Claw-SWE-Bench：评估 OpenClaw 风格 Agent 框架在编程任务上的基准测试

首个将 harness 作为控制变量的 SWE 风格编码评测基准

前置知识

SWE-bench

SWE-bench 是一个用于评估软件工程智能体的基准测试，它使用真实的 GitHub issue 和对应的测试套件来衡量模型解决实际代码问题的能力。评测时，给定问题描述、目标仓库和基础提交，系统需要生成一个可以应用到仓库的补丁，并通过测试来判断是否解决了问题。这个基准已成为评估代码智能体的实际标准，涵盖了多种编程语言和真实世界的代码库场景。

本文基于 SWE-bench 设计新的评测基准，理解 SWE-bench 的评测机制（Docker 环境、补丁提交、测试验证）是理解本文工作如何解决现有评测问题的基础。

Agent Harness

Agent Harness 是指将大语言模型包装成自主智能体的框架，它定义了 agent 的生命周期、工具接口、循环逻辑、停止策略等关键组件。例如 OpenClaw、SWE-agent、OpenHands 等都是不同的 harness。它们负责管理 agent 如何与环境交互、如何使用工具、何时停止等行为。不同的 harness 可能有不同的内部实现，但都提供了将 LLM 转化为可执行 agent 的能力。

本文的核心创新是将 harness 作为一个受控的实验变量，理解什么是 harness 以及它如何影响 agent 行为是理解本文贡献的关键。

Pass@1

