榜单上的分数量的不是模型，是整套脚手架

本文是立场论文 Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering（arXiv:2606.17799）的中文译文，由智测团队翻译。作者来自伦敦 Tessl。会议是与 KDD 2026 同期的 Agentic Software Engineering（SE 3.0）研讨会，2026 年 8 月 9–13 日，韩国济州。参考文献未逐条展开。这是立场文，不是新实验。文中的榜单数字引自别人的报告。

摘要

编码智能体已经成为软件工程的一种主要方式。但用来比较它们的基准，是在智能体时代之前设计的：把模型、脚手架和环境收成一个端到端分数，通常对照一份参考解来算，而且没有可供迭代的组件级信号。作者认为，当前编码基准与智能体软件工程错位。实践里的编码智能体不是一个模型，而是一套系统脚手架：模型、脚手架、上下文、环境和反馈信号的组合。其中任何一项，都能把基准分数移动到与相邻两代模型之间相当的幅度。三个症状是：（i）基准分数把模型和脚手架的其余部分混在一起；（ii）对照单一参考解打分，会惩罚同样合法的替代方案；（iii）单个脚手架组件没有信号，端到端分数难以用来迭代。

1 引言

编码智能体现在是软件工程的一种主要方式。它们开拉取请求、合并拉取请求、写内部库，并越来越多地在人的监督下承担多日的工程工作。它们是复合系统：大语言模型处在工具使用循环里，外面还有脚手架、环境和上下文。这些组件中的每一个，都能把端到端基准分数移动到与相邻模型代际之间相当的幅度。

用来比较它们的基准，针对的是更早的研究对象：大模型能否一次生成能工作的代码。SWE-Bench、HumanEval、MBPP、LiveCodeBench 和 BigCodeBench 结构相同：一个模型、一套脚手架、一个环境，一起产出一个数字。这是没有组件级信号的端到端系统分数，而且常常对照一份参考解来比。

基准的选择不是中性的。它隐含地塑造方法如何被评判、哪些研究方向被追，即便基准只部分抓住真正关心的单元。

作者的立场是：当前编码基准与智能体软件工程错位。它们只给所建造之物的一小部分打分，而且对照的是我们并不想要的构念。补上缺口，需要围绕智能体系统的结构来设计基准，而不是围绕个别参考解。这样的基准会把智能体当成它所是的复合系统，在单个组件上露出信号，并把正确性建立在独立的行为规格上，而不是任何一份参考解上。这个计划里最难的开放问题是操作化：用可以测量的语言规定我们要系统做什么，同时不编码智能体应该怎样去尝试。

2 系统脚手架

图 1 是编码智能体周围的系统脚手架。黄色是脚手架修改或产出的组件。外面是它读取但不控制的东西。反馈信号分成内环、中环和外环；每一环又分成智能体可控的（脚手架可以改写检查）和外部的（拉取请求评论、生产结果）。

编码智能体不是模型。它是系统脚手架的一部分。系统脚手架是围绕一个或多个大模型的编排层，随时间管理任务、环境和反馈。作者区分两层编排。智能体脚手架是一个语言模型与工具交互，朝单一任务工作，带有系统提示和可抽取的上下文。大多数被称为「编码智能体」的制品都是这个意义上的智能体脚手架：Claude Code、Codex、Cursor Agent、SWE-Agent、OpenHands，以及许多其他。系统脚手架是外层编排：把更高层目标变成具体任务，把每个任务派给一个或多个智能体脚手架，管理它们所作用的环境，并把输出送进近似「工作是否可接受」的反馈。规模化的实际智能体编码，运作在系统脚手架这一层。当前编码基准运作在智能体脚手架这一层。近期例子包括 Symphony 和 GasCity。作者还建造并开源了 NS2（https://github.com/drufball/ns2），一个由 Issue 驱动的系统脚手架，在一叠确定性和由智能体仲裁的检查之下，跑一个四工具的智能体循环。在 NS2 里，GitHub Issue 是协调原语：产品经理智能体把一个功能 Issue 分解成纵向切片的子 Issue；软件工程智能体在隔离会话里实现这些 Issue；评审、测试质量、冒烟测试和拉取请求构建智能体消费 Issue 和拉取请求事件，决定工作应该前进、修订，还是写成供评审的描述。建造和运行 NS2，暴露了本文所表述的许多错位。许多脚手架，包括 NS2，把问题跟踪器当作工作的持久状态机，并为每个任务派生智能体会话。

