下面是用 tbrain + tclaw 多 Agent 协作开发的挂机游戏：
一个听起来很合理的设计
做 AI agent 做到一定程度，你会开始嫌一个 agent 不够用。
写代码的事，交给 coder。做设计文档，交给 designer。整体协调，交给一个大管家 captain。每个人做自己擅长的，这不就是正常团队的运作方式吗？
所以我给自己的 agent 工具做了一个消息总线。每个 bot 都注册在上面，bot 之间通过发消息协作，想让谁做事就 @ 它。设计上简洁，概念上直觉，感觉挺美的。
确实美了一段时间。
开车的时候用飞书和 captain 说一句需求，captain 帮我整理思路，觉得需要写代码就 @ coder，coder 内部再分工，architect 写设计、implement 写代码、tester 跑测试。我只管说，后面的事它们自己协调。那段时间我给这套东西取了个名字叫"咖啡"——一边喝咖啡，咖啡自己把活干完了。
好景不长
然后问题来了。被 @ 的 bot，自己也会去 @ 别的 bot，消息裂变，系统失控。
这段噩梦足足耗了三周，几十个分支，上百次提交，最后还是回滚了。细节就不在这里展开了——如果有兴趣，可以去看 tclaw 的开发故事，那篇写得比较完整。
简短结论：靠规则和提示词约束 LLM，本质上是在用不确定的方式解决不确定性带来的问题。这件事根本做不完。
放弃，重构。
重构之后
重构后的方案简单多了：不再有消息总线，改成调用制。用 list_categories 看看现在有哪些领域的 agent，用 list_agents 列出该领域下的具体 agent，再用 run_agent 让它去做事。被调用的 agent 做完返回结果，不能主动去找别人。控制权始终在调用方手里，不会有人越权乱插嘴。
这套方案稳了很多。但用了一段时间之后，碰到了另一堵墙——
所有 agent 还是跑在同一台机器、同一个进程里。想在开发机上跑一个 coder，测试机上跑一个 tester，让它们协同，做不到。每个 agent 都是孤岛。
这个问题，就是 tbrain 要解决的。
tbrain 源码在这里：tbrain
最兼容 tbrain 的 Agent 运行时是 tclaw，感兴趣可以去 tclaw 体验。