多智能體軟體開發本質上是分散式系統問題

背景

隨著大型語言模型（LLM）的應用從單一對話轉向多代理（Multi-agent）協作，開發者開始面臨如何讓多個代理有效協作以完成複雜軟體工程的問題。本文作者 Kiran 提出一個核心論點：多代理軟體開發本質上是一個分散式系統問題，即便未來人工智慧達到通用人工智慧（AGI）的程度，也無法逃避分散式共識與協調的數學限制。

社群觀點

在 Hacker News 的討論中，社群對於「多代理協作是否等同於分散式系統問題」持有分歧但深刻的見解。部分評論者認為作者過於執著於數學證明，忽略了人類開發大規模軟體（如 Linux 核心）的既有事實。他們指出，人類開發者同樣面臨資訊不對稱與協調挑戰，但透過迭代與溝通解決了問題，因此不應斷言 AI 代理無法克服這些障礙。然而，支持作者觀點的網友則反駁，多代理協作中的「主導代理」或「編排者」角色，實際上就是在執行分散式協議中的兩階段提交（2-Phase Commit），這證明了分散式演算法的理論框架確實適用於分析 AI 工作流。

關於代理數量的效能問題，社群中出現了對「代理過剩」的警惕。有觀點認為，目前市場上推崇的多代理架構有時更像是為了增加 Token 消耗量的行銷手段。類比於現實開發環境，雇用大量廉價的初級開發者往往會導致溝通成本激增而非效率提升，代理系統若缺乏精確的架構設計，同樣會陷入協調地獄。更有網友引用康威定律（Conway’s Law）指出，良好的軟體架構與協作模式不會因為代理數量增加而自動湧現，關鍵在於「架構師」角色的缺失。

另一派討論則聚焦於 LLM 的本質差異。有評論者質疑將代理視為獨立分散式節點的合理性，認為 AI 代理的挑戰更多在於上下文注意力、關聯性以及單一有序緩衝區內的操作，而非傳統分散式系統中的獨立機器失效或網路延遲問題。此外，關於「迭代」是否能解決共識問題也引發熱議：如果主代理能不斷審查與修正子代理的程式碼，這種序列化的回饋迴路或許能規避並行開發帶來的衝突，但這也意味著系統可能退化回單一代理的邏輯，或是必須擁有極大的上下文視窗才能實現。

最後，社群達成了一種微妙的共識，即「共享狀態」是萬惡之源。借鑑微軟服務的經驗，代理若能被限制在極小的關注點內（如僅負責執行測試或 Lint 檢查），其表現通常最為穩定；一旦涉及共享狀態的協作，複雜度便會呈指數級增長。這印證了作者的預警：開發者在構建多代理系統時，必須嚴肅對待協調邏輯，而非寄望於模型能力的提升能自動消解這些結構性難題。

延伸閱讀

• Prompting Guide: Knowledge Retrieval - 關於如何透過提供外部知識或證明來提升 LLM 準確性的技術說明。
• Semantik - 討論中提到的上下文經紀人工具，旨在處理代理協作中的資訊關聯性問題。