系统脚手架有五个反复出现的组件。（i）任务：从更高层目标导出的工作单元。（ii）一个或多个智能体脚手架：由模型、提示、工具和循环组成的可配置执行器，系统脚手架可以调它，也可以当黑盒。（iii）环境：正在被改的仓库和运行时，以及集成的外部服务（问题跟踪器、持续集成、部署面）。（iv）上下文：环境和脚手架所写材料的一份策展投影，包括技能、插件、钩子、规格，载入某一次调用。（v）反馈信号：脚手架用来精炼解或精炼自身的任何东西，包括测试、类型、lint、形式验证、大模型当裁判的量规、拉取请求评论、评审者批评、生产事故，以及更长程的业务信号。在反馈之内，验证器是适合用来阻断的严格子集，返回通过或失败：测试、类型检查、lint 和二值量规。更宽的反馈还包括告知而非设门的定性评审和结果信号。

反馈按范围、延迟和信任分三档。内环信号（秒到分钟：测试、类型、lint、编译）快而便宜，但窄。它们在单次变更尝试内部运作，通常在提交或拉取请求范围，立刻告诉智能体当前编辑是否可执行、类型是否正确、是否符合策略、是否值得再迭代。中环信号（分钟到小时：评审者要求、模拟、维护智能体、评分量规）在更宽的工作切片上汇总。维护智能体是按计划或按需运行的智能体，检查项目、拉取请求或智能体轨迹，然后提交或实现反复出现的质量改进。中环信号抓住对单元测试来说太宽或太依赖判断的性质：反复出现的评审批评、偏离项目约定、重复的抽象、日志里可见的智能体低效，或一次维护运行前后的健康指标。外环信号（天到周：拉取请求接受、回滚率、事故报告、客户反馈）最接近地面真值，但延迟且混杂。它们测量发出去的工作是否经受住了人的评审、生产和使用，往往不能干净地归因到一次提示、一个任务或一处改动。有生产力的系统脚手架三者都用：内环在循环里精炼解，中环露出反复出现的问题和质量漂移，外环校准哪些内环和中环代理值得信任。中环信号有用，是当它们预测或改善外环结果，例如更少回滚、更少评审轮次，或更低的人干预率。

另一条正交的轴，区分脚手架能改的信号（例如测试）和不能改的信号（人的拉取请求评论、业务结果）。所有信号都可以参与脚手架的自我改进循环：积累的日志和反复失败反馈进脚手架自己的组件。NS2 说明这个模式：极严格的 lint、覆盖率阈值和依赖图单元测试是内环严格验证器；变异测试、LCOM 内聚检查，以及每日的智能体架构评审和测试质量评审是中环反馈；冒烟测试智能体的摩擦报告、合并后的回滚信号和生产事故是外环反馈。智能体自己编写并维护约束它的 lint 规则和量规。

3 相关工作

作者用第 2 节的系统脚手架来读现有的编码智能体评测。

编码基准分两族。第一族用隐藏测试给短的、自包含的问题打分：HumanEval、MBPP、带污染控制的 LiveCodeBench、BigCodeBench。它们设计时，被测制品是模型，正确地对准智能体脚手架里的模型组件。它们不是为区分系统脚手架而设计的。第二族给真实仓库上的补丁打分。SWE-Bench 要求智能体的补丁让留出的 FAIL_TO_PASS 集合通过，同时保持 PASS_TO_PASS 集合通过。两套测试都从原始拉取请求导出，这个构造在第 4.2 节会回到。基准后来针对不同缺点迭代：Verified 策展 500 个经人工核验的任务；Multimodal 加入视觉领域；Pro 用经人工核验的任务拓宽任务时程和语言覆盖，OpenAI 现在推荐用它代替 Verified。SWE-rebench 用规模换掉人工核验，在 20 种语言上生成 3.2 万个以上的任务。超出修 Issue 的形状之后，Terminal-Bench 把评测扩到终端任务（通常 1 到 20 分钟），并成为事实上的前沿报告标准。Frontier-SWE 对准超长时程表现和机器学习研究挑战。相邻套件包括 SWE-Lancer、RE-Bench、MLE-bench、τ-bench、AgentBench 和 Aider 多语言基准。这些基准在任务领域、时间时程和验证器形状上不同，但设置相同：智能体配一个固定的环境和验证器，报告单一的端到端通过率。用第 2 节的语言，系统脚手架的其余部分被折进协议，而不是被当作受测制品的一部分。

