别再只看SWE-bench分数：Agentic软件工程需要怎样的新评测体系

摘要

Coding Agent 已经从“一次生成代码”走向持续读取仓库、调用工具、运行测试、接收反馈并迭代修改的复合系统。但行业仍习惯用一个端到端通过率给模型排位。2026 年 6 月的论文《Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering》指出：这类分数同时混入模型、Agent Harness、系统编排、上下文、运行环境和验证器的影响，既无法准确归因，也难以指导工程迭代。本文拆解论文提出的三类错位，并给出研发团队可落地的分层评测方案。

背景：被评测的对象已经变了

HumanEval、MBPP 等早期基准主要回答一个问题：模型能否根据描述一次生成可运行代码。SWE-bench 将任务推进到真实 GitHub Issue 和仓库级修改，但排行榜仍通常把一次运行的最终结果压缩为“解决率”。

真实 Coding Agent 并不是单独的模型。论文把它拆成两个层次：

• Agent Harness：模型、系统提示词、上下文选择、工具集合和单任务循环。
• System Harness：把高层目标拆成任务，调度一个或多个 Agent，管理仓库与运行环境，并把测试、代码审查和生产反馈送回系统。

系统还包含任务、环境、上下文和反馈信号。任一部分的变化都可能改变最终分数。因此，“模型 M 在某基准上达到 65%”并不等于模型本身拥有 65% 的修复能力，它只说明某个具体组合在某套协议下取得了该结果。

技术要点一：端到端分数混淆模型与 Harness

论文引用 TerminalBench 的结果说明，同一个 Claude Opus 4.6 在不同 Agent Harness 下，成功率差异可达到 20 个百分点以上，幅度足以覆盖相邻模型代际之间的差距。

原因并不神秘。上下文是否包含正确文件、工具是否能高效检索、Shell 输出是否被截断、测试失败能否进入下一轮、超时和 Token 预算如何设置，都会直接影响结果。排行榜如果只显示模型名和一个分数，读者很容易把系统工程收益误判成模型能力收益。

这对研发决策的影响很实际：团队可能花成本升级模型，却忽略更便宜、更稳定的改进，例如优化仓库索引、减少无关上下文、增加类型检查，或让失败测试以结构化形式返回 Agent。

技术要点二：单一参考解不等于行为正确性

软件任务通常存在多个正确实现。两个补丁可能采用不同抽象、修改不同文件，只要满足接口、兼容性和性能要求，都可能被维护者接受。若评测过度依赖与参考补丁的结构相似度，就会惩罚合法替代方案。

反过来，“测试通过”也不必然代表可以合并。测试可能覆盖不足，补丁可能破坏未被断言的行为，或引入安全、性能和维护性问题。评测真正应该描述的是独立行为规范：哪些输入输出必须成立、哪些公开 API 不得改变、资源和延迟预算是多少、哪些回归不能出现，而不是规定 Agent 必须复制作者当时的实现路径。

因此，参考解应主要用于构造和校验任务，而不是成为唯一正确答案。更可靠的验证器应组合隐藏测试、属性测试、变异测试、静态分析和人工审查抽样。

技术要点三：一个总分无法告诉团队该修哪里

端到端结果只能报告成功或失败，却不能区分失败来自哪里：

• 任务拆解错误，Agent 从一开始就在解决错误问题；
• 检索失败，关键模块没有进入上下文；
• 模型推理或代码生成错误；
• 工具调用失败、环境不一致或依赖安装异常；
• 验证器过弱，让错误补丁通过；
• 验证器过强，把等价实现判为失败；
• 多 Agent 交接丢失约束或重复工作。

缺少组件级信号时，团队只能依赖直觉做消融实验。论文主张把系统组件也变成可评测对象：固定其他变量，分别测试上下文构建、工具使用、任务委派、验证质量和反馈利用能力；最后再测完整组合。

研发视角：把排行榜问题改造成可诊断的测量系统

对于企业内部 Agent，最有价值的不是得到一个更漂亮的公开分数，而是建立“失败可定位、改动可归因、收益可复现”的评测闭环。

第一层是任务级结果：补丁是否满足行为规范，是否通过回归测试，是否符合安全和性能预算。

第二层是过程级指标：首次定位正确文件的比例、无效工具调用数、测试失败后的恢复率、上下文利用率、平均迭代轮数、人工接管率。

第三层是组件级评测：检索器能否找到依赖链，任务分解器能否保留验收条件，测试生成器能否杀死注入的变异，代码审查 Agent 能否发现真实缺陷。

第四层是运营指标：单任务成本、端到端延迟、环境失败率、重试次数，以及不同仓库和语言上的稳定性。只有这四层同时存在，模型升级、Prompt 修改或工具链调整才有可解释的对比基础。

实践建议

1. 记录完整实验指纹。至少保存模型版本、Harness 版本、Prompt、工具权限、仓库提交、镜像、依赖锁文件、预算和随机种子。
2. 将模型与 Harness 分开做矩阵实验。固定 Harness 比模型，固定模型比 Harness，避免把组合收益错误归因给单一组件。
3. 为失败建立结构化分类。每次运行标注检索、规划、执行、环境、验证和交接等故障类型。
4. 用行为规范替代补丁相似度。优先隐藏测试、属性约束、兼容性检查和资源预算。
5. 检查验证器本身。通过变异测试确认测试套件能否发现错误实现，防止 Agent 学会“迎合测试”。
6. 报告分布而非单点。对同一任务重复运行，展示均值、方差、置信区间、成本和超时率。
7. 保留真实研发出口。除自动分数外，抽样统计 PR 可合并率、审查修改量和上线后回归。

风险与限制

论文是一篇立场论文，重点是指出测量对象错位并提出研究方向，不是已经完成标准化的新基准。组件级评测会增加运行成本，也可能把系统优化成一组局部指标；组件之间的交互仍需端到端实验验证。

行为规范同样难以完备。隐藏测试、LLM Judge 和人工审查都有偏差，生产反馈又具有延迟和噪声。团队不应删除端到端通过率，而应把它从“唯一答案”降级为多层指标中的一个结果信号。

此外，内部任务分布与公开基准不同。面向单仓库优化的 Harness 可能在本地表现很好，却缺少跨语言、跨架构的泛化能力。评测报告必须明确适用范围，避免把局部结论包装成通用能力。

结语

Agentic 软件工程改变的不只是代码生成方式，也改变了评测对象。我们使用的是由模型、Harness、上下文、环境和反馈组成的系统，却仍试图用一个数字解释所有变化。下一阶段真正有价值的评测，不是再制造一个更大的排行榜，而是建立能区分组件、验证多种合法实现、并能驱动持续改进的测量体系。

参考来源

• arXiv：Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering
  https://arxiv.org/abs/2606.17799