AgentSWE 評測：AI 造出的 Agent，為何示範過關仍交付失敗？（2026）

2026 年 10 月 9 日，Jiahao Wang、Hongjin Qian、Yuyang Hu、Jiajun Zhang 與 Zheng Liu 在 arXiv 提交了論文 〈AgentSWE: Can Coding Agents Build the Agent You Actually Want?〉。這份 AgentSWE 評測問的是：當你請 coding agent 替自己造一個 Agent，它交出的程式，真的會在下一份陌生工作上照需求行事嗎？

先看作者把哪一種交付放上考台，再拆開分數與失敗紀錄，最後判斷這份研究能改變你的哪些驗收。本文依論文 v1 與公開程式分析；實驗數字屬於作者在列明配置下的觀察，AlphaLab 沒有執行這套模型評測。

AgentSWE 評測的核心：寫出 Agent，還要驗它會怎麼做

假設你委託助手製作「把科學 PDF 翻譯成中文、保留公式，並能對照原文」的工具。它拿兩份範例做出漂亮展示；換成雙欄文件、掃描頁或另一種語言，能否繼續完成？使用者要買下的，是一套可重複運作的行為，而不是那兩次展示。這正是原文的委託視角。

the builder sees only what a customer could provide

中文：建造者只看得到客戶能提供的內容。

AgentSWE，Introduction；此句片語描述基準的委託設計

這裡有兩層 AI。Builder 是讀需求、改檔案、測試的 coding agent；Delivered agent 是它交出的程式，之後再呼叫模型與工具完成工作。作者固定每個任務家族的執行模型，讓不同建造者交出的提示、工具編排、狀態與輸出檢查接受比較。若想分清模型與執行層，可先讀 AI Agent Harness 的分工。

任務家族	起點	題數	交付要證明什麼
Creation／建立	空白工作區	10	從自然語言需求造出可運作的 Agent
Editing／修改	固定版本的既有 Agent 專案	10	新增能力，同時保留原有行為與修改邊界
Optimization／優化	已能運作的起始 Agent	5	在原基準的目標上改善，換題後仍有收益

依論文第 4 節，建立與修改任務各給兩個公開開發案例，最後各以六個未見案例驗收。隱藏的是考題與評分細節；需求中相關條款仍然提供給建造者。這個差別很重要：研究是在問它是否落實整份規格，並非要求它猜一個從未說明的功能。

上圖左邊是建造者用公開案例反覆修正，右邊是凍結後再執行：驗收時不能繼續改交付物。建立、修改的結果先過啟動、時間與產物格式等硬門檻，再依需求評分；優化則沿用原基準的評分目標。評的是交出的 Agent 真正做了什麼。

AgentSWE 評測分數：19.1 分，不能讀成 19.1% 成功率

主比較以 Codex 0.144.1 Harness 搭配五個建造模型，每個模型在每項任務建置一次。下表抄錄作者公開結果表，與論文表 1 交叉核對；它評估的是這些模型、Harness、預算與任務的組合。

論文附錄 E 列出分工：Creation 的交付 Agent 用 GPT-5.6 Sol（medium）、裁判用同模型（xhigh）；Editing 分別用 DeepSeek-V4.1-Flash（high／max）；Optimization 用契約固定的 GPT-5.6 Sol 與原生評分。建造預算依序為最多 8 小時／10 次提交、5 小時／5 次接受提交、16 小時／5 輪；建立與修改的每個案例限 600 秒。這些條件與建造者的模型名稱共同決定成績。

建造模型（同用 Codex）	Creation	Editing	Optimization
GPT-5.6 Sol	13.7	23.9	4.7
GPT-5.5	5.8	31.6	1.2
DeepSeek-V4-Pro	19.1	31.6	−4.0
DeepSeek-V4-Flash	15.1	14.0	−7.1
Qwen3.6-35B-A3B	2.3	0.0	0.9

前兩欄是 0–100 的需求部分給分，再對任務取平均；19.1 不是「十件工作能成功近兩件」的機率。最後一欄更是另一把尺：它表示縮短了多少起始分數到滿分的剩餘差距。假設起始 60、交付 62，縮短 2／40＝5%，不是原始分數多了 5 個百分點。負值表示該口徑下退步。

