編輯｜楊文

編程 Agent 的評測，一直是本糊涂賬。

SWE-bench 如今已成事實標準，幾乎每家發布新模型或新 Agent 框架，都會拿出一個 SWE-bench 分數來證明自己有多強。

但這些數字真的能直接橫向比較嗎？

LLM Agent 的能力，本質上是模型和 harness 共同決定的，同一個模型換一套 harness，在 SWE-bench、Terminal-bench 等評測上的分數能相差十幾甚至二十多個百分點，差距堪比換一代模型。

也就是說，一個 SWE-bench 分數背后，同時藏著三個變量：底層用的是哪個大模型、把大模型包裝成 Agent 的 harness 是怎么設計的、評測用的是哪批任務。

SWE-agent、AutoCodeRover、OpenHands、mini-SWE-agent，每個系統都有自己的提示詞模板、工具接口、最大輪數、超時策略和停止邏輯。模型、harness、任務集，三個變量打包在一起，很難判斷 A 比 B 高出的那幾個點，是模型更強、harness 設計更優，還是任務集選得更有利。

另一方面，OpenClaw 這類原本面向通用工具調用場景的 Agent，根本進不去 SWE-bench 的評分流程，「通用 Agent 到底有沒有寫代碼能力」這個問題，也因此長期處于無法驗證的狀態。

近日，基元律動聯合無問芯穹，清華大學、北京大學、SEE 基金等機構發了篇論文，并完全開源代碼和數據，試圖把這筆糊涂賬理清楚。

• 論文鏈接：https://arxiv.org/pdf/2606.12344v1
• GitHub：https://github.com/opensquilla/claw-swe-bench
• Hugging Face：https://huggingface.co/datasets/TokenRhythm/Claw-SWE-Bench

論文提出了一套claw for coding 適配器，第一次讓 OpenClaw 這類通用 Agent，能夠在 SWE-bench 式的真實代碼任務上交出可評分的答卷。

在這套適配器之上，他們構建了Claw-SWE-Bench，一個覆蓋 8 種編程語言、43 個真實代碼倉庫、350 個 GitHub issue 修復任務的多語言基準，外加一個專門給學術圈和小團隊用的輕量版 Lite-80。

該基準強制要求所有系統在統一的 prompt、預算和評分流程下匯報 API 總成本，讓準確率和運行代價能夠在同一張表里被直接解讀。

這也是 SWE-bench 式基準中，第一次讓 harness 作為可獨立測量的變量加以控制

而在搭建評測環境的過程中，他們還順手發現并修復了 SWE-Bench-Multilingual 官方數據集里的一處答案泄露問題，并已向上游提交了修復 PR。

基元律動由原華為諾亞方舟實驗室主任、盤古大模型負責人王云鶴創立，離職僅兩個月便完成首輪融資。

Claw-SWE-Bench，正是其首個對外亮相的技術成果。

適配器解決了什么？

OpenClaw 這類通用 Agent，本來面向的是更廣泛的工具使用場景。它可以調用工具、讀寫文件、執行命令、保留會話狀態，也可以生成自然語言解釋。

但 SWE-bench 的評分中，系統必須提交一個可應用到代碼倉庫的 diff patch，評估器只看 patch 和測試結果，對自然語言回答和 Agent 的交互軌跡一概不理。這種差異，源自于測評方式本身的限制，并不真實反映 Agent 的能力。

這種差異帶來幾個直接問題。

其一，SWE-bench 需要一個干凈、可復現的 Docker 工作區，通用 Agent 則依賴自己的運行環境、工具配置、API 訪問和會話狀態。

其二，SWE-bench 只讀取 model_patch 字段，而通用 Agent 原生輸出的可能是最終回答、結構化消息或日志。

其三，通用 Agent 在執行過程中可能生成各種緩存、元數據、會話文件，一旦這些內容混進 git diff，便會污染最終提交給評估器的 patch。

因此，OpenClaw 無法原生進入 SWE-bench 評分流程，并不說明它沒有寫代碼能力。更準確地說，是我們需要將通用 Agent 的行為轉化成 SWE-bench 可以讀取、應用和評分的標準化內容。

Claw-SWE-Bench 的解決思路是引入一個 adapter（適配器）層

OpenClaw 式 harness 與 SWE-bench 之間不匹配。適配器將通用 Agent 交互轉換為可由 SWE-bench 評分的補丁預測，同時通過外部控制確保公平性、可比性和成本可追蹤。

