tclaw（三）：重构——换一种方式让 Agent 协作

Tue, 02 Jun 2026 03:00:00 +0000

问题出在哪里

消息总线那套方案放弃之后，我坐下来想了一下，问题到底出在哪。

根本原因是：消息总线是对等的，每个 bot 都可以给任何人发消息。这种自由度在人类团队里没问题，因为人有判断力，知道什么时候该说话、什么时候不该插嘴。但 LLM 不一样，它的"判断"是概率性的，今天遵守规则，明天又忘了。你加再多提示词约束它，它该乱的时候还是会乱。

既然对等通信管不住，那就换成单向调用——上级调下级，下级只干自己的事，不主动找别人。

重构后的 tclaw，多 agent 协作的方式变成了这样：

list_categories → list_agents → run_agent

用户或者顶层 agent 先用 list_categories 看看现在有哪些领域，再用 list_agents 列出某个领域下的所有 agent，然后用 run_agent 调用具体的 agent 去做事。

就像公司里的层级结构：你要找人做事，先找到对应的部门，再找到对应的人，直接下任务。这个人完成任务后把结果交回来，不会自己跑去找别的部门。

这样一来，协作的控制权始终在调用方手里，被调用的 agent 只负责完成自己的任务，不能主动发起新的协作链路。

这次重构等于把整个架构重新来过，代码改动很大，干脆起了个新名字：tclaw。t 是我名字的首字母。

2026 年 4 月 21 日，tclaw 第一次提交。从 pcclaw 的第一次提交到现在，差不多过了五周。

新架构稳定多了。agent 之间的协作变得可预测，出了问题也知道去哪里找。当然也不是完美的——有时候顶层 agent 该调用专业 agent 的时候，它自己就把事情做了，没有委托出去。但比起消息总线那套，已经好太多了。

重构完内核，顺手把周边也整理了一遍：

从只能在命令行用的小工具，开始变成一个像样的产品。