5个AI代理抢任务：他扔掉消息总线，用1个文件夹省了380条连接

去年有个数据让多代理架构的开发者集体沉默——20个AI代理用消息总线协调，会产生380条潜在连接。每多一个代理，系统复杂度按平方级膨胀。

这不是理论推演。CrewAI、AutoGen这些框架的开发者都踩过这个坑。消息在队列里飞，状态在内存里飘，出了问题你面对的是一片黑箱。

一个做Batty项目的开发者试了六个月，最后把整套消息机制扔进垃圾桶。替代品是个文件夹，里面躺着一堆markdown文件。

消息总线的N²陷阱

多代理系统的经典设计是这样的：代理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个代理状态的时刻？