效度与基准–部署缺口。近期论文暴露 SWE-Bench 式设置的效度问题。SWE-Bench+ 记录 Issue 文本里的解答泄漏，以及在薄弱测试下的通过。Liang 等人报告与记忆一致的文件定位行为。Wang 等人用差分测试表明，已解决补丁中有 7.8% 通不过开发者写的测试，29.6% 与黄金补丁的行为分叉。Whitfill 等人发现，许多已解决补丁在普通维护者评审下不会被合并。Li 等人在另一端测量缺口：61,000 个仓库里 456,000 个由智能体撰写的拉取请求，真实接受率是 35% 到 64%，远低于 Verified 上超过 70% 的头条数字。他们的 AIDev 数据集的用处超出它所记录的缺口。因为它来自活的仓库而不是策展基准，可以报告接受、评审周转和代码复杂度，而不是单一通过率，这更接近作者主张的测量。另一条工作开始把脚手架本身当作测量对象。Fan 等人报告，同一脚手架在不同底模上的词元预算有效性相差 3 到 7 倍，并得出有效性是脚手架与模型集成的性质，不是任一组件单独的性质。SkillsBench 测量可归因于智能体技能的提升。Meta-Harness 把脚手架当作优化对象，用外层提议者搜索脚手架代码空间。作者的立场与这条轨迹一致：如果脚手架是制品，就应该测量脚手架。

智能体软件工程。一门智能体软件工程学科的框架正在并行成形。Hassan 等人呼吁围绕结构化的人–智能体协作做「SE 3.0」研究路线图，用合并就绪包替换「测试通过即成功」——「只通过测试已经不够」。作者的论证是测量上的对应物：如果制品是复合系统，基准就必须给复合系统打分。他们借助把评测当成测量问题的工作。Wallach 等人认为评测生成式人工智能是社会科学的测量挑战，区分构念（例如「解决了缺陷」）和操作化（如何测量）。Jacobs 和 Wallach 形式化一项测量要对其构念有信息量所必须满足的效度链。第 4 节直接使用这套语言：单一参考锚定（第 4.2 节）是内容效度主张；把一捆东西混在一起（第 4.1 节）是判别效度主张。一个分不开模型和脚手架的基准，是在测量某种东西，但不是它所标注的那个东西。

4 错位的三个症状

4.1 把模型和脚手架混在一起

表 1 是 Terminal-Bench 榜单上的条目，同一模型 Claude Opus 4.6，在固定任务分布上、跨不同智能体脚手架的成功率。在固定任务分布内，成功率可以相差 20 个百分点或更多，幅度与模型代际之间的差别相当。

这种混淆不是新的。Dehghani 等人对非智能体基准做过密切相关的论述，SWE-Bench 社区此后也逐步重新发现它。作者的立场是：这一点还没有被充分落实。不作为的代价变大了，因为模型只是实践中所用之物的一小部分。补救很可能需要在基准层面做结构改变，而不只是个人小心。

Terminal-Bench 是容器环境里的终端任务基准。每个任务给智能体一条英文指令、一个沙箱环境和隐藏测试。解决它需要普通的终端工作：检查文件、跑命令、调试失败、编辑代码或配置、从中间错误里恢复。在这个固定任务分布上，脚手架之间出现 20 个百分点或更多的差别。从业者报告，Claude Opus 4.5 在 SWE-Bench Verified 上，标准化脚手架和定制脚手架之间有 4 到 10 个百分点的摆动。OpenHands 脚手架用可比模型达到 77.6%，而这些模型在标准化的 mini-SWE-Agent 脚手架下低好几个点。效应不只是相加。Fan 等人报告，有效性「不是脚手架的固有性质」，它从脚手架如何与底模集成中涌现；在固定脚手架下换模型，解决率移动 2 到 3 倍。在超过 20 万次 SWE-Bench 运行上，AI21 发现，编排选择、容器分配和评测种子，在模型和脚手架都固定时仍会实质移动通过率。Anthropic 报告其自身评测流水线里也有类似的基础设施级噪声。

