架构设计

单进程的墙 重构之后的 agent 工具稳多了。但用了一段时间，新问题浮出来了。 所有 agent 都跑在同一台机器、同一个进程里。这意味着你没法把 coder 部署在开发机、tester 部署在测试机，让它们跨机器协作。不同机器上跑的 agent，没有办法互相知道对方，没有办法分工，更没有办法共同完成一个任务。 每个 agent 都是孤岛。 想真正做到多 agent 协作——不管 agent 在哪台机器、用什么语言写、跑在什么框架上——就需要一个独立的调度层，负责把任务分发出去，收集结果回来。 这就是 tbrain 最初的动机：一个专门的任务调度引擎，让分散在各处的 agent 能协同工作。 只做调度该做的事 开始设计这个引擎的时候，第一个问题是：它到底要做什么？ 最直接的想法是给它加上 AI——让它自己理解需求、自己拆任务、自己决定派给谁。但停下来想了一下，调度这件事本身，其实不需要理解任何东西。它要做的就是：task 1 完成了，通知 agent 去做 task 2；task 2 完成了，通知 task 3。就这些，纯粹是状态流转，机械的，确定性的。 那哪里需要 AI？继续想——需要 AI 的地方，是在任务开始之前：得有人把流程安排好，知道现在有哪些 agent、各自能干什么，然后决定先做什么、再做什么、交给谁。这一步需要判断力，是 AI 该干的事。 但这一步做完之后，后面的执行就不需要 AI 了。系统只要照着计划，按部就班地通知、等待、更新状态，就行了。 这么一推，结论就出来了：调度引擎本身不需要 AI，AI 只需要在开始的时候把计划交给引擎，剩下的事交给系统。 那 AI 去哪了 AI 没有消失，只是搬了个位置。 tbrain 里有一个叫 brain agent 的角色。它是专门处理"需要判断力"的事：理解目标、规划任务、决定顺序、处理失败。这些是 LLM 擅长的，就交给它来做。 但 brain agent 是一个外部角色，和其他 agent（coder、tester、researcher……）地位完全平等——同样是注册到 tbrain，轮询任务，上报结果。tbrain 不知道也不关心它内部用的是 Claude 还是 GPT，甚至不关心它是不是 LLM。 ...