Claw-SWE-Bench：评估 OpenClaw 风格智能体调度器在编码任务上的基准测试

来源： https://arxiv.org/html/2606.12344v1

论文标题： Claw-SWE-Bench: Benchmark for Evaluating OpenClaw-Style Agent Harnesses on Coding Tasks

优化版本： 领域专家分析

语言： 中文

📌 核心贡献与问题定义

问题： 现有的 SWE-bench 类评测通常将大语言模型（LLM）、智能体调度器（Harness）和任务变量混淆在一起，导致无法公平评估单一维度的性能变化。

解决方案： Claw-SWE-Bench 引入了一个标准化 适配器协议（Adapter Protocol），将异构智能体调度器封装到统一的基准测试流水线中，解耦了模型、调度器与任务变量。

核心创新：

适配器协议： 标准化接口使不同调度器（如 OpenClaw、Hermes、Zeroclaw）能够接入统一的 SWE-bench 执行管道。
Git 状态提取机制： 候选方案直接从 Git 仓库状态中提取（而非解析文本日志），确保输出契约与文本输出格式无关。
Lite 子集： 通过成本感知与排名感知算法构建 80 个实例的 Lite 子集，成本仅为全量运行的 22.9%，且保留 ~0.4 pp 的性能偏差。

🏗️ 基准测试架构设计

🔹 适配器协议（Adapter Protocol）

调度器实现以下抽象方法：

python 复制代码

create_agent()      # 创建智能体实例
send_task()         # 发送编码任务
backup_session()    # 备份会话状态
delete_agent()      # 清理实例
get_docker_args()   # 获取容器参数

设计优势：

解耦设计： 基准测试层负责容器管理、提示实例化、补丁提取和评估；调度器仅连接生命周期并控制内部智能体。
固定评估契约： 所有调度器共享相同的提示模板，禁止 git add/git commit，并防止修改测试文件。

🔹 标准化执行管线

组件	规范
运行时环境	每个实例独立的 Docker 镜像；仓库重置到 `base_commit`
超时与并发	3600 秒 wall-clock 超时；3 线程并发工作
未来提交清理	移除 `base_commit` 之后的可达 Git 提交，防止未来修复泄露
提示模板	跨所有调度器固定
评分契约	官方 SWE-bench 评估器读取 `model_patch` 字段；测试通过即视为解决

📊 Claw-SWE-Bench Lite 子集

设计用于快速迭代验证，同时保持基准保真度：

指标	值/描述
规模	80 个实例（每种语言 10 个）
成本缩减	~22.9% 的全量运行成本
选择方法	成本感知、排名感知二进制优化，基于 17 列校准（9 模型列 + 8 跨爪列）
验证一致性	全量集 `Pass@1` 均值 0.639 vs Lite 集 0.643（偏差仅 ~0.4 pp）
K-Sweep 结果	最小子集大小 K* ∈ $8, 10$ ；保守选择 K=10

⚙️ 实验设置

🔹 评估的 Claw 调度器

Claw	实现	显著特征
`openclaw`	Node.js	结构化 JSON 输出，工具拒绝列表，逐实例隔离
`hermes-agent`	Python (CPython 3.12)	无状态 `--yolo` 调用，终端/文件工具集
`zeroclaw`	Rust 二进制 (~37MB)	无状态，原生 `costs.jsonl` 日志，绑定挂载二进制
`nanobot`	Python	工作区元数据清理 (`AGENTS.md`, `SOUL.md` 等)
`generic`	Python (GenericAgent)	基于文件的 I/O 契约 (`input.txt/output.txt`)，函数调用架构

🔹 评估的模型

模型扫描： 9 个 LLM（GPT 5.5、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）
Claw 扫描： GLM 5.1 与 Qwen 3.6-flash 在全部 5 个 Claw 上的表现

🔹 评估指标

math 复制代码