各行的模型是固定的，所以散布不能解释成模型能力差异。它表明智能体脚手架——提示、工具接口、动作循环、环境处理、重试行为，以及使用终端的约定——是被测对象的一部分。模型也可能在特定工具使用约定下被训练或调过，因此脚手架在任何任务专用推理开始之前，就可以和模型匹配得好或差。另一个规定不足的变量是推理努力：有些模型接口让调用方直接改变产生答案所用的推理计算量，在彻底性与速度、成本之间权衡，包括跨工具调用。改这个设置，即使模型名和智能体代码名义上不变，也能移动输出质量。

尽管如此，近期工作仍常常发表单脚手架、单数字的比较。结果被归到模型头上，而它是智能体脚手架和环境作为整体的性质。模型只是若干组件之一。「模型 M 在 SWE-Bench Verified 上 65%」这种榜单条目，并不能告知 M 在不同脚手架或环境下会不会解决给定测试。比较两个这样的数字，是在比较两个系统，不是两个模型。端到端数字是有信息的，但作者主张它们规定不足，而且被测量的单元不是实践中被使用的单元。

建议的补救是结构性的，不是方法学上的小修。榜单维护者和基准管理者应要求提交时带上相关元数据：用了什么模型、智能体脚手架版本、环境哈希和数据集版本。此外，提交应至少包含一次沿非模型轴、对照固定基线的消融。

4.2 锚定在单一参考解上

许多编码基准按解与单一参考的接近程度打分。对智能体工作，SWE-Bench 是典型：FAIL_TO_PASS 和 PASS_TO_PASS 从原始拉取请求改过的测试文件导出，编码了一种特定分解——哪些函数存在、它们的签名等等。一个智能体若用不同抽象层次重述接口来解决不稳定测试，被评判的不是缺陷是否修好，而是参考测试是否仍然成立。用测量的语言，补丁是构念的代理。

这种打分只有在任务规定得足够紧、智能体除了做出与参考解相同的实现决策之外别无选择时，才公平。实践里，工作很少这么紧，也很少只是修缺陷：开发者让智能体定义接口、升级依赖、演化抽象，或在架构形状之间选择。从业者一致把规格质量而不是模型能力认成主要瓶颈。相比之下，SWE-Bench 实例是按可处理性挑选的：每条都有清楚提交的 Issue 和干净合并的补丁。基准因此双重锚定：输出对照参考补丁打分，输入也被预选到「问题陈述良好」的标准。

这个构造也嵌入已知弱点。Aleithan 等人报告 Issue 文本里 32.67% 的解答泄漏，以及在不充分测试下 31.08% 的通过。Wang 等人用差分测试表明，已解决补丁中 7.8% 通不过开发者写的测试，29.6% 与黄金补丁的运行时行为分叉。Liang 等人记录与记忆一致的文件定位。

更深的问题是，单一参考打分既弄错了构念，也弄错了粒度。参考编码的是许多解中的一个。我们要的是能重构、重排结构、并在合理替代方案之间选择的智能体。在编译器优化或内核自动调优这类窄领域，还要找到参考补丁没有编码的形状。单一参考打分的缺点在更广的机器学习里已经确立。

隐藏的单元测试也只给局部行为打分。它们看不见好代码和能工作的代码之间的差别：抽象的选择、架构契合、系统设计。智能体可以每个测试都过，同时把代码库改到评审者一眼就会拒绝的程度。方法上的转向是：不按与某个特定解的接近程度打分，而按更宽的功能正确性定义，以及设计级质量来打分。代码被复用而不是复制，新抽象遵循项目约定，依赖图保持健全。这些是不变量：应在许多候选解上成立，也应在同一代码库的许多拉取请求上成立。近期从业者工作朝这个方向走：技能遵循评测对照单独撰写的策略打分；抽象遵循检查验证结构性质，而不规定实现；ProgramBench 用智能体生成的行为测试打分，而不是比较源码。三者都把验证器与任何特定候选解解开。剩下的工作是表述：把不变量写成可以可靠打分的量规，并选择这些不变量适用的任务。作者主张，这是智能体编码评测的中心开放问题：用不编码「如何做」的语言，规定我们要系统做什么。

