工具调用的苦涩教训：当代码取代 JSON，14 个模型同台竞技

原论文： The Bitter Lesson of Tool Calling
作者： Ishan Patel, Sahil Sen, Elias Lumer, Vamse Kumar Subbiah（PricewaterhouseCoopers）
arXiv： 2608.06370v1，2026 年 8 月 6 日

一个点菜的故事

想象你在餐厅点菜。

方式一（JSON 工具调用）： 你跟服务员说"来一份宫保鸡丁"。服务员去厨房，等菜做好，端回来。你说"再来一碗米饭"。服务员再去。你说"把宫保鸡丁和米饭拌在一起"。服务员第三次跑腿。每一步都是：你说话 → 服务员传话 → 厨房做 → 端回来 → 你再说下一句。

方式二（程序化工具调用，PTC）： 你递给服务员一张纸条，上面写着一行 Python 代码：

dish = order("宫保鸡丁")
rice = order("米饭")
mix(dish, rice)
serve()

服务员一次性把纸条给厨房，厨房自己看着办——四道工序一气呵成，你只等最后那盘拌好端上来的菜。

这就是这篇论文的核心对比。方式一是当前主流的 JSON 工具调用——模型每调一次工具，吐一个 JSON 对象，等结果，再吐下一个。方式二是程序化工具调用（PTC）——模型直接写一段 Python 脚本，把工具当函数调用，链式执行、并行执行、条件分支，全在一个回合里搞定。

听起来方式二明显更好？但直到这篇论文之前，没有人系统地在标准基准上把两种范式拉出来，跨多个模型世代做过对照实验。

14 个模型，一个基准，四个维度

论文选了 BFCL v4（Berkeley Function Calling Leaderboard）作为主战场，拉来 14 个语言模型同台竞技。对比的不只是单次调用准确率，还有三个真实场景下的"压力测试"：

1. 链式调用（Chaining）：A 的输出是 B 的输入，B 的输出是 C 的输入。像点菜那个例子。
2. 并行扇出（Parallel Fan-out）：同时调十个工具，等所有结果回来。像让十个服务员同时去取十道菜。
3. 上下文腐烂（Context Rot）：在长对话里塞一堆无关信息，看模型还能不能正确调工具。像餐厅里人声鼎沸、菜单被风吹得乱翻。

四个维度，14 个模型，两种范式。实验设计本身就已经比大多数"我比你强"的论文严谨。

核心数字

结果出来了，几个关键数字：

• 11/14：在 BFCL v4 主测试上，PTC 在 14 个模型中的 11 个上匹配或超过 JSON 调用。
• 10.6%：GPT-5.6 家族用 PTC 比用 JSON 提升了 10.6 个百分点。这是最大的单模型增益。
• 13/14：在并行扇出场景下，PTC 在 14 个模型中的 13 个上匹配或超过 JSON。几乎全胜。
• 2.3%：在上下文腐烂场景下，JSON 调用平均掉 2.3%，PTC 基本不掉。

这几个数字讲了一个一致的故事：PTC 不是"另一种选择"，它在大多数情况下就是更好。尤其在链式和并行场景下，PTC 的优势是结构性的——JSON 模型需要模型自己规划"先调 A，等结果，再调 B"，而 PTC 直接把这个规划写进代码，Python 解释器替模型执行了规划逻辑。

为什么叫"苦涩教训"

论文标题致敬了 Rich Sutton 2019 年那篇著名的《The Bitter Lesson》。Sutton 的核心论点是：在 AI 发展史上，所有依赖人类先验知识的技巧（特征工程、领域知识、手工架构），最终都被"用更多算力 + 更通用方法"的路线碾压。越通用，越赢。

这篇论文把同样的逻辑搬到了工具调用上：

"PTC 的优势随模型能力增长而增长。当前世代模型在 PTC 上表现更好，未来世代模型会更擅长写代码，PTC 的优势会进一步扩大。"

换句话说，JSON 工具调用本质上是一种"人类帮模型规划好了调用结构"的先验。当代码能力足够强时，模型自己写代码调工具，比人类替它设计 JSON schema 更灵活、更高效。人类设计得越少，模型发挥得越好——这就是工具调用领域的苦涩教训。

论文还做了一个有意思的分析：模型世代预测 PTC 可行性。他们发现，越新的模型世代（GPT-5.6 > GPT-4.5 > GPT-4o），PTC 相对 JSON 的增益越大。这和 Sutton 的预言完全一致——能力越强，通用方法（写代码）越占优。

PTC 的结构性优势：Fan-Out

论文最精彩的一段分析是关于并行扇出（Fan-Out）的。

JSON 模式下做并行扇出：模型必须在一次输出里生成多个 JSON 对象，每个对象调一个工具。这要求模型自己理解"并行"的语义——它得在脑子里规划好"我要同时调这十个工具"，然后一次性吐出来。模型经常搞砸：漏掉几个、重复几个、或者顺序混乱。