Pass@1 是代码评测中常用的指标，定义为首次尝试解决问题的成功比例。在 SWE-bench 风格的评测中，它等于被标记为 RESOLVED 的实例数量除以总实例数量。具体计算公式为 $\text{Pass@1} = \frac{\#\text{RESOLVED}}{\#\text{INSTANCES}}$。Pass@1 衡量的是 agent 在单次运行中解决问题的能力，不需要多次尝试，因此它更能反映 agent 的实际可用性。

Pass@1 是本文的主要评估指标，理解它的计算方式和含义有助于理解不同模型和 harness 的性能比较。

Pareto Frontier

帕累托前沿是指在多目标优化中，所有非支配解构成的集合。一个解是非支配的，如果没有其他解在所有目标上都同时优于它。在本文的上下文中，帕累托前沿是在准确率和成本的二维平面上，那些既不是最贵也不是最差的组合。每个点代表一个 claw-model 组合，帕累托前沿上的点代表了在不同预算下的最佳操作点。如果一个点在帕累托前沿上，意味着没有其他组合同时具有更低的成本和更高的准确率。

本文使用帕累托前沿来展示准确率和成本的权衡关系，理解这个概念有助于理解为什么不能只看 Pass@1 而忽视成本。

Cost-Aware Selection

成本感知选择是指在构建评测子集时，不仅考虑任务分布的代表性，还考虑运行成本的平衡性。本文的 Lite 子集选择使用了一个优化目标，包含三个项：resolve-rate parity（解决率一致性）、pairwise ranking hinge（排序一致性）和 cost parity（成本一致性）。通过这种多目标优化，Lite 子集在保持与完整集相似的性能分布的同时，还能保持相似的 cost 结构，使得在 Lite 上的评测结果可以近似地预测完整集的性能和成本。

本文提出的 Lite 子集是成本感知选择方法的应用结果，理解这个方法有助于理解为什么 Lite-80 可以在减少 77% 成本的同时保持性能相似性。

研究动机

现有的 SWE-bench 风格评测存在根本性的方法论缺陷，它们将 prompt template、agent loop、tool interface、per-instance timeout、patch extraction 策略和停止逻辑打包成一个整体系统发布，这导致最终的 resolved rate 混淆了三个在因果上不同的因素：被评估的 LLM、将 LLM 变成 agent 的 harness、以及被解决的任务实例。例如，当比较两个系统的 resolved rate 时，我们无法知道差异是来自模型能力、harness 设计还是任务集选择。此外，现有评测大多只报告 resolved rate，隐藏了资源成本。同样的 Pass@1 可能对应着非常不同的 token 使用、实际运行时间和交互长度。只报告 resolved rate 会奖励那些依赖更长探索或更高预算的系统，并可能误解那些更便宜或更快但更脆弱的系统。这种评测方式使得小团队和学术团体难以参与基准测试。

本文的目标是本文的目标是创建一个将 agent harness 作为受控实验变量的 SWE-bench 风格评测基准。具体来说，作者希望：第一，证明像 OpenClaw 这样的通用 agent 是否可以通过适配器进入真实的代码评测；第二，提供一个统一的评测协议，使得不同的 harness 可以在相同的任务、预算和评分流程下比较；第三，不仅报告准确率，还要报告端到端的成本、运行时间和缓存使用率；第四，提供一个低成本的子集用于快速验证和迭代。通过这些目标，作者希望推动 SWE 风格的编码 agent 评测向更加可重复、可比较和可负担的方向发展。

与已有工作不同的是，本文的独特切入角度在于明确地将 harness 作为一个受控的实验变量，而不是将其作为模型评测的隐藏实现细节。现有的 SWE-bench 风格评测虽然有一些相关工作，但没有一个真正解决了这个问题。HAL 倡导整体的准确率-成本-延迟评测，但只发布了一个 harness，无法识别 harness × model 交互。SWE-Bench Pro 使用统一的 scaffolding 来比较长时任务，但它是在一个 harness 下比较模型，而不是比较 harness。SWE-Effi 明确提到了 scaffold-model 的纠缠，但它改变 scaffolding 时没有固定 prompt、timeout 和并发性，其 scaffold × model 依赖仍然是一个注意事项而不是受控测量。本文通过定义一个统一的适配器协议，使得不同的 harness 可以接入同一个评测流程，从而将 harness 从实现细节提升为实验变量。

核心方法

本文提出了 Claw-SWE-Bench，一个多语言的 SWE-bench 风格评测基准，它通过两层设计实现了将不同 harness 统一到同一评测协议下的目标。第一层是适配器，它将通用或专用 harness 的原生执行风格连接到 SWE-bench 要求的仓库编辑和补丁预测过程，使得这些系统有资格参与同一类编码任务。第二层是共享编排器，它固定了任务集、仓库状态、任务 prompt、Docker 运行时、外部预算、补丁提取、预测格式和下游的 SWE-bench 评测，将 harness 从偶然的实现细节提升为实验变量。在这个控制下，Pass@1、运行时间和交互轨迹的差异可以归因于模型或 harness 维度，而不是不一致的评测协议。完整的工作负载包含 350 个真实的 GitHub issue-resolution 任务，覆盖 8 种编程语言和 43 个仓库。为了降低使用门槛，作者还发布了 Claw-SWE-Bench Lite，一个 80 实例的低成本子集，用于需要快速验证的场景。

核心创新点在于设计了适配器协议，它不要求不同的 harness 使用相同的内部 agent 循环，而是标准化了 harness 和评测生命周期之间的接口。每个支持的 harness 实现相同的抽象方法：create_agent、send_task、backup_session、delete_agent 和 get_docker_args。共享编排器只通过这些方法驱动运行，不需要知道下面是哪个 harness。这种设计将评测生命周期从 agent 实现中解耦：容器管理、prompt 实例化、补丁收集、预测写入、元数据记录、恢复支持和评测都由评测层实现，而每个 harness 适配器只将其 agent 连接到该生命周期并提供驱动 agent 在容器内运行所需的代码。关键是候选补丁从仓库状态收集，而不是从 agent 的最终消息解析。agent 只能通过编辑仓库中的文件来表达解决方案，这使得输出契约独立于 harness 是否原生产生 JSON、纯文本、最终叙事响应或根本没有结构化响应。

方法步骤详情

评测流程包含几个关键步骤。第一步是加载任务数据，包括 problem_statement、repo、base_commit 和对应的 Docker 评测镜像。第二步是启动容器，仓库被重置到实例的 base_commit 并挂载在 /testbed。对于来自 SWE-bench-Multilingual 的七种非 Python 语言，还需要处理 future-commit 可见性问题，通过删除可达的 future commits 确保 agent 只能在 issue 的历史边界内读取、编辑和运行代码。第三步是 prompt 实例化，每个实例从相同的任务-prompt 模板实例化，包括问题陈述和基础提交，指示 agent 在 /testbed 中工作，禁止 git add 和 git commit，并要求 agent 不修改测试文件。第四步是任务执行，适配器创建或配置 agent，派发实例化的任务，保存运行产物，并在完成后清理 harness 状态。第五步是补丁收集，harness 终止、超时或返回错误后，runner 计算与 base commit 的 diff，移除已知的非解法产物，并写入 SWE-bench 兼容的预测。第六步是评测，使用官方的 SWE-bench harness 运行测试，判断 patch 是否解决问题，报告 RESOLVED 或 NOT_RESOLVED。最后记录各种指标，包括 Pass@1、总 API 成本、运行时间、token 使用、turn 数和缓存命中率。

技术新颖性

技术新颖性体现在几个方面。第一，适配器协议的设计使得异构的 harness 可以接入同一评测流程，这是首次将 harness 作为受控变量的 SWE-bench 风格评测。第二，从仓库状态收集补丁而不是从 agent 消息解析，这使得输出契约独立于 harness 的原生输出格式，这是一个本质性的设计转变。第三，未来提交清理技术解决了多语言容器的公平性问题，这是之前的工作没有充分处理的。第四，成本感知、排序感知的 Lite 子集选择方法使用了 17 个校准列，跨越了模型和 harness 变化，这比简单的随机采样更科学。第五，端到端的成本报告，包括总 API 成本、输入/输出 token、缓存命中率和 wall-clock 时长，这推动评测从单一准确率向准确率-成本联合评价转变。最后，完整的 350 实例多语言工作负载加上 80 实例的 Lite 子集，为研究社区提供了可扩展的评测资源。

**Figure 2**: Contract mismatch between OpenClaw-style harnesses and SWE-bench. The adapter converts a general agent interaction into a SWE-bench-scored patch prediction, while outer controls ensure fairness, comparability, and traceable cost.

实验结果

实验结果揭示了几个关键发现。首先，适配器设计对通用 agent 进入 SWE-bench 评测至关重要。使用 GLM 5.1 backbone 的实验显示，bare adapter（直接要求模型输出统一 diff）只达到 19.1% Pass@1，而 full adapter（让模型编辑文件后从 Git 状态导出补丁）达到 73.4% Pass@1。这证明了适配器不仅是工程包装，而是使通用 agent 能够可靠评分的必要条件。其次，模型选择仍然是主要的性能来源。在固定 OpenClaw 的情况下，九个模型的 Pass@1 范围从 Seed 2.0-mini 的 48.6% 到 GPT 5.5 的 78.0%，跨度为 29.4 个百分点。但准确率排名不等于成本排名。GPT 5.5 有最高的 Pass@1，但完整运行成本为 $1399.1；Claude Opus 4.7 只低 0.9 个百分点，成本为 $1082.0；而 DeepSeek-V4 Pro 达到 71.7% Pass@1，成本仅为 $81.3；DeepSeek-V4 Flash 达到 70.3%，成本只有 $8.2。第三，harness 选择是一阶因素。在固定 GLM 5.1 的情况下，五个 claws 的 Pass@1 范围从 60.9% 到 73.4%，跨度为 12.5 个百分点。在固定 Qwen 3.6-flash 的情况下，跨度更大，从 38.6% 到 66.0%，为 27.4 个百分点。这意味着只改变 harness 特定的 agent 循环、工具接口、workspace 管理和停止策略可以产生与相邻模型层级相当或更大的性能差异。最后，准确率和成本不是简单对齐的。Pareto 前沿分析显示，没有哪个组合在所有维度上都占优。例如，generic × Qwen 3.6-flash 成本最低（$14.50），但 Pass@1 只有 38.6%；zeroclaw × Qwen 3.6-flash 增加成本到 $49.26，Pass@1 提升到 58.3%；OpenClaw × Qwen 3.6-flash 达到 66.0% Pass@1，成本 $71.47。在 GLM 5.1 组中，OpenClaw 是高准确率端点，73.4% Pass@1，成本 $277.00；hermes-agent 和 zeroclaw 有相似的解决率，但被 OpenClaw × GLM 5.1 支配，因为它们都更贵且更不准确。Lite-80 的验证结果显示，在 17 个校准列上，完整集的平均 Pass@1 是 0.639，Lite-80 是 0.643，差异约为 0.4 个百分点。完整的 Lite 运行成本约为完整 350 运行的 22.9%。未来提交清理的实验显示，清理后 Pass@1 从不高于清理前，影响从 Seed 2.0-mini 的约 0.6 个百分点到 Claude Opus 4.7 的 8.0 个百分点不等，这证明了公平性处理的必要性。

**Table 1**: Diagnostic comparison between the bare adapter and the full adapter. Both use the same GLM 5.1 backbone and the full-350 workload; the bare adapter is a minimal directly scorable baseline, not a component ablation of the full adapter. Apply Failed is the fraction of instances whose submitted patch cannot be applied to the repository by the SWE-bench evaluator.

**Table 2**: LLM-axis variation: OpenClaw × 9 models on the full 350-instance Claw-SWE-Bench. Cost is total API cost for the full run (USD); In/Out are total input/output tokens (millions); Turns is average turns; Cache is cache hit rate. Rows are sorted by Pass@1; the best Pass@1 and lowest Cost are in bold.

**Table 3**: Claw-axis variation: five claws × two models on the full 350-instance Claw-SWE-Bench. Cost is total API cost for the full run (USD); In/Out are total input/output tokens (millions); Cache is cache hit rate. Within each model group, the best Pass@1 and lowest Cost are in bold.

**Figure 1**: Resolve-rate–cost Pareto frontier. Data are from the five-claw × two-model sweep in Table 3. Each point is one claw–model combination on the full 350-instance evaluation; the vertical axis is Pass@1 / resolved rate, and the horizontal axis is full-run total API cost (USD, log scale). The black line connects non-dominated operating points.

**Figure 3**: Lite-80 parity with full-350. (a) Per-language comparison between full-350 and Lite-80 Pass@1, averaged uniformly over the 17 calibration columns. (b) Cross-claw Pass@1 comparison between full-350 and Lite-80 over 5 claws × 2 shared models. (c) K-sweep sensitivity envelope; the minimum acceptable K falls in [8, 10] across scenarios, and the release uses the conservative stable point K=10, or 10 instances per language.

**Figure 4**: Effect of future-commit cleanup on the OpenClaw model sweep. After cleanup, Pass@1 does not increase for any of the nine models; drops range from 0.6 to 8.0 pp.

查看结构化数据

任务	指标	本文	基线	提升
GitHub Issue Resolution (350 instances, 8 languages)	Pass@1	OpenClaw × GLM 5.1: 73.4%	Bare adapter: 19.1%	54.3 pp (284% relative)
GitHub Issue Resolution (350 instances, 8 languages)	Pass@1	OpenClaw × GPT 5.5: 78.0%	OpenClaw × Seed 2.0-mini: 48.6%	29.4 pp (60.5% relative)
GitHub Issue Resolution (350 instances, 8 languages)	Total Cost (USD)	OpenClaw × DeepSeek-V4 Flash: $8.2	OpenClaw × GPT 5.5: $1399.1	99.4% cost reduction
Claw Sweep (GLM 5.1)	Pass@1	OpenClaw: 73.4%	Generic: 63.1%	10.3 pp (16.3% relative)
Claw Sweep (Qwen 3.6-flash)	Pass@1	OpenClaw: 66.0%	Generic: 38.6%	27.4 pp (71.0% relative)
Lite-80 vs Full-350	Pass@1 (17-column avg)	Lite-80: 64.3%	Full-350: 63.9%	+0.4 pp (0.6% relative)
Lite-80 vs Full-350	Total Cost Reduction	22.9% of full cost	Full-350: 100%	77.1% cost reduction

局限与改进

作者承认了几个限制。首先，主要实验报告的是单次运行汇总，因此只有几个百分点的差异不应被过度解释为稳定的系统优越性，未来的工作应该使用多种子复制来估计随机性和运行到运行的方差。其次，claw sweep 覆盖了五个 claws 和两个代表性模型，这足以显示 harness 是 SWE 风格编码 agent 评测中的一阶变量，但不足以完全分解 harness × model 交互。更宽的模型轴可以帮助确定哪些结论来自通用的 harness 机制，哪些依赖于特定的 backbone。第三，成本分析依赖于提供商端的定价和缓存记账，因此报告总 API 成本、输入/输出 token 和缓存命中率是必要的，未来的发布也应该保留原始 token 轨迹，以便成本差异可以被审计和重新定价。此外，本文没有深入分析 harness 内部组件（如 agent 循环、工具 surface、parser、停止规则）如何单独影响准确率-成本权衡，这些仍然需要进一步的研究。最后，实验主要在固定的外部预算下进行，不同预算下的行为差异还需要更多的探索。

独立分析的弱点

独立分析的弱点包括：首先，claw sweep 只覆盖了五个 harness，可能遗漏了其他重要的 harness 设计模式。未来的工作应该扩展到更多的 harness，包括最新发布的系统，以提供更全面的比较。其次，模型 sweep 虽然覆盖了九个模型，但主要集中在中文模型和一些旗舰模型上，缺乏对更多开源模型的系统评估，这可能限制了结果的普适性。第三，Lite 子集的选择虽然经过精心设计，但它仍然是一个静态子集，可能无法适应快速发展的模型和 harness。一个动态的、可更新的子集选择机制可能更有价值。第四，未来提交清理技术虽然解决了公平性问题，但它假设所有 future commits 都是泄露，这可能在某些情况下过于保守。更细粒度的泄露检测和过滤可能更准确。第五，虽然报告了缓存命中率，但没有深入分析不同 harness 的缓存策略差异，以及这些差异如何影响实际成本和性能。最后，评测主要关注 resolved rate 和成本，但可能忽略了其他重要的维度，如代码质量、安全性、可维护性等。

未来方向

基于本文成果可以延伸的未来研究方向包括：首先，进行多种子复制实验，以估计随机性和运行到运行的方差，提供更可靠的性能估计。其次，扩展模型轴，包括更多的开源模型和不同规模的模型，以确定 harness × model 交互的普适性。第三，分解 harness 内部组件的影响，通过消融实验分析 agent 循环、工具 surface、parser、停止规则等单独对准确率-成本权衡的贡献。第四，研究模型-harness 非可分性是否推广到 web agent 或计算机使用 agent，以及其他类型的任务。第五，开发更细粒度的泄露检测和过滤技术，以更准确地处理 future-commit 可见性问题。第六，设计动态的子集选择机制，使得 Lite 子集可以根据新的模型和 harness 结果自动更新。第七，扩展评测维度，包括代码质量、安全性、可维护性等，以提供更全面的评估。最后，建立长期的、可复现的评测流水线，使得新的模型、harness 和适配器更改可以在相同的任务、预算和成本记账约定下进行比较。

复现评估

本文的开源情况较好。数据集和代码发布在 GitHub（https://github.com/opensquilla/claw-swe-bench）和 HuggingFace（https://huggingface.co/datasets/TokenRhythm/Claw-SWE-Bench）。完整的 350 实例工作负载和 80 实例 Lite 子集都是公开可用的。适配器协议和实现细节在论文中有详细描述，添加新的 claw 只需要实现适配器接口并在 harness map 中注册。评测运行在 16 核 CPU 服务器上，61 GiB 内存，没有本地 GPU，所有模型推理都通过远程 API 进行。单次完整运行的成本从 $8.2 到 $1399.1 不等，取决于模型选择。运行时间从约 400 秒到约 1200 秒不等。虽然没有提供 Docker 镜像的直接链接，但基于上游 SWE-bench 的 Docker 镜像，环境应该是可复现的。总体来说，复现难度中等，需要访问模型 API 和足够的计算资源，但所有必要的组件和数据都是公开的。