不同 harness 通過統一接口接入評測流程，Agent 無需在最終回答里手寫 diff，而是在 /testbed 工作區里真實編輯倉庫文件。運行結束后，runner 從 Git 狀態中導出代碼補丁。

這套適配器是不是真的有用，研究者進行了一組 bare adapter 和 full adapter 的對照實驗

同樣以 GLM 5.1 為底座模型，在全部 350 個實例上，bare adapter 只做最小集成，把 OpenClaw 放進 Docker 環境，發送任務描述，然后讓模型直接在最終回復中輸出一段 unified diff 文本。結果，bare adapter 的 Pass@1 僅為 19.1%，patch 應用失敗率高達 69.1%。

full adapter 則要求 Agent 通過工具直接編輯倉庫文件，再由 runner 從 Git 狀態中導出代碼補丁。Pass@1 隨即提升至 73.4%，應用失敗率降至 1.5% 以下。

這也說明，一個通用 Agent 可能已具備解決代碼任務的潛力，但若缺少合適的評測接口，其能力會被 patch 格式、工作區污染、輸出解析等工程細節所掩蓋。而 adapter 本身就是能力釋放的一部分。

一個多語言 benchmark

在適配器的基礎上，研究者又構建了Claw-SWE-Bench，以此解決「評什么、怎么評得公平」。

完整版本包含 350 個真實 GitHub issue 修復任務，覆蓋 8 種編程語言、43 個代碼倉庫，其中 300 個非 Python 實例來自 SWE-bench-Multilingual，覆蓋 Java、Go、Rust、JavaScript/TypeScript、C/C++、Ruby、PHP，另外 50 個經過人工校驗的 Python 實例來自 SWE-bench-Verified-Mini。

為了讓不同 harness 之間的差異真正可比，Claw-SWE-Bench 還在外層固定了一套評測條件。所有 harness 使用同一份 prompt 模板、同一個任務集、同一套 Docker 運行環境，以及每個實例相同的 3600 秒超時預算。

prompt 里的任務描述、操作規則完全一致，差異只來自 harness 自身的內部實現。

如此一來，不同 harness 之間的 Pass@1 差異，才能被真正歸因到 harness 設計上，而非外部條件不同造成的假象。

由于完整版本包含 350 個實例，這樣規模的評測成本過高，適合正式報告，但不適合日常高頻迭代。

為此，研究者還構建了一個輕量版本 Claw-SWE-Bench Lite，從 8 種語言中各選 10 個實例，共 80 個實例，專門留給學術團隊、開源社區和資源有限的小團隊，用來做日常的 prompt 調整、模型替換、adapter 調試和回歸測試。

Lite 不是隨機抽樣。它控制了語言分布、難度四分位和倉庫覆蓋，并以 17 個校準列擬合 full-350 的行為，這 17 個校準列同時覆蓋模型變化和 harness 變化。

結果顯示，Lite-80 的成本約為 full-350 的 22.9%。在 17 個校準列上，full-350 平均 Pass@1 為 0.639，Lite-80 為 0.643，只差約 0.4 個百分點。

Lite-80 與 full-350 的一致性。（a）full-350 與 Lite-80 在各語言上的 Pass@1 對比，結果是在 17 個校準列上均勻平均得到的。（b）在 5 種 claws × 2 個共享模型上，full-350 與 Lite-80 的跨 claw Pass@1 對比。（c）K 掃描的敏感性包絡；在不同情景下，最小可接受 K 值落在 [8, 10] 區間內，發布版本采用保守且穩定的 K=10，即每種語言 10 個實例。

Lite 還覆蓋了 full-350 中 43 個倉庫里的 34 個，覆蓋率達到 79%。

花四分之一左右的成本，就能拿到一個和完整評測幾乎一致的反饋信號，這對學術團隊和小公司來說相當友好。

此外，在構建這套多語言任務集的過程中，團隊還順手發現了一個問題。

檢查 SWE-bench-Multilingual 的容器時發現，部分實例中 base_commit 之后的 Git 歷史仍然可見，Agent 如果通過 git log 或 git show 看到未來的修復提交，分數就會被人為抬高。

因此，研究團隊在非 Python 多語言任務中移除了 base_commit 之后仍可達的 Git 歷史，并把這一清理邏輯變成了 Claw-SWE-Bench 評測流程的標準步驟，同時把這一問題反饋給了上游 SWE-bench-Multilingual 項目。