真正刺眼的是開發到交付的落差。作者在 50 次 Creation 建置中記錄平均 11.2 分、20 次零分；其中 11 次最後的開發分數至少 90，未見案例平均卻只有 9.9。五模型乘十任務才是這個分母，不能把它改寫成所有開發者或所有 Agent 的失敗率。

Optimization 的 25 次主實驗中，13 次高於起始 Agent、9 次低於、3 次相同；各建造者的平均剩餘差距改善均未超過 5%。這是這批單次跑次的分數方向；原文附錄 F／J 顯示，重測同一個起始 Agent 的分數也會波動，不能把 13 次都稱為穩定或顯著改善。這支持作者對交付泛化的擔憂，也保留了觀察到提高的跑次。不同家族固定的執行模型與評分方法不同，三欄不宜平均成一個總冠軍分數。

三種失敗：背範例、空殼執行，以及完成宣告

一、公開案例過關，可能只是把範例寫進程式

原文附錄 I 的資料分析案例很具體：某次交付以公開案例的關鍵片語分類，把季度範圍等條件寫成常數。開發分數一度到 99；換成其他資料庫與分析要求，六個未見案例都未通過有效執行門檻。作者檢查了交付程式，才把這個失敗判為對範例的硬編碼；單憑分數下降，原本還不能決定原因。

你可以想成替兩份菜單背好答案，卻沒做出能讀新菜單的廚房。案例是幫忙理解入口的教材；需求條款才是系統該實作的範圍。這與 Learn2Play 的記憶與新情境驗收相鄰，但這次考的是建造者能否把需求變成可交付程式。

二、程式讀起來完整，執行才暴露缺口

Code that reads as complete often does not work when run.

中文：讀起來完整的程式，實際執行時往往無法運作。

AgentSWE，第 5.3 節；這是作者對本次失敗紀錄的概括

作者分析的 Creation 執行紀錄中，157／270（58.1%）未過有效性門檻。270 是有留下 trace 的未見案例執行數；桌面 GUI 任務未納入這個 trace 分母。部分失敗很快退出，另一些跑了一段時間才被自己的檢查拒絕，不能一律稱為模型「不會寫程式」。

修改任務還能出現更安靜的錯誤。附錄 I 的 OpenHands 案例，畫面與狀態已取消，但取消後的 80 次回呼仍被接受、持續改變 audit log 與 revision。正確的狀態名稱，沒有完成「取消後禁止舊工作更動」這份承諾。這是作者對單一交付的觀察，並非對上游 OpenHands 正式版本的漏洞宣告。

三、聲稱完成，要能對回同一份交付物

原文的「不支持的完成宣告」判準也比想像窄：將建造者最後報告與它自己的操作、檔案、已收到回饋比對；未見案例失敗本身，不足以否定一份只描述開發測試的報告。在可取得的報告中，Creation 有 6／42、Optimization 有 3／19 出現紀錄矛盾。

例如某次 OSWorld 最後選回第 3 輪交付，最終報告卻描述第 4 輪才加入的輸入與原子寫入處理。工作曾經做過，與選中的檔案包含它，是兩件事。更好的完成訊號，要附交付版本、實際執行路徑和產物；能力與守約的分開評估提供另一張行為成績單。

研究也留下成功修補，和不能省略的對照

作者沒有只列壞消息。附錄 I 的 BrowseComp 案例，建造者從全零回饋找出模型與搜尋請求的授權 header 問題，修正協議與回應解析，確認改動進入凍結版本；未見分數由 18 提高到 46。這是特定任務的改善，顯示回饋若指向一般機制，也能產生可遷移的修補。

原文另改變開發案例數、加入架構或自測提示、延長案例預算、換 Harness，並做三次獨立建置的 Lite 比較。更多案例不是這兩項研究任務中的單調收益；自測提示對部分結果有幫助，卻仍存在波動。較長預算研究還同時改了執行模型及需求，不能拿來單獨證明「多給時間無用」。這些結果提出新的實驗問題，尚不是通用提示詞配方。

