SWE-Explore 是一個針對 AI coding agent 的新評測：它先問更前面的問題——agent 在修之前，有沒有找到真正需要讀的程式碼區段？ 最後有沒有修好 bug，留到後面的修補與驗證階段再看。
這個問題比看起來更關鍵。很多 coding agent 失敗的原因包含：只讀到「看起來相關」的檔案，卻漏掉真正決定修法的幾行程式碼、測試、邊界條件或呼叫鏈。
根據 arXiv 論文〈SWE-Explore: Benchmarking How Coding Agents Explore Repositories〉、SWE-Explore-Bench GitHub repo、Hugging Face dataset 與 The Decoder 的整理，SWE-Explore 覆蓋 848 個 issues、203 個開源 repositories、10 種程式語言，並把成功修復軌跡中實際讀過的程式碼區段蒸餾成 line-level ground truth。
它的價值不在宣傳「某模型分數又提高」。它更像一把手術刀，把 AI coding agent 的工作拆開：先評估探索與定位，再談 patch 生成。對正在導入 Claude Code、Codex、Antigravity 類 AI coding agent 的團隊，這比單一修復率更接近真實工程風險。
SWE-Explore 是什麼？
SWE-Explore 的任務設定很簡單：給 agent 一個 repository 與一個 issue，要求它在固定行數預算下，回傳一組排序過的相關程式碼區段。
也就是說，它的評估焦點是：
| 評估問題 | SWE-Explore 關注點 | 為什麼重要 |
|---|---|---|
| 找到對的檔案嗎？ | file-level localization | 沒有進到正確檔案，後面修法通常只是猜測 |
| 找到對的行嗎？ | line-level coverage | 同一個檔案可能上千行，找錯區段仍會產生錯 patch |
| 排序有效嗎？ | ranking under budget | context window 有限，重要區段要排在前面 |
| 看太多雜訊嗎？ | context efficiency | 讀太多無關內容會稀釋注意力，也提高成本 |
| 探索分數和修復率有關嗎？ | downstream validation | 評測不能只漂亮，還要能預測真正修 bug 的結果 |
研究團隊用成功修復軌跡建立參考答案：如果多個獨立成功解法都讀過某些檔案或行號，這些區段就成為重要 context 的候選。這種做法不完美，因為成功軌跡讀過的內容不一定是唯一必要內容；但它比人工憑空標註大型 repo 的「正確行號」務實很多。
為什麼 SWE-bench 類分數還不夠？
SWE-bench 這類 repository-level benchmark 對 AI coding agent 很有價值，因為它把任務拉回真實 repo、真實 issue、真實測試。
但單看 resolved / unresolved 會混在一起很多原因：
- agent 根本沒找到相關檔案；
- agent 找到檔案，但漏掉關鍵函式或測試；
- agent 讀到正確 context，卻寫錯 patch；
- patch 合理，但測試覆蓋不足；
- tool runtime、dependency、timeout 或 sandbox 設定失敗。
這些失敗在最終分數上都長得一樣：沒有修好。
SWE-Explore 的價值，是把第一段「探索 repo」獨立拿出來量。這對企業導入尤其重要，因為採購或內部試點常常只問「哪個 agent 修復率最高」。真正該多問一題：它修之前看了什麼？
如果 agent 沒有可審查的探索軌跡，團隊就很難判斷錯誤來源。問題可能落在 retrieval、repo map、symbol search、test discovery、tool permission 或 prompt workflow 設計。
延伸到實務流程，可搭配站內的 AI Coding Agent 從 Issue 到 PR 的工作流 來看：issue 拆解、context 搜尋、patch、測試、review 是一條鏈，不能只看最後一步。
研究提醒：找到檔案，不等於找到答案
SWE-Explore 摘要中的關鍵句是：現代方法的 file-level localization 已經相對強，但 line-level coverage 與 efficient ranking 才是區分 state-of-the-art explorer 的核心。
換成工程語言，就是這樣：
Agent 常常能找到「大概是這裡」的檔案，卻不一定能找到「真正要讀」的那幾段。
這很符合日常 coding agent 使用經驗。你給它一個 bug，它可能很快打開正確 module，甚至能說出大致原因；但 patch 失敗時，常見原因是它沒有讀到：
- 旁邊的測試如何描述 edge case；
- 舊函式的 backward compatibility；
- 同一個錯誤在其他 adapter 的處理方式；
- 某個 helper 的特殊輸入約定；
- issue 裡提到的 stack trace 對應到哪個 branch；
- 型別、schema、config 或 fixture 的隱含限制。
這也是為什麼「context window 變大」解不了所有問題。大 context 可以讓 agent 塞進更多檔案，但若排序與定位不好，只是把更多噪音放進同一個視窗。
對 Claude Code、Codex、OpenHands 類工具代表什麼？
SWE-Explore 的重點不在批評某一家模型。論文與 The Decoder 報導都提到，不同通用 coding agents 的探索行為有相似瓶頸；強模型可以調整表現，但不會自動消除 line-level context 問題。
對使用者來說，這代表選工具時不能只問：
- 它用哪個 frontier model？
- SWE-bench 分數多少？
- 能不能自動開 PR？
還要問：
| 要問的問題 | 實務檢查方式 |
|---|---|
| 它如何探索 repo？ | 是否有 symbol search、grep、AST、test discovery、call graph 或 repo map |
| 它如何顯示讀過的內容？ | run log 是否能看到檔案、行號、搜尋查詢、跳過理由 |
| 它是否能收斂 context？ | 是否會把候選區段排序，避免無限制塞入整個檔案 |
| 它如何避免漏測試？ | 是否主動找相關 test、fixture、snapshot 與 reproduction case |
| 它是否能交代不確定性？ | patch 前是否說明還缺哪個資訊，避免假裝已完全理解 |
| 團隊能不能 review 它的探索過程？ | PR 描述是否包含「讀了什麼、為什麼改、怎麼驗證」 |
這也解釋了為什麼 AI 產生的 PR review checklist 不該只檢查 diff。Reviewer 應該看 agent 的 context trail：它讀了哪些檔案？有沒有跳過測試？有沒有只根據錯誤訊息猜 patch？
團隊導入時的 6 個防呆做法
1. 要求 agent 在 patch 前列出 context plan
不要一開始就叫 agent「直接修」。比較穩的 prompt 是先要求它輸出：
- 可能相關的檔案與原因
- 已讀過的行號範圍
- 還需要確認的測試或 fixture
- 暫時不應修改的檔案
- 下一步最小 patch 計畫這會迫使 agent 把探索階段顯性化，效果比單純讓回答更漂亮重要。若它連 context plan 都說不清楚，後面的 patch 更應該小心。
2. 把「行級 evidence」放進 PR 描述
AI agent 開 PR 時，PR 描述不該只有摘要。至少要包含：
- 問題對應的 source lines；
- 修改前後的行為差異；
- 哪些 tests 驗證了這個改動；
- 哪些相關檔案被檢查但沒有修改；
- 哪些風險仍需要人類判斷。
這能把 SWE-Explore 關心的 line-level localization 轉成團隊可 review 的交付物。
3. 不要把整個 repo 全塞給模型
大型 context 會降低「找不到」的機率，但也提高雜訊、成本與誤讀風險。更好的做法是分階段：
- 用搜尋、symbol、test name、stack trace 找候選檔案；
- 讀候選檔案的相關區段；
- 再讀 tests、fixtures、caller / callee；
- 最後才補充整檔或架構文件。
這種流程比「把 20 個檔案一次塞進去」更容易審查，也更符合 SWE-Explore 的 ranking under budget 精神。
4. 把探索失敗納入工具評估
企業評估 coding agent 時，不要只統計「修了幾個 issue」。應額外記錄：
- 有多少失敗是找錯檔案；
- 有多少失敗是找對檔案但漏掉測試；
- 有多少失敗是 context 足夠但 patch 寫錯；
- 有多少失敗是工具權限、環境或 dependency 問題；
- 哪些任務需要人類補 context 後才成功。
這會讓 企業 AI coding agent 評估 更接近真實 ROI，避免只看 vendor demo。
5. 讓 coding agent 少做「看起來順手」的事
SWE-Explore 處理的是 context 找不準；另一篇 OverEager 研究處理的是 agent 做太多。兩者剛好互補：一個是「沒看夠」，一個是「改太多」。
如果團隊同時忽略兩件事，最危險的組合會出現：agent 讀得不夠準，卻很有自信地改很大。
可搭配 Overeager coding agents 研究解析 一起建立政策：先限制修改範圍，再要求 context evidence，最後才允許 patch。
6. 對台灣團隊：先改流程，不急著換最貴模型
繁中與台灣工程團隊常遇到的現實限制，包含 repo 文件不完整、測試不穩、issue 寫得太短、domain knowledge 留在少數資深工程師腦中；frontier model 只是其中一個條件。
在這種情境下，直接升級模型通常只能局部改善。更有效的投資順序是：
- 把 issue template 寫清楚，要求 reproduction、expected behavior、scope；
- 讓 agent 先輸出 context plan；
- 補測試命名與 fixture 文件；
- 在 PR template 加入 AI context evidence；
- 再比較 Claude Code、Codex、Cursor、OpenHands 等工具的差異。
工具很重要，但流程會決定工具能不能穩定發揮。
這篇研究能回答哪些 coding agent 問題？
| 讀者問題 | 回答角度 |
|---|---|
| SWE-Explore 是什麼 | 評估 coding agent repository exploration 的 benchmark |
| SWE-Explore 和 SWE-bench 差在哪 | SWE-bench 看最終修復，SWE-Explore 看修復前是否找到正確 context |
| AI coding agent 為什麼會修錯 | 常見原因是 line-level context 不足，模型寫 code 能力只是其中一環 |
| Claude Code / Codex 怎麼評估 | 除了成功率，也要看探索軌跡、行號 evidence、測試查找與 PR 說明 |
| 企業如何導入 AI coding agent | 建立 context plan、PR evidence、最小修改、測試與人工 review gate |
| 台灣工程團隊該注意什麼 | 先改善 issue、測試、文件與 review 流程，再追求更強模型 |
限制與可信度
這篇判斷基於公開論文、GitHub repo、Hugging Face dataset 與媒體報導，沒有在本地重跑 SWE-Explore benchmark，也沒有替任何 vendor 做重新排名。
幾個限制要先說清楚：
- line-level ground truth 來自成功 agent trajectories，不等於唯一正解；
- 848 個 issues 很有參考價值，但不一定代表所有企業 monorepo；
- 不同 coding agent 的工具權限、repo access、prompt、runtime 會影響結果；
- benchmark 分數不應直接等同於生產環境安全性；
- 研究聚焦探索階段，沒有完整取代 code review、測試、資安檢查與 rollout 評估。
可信的用法，是把 SWE-Explore 當成一個提醒：評估 AI coding agent 時，把「它是否找到正確 context」納入正式指標。這篇文章的焦點是 context localization；模型參數規模、授權條款與自架部署可行性只會影響實驗外推，無法取代 line-level evidence。
Mason 的觀點：下一個護城河是 context localization
AI coding agent 過去一年最醒目的競爭，是誰能修更多 SWE-bench issues、誰能從 issue 開 PR、誰能跑更久的任務。
SWE-Explore 把注意力拉回一個比較不炫、但更靠近工程現場的問題：修 code 之前，先找到該讀的 code。
我們認為這會成為下一輪差異化。未來強的 coding agent 需要同時做到：
- 快速建立 repository map；
- 找到 bug 相關的最小程式碼區段；
- 用測試與呼叫鏈驗證 context；
- 避免把無關檔案塞滿 context；
- 在 PR 裡留下可審查 evidence；
- 知道自己 context 不足時先停下來問。
對團隊來說，最務實的結論是：可以用 AI coding agent，但不要把 agent 當成神祕黑盒。讓它顯示探索過程，讓 reviewer 檢查 context evidence，讓工具只在足夠資訊下動手。
會寫 code 的模型會越來越多；能穩定找到正確上下文、說明判斷依據、並被工程流程治理的 agent，才比較可能進入真正的 production workflow。
FAQ
SWE-Explore 是新的 AI coding agent 排行榜嗎？
它比較像探索階段的評測框架，排行榜只是其中一種呈現方式。SWE-Explore 要求 agent 在固定行數預算下回傳相關程式碼區段，用來評估 repository exploration、context retrieval、code localization 與 ranking quality。
SWE-Explore 和 SWE-bench 最大差異是什麼？
SWE-bench 類評測通常看最後是否修好 issue；SWE-Explore 把修復前的探索階段獨立出來，看 agent 是否找到真正需要讀的檔案與程式碼行。兩者可以互補，而不是互相取代。
這代表 Claude Code、Codex 或其他 agent 不可靠嗎？
不代表。研究更精準的提醒是：現代 coding agent 已比傳統檢索方法強，但 file-level 命中不等於 line-level context 足夠。使用這些工具時，要看探索軌跡、測試證據與 PR 可審查性，模型名稱只能當作其中一個參考。
一般工程團隊可以怎麼採用 SWE-Explore 的觀念？
最簡單的做法是要求 agent 在動手前輸出 context plan，在 PR 描述中列出讀過的檔案與行號，並把「找錯 context」納入失敗分析。這些流程不需要重跑 benchmark，也能提升 AI coding agent 的可審查性。