從檔案系統到狀態平面：為多代理 AI 系統打造低成本的協作中介層
當多個 AI 代理並行運作時，混亂往往源於缺乏共同的「現實感」。我們需要的不是更強大的模型，而是一個能讓所有代理共享任務狀態、分工與進度的中介層。本文將揭示如何把看似簡單的檔案系統，轉化為一個極簡卻高效的「協作基板」，巧妙解決多代理 AI 系統中最棘手的協調難題，讓你的 AI 團隊也能順暢合作。
當我們開始部署多個 AI 代理（agent）並行處理複雜任務時，很快會發現真正的瓶頸不是個別模型的智慧，而是它們之間混亂的協作。真正的稀缺資源，是一個能讓任務狀態、責任分工與進度變化被外部化、共享與追蹤的共同平面。近期一個有趣的實驗案例，展示了如何用最簡單的檔案系統，打造出一個低成本但極為有效的協作中介層（coordination substrate），這個思路遠比單純的可視化工具更有價值，它直指多代理系統的核心架構問題。
為什麼多代理系統的瓶頸不在模型，而在協調？
想像一個場景：你同時啟動了 5 個獨立的 AI 代理，分頭處理一個大型軟體開發專案的不同部分。一個代理負責寫 API、一個負責寫單元測試、一個負責修正 bug。只看終端機不斷滾動的日誌，你很快就會迷失：誰正在工作？誰卡住了？任務 A 的產出是否已經可以交給下一個代理？這種混亂源於缺乏一個集中、可觀測的「單一事實來源」（single source of truth）。
這不是新問題，而是分散式系統的老問題在新場域的重演。當多個獨立執行單元並行工作時，如果沒有一個明確的狀態管理與溝通機制，整個系統的效率與可靠性將急遽下降。在 AI 代理的脈絡下，這個問題更加尖銳，因為它們的行為具有不確定性。
為了解決這類協調難題，許多現有的多代理框架，例如 MetaGPT 提出的結構化工作流程，或 AutoGen 的對話式協作模型，都在試圖提供解決方案。然而，它們往往需要引入更複雜的內部狀態管理器或通訊協議，這無形中增加了系統的設計與維護成本。
然而，解決協調問題不一定需要複雜的工具。有時候，最優雅的解法反而是最簡單的。
檔案系統如何成為 AI 代理的共享「狀態機」？
那麼，這個實驗案例究竟是如何將看似普通的檔案系統，轉化為一個高效的 AI 代理協作基板呢？其核心思想，是將檔案系統本身視為一個共享的「狀態機」。整個設計極為簡潔且巧妙：
- 任務表示：每個任務都是一個獨立的 Markdown 檔案，其元數據（如任務 ID、指派對象、狀態）則儲存在檔案頭部的 YAML frontmatter 中。
- 狀態佇列：透過建立
todo、doing、done三個資料夾來代表任務的不同狀態。 - 狀態轉換：一個代理領取任務，就是將對應的 Markdown 檔案從
todo原子性地移動到doing。任務完成後，再移至done。 - 可觀測性：一個輕量的 Web 伺服器（例如使用 FastAPI）定期掃描這些資料夾，並將狀態呈現在一個簡單的 HTML 看板上。
這種極簡架構帶來了哪些意想不到的好處？
這個架構的巧妙之處在於，它將抽象的「任務狀態」實體化為檔案系統中的一個個檔案。這種做法帶來了幾個顯著的好處：持久性（即使代理崩潰，任務檔案依然存在）、原子性（檔案移動在多數作業系統上是原子操作，避免了競爭條件）、以及極佳的人機可讀性。開發者可以直接透過檔案總管或終端機來監測、甚至手動介入整個工作流。
這種方法的本質，是建立一個「外部化的共享記憶體」。代理們不必直接溝通，而是透過讀寫這個共享的狀態平面來進行隱性協調。這正是早期 AI 研究中黑板系統（Blackboard Systems）思想的現代極簡實現。
這種架構的真正價值是什麼？
將這個實作提升到架構層次來看，它的價值遠不止於一個「任務看板」。它是一個功能完備、但成本極低的協作基板（coordination substrate）。
首先，它實現了代理與狀態的解耦。代理本身不需要維護複雜的內部狀態，它們只需要學會如何從特定位置（todo 資料夾）拿取工作，並在完成後將產出放回指定位置（done 資料夾）。這大大降低了單一代理的設計複雜度，也讓替換或增加新的代理變得輕而易舉。
其次，它提供了無與倫比的可觀測性與可治理性。由於所有狀態都以純文字檔案的形式存在，我們可以輕易地對其進行版本控制、備份、審計。當系統出錯時，我們能精準地回溯到是哪個任務、在哪個環節出了問題。這種透明度是建立可信任 AI 系統的基石。
最後，它展示了漸進式擴展的可能性。這個基於檔案系統的簡單模型，可以視為一個起點。當系統規模擴大，例如每秒需要處理數百個任務時，我們可以平滑地將底層的協作基板替換成更專業的工具，而無須大幅修改代理本身的邏輯。
下面是一個簡單的比較，說明不同協作基板之間的取捨：
| 協作基板類型 | 優點 | 缺點 | 適用場景 |
|---|---|---|---|
| 檔案系統 | 極度簡單、零依賴、易於除錯 | 效能受限、不適合高併發寫入 | 原型開發、小型專案、少於 10 個代理 |
| 資料庫 (如 SQLite) | ACID 保證、支援複雜查詢 | 需要資料庫管理、有一定學習曲線 | 需要結構化數據、任務間有關聯性 |
| 工作流引擎 (如 Temporal) | 強大的狀態管理、重試、容錯機制 | 架構複雜、部署與維運成本高 | 企業級、長時運行的複雜工作流 |
最終，工具的選擇應服務於架構目標。關鍵不在於我們用的是檔案系統還是昂貴的企業級軟體，而在於我們是否意識到：為多代理系統設計一個清晰、可靠的共享狀態平面，是通往穩定與規模化的必經之路。在許多情況下，從最簡單的檔案系統開始，或許就是最明智的選擇。
延伸閱讀
- Claude Code で作ったエージェントのタスクを可視化する (原始案例的日文技術文章)
- MetaGPT: Meta Programming for Multi-Agent Collaborative Framework (關於結構化多代理協作的論文)
- Blackboard Systems: The Blackboard Model of Problem Solving (AI 黑板系統的經典論文)
- Temporal: Durable Execution System (一個現代化的工作流協調引擎)
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。