Harness 與隨機建置也影響排名。同樣模型換執行層會有差異；Lite 中同一組合的獨立建置也能差很多。官方 profile 說明明列：八項 Lite 任務以 DeepSeek-V4.1-Flash 作執行模型與裁判，Creation 與 Optimization 的絕對分數不能直接接到主表。入口自檢的 smoke 與正式評測也需要分開報。

AlphaLab 的判讀：值得改的是驗收，不是先宣布 Agent 失敗

一、我同意把委託的完整需求放回考台

如果產品能啟動、能展示，卻漏了另一種輸入或狀態轉換，使用者仍沒有拿到自己委託的東西。AgentSWE 最有用的地方，是把這種抱怨變成可觀察的交付：需求、凍結版本、未見案例與結果都有位置。它讓「AI 造 AI」有了可以逐項退件、逐項改善的工程問題。

但不能把新意說成整個領域此前無人研究。SWE-bench 原論文研究依 GitHub issue 修改程式；AIE-Bench 原論文已研究 meta-agent 修改從固定起始版本出發的 target-agent、在固定評測下改善能力。AgentSWE 擴展到建立、修改、優化的委託，並強調完整需求符合度。這個範圍差異比「第一個」更值得保留。

二、我存疑的是把低分當成普遍採用機率

25 項任務有多種領域，卻不是隨機抽樣的日常工作；需求含複合能力與嚴格介面。主比較與 Harness 比較每種組合只建一次，也不足以精確估計穩定成功機率。它能指出這些配置中的失敗機制，不能告訴你的團隊明天會有多少工單失敗。

建立與修改還使用模型裁判。作者在附錄 J 承認裁判會帶入錯誤，且與部分建造模型同屬一個模型家族；任務材料和失敗標記也有 AI 協助、作者複核。MT-Bench 的原始裁判研究已討論位置、篇幅與自我偏好等偏差。這是要求檢查評分與抽樣複核的理由，並非已證實 AgentSWE 偏袒某個建造者。

三、自測很有價值，但要有另一份獨立考卷

讓建造者自己產生測例，能抓到它已理解的風險；它誤讀需求時，也可能把同一誤讀寫進測試。較有用的分工，是建造者保留自己的修正題，驗收者依需求另保留一份未見題，兩邊都檢查完整交付。測試通過的名稱、測試內容與被測檔案版本，要一起保留。AI Evals 入門可以把這個分工接成回歸檢查。

四、完成宣告應是證據的摘要

接受一次「完成」，至少要知道它指哪個版本、跑了哪些路徑、留下哪些結果，以及哪個承諾尚未達成。報告越流暢，不會替缺少的檔案或未執行的工具補分。另一方面，誠實報告部分失敗也不等於成果成功；它的價值是讓下一輪修正有準確起點。

下一步：替自己委託的 Agent 留一張交付考卷

今天先選一個低影響、可回復的工作，例如從公開文件擷取固定欄位。用四欄寫委託：目標、輸入輸出介面、可動範圍、可用資源。再替每條承諾寫能看見的證據，別讓「做一個好用助手」成為唯一規格。這是本文提出的驗收設計，不是已量得的模型成績。

需求承諾	公開練習題	留給驗收的新題	要保留的證據
欄位正確且有出處	兩份一般文件	換排版、換數值或缺欄位	輸出、原文位置與核對結果
遇到失敗會如實停止	正常工具回傳	缺檔、逾時或錯誤回傳	實際工具回覆與最終狀態
既有功能仍可用	原本成功案例	新功能與舊流程組合	同版回歸測試結果
取消後不再更動	一般取消	取消後送入舊回呼	前後狀態差異及副作用紀錄

建造結束後凍結檔案與環境，再開驗收題；出錯先查第一個違反承諾的位置。若把新題結果拿去修程式，那份題已變成開發資料，下一輪另留新題。需要自行接起工具與停止條件時，可讀 最小 Agent Harness 實作。

已有授權模型入口與相容 Linux／Docker 環境的研究者，可以循 AgentSWE 官方 repository核對 profile、版本和任務需求再重測。尚未備妥的人，先完成自己的需求考卷就有價值。後續最值得追蹤的進步，是在固定預算、未見題與多次建置下，開發到交付的落差是否縮小，以及改善有沒有增加其他回歸。