很多開發者在接觸 AI Agent（能自主執行任務的 AI 代理）時，常會對其自動修復 Bug 的能力抱有高度期待。目前的共識通常認為，只要能透過 RAG（檢索增強生成，一種讓 AI 能在回答前先從外部知識庫搜尋相關資訊的技術）提供更精準的程式碼片段，AI 就能更有效地解決問題。然而，近期針對 Kubernetes 這種超大型專案的基準測試顯示，提升檢索能力並不等於提升修復品質。
在這次的實驗中，研究者使用了真實的 Kubernetes Bug 報告作為測試集，讓 AI Agent 在不知道正確答案（PR 內容）的情況下，僅憑 Issue 描述來嘗試修復。為了測試不同的程式碼獲取方式，實驗設計了三種配置：一種是純 RAG 模式，透過向量資料庫快速抓取片段；一種是混合模式，先用 RAG 定位再進入本地檔案系統深入探索；另一種則是直接讓 AI 讀取本地整個程式碼庫。
從效能與成本來看，純 RAG 模式最快且最便宜，因為它跳過了檔案系統的導航過程。混合模式則最慢且最昂貴，主因在於它觸發了更多次的模型調用，而由於 API 是無狀態的，每次調用都需要重新傳送之前的對話歷史，導致 Token 消耗劇增。
然而，最關鍵的發現在於正確性。實驗發現，AI Agent 失敗的主要原因並非「寫錯程式碼」，而是「修得不完整」。AI 往往在解決了表面上的核心問題後就停止工作，而忽略了系統性的連鎖反應。例如，它可能修好了主邏輯，卻忘了更新依賴的整合邏輯，或者在發現程式碼中已有部分修復跡象時就提前放棄。
這種現象揭示了 AI Agent 目前的一個重大缺陷：缺乏對系統全局影響的理解（System-wide Impact）。AI 傾向於解決眼前看到的 Bug，而不會主動詢問「還有哪些地方需要同步修改？」。此外，在架構選擇上，AI 傾向於創造新的抽象概念（例如定義一個新欄位）而非複用既有的架構設計，這會導致程式碼變得臃腫且不符合原有的設計哲學。
有趣的是，實驗發現檢索策略（RAG 或本地讀取）僅能影響 AI 「找到程式碼的速度」，而不能提升 AI 「推理的品質」。雖然強制使用 RAG 有時能逼迫 AI 先去尋找對應的策略層，進而做出較好的架構決定，但一旦進入實作階段，AI 依然受限於局部推理。
最令工程師感到意外的結論是：Issue 描述的品質比 RAG 架构更重要。當 Bug 報告寫得非常詳細，明確指出了出錯的文件、函數以及預期行為時，無論使用哪種檢索方式，AI 的表現幾乎一致且都相當優秀。這意味著，目前提升 AI 自動修復成功率最強大的槓桿，竟然是人類撰寫高品質 Bug Report 的能力。
總結來說，AI Agent 在大型專案中面臨的最大挑戰是「範圍發現」（Scope Discovery），也就是如何識別所有需要變動的模組。雖然可以嘗試透過結構化的技能集或 Playbook（操作指南）來輔助，但在快速迭代的大型專案中，維護這些指南的成本可能比手動修 Bug 還要高。對於 Junior 工程師來說，這提醒我們：AI 可以幫我們快速定位問題並提供初步方案，但審核其是否影響系統全局、是否符合既有架構，依然是人類工程師不可或缺的核心價值。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。