Agent 接外部工具，过去两年的行业默认动作是同一个：模型吐一段 JSON 函数调用，运行时执行，结果塞回上下文，模型再想一轮，决定下一步。这套流程自然到很多人把它当成"Agent 本该如此"。
普华永道（PwC）技术团队的一篇新论文，对这个默认动作提出了质疑。他们把"程序化工具调用"（PTC：模型写一段 Python 脚本，一次把工具调完）和原生 JSON 工具调用放到 BFCL v4 基准（309 个任务、8 类场景）上对比，测了 14 个模型。结论不含糊：11 个模型的 PTC 准确率持平或超过 JSON，GPT-5.6 家族最高提升 10.6 个百分点。（来源：PwC《The Bitter Lesson of Tool Calling》，arXiv:2608.06370）
图注：两种范式：JSON 每轮调一个工具，PTC 写脚本一次调完（来源：PwC 论文 Figure 1）
JSON 输在哪
三组消融实验，把 JSON 的败点定位得很准。
链式调用。任务要求 f1 的输出喂给 f2 时，JSON 需要两个推理轮次，PTC 把两次调用写进同一段脚本。链长 ≥12 时，PTC 平均领先 JSON 18.8 个百分点；Claude Sonnet 5 从 80.8% 升到 96.2%。多出来的那个推理轮次，就是 JSON 为每一环交的税。
并行扇出。13 个模型在并行消融里 PTC 持平或更好，GPT-5 从 71.9% 升到 96.9%。上限测试更直接：一步要发 70~72 个并行调用时，Claude Sonnet 5 的 JSON 模式开始丢调用；PTC 在 N=100 时仍保持 100% 的调用完整性。这不是能力问题，是结构上限——原生协议一轮就发不出这么多调用。
上下文腐烂。往上下文里灌 128 个 decoy 函数定义，JSON 准确率平均掉 2.3%，PTC 基本稳住。同组实验里，文件系统探索方案（让模型自己去读工具定义文件）平均掉 32%，论文只把它当参照点列出。工具定义本身就是污染源，谁往上下文里塞得少，谁就稳。
还有个细节值得单独说。并行实验里，模型经常不真执行那 N 个调用，直接用参数化知识回答聚合问题。打分器算它对，但不代表工具链路真的在跑。论文因此把枚举准确率和聚合准确率分开报，以前者为主指标。
图注：14 个模型 BFCL v4 准确率对比，11 个模型 PTC 持平或反超（来源：PwC 论文 Table 2）
老模型的死法
PTC 不是万能药。GPT-4o 从 81.9% 掉到 55.0%，GPT-4.1 从 81.9% 掉到 62.1%，GPT-5.4-mini 从 79.3% 掉到 55.0%；链式消融里 GPT-4.1 更夸张，98.1% 直接崩到 40.4%。死法一致：模型在多行脚本里写出字面的 \n 转义而不是真换行，子进程语法报错。同期发布的 GPT-5-nano 没有这个毛病，说明修复是在 GPT-5.4-mini 和 GPT-5 之间进入训练数据的。
论文也自己交底：消融样本只有 31~52 条，单个模型的结果只能看方向，跨模型的聚合模式才算可靠。
Anthropic 已经用脚投票
这个结论不算新鲜。去年 11 月，Anthropic 就在 Claude 平台把 Programmatic Tool Calling 做成了 beta 功能，官方博客写的理由和论文的实测对上了：自然语言工具调用每次都要走一整轮推理，中间结果不管有没有用都会堆进上下文。（来源：Anthropic 工程博客《Introducing advanced tool use》，2025-11-24）
Anthropic 还公布过更直观的数字：内部一个案例里，工具定义在优化前吃掉 134K tokens；一个常见的 5 服务器配置（GitHub、Slack、Sentry 等 58 个工具）在对话开始前就消耗约 55K tokens。PTC 上线后的内部测试里，复杂研究任务的平均 token 消耗从 43,588 降到 27,297，省了 37%；GIA 基准准确率从 46.5% 升到 51.2%。官方博客的例子很说明问题：查报销单，传统方式要把两千多条明细全灌进上下文；PTC 让脚本在沙箱里算完，只把超预算的几个人名送进上下文，200KB 变 1KB。能读写上千行表格的 Claude for Excel，靠的就是这套机制。同批发布的 Tool Search Tool 把 50 多个工具的上下文开销砍掉 85%，Opus 4 在大型工具库上的准确率从 49% 升到 74%。方向已经很清楚：工具定义从"全量预载"转向"按需加载"，工具调用从"一轮一次"转向"一段脚本写完"。MCP 生态还在扩张，Agent 接的工具只会越来越多，上下文这笔账只会越算越紧。谁先解决它，谁先做出更复杂的 Agent。
再往前追，理论源头是 CodeAct（UIUC，2024）：用可执行代码作为 Agent 的统一动作空间，成功率高 20%，交互轮次少 30%。原文测了 17 个模型，提升集中在并行和组合场景；PwC 两年后这三组消融，盯的也是同一批场景。（来源：CodeAct，arXiv:2402.01030）
图注：链式消融：链越长两种范式差距越大，Claude Sonnet 5 从 80.8% 升到 96.2%（来源：PwC 论文 Table 3）
源势AI怎么看
我们这一年做企业 Agent 落地，体会是：工具接口设计，比模型选型更影响成败。这篇论文给出三个可操作的判断。
把工具当代码 API，而不是 JSON 插槽。harness 层提供类型化 stub 加代码执行环境，长链、高扇出任务更稳也更省。我们给企业客户做智能体时做法一样：能写进脚本的编排逻辑，绝不交给模型一轮轮吐 JSON。Anthropic 给过一条经验线：工具定义超过 1 万 tokens、或工具数超过 10 个，就该上按需加载和代码编排。多数企业 Agent 一上线就过线。
范式选择跟着模型代际走，不跟着厂商走。论文里分野线很清楚：Anthropic 五个模型和最新的三个 GPT-5.6 版本全部站住，GPT-4o、GPT-4.1 这些老模型在 PTC 下直接崩。老模型别急着迁。
JSON 也没死。短链、单调用任务上两者几乎打平；PTC 有固定的系统提示开销，扇出 N 到 26 左右 token 成本才反超变省。论文里 PTC 在 parallel 类任务上平均还落后 JSON 14.1%，部分源于老模型的换行 bug，但也说明脚本范式在多调用场景有自己的坑。简单任务保持简单。
工具调用的分野，正在从"会不会调"变成"怎么调"。我们的 Token 聚合平台也在往同一方向走：20 多个模型放在一个 API Key 后面，编排逻辑尽量从模型侧下沉到平台侧，模型只盯结果，上下文和推理轮次的浪费由平台吸收。这和 PTC 是同一笔账，只是算的位置不同。
做 Agent 的团队，是时候重写工具层了。
