AI Coding Agent 的真正瓶頸：當模型不再是問題，問題就出在工程管線

在實地部署 AI coding agent 的過程中，我觀察到一個顯著的瓶頸轉移。過去我們多半聚焦於模型生成程式碼的品質，但隨著 GPT-4o、Claude 3 等模型的飛速進步，這個問題已不再是主要障礙。真正的挑戰，反而落在 AI 與既有工程基礎設施的整合介面上——那些我們稱之為「執行接縫」（execution seams）的環節，例如 Git 操作、CI/CD 流程、API 認證與網路狀態處理。這意味著，AI 代理的競爭力已從模型本身，轉向整條工程管線的魯棒性與容錯能力。

當模型寫的程式碼已足夠好時，問題在哪裡？

大型語言模型（LLM）在程式碼生成方面的能力，近年來有了驚人的突破。從撰寫複雜的函式、產生單元測試，到執行整個專案的重構，頂尖模型的表現有時甚至能超越一般的人類工程師。這讓我們很容易產生一種錯覺：只要模型夠強，打造一個全自動的 AI 程式設計師就指日可待。然而，當我們將這些聰明的代理程式放進真實的開發環境時，才發現事情沒有這麼簡單。

一個模型產出的程式碼，無論多麼優雅或高效，如果無法順利地被版本控制系統接收、通過自動化測試、並成功部署，那它就毫無價值。這就像一位才華洋溢但與世隔絕的開發者，他能寫出曠世巨作，卻不知道如何使用 Git 提交程式碼、看不懂 CI/CD 的錯誤報告，或是在需要 API 金鑰時束手無策。

在工程實務中，純粹的程式碼撰寫，可能只佔整個開發流程不到 50% 的時間；其餘大量的時間，都花在與工具鏈、基礎設施和團隊協作上。這正是當前 AI coding agent 面臨的窘境：它們的「智商」（程式碼生成能力）越來越高，但「情商」與「實作能力」（與真實世界工程系統互動的穩健性）卻嚴重滯後。瓶頸已經從「能不能寫出好程式」，轉移到「能不能在真實、混亂且充滿意外的環境中，可靠地完成任務」。

AI 代理在哪些「執行接縫」上容易跌倒？

所謂的「執行接縫」，就是 AI 代理的認知空間（模型內部）與外部物理世界（檔案系統、網路、工具鏈）的交界處。這些接縫非常脆弱，也是失敗最常發生的地點。根據日本開發者 zoe-taka 在 Zenn.dev 上的實務分享，以及我自身的經驗，AI 代理經常在以下幾個看似簡單的環節中失效：

• Git 操作的微妙之處：AI 代理可以輕易生成 git commit 或 git push 指令，但它能處理非預期的 merge conflict 嗎？當遠端分支被強制更新（force push）後，它懂得如何正確 rebase 嗎？當 SSH key 權限突然失效時，它能從錯誤訊息中判斷問題並尋求協助嗎？這些對人類來說相對直觀的情境，對 AI 卻是巨大的挑戰。
• CI/CD 流程的非預期狀態：一個 CI pipeline 可能會因為測試環境的網路抖動而偶然失敗，也可能需要等待超過 30 分鐘才能完成。人類工程師會憑經驗判斷「這只是暫時性問題，重跑一次就好」或是「這個測試卡住了，需要手動介入」。但 AI 代理缺乏這種情境感知能力，它很可能在第一次失敗後就直接放棄，或陷入無限等待的死循環。
• 認證與權杖管理：現代開發流程高度依賴各種 API 權杖（例如 GitHub token、雲端服務 access key）。這些權杖會過期，需要刷新。AI 代理是否有能力安全地儲存、管理並在必要時刷新這些權杖？這不僅是技術問題，更涉及高度的安全性考量。
• 網路與外部工具的不可靠性：AI 代理在執行任務時，可能需要查詢外部文件、下載依賴套件、或呼叫第三方 API。任何一次網路超時、DNS 解析錯誤、或 API 回傳非預期的 503 Service Unavailable 狀態碼，都可能中斷整個任務流程。

人類工程師在這些環節中，憑藉著大量隱性知識與直覺，下意識地避開了許多地雷。但對 AI 代理來說，每一個預期外的 shell 輸出、每一次超時，都可能是一次無法恢復的任務失敗。

史丹佛大學發表的 SWE-bench 評測框架，就深刻體現了這個挑戰。它要求 AI 代理在真實的 GitHub issue 中修復 bug，這不僅考驗程式碼生成，更考驗代理程式理解專案結構、運行測試、並與版本控制系統正確互動的「全棧工程能力」。許多在單純程式碼生成任務上表現優異的模型，在 SWE-bench 上的成功率卻不到 5%，這正是「執行接縫」脆弱性的最佳證明。

如何加固這些接縫，打造更可靠的 AI 代理？

既然問題的核心在於執行層面的魯棒性，我們的解決方案也應該從這裡著手。這不再是單純追求更大、更強的語言模型，而是需要細膩的軟體工程與系統設計。

首先是強化狀態管理與錯誤處理。AI 代理需要一個強健的狀態機來追蹤任務進度，並針對每一個可能的失敗點設計明確的重試（retry）與恢復（recovery）策略。

例如，當 git push 失敗時，不應直接放棄，而應解析錯誤碼，嘗試重新驗證、拉取最新程式碼（git pull --rebase）後再試一次。這需要將人類工程師的除錯直覺，轉化為代理程式可以遵循的結構化規則。

其次是建立更穩定的工具抽象層。與其讓 AI 直接操作原始的 shell，不如為它提供一組更高階、更穩定的 API。

例如，設計一個 safe_push_to_remote() 函式，內部封裝了認證檢查、自動重試、衝突解決等複雜邏輯。這樣一來，AI 就可以專注於「要做什麼」（What）的策略層面，而不是「該怎麼做」（How）的繁瑣細節。這也是 LangChain 或 AutoGen 這類代理框架試圖解決的核心問題之一：為 AI 提供可靠的工具集。

最後，提升系統的可觀測性（Observability）至關重要。當 AI 代理失敗時，我們需要詳盡的日誌、追蹤（tracing）與指標（metrics）來快速定位問題根源。究竟是模型理解錯誤、工具執行失敗，還是外部環境異常？沒有良好的可觀測性，除錯 AI 代理將會像大海撈針，極大地阻礙了系統的迭代與優化。

總結來說，AI coding agent 的發展已經進入了下一個階段。當模型的智慧逐漸商品化（commoditized），真正的差異化優勢將來自於那些能夠打造出最穩定、最可靠、最能適應真實世界混亂的工程執行系統的團隊。戰場已經從演算法的象牙塔，轉移到了泥濘的工程第一線。

延伸閱讀

• AIコーディングエージェントを本番で回し始めて分かったこと
• SWE-bench: Can Language Models Solve Real-World Software Engineering Problems?
• Git Official Documentation

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。