2026 年，"能不能调用工具"已经不是一个问题——OpenAI、Anthropic、Google 三家的原生 Function Calling（FC）接口在生产环境都已可用。真正的分歧收缩到三条断层上：**Schema 保真度**（输出的 JSON 是否每次都死咬你给的 schema）、**状态机归属**（工具循环的状态保存在服务端还是客户端）、**可靠性一致性**（单次跑高分，连跑十次还剩多少）。本期横评这三家的原生 FC 接口，并结合 BFCL v3 与 τ-bench 两类主流基准，指出一条被星标和单跑分数掩盖的结论：**原生接口的差距不在"会不会调"，而在"调得有多稳"，而稳定性恰恰是单跑榜单测不出来的维度**。 ## 原生 FC 接口多维对比 | 维度 | OpenAI（Chat / Responses） | Anthropic（Claude） | Google（Gemini） | |------|---------------------------|---------------------|------------------| | Schema 约束方式 | `strict:true` 约束解码，语法级保证 | `input_schema` 子集，靠模型自觉，无原生 strict | `response_schema`（OpenAPI 3.0 子集），较窄 | | 联合类型（anyOf/oneOf） | strict 下原生支持 | 支持 | 历史不支持，2.5 后逐步放宽 | | 并行调用 | `parallel_tool_calls` | `disable_parallel_tool_use` 可关 | 原生支持 | | 流式部分工具调用 | `tool_calls` delta | `input_json_delta` | partial function call | | 工具选择控制 | auto/none/required/指定函数 | auto/any/tool/none | AUTO/ANY/NONE + allowed list | | 状态机归属 | Responses API 服务端有状态 | 客户端管理消息历史 | 会话式，可服务端 | | 工具结果回灌格式 | `function_call_output`（Responses）/ `tool` role | `tool_result` block | `functionResponse` part | | 多跑可靠性（τ-bench pass^k 表现） | 高，但依赖 Responses 循环 | 公认强项，方差低 | 中，schema 压力下波动大 | | 上手难度 | 最低，文档/生态最全 | 中，需手写循环 | 中，schema 子集需适配 | | 变现可包装性 | 极高（企业落地最多） | 高（Agent 类训练营首选） | 中（多模态捆绑） | ## 一、Schema 保真度：约束解码 vs 模型自觉 这是三条断层里最硬的一条。OpenAI 在 Structured Outputs 里提供 `strict: true`，底层走的是**约束解码（constrained decoding）**：在生成每一个 token 时，解码器只允许出现在"当前还能合法构成目标 JSON Schema"的分支里，因此输出**结构上不可能违反 schema**。代价是 schema 受限：必须 `additionalProperties: false`、所有字段进 `required` 或带 `default`、嵌套有层数与属性数上限、对 `$ref/$defs`、`anyOf/oneOf`、`pattern`（正则）、`format` 的支持是逐版本补齐的。 Anthropic 走的是另一条路：`input_schema` 是 JSON Schema 的一个子集，支持枚举、联合、`$ref`，但**没有原生的 grammar 级 strict**。它依赖模型本身对 schema 的遵循能力——在 Claude 4.x 上这个遵循度很高，但它是统计意义上的高，不是语法保证。你仍需要在生产侧加一层 JSON Schema 校验 + 重试。 Gemini 用的是 OpenAPI 3.0 子集（`response_schema`），在三家里**子集最窄**：基本类型、enum、format 没问题，但历史上对联合类型、`additionalProperties` 强约束、`nullable` 的支持滞后，直到 2.5 才逐步放宽。这意味着同一份复杂 schema，你在三家跑出来的"合法通过率"会分层。 ```python # OpenAI：strict 模式，结构级保证 resp = client.responses.create( model="gpt-5", input="查东京和巴黎的天气", tools=[{ "type": "function", "name": "get_weather", "description": "获取当前天气", "parameters": { "type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"], "additionalProperties": False }, "strict": True }], ) # Anthropic：无原生 strict，需外加校验 resp = client.messages.create( model="claude-opus-4-8", max_tokens=1024, tools=[{"name": "get_weather", "description": "获取当前天气", "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}}], messages=[{"role": "user", "content": "查东京和巴黎的天气"}], ) ``` **优缺点**：OpenAI strict 把"保真度"从概率问题降级成了确定性问题，工程上最省心；Anthropic 灵活度高但要自负校验；Gemini 适配成本最高。**变现评估**：这条断层最适合做企业内训——"如何让你的 FC 输出 100% 合法"是付费点，可包装成"结构化输出训练营"。 ## 二、状态机归属：服务端有状态 vs 客户端手撸循环 OpenAI 的 Responses API 把**工具循环的状态搬到了服务端**：你用 `previous_response_id` 串起多轮，服务端帮你维持上下文与中间步骤，内置工具（web search、file search、computer use）的循环也在服务端跑。这降低了客户端复杂度，但代价是你**把状态机交了出去**——可观测性、上下文裁剪、重放调试都受限于平台暴露的接口。 Anthropic 至今是**无状态设计**：工具循环完全由客户端驱动，`messages` 数组里的 `tool_use` / `tool_result` block 由你自己拼接。这给你最大的控制权——你可以插桩、改写、压缩历史、做断点续跑——但要自己实现完整的 ReAct 循环、错误回灌和消息格式管理。这也正是 Anthropic 在可调试性上被开发者偏爱的原因。 Gemini 介于两者之间：AI Studio 的 `chats` 会话是**有状态的**，Vertex AI 也提供会话抽象，但你同样可以在"无状态单发"模式下完全自控。 这条断层直接影响**上下文成本**和**可调试性**两个生产指标。服务端有状态省了客户端的实现量，但账单不透明、状态黑盒；客户端无状态累但白盒、可裁剪。**变现评估**：可作为"Agent 工程化进阶营"的核心模块——讲透状态机归属，是区分"调 API"与"做产品"的分水岭。 ## 三、并行调用：能力都在，耦合是暗坑 三家都支持一次返回多个工具调用（OpenAI `parallel_tool_calls`、Anthropic 多个 `tool_use` block、Gemini 多个 `functionCall`），Anthropic 还提供 `disable_parallel_tool_use` 让你能强制串行。 但"能并行"和"该并行"是两回事。**真正塌方发生在隐藏耦合上**：两个工具表面上独立，实则第二个的入参依赖第一个的结果（比如先查订单、再用订单号查物流），模型若误判为独立、同时发出，第二个就会带着空值或臆造值调用。这个问题在三家的原生接口上**不会自动帮你拦截**——它们都诚实地把判断权交还给模型。所以并行能力的实际收益，高度依赖 schema 描述里是否写清了依赖关系，而非接口本身。 ```python # Anthropic：可以一键关掉并行，强制串行以避免耦合误判 resp = client.messages.create( model="claude-opus-4-8", tools=tools, tool_choice={"type": "auto", "disable_parallel_tool_use": True}, messages=msgs, ) ``` **优缺点**：并行能显著降延迟，但耦合误判带来的"看似成功实则脏数据"最难排查。**变现评估**：适合做"Agent 性能优化"专题课的硬核章节。 ## 四、流式工具调用：partial JSON 的工程税 三家都支持流式返回工具调用的**部分参数**（OpenAI 的 `tool_calls` delta、Anthropic 的 `input_json_delta`、Gemini 的 partial function call）。这让你能在参数还没生成完时就开始渲染 UI（比如边出边填表单）。 但代价是**partial JSON 解析**：参数 JSON 是逐 token 增长的，中间任何一刻都不是合法 JSON，你需要用增量解析器（如 `partial-json`、`jsonrepair`）或自己写状态机来消费。三家的 delta 粒度还不一致，迁移时这部分几乎要重写。**变现评估**：偏前端工程，可做成"流式 Agent UX"小课。 ## 五、可靠性一致性：pass^1 高≠pass^k 高 这是被单跑榜单掩盖得最深的断层。τ-bench（Sierra 出品）提出了 **pass^k** 思路：衡量模型在 k 次独立运行中表现出的**一致性/可靠性**。它的核心论点是——很多模型 pass^1（单跑通过率）很高，但连跑多次后**方差巨大**，pass^k 暴露的就是这种"时灵时不灵"。在生产里，一个 90% 单跑通过但连跑十次才稳定通过的 Agent，比一个 75% 但次次 75% 的 Agent 风险更高，因为前者让运维永远在赌。 BFCL v3（伯克利 Gorilla 团队）则在 v3 引入了**多轮、有状态、真实 API 调用**的评测，分 AST（语法树匹配）、Exec（真实执行）、Relevance（识别无关问题）、Multi（多轮）等维度，比早期单轮 AST 进步很多，但它仍是**任务级正确性**度量，对"多次跑稳不稳"的刻画不如 τ-bench 的 pass^k 直接。 落实到三家：Anthropic 在 τ-bench 这类多轮、有策略库（policy DB）约束的任务上**方差公认较低**，是其 Agent 口碑的基石；OpenAI 依赖 Responses 循环，稳定性随循环复杂度波动；Gemini 在 schema 压力大的任务上波动最大。**变现评估**："可靠性工程"是 2026 年企业最愿意付费的议题——把 pass^k 讲透，是高客单价训练营的核心。 ## 六、工具结果回灌：格式差异即迁移税 工具调用完了，结果怎么喂回去，三家格式完全不同：OpenAI Responses 用 `function_call_output`（Chat Completions 用 `role:"tool"`），Anthropic 用 `tool_result` block 套在 user message 里，Gemini 用 `functionResponse` part。这导致**同一套工具循环逻辑在三家之间不能直接迁移**——你换一家就要重写消息装配层。 更隐蔽的是**错误回灌**：工具抛错时，你要不要把错误字符串塞回上下文让模型重试？三家都支持，但语义粒度不一。Anthropic 的 `is_error` 标志、OpenAI 的错误字符串约定、Gemini 的 error 字段，处理姿势各异。这正是"模型无关税"在接口层的具象化：上层框架（LangChain 等）帮你抹平这些差异，但抹平的代价是又多了一层抽象与约束。 ## 七、基准之间的鸿沟：BFCL 与 τ-bench 测的不是一回事 最后必须提醒：**别用一个榜单下结论**。BFCL v3 强调"函数调用语法与执行的准确度"，适合衡量"单步工具能力"；τ-bench 强调"多轮、有状态、有策略约束下的任务完成与可靠性"，适合衡量"Agent 化能力"。一个模型在 BFCL 上登顶，不代表它在 τ-bench 的 pass^k 上也稳——后者才是更接近生产的信号。**结论性建议**：评测工具调用时，BFCL 与 τ-bench 至少各跑一份，并且 τ-bench 一定要看 pass^k 而非只看 pass^1。 ## 原生函数调用循环架构（状态机归属对比） ```mermaid flowchart TD U[用户输入] --> LOOP{工具循环} subgraph OPEN[OpenAI Responses：服务端有状态] O1[服务端维持 previous_response_id] --> O2[服务端决定调工具] O2 --> O3[服务端内置工具循环] O3 --> O4[状态黑盒·可观测性受限] end subgraph ANT[Anthropic：客户端有状态] A1[客户端拼 messages] --> A2[模型返回 tool_use block] A2 --> A3[客户端执行 + 拼 tool_result] A3 --> A4[白盒·可插桩可裁剪] end subgraph GEM[Gemini：会话式] G1[chats 会话/无状态单发] --> G2[functionCall] G2 --> G3[functionResponse 回灌] G3 --> G4[模式可切换] end LOOP --> OPEN LOOP --> ANT LOOP --> GEM O4 --> R[结果] A4 --> R G4 --> R ``` ## 推荐方案 - **追求结构 100% 合法、团队工程能力强**：选 OpenAI strict + Responses API。把保真度交给约束解码，省下校验层；接受状态黑盒的代价。 - **做多轮 Agent、看重可靠性与可调试性**：选 Anthropic。方差低、白盒可控，但要自己实现完整工具循环与 schema 校验。 - **多模态优先、schema 较简单**：选 Gemini。注意提前把 schema 适配到它较窄的子集，复杂联合类型要降级拆分。 - **跨厂商、要规避迁移税**：上层用一个抽象层（LangChain / LiteLLM），但清醒认识到这一层带来的约束税与延迟税。 - **评测动作**：BFCL v3 + τ-bench 各一份，τ-bench 必看 pass^k；不要被任何单跑榜单带偏选型。 ## 参考来源 1. [Function Calling: OpenAI vs Anthropic vs Gemini 2026 — APIScout](https://apiscout.dev/guides/function-calling-ai-apis-openai-vs-anthropic-vs-gemini-2026) — 三家原生函数调用语法、并行执行、错误处理对比 2. [τ-bench: A Benchmark for Tool-Agent-User Interaction (arXiv 2406.12045)](https://arxiv.org/abs/2406.12045) — pass^k 可靠性度量与多轮有状态评测方法 3. [sierra-research/tau2-bench — GitHub](https://github.com/sierra-research/tau2-bench) — τ-bench/τ²-bench 仿真框架与策略库约束任务 4. [Function Calling Benchmarks Leaderboard 2026 — Awesome Agents](https://awesomeagents.ai/leaderboards/function-calling-benchmarks-leaderboard/) — BFCL v3、τ-bench、ToolBench 横向排名汇总 5. [τ-bench — Sierra](https://sierra.ai/blog/tau-bench-shaping-development-evaluation-agents) — pass^k 背后的"可靠性优于单跑通过率"论点 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。