重构

问题出在哪里 消息总线那套方案放弃之后，我坐下来想了一下，问题到底出在哪。 根本原因是：消息总线是对等的，每个 bot 都可以给任何人发消息。这种自由度在人类团队里没问题，因为人有判断力，知道什么时候该说话、什么时候不该插嘴。但 LLM 不一样，它的"判断"是概率性的，今天遵守规则，明天又忘了。你加再多提示词约束它，它该乱的时候还是会乱。 既然对等通信管不住，那就换成单向调用——上级调下级，下级只干自己的事，不主动找别人。 新的设计 重构后的 tclaw，多 agent 协作的方式变成了这样： list_categories → list_agents → run_agent 用户或者顶层 agent 先用 list_categories 看看现在有哪些领域，再用 list_agents 列出某个领域下的所有 agent，然后用 run_agent 调用具体的 agent 去做事。 就像公司里的层级结构：你要找人做事，先找到对应的部门，再找到对应的人，直接下任务。这个人完成任务后把结果交回来，不会自己跑去找别的部门。 这样一来，协作的控制权始终在调用方手里，被调用的 agent 只负责完成自己的任务，不能主动发起新的协作链路。 pcclaw → tclaw 这次重构等于把整个架构重新来过，代码改动很大，干脆起了个新名字：tclaw。t 是我名字的首字母。 2026 年 4 月 21 日，tclaw 第一次提交。从 pcclaw 的第一次提交到现在，差不多过了五周。 新架构稳定多了。agent 之间的协作变得可预测，出了问题也知道去哪里找。当然也不是完美的——有时候顶层 agent 该调用专业 agent 的时候，它自己就把事情做了，没有委托出去。但比起消息总线那套，已经好太多了。 同期做的其他事 重构完内核，顺手把周边也整理了一遍： 把引擎抽成独立包，方便后续扩展 加了 WebSocket server，可以用浏览器访问 做了 WebGUI，有 tool call 展示 加了 session 历史侧边栏 做了 onboarding wizard，引导新用户配置 从只能在命令行用的小工具，开始变成一个像样的产品。 ...