单进程的墙
重构之后的 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。
用一句话概括 tbrain 的设计：调度归调度，推理归推理，两件事不混。
确定性的系统做确定性的事，AI 做 AI 擅长的事。
对话也在外面
还有一层也在 tbrain 外面：和用户的对话。
用户用自然语言说需求，理解意图、对齐需求——这些都是 tclaw 或者其他对话 agent 的事。它们把需求理解清楚之后，发一个结构化的请求给 tbrain，tbrain 才开始干活。
整个链路是：
用户说需求
↓
对话 agent 理解意图
↓
tbrain 接收结构化请求，开始调度
↓
brain agent + 各专业 agent 执行
tbrain 在这条链路里只负责中间那段——接收请求、分发任务、追踪状态、收集结果。干净，清晰，可预测。
四个"不依赖"
设计 tbrain 的时候，立了四个原则：
- 不依赖语言：agent 用 Go、Python、JS 都行，只要能发 HTTP
- 不依赖框架：不需要改现有 agent 的任何核心逻辑
- 不依赖部署：agent 可以在任何机器，能访问到 tbrain 就行
- 不依赖实现：LLM、规则引擎、甚至是真人，遵守协议就能接入
这四个原则的本质是：tbrain 只是一个协议层。它不关心 agent 里面是什么，只关心 agent 能不能注册、能不能接任务、能不能上报结果。
类比一下：操作系统管理进程，不关心进程用 C 还是 Python 写。Kubernetes 管理容器，不关心容器里跑什么应用。tbrain 管理 agent，不关心 agent 用什么框架、什么 LLM。
tbrain 源码在这里：tbrain
最兼容 tbrain 的 Agent 运行时是 tclaw，感兴趣可以去 tclaw-releases 体验。