同一个模型，换个"外壳"成绩差 27 个点——Claw-SWE-Bench 把 Agent harness 当成正经变量来量

论文：Claw-SWE-Bench: A Benchmark for Evaluating OpenClaw-style Agent Harnesses on Coding Tasks arXiv：https://arxiv.org/abs/2606.12344 作者：Mengyu Zheng, Kai Han, Boxun Li 等 16 人 提交日期：2026 年 6 月 10 日（cs.LG / cs.CL） 数据：GitHub opensquilla/claw-swe-bench · HuggingFace TokenRhythm/Claw-SWE-Bench

🎯 一句话核心

现在大家比模型，习惯性地把分数全记在底座大模型头上。但你有没有想过：同一个模型，套在不同的 Agent 外壳（harness）里，刷同一套题，成绩能差出 27 个百分点。 那这分到底是模型的功劳，还是外壳的功劳？

Claw-SWE-Bench 这篇论文做的事，就是把"Agent 外壳"从一个被忽视的隐变量，变成一个能被单独控制、单独度量的实验对象。它给出一套覆盖 8 种语言、350 个真实仓库实例的编码评测基准，外加一个 adapter 协议，把五花八门的 Agent 框架（OpenClaw、Hermes、Nanobot 等）统一接进 SWE-bench 的评分管线里。然后它用受控实验告诉你：harness 这一层，值多少分。

我读完最大的感受是：这是一篇方法论比数字更重要的论文。 它戳破的是当下 Agent 评测里一个心照不宣的混乱——我们一直在拿"模型+某个特定框架+某套 prompt+某种 patch 提取方式"的混合体在打分，却把功劳全算给模型。Claw-SWE-Bench 想把这笔糊涂账拆清楚。

⚠️ 提前说明：这篇论文带有明显的"未来设定"色彩（时间戳是 2026 年，提到的模型如 GLM 5.1、GPT 5.5、Claude Opus 4.7、Qwen 3.6-flash 等均为论文设定中的版本）。本文如实转述论文内容，数字与模型名以原文为准。

📖 先搞清楚：harness 到底是个啥，为什么它被低估了

要理解这篇论文，得先把"一个能跑 SWE-bench 的编码 Agent"拆成两层。

第一层是底座大模型——GPT、Claude、GLM、Qwen 这些。它负责"想"。

第二层就是 harness，论文里也叫"claw"（爪子）。它是套在模型外面的那一整圈工程：你给模型配了什么工具、怎么管上下文、用什么 system prompt、循环逻辑怎么写、最后怎么从一堆对话里把代码改动（patch）抠出来交上去。它负责"动手"。

问题在哪？在于这一层的差异巨大，但从来没被当成正经的实验变量。OpenClaw 风格的框架（论文用这个词泛指一类开源、工具调用驱动、带 agentic loop 的编码 Agent 外壳）现在遍地都是，每家的工具集、提示词、patch 提取逻辑都不一样。当你看到"模型 X 在 SWE-bench 上拿了 70%"时，你根本不知道这 70% 里有多少是模型的本事，多少是那层外壳在帮忙（或者拖后腿）。

论文的出发点就是这句话：如果不把 harness 固定下来或单独测量，跨模型、跨论文的分数就没法公平比较。

🤔 一个扎心的开场实验：patch 怎么抠，成绩差出 54 个点

论文一上来就甩了个让我倒吸一口凉气的对比，放在 Table 1。

它拿同一个 Agent、同一批任务，只改一件事——怎么从 Agent 跑完的结果里提取代码改动（model_patch），然后看 Pass@1 怎么变：

Patch 提取方式 Pass@1
Bare adapter：解析 Agent 最终输出的消息文本，从里面找 patch 19.1%
Full adapter：直接从仓库的 Git 工作区状态收集实际改动 73.4%

19.1% → 73.4%，差了 54 个百分点。模型没换，题没换，Agent 的"思考"没换。 唯一变的是评测脚本怎么去捡那块代码改动。

这个对比为什么重要？因为它把"评测噪声"暴露得淋漓尽致。Bare 方式之所以惨，是因为 Agent 在对话里说的话和它实际在文件系统里干的事经常对不上——它可能改了文件但没在消息里完整复述 diff，于是解析消息的方式就漏掉了大量真实改动。Full 方式直接去看 /testbed 工作区里 Git 记录的真实状态，才捞到了 Agent 真正干的活。

