背景：评测对象的一次下移
过去两年的智能体评测，绝大多数测的是「给定任务，智能体能不能做对」。这个框架有一个隐含前提：Harness（驱动模型的那层程序）是固定的、可信的、不在评测范围内。现实里这个前提越来越站不住——同一款模型配不同 Harness，分数可以差出两位数；而越来越多的团队开始让智能体改自己的 Harness。
问题接着就来了：如果 Harness 变成被评测的对象，那么评测它的方法必须和评测代码的方法不一样。代码可以用单元测试判断对错，Harness 的行为却分散在「它向模型发了什么请求、它在磁盘上留下了什么、进程以什么码退出、命令输出长什么样」这些可观测信号里，而且很容易出现「看起来通过了但其实什么都没做」的空过。
十月的这三份工作，正好分别从三个方向回应了这个问题：Doc2Harness 负责让 Harness 工程本身变得可评分，HPCAgent-Bench 负责让「加工具、加技能到底值不值」变得可量化，AgentSWE 负责检验智能体造出来的另一个智能体在换条件之后还成不成立。
它们都不再测「智能体当下这一轮表现如何」，而是测「智能体产出的那个东西，脱离了产出它的环境之后，还能不能正常工作」。这个转向带来的直接后果是分数普遍变低——三份基准的最高分没有一个超过 60。这不是退步，而是此前很多高分本来就没测到这一层。
三张考卷：基本参数对照
| 维度 | Doc2Harness | HPCAgent-Bench | AgentSWE |
|---|---|---|---|
| 发布时间 | 2026-10-14（arXiv 2610.20344） | 2026-10-14（arXiv 2610.20673） | 2026-10-09（arXiv） |
| 机构 | 中科院计算所、清华、北大、东南大学 | 苏黎世联邦理工等（Torsten Hoefler 团队） | 北京智源、中科院、中国人民大学 |
| 测什么 | 模型造 Harness 的能力 | 智能体优化代码的效果与成本 | 智能体造、改、优化智能体的泛化能力 |
| 规模 | 19 个模型 × 3 次构建 × 328 用例 | 689 个 kernel，3 条赛道，40 组配对设置 | 25 个任务；主评测 5 模型 × 10 任务 = 50 次 |
| 判分方式 | 四通道可观测信号 + 阳性对照 | 外部裁判对隐藏模糊输入校验并计时 | 冻结交付物后在 6 个未见用例上运行 |
| 最好成绩 | 53.05%（GPT-6 Astra） | 相对自动并行器最高 4.2 倍加速 | 19.1 分（DeepSeek-V4-Pro 配置） |
| 最弱成绩 | 27.44% | 未统一给出单模型末位 | 20 次尝试得 0 分 |
Doc2Harness：两阶段设计与四个可观测通道
Doc2Harness 的设计核心是「把构建环境和运行环境彻底分开」。在构建阶段，一个构建模型在固定的 builder harness 里工作，拿到的是一份只含接口定义的契约骨架，外加一份汇总了十二个前沿 Harness 行为的开发文档，然后在隔离容器里造出一个完整的候选 Harness。第二阶段，这个被冻结的候选 Harness 在与构建环境完全隔离的容器中运行，每个测试用例一个容器，由一个脚本化的 mock 模型端到端驱动。
这两个阶段的分开很关键。如果在同一个容器里既构建又运行，模型可以通过残留文件、环境变量、缓存这些侧信道拿到本不该拿到的信息，评分就失去了意义。分开之后，「这个 Harness 是独立可用的」才成为被测的东西。
评分用四个可观测通道：发给模型的请求、磁盘上的文件、进程退出码、命令输出。选这四个信号的理由很实际——它们都是客观事实，不需要人来判断，也不依赖被测模型自己的陈述。此外还设置了阳性对照，用来排除空过：如果一个候选 Harness 什么都没做却能让测试通过，那这个用例就是无效的，必须被剔除。
十九个模型的成绩单
论文摘要给出：十九个前沿模型，每个以三次独立构建在 328 个测试用例上评估，GPT-6 Astra 以 53.05% 的通过率居首，最弱模型为 27.44%，两端相差约 26 个百分点。论文图 1 给出了十九个模型按强弱排列的通过率柱状图均值。
| 位次 | 模型 | 通过率读数 | 位次 | 模型 | 通过率读数 |
|---|---|---|---|---|---|
| 1 | GPT-6 Astra | 53 | 11 | Kimi K3 | 38 |
| 2 | Opus 5 | 47 | 12 | Opus 4.8 | 38 |
| 3 | Qwen3.8 Max | 46 | 13 | GPT-5.5 | 35 |
| 4 | GPT-5.6-sol | 44 | 14 | Doubao Seed 2.1 Pro | 33 |
| 5 | Grok 4.7 | 44 | 15 | Opus 4.7 | 32 |
| 6 | GLM 5.3 | 42 | 16 | DeepSeek V4 Pro | 32 |
| 7 | MiMo-V2.6-Flash | 42 | 17 | Opus 4.6 | 28 |
| 8 | Step 5 Preview | 41 | 18 | GLM 5.2 | 28 |
| 9 | DeepSeek V4.1 Flash | 40 | 19 | Hy3 | 27 |
| 10 | Hy4 preview | 39 | — | — | — |
需要说明读法：表中数值取自论文图 1 柱状图的均值刻度，为整数读数；摘要给出的精确值为居首 53.05%、末位 27.44%。两者口径一致，精度不同。
这张表里最值得注意的不是谁排在前面，而是整体水位。居首者仍有接近一半的测试用例没通过；而排名第十的 Hy4 preview 与居首者相差 14 个百分点，中间十几个模型挤在 27 到 47 的区间里。换句话说，造 Harness 这件事上，前沿模型之间的差距是连续的，没有出现断档。
另一个可留意的细节是开源与闭源的交错：Qwen3.8 Max、GLM 5.3、MiMo-V2.6-Flash、DeepSeek V4.1 Flash、Kimi K3、Hy3 等开源或开放权重模型分布在中段，与部分闭源模型的分差在个位数以内。这与某些以 API 调用为主的榜单呈现出的格局并不相同。
失败集中在横切功能的模块拆分
论文对失败模式给出了一句判断：即便是居首的模型，也有近一半测试用例失败，且失败集中在横切功能如何跨模块拆分。这句话的含义需要展开一下。
Harness 与一般软件的差别在于，它有一批功能是贯穿所有模块的——上下文管理、权限校验、会话状态、失败恢复、结果校验。这些功能不属于任何一个单独的模块，却要在每个模块里被正确调用。模型在造 Harness 时容易出现的做法，是把这类逻辑复制粘贴到各个模块里，或者干脆在某个模块里实现一份而其它模块用不上。
这个失败模式在工程上很眼熟：它本质上是「架构决策」而非「编码能力」的问题。Doc2Harness 的价值之一，就是把这个此前只能靠 code review 发现的问题变成了可量化的分数。对正在用智能体生成内部工具链的团队，这条结论的直接用途是：让模型造骨架可以，但横切关注点的划分应当先由人给定，而不是指望模型自己收敛。
HPCAgent-Bench：689 个 kernel 与两个新指标
HPCAgent-Bench 针对的是代码优化智能体。它指出既有基准的问题：固定某一种加速器、某一种编程模型或某一个 Harness，因此既无法分离各个组件各自的贡献，也无法判断新增的技能与工具是否值回票价。
它的做法是：689 个 kernel 分三条赛道——循环级优化题、从 HPC 代码中抽取的真实 kernel、机器学习模型；每个 kernel 用 NumPy 描述一次，据此派生 C 与 Fortran 参考实现；提交走统一的 C ABI 或 Python 接口；可以在 CPU 或 GPU 上、单机或多节点运行。防作弊方面，由一个外部裁判在隐藏的模糊输入上校验正确性并计时，堵掉智能体通过探测测试系统来取巧的路径。
| 赛道 | 内容 | 评测关注点 |
|---|---|---|
| 循环级优化 | loop-level optimization challenges | 局部改写是否带来真实加速 |
| HPC 抽取 kernel | kernels extracted from HPC codes | 真实工程代码的优化迁移性 |
| 机器学习模型 | machine-learning models | 跨框架与跨设备的一致性 |
在结果层面，智能体相对自动并行器取得最高 4.2 倍的加速。更值得关注的是迁移性：优化结果换到另一台机器上，不含设备专属代码的答案中有 93% 到 99% 仍然正确，每个 kernel 的加速比保持秩相关 rs 不低于 0.84。这组数字说明智能体给出的优化不是针对某台机器调出来的特例，而是具有可迁移的一般性改进——对 HPC 场景，这一点比绝对加速比更有价值。
干预只两次改变速度，却把成本改动三倍
论文引入的两个指标是这份工作里方法论贡献最实的一部分。
| 指标 | 定义 | 关键读数 | 工程含义 |
|---|---|---|---|
| 干预效能 | 通过配对运行衡量某项干预（如加一个工具）对加速比、成功率、成本的影响 | 40 组配对设置中，只有 2 次对加速比产生显著影响 | 多数「加技能」的动作不改变结果质量 |
| 加权 token 成本 | 在显式权重下报告输入、缓存输入、输出三类 token | 同一批配对设置中，token 成本最多变动 3.0 倍 | 但同样的动作可能大幅改变账单 |
把两个读数放在一起，结论就很直接了：在 40 组配对设置里，加工具、加技能这类干预只有两次真正改变了加速比，却能让 token 成本最多变动三倍。也就是说，多数这类改动买到的不是更好的结果，而是更贵或更便宜的同一结果。
论文还特别强调了一件容易被人忽略的事：token 权重决定了「省下来的钱算不算数」。输入、缓存输入、输出三类 token 的定价差异很大，权重怎么设，直接决定一项优化是否被判定为显著。因此作者明确写出自己使用的权重，并把每一次运行的全部 token 计数一并公开，作为成本报告的标准。这个做法值得所有做智能体成本评测的团队照抄——不公开权重的成本对比，基本无法复核。
AgentSWE：开发期 90 分以上，未见用例 9.9 分
AgentSWE 由北京智源人工智能研究院、中国科学院与中国人民大学的研究者提出，10 月 9 日发布于 arXiv。它把问题设成：编程智能体能不能在不破坏既有功能的前提下，构建、修改和改进别的智能体。
基准包含 25 个任务：10 个要求从零造智能体，10 个要求修改既有系统，5 个考察改进已可用程序的能力。与传统评测的差别在测量对象——它不只看代码有没有生成、开发期测试有没有通过，而是把交付的软件放到未见过的情形里跑，看它是否真的满足规格。
流程上的关键设计是「冻结」：在构建与修改任务中，编程智能体先拿到两个示例来引导开发；开发结束后版本被冻结，再在 6 个开发期未知的额外用例上评估。这道隔离墙正是整套结果的来源。
结果对比相当鲜明：在 11 次成功完成开发的造智能体尝试中，编程系统在开发期拿到 90 分以上的成绩；当这些程序被放到未见过的情形中时，平均分掉到 9.9。
50 次尝试、20 次零分与 58.1% 的无效执行
主评测把 5 个模型配同一个 Codex 编排环境，在 10 个任务上共 50 次尝试。
| 观察项 | 读数 | 口径说明 |
|---|---|---|
| 创建任务平均分 | 11.2 / 100 | 50 次尝试的整体均值 |
| 零分尝试 | 20 / 50 | 占全部尝试的 40% |
| 最佳配置 | DeepSeek-V4-Pro，19.1 分 | 在 10 个任务中有 8 个低于 20 分 |
| 未见执行无效比例 | 157 / 270 = 58.1% | 有日志的未见执行中未通过基本有效性检查 |
| 修改任务缺陷 | 28 / 33 | 产生交付的修改尝试中功能缺失、未执行或不完整 |
| 优化任务 | 13 改善 / 9 变差 / 3 持平（共 25 次） | 结果波动明显 |
| 自述与日志矛盾 | 6 / 42 | 创建任务的最终报告中陈述被开发日志推翻 |
论文给出的 Qwen3.6 案例把机制讲得很清楚。在造一个数据库分析智能体时，系统产出了 2073 行代码，其中识别的表达式是针对所给两个示例专门写死的。开发期分数一度到 99、最终收在 96；但在 6 个未见用例中，全部执行都未通过有效性检查——其中 5 个几乎立刻失败，因为程序不认识请求类型，第 6 个撞上了一个不存在的表引用。
另一类问题更隐蔽：代码看起来结构完整，但关键组件从未真正执行。在一个涉及 OpenWiki 的任务里，某个智能体通过了初始检查，然而五个必需信息类别中有四个是空的。这说明「通过测试」与「功能完整」之间隔着一道必须单独验证的墙。
还有一个对实践最有警示意义的数字：在 42 份可获得的创建任务最终报告中，有 6 份的陈述与开发日志相矛盾。也就是说，任务被标记为完成，并不总对应一次功能可用且经过验证的交付。
三张考卷放在一起看
| 共同设计选择 | 解决的问题 | 在三者中的体现 |
|---|---|---|
| 构建环境与运行环境分离 | 防止侧信道与残留状态影响评分 | Doc2Harness 的两阶段；AgentSWE 的冻结交付 |
| 客观可观测信号判分 | 不依赖被测系统自述 | Doc2Harness 四通道；HPCAgent-Bench 外部裁判计时 |
| 阳性对照 / 有效性检查 | 排除空过 | Doc2Harness 阳性对照；AgentSWE 基本有效性检查 |
| 成本显式化 | 让「值不值」可复核 | HPCAgent-Bench 的加权 token 成本与公开权重 |
| 未见条件复评 | 把泛化从口号变成可测量 | AgentSWE 的 6 个未见用例 |
三者的交集指向同一件事：此前很多智能体评测的分数，测的是「在开发条件下看起来对不对」，而这三份工作测的是「脱离开发条件之后还成不成立」。这个差别不是细节，它决定了分数能不能用来预测生产表现。
读这类榜单的四条检查
- 先看最高分而不是名次：Doc2Harness 居首 53.05%、AgentSWE 最佳 19.1，说明这两件事目前整体没被解决。在这类水位下，几个百分点的高低不足以支撑选型结论。
- 确认判分信号是否客观：依赖模型自述或人工打分的榜单，与用四通道信号、外部裁判的榜单不可直接比较。前者测到的部分能力，后者不会计分。
- 查成本口径是否公开权重：HPCAgent-Bench 的经验是，token 权重决定节省是否显著。没写权重的成本对比，只能当方向看。
- 找「未见条件」那一栏：开发期分数与冻结后分数之间的落差，是这套系统真实泛化能力的近似。AgentSWE 的 90 对 9.9 是最典型的例子。
局限与冷静判断
- 三份均为预印本：Doc2Harness 与 HPCAgent-Bench 于 10 月 14 日提交 arXiv，AgentSWE 于 10 月 9 日发布，均未见同行评议结论，也未见独立第三方复现报告。
- Doc2Harness 的模型名单与分数精度：十九个模型的具体通过率取自论文图 1 的柱状刻度，为整数读数；摘要只给出居首与末位的精确值。中间位次的分差在同一次构建内可能有波动。
- Doc2Harness 只测构建阶段：它评的是模型照文档造 Harness 的能力，不等于「这个 Harness 配上真实模型之后效果好」。第二阶段用的是脚本化 mock 模型，刻意排除了模型能力差异，这既是设计优点也是覆盖边界。
- HPCAgent-Bench 的领域局限：689 个 kernel 集中在高性能计算场景，其结论能否外推到通用业务代码优化，论文未作主张。
- AgentSWE 的样本与运行次数：主评测每个任务与配置的组合只跑一次（补充实验含重复），50 次尝试分布在 10 个任务上，样本量偏小；部分评分依赖评测模型，而这些模型在某些情况下与被测系统同属一个家族，可能引入偏差。
- 9.9 分不宜外推：该分数描述的是「开发期成功完成的那些交付」在未见用例上的表现，不是所有 AI 生成程序的失败率。报道方也明确提示了这一点。
- 三者之间的分数不可横向比较：任务、环境、判分标准均由各自作者定义，把它们放在同一张表里只用于对照设计取向，不代表能力排序。
- 时间窗口很新：三份工作集中出现在十天内，社区复现与批评意见尚未形成，结论应视为阶段性。
综合来看，这三张考卷给出的最好消息不是某个模型排在哪一位，而是「造出来的东西换条件还成不成立」这件事终于有了可重复的测量方法。对工程团队，当下最可执行的三条建议是：横切关注点的模块划分先由人定，不要让模型自己收敛；加工具加技能之前先做配对成本实验，因为多数这类干预不改变结果只改变账单；验收智能体交付物时，一定要在它没见过的用例上复跑一遍，并核对它的自述与日志是否一致。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。