Function Calling 与普通 JSON 输出有什么区别？

简化版

普通 JSON 输出是让模型生成符合约定的数据文本；Function Calling 则由 API 协议提供可选工具及参数 Schema，模型返回“调用哪个工具、参数是什么”的结构化意图，应用执行工具后再把结果交回模型。Function Calling 更适合需要工具选择和多轮执行的场景，JSON 输出更适合抽取、分类等只需要结构化结果的场景；两者都只能约束格式，不能替代业务校验、权限检查和真实执行。

详细版

区别不在于最终是否长得像 JSON，而在交互语义。结构化 JSON 通常是最终业务结果；Function Calling 的输出是一个待执行动作，包含工具名、调用 ID 与参数，后续还要经过网关校验、执行和 Observation 回传。

维度	JSON 输出	Function Calling
目标	生成结构化内容	选择并请求执行工具
协议	通常是一轮响应	可能多轮调用与回传
Schema	约束结果字段	约束各工具参数
应用职责	解析和使用	授权、执行、回传、重试

如果只需从简历抽取姓名和技能，用结构化输出更直接；若要先搜索客户、再创建工单，应使用工具调用协议。无论哪种方式，应用都要验证 Schema 与业务规则；工具参数还要做最小权限、幂等和人工审批。不能把模型给出的函数名直接反射执行。

完整版教学

一、两者表面相似，协议角色不同

模型返回的工具参数通常也是 JSON，所以容易误以为 Function Calling 只是“更稳定的 JSON”。真正差异是协议把结果声明为一个动作候选，并规定工具定义、调用 ID、工具结果消息和后续生成的交互顺序。

普通结构化输出往往到此结束：应用取得对象并保存或展示。工具调用却只是中间步骤，应用还要判断能否执行、执行哪个真实实现，并把结果与原调用关联。

记忆钩子：JSON 输出回答“结果是什么”，Function Calling 回答“下一步想调用什么”。

二、普通 JSON 输出适合数据任务

分类、信息抽取、表单填充和评分等任务，最终产物本身就是结构化数据。给定 Schema 后，服务端可以保证语法合法或减少格式错误，应用再做字段和业务验证。

{
  "sentiment": "positive",
  "confidence": 0.82,
  "evidence": ["交付速度很快"]
}

这里没有外部动作。即使对象完全符合 Schema，confidence 也可能未校准、evidence 也可能不支持结论，所以格式保证不等于语义正确。

三、Function Calling 是一次受控协商

应用把工具名称、描述和参数 Schema提供给模型；模型选择工具并产生参数；应用校验后执行；工具结果以带调用 ID 的消息返回；模型基于结果继续调用或生成答案。

App: tools=[search_order, create_refund]
Model: call search_order({order_id:"A1"}, call_id="c7")
App: tool_result(call_id="c7", status="paid")
Model: call create_refund(...)

调用 ID 对并行工具尤其重要，防止两个结果串线。模型只能提出调用，真实执行权仍在应用。

四、Schema 能约束什么，不能约束什么

Schema 可约束类型、必填字段、枚举和部分范围。例如 amount 必须大于 0，currency 只能是 CNY 或 USD。它不能证明订单属于当前用户，也不能证明退款金额没有超过实付金额。

校验层	示例	负责组件
语法	JSON 是否可解析	API/解析器
结构	字段、类型、枚举	JSON Schema
业务	退款不超过实付	领域服务
权限	用户能否退该订单	工具网关
副作用	是否仅退款一次	幂等执行器

因此 Schema 是入口校验，不是安全边界。

五、工具选择也可能出错

模型可能选择相似但不合适的工具，或者在信息不足时猜参数。工具描述要清楚说明适用条件、禁止场景和关键差异，但应用仍要检查前置条件。

假设有 send_preview_email 与 send_email，仅靠名字区分很容易误发。更稳的设计是让预览工具无副作用，真实发送要求审批令牌；即使模型选错，也会被执行层拦截。

工具集合也不宜一次暴露几百个。可先按意图路由候选工具，减少选择混淆和 Schema token 成本。

六、多轮调用带来状态与错误处理

工具超时、部分成功、异步等待和并行结果都要求应用维护状态。Function Calling 本身不会替你完成重试、幂等或恢复；框架把循环封装起来，也不能消除这些工程问题。

若写工具响应超时，不能让模型立即再调用一次。控制器应使用幂等键查询外部状态，再把“已成功、未执行或未知”作为 Observation 返回。

达到最大步骤、费用或时间后要安全停止，并向用户解释已完成和未完成部分。

七、何时只用 JSON，何时组合使用

单轮抽取优先结构化输出，流程编排用 Function Calling。两者也可组合：先用 JSON 抽取意图和候选实体，再由确定性规则决定开放哪些工具；工具执行完成后，再用 JSON 生成最终报告对象。

假设 1000 次字段抽取不需要外部数据，强行包成工具会增加一次调度和协议复杂度，却没有收益。反过来，要求 JSON 返回 {"action":"refund"} 后应用直接退款，本质是在自制不完整工具协议，容易漏掉调用 ID、权限和结果回传。

选择依据是结果是否需要改变或读取外部世界，而不是团队偏好哪种 SDK。

八、测试要覆盖协议而非只看格式

JSON 输出测试 Schema 通过率、字段准确率、缺失和拒答。Function Calling 还要测试正确工具选择率、参数准确率、无工具场景、并行关联、错误恢复、越权拦截和副作用幂等。

例如 200 个工具任务中，190 次选对工具，180 次参数也正确，最终 175 次执行成功。不能只报告 95% 工具选择率；端到端成功率实际是 87.5%，中间还有参数与执行损失。

日志记录工具定义版本、调用 ID、规范化参数、策略结果和工具 Observation，以便定位错误发生在哪一层。

九、常见误区与追问

误区：Function Calling 会真的在模型内部执行函数。 模型只输出调用候选，应用负责真实执行。
误区：返回符合 Schema 就可以直接入库。 还需业务、权限、来源和范围校验。
误区：任何 JSON 任务都应该包装成函数。 单轮抽取使用结构化输出更简单。
误区：工具描述写得好就不会选错。 运行时前置条件和权限仍必须校验。
误区：框架自动循环就解决了重试和幂等。 写操作的未知结果与恢复仍是应用责任。
追问：模型返回不存在的工具怎么办？ 只接受注册表中的工具名，拒绝并返回可恢复错误。
追问：多个工具能并行吗？ 无依赖且无资源冲突时可以，用调用 ID 关联结果。
追问：结构化输出是否完全可靠？ 语法可强约束，语义与事实仍需独立验证。

十、加强记忆

区分两者记住“数据结果”和“动作意图”：JSON 输出交付一个结构化对象，适合抽取与分类；Function Calling 交付工具名、调用 ID 和参数，应用还要授权、执行并回传结果。Schema 只守住形状，业务规则守语义，权限网关守边界，幂等执行器守副作用。是否要读写外部世界，是选择协议的关键。

简化版

详细版