5個AI代理搶任務：他扔掉消息總線，用1個文件夾省了380條連接

去年有個數據讓多代理架構的開發者集體沉默——20個AI代理用消息總線協調，會產生380條潛在連接。每多一個代理，系統復雜度按平方級膨脹。

這不是理論推演。CrewAI、AutoGen這些框架的開發者都踩過這個坑。消息在隊列里飛，狀態在內存里飄，出了問題你面對的是一片黑箱。

一個做Batty項目的開發者試了六個月，最后把整套消息機制扔進垃圾桶。替代品是個文件夾，里面躺著一堆markdown文件。

消息總線的N2陷阱

多代理系統的經典設計是這樣的：代理A完成任務，廣播"任務27搞定"；代理B、C、D、E同時收到，各自更新狀態。B搶下任務28，再廣播一次，剩下的人再同步一次。

5個代理時，這套還能跑。10個代理，90對連接。20個代理，380條潛在消息路徑。每次廣播都是競態條件的溫床，每個代理的內存狀態都可能滯后。

更隱蔽的痛點是可視化——協調狀態活在飛行中的消息里，活在代理的上下文窗口里，就是不在你能看見的地方。

調試時你在追幽靈：消息丟了嗎？狀態同步延遲了嗎？哪個代理的本地視圖已經過期了？

文件系統當調度板

Batty的解法把問題攤平在磁盤上。任務目錄長這樣：

.batty/board/tasks/
├── 027-add-jwt-auth.md # status: in-progress, claimed_by: eng-1
├── 028-user-registration.md # status: todo
├── 029-add-rate-limiting.md # status: backlog
└── 030-fix-dashboard-css.md # status: done

每個文件是YAML frontmatter加markdown正文。機器讀前半段，人讀后半段。一個文件就是一個任務的全部真相。

代理不訂閱主題，不對等協商。它打開一個文件，知道自己該干什么。讀取復雜度永遠是O(1)，跟代理數量無關。

10秒輪詢的暴力美學

調度邏輯被壓縮到一個polling循環里，每10秒跑一輪：

掃描任務目錄→找出空閑代理→按優先級匹配可執行任務→寫回文件狀態→啟動代理。

匹配條件寫死四條：狀態是backlog或todo、無人認領、未被阻塞、依賴已解決。沒有消息協商，沒有狀態廣播，只有文件鎖和原子寫。

「我用消息總線時，代理們像在會議室里互相喊話搶任務。現在它們像圖書館里的讀者，各自找書、各自安靜干活。」開發者這樣描述。

六個月過去，他沒再回頭看過消息總線的代碼。

這套機制能跑通有個前提：任務粒度要夠粗。10秒的調度延遲對寫代碼來說可接受，對高頻交易就是災難。文件系統的原子操作保證了互斥，但也限制了吞吐上限。

代價是顯式的，收益也是。你打開文件夾就能看見整個系統的狀態，不需要抓包、不需要翻日志、不需要重建代理的內存視圖。

當AI代理從5個變成50個，你的調試工具是什么？還是說你還沒遇到過需要同時看50個代理狀態的時刻？