循环拆成零件之后：同一个模型，成功率差了九倍 (2026)

9 月 17 日同一天，两篇预印本送上了预印本平台，问的是同一个问题的两半：一条 Agent 循环里，到底哪几个零件在产出结果。1 2

第一篇把执行骨架钉死，只动规划、动作接口和上下文管理三块，用 176 组配置量每一块在什么条件下值钱；第二篇给规划信息和提交前的验证各做了一次干净对照，并把「错误放行」的代价写进了价值的算式。

本期听什么

为什么过去只能说「这条循环不错」：两个完整循环之间的差距里混着规划、工具、上下文和模型适配，没有办法归因。1
上下文管理的钱几乎都花在防溢出上——同一个模型、同一个 3.2 万 token 的窗口，不做管理是 6.4%，只用摘要能到 58.4%，差出九倍。1
规划对能力弱的模型是提成绩，对能力强的模型是省钱；动作接口该给预定义工具还是只给一个 shell，取决于模型有多熟 shell。1
一个只读不改的终端验证器挡掉了 61% 的错误完成，也误扣了 17% 本来正确的，但把错误放行率从 57.21% 压到 20.96%。2
这些结论的边界：编码与客服两类场景、特定模型群，零件组合起来的账还得自己量。

同一个模型，差出九倍

第一篇的实验材料是这样的：一个从零写的轻量编码循环，执行骨架固定为「想一步、动一步、看结果」；模型用了四个，Nemotron-3 的 300 亿、1200 亿、5500 亿参数三档，再加一个跨家族的 Mistral-Medium-3.5-128B；任务集是 SWE-Bench Verified 的 500 道真实 GitHub issue，和 Terminal-Bench 2.1 的 89 个命令行任务。上下文管理五种策略，配 3.2 万到 12.8 万 token 四个窗口，再加上规划和动作接口的消融，一共 176 组配置，每组都做配对比较。1

上下文管理的收益几乎全部来自一件事：别让循环撞上窗口。预算紧的时候，没有管理的循环会在撑爆窗口那一步直接终止，连改代码、跑验证的机会都没有。在 SWE-Bench Verified 上，5500 亿参数那个模型、3.2 万 token 的窗口，不做管理是 6.4%，只做规则裁剪是 51.4%，只用摘要能到 58.4%。窗口放宽到 12.8 万 token，这个优势就小得多，因为空间够它自己撑。1

效率最高的上下文策略是「先裁剪、后摘要」：先用便宜的办法把过时的工具输出压成占位符，还超预算，再让模型把最老的那段总结掉。至于那个让被裁掉的内容还能取回来的回取工具，模型几乎不调用；这套机械加上去，准确率一点没涨。1

规划从能力脚手架变成省钱工具

关掉规划，300 亿参数那个模型在 12.8 万 token 下的成功率从 25.2% 掉到 13.6%，每任务成本也从 0.09 美元降到 0.02 美元：它在花钱买成绩。换到 5500 亿参数那个，关掉规划成功率没掉，成本反而从 2.33 美元涨到 3.31 美元，那份计划在做的事变成了省掉重复的检查。1

动作接口是同一个逻辑。不熟 shell 的模型需要预定义工具兜底：读文件、改文件、grep、列目录。熟 shell 的模型只给一个 bash 就够：5500 亿参数那个换成纯 bash，成功率从 65.8% 升到 69.4%，每任务成本从 2.33 美元降到 1.11 美元；同样是纯 bash，换到 Mistral 身上，成功率从 68.6% 掉到 45.4%。同一个改动，在两个模型上一个赚一个亏。1

「错误放行」的代价决定验证器值不值

第二篇先给规划做了一次更干净的对照：同一个任务、同一个模型，一边给预先写好的任务计划，一边给同样字数、但被打乱的策略文本当安慰剂。数据来自 Retail 和 Airline 两个有状态工具环境，主力是 Retail 的 1547 条轨迹、16 个任务、6 个模型，另有 1227 条轨迹的规划专项和 233 条轨迹的航空试点。265 个配对单元下来，真计划把经过判定的成功率抬高 7.17 个百分点（90% 区间 1.15 到 13.36），提升集中在更复杂的任务上。2

第二条更值得记住。他们放了一个只看对话、只读不改的终端验证器，在提交完成结果之前把关：它挡掉了 137 条错误完成里的 83 条（61%），也误扣了 92 条本来正确的里的 16 条（17%），净效果是错误放行率从 57.21% 降到 20.96%。更省钱的结论在后面：单独放一个验证器，就能拿到「规划加验证」完整堆栈里几乎所有的防错放行收益，48.4 个百分点对 49.8 个百分点，增量成本只有十二分之一。2

所以规划和验证器不是二选一，取决于你给「错误放行」标了多高的代价：代价低的时候，规划带来的成功率提升占主导；代价高的时候，验证器避免的误放行占主导。论文把它写成一条可以套的式子：一项配置的净价值，等于成功率提升乘以成功的价值，加上少掉的误放行乘以误放行的损失，再减掉多花的钱。同一套循环改动，放在客服工单系统里和放在支付系统里，值不值钱是两个答案。2

落到自己循环上的四条

先量预算，再决定往哪投。 窗口宽裕的时候，上下文管理做得再花哨，收益也有限；窗口紧的时候，它就是那条保命线。
上下文策略按「先便宜后贵」排。 规则裁剪在前，模型摘要在后；顺手加的取回机制如果模型不用，就砍掉，它只会增加维护成本。
规划和动作接口按模型定。 能力弱的模型给计划和预定义工具，能力强的模型可以只留一个 shell，把省下来的钱花在验证上。
把「错误放行」的代价写进选型表。 没有这个数字，规划和验证的账算不出来，也没法向业务解释为什么要多花那一笔。

同一周还有第三条线：一篇 9 月 14 日提交的预印本把 harness 拆成五个可以各自演化的模块，用 2000 个和评测集不重叠的任务分别演化它们，最后再合回一条循环。3

这些数字的边界

两篇都在固定好的循环里只动一个零件，结论因此是条件性的。第一篇的两个基准都是编码任务，四个模型里三个同源；它量的规划是「预先写好的计划」这个脚手架，不是规划这种能力本身。第二篇主要在零售客服场景，验证器是一种具体实现，误扣 17% 这个代价换到别的场景会变；论文自己也把语义规划错误和读侧异常放在测量范围之外。1 2

真实系统里零件是互相咬合的：上下文预算会改变规划的价值，动作接口又会改变上下文里留下什么。组合起来的账，只能拿你自己的任务集去量。

本期基于两篇 2026 年 9 月 17 日提交的预印本（2609.20804 与 2609.20474），以及 9 月 14 日提交的 2609.14857；覆盖窗口是 9 月 18 日到 9 月 21 日，因为预印本平台周末不更新。需要说清的边界：三份材料都是作者自己的实验与口径，第一篇的结论限于其轻量编码循环与两个编码基准，第二篇的验证器与代价框架限于 Retail、Airline 两个环境；其中的成本数字按论文使用的 API 价格折算，换成你自己的部署价会不同。

循环拆成零件之后：同一个模型，成功率差了九倍