PTC 模式下做并行扇出：模型写一行 results = [tool(x) for x in inputs]。Python 的列表推导式天然就是并行的语义。模型不需要理解"并行"，它只需要会写列表推导式，Python 解释器替它并行执行。

这是一个深刻的洞察：PTC 把"理解并行"这个认知负担从模型转移到了编程语言。模型不需要学会并行思维，只需要会用 for 循环。这和"让 LLM 当诗人，让 Prolog 当会计"是同一个思路——把模型不擅长的认知任务外包给擅长的工具。

链式调用同理。JSON 模式下，模型得记住"上一步的输出要喂给下一步"——这是一个状态管理任务，模型容易忘。PTC 模式下，模型写 a = step1(); b = step2(a); c = step3(b)，变量名就是状态，Python 替模型记住。

上下文腐烂：PTC 的隐藏优势

上下文腐烂（Context Rot）是这篇论文造的一个词，指长对话里无关信息累积导致工具调用准确率下降。这是真实场景里非常常见的问题——你跟助手聊了半小时，突然让它调个工具，它可能把前面对话里的无关信息混进工具调用的参数里。

JSON 模式平均掉 2.3%，PTC 基本不掉。为什么？因为 PTC 把工具调用隔离在代码块里——代码就是代码，不受对话上下文污染。模型写 order("宫保鸡丁") 时，"宫保鸡丁"这个参数在代码语法结构里，不会被前面对话里提到的"麻婆豆腐"干扰。JSON 模式下，模型在生成 JSON 时更容易被上下文带偏。

隔离就是防护。这和"把推理外包给 Prolog"是同一个道理——结构化的容器比自然语言更抗噪音。

诚实评价：PTC 不是银弹

论文也坦率说了局限：

1. PTC 只对代码能力强的模型有效。14 个模型里有 3 个 PTC 反而比 JSON 差，都是代码能力较弱的模型。PTC 的前提是模型会写 Python——如果模型连 for 循环都写不对，给它 PTC 就是给它一把不会用的刀。
2. PTC 的优势可能被未来模型抹平。如果未来模型在 JSON 模式下也能完美规划并行和链式调用，PTC 的优势就会缩小。但论文的分析显示趋势相反——越强的模型，PTC 增益越大。所以短期内 PTC 的优势会扩大，不是缩小。
3. BFCL v4 是合成基准，真实场景可能不同。论文承认，真实场景的工具调用可能涉及更复杂的错误处理、重试逻辑、超时管理，这些在 BFCL v4 里没测。
4. PTC 的可调试性是双刃剑。代码出错时，调试 Python 脚本比调试 JSON 序列更难——错误信息更长、调用栈更深。对开发者要求更高。

这篇论文的位置

把它放到更大的图景里看：

• Sutton 的苦涩教训（2019）：通用方法 > 手工先验。
• Anthropic 推出 PTC（2024）：把"让模型写代码调工具"产品化。
• 这篇论文（2026）：系统验证 PTC 确实更好，且优势随模型能力增长。

这是一条从"哲学论断"到"产品实现"到"实证验证"的完整链条。论文标题里的"苦涩"二字，既是致敬 Sutton，也是在说：工具调用领域也逃不过这个规律——人类设计得越少，模型发挥得越好。

对 Agent 工程师来说，这篇论文的实操含义很清楚：如果你的模型代码能力强，PTC 在大多数场景下就是更好的选择。JSON 工具调用不是"标准做法"，只是"历史做法"。

概念谱系：又一个"分工比统一更有效"

这篇论文的发现可以归入我们一直在追踪的概念谱系——"分工比统一更有效"：

• 章鱼 DNA 预训练 + RNA 推理时计算
• Euclid-MCP：LLM 当诗人，Prolog 当会计
• Rebucca：小模型初筛 + 大模型验证
• PTC：模型写代码，Python 解释器管执行

PTC 的核心就是把"规划调用结构"（模型擅长）和"执行调用结构"（解释器擅长）分开。模型不需要自己执行并行和链式——它只需要表达意图，解释器替它执行。分工比统一更有效，又一次。

结论

这篇论文做了一件简单但重要的事：把一个被产品化但未被严格验证的范式（PTC）拉到标准基准上跑了一遍。结果支持 PTC——11/14 模型上更好，13/14 并行场景更好，上下文腐烂场景更稳。而且优势随模型世代增长。

"苦涩教训"的标题既是致敬也是预言：工具调用领域，人类设计得越少，模型发挥得越好。JSON 不是终点，只是一个过渡形态。

论文链接： https://arxiv.org/abs/2608.06370
HTML 版本： https://arxiv.org/html/2608.06370v1
代码： 论文未公开代码仓库（BFCL v4 基准见 https://gorilla.cs.berkeley.edu/blogs/13_bfcl_v4.html）