工具调用的苦涩教训

💬 在14个模型、BFCL v4基准上系统对比"工具即代码"（程序化工具调用）与原生JSON工具调用，发现前者在11/14个模型上打平或超越后者，GPT-5.6系列提升达10.6%；在并行扇出场景下13/14模型打平或更优，且在上下文腐化（context rot）条件下保持稳定，而JSON基线平均下降2.3%。

🎯 问题

"工具即代码"缺少系统性的实证评估

工具使用让LLM能超越训练数据本身去执行动作，而对于具备代码能力的模型，程序化工具调用（programmatic tool calling, PTC）用可以自然链式调用和并行化的脚本，取代了僵硬的JSON调用形式，进一步扩展了这种能力。然而，此前一直缺少在既有基准上、跨当前与历史多代模型、在贴近真实任务条件下对"工具即代码"范式的系统性评估。

🔬 方法

14个模型 × BFCL v4，对比PTC与原生JSON工具调用

作者在 BFCL v4 基准上，对14个语言模型系统对比程序化工具调用（PTC）与原生JSON工具调用。在PTC范式下，工具以带类型的Python函数存根（typed Python stubs）形式暴露给模型，模型通过编写代码来调用这些工具，执行与结果处理都在单个agent轮次内完成，而不需要像JSON调用那样在多轮之间来回传递结构化调用与结果。

📊 结果

PTC在多数模型、多种条件下打平或超越JSON调用

程序化工具调用在14个模型中的11个上匹配或超过原生JSON工具调用，其中 GPT-5.6 系列相较JSON基线提升达10.6%。在并行扇出（parallel fan-out）场景下，PTC 在14个模型中的13个上匹配或优于基线。在上下文腐化（context rot）条件下，PTC 表现稳定，而JSON基线平均下降2.3%。整体而言，PTC 的性能表现随模型能力的代际提升而同步增长，显示其是一种可靠且与模型能力共同演进的替代范式。

💡 我的看法

这篇论文的核心结论（"把工具调用变成写代码，比拼JSON格式更稳、更能扇出并行、更抗上下文腐化"）与你关注的agent架构和工具调用密切相关，但它同样值得放进duplex/全双工的语境里审视：论文强调PTC能让"执行与结果处理在单个agent轮次内完成"，这对于减少轮次间往返、降低端到端延迟是有利的——这正是全双工交互对工具调用范式的期待，即工具调用不应该打断或拖慢主对话流的响应节奏。不过论文的评测场景（BFCL v4）本质上仍是离线/批处理式的函数调用正确性评测，没有涉及流式生成、边说边调用、或工具结果需要实时插入到语音/文本输出流中的场景，因此"单轮完成执行"是否真的能转化为更低的感知延迟，仍需要在真正的实时交互基准上验证。另外，"上下文腐化下JSON掉2.3%而PTC保持稳定"这一发现，如果能进一步解释为什么代码形式对上下文噪声更鲁棒（是因为类型检查提前暴露错误，还是代码本身的结构化程度更高），会让这个结论更有说服力。

工具调用的苦涩教训The Bitter Lesson of Tool Calling

🎯 问题

🔬 方法

📊 结果

💡 我的看法

工具调用的苦涩教训
The Bitter Lesson of Tool Calling