Tbrain

从 DAG 到行为树 tbrain 最初的任务调度是 DAG（有向无环图）：brain agent 把 job 拆成带依赖关系的任务列表，orchestrator 按依赖顺序执行。这套机制简单直接，但有一个缺陷——缺乏条件分支和自适应能力。任务成功失败的处理方式是固定的，无法根据执行结果走不同路径。 为了解决这个问题，引入了行为树（Behavior Tree）——游戏 AI 里常用的决策架构。实现了 sequence、selector、retry、condition、parallel 五种节点类型，支持顺序执行、失败回退、条件判断、重试等逻辑，并为此做了 SVG 流程图渲染。 两个根本问题 但随后发现两个根本问题： 让 LLM 建树难度很高。 LLM 建普通任务列表已经容易出错，建一棵结构正确、逻辑合理的行为树更难——节点类型选择、嵌套结构、条件语义，每一步都容易出偏差。 渲染流程图难度也高。 行为树是嵌套树形结构，和 DAG 的布局算法完全不同，需要手写递归布局算法才能正确渲染。 结论 行为树的核心价值——条件分支、根据结果重新规划——其实可以用更简单的方式实现：brain agent 在任务末尾根据验收结果决定是否追加新任务。本质上是同样的能力，但对 LLM 的要求和系统复杂度都低得多。 行为树分支因此未合并，回到了 DAG + brain agent 动态追加任务的路子。 tbrain 源码在这里：tbrain 最兼容 tbrain 的 Agent 运行时是 tclaw，感兴趣可以去 tclaw 体验。

关于协议 第一个要想清楚的问题：agent 怎么和 tbrain 通信？ 一开始想过用 WebSocket，实时性更好。但想了想，任务调度对实时性要求没那么高，agent 每隔几秒来拉一次任务完全够用，换来的是协议简单、接入方便。就用 HTTP 了。agent 的工作流程大概是这样： 注册自己，告诉 tbrain 我是谁、能做什么，拿到一个 token 每 30 秒发一次心跳，证明自己还在线 每 3 秒拉一次任务，有活就认领 执行过程中可以上报进度，UI 上能实时看到 做完上报结果，或者上报失败并说明原因 tbrain 通过心跳判断 agent 是否在线。心跳超时的 agent 会被标记为离线，手里的任务重新放回队列，等其他同角色的 agent 来认领，不需要人工介入。 任务计划谁来出 调度是确定性的，但"这个任务该怎么拆、交给谁"不是——这需要判断力。 有些场景流程是固定的，比如"先开发、再测试、再部署"，每步交给谁很明确，提前写死就行。但有些场景不好提前定死，需求一来，得先看看现在有哪些 agent 在线、各自能干什么，再临时决定怎么安排。 所以支持了三种模式： 静态模式：提交 Job 时自己写好任务列表和依赖关系，tbrain 照着跑。 AI 规划模式：只提交一个目标，brain agent 看到目标后自己规划出任务列表，发回给 tbrain 执行。 混合模式：骨架是静态的，某些步骤交给 brain agent 来决定怎么做。 任务失败了怎么处理 设计失败处理的时候，想了一下失败都有哪些情况：网络抖一下超时了、agent 做错了需要重来、碰到了没权限处理的情况需要人来拍板……这几种情况的处理方式完全不一样，不能一刀切。 最后让 agent 自己在上报失败时指定失败等级： 自动重试：瞬态错误，系统自动重试，不超过两次 打回重做：业务失败，打回上游任务重新来过 人工审核：需要人来决定，任务挂起等人处理 致命错误：整个 Job 直接失败 agent 自己最清楚为什么失败，让它定级比 tbrain 猜要靠谱。 ...

单进程的墙 重构之后的 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 + 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 都是孤岛。 ...