清理之后，9 個模型在 300 個 Multilingual 實例上的 Pass@1 沒有一個上升，Claude Opus 4.7 下降最多，從 84.7% 降到 76.7%，降了 8.0 個百分點；Kimi 2.6 下降 5.0 個百分點，Qwen 3.6-flash 下降 2.0 個百分點。

兩組橫掃實驗，把關鍵變量逐一拆開

在統一的適配器和評測協議之下，論文做了兩組橫掃實驗。

固定 harness，換模型

第一組實驗固定 OpenClaw 這個 harness，只更換底層模型，在 9 個模型上做橫掃。

結果顯示，模型選擇依然舉足輕重。GPT 5.5 最高，Pass@1 為 78.0%，Claude Opus 4.7 為 77.1%，GLM 5.1 為 73.4%，最低的 Seed 2.0-mini 為 48.6%。最高和最低之間相差 29.4 個百分點。

這組實驗真正有意思的結論在成本側。GPT 5.5 跑完 350 個實例的總 API 費用是 1399 美元，Claude Opus 4.7 是 1082 美元，兩者 Pass@1 只相差不到 1 個百分點。

DeepSeek-V4 Flash 以 70.3% 的 Pass@1 完成評測，總成本只要 8.2 美元。DeepSeek-V4 Pro 以 71.7% 的成績花了 81 美元，Qwen 3.6-flash 以 66.0% 花了 71 美元。

同樣是七成左右的解決率，成本可以差出兩個數量級。如果評測報告只寫一個 Pass@1，完全看不出這個維度的差異。

固定模型，換 harness

第二組實驗則固定模型，在 GLM 5.1 和 Qwen 3.6-flash 上分別對 OpenClaw、Hermes-agent、ZeroClaw、GenericAgent、Nanobot 這五個 harness 做橫掃。

prompt、任務集、運行預算等其它條件全部保持一致，唯一的變量就是 harness 內部的 agent loop、工具集和停止策略。

結果是，在 GLM 5.1 上，五個 harness 的 Pass@1 分布在 60.9% 到 73.4% 之間，差距達 12.5 個百分點。

在 Qwen 3.6-flash 上，從 Generic 的 38.6% 到 OpenClaw 的 66.0%，差距擴大到 27.4 個百分點。

Claw 維度的變化：五種 claws × 兩個模型在完整 350 實例 Claw-SWE-Bench 上的結果。Cost 表示完整運行的總 API 成本（美元）；In/Out 表示總輸入 / 輸出 token 數（百萬）；Cache 表示緩存命中率。在每個模型組內，最佳 Pass@1 和最低 Cost 以粗體標出。

同一個模型，換一套 harness，結果能相差一個模型檔位甚至更多，這說明在編程 Agent 里，harness 會顯著影響最終能力

論文進一步用 Pareto 前沿圖呈現了成本分布。

橫軸是 350 個實例完整運行的總 API 成本，縱軸是 Pass@1，Pareto 曲線連接那些「沒有任何其他組合既更便宜又更準確」的工作點。

我們可以看到，generic × Qwen 3.6-flash 成本最低，約 14.5 美元，但 Pass@1 只有 38.6%，實用價值有限。

ZeroClaw × Qwen 3.6-flash 花 49 美元可達 58.3%，OpenClaw × Qwen 3.6-flash 花 71 美元能到 66.0%，OpenClaw × GLM 5.1 花 277 美元可達 73.4%。

這類對比把評測從「誰分數最高」推進到「什么組合在成本和準確率之間最值得選用」。對研究團隊、開源社區和小公司來說，這個視角尤為重要。真實研發通常不是一次性沖榜，更多時候是在預算約束下反復試錯、調參、回歸和驗證。

結語

AI 編程 Agent 的競爭，已經不只發生在模型層。真正決定它能否進入真實軟件工程流程的，還有工程實現、系統架構和成本控制。

然而，這些維度在當前以單一 Pass@1 數字為核心的行業話語里，幾乎是隱形的。

一個系統分數更高，究竟是因為模型更強，還是 harness 設計更好，抑或是任務集選得更有利，外界很難看清。

因此，未來的編程 Agent 評測，不能只報告 Pass@1，也不能默認把所有提升都歸因于模型。harness 設計、工具接口、運行預算、緩存策略與成本核算，都應當進入評測表。否則，我們所看到的數字，充其量只是故事的一半。