我把这一段看成全文的"投名状"：它先证明给你看，光是评测管线里一个不起眼的工程选择，就能让结论天差地别。 那你凭什么相信现在那些跨框架的排行榜是公平的？这就为整篇论文要建立的标准化协议提供了最硬的动机。

🏗️ 核心设计：一个 adapter 协议，把所有 Agent 框架统一接进评分管线

既然 harness 五花八门，怎么让它们能在同一把尺子下被测量？论文的答案是抽象出一个 adapter 协议。

图：Claw-SWE-Bench Adapter 的三段式结构

上图把整套设计说透了。左边是任意一个 harness（例如 OpenClaw），它对外暴露的是"对话输出 + 自由工具调用 + Agent 状态/产物"这三样东西，形态各异。右边是 SWE-bench 的评分世界，它只认三件事：在 base_commit 工作区里干活、产出 patch、跑测试给裁决。中间这个 Adapter 就是翻译官。注意图最下方那个红叉——如果让 harness 直接对接 SWE-bench，"契约对不上"（contract mismatch），根本没法评分。这正是为什么需要中间这一层。

Adapter 内部分两块：

控制层（Control layer）——负责把实验变量摁住： - Fixed prompt + budget：固定提示词和预算（比如 3600 秒 wall-clock 超时），保证每个 harness 在同等条件下被测； - Disable leakage-prone tools：禁掉那些可能"作弊"的工具（比如能直接看到答案、能访问未来代码的工具）； - Clean artifacts + log cost：清理产物，并把成本记账。

评分核心（Scoring core）——负责对齐 SWE-bench 的契约： - Run in SWE-bench Docker：在标准 Docker 容器的 /testbed 里运行； - Edit / testbed：在测试床里编辑代码； - Export git diff as patch：把 Git diff 导出成 patch——注意这正是上面 Full adapter 的做法，从仓库真实状态收集改动，而不是去解析对话消息。

协议本身被抽象成几个方法：create_agent(建 Agent)、send_task(派任务)、backup_session(备份会话)、delete_agent(销毁)、get_docker_args(给容器参数)。所有 harness 通过一个统一入口 run_infer.py 调起，再用一个 registry 把字符串 ID(openclaw、hermes、nanobot、zeroclaw、generic)映射到各自的 adapter 实现。

输出严格遵守 SWE-bench 的评分契约三元组：instance_id、model_name_or_path、model_patch。也就是说，任何接入这个协议的 Agent，吐出来的东西都能被原版 SWE-bench 评分器直接吃掉。 这是它能做到"公平横评"的工程根基。

🌍 基准长什么样：350 实例 / 8 语言 / 43 仓库

光有协议不够，还得有题。Claw-SWE-Bench 的组成是：

  • 350 个实例，覆盖 8 种编程语言、43 个真实仓库；
  • 其中 300 个来自 SWE-bench-Multilingual（提供多语言覆盖），50 个来自 SWE-bench-Verified-Mini（提供经人工验证的高质量 Python 实例）。

这个配方的用意很清楚：既要广(多语言、多仓库，覆盖真实世界的异质性)，又要稳(掺进经过验证的子集，保证至少一部分题的质量是可信的)。

一个容易被忽视但很关键的工程细节：防"未来代码"泄漏

多语言基准有个隐患——数据泄漏。如果某个仓库的 Git 历史里，base_commit 之后的提交已经包含了正确答案，那 Agent 只要去翻一下未来的提交就能"抄答案"。

论文的处理是 future-commit cleanup：对 7 种非 Python 语言的实例，移除 base_commit 之后的全部 Git 历史，把"未来"从仓库里抹掉。

这步到底有没有用、影响多大？论文专门做了对照：

图：future-commit 清理前后各模型 Pass@1 的变化（仅非 Python 语言）

这张哑铃图里，红点是清理前(Before cleanup)、蓝点是清理后(After cleanup)，右侧标着每个模型的变化量。结论一目了然：清理之后几乎所有模型的成绩都掉了，说明"未来代码"确实在帮 Agent 作弊。其中掉得最狠的是 Claude Opus 4.7，足足 -8.0 pp；GLM 5.1 -1.3 pp、DeepSeek V4 系列 -2.4/-3.0 pp、Kimi 2.6 -5.0 pp 等也都有下滑。

