在 SWE-Review 的实验中智能体代码审查占完整“生成—审查—修订”流程 Token 消耗的 36%—66%。这个比例并不能代表所有 Coding Agent。它来自 SWE-bench Verified、特定模型和特定审查流程。但它足以提醒我们让智能体写完代码后再找一个智能体检查并不是一个轻量附加步骤。评价器需要重新理解 issue、代码库和当前补丁这部分成本可能接近代码生成本身。评价又确实可能带来明显收益。同一项研究中带有具体诊断的审查—修订流程将任务解决率从 22.9% 提高到 38.4%只让评价器判断通过或拒绝、被拒后重新生成补丁解决率为 32.3%。前一种方案平均使用 2.44 次生成或修订后一种需要 8.86 次其单位 Token 带来的解决率增益相差约 6.5 倍。评价很贵却有时比少评价更节省计算。这个看似矛盾的结果提出了一个比“要不要加评价器”更重要的问题Coding Harness 中增加的模型调用究竟怎样转化为任务效果评价只是其中较容易看见的一笔开销。为了理解代码智能体会继续搜索和读取文件为了修复失败它会增加执行轮次为了扩大搜索范围系统还可能创建子智能体。这些机制都有机会提高任务成功率也都可能让计算消耗迅速增加。高性价比的 Harness 需要判断额外计算具体解决了什么问题以及它是否真的推动任务继续完成。一、评价为什么贵它需要重新理解任务和代码代码审查无法只看模型最后给出的“已完成”。评价器至少需要理解原始 issue、代码差异、相关调用关系和测试结果。修改越复杂评价器需要查找的相关代码可能越多。代码检索方式因此会直接影响审查成本。GitHub 最近在 Copilot Code Review 上遇到了一个很典型的问题。grepglobview运行轨迹显示审查智能体开始按照通用编码助手的方式浏览代码库。它扩大搜索范围、读取更多文件又根据新读到的内容继续搜索。上下文不断增长查找过程却没有持续接近当前 PR 中真正需要判断的问题。GitHub 随后重新设计了工具说明让审查过程从 PR diff 出发先围绕某项修改提出具体问题再搜索能够证实或排除该问题的代码。调整后平均审查成本下降约 20%审查质量保持在原有水平。GitHub 对这次改进的判断是问题出在工具周围的工作流程而非工具能力本身。这个案例说明在代码审查中评价器如何寻找相关代码是决定成本和有效发现数量的重要因素。审查所需的上下文需要足以判断当前修改带来的风险。检索范围可以随着具体问题展开缺少判断目标的广泛浏览则很容易产生大量低价值上下文。这项问题也不只存在于评价器。代码生成智能体同样需要读取 issue、diff、文件内容和工具定义。Harness 如果把大量稳定、重复的数据获取也放进模型循环就会让模型为本可直接完成的操作持续支付推理成本。GitHub 在优化 Agentic Workflows 时发现一个包含 40 个工具的 GitHub MCP Server每轮可能附带 10—15 KB 的工具定义某些工作流实际上只使用其中两个工具。删除无用工具后其测试工作流每次调用的上下文减少了 8—12 KB每次运行节省数千 Token行为没有发生变化。gh pr diff这里可以得到一个相对明确的建设原则模型处理需要判断的部分程序处理稳定、确定和重复的数据获取。强工具和长上下文本身没有问题。需要警惕的是Harness 是否让模型反复处理了不需要模型判断的内容。二、评价的收益让下一轮能够定向修订控制代码检索范围可以降低评价本身的成本。但评价是否划算最终还要看它给后续执行带来了什么。SWE-Review 比较了三种增加测试时计算的方法。第一种是生成多个独立补丁再由验证器打分选优。第二种是让审查智能体判断补丁是否通过如果未通过生成智能体放弃当前结果从头再试。第三种则由审查智能体给出结构化诊断生成智能体保留现有补丁根据诊断继续修改。第三种方式取得了更高的解决率也使用了更少的平均尝试次数和 Token。差异来自后续计算怎样利用前一轮结果。只给出“通过”或“拒绝”能够阻止错误补丁进入下一步却没有告诉生成智能体哪里出了问题。被拒后从头生成意味着系统需要重新理解任务、搜索代码并构造新的补丁前一轮已经完成的有效工作也可能被放弃。结构化诊断则会缩小下一轮的处理范围。它可以指出哪项行为没有满足 issue问题出现在哪段代码或调用关系中哪个边界条件没有被覆盖当前补丁还需要修改或验证什么。此时新增计算集中在已经定位的问题上前一轮的有效修改能够得到保留。SWE-Review 的结果因此支持一个比“评价能够提高成功率”更具体的判断评价的收益主要来自它能否将后续执行从重新尝试转成有依据的修订。评价器多给出一次“对不对”的判断价值有限。它需要形成足够具体的诊断让后续智能体知道应该保留什么、修改什么、继续验证什么。当然这项结论仍有适用范围。SWE-Review 主要研究基于 issue 的代码修复评价指标集中在补丁能否解决目标问题。架构调整、大规模重构、性能优化和安全审查是否具有相同的收益曲线还需要进一步验证。但它提供了一种很有用的评测方式评价器除了看判断准确率还要看其反馈能否改善后续补丁以及取得这项改善用了多少 Token。三、更多轮次未必能补上 Harness 缺失的能力审查给出具体诊断后继续修订通常比从头生成更有效。但任务持续失败时系统还要判断当前问题是否仍然能够通过修改代码解决。GitHub Agentic Workflows 曾出现过一个 64 轮的异常轨迹。/tmp/这里的问题不在补丁也不在模型是否进行了充分反思。Harness 没有提供可用的执行环境增加重试、评价器或更强模型都无法直接解决。因此持续失败后需要先判断失败发生在哪一层新的测试或审查结果已经指出代码缺陷可以继续修订当前缺少相关代码或依赖信息需要调整检索范围工具、权限或环境无法正常工作需要先修复 Harness系统无法继续缩小问题范围需要停止或转交人工。这类判断不能只依赖固定轮数。最大轮数可以限制损失却不能解释为什么某项任务值得继续。更有价值的信号存在于运行轨迹中智能体是否获得了新的错误信息测试结果是否发生变化补丁是否针对已发现的问题作出修改还是系统仍在重复读取相同内容、调用相同工具和尝试相近方案。四、多一个智能体有时提高效率有时只会扩大开销创建子智能体是另一种常见的计算扩展方式。Anthropic 在多智能体研究系统中发现多智能体适合需要同时探索多个独立方向的广度研究任务。其内部评测中Token 使用量能够解释 BrowseComp 性能差异的 80%与此同时普通智能体的 Token 使用量约为普通对话的 4 倍多智能体系统约为普通对话的 15 倍。Anthropic 明确指出多智能体需要应用在任务价值足以覆盖额外成本的场景。Anthropic 还专门提醒大多数编码任务能够并行处理的部分少于研究任务。多个智能体如果需要共享相同代码状态、相互等待或频繁协调当前模型并不擅长稳定地完成实时委派。这意味着为 Coding Harness 增加 reviewer 或其他子智能体不能只理解成“多加一道保险”。每个智能体都会建立自己的上下文调用模型和工具并产生结果传递与协调开销。但子智能体也不必然增加完整任务成本。微软研究院的 SWE-Edit 将代码查看和代码修改拆给两个专门子智能体Viewer 使用较小模型从完整文件中提取与任务相关的代码Editor 根据高层计划执行修改主智能体集中处理推理和规划。在 SWE-bench Verified 上这种结构将解决率提高了 2.1 个百分点同时把推理成本降低了 17.9%。其中单独加入 Viewer 就降低了 7.7% 的成本。论文将原因归结为两点Viewer 使用较小模型处理完整文件并只把相关代码片段返回主智能体从而减少主上下文中的无关内容。SWE-Edit 与 reviewer agent 解决的并非同一个问题。前者拆分的是代码查看与编辑后者拆分的是生成与验证。但它说明了一项共同原则子智能体是否划算取决于职责拆分能否减少主执行链路的负担而不取决于智能体数量本身。任务边界清楚、子智能体可以使用更便宜的模型、返回结果能够被压缩时新增调用可能降低完整任务成本。多个智能体需要重复读取相同代码、持续同步状态时协调成本更可能抵消收益。五、怎样判断一项 Harness 机制值不值得保留评价、代码检索、重试和子智能体看起来是不同问题实际都在用额外计算换取任务效果。判断一项机制是否划算可以先问三个问题。当前任务卡在哪里是缺少相关代码和依赖信息补丁存在具体错误执行环境不可用还是现有自动验证无法覆盖关键风险问题判断错误额外计算很容易投向无关环节。工具不能运行时继续反思代码没有意义需求理解存在偏差时重复运行相同测试也很难给出答案。新增计算具体改变了什么它是否补充了此前缺少的相关代码形成了能够指导修改的诊断打开了不同的解决路径或者减少了主智能体需要处理的内容“增加了一轮评价”“创建了一个子智能体”只是系统动作不能直接说明收益。什么时候应该停止新的搜索是否仍返回与当前问题有关的信息测试和错误结果是否发生变化审查意见是否被后续修改采用多个智能体是否在处理彼此独立的工作如果连续投入没有改变这些状态系统需要调整工具、重新建立上下文、切换处理方式或者结束当前自动执行。这三个问题不需要成为一套复杂的方法论。团队可以直接用它们复盘自己的高成本轨迹模型反复读取了哪些内容哪些轮次真正改变了补丁评价器指出的问题有多少进入了后续修订子智能体是否完成了彼此不同的任务最终失败来自代码还是 Harness 的工具和环境这些答案通常不会出现在模型 benchmark 或价格表中只能从自己的执行轨迹里获得。从评价成本重新理解 Coding HarnessSWE-Review 提醒我们一次完整的智能体审查可能占据任务中相当大的一部分 Token。它同时证明能够指导修订的评价也可能比反复生成新补丁更有效率。GitHub 的实践进一步说明评价成本并不只由模型价格决定。代码检索方式、工具数量、确定性数据是否进入模型循环以及运行环境是否正常都会改变整条任务轨迹。Anthropic 与 SWE-Edit 则从两个方向展示了子智能体的成本问题增加智能体可以扩大计算和协调开销合理的职责隔离也可能减少主模型负担并降低总成本。这些案例共同指向一个判断Coding Harness 的性价比取决于每一份额外计算是否改变了任务的后续进展。它可以让系统获得当前判断需要的信息让下一轮围绕具体问题修订也可以帮助系统及时发现当前路径已经失效。对团队来说成本优化的第一步未必是立刻切换便宜模型。更值得先做的是打开一批高成本任务的运行轨迹看清模型把 Token 花在了哪里以及其中哪些调用真正改变了任务结果。Harness 中的规划、评价、重试和子智能体都可以提高性能。它们也都应该能够回答同一个问题增加的这部分计算具体让任务发生了什么变化参考资料1. Ruoyu Wang 等《SWE-Review: Closing the Loop on Issue Resolution with Agentic Code Review》 https://arxiv.org/abs/2607.06065 2. GitHub《Better tools made Copilot code review worse. Here’s how we actually improved it.》 https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/ 3. GitHub《Improving token efficiency in GitHub Agentic Workflows》 https://github.blog/ai-and-ml/github-copilot/improving-token-efficiency-in-github-agentic-workflows/ 4. GitHub《Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks》 https://github.blog/ai-and-ml/github-copilot/evaluating-performance-and-efficiency-of-the-github-copilot-agentic-harness-across-models-and-tasks/ 5. Anthropic《How we built our multi-agent research system》 https://www.anthropic.com/engineering/multi-agent-research-system 6. Yikai Zhang 等《SWE-Edit: Rethinking Code Editing for Efficient SWE-Agent》 https://arxiv.org/abs/2604.26102 7. Microsoft Research《SWE-Edit: Rethinking Code Editing for Efficient SWE-Agent》 https://www.microsoft.com/en-us/research/publication/swe-edit-rethinking-code-editing-for-efficient-swe-agent/