許多工程師目前使用 AI 開發工具（如 Cursor 或 Claude Code）時，常陷入一種被稱為 Vibe Coding 的狀態。簡單來說，就是憑感覺寫程式：輸入一個 Prompt，AI 生成一大段程式碼，看起來跑得通就合併。但這種開發模式在企業級產品中隱藏著巨大的風險。當 AI 生成的程式碼佔比提高，但缺乏嚴謹的驗證時，開發瓶頸會從寫程式轉移到代碼審查（Code Review）與除錯（Debugging），甚至導致安全漏洞增加。
要突破這個生產力天花板，我們不能只依賴單一的 AI 聊天視窗，而需要構建一套多代理人系統（Multi-Agent System, MAS）。這不是簡單地把 LLM 放入 CI/CD 流程，而是建立一個由不同專業角色組成、能相互制衡且持續學習的自動化體系。
多代理人體系的關鍵角色
在一個可靠的 AI 開發體系中，不能讓同一個 AI 既當創作者又當審核者，因為 LLM 傾向於認同自己的邏輯。我們需要將其拆分為不同的代理人：
測試代理人（Testing Agent） 將測試視為可執行的規格書。測試代理人不僅負責生成單元測試，更重要的是透過執行結果來反饋程式碼是否正確。實務上，同時使用 AI 進行測試與開發的團隊，其整體產能提升最為明顯，因為測試過程強迫 AI 與工程師更深入地思考邊界條件。
審查代理人（Review Agent） 審查代理人的目標是擔任門衛（Gatekeeper）。它不應只根據通用知識審查，而必須結合團隊的特定標準（Best Practices）。例如，透過定義自定義規則（Customized Compliance），讓 AI 知道團隊對於 if 語句或錯誤處理的具體偏好，將技術領袖的經驗轉化為可自動執行的審查規則。
上下文引擎代理人（Context Engine Agent） 這是整個系統的基石。目前的 RAG（檢索增強生成）已演進為專門負責獲取上下文的代理人。它不再只是簡單的向量檢索，而是能主動從 PR 歷史、架構文件（ARCHITECTURE.md）、日誌以及組織規則中抓取資訊。如果上下文不足，AI 就會產生幻覺（Hallucination），這也是 88% 工程師認為 AI 工具失效的主因。
多代理人架構的設計挑戰
當我們將這些代理人組合在一起時，會面臨三個核心工程問題：
通訊與可觀察性 代理人之間可以透過 MCP（Model Context Protocol）等協議通訊，但對工程師而言，最重要的是通訊過程必須可視化。建議將代理人的互動紀錄在 GitHub PR 或類似的 UI 界面中，而不是隱藏在後台日誌裡，這樣人類才能在必要時介入審查。
仲裁機制（The Arbiter） 當測試代理人說程式碼有錯，但開發代理人堅持正確時，誰說了算？這需要一個仲裁者角色。仲裁者的核心能力在於對規格（Spec）的嚴格要求。如果初始的規劃規格不夠完整，仲裁者就無法判斷誰對誰錯。因此，系統必須在規劃階段就強制要求補全資訊。
權限與治理（Governance） 不同代理人應擁有不同權限。例如，測試代理人需要存取 Staging 環境以驗證功能，但開發代理人為了安全，不應直接接觸運行環境。
從 Vibe Coding 轉向 Viable Coding
我們追求的目標並非放棄 AI 帶來的流暢感（Flow），而是將 Vibe-Driven Development（憑感覺開發）轉化為 Viable Coding（可行的開發）。
這意味著在保持開發流暢度的同時，將品質門檻前移（Shift-Left）。在程式碼寫完之前，就讓審查代理人與測試代理人介入規劃階段。透過這種多代理人的制衡體系，AI 不再僅僅是一個快速生成文字的工具，而是一個能夠自我驗證、符合企業標準且可控的軟體工程系統。
對於工程團隊的建議
不要試圖一次性構建完整的 MAS 體系。建議先找出目前 SDLC（軟體開發生命週期）中的最大瓶頸。如果 PR 堆積嚴重，先導入審查代理人；如果 Bug 率過高，先強化測試代理人。逐步將 AI 注入每個環節，最終形成一個能持續學習團隊品質標準的適應性系統。
來源：infoq.com (The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。