自我修正的 Agent，钱该花在生成、批评还是改写？

把一次回答交给“生成—批评—改写”三段流水线看起来像是把同一个模型多调用两次。真正落到预算上却很容易变成另一种浪费三个位置都放同样大的模型或者为了省钱把最后的改写器换成最小模型。前者不知道钱花在了哪里后者则可能让一条本来可用的回答被错误修改。《Asymmetric Capacity Allocation in Self-Refinement Pipelines》把这个问题拆开测量。论文在规划、摘要、逻辑推理、代码优化和故事补全五类任务上分别只改变生成器、批评器或改写器的模型尺寸其余两段固定。它观察到一个不对称的结果生成器和改写器对尺寸更敏感批评器的尺寸曲线更平但保留一个小批评器仍通常好于完全不批评。它不支持“批评器越小越好”的口号而是提醒工程团队把预算问题改写成每一段到底在消耗什么能力系统又能验证什么先别选模型先把三段的失败写出来以一个代码 Agent 的任务卡为例用户要把一段批量导入脚本改成“遇到一行坏数据时跳过、记录原因、继续处理”。生成器先给出修改方案和补丁草稿批评器检查它是否吞掉了原始错误、是否把计数写在错误位置、是否误改了数据库事务改写器再结合意见输出最终补丁。三段的输出都叫文本但失败方式完全不同。生成器的失败是没有找到正确的入口或没有形成可执行方案。它需要理解现有代码、接口契约和任务限制。改写器的失败则更危险它拿到一份初稿和一段反馈却没有把反馈落实到正确的行、正确的条件与正确的测试。批评器的失败通常表现为漏报或给出不完整意见它可能少指出一个边界却不一定要替执行者写完补丁。论文的实验形式化了这个分工输入为 x生成器给出初稿 y0批评器根据 x 与 y0 生成反馈 f改写器根据三者生成最终结果 yr。作者在 Qwen3 与 Gemma 3 两个模型族中一次只改变其中一个位置的尺寸另外两个位置保持不变。这里每次只执行一轮“批评—改写”没有测量多轮自我修正。这样的对照不能直接给出你的生产最优配比却能避免一个常见误判把三段全都当成同一种“多想一点”。对工程团队来说第一步不该照抄论文里的参数量应当为上述导入任务写三张失败表。生成阶段要记录“是否找到真实入口、是否说明事务范围”批评阶段要记录“是否指出遗漏的失败分支、每条意见能否回指 diff”改写阶段要记录“补丁是否通过现有测试、是否新增了只覆盖坏数据的断言”。没有这三张表所谓模型路由只能优化 token 数不能优化最终风险。这也改变了提示词的写法。生成器不应被要求“给出最佳修复”而应被要求先列出它认为的入口、输入契约和不确定项批评器不应泛评代码质量而要回答“哪一条任务卡要求没有被满足”改写器则只接收已编号的意见并在输出中标出每条意见的处理结果。这样做的收益不在文案更整齐而在于后续可以计算一条失败究竟是初稿遗漏、批评漏检还是改写没有落实。如果没有真实仓库也可以先做一个受控夹具。给批量导入脚本准备四类行正常行、缺失字段、格式错误行和会触发事务回滚的行再固定每轮的上下文、测试命令和判定规则。夹具不是生产证明但能把“模型看起来更聪明”转换成可比较的结果。等夹具稳定后再把同一张记录表带到真实 PR 中避免把练习里的收益直接写成线上收益。为什么更大的批评器未必带来等量收益论文报告在它测量的五类基准上批评器尺寸的敏感性低于生成器和改写器。以 Qwen3-32B 配置下的表格为例代码优化 PIE 的性能范围 Δ在生成器、批评器、改写器扫描中分别为 28、4、50 个百分点。Δ 是一次扫描中最高分减最低分这里的分数采用 %OPT即功能正确且成功优化的程序比例并非速度提升百分比不同任务和模型族数值不同但批评器曲线整体更平。作者还抽样比较了小批评器与大批评器更大的批评器常能多发现问题但这些额外信息未必会被改写器有效利用。这解释了一个很实际的现象。批评器只要能把“这里可能吞错”“这条断言没有走真实入口”说清楚就已经给改写器提供了高价值的约束。把批评器从小模型升级到最大模型可能让意见更全面却不自动让最终补丁更正确如果改写器看不懂、没有上下文、或者没有测试去筛选反馈它只会得到更长的自然语言。但“曲线平”不是免费通行证。论文同时给出一个重要的对照保留最小 Qwen3-0.6B 批评器通常优于移除批评环节的无批评基线。对导入脚本而言一个足够小但能稳定列出事务、计数和日志风险的批评器可能比直接让改写器凭感觉重写更有用。这里的“小”是相对于该论文的模型族、提示与任务而言不是任何模型都能被任意缩小。因此批评器的预算不应只按参数量决定而要看它能否生成可消费的意见。一个合格的批评输出至少包括问题位置或证据、违反的契约、风险级别、建议的验证方式。若它只说“注意边界条件”“建议加强错误处理”再大的模型也只是把模糊话写得更长。反过来若小模型能把意见绑定到 diff 和测试名它就可以承担廉价的筛查层。缩小改写器可能增加返工论文对改写器的结果更值得谨慎对待。作者观察到改写器尺寸对端到端表现高度敏感过小的改写器甚至可能让结果低于最初生成。回到批量导入脚本它不仅要读懂“跳过坏数据”的批评意见还要把计数、日志和事务位置落在真实分支上。改写并非复制批评意见它还要保持原任务、理解初稿、过滤错误反馈、把正确的改变落到输出格式里。它处在“信息最多、后果最集中”的位置。把这个结论移到代码 Agent 时不能写成“最后一步必须用最大模型”。真实系统还受上下文长度、代码检索质量、工具调用、测试成本和失败回滚影响。更稳妥的工程判断是如果最终步骤拥有写文件、提交或调用外部工具的权限就不要仅因为它被命名为 refine 而把它当成低风险的格式化步骤。它至少要有足够能力处理批评反馈并且被测试、diff 与权限边界约束。一个可操作的预算顺序是先保证生成器能提出覆盖关键约束的初稿再保证改写器能正确落实经验证的反馈最后在批评器上寻找成本拐点。若预算不足先缩减批评器的上下文或让它只检查明确的风险清单而不是直接换掉改写器。若改写后的失败率升高也不要立刻把批评器换大先看失败是“批评没有发现”还是“改写没有执行批评”。这两个根因对应不同的预算动作。用一个小矩阵决定下一次路由下面的矩阵不是论文实验的复现而是把它的阶段敏感性变成一次可记录的工程实验。拿同一批量导入脚本的坏数据样本来跑每格都需要真实任务、真实命令和真实结果不能只让另一个模型给分。观察到的现象更可能的瓶颈下一次只改什么必须保留的证据初稿经常漏掉接口或约束生成器理解不足增强生成器或补齐检索输入任务卡、入口文件、初稿 diff批评能指出问题但最终补丁仍错改写器落实不足保持批评增强改写器或缩小写入范围批评项到 diff 的对应、测试输出批评意见泛泛测试也抓不到缺口批评提示或验证设计不足先加结构化检查项不急于换大模型失败样本、契约、断言名称加大批评器后意见更多但通过率不变反馈未被消费改写器只接收可验证意见被采纳与被拒绝意见记录改写后 diff 变大且无关改动增加写入范围失控收紧改写器的文件与操作权限文件清单、diff、拒绝操作记录三段都变大但延迟翻倍、失败率不变任务或验证不是容量瓶颈固定模型检查检索和测试入口延迟分位数、缺失上下文、测试覆盖用同一批任务做一次最小扫描即可固定生成器和改写器先用小批评器记录通过率、平均延迟、每条可回指意见数和改写后新增失败数再只替换批评器。随后反过来固定批评器扫描改写器。这里的关键是“一次只改一段”这正是论文的控制思路。没有控制变量看到成本和质量一起变化时团队无法知道应该归因于模型、提示、检索还是任务分布。实验记录还应写下停止规则。例如某个模型组合在十个固定样本里连续两次引入无关文件修改就停止扩大它的写入权限某个批评器连续三轮只能给出无法回指的建议就先调整检查表不继续增加它的上下文。容量扫描不是排行榜它的目的不是找一个全局最高分而是找出在当前任务、当前检索和当前验收下最先失效的环节。成本也不只是一笔推理费用。生成器变大可能提高首次命中率减少后续工具调用改写器变大可能减少人工回退批评器变大则可能增加延迟和更长的意见阅读成本。记录每段的输入 token、输出 token、工具次数、测试时长与人工复核分钟数才有可能比较总成本。若只看模型单价团队往往会把最便宜的一段优化成最昂贵的返工来源。不要把论文的平均趋势当成生产保证这项研究有明确范围。它使用五种基准、两类开放权重模型族和特定的少样本提示指标也随任务不同而不同例如规划看可行性、代码优化看功能正确且成功优化的比例。实验还固定了解码设置使用贪心解码温度为 0最多生成 700 个新 token各尺寸和阶段保持一致附录 A。复现时应先对照附录 B 的子集与难度范围、附录 G 的完整提示模板再看附录 C—E 的模型族和固定容量配置不能只拿模型名称对齐。它没有测量带真实权限的代码代理、私有仓库检索、长时间工具调用、线上延迟尾部或人工审阅成本。论文的“批评器不敏感”不能替代你对安全审查、合规检查或领域知识的评估。尤其是在高风险变更中批评器不是一个可以随意降级的装饰层。数据库迁移、支付、权限策略和生产配置需要可执行验证、人工批准与回滚而不是依赖任意模型生成一段“看起来合理”的批评。若批评阶段掌握独特领域规则较小的通用模型可能完全不够此时应优先接入确定性检查、专用规则或人工复核而不是只比较参数量。早期 Self-Refine 研究的是单一 LLM 反复生成反馈并改写它与本篇主论文的单轮容量扫描是不同的实验设定。不能把单轮尺寸敏感性当作多轮收益已经得到验证也不能预设每增加一轮都能改善生产任务。这里还需要检验一个工程风险假设如果错误反馈没有经过验证就反复进入后续上下文改写器可能沿着错误前提继续修改。两篇论文的上述证据并未验证这一生产场景中的风险或发生频率应在自己的任务中记录并检查不能把它当作已有实验结论。对导入脚本这类任务正确的停止条件应该是测试覆盖了任务卡里的正常与失败输入批评意见已被逐条采纳或拒绝并且 diff 没有扩大到无关文件不是“模型还可以再想一轮”。还有一个容易遗漏的边界是任务分布变化。论文里的容量趋势来自固定基准和统一的阶段定义真实团队的“批评器”可能同时在做代码审查、运行日志归因和安全策略解释这些职责未必共享同一条曲线。不要先把组织里的角色名称映射到论文的三个标签再反向挑模型。应该先从失败工单中抽样确认每个阶段实际接到的输入、允许调用的工具和最终验收指标再决定是否值得做同类扫描。当测量样本很少时结论也应保持条件化。比如六个 PR 都显示小批评器足够只能说明它们覆盖的规则与上下文下没有观察到升级收益它不能证明更难的重构、跨服务变更或陌生领域也一样。把未覆盖任务单独列出来比用一个平均分把它们混进去更诚实也更有利于下一轮补样本。结语把容量给承担结果的人这篇论文最有价值的地方不是给出一个固定的 32B—0.6B—32B 配方而是要求我们把自我修正拆成不同的责任谁提出方案谁定位问题谁把修改落到可验证结果。生成和改写的容量往往更直接决定终局质量小批评器仍可能以较低成本提供重要约束而大批评器的收益取决于系统能否把它的意见真正用起来。下一次设计 Agent 流水线时不妨先拿一类真实任务跑上述小矩阵。把每段的输入、权限、模型、成本、失败样本和测试结果留档再决定哪里该升级、哪里该压缩。这样得到的是适合自己任务分布的路由策略而不是从一张论文图表里抄来的均匀配比。资料来源Yang 等Asymmetric Capacity Allocation in Self-Refinement Pipelines第 3—5 节、表 1、Limitations、附录 A—G。Madaan 等Self-Refine: Iterative Refinement with Self-Feedback摘要。