2026 年，"能不能调用工具"已经不是一个问题——OpenAI、Anthropic、Google 三家的原生 Function Calling（FC）接口在生产环境都已可用。真正的分歧收缩到三条断层上：Schema 保真度（输出的 JSON 是否每次都死咬你给的 schema）、状态机归属（工具循环的状态保存在服务端还是客户端）、可靠性一致性（单次跑高分，连跑十次还剩多少）。本期横评这三家的原生 FC 接口，并结合 BFCL v3 与 τ-bench 两类主流基准，指出一条被星标和单跑分数掩盖的结论：原生接口的差距不在"会不会调"，而在"调得有多稳"，而稳定性恰恰是单跑榜单测不出来的维度。

原生 FC 接口多维对比

一、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，你在三家跑出来的"合法通过率"会分层。

# 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 描述里是否写清了依赖关系，而非接口本身。

# 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。

原生函数调用循环架构（状态机归属对比）

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 — 三家原生函数调用语法、并行执行、错误处理对比
2. τ-bench: A Benchmark for Tool-Agent-User Interaction (arXiv 2406.12045) — pass^k 可靠性度量与多轮有状态评测方法
3. sierra-research/tau2-bench — GitHub — τ-bench/τ²-bench 仿真框架与策略库约束任务
4. Function Calling Benchmarks Leaderboard 2026 — Awesome Agents — BFCL v3、τ-bench、ToolBench 横向排名汇总
5. τ-bench — Sierra — 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 等场景全覆盖。