建议的补救：用允许多种形状的行为验证器替换从单一参考导出的测试集，例如性质测试、参考预言，或对照替代实现的差分测试。若仍保留单一黄金补丁，应声明哪些行为是必需的，哪些只是参考实现的附带物。

4.3 没有组件级信号

在单个基准任务上的端到端智能体运行可以花数小时，但每个任务只产出少量信号。如第 2 节所见，现代智能体系统有许多组件，每个都影响总体结果。例如 OpenAI 描述的那套，或 NS2 及其 lint、依赖图单元测试、变异测试、智能体评审者和冒烟测试智能体。若一个组件失败，端到端任务的评测会抓住失败，但不一定能说出是哪个组件坏了。要决定如何改进整体脚手架，可能只好做消融实验，使改进循环更费时。

朝自主系统建造的从业者描述一个持续改进循环：失败必须在组件级诊断和修复，组件是上下文、工具、验证器或任务分解。端到端分数表明有东西失败了，但不说该修什么。没有组件级信号，这个循环退化成靠直觉的消融。如果脚手架是组件的组合，就应争取分开评组件。这与把软件测试分成单元测试和集成测试是同一逻辑：集成测试更忠实地反映部署，但不说哪个组件坏了。

近期评测工作在任务一侧朝这个方向走。Ribeiro 等人把任务分解成带单元式断言的能力。Dehghani 等人表明，汇总分数掩盖了哪些任务在驱动排名。但受测系统仍是黑盒。同样的分解应适用于系统本身：每个组件既单独评，也在组合里评。

智能体系统的组件级评测很稀少，编码尤其如此。只评大模型的基准（例如一次生成代码）实际上评的是模型组件。少数技术把技能当作独立上下文来评。相邻文献开始对准单个组件：PEEK 按长上下文聚合和上下文学习给智能体打分，而不是端到端完成，把定向知识当成可评测的制品。DecisionBench 评智能体把子任务委派给一池模型的好坏。两者都不直接对准编码，但都说明那种形状：其余脚手架保持不变的逐组件验证器。有些脚手架组件本身就是别人的评测目标：在 NS2 里，变异测试评单元测试套件的质量，智能体式的 lint 质量评审评 lint 配置。脚手架组件形成一叠「验证器的验证器」。只报告端到端通过率，把这叠东西压平了。

建议的补救：把图 1 的组件本身当成评测目标，回答诸如「上下文对帮助智能体有多有效」「智能体遵循约定不变量有多好」「智能体把策略转成确定性验证器有多有效」。对维护智能体，报告限定范围内健康指标的前后差值——复杂度、重复、死代码、依赖环，或频繁改动的热点——而不是只看最终拉取请求有没有合并。

5 另一种看法

「端到端分数反映真实使用。」作者同意。他们反对的是只用端到端指标，以及把所得分数当成模型的性质而不是脚手架的性质。在软件工程里，同一个问题已经定论：单元测试和集成测试都要有。

「分解的评测太贵。」当前实践里的主导成本，是把改进归错、并按误导信号选择系统的机会成本。即便部分分解也有帮助：在端到端分数旁边加一个组件级指标，就已经改善信号。

「参考解是合理的黄金标准。」当任务规定得足够紧、参考解是唯一合理形状时，它是。但智能体软件工程的野心比产出能通过的补丁更宽：我们要评设计、抽象选择和架构契合。单一参考补丁不编码这些性质，隐藏测试也看不见。

6 行动呼吁

作者呼吁社区落实第 4 节的三项补救：报告意识到脚手架的元数据；从单一参考测试集转向承认多种合法解形状的验证器；在端到端分数旁边发展组件级评测方法。每一项都可做，但都不平凡。三者之下还有一个更难的问题：如何用自动评分器能应用的语言陈述我们要编码系统做什么，同时不规定如何做？这是 Wallach 等人的操作化缺口用到智能体编码上，也是下一代基准的决定性约束。在它闭合之前，基准会继续按智能体与「关掉那个 Issue 的解」有多像来打分，而野心是让它们做得更好。