「總體來說，agents 可能會突然崩潰。」這句話聽起來像是在描述某個不穩定的分散式系統，而不是在談論 AI agents 的未來。但這正是問題的核心：當我們把多個 AI agents 放在一起協作軟體開發時，我們其實是在重新設計分散式系統。

一個值得思考的問題

如果你讓一個 AI agent 負責寫程式碼，另一個負責測試，第三個負責部署，這三個 agents 之間要如何協調？當其中一個突然「崩潰」——不管是因為 API 超時、模型產生無效輸出，還是單純遇到不明的錯誤——整個流程會怎麼變？

這不是假設性的問題，而是任何嘗試建立 multi-agentic 開發環境的人都會遇到的現實難題。

為什麼 Multi-Agentic 是分散式系統問題？

在傳統的分散式系統中，我們有幾個經典問題：訊息傳遞的可靠性、節點的故障處理、最終一致性、以及協調協定。這些問題在 AI agents 的世界裡，一個都沒少，而且更複雜。

訊息傳遞更不可靠。AI 的輸出不是確定性的函數呼叫，而是基於語境的機率產生。今天讓 agent A 告訴 agent B「修復這個函式的 bug」，B 可能給你一個完美的 patch；明天同樣的輸入，B 可能給你一段完全無關的程式碼，或者產生格式錯誤的輸出。

節點故障的模式更難預測。在傳統系統裡，節點通常是「可用」或「不可用」的狀態。但 AI agent 有第三種狀態：它在回應，但回應是錯的。這比完全沒回應更難處理，因為你需要額外的檢驗機制來判斷「這個回應是不是真的有用」。

最終一致性？AI agents 之間的協作可能永遠達不到一致性，因為每個 agent 對同一個需求的理解都可能不同。A 說「優化效能」，B 可能理解為「減少 API 呼叫」，C 可能理解為「加快資料庫查詢」。三個人可能給你三種不同的方向。

從單一 Agent 到 Multi-Agent：複雜度跳升

單一 AI coding agent 的使用模式相對簡單：給它一個任務，它給你一段程式碼。即使程式碼有問題，你還是可以手動修復，或者給它更清楚的指令。

但在 multi-agentic 的環境裡，這種簡單性消失了。你需要設計：

角色分配協定：誰負責架構？誰負責實作？誰負責測試？誰負責 code review？如果遇到超出角色範圍的問題，要怎麼轉發？

狀態同步機制：當 agent A 修改了一個檔案，agent B 和 C 如何知道？是透過 event system？定期檢查？還是某種共用的狀態資料庫？

錯誤恢復策略：如果 agent B 產生的程式碼無法編譯，誰來修復？是 B 自己重試？還是交給一個「修復 agent」？修復失敗的話，要如何通知人類介入？

衝突解決方案：當 agent A 和 agent C 同時修改同一個檔案的不同部分，或者對同一個問題提出相反的解決方案，誰來仲裁？

這些都不是新問題。分散式系統工程師過去幾十年已經花了很多時間在解決這些問題。但關鍵在於：AI agents 不是標準的服務，它們有自己獨特的特性，讓這些經典問題變得更難處理。

為什麼驗證研究者會感到無力？

文章中提到的觀察很值得注意：即使是應該知道更好的驗證研究者，對當前的狀況也有一種「apathy」（冷漠或無力感）。

這不是因為他們不在乎，而是因為這個問題實在太大了。在傳統的軟體驗證領域，我們可以建立形式化的模型、驗證協定的正確性、證明系統在某些假設下的安全性。但對於 AI agents，這些方法都遇到難以克服的挑戰。

形式化模型需要確定的行為。AI 的核心就是不確定。驗證協定需要明確的介面規格。AI 的介面是自然語言，本身就有模糊性。證明系統的安全性需要完整的狀態空間。AI 的輸出空間在理論上是無限的。

於是，驗證研究者選擇了一條更實際的路：不要試圖從根本上證明系統的安全性，而是建立監控機制、記錄日誌、提供回饋迴路。這聽起來像是在放棄，但實際上是在接受現實。

實務上如何處理 Multi-Agentic 開發？

