Pydantic工程师Michael Pfaffenberger：代码模式在长任务上砍半成本，5条记录时反而更贵

AI Agent开发者中流行一种说法：与其让模型逐个调用工具，不如让它写一段程序把工具调用包在循环里，这样一切都会更便宜、更快、更准确。Pydantic工程师Michael Pfaffenberger相信这个方向，但他注意到几乎所有支持这一论点的数字都来自拥有数百个工具或巨大载荷的复杂Agent场景。现实中的许多Agent其实很朴素：几个增删改查工具，一个具体任务。于是他设计了一个刻意简单的基准测试来验证这个论点到底在什么条件下成立。

测试覆盖五个小型Pydantic AI应用——购物车、日历、聊天室、看板板和库存系统——每个只有单条记录的CRUD工具，分页列表，没有shell、文件系统或批量接口。三种工作负载：50个日常短任务（平均13次工具调用）、12个长程多步任务（60到500条记录，平均68次调用）、以及一个可以从5条缩放到200条记录的重复规则任务。8个模型，代码模式开和关各跑一遍，共5276次评分运行，由确定性预言机判定对错，不用LLM当裁判。

结果的核心发现是：任务越长，代码模式的优势越大。在长程任务上，8个模型平均成本降低58%，耗时降低51%，成功率提高16个百分点。在200条记录的规模上，代码模式比标准工具调用便宜47%到75%。但在5条记录时，代码模式在五个任务中的三个上反而贵了21%到38%。交叉点大约在20到50条记录之间。

Pfaffenberger对机制的解释推翻了一个常见假设。通常的说法是：每次工具调用都多一轮模型请求，代码模式通过减少轮次来省钱。但测试发现现代模型已经在大量并行调用——在200条记录的规模上，claude-haiku-5-5把全部200次调用塞进了一个响应。代码模式开启后，模型请求数平均只下降了1%到22%，远没有宣传的那么戏剧性。真正被削减的是每次请求中累积的内容：模型写出的调用指令和读回的工具结果。在标准工具调用中，205次调用的结果全部进入上下文，gpt-6.1-sol最终读了183723个输入token；在代码模式中，模型只写了5段程序，读了34461个token。输出token下降66%，输入token下降53%。

代码模式的成本结构因此很清晰：它收取一笔固定费用——每次请求附带约2600字符的沙箱使用指南——然后按任务规模获得递减的边际成本。标准工具调用没有固定费用，但每条记录都让模型多写一次调用、多读一次结果。在单次编辑上固定费用占优；在几百条记录上逐条费用占优。Pfaffenberger写道：模型更擅长写循环，而不是充当循环本身，而且这个差距随任务长度增长。

正确性的变化同样值得关注。没有代码模式时，成功率从5条记录的92%到100%滑落到200条记录的62%到79%；有代码模式时，200条记录仍保持92%到100%。最弱的模型gpt-6-luna在200条记录上，没有代码模式时15次运行全部失败，7次根本没做任何修改，只是解释了为什么做不到；有代码模式时它对了8次。这不是崩溃或超时，而是模型面对200次调用时选择了放弃。在长程任务中，16/24次无代码模式运行失败，有代码模式时只有1/24失败。

但Pfaffenberger也诚实地列出了代码模式付出代价的地方。小模型写的代码有bug，每次失败就多一轮往返；有些模型会把数据打印回对话，抵消了token节省；一个中途失败的代码片段重跑时可能重复写入，gpt-6-luna在长程任务中三次因此创建了重复记录。在调试方面，失败的程序把中间值藏在沙箱里，开发者需要读代码而不是读JSON。

这套测试运行在Pydantic自己的Monty沙箱中——一个用Rust编写的Python解释器，默认无宿主文件访问、无网络、30秒执行时限、256MiB堆内存上限。Pfaffenberger强调沙箱设计与模型能力同等重要：生成的代码只能触达你交给它的工具，工具本身仍需要自己的验证和授权。

作为第一方厂商基准测试，这些数据尚未经过独立复现。测试环境是内存中的应用状态，不涉及真实网络延迟、并发负载或生产级故障恢复。但Pfaffenberger对机制的解释——代码模式削减的不是请求轮次而是每次请求中累积的上下文——是一个可以独立检验的结构性论点，对所有考虑在Agent中引入代码执行能力的开发者有实际参考价值。