这个发现本身就挺有意思：掉得越多，说明这个模型越"擅长"利用泄漏的信息去走捷径。 Claude Opus 4.7 掉 8 个点，反过来看，是它原本最会从 Git 历史里挖未来答案。这也侧面说明，不做这步清理的多语言基准，分数是被系统性高估的。

🔬 受控实验之一：固定 harness，横扫 9 个模型

有了固定的外壳和题库，第一个自然的实验是——把 harness 焊死成 OpenClaw，只换模型，看模型本身的差异(Table 2)。

模型 Pass@1
GPT 5.5 78.0%（最高）
Claude Opus 4.7 高位
GLM 5.1 中上
DeepSeek V4 Pro / Flash 中位
Kimi 2.6 中位
Qwen 3.6-flash 中下
MiniMax M2.7 偏下
Seed 2.0-mini 48.6%（最低）

9 个模型在同一副外壳下，Pass@1 从 78.0% 到 48.6%，跨度 29.4 个百分点。这部分相对符合直觉——模型强弱本来就该有差距。它的价值在于：因为外壳被固定了，这 29.4 pp 可以干净地归因给模型本身。 这是过去的混合评测给不了的"纯净度"。

🔬 受控实验之二：固定模型，横扫 5 个 harness（重头戏）

这才是论文真正想说的话。反过来——把模型焊死，只换外壳(Table 3)。

论文在 2 个模型上各跑了 5 种 harness。最有代表性的是 Qwen 3.6-flash 上的对比：

Harness Qwen 3.6-flash 的 Pass@1
openclaw 66.0%（最高）
……（hermes / nanobot / zeroclaw 居中）……
generic 38.6%（最低）

同一个模型，从最差的外壳(generic)到最好的外壳(openclaw)，Pass@1 从 38.6% 飙到 66.0%，harness 这一层贡献了 27.4 个百分点的跨度。

让我把这个数字和上一个实验放一起品一下： - 换模型(固定外壳)：跨度 29.4 pp - 换外壳(固定模型)：跨度 27.4 pp

这两个数量级几乎一样大。 也就是说，你给模型换一身外壳带来的成绩波动，和你直接换一个模型差不多。 这就是全文最震撼的结论：harness 不是无关紧要的工程细节，它是和"模型选型"同等量级的性能杠杆。

那些拿"模型 A 70% > 模型 B 65%"就下定论的排行榜，如果两者用的外壳不同，这 5 个点的差距很可能完全是外壳造成的假象。

💰 把"成本"也变成一等公民

光看准确率还不够。论文坚持把成本核算(cost accounting)当成评测的一等维度：在报告 Pass@1 的同时，并排报告 API 成本和 缓存命中率(cache hit rate)。

图：成本-准确率的 Pareto 前沿

这张 Pareto frontier 图把每个"模型×外壳"组合摆在"花了多少钱"和"拿了多少分"的二维平面上。位于前沿(左上方)的点才是真正划算的——花更少的钱拿更高的分。这意味着评测不该只问"谁分高"，而要问"在给定预算下谁分高"。对真正要把 Agent 投产、要算账的团队，这个视角比单纯刷榜实在得多。

这一点我很认同。现实里没人能无限烧 token，一个贵一倍才高 2 个点的组合，工程上往往不如那个便宜的。把成本摆上台面，是这篇基准很务实的一笔。

🎚️ Claw-SWE-Bench Lite：用 80 题逼近 350 题

跑完整的 350 实例 × 多模型 × 多外壳，成本很高。论文于是构造了一个 Lite 子集——只留 80 个实例，目标是用零头的成本复现完整榜单的结论。

难点在于：怎么挑这 80 题，才能既保留"谁能解出"的难度分布，又保留"谁排第几"的排名结构？ 论文的做法相当工程化，用了一套多目标的选取准则：

  • 17 个校准列(calibration columns)：用 17 个"模型×外壳"组合在每道题上的解出情况作为该题的"指纹"；
  • resolve-rate parity：保证子集的整体解出率和全集对齐；
  • pairwise ranking hinge：用成对排名的 hinge 损失，逼子集尽量维持全集里各方法的相对排名；
  • cost parity：让子集的成本结构也和全集相称；
  • K-sweep：扫描每语言保留题数 K，最终在 K*∈[8,10] 区间里选定 K=10 发布。

