![]()
去年有个数据让多代理架构的开发者集体沉默——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个代理状态的时刻?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.