让大模型调用工具，主流做法是让它输出一段JSON格式的函数调用。每个API都这么设计，开发者也习惯了。但PwC的一个研究团队在今年8月发表的论文里问了一个简单问题：既然模型已经会写代码了，为什么不让它直接写Python脚本调用工具？
他们用程序化工具调用（Programmatic Tool Calling，简称PTC）替代JSON工具调用，在BFCL v4基准上测了14个模型。结果有点出乎意料。
图注：14个模型在BFCL v4上的JSON vs PTC准确率对比，PTC在11个模型上持平或超越JSON
BFCL v4是伯克利发布的工具调用评测集，包含309个测试条目，覆盖8个任务类别——从简单的单次调用到多工具并行、实时用户查询。这个评测集是目前业界公认的Agent工具调用能力标准测试。
11比3的格局
14个模型里，PTC在11个上达到或超越JSON工具调用的准确率。GPT-5.6家族的提升最明显，Sol和Terra各比JSON基线高10.6个百分点。Claude Sonnet 5从80.8%跳到96.2%，Opus 4.8从80.8%跳到94.2%。
但PTC不是全面碾压。GPT-4o、GPT-4.1和GPT-5这几个老模型上PTC反而更差。GPT-4.1从98.1%暴跌到40.4%，主要原因是\n编码问题在链式任务里特别致命——每个中间计算都需要多行脚本，编码一崩全崩。论文作者把这个现象总结为"代际分界"：PTC的可行性按模型代际划分，而不是按模型家族划分。Anthropic五个模型从Haiku 4.5到Sonnet 5，PTC跟JSON基本持平。OpenAI则从GPT-5-nano才开始追上，GPT-4o时代PTC还落后26.9个百分点。
CodeAct的早期研究已经证明代码动作在多工具任务上比JSON高出20%的任务成功率，PwC这篇论文把这个结论在更大规模上验证了。OpenAI自己的框架也在往这个方向走——Hugging Face和Anthropic的生产实践已经把代码组合当作默认接口。Recursive Agent Harnesses的后续工作进一步把代码执行原语扩展到并行子Agent生成，绕过了JSON函数调用在高扇出时的逐轮限制。
论文也坦承了四个局限。第一，BFCL v4用的是echo-return stub——每个函数只返回参数本身，不执行真正的API调用。所以测的是参数序列化准确率，不是端到端工具使用正确率。真实场景里返回值会影响后续调用，这个变量没有覆盖。第二，消融实验样本量小，每个条件只有31到52个条目，个体模型结果置信区间宽，只能看跨模型的聚合模式。第三，BFCL v4自身有20%的评测-人工对齐偏差。第四，PTC在短链任务里有固定token开销——系统提示要嵌入完整代码模板作为prose，而JSON通过API的tools参数传递，某些provider不计入对话token。这些局限不改变核心结论，但提醒读者：11比3是方向性结果，不是精确数字。
图注：链式任务消融实验，链长2-20，PTC在长链上的优势随链长增长而扩大
长链任务拉开差距
真正的分水岭在长链任务上。JSON工具调用每一步都要等模型输出一个JSON对象、接收返回值，再输出下一个——每多一环就多一次推理。PTC把整条链写在一个脚本里，一次执行完。这中间的推理轮次差异，链越长越大。
论文的链式消融实验用了52个测试条目，链长从2到20。结果显示，当链长≥12时，PTC比JSON的绝对准确率优势达到18.8个百分点。短链时两边差不多，链越长PTC越占优。这个差距不是模型变聪明能弥补的，是调用范式的结构性差异。
为什么JSON在长链里会出问题？每一步推理都有出错概率，十步以上的链，每步98%准确率，十步下来只剩81.7%。PTC把十步写在一个脚本里执行，中间状态直接在代码里传递，不经过模型的推理轮次。故障模式从"每步独立失败概率的乘积"变成了"整个脚本成功或失败"，这对长程Agent的可靠性是质变。
并行和上下文洪泛
并行扇出的实验更能说明问题。JSON工具调用在N=70时还能保持100%的枚举准确率，到N=72就掉到75%，N=100直接归零。模型要逐个枚举所有工具调用对象，N太大就扛不住。PTC在N=100时仍然保持100%，因为脚本可以用循环和列表推导批量生成调用。这是JSON范式的硬性结构限制。
上下文洪泛测试也说明了问题。当上下文里塞了128个函数定义——大部分是跟当前任务无关的干扰项——JSON工具调用平均下降2.3%，文件系统发现法暴跌32%。PTC基本稳定。原因在于PTC不依赖上下文里逐个列出所有函数定义，模型从源码模块里import需要的函数，干扰项的存在不影响它找到正确的工具。
成本方面也有影响。PTC在短链任务里输入token开销是JSON的1.5倍，因为系统提示要嵌入完整的Python代码模板。但高扇出场景下情况反转——N=48时JSON消耗5097个token，PTC只需3535个。对于高频调用场景，这个成本差会累积成可观的数字。
图注：OpenAI和Anthropic两家的PTC vs JSON准确率按模型代际对比，呈现相反的迁移模式
源势AI观点
工具调用范式的选择不是纯粹的学术问题，直接影响Agent的生产表现。我们在企业级Agent落地中遇到过类似的瓶颈——长链任务里JSON调用每一步的延迟和失败率会累积，十步以上的任务成功率断崖式下降。
论文的数据印证了我们的工程判断。我们的Token聚合平台支持20多种模型，不同模型在工具调用上的表现差异很大。选模型不能只看benchmark分数，还得看它对PTC的支持程度。新一代模型越来越倾向于代码执行范式，这不是偶然——模型本身的代码能力越强，PTC的优势就越明显。
对企业用户的建议：如果你的Agent任务链经常超过5步，或者需要大量并行工具调用，认真考虑从JSON迁移到PTC。Anthropic全系列模型已经原生支持，OpenAI从GPT-5-nano开始也跟上了。工具调用范式的迁移还在早期，大多数生产框架仍以JSON为主。但Anthropic从第一代模型起PTC就跟JSON持平这个事实，暗示了一条更优的工程路径。在新的长链任务场景里直接上PTC，别等JSON的硬性限制撞上来了再改。