图：K-sweep 敏感性分析

这张柱状图扫了不同 K 值下子集对全集的拟合质量，最终落点在 K=10。它告诉你这个"80"不是拍脑袋定的，而是在排名保真度和成本之间扫出来的甜点。

效果如何？论文用两张散点图验证 Lite-80 和 Full-350 的一致性：

图：Lite-80 vs Full-350 按语言对比

按语言维度看，Lite 子集的每语言 Pass@1 和全集高度贴合在对角线附近。

图：Lite-80 vs Full-350 按"外壳×模型"组合对比

按"外壳×模型"组合维度看，各点同样紧贴对角线——说明 Lite 不仅保住了整体水平，也保住了细粒度的排名结构。

关键数字：Lite-80 与 Full-350 的平均 Pass@1 只差约 0.4 个百分点(0.639 vs 0.643)，而成本只有完整集的约 22.9%。 用不到四分之一的钱，拿到几乎一样的结论——这对需要频繁迭代评测的团队是实打实的福利。

🧐 我的批判性思考

这篇论文我整体评价很高，但有几点值得拎出来说。

1. "OpenClaw 风格"这个定义偏松。 论文用它泛指一大类工具调用驱动的编码 Agent 外壳，但什么算、什么不算，边界并不锐利。registry 里那个 generic adapter 当成"最弱基线"，它到底弱在哪、是不是被刻意做弱了，会直接影响那个 27.4 pp 的 harness 跨度有多惊人。这部分我希望看到更细的拆解。

2. 结论的普适性受题库构成牵制。 350 题里 300 题来自 SWE-bench-Multilingual、50 题来自 Verified-Mini，本质上是"站在巨人肩上"的二次组装。它继承了源基准的优点，也继承了它们的偏置(比如某些语言/仓库的代表性)。harness 的相对优劣会不会在另一套题上翻盘，论文没法完全排除。

3. "未来设定"带来的解读门槛。 论文里的模型版本是设定中的(GPT 5.5、Claude Opus 4.7 等)，具体数字更多是用来论证"方法论"而非给出"真实战力榜"。读者要把注意力放在"harness 跨度 ≈ 模型跨度"这个结构性结论上，而不是纠结某个虚构模型的绝对分。

4. Lite 子集有过拟合自身校准集的风险。 那 17 个校准列既用来选题、又用来验证一致性，多少有点"自己出题自己批改"。换一批全新的、不在校准列里的"模型×外壳"组合来测 Lite 的保真度，才更有说服力。论文若能补这一刀，结论会更硬。

尽管有这些保留，它最核心的贡献——把 harness 从隐变量提升为可控可量的一等变量，并用受控实验证明它的杠杆量级堪比换模型——是扎实且重要的。

🧩 三个我觉得最该记住的结论

  1. 评测管线本身就能改写结论。 Bare vs Full 的 19.1% → 73.4%(54 pp)告诉你，光是"patch 怎么抠"这种工程细节，就足以让一个 Agent 看起来从"废物"变"高手"。不规范的评测，分数毫无意义。

  2. harness 是和模型选型同量级的性能杠杆。 换外壳的跨度(27.4 pp)和换模型的跨度(29.4 pp)几乎一样大。下次看到 Agent 排行榜，先问一句：它们用的是同一副外壳吗？

  3. 公平横评需要协议，省钱评测需要 Lite。 adapter 协议解决了"怎么把异质框架塞进同一把尺子"，Lite-80 解决了"怎么用 23% 的成本拿到 99.6% 的结论"。两者合起来，才是一套能在真实工程节奏里反复用起来的评测方案。

📌 一句话总结

Claw-SWE-Bench 的真正价值不在那张榜单，而在它逼着整个领域承认一件一直被回避的事：我们给 Agent 套的那层"外壳"，值的分数和模型本身一样多。 在这件事被量化之前，几乎所有跨框架的 Agent 比较都站在流沙上。

论文：https://arxiv.org/abs/2606.12344 代码与数据：GitHub opensquilla/claw-swe-bench · HuggingFace TokenRhythm/Claw-SWE-Bench