程序化工具调用：Agent 一次请求跑完几百个工具，省的是什么

程序化工具调用Agent 一次请求跑完几百个工具省的是什么原文Factory Research - 《Droid 1.0: Building a Frontier Harness》https://factory.com/news/frontier-harness一、先说结论省的不是钱是请求次数我们平时写的 Agent 循环基本是这样一个节奏模型输出一个工具调用框架执行把结果塞回消息列表再请求一次模型。一个任务里有 10 个工具调用就是 10 次以上的模型请求。Factory 这次发布的 Droid 1.0 换了个做法叫程序化工具调用Programmatic Tool CallingPTC不逐个调用工具而是让模型先写一段 JavaScript把要怎么调用工具这件事写成代码然后一次执行完。原文的定义很短——PTC 是让 Agent 写一个程序去调用工具模型可以先把整个流程想清楚写出代码然后一次性端到端执行。这句话里最值得琢磨的是一次性。因为在逐个调用的模式下每一轮请求都要把系统提示、工具定义、历史记录、之前的工具结果重新发一遍。调用越碎重复发的东西越多。二、两个真实例子量级差别有多大原文给了两个企业内部场景的实测对比的是直接工具调用和Script 模式。场景直接调用Script 模式Linear 批量清理任务移动并验证 151 个 issue312 次工具调用约 36 次模型请求约 310 万输入 token2 次模型请求约 6.1 万 tokenCI 扫描547 个 run 里的 5384 个 desktop job550 次工具调用估计 59 到 187 次请求2 次请求每次 60 个并发第二个例子更值得注意550 次工具调用跑完进入模型上下文的结果不到 0.1%模型最后只看到五个数字的摘要其中包含 41 个 failed jobs。这就是 PTC 和传统工具调用的本质差别。传统模式下每一次工具结果都必须回灌到对话里因为那是模型判断下一步的依据。而 PTC 模式下原始文件、搜索结果、日志这些都留在程序内部当变量模型收到的只有程序打印出来的那部分输出。三个理由原文讲得很直白上下文干净。模型只拿到程序的输出不用吞掉几百条原始结果。请求次数少。一个程序跑多次调用固定成本只付一次。可靠性高。判断和循环在代码里确定性地执行不依赖模型每一步都判对。第三点容易被低估。如果你要遍历 500 个文件、挑出提到某个词的那几个这件事写成代码就是一个 filter写成 Agent 的多轮推理就是 500 次这个文件提到了吗的判断其中任何一次判错都会污染后面。三、Script 工具的设计细节比写代码调工具更重要如果只是让模型输出代码再执行那算不上什么新东西。原文里有几个设计选择才决定这套东西能不能用在生产环境。1. 程序拿到的必须是真数据原文的说法是程序拿到整个文件和结构化的、带类型的搜索结果过滤和计数在代码里完成不消耗 token。这一点决定了 Script 模式的成本优势。如果工具返回的是被格式化、被截断、被转义过的字符串那程序里就没法做正经的数据处理模型还是得把结果读回上下文。2. 字面文本走原始输入块文件内容、补丁、命令这些直接放在原始输入块里不走转义字符串。原文的理由是省 token也减少格式错误的调用。写过工具调用的人应该都踩过这个坑把一个 2000 行的文件塞进 JSON 字符串里既要转义引号和换行又容易把 JSON 本身的格式搞坏。原始输入块绕过了这个问题。3. 编辑结果返回短摘要程序内部做一次文件编辑返回的摘要和直接编辑一样短文件内容不会被重新粘回上下文。4. 长任务不让模型干等程序最多等 5 分钟超时就把当前已有的输出交回也可以后台启动、立即返回。配套的是三个专用工具查看、等待、停止。后台任务完成时harness 主动唤醒模型而不是让模型反复问好了吗。这个设计针对的是一个很现实的延迟问题。跑一次全量测试可能要几分钟如果模型必须同步等待这几分钟就完全浪费如果改成轮询又白烧请求。5. 启动时只加载两个工具原文提到工具定义从 11 个降到 2 个很少用的工具按需加载。整份启动 prompt 从 20887 token 降到 13055 token降幅 37%。其中工具定义从 15798 降到 8528。这个数字和 PTC 没有直接关系但它说明了同一件事的两面Agent 的每一轮请求都在为固定开销付钱固定开销越小同样的钱能买到的有效工作越多。四、一个单测修复的回放看清时间花在哪原文给了同一任务、同一模型GPT-6.1 Solhigh reasoning的两种跑法的逐轮计时。任务是修一个失败的单元测试。直接调用10 次模型调用 15 次工具调用总耗时 56.8 秒。Script 模式5 次模型调用 同样 15 次工具调用总耗时 41.6 秒提前 15.2 秒。拆开看就明白了。直接调用里每次模型调用之间通常只夹 1 到 2 个工具调用而工具本身执行很快读文件 14 毫秒、git status 218 毫秒真正的时间在模型调用上。Script 模式下第一轮那个 Script 用 421 毫秒一口气做完了 TodoWrite、读两个文件和 git status第二轮用 1.25 秒做完 TodoWrite 加打补丁于是模型调用从 10 次减到 5 次模型调用总耗时从 42.3 秒降到 28.0 秒。所以 PTC 的收益结构和工具快不快关系不大和工具调用的轮次多不多强相关。原文的另一个数字印证了这点Script 模式让 Droid 在 Claude Opus 5.5 上成本降低 15%而节省集中在其中 12.5% 的、工具调用达到 6 次以上的任务上。大多数 Script 都很小小到省不出多少东西。这条经验对做 Agent 产品的人很实用不要为了 PTC 而 PTC先看看你的任务里有没有多次短调用的模式。五、自己动手最小验证下面这段是最小验证脚本用来量化轮次削减能带来多少请求数和 token 的下降。它不依赖任何特定框架只统计请求数。# 自拟示意非官方实现用于验证请求数变化# 场景读 200 个文件找出包含关键词的文件名importglob,os FILESglob.glob(repo/**/*.ts,recursiveTrue)[:200]KEYdeprecated# 方案 A逐个工具调用 —— 每个文件一次 read_file每批一次模型请求defturn_by_turn(batch_size2):requests,tool_calls,tokens0,0,0foriinrange(0,len(FILES),batch_size):requests1# 每批结果回灌后模型要再请求一次batchFILES[i:ibatch_size]tool_callslen(batch)# 粗略估算每个文件内容都进上下文一个文件按 800 token 计tokenssum(800for_inbatch)3000# 3000 是每轮固定的指令与历史开销returnrequests,tool_calls,tokens# 方案 B程序化工具调用 —— 一个 Script 里循环读文件只返回命中的文件名defprogrammatic():requests1# 一次模型请求写出程序tool_callslen(FILES)tokens3000sum(len(os.path.basename(f))forfinFILES)//4returnrequests,tool_calls,tokensforname,fnin[(A 逐个调用,turn_by_turn),(B 程序化调用,programmatic)]:req,tcs,tokfn()print(f{name}: requests{req}, tool_calls{tcs}, est_tokens{tok:,})三个参数值得解释一下batch_size控制每次请求里塞几个工具调用。设成 2 是偏乐观的估计实际框架通常更保守。方案 A 的 token 估算里每个文件按 800 token 计入上下文这是关键项同一份文件内容在后续每轮请求里都会被重复发送真实开销比这个模型更高。方案 B 的 token 只算程序打印出来的文件名因为原始内容没有进上下文。跑完你会看到请求数从约 100 降到 1token 差一个数量级以上。数量级结论是可靠的具体数字取决于你的文件大小和系统提示长度应当自己按实际场景重算。需要把口径说清上面的比例来自我按原文描述写的估算脚本不是官方实测。原文给的两个企业场景数字312 次调用压到 2 次请求、550 次调用压到 2 次请求才是官方口径。六、收益的边界在哪原文的基准测试里Droid 1.0 在 Terminal-Bench 4 上用 GPT-6.1 Sol 时分数比 Codex 高 3.5 分、成本低 12%用 Claude Opus 5.5 时比几款对比 harness 高 3.0 到 7.6 分。全文总括的说法是最多高效 20%。这些数字的前提要说清楚每个任务跑 3 次 trial只统计两边都通过的任务成本按各家的列表价计算。PTC 不改变模型的推理能力它改变的是同样的推理要花多少次请求。所以 PTC 有明确的适用边界适合批量读、批量搜、批量改任务里各步骤之间依赖弱可以写成确定性的程序。不适合每一步都必须看结果再决定下一步的探索型任务写不出稳定的程序硬写反而更差。风险程序跑错了不会自己停下来纠正一次执行完可能已经改了 50 个文件。所以沙箱要限制住Droid 的 Script 沙箱自身没有文件、网络、系统访问打印输出有大小上限并且要有回滚。顺带提一个原文里的反向案例挺有意思给每个文件的每一行都加行号让模型不用再通过 shell 去查行号某一任务上把 Opus 的成本降了 22%但这让每次读取多出约两行 tokenGLM 的成本涨了 8%Kimi 涨了 32%。同一个优化在不同模型上方向可以相反。工具的 token 成本必须按模型算不能拍脑袋。七、想在自己的 Agent 里试按这个顺序先统计你现有任务里工具调用的分布。如果多数任务只有 1 到 3 次调用PTC 帮不了你。找出那些读几十个文件然后汇总的模式这是最容易改写的地方。把中间的原始数据挡在程序内只把摘要交给模型这一步是收益的主要来源。沙箱一定要先做没有文件、网络、系统访问权限的 JS 执行环境是底线。后台任务要配唤醒机制不要让模型轮询。原文提到 PTC 的思想源头是 CodeActWang 等2024那篇论文的结论是用代码行动在 17 个模型上都优于 JSON 和文本形式的工具调用。这次的变化在于把它做成了产品级的 harness 能力带沙箱、带超时、带后台任务管理。