Pass@1 = \frac{\#Resolved}{\#Instances}

math 复制代码

CacheHit = \frac{\#CacheReadTokens}{\#InputTokens + \#CacheReadTokens}

主要指标： Pass@1（解决率）
效率指标： 总 API 成本（USD）、wall-clock 持续时间、轮次计数
诊断指标： 缓存命中解释（解释成本差异，不代表能力）

📈 关键实验发现

🔹 适配器的必要性

配置	Pass@1
最小 Bare Adapter	19.1%
Full Adapter	73.4% (GLM 5.1)

直接生成 diff 非常脆弱；Git 状态提取是解决此瓶颈的关键。

🔹 模型 vs 调度器影响

扫描维度	核心发现
模型扫描	`Pass@1` spread 达 29.4 pp ；成本差异巨大（GPT 5.5: `$1399` vs DeepSeek-V4 Flash: `$8.2`），但准确率相似。
Claw 扫描	Claw 选择是一阶因素；在 GLM 5.1 上 spread 为 12.5 pp ，在 Qwen 3.6-flash 上 spread 为 27.4 pp。

🔹 成本-准确率权衡

解耦现象： 相似 Pass@1 的系统，成本可能相差数个数量级。
缓存影响： 缓存命中率因 Claw 而异（96.5% vs 63.9%），严重影响实际 API 成本。缓存率是诊断指标，不是能力指标。
未来提交清理： 必要且公平；减少了解决率（如 Claude Opus 下降 8.0 pp），但防止了从 Git 可见性中获得的 inflated 分数。

🌍 语言依赖与成本分析

🔹 语言表现差异

语言	表现特征
Go	consistently 最难解决
Java/Rust	表现主导，Claw spread 在这些语言上更显著
小模型场景	Claw spread 进一步扩大

🔹 成本帕累托前沿（Pareto Frontier）

端点	准确率	成本 (USD)	特征
Generic × Qwen 3.6-flash	~38.6%	`$14.50`	低成本，低准确率
Openclaw × GLM 5.1	~66.0%	`$277.00`	高准确率，高成本

结论： 跨 Claw 比较必须采用成本感知帕累托视图。

📦 复现性与资源

资源	链接/路径
GitHub	`opensquilla/claw-swe-bench`
HuggingFace	`TokenRhythm/Claw-SWE-Bench`
Lite 构建脚本	Node.js 工具包（选择、K-sweep、灵敏度检查）
硬件要求	CPU: 16-core, RAM: 61 GiB, GPU: None (API-only)
运行入口	`run_infer.py`（所有 Claw 的单入口）

💡 领域专家分析

为什么 Claw-SWE-Bench 是突破？

消除混淆变量： 传统基准测试无法区分性能变化是来自模型、调度器还是任务。Claw-SWE-Bench 通过固定提示、固定环境、Git 提取机制，隔离了调度器变量。
Git 状态提取： 这是核心创新。传统方法从文本输出中提取补丁，容易因格式问题失败。Git 提取直接读取仓库状态，将错误率降至 <1.5%。
Lite 子集的数学严谨性： 通过成本感知和排名感知算法构建子集，确保 Lite 集与全量集仅存在 ~0.4 pp 的差异，使得快速验证具有统计学意义。
调度器是一阶因素： 与直觉不同，调度器的选择对结果的影响与模型本身同样重要（spread 27.4pp），这意味着在评估编码智能体时，调度器设计是首要考虑因素。

与其他智能体基准测试的对比

维度	Claw-SWE-Bench	SWE-bench	AgentBench
评估焦点	智能体调度器（Harness）	大语言模型	多任务类型
解耦能力	✅ 强（适配器协议）	❌ 弱（模型与任务混杂）	❌ 弱
补丁提取	Git 状态提取	文本解析	文本解析
Lite 子集	✅ 成本感知构建	❌ 无	❌ 无
调度器多样性	5 种 Claw	N/A	N/A

🔬 核心创新总结

适配器协议： 标准化接口，使异构调度器能够公平比较。
Git 状态提取： 从 Git 仓库状态提取候选方案，解决统一 diff 脆弱性问题。
Lite 子集构建： 通过成本感知算法构建 Lite 集，成本仅为全量运行的 22.9%。
调度器是一阶因素： 证明调度器设计对编码任务结果的影响与模型本身同样重要。