「虛擬公司」的陷阱：為何頂尖 AI Agent 架構都轉向了「狀態文件」

在建構多 Agent 系統的過程中，一個極具吸引力的比喻是「虛擬公司」。我們想像著一個由 AI 組成的團隊：CEO Agent 負責擘畫策略，PM Agent 撰寫規格文件，Engineer Agent 根據規格產出程式碼，QA Agent 則進行測試。這個模型非常直觀，因為它完美映射了我們在人類世界中協作的經驗。然而，經過一段時間的實踐與觀察，我愈發確信，這個看似合理的類比，實際上是一個會引導我們走向低效、脆弱系統的工程陷阱。

問題的根源，在於我們誤將人類組織的協作模式，強加在一個運作原理完全不同的基底——大型語言模型（LLM）之上。人類之所以需要明確的角色分工與「文件交接」，是因為我們的認知資源有限。一位產品經理無法同時記住市場所有需求、技術所有限制與使用者所有回饋，因此他需要將思考「壓縮」成一份規格文件（PRD），交給工程師。這個交接過程，本質上是一種為了克服人類記憶與注意力瓶頸的、有損的資訊傳遞。工程師再根據這份被壓縮過的資訊，在自己的專業領域內進行「解壓縮」與實作。

但 LLM 不同。對 LLM 而言，並不存在獨立的「PM Agent」或「Engineer Agent」個體。每一次的呼叫，都是在一個給定的上下文（Context）中進行一次性的推理。當我們讓 PM Agent 生成一份 PRD，再將這份 PRD 交給 Engineer Agent 時，我們做的並不是資訊傳遞，而是建立了一個割裂的、不連續的推理鏈。Engineer Agent 必須從頭閱讀、理解這份 PRD，這個過程不僅消耗了寶貴的 Token，更嚴重的是，它遺失了 PM Agent 在生成 PRD 過程中的所有中間思考與權衡——那些沒有被寫進最終文件，卻至關重要的隱性脈絡。

這就引出了多 Agent 系統設計的核心瓶頸。許多人認為瓶頸在於 LLM 的注意力（Context Window 長度），但更關鍵的制約因素，其實是「推理深度」（Depth of Reasoning）。一個能夠解決複雜問題的系統，需要的是一條長而連貫的思考鏈，讓每一次的推理都能建立在前一次的基礎上，層層遞進。角色扮演與文件交接的模式，恰恰是反其道而行。它人為地製造了邊界，不斷打斷這條推理鏈，迫使模型在每一個環節都重新啟動思考，這極大地限制了系統能達到的複雜度上限。

想像一下，你要求一位頂尖工程師解決一個難題。你是希望他能沉浸其中，心無旁鶩地從頭到尾思考、實作、除錯，還是每隔十分鐘就打斷他，讓他向一位新的專案經理匯報進度，然後再由這位經理轉述給下一位接手的工程師？答案顯而易見。我們給予人類專家的，是連續的時間與完整的資訊；我們給予 AI Agent 的，也應該是同樣的東西。

那麼，如果「虛擬公司」是個陷阱，那條正確的路是什麼？從 Anthropic、OpenAI 到 Google 等頂尖團隊的實踐中，我們看到了一個清晰的趨勢：放棄角色扮演的對話模式，轉向以「狀態文件」（State File）為核心的架構。

這個架構的核心思想很簡單：所有 Agent 不再互相「對話」或「交接」，而是共同讀寫一份中央的、不斷演進的狀態文件。這份文件就像是整個專案的「單一事實來源」（Single Source of Truth）。它可以是一份 Markdown 文件、一個 JSON 物件，或任何結構化的文本。任務的每一步進展，都是對這份文件的一次追加或修改。

舉個例子，一個自動化開發流程可能會是這樣：

1. 初始狀態：使用者需求被寫入 `state_v0.md`。
2. 規劃階段：一個專門負責「規劃」的 Agent（或更精確地說，是帶著「規劃」指令的 LLM 調用）讀取 `state_v0.md`，將其分解成詳細的執行步驟，並將這些步驟追加到文件末尾，生成 `state_v1.md`。這份文件現在同時包含了原始需求和執行計畫。
3. 開發階段：一個負責「編碼」的 Agent 讀取 `state_v1.md`，根據計畫撰寫程式碼，並將程式碼區塊附加進去，生成 `state_v2.md`。此刻，文件裡有需求、計畫、還有程式碼。
4. 測試與修正：一個負責「除錯」的 Agent 讀取 `state_v2.md`，執行程式碼，發現錯誤，然後將錯誤日誌、分析和修正後的程式碼一併寫入文件，生成 `state_v3.md`。

整個過程，沒有任何一份獨立的「交接文件」被產生。所有的上下文、所有的歷史紀錄、所有的推理過程，都被完整地保留在這份不斷增長的狀態文件中。當任何一個 Agent 需要執行任務時，它都能看到從起點到當下的完整脈絡。這最大限度地保留了推理鏈的連續性，讓 LLM 可以在一個極其豐富且連貫的上下文中進行深度思考。

這種模式的優勢是顯而易見的：

• 推理連續性：這是最大的好處。LLM 不再需要從零開始理解一份新文件，而是可以在一個完整的、累積的脈絡上繼續工作，從而能夠處理更複雜、更長鏈條的任務。
• Token 效率：我們不再浪費 Token 在模擬人類對話的繁文縟節上（例如「你好，工程師 Agent，這是 PM Agent 給你的規格...」）。上下文中的每一個 Token 都是高密度、高價值的資訊。
• 可追溯性與可除錯性：這份狀態文件本身就是一份完美的執行日誌。當系統出錯時，我們可以回溯整個文件的演變過程，精準定位問題出在哪一個環節的哪一次修改。這對工程化與維護至關重要。

當然，這種架構也帶來了新的挑戰，這也正是我們這些系統建構者應該關注的焦點。我們的工作重心，將從「如何設計巧妙的 Agent 角色與對話流程」，轉向「如何進行高效的上下文工程（Context Engineering）」。我們需要設計狀態文件的格式，使其既能被人和機器輕易讀懂，又能高效地傳遞資訊。我們需要管理上下文的增長，在不超出模型限制的前提下，保留最有價值的資訊。我們需要思考如何讓不同的 Agent（或不同的任務模組）以一種標準化的方式與這份狀態文件互動。

這是一次深刻的典範轉移。我們必須停止用擬人化的思維去束縛 AI，停止將源於人類認知局限的協作模式，當成放諸四海皆準的真理。LLM 不是廉價的人類勞動力，它是一種全新的資訊處理與推理引擎。要釋放它的全部潛力，我們需要為它設計符合其本質的、LLM-Native 的架構。觀察行業領導者的動向，他們無一例外地放棄了「虛擬公司」的浪漫想像，轉而投身於更務實、更強大的狀態管理工程。對我們所有 AI 系統的建構者而言，這不僅是一個技術選擇，更是一種思維模式的躍遷。我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。