理論上的困難不代表實務上無法使用。很多團隊已經在實驗 multi-agentic 開發流程，而且有些方法看起來相當可行。

第一，限制協作的深度

不要試圖讓 agents 自主協作完成整個專案。限制在單一任務的範圍內，例如：「寫一個單元測試來覆蓋這個函式的所有邊界情況」，或者「審查這個 PR 並指出潛在的安全性問題」。

這種淺層的協作更容易控制，出錯的影響也有限。

第二，建立明確的協定

即使 AI 的輸出不確定，你還是可以定義清楚的輸入輸出規格。例如，要求測試 agent 的輸出必須符合某種特定的 JSON 格式，包含測試名稱、輸入參數、預期輸出等欄位。

如果輸出格式不符，可以直接拒絕並要求重試。這聽起來很基本，但在實務上可以避免大量混亂。

第三，使用人類作為最終仲裁者

不要讓 agents 自主做出關鍵決策。讓它們提供建議，但讓人類來做最終的決定。例如，agent 可以指出程式碼中的潛在問題，但不應該直接修改生產環境的程式碼。

這個聽起來像是「半自動化」而不是「全自動化」，但這可能是目前最可行的路徑。

第四，建立完善的日誌和追蹤

當 agents 之間的協作出問題時，你需要能夠回溯發生什麼。記錄每個 agent 的輸入輸出、時間戳、決策邏輯。這不僅是為了除錯，也是為了建立可重現的流程。

分散式系統的智慧應用在哪裡？

好消息是，我們其實已經有很多分散式系統的智慧可以借用。例如：

Saga pattern：用來處理跨服務的長事務。如果某個步驟失敗，可以執行補償事務來回滾前面的操作。在 AI agents 的語境裡，如果 agent B 的輸出無法通過測試，可以讓 agent C 執行補償操作。

Circuit breaker：如果某個 agent 持續產生錯誤的輸出，可以暫時停止對它的請求，直接回退到備用策略或人類介入。

Leader election：當多個 agents 可能對同一個任務提出不同的解決方案時，可以用某種機制選擇「最佳」的方案。這可能是基於某些評分指標，或者基於歷史成功率。

這些 pattern 不是為了 AI agents 設計的，但它們提供了一個起點。關鍵是要認識到：multi-agentic 開發不是一個全新的領域，而是分散式系統在新的約束下的變形。

現階段的實際建議

如果你想在你的團隊裡嘗試 multi-agentic 開發，這裡有一些實際的建議：

從小開始。不要試圖替換整個開發流程。選擇一個小而明確的任務，例如自動產生單元測試，或者自動化 code review 的部分檢查項目。

建立清晰的邊界。明確定義每個 agent 的職責範圍，以及它們之間的互動方式。這可以減少協調的複雜度。

監控和度量。追蹤 agents 的成功率、回應時間、錯誤類型。這些數據會告訴你哪裡需要改進。

保持人類在迴路中。不要讓 agents 自主運行太久。定期審查它們的輸出，確保方向沒有偏離。

未來的走向

從目前的研究和實務經驗來看，multi-agentic 軟體開發不會在一夜之間取代傳統的開發流程。它更有可能逐漸融入開發工具中，成為另一種自動化層級。

例如，你的 IDE 可能會內建多個專門的 agents：一個負責自動完成程式碼，一個負責即時的語法檢查，一個負責建議重構。這些 agents 在背景協作，但你作為開發者依然在掌控全局。

這聽起來不像「AI 取代開發者」的劇情，而更像「AI 讓開發者更有效率」的漸進式改變。這種改變需要時間，需要工具，更需要對分散式系統問題的深刻理解。

所以回到最初的問題：multi-agentic 軟體開發真的是分散式系統問題嗎？答案是肯定的。而且可能比傳統的分散式系統更複雜。但這不代表無法解決，只是需要更多的思考、實驗和從失敗中學習。

當你看那些在 GitHub 上爭論如何設計 multi-agent 架構的討論串，或者閱讀那些關於「agents 可能會突然崩潰」的研究論文，你會感覺到這個領域正在經歷分散式系統早期的階段：充滿困惑、嘗試，但也有無限的可能性。

這不是一個會很快解決的問題，但這正是讓它有趣的原因。