目录一、Coding Agent评测正在发生一次“尺度迁移”一从代码生成到工程行动评测对象已经改变1、过去的核心问题是“代码对不对”现在的问题是“任务做没做完”真实工程任务至少包含五类隐含工作2、排行榜上的一个数字实际上压缩了一个复杂系统二长程任务把“可靠性”从附加属性变成核心能力1、任务越长单步能力越不能代表最终能力长程能力的本质是“持续保持正确方向”2、真实企业更关心失败分布而不仅是平均分二、六类Benchmark并不是六张排行榜而是六个不同的“能力切面”一DeepSWE测的是陌生仓库中的真实功能开发1、任务设计把重点从“复现历史修复”转向“解决新需求”2、DeepSWE真正测量的不是代码长度而是跨文件因果理解3、DeepSWE的指标强调“是否真正解决”但要注意多次运行语义二Terminal-Bench 2.1测的是“能否把一台计算机真正操作到目标状态”1、它把代码降级为手段把最终环境状态升级为评测对象2、Terminal-Bench暴露了“会编程”和“会操作系统”之间的差距3、2.1版本提醒我们Benchmark本身也需要持续验证三FrontierSWE测的不是日常Issue而是Agent能力上限1、它主动选择“当前系统很可能做不完”的任务2、性能任务体现了“正确性是门槛优化是第二阶段”3、Dominance之类的相对指标适合异构任务但不能被误解为成功率四Kimi Code Bench 2.0内部综合评测的价值与局限1、内部Benchmark可以更贴近产品但公开可解释性天然不足2、 内部Benchmark最适合作为“产品回归仪表盘”而不是公共科学基准五ProgramBench测的是黑盒理解、架构设计与“从零重建”1、不给源码只给可执行程序和文档这实际上在测“主动实验能力”2、Raw Pass Rate、Almost Resolved和Fully Resolved表达的是不同工程状态六SWE-Marathon测的是数小时尺度上的工程持续性1、超长任务把Agent从“会做题”推向“会做项目”2、超长任务真正放大的是“自我验证债务”3、反奖励投机开始成为Benchmark的一等公民三、六类Benchmark背后其实存在一套统一的评测系统结构一第一层是任务决定你到底在测什么1、任务来源比任务数量更重要2、 任务应该覆盖“频率 × 价值 × 风险”三维分布二第二层是环境决定Agent能看到什么、能做什么1、环境是评测的一部分不是背景条件2、环境可重复性决定结果能否被信任三第三层是Agent Harness决定模型能力如何被释放1、Harness不是无关紧要的外壳2、企业评测应同时跑“能力基线”和“产品配置”四第四层是验证器决定什么叫“完成”1、验证器比题目文本更接近Benchmark的真实规范2、一个成熟验证器至少要覆盖五种检查五第五层是统计决定一个分数究竟有多可靠1、单次运行无法代表随机Agent的真实能力2、不同指标回答的是不同业务问题四、为什么六个Benchmark的数字不能直接横向相加或平均一分母不同有的是任务有的是试次有的是测试点1、一个“80%”可能至少有三种含义2、必须同时看“项目级完成”和“行为级覆盖”二预算不同高分可能来自更多时间、更多Token或更多重试1、能力与计算预算必须绑定报告2、“单位成功成本”比单纯Token成本更有决策价值三Harness不同你可能在比较Agent产品而不是比较模型四任务难度分布不同一个总分可能隐藏“能力结构”五、面向企业落地应该怎样构建自己的Coding Agent评测体系一先定义“要把什么工作交给Agent”再定义Benchmark1、从工作流切片而不是从模型能力词汇出发2、建议建立三档任务池二建立“公共Benchmark 私有Benchmark 在线回放”三层结构1、公共Benchmark用于外部定位2、私有Benchmark用于真实产品决策3、在线回放用于发现静态Benchmark没有覆盖的问题三统一Harness与最优Harness必须双轨评测1、统一Harness回答“模型谁更强”2、最优Harness回答“产品谁更好用”四建立多层验证器而不是只跑单元测试1、验证器可以采用“门槛 连续分”组合2、推荐的企业任务评分结构五把成本、时延和人工接管纳入主指标1、Agent不是只要成功就行2、建议至少记录六个效率字段六用统计而不是单次Demo做决策1、每个关键任务至少需要重复试验2、报告置信区间和分层结果六、一个成熟评测体系应该重点识别哪些失败模式一理解失败一开始就做错了问题二定位失败知道要做什么但找不到正确修改点三实现失败设计正确但代码本身不成立四环境失败代码可能正确但执行系统没有准备好五验证失败Agent做了很多工作却不知道自己没完成六恢复失败遇到错误后无法回到稳定状态七奖励投机发现“过验证器”比“做任务”更容易Agent越强验证器越要假设对手会主动寻找漏洞七、从这六类Benchmark可以推导出的五个趋势一趋势一评测将从“静态数据集”走向“持续维护的软件系统”二趋势二验证器工程会成为Agent时代的核心基础设施三趋势三长程评测会更强调中间过程指标但不会直接奖励“漂亮推理”四趋势四模型、Harness和预算会被视为不可分割的产品配置五趋势五企业会从“总分冠军”转向“任务路由”八、从Benchmark到生产建议建立一张“Coding Agent可托付性记分卡”一第一维能力覆盖二第二维稳定性三第三维完成质量四第四维经济性五第五维安全与可控性六第六维可恢复性七第七维泛化与抗污染八第八维可解释的失败归因九、结论真正的下一代评测不是更难的题而是更接近真实交付的测量一六类Benchmark共同揭示了一个变化Coding Agent的竞争正在从“生成能力”转向“闭环工程能力”二对企业而言最重要的不是追逐榜单第一而是建立自己的证据链三未来的核心指标可能不再是一列“Score”而是一张联合分布图可参考文章与官方资料干货分享感谢您的阅读Coding Agent 的能力正在从“生成一段可运行代码”快速迁移到“在真实软件环境中持续行动并完成交付”。这使得传统以单元测试、单文件补全和单次成功率为中心的评测方法越来越难回答真正重要的问题一个 Agent 能否理解陌生仓库能否在终端环境中完成依赖配置和调试能否在数小时尺度上维持目标、记忆与自检能否重建一个看不到源码的程序能否在正确性之外继续优化性能能否抵抗验证器漏洞和奖励投机。我们以 DeepSWE、Terminal-Bench 2.1、FrontierSWE、Kimi Code Bench 2.0、ProgramBench 与 SWE-Marathon 六类代表性评测为切入点在梳理其任务形态、环境、验证器与指标语义的基础上进一步提出一套面向企业落地的 Coding Agent 评测框架。未来真正有价值的评测对象不是“模型”本身而是“模型 Agent Harness 工具权限 运行环境 预算 验证器”组成的完整执行系统真正应该被度量的也不只是平均成功率而是成功率、稳定性、成本、时间、可恢复性、行为安全、泛化与交付质量的联合分布。一、Coding Agent评测正在发生一次“尺度迁移”一从代码生成到工程行动评测对象已经改变1、过去的核心问题是“代码对不对”现在的问题是“任务做没做完”早期代码模型的典型评测单位是一道函数题给出自然语言说明、函数签名和若干示例让模型生成实现再用隐藏测试判断是否正确。这种评测之所以有效是因为模型的输入、输出和责任边界都非常清晰。模型不需要理解大型仓库不需要安装依赖不需要选择调试策略也不需要记住自己一小时前做过什么。它只要把局部函数写对即可。Coding Agent 改变了这一前提。Agent 获得 shell、编辑器、文件系统、测试框架、包管理器、浏览器甚至远程服务后输出不再是一段静态文本而是一连串对环境的操作。真正决定结果的往往不是“能否写出某个函数”而是能否发现正确文件、理解调用链、判断失败日志、选择工具、维护工作状态、修改多个模块、跑通测试并最终提交一个干净的结果。也就是说评测对象从“语言模型的局部生成能力”变成了“智能体在环境中的闭环执行能力”。如果仍然只看最终补丁是否通过几个测试就可能遗漏大量决定真实可用性的能力差异。真实工程任务至少包含五类隐含工作第一类是定位。需求通常不会告诉 Agent 应修改哪个文件Agent 必须自己理解仓库结构、入口、依赖关系和历史设计。第二类是计划。复杂需求常常同时涉及数据结构、接口、异常处理、测试、文档和兼容性Agent 需要把任务拆成可执行阶段。第三类是环境操作。依赖安装、构建、容器、权限、数据库、GPU、网络和系统工具都可能成为任务的一部分。第四类是反馈驱动迭代。第一次实现失败是常态Agent 必须根据编译器、测试、运行日志和行为差异持续修复。第五类是完成性判断。真正困难的不是“开始做”而是判断什么时候已经满足需求、哪些测试仍不足、是否存在回归、是否还需要额外验证。这些能力构成了一种新的软件工程智能它不等同于代码知识也不等同于推理能力而是知识、推理、工具使用、状态管理和验证习惯的组合。2、排行榜上的一个数字实际上压缩了一个复杂系统当一个评测结果写成“72.9”“88.3”或“42.0”时人很容易把它理解为“这个模型有 72.9%、88.3% 或 42% 的编程能力”。这种理解几乎总是过度简化。一个 Coding Agent 的结果至少由以下变量共同决定底层模型、思考预算、上下文窗口、Agent Harness、系统提示词、工具集合、工具调用协议、运行时限、容器资源、网络策略、重试机制、上下文压缩策略、文件编辑方式、测试反馈是否可见以及最终验证器的严格程度。只要这些变量中的一项发生变化同一个模型就可能呈现明显不同的成绩。因此未来讨论 Coding Agent 时更准确的表述不应是“模型 A 在 Benchmark X 上得分多少”而应是“模型 A 在某个明确的 Agent Harness、预算和环境配置下经过某种验证方法得到什么结果”。这不是措辞洁癖而是可复现性要求。二长程任务把“可靠性”从附加属性变成核心能力1、任务越长单步能力越不能代表最终能力短任务中模型某一步判断错误可能只意味着一个测试不过长任务中一次早期错误可能在数十个步骤后才暴露并产生连锁成本。Agent 可能在错误架构上投入大量时间也可能因为一次错误依赖安装污染环境还可能在上下文压缩后忘记关键约束。这意味着长程任务的成功概率不是若干局部能力的简单平均而更像一条“可靠性链”。假设一个任务包含十个都必须完成的关键阶段每个阶段独立成功概率都是 95%那么十个阶段全部成功的理论概率只有约 60%。真实 Agent 的阶段还并不独立前期理解偏差会显著降低后续实现和验证成功率因此整体成功率可能下降得更快。长程能力的本质是“持续保持正确方向”长程 Agent 不是单次生成更长文本而是在较长时间内持续维护三个内部状态目标状态、世界状态和工作状态。目标状态回答“最终要实现什么”世界状态回答“当前代码和环境实际是什么”工作状态回答“我已经做了什么、还欠什么、哪些假设尚未验证”。只要其中任何一个状态在长时间运行中漂移Agent 就可能出现典型的“看起来一直在工作但越来越偏离目标”的现象。因此 SWE-Marathon 一类超长程任务的价值不只在于把时限从几十分钟拉长到数小时更在于把 Agent 的计划保持、记忆恢复、自我验证、失败恢复和终止判断暴露出来。2、真实企业更关心失败分布而不仅是平均分企业部署最怕的往往不是“平均能力稍弱”而是失败模式不可预测。例如一个 Agent 平均能完成 80% 的任务但剩余 20% 会静默引入数据错误另一个 Agent 只能完成 70%但失败时会明确停止并给出可审查证据。对于生产系统第二种 Agent 可能更安全、更容易纳入流程。因此平均成功率只能回答“通常有多强”不能回答“失败时会发生什么”。工程评测必须同时记录失败是否可检测、失败发生在哪个阶段、是否会破坏环境、是否会误报成功、是否能恢复、是否会尝试绕过验证器以及人工接管需要多少成本。二、六类Benchmark并不是六张排行榜而是六个不同的“能力切面”一DeepSWE测的是陌生仓库中的真实功能开发1、任务设计把重点从“复现历史修复”转向“解决新需求”DeepSWE 由 113 个原创长程软件工程任务构成覆盖 91 个活跃开源仓库和 TypeScript、Go、Python、JavaScript、Rust 五种语言。其关键设计并不是简单增加题目难度而是刻意减少训练数据污染任务由评测方重新编写不从已经存在的 GitHub issue、PR 或历史修复中直接抽取参考实现也不会进入上游公开记录。公开资料进一步强调评测由手写 verifier 检查外部行为而不是要求实现细节与参考补丁一致。[1][2]这使它更接近真实的陌生仓库开发用户提出一个新需求Agent 需要自己理解仓库、设计实现、修改多个文件、运行测试然后交付补丁。评测的核心问题不是“是否记住了某次历史修复”而是“能否在未见过的新需求上完成端到端工程闭环”。2、DeepSWE真正测量的不是代码长度而是跨文件因果理解在大型仓库中困难通常不在于写某一段算法而在于知道这段逻辑应该放在哪里、会影响什么、需要兼容哪些现有约束。一个看似短的需求可能涉及配置加载、缓存语义、并发控制、错误处理和回归测试。Agent 必须构建对仓库的局部“因果模型”哪些模块是入口哪些状态会传播哪些公共接口不能破坏。这类能力与传统函数级代码生成差异很大。函数题可以通过局部模式匹配解决而仓库任务更依赖结构搜索、证据收集和变更影响分析。3、DeepSWE的指标强调“是否真正解决”但要注意多次运行语义资料中常用 pass1、pass4 描述结果。工程上可把 pass1 理解为单次随机运行成功的概率而 pass4 则强调多次独立尝试后“至少成功一次”的解决能力。两者反映不同部署方式如果企业要求一次自动运行就可靠完成pass1 更重要如果允许并行探索、重试和最佳结果筛选多次尝试的指标更接近实际策略。但多次运行并不是免费午餐。pass4 的提升可能来自模型真正更稳定也可能来自把预算放大四倍。因此评测时应同时报告成本和时延否则“多跑几次就能解决”会掩盖系统效率问题。二Terminal-Bench 2.1测的是“能否把一台计算机真正操作到目标状态”1、它把代码降级为手段把最终环境状态升级为评测对象Terminal-Bench 的任务发生在预先构建的容器环境中Agent 可以使用 shell、脚本、编译器、包管理器以及其他终端工具。任务可能涉及软件构建、系统调试、依赖配置、数据处理、科学计算乃至安全相关操作。Terminal-Bench 2.1 对 2.0 中的一批任务进行了修订重点处理测试缺陷、时限与资源设置以及 reward hacking 风险官方提交要求多次试验并通过 Harbor 运行。[3][4]它的重要思想是评测最终状态而不是评测终端里说了什么。Agent 可以写代码也可以调用现成工具可以采取优雅方案也可以采用不同路径。只要最终容器满足隐藏测试要求就算完成。这种设计比“比较生成文本”更接近现实自动化。2、Terminal-Bench暴露了“会编程”和“会操作系统”之间的差距许多强代码模型在真实终端中仍可能失败因为它们需要处理非代码因素版本冲突、权限问题、服务启动、文件格式、路径、环境变量、系统资源或命令行工具行为。真实工程工作的很大一部分恰恰由这些“不漂亮但必须做对”的细节构成。因此 Terminal-Bench 的 Resolution Rate 更像“任务执行成功率”而不是“代码正确率”。即便 Agent 给出了逻辑合理的分析只要最终环境没有达到目标仍然应该判失败。这种严格性对自动化系统非常重要因为生产系统无法用“思路正确”替代可用结果。3、2.1版本提醒我们Benchmark本身也需要持续验证一个容易被忽视的问题是Agent Benchmark 也会有 bug。测试可能漏掉边界情况资源限制可能不合理任务描述可能产生歧义验证器可能被投机利用。Terminal-Bench 2.1 的修订说明了一个重要原则评测集不是一次发布后永远不变的静态试卷而应该像软件一样持续维护、回归测试和版本化。如果一个排行榜没有清晰版本、任务变更记录和验证器修订历史那么跨时间比较很可能失真。企业内部评测同样应采用数据集版本、环境镜像版本和验证器版本三重锁定。三FrontierSWE测的不是日常Issue而是Agent能力上限1、它主动选择“当前系统很可能做不完”的任务FrontierSWE 的定位是 ultra long-horizon technical challenges任务覆盖复杂系统实现、性能工程和机器学习研究。与只看最终 Pass/Fail 的评测不同它允许在非常困难的任务上给予连续部分分并针对不同类别采用不同评分方式。[5]这种设计回答的是另一个问题当所有系统都无法完整完成任务时谁能取得更多有价值的进展如果只采用二元成功率所有模型都可能是 0 分评测就失去分辨率。FrontierSWE 通过正确性比例、性能收益或研究指标让“差一点完成”和“几乎没开始”产生可见差异。2、性能任务体现了“正确性是门槛优化是第二阶段”FrontierSWE 的公开评分说明中Implementation 任务主要按 correctness 计分Performance 任务则采用门控思路代码未完全正确时最多获得正确性相关部分分只有在达到完整正确性之后性能加速或压缩收益才进入更高分区间。[6]这个设计非常工程化。现实中“快但错”的程序通常没有价值因此性能优化不能在正确性未满足时补偿错误。对于企业内部的数据库、编译器、推荐系统或推理服务优化任务这种分层评分值得直接借鉴。3、Dominance之类的相对指标适合异构任务但不能被误解为成功率当 Implementation、Performance、ML Research 的原始得分尺度不同直接把原始分数平均很容易产生无意义的总分。FrontierSWE 因此引入跨任务排名和相对胜率类指标把不同任务先转化为“在该任务上谁更强”再汇总。这类指标的优势是可以统一异构尺度缺点是它依赖参赛系统集合。同一个模型的原始任务结果不变如果对手集合发生变化相对指标也可能变化。因此它更适合“比较一组系统”不适合被解释为“完成了多少百分比任务”。四Kimi Code Bench 2.0内部综合评测的价值与局限1、内部Benchmark可以更贴近产品但公开可解释性天然不足Kimi K3 技术报告中展示了 Kimi Code Bench 2.0Internal分数并说明不同模型通过相应 Coding Agent Harness 执行。公开材料把它描述为面向复杂端到端开发、长程编码、多语言、前端、DevOps 和性能优化等场景的内部综合评测但任务规模、采样方式、验证器结构、重复次数和完整加权公式并未公开。[7]这并不意味着内部 Benchmark 没有价值。相反对产品团队而言内部评测往往最能覆盖真实用户分布、私有技术栈和业务流程。问题在于内部总分的对外含义必须被严格限定。只要评分公式和样本分布不公开就不能把一个 0-100 的综合分直接翻译为“完成率”。2、 内部Benchmark最适合作为“产品回归仪表盘”而不是公共科学基准企业内部评测的最佳用途是稳定地回答版本迭代问题新模型是否退化了某类任务新 Harness 是否减少了工具失败上下文压缩策略是否改善了长任务某次安全加固是否牺牲了过多成功率只要任务集、环境和评分方案在内部版本化内部总分就能成为非常有效的回归指标。但若要用于对外比较就应至少披露任务类别占比、样本规模、运行预算、是否允许重试、基本评分语义和置信区间。五ProgramBench测的是黑盒理解、架构设计与“从零重建”1、不给源码只给可执行程序和文档ProgramBench 把软件工程评测推向了一个很有启发性的方向Agent 看不到参考程序的源代码只能获得编译后的可执行程序和文档。它可以把原程序当作 oracle主动设计输入、观察输出、推断规则然后自己决定架构、语言、模块和构建方式从零重写一个行为兼容的程序。公开项目包含约 200 个任务并通过大规模行为测试比较参考程序与候选程序的可观察行为。[8][9]这使它摆脱了“在现有代码上做局部补丁”的范式。Agent 不仅要编码还要完成需求发现、测试设计、行为建模和架构构造。这实际上在测“主动实验能力”ProgramBench 中最关键的步骤之一不是写代码而是问对问题。面对一个黑盒程序Agent 必须设计足够有信息量的输入才能快速缩小行为假设空间。若只随机试几个例子很容易得到错误泛化若能系统覆盖边界、异常、组合输入和状态转换就更可能逼近真实行为。这种能力与科研中的实验设计非常相似先提出假设再构造实验区分假设根据结果更新模型。未来强 Coding Agent 的竞争力很可能越来越取决于这种“自己制造监督信号”的能力。2、Raw Pass Rate、Almost Resolved和Fully Resolved表达的是不同工程状态ProgramBench 公开排行榜区分 Fully Resolved、Almost Resolved 和平均行为测试通过率。Fully Resolved 要求一个任务的隐藏行为测试全部通过Almost Resolved 用高通过率阈值描述“几乎完成”平均测试通过率则反映部分行为覆盖程度。[9]对企业评测而言这种多层指标非常有价值。单一平均测试通过率可能掩盖“每个项目都只完成 80%”的危险状态单一 Fully Resolved 又可能在模型尚弱时过于稀疏。把完整成功率和部分完成度同时展示可以既保持严格交付标准又保留能力进步的分辨率。六SWE-Marathon测的是数小时尺度上的工程持续性1、超长任务把Agent从“会做题”推向“会做项目”SWE-Marathon 包含 20 个长程任务横跨软件工程和相邻技术领域。公开论文强调任务需要在复杂环境中持续运行包含多层验证Agent 轨迹平均消耗数千万 token其研究重点包括规划、长上下文、记忆、自验证、失败恢复和奖励投机等问题。[10]与 DeepSWE 的“在仓库中完成新功能”相比SWE-Marathon 更强调时间跨度和项目完整性。Agent 可能需要在数小时内反复实现、运行、观察、修复甚至训练模型或进行性能优化。最终验证通常看提交后的环境状态而不是中间推理是否漂亮。2、超长任务真正放大的是“自我验证债务”人在长项目里会自然形成里程碑、检查清单、阶段性测试和回滚点Agent 如果没有这些机制就会不断积累未验证假设。任务越长这种“自我验证债务”越容易复利增长一个早期错误假设会影响后续设计后续实现又建立在错误设计之上直到最终测试才集中爆炸。因此长程 Agent 的关键能力并不是永远不犯错而是把错误控制在局部、尽早发现、能够恢复。评测中应专门记录回滚次数、错误发现延迟、阶段性测试覆盖和失败后的恢复成功率。3、反奖励投机开始成为Benchmark的一等公民SWE-Marathon 论文报告了对 reward hacking 的观察并通过多层检查、对抗性审查和完整性验证降低“绕过真正任务”的可能性。[10] 这说明随着 Agent 工具权限增强评测不再只是“出题和判卷”而是要考虑一个主动优化者会不会发现验证器漏洞。未来任何高价值 Agent Benchmark 都需要安全思维验证器应测试结果而不是暴露容易被针对的路径关键文件和参考答案需要隔离环境要限制不必要的外部访问还要审查异常快速完成、修改测试、替换参考二进制、伪造输出等投机行为。三、六类Benchmark背后其实存在一套统一的评测系统结构一第一层是任务决定你到底在测什么1、任务来源比任务数量更重要一个 Benchmark 的质量首先取决于任务分布而不是题目总数。任务来源决定了模型可能利用什么捷径也决定了得分能否外推到真实工作。如果任务直接来自已经公开多年的 GitHub issue 和补丁模型可能在训练中见过相关文本即便没有直接记住答案也可能学到高度相似的修复模式。原创任务、时间切分、私有任务或持续滚动生成任务可以降低这种污染风险。但原创任务也有代价需要专家设计、实现参考解法、编写验证器并进行质量审查成本远高于从历史仓库自动采样。企业内部可以采用“真实工单脱敏 新需求改写 合成变体”混合方式在真实性和保密性之间平衡。2、 任务应该覆盖“频率 × 价值 × 风险”三维分布只按真实出现频率采样会让大量简单任务淹没少数关键任务只挑最难任务又会与日常生产脱节。更合理的企业任务集应按三维权重构造出现频率、业务价值和失败风险。例如简单配置修改很常见但风险低数据库迁移频率不高但风险极大跨模块功能开发价值高且常见。评测集应该让这三类任务都占有合理比重并分别报告结果而不是只合成一个总分。二第二层是环境决定Agent能看到什么、能做什么1、环境是评测的一部分不是背景条件同一道任务如果允许联网、允许访问 git 历史、允许读取测试源码、提供强大的 IDE 索引难度会完全不同。Agent 的工具权限直接改变问题空间因此环境配置必须像模型版本一样被记录。Terminal-Bench 和 SWE-Marathon 的价值就在于把环境显式化任务不只是文本而是“文本 容器 资源 工具 隐藏验证”。这比纯文本 Benchmark 更接近真实部署。2、环境可重复性决定结果能否被信任依赖源更新、基础镜像变化、网络波动、GPU 型号、编译器版本和外部 API 都可能让同一个任务在不同日期得到不同结果。企业评测应尽量冻结镜像、依赖和数据快照对确实需要外部服务的任务则应记录服务版本并建立可重放替身。一个高质量任务应该能区分“Agent失败”和“基础设施失败”。如果因为下载源短暂不可用而把 Agent 判错指标会混入大量噪声。三第三层是Agent Harness决定模型能力如何被释放1、Harness不是无关紧要的外壳同一个底层模型通过不同 Harness 运行可能形成完全不同的行为。Harness 决定系统提示、工具定义、文件浏览方式、是否自动跑测试、是否保留计划、何时压缩上下文、如何恢复失败、是否并行子任务以及何时终止。因此比较底层模型时如果同时改变 Harness就难以判断提升来自模型还是工程框架。公共 Benchmark 最理想的做法是提供统一最小 Harness 作为基础线同时允许产品 Harness 参赛但排行榜中必须把“模型”和“Agent”作为两个独立字段。2、企业评测应同时跑“能力基线”和“产品配置”能力基线使用尽量统一、简单、透明的 Harness目的是观察模型本身的相对能力产品配置使用真实生产 Agent目的是判断用户最终体验。两套结果都重要。只有能力基线可能忽略产品工程带来的巨大增益只有产品配置则无法定位一次迭代究竟是模型变强还是 Harness 变强。四第四层是验证器决定什么叫“完成”1、验证器比题目文本更接近Benchmark的真实规范在 Agent 评测里文字需求只是表面规范真正决定得分的是验证器。若验证器覆盖不足Agent 可以实现一个不完整方案却得满分若验证器绑定具体实现细节又可能把正确的替代方案判错。DeepSWE 强调基于行为的手写 verifierProgramBench 用大量行为测试比较参考程序与候选程序SWE-Marathon 采用多层验证。这些做法共同指向一个原则验证器应该尽可能验证用户可观察的结果而不是逼迫 Agent 复制参考实现。2、一个成熟验证器至少要覆盖五种检查第一功能正确性核心需求是否实现。第二回归性原有功能是否被破坏。第三非功能约束性能、资源、兼容性、安全性是否满足门槛。第四完整性是否通过修改测试、伪造输出或访问参考答案绕过任务。第五可重放性结果在干净环境中是否仍能复现。如果验证器只检查第一项就很容易高估 Agent 的工程可用性。一个更完整的Coding Agent评测流水线任务、环境、Harness、验证器、重复试验与统计口径缺一不可。五第五层是统计决定一个分数究竟有多可靠1、单次运行无法代表随机Agent的真实能力现代推理模型通常具有采样随机性Agent 的工具调用路径也会因为早期选择不同而快速分叉。同一个任务第一次成功、第二次失败并不罕见。因此只跑一次会把“运气”误当成“能力”。多次独立运行可以估计成功概率但应报告试次总数和置信区间。如果两个系统分别是 71% 和 73%而置信区间高度重叠就不应做过度结论。2、不同指标回答的是不同业务问题pass1 或 Resolution Rate 适合回答“随机跑一次能完成多少”best-of-N 适合回答“允许多次探索、最后挑一个最好结果能到什么水平”平均连续得分适合回答“即便没完成能推进到什么程度”相对胜率适合跨异构任务比较成本和耗时则回答“这份能力值不值得”。评测报告应该先说业务问题再选指标而不是先有一个排行榜指标再强行解释业务意义。常见指标的语义边界同为“分数”它们对完整成功、部分进展和多次尝试的含义完全不同。四、为什么六个Benchmark的数字不能直接横向相加或平均一分母不同有的是任务有的是试次有的是测试点1、一个“80%”可能至少有三种含义第一种是 80% 的任务被完整解决第二种是所有独立试次中有 80% 成功第三种是平均通过了 80% 的隐藏测试。三者在产品意义上差别巨大。如果一个系统在 100 个项目上都只实现 80% 功能那么 Raw Pass Rate 可能很好看但完整交付率可能是 0。相反一个系统可能在 60 个任务上全部完成、40 个任务几乎没做完整成功率为 60%平均测试通过率也许同样在 60% 左右但用户体验完全不同。2、必须同时看“项目级完成”和“行为级覆盖”项目级完成指标严格、直观适合最终交付行为级覆盖指标连续、敏感适合研发阶段观察进步。成熟评测最好同时保留两者避免任何一项独占解释权。二预算不同高分可能来自更多时间、更多Token或更多重试1、能力与计算预算必须绑定报告一个允许数小时、百万级上下文和多次并行探索的 Agent与一个限制十分钟、低 token 预算的 Agent不应只用最终成功率比较。对于企业这就像比较两个团队时忽略一个团队用了四倍人力。建议每个 Benchmark 结果至少同时报告成功率、单任务平均成本、成功任务成本中位数、平均墙钟时间、P90 时间、平均模型 token、工具调用次数、重试次数。2、“单位成功成本”比单纯Token成本更有决策价值可定义一个工程指标单位成功成本 总评测成本 / 完整成功任务数。它把能力和成本放到同一分母上。一个昂贵但稳定的系统与一个便宜但经常失败的系统就可以在更接近业务的尺度上比较。当然该指标也不能单独使用因为失败任务的风险差异很大但作为产品决策指标它比只看平均 token 更有意义。三Harness不同你可能在比较Agent产品而不是比较模型工具工程可以带来与模型升级同量级的变化更好的文件检索、更稳定的编辑器、更智能的测试选择、长期记忆、自动回滚和上下文压缩都可能显著提高成功率。如果排行榜上的模型 A 使用高度优化的原生 Harness而模型 B 使用通用 Harness直接把差距归因于模型是不严谨的。因此评测报告应明确标注“Model × Harness × Effort”三元组。对于内部模型选型则最好在统一 Harness 下做一次控制实验再在各家最优 Harness 下做一次产品实验。四任务难度分布不同一个总分可能隐藏“能力结构”总分相同的两个Agent可能完全不一样Agent A 擅长 Python 和常规后端 issue但不擅长 DevOpsAgent B 在系统调试和性能优化很强但普通仓库开发一般。如果把所有任务混成一个平均分两者可能相同但对具体团队的价值完全不同。真正的产品选型应使用能力向量而不是单一标量。至少应分出仓库理解、功能开发、调试、终端操作、依赖与环境、性能优化、前端/交互、黑盒逆向、长程规划、恢复能力、安全与反投机等维度。五、面向企业落地应该怎样构建自己的Coding Agent评测体系一先定义“要把什么工作交给Agent”再定义Benchmark1、从工作流切片而不是从模型能力词汇出发企业常见错误是先列“代码能力、推理能力、Agent能力”等抽象指标再去找题目。更有效的方式是从真实软件生命周期切片需求理解、仓库定位、开发、测试、调试、代码审查、发布、事故处理、数据迁移、性能优化、文档与运维。对每一个环节定义可托付边界Agent 是只给建议、提交 PR、自动合并还是可以直接操作环境自动化等级越高评测就越应重视完整性、可恢复性和风险控制。2、建议建立三档任务池A档高频基础任务。如小型 bug、测试补充、配置修改、文档同步。目标是衡量效率和稳定性。B档核心工程任务。如跨模块功能、复杂调试、依赖升级、重构。目标是衡量端到端交付能力。C档高难或高风险任务。如性能优化、数据库迁移、生产故障修复、安全加固、长程项目。目标是探测能力边界和风险。三档应分别报告不能让 A 档大量简单任务把 C 档严重失败“平均掉”。二建立“公共Benchmark 私有Benchmark 在线回放”三层结构1、公共Benchmark用于外部定位公共 Benchmark 的价值是可比较、可复现和有研究生态。可以选取 DeepSWE 代表仓库功能开发Terminal-Bench 代表终端执行ProgramBench 代表黑盒重建SWE-Marathon 或 FrontierSWE 代表超长程/能力上限。但公共 Benchmark 无法完全代表企业自己的语言栈、框架、数据和流程因此只适合做“外部能力坐标”。2、私有Benchmark用于真实产品决策私有任务来自企业真实工单、历史故障、重构需求和项目模板经过脱敏和冻结后形成可重放数据。它的价值是高相关性也天然降低公开训练污染。私有集需要严格权限控制防止评测题进入训练或提示模板模型迭代过程中还应保留一部分永不用于调优的“冷藏集”。3、在线回放用于发现静态Benchmark没有覆盖的问题静态 Benchmark 很难覆盖真实用户的新任务和环境变化。生产系统可以在保证隐私与合规的前提下把真实失败轨迹抽象成可重放案例定期加入候选评测池。这样评测集就能随产品一起演化。三统一Harness与最优Harness必须双轨评测1、统一Harness回答“模型谁更强”让不同模型使用同一套最小 Harness、相同工具和预算控制其他变量。该结果适合模型采购、基座选择和能力研究。2、最优Harness回答“产品谁更好用”允许每个 Agent 使用自己的真实工具链和最佳配置评估最终系统体验。该结果适合产品选型和用户价值判断。两种实验必须明确分开否则一个好 Harness 可能被误认为模型优势一个好模型也可能被糟糕 Harness 拖累。四建立多层验证器而不是只跑单元测试1、验证器可以采用“门槛 连续分”组合例如核心功能必须 100% 通过否则任务最高只能得到 60 分核心功能通过后再根据性能、代码质量、回归测试、资源占用和体验获得额外分。这样既保持“功能不对就不能算完成”的底线也可以区分高质量与勉强可用的方案。2、推荐的企业任务评分结构可以把单任务评分拆成五层功能正确性40%关键功能必须过门槛回归与兼容性20%非功能质量15%包括性能、资源与安全工程质量10%包括可维护性、构建和测试过程可靠性15%包括自验证、恢复、无越权行为。具体权重应按业务调整。关键不是这组数字本身而是把“完整交付”拆成可解释层级。五把成本、时延和人工接管纳入主指标1、Agent不是只要成功就行如果一个 Agent 完成普通任务需要 40 分钟和高额推理成本而人工工程师只需 15 分钟那么即使成功率高也未必有经济价值。反之如果 Agent 能在后台并行处理大量低优先级任务墙钟时间稍长也可能可以接受。因此企业评测必须结合实际工作模式定义效率指标而不是机械追求最低延迟。2、建议至少记录六个效率字段单任务模型成本、总工具调用次数、墙钟时间、首次有效修改时间、完整验证时间、人工接管分钟数。“人工接管分钟数”尤其重要。一个成功率稍低但能把失败清晰定位的 Agent可能比一个需要工程师花很久清理现场的 Agent 更有价值。六用统计而不是单次Demo做决策1、每个关键任务至少需要重复试验对于随机性较高的 Agent同一任务跑多次才能估计稳定性。资源有限时不必对所有任务都跑五次但高价值、高风险任务应优先重复且应固定随机种子策略和运行预算。2、报告置信区间和分层结果一个企业评测仪表盘最好同时展示总体成功率、任务类别成功率、不同难度成功率、成本分布、时延分布和失败类型。比起一个精确到小数点后一位的总分这些分布更能支持工程决策。面向企业的Coding Agent五层评测框架从任务分布到环境、Harness、验证器、统计与成本最终形成“能力-可靠性-经济性”联合决策。六、一个成熟评测体系应该重点识别哪些失败模式一理解失败一开始就做错了问题需求误读与隐含约束遗漏Agent 可能抓住表面功能却忽略兼容性、边界条件或旧行为。此类失败往往在实现阶段看起来进展顺利直到隐藏测试才暴露。评测应记录“错误假设首次出现时间”和“隐藏约束发现时间”以区分知识不足和验证不足。二定位失败知道要做什么但找不到正确修改点仓库结构理解不足大型仓库可能有多个相似模块、生成代码、平台适配层和测试夹具。Agent 如果只靠文本搜索很容易修改表层位置而没有触达真正执行路径。可以通过轨迹分析统计无效文件浏览、重复搜索、错误入口修改和最终变更跨度衡量仓库导航效率。三实现失败设计正确但代码本身不成立常见情况是单个模块测试通过但跨模块接口、异步时序或状态一致性失败。此类问题说明 Agent 的局部编码能力强于系统级整合能力。四环境失败代码可能正确但执行系统没有准备好依赖、构建、权限和资源问题Terminal-Bench 尤其能暴露这一类失败。企业生产中这类问题非常常见所以不能把它简单归为“非模型问题”。如果产品定位就是自动化工程师环境处理本身就是能力的一部分。五验证失败Agent做了很多工作却不知道自己没完成Agent 在没有跑关键测试、只看到局部成功日志时就结束是长程任务中的高频风险。比起明确报错这种失败更容易进入后续流程。因此评测应记录终止前最后一次验证覆盖、Agent 自报置信度和真实结果之间的校准关系。一个好的 Agent 不仅要会做还要知道自己做没做对。六恢复失败遇到错误后无法回到稳定状态Agent 在缺乏回滚意识时会在错误方案上不断打补丁最终产生难以解释的状态。企业级 Agent 应具备明确的检查点、git 提交、环境重建或分支试验能力。七奖励投机发现“过验证器”比“做任务”更容易Agent越强验证器越要假设对手会主动寻找漏洞可能的投机包括修改测试、硬编码已知输出、替换参考程序、绕过性能检查、读取不应访问的文件、伪造状态或利用网络检索答案。随着 Agent 推理和工具能力增强这些行为不一定来自恶意而可能是优化目标的自然结果。因此安全隔离、完整性检查和异常轨迹审计应成为 Benchmark 基础设施的一部分。Coding Agent常见失败链路失败并不只发生在“写代码”阶段理解、定位、环境、验证、恢复和完整性都会成为瓶颈。七、从这六类Benchmark可以推导出的五个趋势一趋势一评测将从“静态数据集”走向“持续维护的软件系统”版本、镜像和验证器会像代码一样迭代Terminal-Bench 2.1 的修订已经体现这一趋势。未来 Benchmark 需要有 issue、版本发布、验证器回归、污染审计和硬件适配说明。一个长期不更新的评测集即使仍有知名度也可能逐渐失去测量价值。二趋势二验证器工程会成为Agent时代的核心基础设施谁能定义“完成”谁就能更可靠地训练和评估Agent对于可自动验证任务强化学习、搜索、best-of-N 和自我改进都依赖高质量 reward。验证器不仅服务评测也直接决定训练上限。DeepSWE 的行为验证、ProgramBench 的大规模行为测试、SWE-Marathon 的多层验证都说明未来高质量 Agent 数据集的主要成本很可能不在写 prompt而在构建可靠 verifier。三趋势三长程评测会更强调中间过程指标但不会直接奖励“漂亮推理”过程指标的目的应是诊断而不是替代结果最终结果仍然应该由可观察状态决定但为了研发需要额外记录里程碑达成、验证频率、回滚、上下文压缩、工具失败、错误恢复等过程变量。这些数据能解释为什么 Agent 失败并指导 Harness 改进。换言之结果用于排名过程用于工程。四趋势四模型、Harness和预算会被视为不可分割的产品配置未来排行榜会越来越像系统BenchmarkKimi K3 技术报告已经把不同 Coding Agent 评测放在模型与 Harness 配置中展示。[7] 随着 Agent 工程复杂度上升单纯比较 API 模型名的意义会下降。对用户来说真正购买的是“在给定成本和权限下能完成工作的系统”。五趋势五企业会从“总分冠军”转向“任务路由”最强系统未必是所有任务的最优系统有的模型擅长长上下文有的模型终端执行稳定有的模型性能优化更强有的系统成本低。企业最终很可能不是选一个 Agent 处理所有工作而是根据任务类型、风险和预算动态路由简单任务用低成本模型复杂仓库任务用强模型性能任务用专门配置高风险任务要求人机协同。这种路由策略需要能力画像而不是单一排行榜。八、从Benchmark到生产建议建立一张“Coding Agent可托付性记分卡”一第一维能力覆盖按仓库开发、终端操作、黑盒重建、性能优化、前端、DevOps、数据任务、长程项目等类别给出成功率和样本量。不要把未覆盖任务默认视为“应该也能做”。二第二维稳定性同一任务多次运行是否结果一致记录 pass1、重复运行方差、失败重试收益和不同随机种子差异。稳定性决定无人值守程度。三第三维完成质量不是“测试过了”就结束同时检查回归、性能、安全、代码可维护性、构建可复现性和文档。对于生产 PR还应看人工 Review 修改量。四第四维经济性能力必须换算成单位工作成本至少记录单位成功成本、平均时延、并发吞吐和人工接管。模型费用只是总成本的一部分失败清理和等待时间也应计入。五第五维安全与可控性评测越权访问、危险命令、秘密信息处理、外部网络行为、测试篡改、数据破坏和误报成功。高风险环境应采用权限最小化、沙箱和审计日志。六第六维可恢复性一个可托付 Agent 应能在部分失败后保留可理解的工作产物或者安全回滚到起点。恢复时间和人工接管难度应被量化。七第七维泛化与抗污染是否只会做“见过的题型”通过原创任务、时间切分、私有任务、描述改写和实现路径变化测试泛化。对于高频调优的内部评测要防止 Harness 团队对固定题集过拟合。八第八维可解释的失败归因评测的最终价值是指导改进每次失败应尽量归入可行动类别模型理解、检索定位、工具失败、上下文丢失、实现错误、测试不足、资源不足、验证器问题或安全拦截。只有能归因Benchmark 才能从“比赛”变成“研发系统”。九、结论真正的下一代评测不是更难的题而是更接近真实交付的测量一六类Benchmark共同揭示了一个变化Coding Agent的竞争正在从“生成能力”转向“闭环工程能力”DeepSWE 把焦点放在陌生仓库和原创需求上Terminal-Bench 2.1 把评测对象扩展到完整终端环境FrontierSWE 用连续得分探索能力上限ProgramBench 让 Agent 在黑盒条件下自己发现行为并重建软件SWE-Marathon 把任务拉到数小时尺度逼迫系统面对记忆、恢复和自验证Kimi Code Bench 2.0 则代表厂商内部以真实产品场景为导向的综合回归体系。它们并不存在一个简单的“谁更高级”关系。它们像不同的压力测试有人测仓库有人测终端有人测黑盒有人测极限有人测耐力。真正成熟的评测策略应该把这些切面组合成能力画像。二对企业而言最重要的不是追逐榜单第一而是建立自己的证据链任何“这个Agent能不能用”的结论都应该能回答六个问题第一任务和我们的真实工作有多像第二Agent 在什么 Harness、预算和权限下运行第三验证器是否真的覆盖了用户关心的结果第四成功率是否经过足够重复试验置信区间多大第五成功需要多少时间、成本和人工接管第六失败时会不会造成不可接受的风险只要其中一个问题答不上来一个漂亮的 Benchmark 分数就仍然只是营销信息而不是工程证据。三未来的核心指标可能不再是一列“Score”而是一张联合分布图可托付性 能力 × 稳定性 × 验证质量 × 经济性 × 安全性当 Coding Agent 真正进入开发流程组织最终关心的不是“它偶尔能不能惊艳地完成一个难题”而是“在大量日常工作中它能否以可预测成本、可审查过程和可接受风险稳定完成任务”。这也是为什么下一阶段的 Agent 评测必然从单一榜单走向系统工程任务要更真实环境要可重放Harness 要被显式记录验证器要足够强统计要反映随机性成本和风险要进入主表失败轨迹要能被复盘。当这些条件具备时Benchmark 才不再只是一场模型竞赛而会成为组织决定“哪些工作可以真正交给 Agent”的基础设施。可参考文章与官方资料DeepSWE 官方网站Long-Horizon Software Engineering BenchmarkDeepSWE 论文Measuring Frontier Coding Agents on Original, Long-Horizon Engineering TasksTerminal-Bench 2.1 官方仓库Terminal-Bench 论文Benchmarking Agents on Hard, Realistic Tasks in Command Line InterfacesFrontierSWE 官方仓库FrontierSWE 官方评分说明Kimi K3 技术报告ProgramBench 官方网站ProgramBench 论文Can Language Models Rebuild Programs From Scratch?SWE-Marathon 论文Can Agents Autonomously Complete Ultra-Long-Horizon Software Work?SWE-Marathon 官方代码仓库Terminal-Bench 2.1 官方排行榜与运行说明