最近沉迷 agent，所以对相关论文和 bench 比较感兴趣。下面这篇是我最近看到的比较炸裂的一篇。
https://arxiv.org/html/2606.12344v1 https://github.com/opensquilla/claw-swe-bench
我的结论很简单：这篇可以看看 bench 设计思路，但是实验结论基本没什么意义。原因也很直接：论文把单次运行、混杂对比和不完整实验网格写成了看起来很确定的结论。作者明知每个组合只跑一次，还在正文里讨论排名、机制和框架优劣，多多少少有点让我脑内自动浮现派大星翻白眼流哈喇子表情包。
这篇论文讨论的是 SWE-bench 类榜单的一个老问题：表格通常只报解决率，但一个系统的分数同时受模型、提示词、工具接口、运行预算、补丁生成方式、停止条件和评测脚本影响。分数变了，读者很难判断变化到底来自模型，还是来自把模型组织成智能体的那套评测框架。
Claw-SWE-Bench 想做的事，就是把评测框架单独作为变量。论文把这类框架叫作 claw，比如 OpenClaw、hermes-agent、zeroclaw、nanobot 和 GenericAgent。这个思路本身不新鲜，类似 HarnessBench 的工作已经在讨论 harness 对结果的影响。这篇的实际贡献，是做了一套统一运行器，把不同 claw 接到同一个 SWE-bench 风格流程里。
这套流程大概是这样：每个任务都有 GitHub issue、仓库和 base commit，agent 在 Docker 里的 /testbed 改代码；退出后，运行器用 git diff 从仓库状态生成 model_patch，再交给官方 SWE-bench evaluator 判断是否 resolved。这样做的好处是，不同 agent 的最终回复格式不再重要，能统一进入同一个补丁评测流程。
任务集叫 full-350，一共 350 个真实 issue-resolution 任务，覆盖 8 种语言和 43 个仓库。论文还做了一个 80 题的 Lite-80 子集，用 17 个校准实验列做选择，目标是让 Lite-80 的分数、排名和成本结构尽量贴近 full-350。论文也处理了一个确实重要的问题：部分 Multilingual 镜像能看到 base commit 之后的 Git 历史，可能泄露 gold patch，所以主实验会清理 future commit。
这些工程设计是有价值的。统一运行器、runner-side patch collection、future commit 清理、成本记录，都是值得看、也值得复用的东西。问题出在实验结论。
第一个大问题是 bare/full 对比。论文只看 OpenClaw + GLM 5.1，bare 是 67/350，Pass@1 19.1%，Apply Failed 69.1%；full 是 257/350，Pass@1 73.4%。这个差距很大，但它主要说明一件事：让模型在最终回复里手写 unified diff 非常脆弱；让模型改文件，再由运行器导出 patch，会稳定很多。
它不能证明某个具体设计点有效。bare 和 full 同时改变了工作区对齐、提示词设计、future commit 清理、Git 补丁导出、补丁清理和最终输出约定。论文自己也说这个诊断实验不应当解释成 full 的单组件消融。54.3 个百分点的差距越大，越应该警惕：对比里混进去的变量太多，因果解释很容易被放大。
第二个问题是模型和框架实验都太薄。固定 OpenClaw 换 9 个模型，论文说模型选择带来 29.4 个百分点的 Pass@1 spread。固定两个模型换 5 个 claw，GLM 组从 60.9% 到 73.4%，Qwen 组从 38.6% 到 66.0%。这些数字能说明评测框架会影响 SWE-bench 分数，但再往前说某个 claw 在一般意义上更好，证据就不够了。
完整实验本来应该更接近 5 个框架 × 9 个模型。论文实际没有跑完整网格，非 OpenClaw 的四个框架只在 GLM 5.1 和 Qwen 3.6-flash 上测试。这个设计拆不清框架和模型之间的交互效应。论文 Limitations 里也承认这一点。
因为我是 nanobot team 的成员，这里还是要单独看看 nanobot。表 3 里 nanobot 分数低，成本和缓存也异常：GLM 5.1 下 nanobot 成本 768.8 美元，高于同组其他框架；Qwen 3.6-flash 下缓存命中率 63.9%，明显低于 OpenClaw、hermes-agent、zeroclaw 接近 97% 的水平。我真不觉得这么明显异常的数据有多少参考价值。如果你跑一百遍，来个置信区间，我摸摸后脑勺自己就去改代码看看怎么改善；但是只跑了一次，还直接把它解读成 nanobot 本身能力差，我就觉得这个实验做得有点粗糙，并且伤害了我的感情。
Lite-80 的证据也要降级理解。它的构造很细：17 个校准列、语言平衡、难度分位、成本和排名都纳入选择目标。可是校准结果主要说明 Lite-80 贴合这 17 个实验列，外推能力还要看留出验证。论文的留出检查只有 OpenSQuILLA 一个系统，而且只比较 OpenSQuILLA 在 Lite-80 和 full-350 上的 Pass@1。这个检查可以说明 Lite-80 对一个外部系统没有明显跑偏；它不能证明 Lite-80 对新的框架/模型组合都稳，也不能保证排行榜关系稳定。
最硬的问题还是统计证据。论文明确说主实验是 single-run aggregates，每个（任务、框架、模型）组合只跑一次。350 个 0/1 结果可以报描述性的 Pass@1；但当 n = 350、p 在 0.6 到 0.75 附近时，最朴素的二项标准误大约也有 2.3 到 2.6 个百分点，95% 区间量级接近正负 5 个百分点。更别说 agent 运行还有非确定性、远程 API 抖动、并发调度、缓存命中差异。
在这个前提下，论文如果只说“我们观察到差异”，问题不大；一旦开始讨论稳定排名、设计机制或因果归因，就明显越过了实验设计能支撑的范围。GPT 5.5 78.0% vs Claude Opus 4.7 77.1%、GLM 5.1 73.4% vs DeepSeek-V4 Pro 71.7%、OpenClaw/GLM 5.1 73.4% vs hermes-agent/GLM 5.1 71.1% 这种相邻排名，不适合写成稳定座次。论文自己的 Limitations 也提醒 few percentage points 不应被过度解读，但正文和表格解读仍然让人看到一套像排行榜一样的叙事。
成本指标也是类似情况。Total Cost 有意义，可以告诉读者这次实验实际花了多少钱；但 USD 受模型价格、输入/输出 token、缓存策略、框架调用路径、服务商价格表和计费档位影响。它适合作为运行记录，不适合当成稳定 benchmark 指标，除非同时发布足够细的 token、缓存轨迹和价格表版本。
所以这篇论文最适合被理解成一个评测产物发布，很难当作一篇能支撑强结论的实验论文。它提供了 full-350、Lite-80、统一运行器、future commit 清理、运行器侧补丁收集和成本记录，这些东西有实际价值。它也确实说明，评测框架会影响 SWE-bench 类结果，成本应该和解决率一起报告。
但 bare/full 的 54.3 个百分点不能作为干净的设计证明；单次运行还讨论机制归因和几个百分点的排名，是很低标准的实验设计；5 框架 × 2 模型的实验不能拆清框架和模型的交互；一个 OpenSQuILLA 留出检查不足以验证 Lite-80 的泛化性；美元成本受服务商和缓存计费影响很大。
综上，带上个人感情给一句评价：作为工具发布，有一定价值；作为实验论文，标准太低。