多智能体团队：什么时候该拆成几个

先说结论：拆分的理由是职责清晰，不是工作量大。当一个智能体的职责说不清楚、或者需要两套互相冲突的行为准则时，就该拆。但拆得越多，要监督的东西也越多——多几个智能体不等于多出产能，只等于多出管理成本。

什么时候该拆：三个信号

1. 说不出它是干什么的。如果一句话讲不完它的职责，那已经是两个智能体了。
2. 调好一件事，另一件变差。这是提示词里两套要求在打架的典型表现，而且只会越来越糟。
3. 权限清单让你不安。一个既能读外部网页、又能发邮件、还能动账务的智能体，出一次事的代价和它做十件事的收益不在一个量级上。这是安全层面的拆分理由，展开在提示词注入的防护清单（英文）。

反过来，不该因为"这件事很重要"或"这件事量很大"而拆。重要和量大都可以由一个职责清晰的智能体承担。

两种协作形态，选错了要返工

同事（peer）是独立的智能体，有自己的页面、自己的渠道、自己的记忆。一个智能体给另一个发消息并等待回复。适合对方本身有持续职责和独立上下文的情况——比如一个统管所有邮件收发的智能体。

子智能体（subagent）嵌在某一个智能体内部。父级把一项任务交出去，子级在自己的上下文里执行并回报，父级的对话保持干净。适合这项工作是别人职责里的一个步骤——比如"查一下这家公司"、"把这一段写出来"。

判断方法很简单：这件事结束之后，它还需要记得什么吗？需要，就是同事；不需要，就是子智能体。

团队负责人：一个被低估的设计

如果有五个智能体，而你要自己决定每件事该找谁，那你就成了路由器——这恰恰是你本来想省掉的那部分工作。

设一个负责人智能体，你只描述要什么，由它去分派。其他智能体照常拥有自己的记忆和工具，照常干活，只是你不用再记住组织结构。

这个设计的另一个好处是可观察：打开智能体之间的通信记录，能看到负责人向邮件智能体交代任务的那一句原话。如果记录里永远只有一个节点在说话，那你并没有建成一个团队，只是给一个智能体加了几道工序——通常原因是分工划得不够清楚。实际形态可以看智能体团队 vs 人类团队。

可见 ≠ 可调用

这是最容易踩的一个坑。"告诉某个智能体它有哪些同事"和"允许它给这些同事发消息"应该是两个独立的开关，而且默认应该是谁也不认识。

原因很实际：一个知道自己有十二个同事的智能体，会想办法把他们都卷进来。一个人人都能呼叫人人的团队会产生循环调用和重复劳动，账单上涨，产出却更差。

务实的做法是按组织结构授权：每个智能体只被告知它真正需要的那几个同事。

一个能用的起步结构

不要从空白开始设计。一个常见且好用的起点是：

• 一个负责人——你大部分对话的入口。
• 两到三个专才——按职能划分，比如客服、销售支持、研究。
• 一个专管某个系统的智能体——比如所有邮件收发都走它。好处是出了事只有一个地方要查。

先跑这四个，跑到无聊了再加第五个。判断"够不够"的标准不是还有多少事没自动化，而是现有的这几个是否还需要你每天盯着。需要，就不要再加。

成本会随拆分上升，但不是线性的

多一个智能体，多的是监督成本和一点点固定开销，不是成倍的模型花费——真正决定账单的是任务的形态：读多少、走几步。一个每天做 20 次深度研究的智能体，可能比五个每天各处理 200 条分流的智能体更贵。所以按任务估算，不要按智能体个数估算。

另外，第二个智能体的搭建成本远低于第一个：连接、约定、审批边界都已经存在了。

三条值得记住的经验

• 从现成的团队模板开始改，比从白纸上设计快得多。
• 每个智能体的职责要能写在一张名片上。写不下，说明是两个。
• 职责清晰才拆，工作量大不拆。加智能体加的是监督，不是产能。