這次我們來看一個評測基準(zhǔn)SWE Refactor Bench。它的定位很直接——不是又一個編碼代理工具而是一套用來回答“編碼代理能不能完成長時間跨度、全倉庫級別、真實技術(shù)棧遷移任務(wù)”的評估框架。為什么這個問題值得單獨做評測因為現(xiàn)有的編碼代理評估大多集中在單文件 bug 修復(fù)、小范圍功能開發(fā)、Issue 級別的局部改動。而真實工程里更常見、也更消耗人力的任務(wù)恰恰是“把一個舊版本框架升級到新版本”“把整個倉庫的調(diào)用方式統(tǒng)一替換”“把配置體系從 A 遷移到 B”這類跨文件、多步驟、需要長鏈路推理的改造。SWE Refactor Bench 想補上的正是這一環(huán)。從標(biāo)題拆這個基準(zhǔn)的關(guān)注點Long-Horizon 表示任務(wù)鏈條長代理需要連續(xù)完成多個步驟Whole-Repository 表示修改范圍是整個代碼倉庫不是單文件補丁Stack Migration 表示任務(wù)內(nèi)容是技術(shù)棧遷移包括框架升級、API 替換、依賴收斂、配置格式遷移等。這幾個詞放在一起決定了它和普通 bug 修復(fù)基準(zhǔn)有本質(zhì)區(qū)別。本文會從基準(zhǔn)定位、任務(wù)設(shè)計、評估指標(biāo)、運行流程、常見失敗模式、工程化啟示幾個角度展開最后給出一套把 SWE Refactor Bench 用進編碼代理能力評估與團隊選型的參考流程。1. SWE Refactor Bench 核心能力速覽先給一張速覽表把基準(zhǔn)的關(guān)鍵信息列清楚。評估項目說明項目類型編碼代理Coding Agent評測基準(zhǔn)核心任務(wù)全倉庫級別技術(shù)棧遷移包括框架升級、API 替換、依賴遷移、配置體系切換關(guān)鍵維度Long-Horizon長時程任務(wù)、Whole-Repository全倉庫、Stack Migration技術(shù)棧遷移與 SWE-bench 的關(guān)系同屬編碼代理自動評估方向但 SWE-bench 偏 bug 修復(fù)SWE Refactor Bench 偏重構(gòu)與遷移適用對象LLM 應(yīng)用工程師、編碼代理開發(fā)者、研發(fā)效能團隊、做技術(shù)選型的技術(shù)負(fù)責(zé)人運行方式本地或 CI 按任務(wù)實例執(zhí)行通常需要容器化隔離環(huán)境結(jié)果形態(tài)代理輸出代碼改動評估端通過構(gòu)建、測試、靜態(tài)檢查等方式判斷是否成功顯存要求不涉及基準(zhǔn)本身不需要 GPU 推理但如果被測代理使用本地模型則取決于所接入模型是否支持 API基準(zhǔn)沒有內(nèi)置業(yè)務(wù) API但可通過腳本接入任意支持命令行或 HTTP 調(diào)用的編碼代理這幾點先明確SWE Refactor Bench 不是一個編碼代理也不是一個開發(fā)工具而是一套“考卷”?？嫉牟皇谴砟懿荒苈牰噶疃谴砟懿荒茉跊]有人一步步指揮的情況下把一次完整的技術(shù)棧遷移從頭做到尾。從當(dāng)前公開信息看這類基準(zhǔn)的設(shè)計思路和 SWE-bench 同源從一個真實倉庫出發(fā)選取真實發(fā)生過且可以被驗證的改造任務(wù)把“代理生成的改動”與“驗證條件”進行自動比對。不同的是SWE-bench 的驗證條件通常是測試用例是否通過而 SWE Refactor Bench 的驗證條件要復(fù)雜得多——遷移后代碼不僅要能編譯還要保證原有行為不被破壞同時所有需要替換的調(diào)用點都得替換干凈。2. SWE Refactor Bench 與 SWE-bench 的定位差異要理解 SWE Refactor Bench最方便的方式是把它和 SWE-bench 放在一起對比。SWE-bench 是編碼代理評測領(lǐng)域繞不開的基準(zhǔn)它從真實 GitHub 倉庫中抽取 Issue 和對應(yīng)的修復(fù) PR讓代理獨立閱讀 Issue、定位問題、修改代碼最后用隱藏測試來判定是否修復(fù)成功。這個設(shè)計解決了早期“人工看對話覺得厲害但不知道代碼能不能跑”的問題把評價標(biāo)準(zhǔn)拉回到了自動化驗證上。但 SWE-bench 的任務(wù)單元本質(zhì)上還是“局部 bug 修復(fù)”問題描述已經(jīng)明確影響范圍通常集中在少量文件修復(fù)目標(biāo)可以濃縮成一兩句可驗證的描述。真實工程里還有另一類任務(wù)它們的難度不在“定位單一 bug”而在“改動橫跨大量文件且彼此之間必須保持契約一致”。技術(shù)棧遷移就是最典型的一類。SWE Refactor Bench 正是從這個缺口出發(fā)。它的任務(wù)設(shè)定和 SWE-bench 有明顯差異對比維度SWE-bench典型 bug 修復(fù)類基準(zhǔn)SWE Refactor Bench重構(gòu)遷移類基準(zhǔn)任務(wù)范圍局部 Issue 修復(fù)全倉庫、跨多模塊改造任務(wù)鏈條通常幾步完成多階段、需要長期規(guī)劃驗證方式隱藏單測是否通過構(gòu)建、測試、行為等價、遷移完整度是否存在中間無效狀態(tài)較少常見遷移過程中代碼可能長期無法編譯對代理規(guī)劃能力的要求中等高這個區(qū)別非常重要。做 bug 修復(fù)時代理的目標(biāo)高度收斂找到出問題的函數(shù)修復(fù)它跑通測試。做堆棧遷移時代理的目標(biāo)是開放的先把舊調(diào)用點全部列出來再確定新調(diào)用方式再分批替換每替換完一批還要確認(rèn)不影響周邊模塊。過程中任何一個環(huán)節(jié)的判斷失誤都會傳導(dǎo)到后續(xù)步驟。所以SWE Refactor Bench 評估的更像是編碼代理的“工程執(zhí)行力”而不只是“代碼理解力”。這也是它區(qū)別于其他基準(zhǔn)的核心價值它逼著代理在真實項目里做一次完整的技術(shù)債償還。3. 任務(wù)設(shè)計全倉庫堆棧遷移為什么難很多人會低估技術(shù)棧遷移的難度覺得“不就是把舊接口換成新接口嗎”。真實做一次遷移就會知道難點根本不在于某一個替換動作而在于替換動作背后的全局一致性。3.1 跨文件調(diào)用鏈在大型倉庫里一個接口可能被幾十個文件引用。舊調(diào)用點分布在不同的模塊、不同的目錄、不同的業(yè)務(wù)層級里。代理不能只看幾個文件就動手它必須先建立一張“調(diào)用關(guān)系圖”知道哪些地方在用、哪些地方是入口、哪些地方是深層依賴。沒有全倉庫視野很容易出現(xiàn)“改了 A 文件忘了 B 文件結(jié)果整體編譯不過”。3.2 中間狀態(tài)不可編譯技術(shù)棧遷移往往不是一步到位的。以框架升級為例假設(shè)舊框架用setup()初始化新框架改成了initialize()那么一次性把全部調(diào)用點改完之前代碼庫大概率處于無法編譯的狀態(tài)。這對代理提出了一個和 bug 修復(fù)完全不同的要求它必須能容忍“中間狀態(tài)是壞的”繼續(xù)按計劃推進而不是一看到編譯失敗就回滾或陷入死循環(huán)。3.3 行為等價性要求遷移完成后代碼行為必須和遷移前保持一致。這看起來是基本要求實際執(zhí)行時卻很難判斷。很多代理在遷移過程中會順手“優(yōu)化”代碼邏輯、調(diào)整變量命名、改變調(diào)用順序。這些改動在單一測試用例里可能不報錯但放到回歸測試?yán)锞褪请[患。評估框架要在“遷移完成度”和“行為未變”之間同時把關(guān)難度比單純跑測試高很多。3.4 上下文窗口限制全倉庫代碼通常遠(yuǎn)遠(yuǎn)超出編碼代理的上下文窗口。代理不可能把整個倉庫讀完再動手它必須在探索、理解和修改之間做平衡。這就非?？简灤淼男畔⒐芾砟芰δ男┪募x一遍就夠哪些文件需要反復(fù)回顧哪些信息可以放進長期記憶哪些信息必須隨時校正。從現(xiàn)有編碼代理的通用表現(xiàn)看長任務(wù)里“前后不一致”是最常見的失敗原因之一。3.5 遷移順序依賴一次完整的遷移通常有先后順序先改底層依賴再改中間層封裝最后才能改業(yè)務(wù)調(diào)用點。順序錯了編譯錯誤會堆積到難以理解的程度順序?qū)α嗣恳恍〔降尿炞C成本都會降低。這類順序規(guī)劃能力正是 Long-Horizon 任務(wù)的核心挑戰(zhàn)。SWE Refactor Bench 把這些問題打包成了標(biāo)準(zhǔn)任務(wù)讓不同編碼代理在同樣的約束條件下被評估。這也是它最有價值的產(chǎn)出它能讓代理開發(fā)者看到自己的系統(tǒng)在長鏈路任務(wù)上的真實短板而不是被短任務(wù)上的優(yōu)秀表現(xiàn)迷惑。4. 評估指標(biāo)與結(jié)果判斷編碼代理完成一次重構(gòu)遷移后怎么判斷成功還是失敗不能只靠“看著改得對不對”必須有一組可自動執(zhí)行的驗證條件。從這類基準(zhǔn)的通用設(shè)計思路看評估指標(biāo)至少應(yīng)該覆蓋以下幾個層面。指標(biāo)作用判斷方式構(gòu)建通過率驗證遷移后的代碼能否正常構(gòu)建執(zhí)行編譯/構(gòu)建命令看退出碼原測試通過率驗證遷移沒有破壞已有行為運行倉庫原有測試套件適配測試通過率驗證遷移后的新接口實際可用運行針對新接口編寫的定向測試遷移覆蓋率驗證舊調(diào)用點是否全部替換干凈靜態(tài)掃描統(tǒng)計舊 API 殘留行為等價性驗證重構(gòu)前后對相同輸入是否輸出一致行為探針用例、基準(zhǔn)輸出比對完成耗時記錄代理完成任務(wù)消耗的資源步數(shù)、token 數(shù)、墻鐘時間這里要特別說明遷移覆蓋率。很多代理做遷移時會替換掉主要入口但留下邊角調(diào)用點。這些殘留調(diào)用點在常規(guī)測試?yán)锊灰欢〞|發(fā)卻會在上線后帶來線上故障。評估基準(zhǔn)如果缺少覆蓋率檢查代理很容易“看起來成功、實際沒做完”。在 SWE Refactor Bench 這類任務(wù)里驗證腳本的工作流大致是# 通用驗證流程示例具體命令以基準(zhǔn)項目實際實現(xiàn)為準(zhǔn) # 1. 應(yīng)用代理生成的補丁 git apply /path/to/agent_patch.diff # 2. 執(zhí)行構(gòu)建 npm run build # 或 mvn compile / pip install -e .取決于任務(wù)倉庫 # 3. 運行測試 npm test # 或 pytest / go test # 4. 掃描舊 API 殘留 ./scripts/check_migration.sh最終的評分不是單一數(shù)字而是多個維度的綜合結(jié)果。這樣設(shè)計的目的很明確避免代理通過“取巧”的方式拿到分?jǐn)?shù)比如把測試文件也改了、把失敗測試刪掉、或者只遷移了最容易遷移的那一層。5. 本地運行 SWE Refactor Bench 的通用流程SWE Refactor Bench 這類基準(zhǔn)的實際運行流程通常包括環(huán)境準(zhǔn)備、任務(wù)實例讀取、代理執(zhí)行、結(jié)果收集、驗證打分。下面給出一套通用流程具體命令需要按你所用的基準(zhǔn)倉庫實際結(jié)構(gòu)調(diào)整。5.1 環(huán)境準(zhǔn)備建議在隔離環(huán)境里跑評估。因為在評估過程中代理會真實修改倉庫代碼這些改動可能是不完整的、錯誤的甚至可能破壞環(huán)境。容器化是最穩(wěn)妥的方式。# 創(chuàng)建評估工作目錄 mkdir -p swe-refactor-eval cd swe-refactor-eval # 拉取基準(zhǔn)倉庫占位鏈接以實際項目地址為準(zhǔn) git clone benchmark-repo-url cd benchmark-repo # 查看任務(wù)實例元信息 ls tasks/ cat tasks/migration_task_001.json任務(wù)實例元信息通常包含目標(biāo)倉庫地址、原始 commit、期望改動范圍、驗證命令、評估說明。這個文件是跑評估的核心輸入。5.2 任務(wù)實例格式一個任務(wù)實例的元信息大致長這樣{ instance_id: migration_task_001, task_type: framework_upgrade, target_repo: https://github.com/example/legacy-repo, base_commit: a1b2c3d4e5f6..., required_change_summary: Replace legacy cache library with new cache interface, validation: { build_command: npm run build, test_command: npm test, migration_scan: scripts/check_legacy_cache.sh } }實際字段名和結(jié)構(gòu)以基準(zhǔn)項目為準(zhǔn)但大方向是一致的基準(zhǔn)把“一個完整遷移任務(wù)”封裝成一個結(jié)構(gòu)化實例讓評估者可以批量運行。5.3 運行編碼代理把任務(wù)實例交給編碼代理執(zhí)行。這里有兩種接入方式如果代理支持命令行模式可以寫一個循環(huán)腳本逐條讀取實例調(diào)用代理命令生成補丁。如果代理只有交互界面則需要把輸入輸出腳本化或者在 CI 環(huán)境里借助驅(qū)動層自動操作。# 批量運行示例偽代碼需按代理接口調(diào)整 for task in tasks/*.json; do echo Running task: $task # 讀取任務(wù)信息啟動隔離環(huán)境 # 調(diào)用編碼代理 CLI 生成補丁 # 保存補丁到 results/ echo Done: $task done5.4 結(jié)果收集與驗證代理完成后把生成的補丁存入結(jié)果目錄然后逐條執(zhí)行驗證腳本# 結(jié)果處理示例讀取補丁并調(diào)用驗證腳本 import json import subprocess from pathlib import Path def run_validation(instance_path: Path, patch_path: Path) - dict: instance json.loads(instance_path.read_text()) result {} # 應(yīng)用補丁 apply_result subprocess.run( [git, apply, str(patch_path)], capture_outputTrue ) result[apply_success] apply_result.returncode 0 # 執(zhí)行構(gòu)建 build_result subprocess.run( instance[validation][build_command].split(), capture_outputTrue, timeout600 ) result[build_success] build_result.returncode 0 # 執(zhí)行測試 test_result subprocess.run( instance[validation][test_command].split(), capture_outputTrue, timeout1800 ) result[test_success] test_result.returncode 0 return result if __name__ __main__: result run_validation( Path(tasks/migration_task_001.json), Path(results/agent_a.patch) ) print(json.dumps(result, indent2))這套流程的核心原則是代理和驗證完全解耦。代理負(fù)責(zé)生成補丁評估端負(fù)責(zé)判斷補丁是否讓倉庫進入預(yù)期狀態(tài)。隔離越徹底結(jié)果越可信。6. 從評估結(jié)果觀察代理的工程化能力SWE Refactor Bench 的價值不只是給一個“通過/不通過”的結(jié)論。它的設(shè)計深度足夠讓評估者從結(jié)果中反推代理的系統(tǒng)能力短板。6.1 任務(wù)拆解能力看代理是否先把全倉庫掃描一遍、列出調(diào)用點清單再開始改代碼。如果代理拿到任務(wù)后立刻開始改第一個文件大概率會在后期被跨文件依賴卡住。6.2 長上下文管理觀察代理在任務(wù)進行到中段時是否還記得最初的遷移目標(biāo)。技術(shù)棧遷移任務(wù)通常有幾十步操作如果代理沒有把目標(biāo)寫成持久化記錄就會在改到后半程時出現(xiàn)行為漂移把精力花在無關(guān)的代碼優(yōu)化上。6.3 失敗恢復(fù)能力在遷移過程中倉庫會經(jīng)歷一段不可編譯的中間狀態(tài)。這是正常的。優(yōu)秀的代理會在出現(xiàn)編譯錯誤時檢查自己最近的一步改動而不是從頭排查也不應(yīng)該因為中間態(tài)報錯就放棄整個任務(wù)。評估時重點看代理遇到的第一次失敗是什么類型后續(xù)采用了什么恢復(fù)策略。6.4 變更聚合與提交習(xí)慣觀察代理是完成一部分就提交一部分還是全部改完后一次性提交。從驗證角度看前者的可追溯性更好從評估角度看兩種方式都應(yīng)該被支持只要最終 patch 可以應(yīng)用并滿足驗證條件。6.5 多文件一致性這點是重構(gòu)遷移任務(wù)最核心的能力。代理在修改interface.ts時是否同步意識到了consumer_a.ts和consumer_b.ts里的舊調(diào)用會失效它會主動搜索所有舊調(diào)用點還是只改自己讀過的那幾個文件對遷移覆蓋率指標(biāo)影響最大的就是這項能力。7. 當(dāng)前編碼代理在長時程遷移任務(wù)中的典型失敗模式雖然 SWE Refactor Bench 的具體評測結(jié)果還沒有大范圍公開但從編碼代理在長時程任務(wù)上的普遍表現(xiàn)可以歸納出幾類典型失敗模式。這些模式也是評估新代理時需要重點留意的信號。7.1 目標(biāo)漂移代理在任務(wù)開始時理解得很清楚接觸了大量代碼后注意力逐漸被細(xì)節(jié)帶走?？赡芑舜蠖螘r間優(yōu)化某個不影響遷移的局部實現(xiàn)卻遲遲沒有推進真正的遷移主線。這在長任務(wù)里非常常見屬于 Long-Horizon 場景下的“規(guī)劃失焦”。7.2 局部最優(yōu)陷阱代理看到倉庫大部分調(diào)用點就認(rèn)為遷移已完成忽略了邊角文件。從局部看它確實完成了絕大多數(shù)替換從全倉庫看殘留的舊調(diào)用點會讓整個遷移失敗。評估端如果只跑測試、不做遷移覆蓋率掃描這類問題很難被發(fā)現(xiàn)。7.3 中間態(tài)恐慌代理把第一個文件改為新接口后發(fā)現(xiàn)整個倉庫編譯失敗于是回滾改動重新嘗試。反復(fù)幾次后任務(wù)時間耗盡。這種情況說明代理對“遷移過程中存在中間無效狀態(tài)”缺少認(rèn)知沒有規(guī)劃好分批順序。7.4 驗證不足代理完成了所有代碼替換但只驗證了新接口能正常工作沒有運行舊測試套件。結(jié)果遷移后的代碼雖然能用卻破壞了原有模塊的行為。這類問題在真實開發(fā)里更隱蔽因為功能鏈路長回歸測試的缺失短期內(nèi)不會暴露。這些失敗模式對所有編碼代理開發(fā)者都有參考價值如果你的代理跑 SWE Refactor Bench 表現(xiàn)不佳不要只怪基準(zhǔn)太苛刻更要分析代理是在哪一類失敗模式上栽的跟頭。8. 運行 SWE Refactor Bench 的常見問題與排查下面是運行這類評估基準(zhǔn)時經(jīng)常遇到的問題按出現(xiàn)頻率整理成排查表。問題現(xiàn)象可能原因排查方式解決方案任務(wù)實例無法解析元信息格式不匹配檢查 JSON 結(jié)構(gòu)和字段名按基準(zhǔn)文檔調(diào)整解析腳本代理生成的補丁無法應(yīng)用代理改了無關(guān)文件或基準(zhǔn) commit 不匹配對比補丁 base commit 和任務(wù)要求重新 checkout 到指定 commit 再應(yīng)用構(gòu)建超時依賴安裝慢或資源不足查看日志確認(rèn)卡在哪一步增配機器預(yù)裝依賴后制作鏡像快照測試結(jié)果不穩(wěn)定每次運行代理的結(jié)果隨機性強同樣的任務(wù)重復(fù)跑多次固定隨機種子和溫度參數(shù)取多次結(jié)果匯總遷移覆蓋率低但測試通過測試用例沒有覆蓋到殘留的舊 API執(zhí)行靜態(tài)掃描腳本增加遷移掃描步驟計入最終評分并發(fā)運行導(dǎo)致機器卡死多個容器同時構(gòu)建消耗資源查看系統(tǒng)負(fù)載串行執(zhí)行或限制并發(fā)數(shù)代理反復(fù)重試同一失敗步驟代理無法從當(dāng)前錯誤中恢復(fù)查看代理日志中的重試循環(huán)增加任務(wù)步數(shù)上限避免無限循環(huán)運行 SWE Refactor Bench 最大的坑不是單個技術(shù)問題而是評估環(huán)境的不一致。兩臺機器、兩套依賴版本、不同的 Node/Python 環(huán)境都可能導(dǎo)致同一個代理出現(xiàn)完全不同的結(jié)果。建議把整個評估環(huán)境做成鏡像固定下來。9. 把 SWE Refactor Bench 用進團隊評估與代理選型如果你不是在做基準(zhǔn)研究而是想給自己的團隊選一個編碼代理SWE Refactor Bench 也很有參考價值。技術(shù)棧遷移是研發(fā)團隊每天都會遇到的真實場景用它來評估代理的實際工程能力比單純看編程競賽題目有意義得多。9.1 建立基線先挑選少量有代表性的任務(wù)實例用你當(dāng)前正在用的代理跑一遍建立基線。不要一開始就上百個任務(wù)選 5 到 10 個覆蓋不同難度的實例就夠了。記錄每個實例的成功率、失敗方式、耗時、資源消耗。9.2 對比多個代理在相同環(huán)境下讓多個代理跑同一批任務(wù)。對比時不只看“誰成功了”還要看“誰失敗的姿勢更有修復(fù)希望”。有些代理失敗是只差一兩個文件人工接手幾分鐘就能補完有些代理失敗是全盤推倒人工接手等于重做。這兩種失敗的工程價值完全不同。9.3 結(jié)合人工抽查自動化驗證是底線但技術(shù)棧遷移里有些問題無法完全自動判斷比如代碼風(fēng)格遷移得是否自然、是否引入了不必要的復(fù)雜度。建議對每個代理的 20% 到 30% 成功樣例做人工 code review綜合判斷質(zhì)量。# 建議的抽查流程 # 1. 將代理生成且驗證通過的補丁導(dǎo)出 # 2. 按文件數(shù)、改動行數(shù)排序 # 3. 人工 review 改動最多的前幾個樣例9.4 合規(guī)注意事項使用 SWE Refactor Bench 的基準(zhǔn)任務(wù)時注意基準(zhǔn)任務(wù)里的倉庫代碼有自己的開源許可。如果要在評估中引入公司內(nèi)部倉庫要確保代碼脫敏不把內(nèi)部代碼提交到外部評估環(huán)境。涉及客戶數(shù)據(jù)、敏感業(yè)務(wù)邏輯的倉庫不建議直接用于外部基準(zhǔn)測試。10. 從評估結(jié)果反推編碼代理的產(chǎn)品化思路SWE Refactor Bench 這類長期任務(wù)基準(zhǔn)給編碼代理產(chǎn)品化的方向提供了一個重要參考代理的能力不能只靠“單輪對話理解”體現(xiàn)更要靠“長時間自主執(zhí)行和恢復(fù)”來證明。如果你在開發(fā)自己的編碼代理這個基準(zhǔn)帶來的啟示很直接。首先代理需要一個“任務(wù)管理器”把全倉庫遷移拆成可驗證的小步驟每步完成都能自檢。其次代理需要把目標(biāo)、已驗證內(nèi)容、剩余待辦持久化保存避免上下文漂移。再次代理需要一種“中間態(tài)容忍”機制當(dāng)編譯失敗時能判斷這是自己剛引入的錯誤還是遷移過程中必然出現(xiàn)的過渡態(tài)。這些能力在普通短任務(wù)基準(zhǔn)里很難暴露但在 SWE Refactor Bench 這類任務(wù)里會迅速顯現(xiàn)。對于使用編碼代理的研發(fā)團隊這個基準(zhǔn)也提醒了一點不要只看代理在 demo 里的驚艷表現(xiàn)要拿真實的長時程重構(gòu)任務(wù)去壓測。代理能寫好一個函數(shù)不代表它能完成一次跨全倉庫的框架升級。技術(shù)棧遷移需要考慮的兼容性、依賴順序、回歸風(fēng)險恰好是編碼代理最容易出問題的地方。如果你想進一步驗證自己的代理可以關(guān)注 SWE Refactor Bench 基準(zhǔn)倉庫和論文的更新看它是否補充了更多行業(yè)級遷移案例。隨著基準(zhǔn)覆蓋的任務(wù)類型越來越廣它給出的評估結(jié)論也會越來越有參考價值。最值得先做的一步是克隆基準(zhǔn)倉庫挑一個遷移任務(wù)實例讓代理跑一次認(rèn)真分析它生成的 patch。是干凈利落地全局替換還是改一半就斷了是正確地保持了行為不變還是引入了不必要的重構(gòu)這些觀察比任何宣傳材料都更能說明一個編碼代理的真實水平。