一个 Agent 跑起来之后，很容易顺出下一个念头：既然一个能干活，那多来几个，是不是更强？
先把冷水泼上：多数时候，不是。多智能体是一种组织方式，不是一种“智力加成”。组织有组织的好处，也有组织的开销，而且开销多半比你想的贵。
什么时候值得拆
要回答“要不要多个”，先看任务有没有这三种特征：
- 有天然的接缝：任务能干净地切成互不重叠的段——搜集归搜集、写作归写作、核查归核查
- 能并行：几段之间没有先后依赖，同时开工能压缩总时长
- 需要独立复核：一方产出一方挑错，纠错收益大于沟通成本
反过来，如果任务是一段连贯的推理、答案全在一口气里，拆开只会把上下文切断、把智力摊薄。三段各看一部分材料的 Agent，合起来还不如一个通读全文的。
拆分的依据是任务边界，不是“人多力量大”。
还有个更常见的浪费：把一个模型复制三份，让它自己跟自己开会。这不叫多智能体，叫同一个脑子自说自话——同样的信息、同样的偏见，聊得越久越自信。
拆分的账其实可以算：每多一个角色，就多一次上下文组装、多一轮模型调用、多一套要维护的交接格式。省下来的是并行换来的一段时间，花出去的是通信与调试的工夫。只有省下的明显更多，拆才是赚的。
真正值得拆的场面也不难认：一次要扫几十份材料的搜集、一段要反复打磨的写作、一份必须独立核过的结论——要么互相独立，要么得互相盯着。一个 Agent 再能干，也不能既当选手又当裁判。
角色不是头衔
决定拆了，下一步是切角色。这里最常见的错误是起名字：“分析师”“笔杆子”“批评家”——名字起得再漂亮，如果三个角色看到的信息、能用的工具、被要求的输出完全一样，那就是同一个 Agent 换了三次马甲。
角色不是名字，是“看到什么、能做什么、交什么格式”这三件事的组合。
一个站得住的例子，比如定选题的小组：
- 搜集者：能联网、能读文档，只负责输出“来源 + 要点”的清单
- 写作者：不给它联网权限，只拿清单，输出草稿
- 审查者：拿到草稿和原始清单，输出“问题清单”，不许直接改稿
注意最后一条的狠处：审查者不改稿。每个角色的职责越干净，交接越不容易浑。
另一个毛病是把角色拆得太细：七八个角色开一场会，光交接格式就有七八种，读都读不过来。角色的数目应该跟任务的接缝数对齐——三个清晰的，胜过七个含糊的。
还有一条工程上的铁律：输出格式就是交接契约。A 的产出要被 B 直接消费，结构化的清单永远比自由发挥的散文好使——散文交接给下一步，等于把噪声原样递过去。
彼此怎么通信
Agent 之间最贵的动作是“说话”。在这个系统里，通信就是上下文传递——A 的结论要变成 B 眼前的文字，而每一个字都要花 token、占注意力。
三种基本的通信形态：
- 接力：一个交给下一个，适合有先后顺序的活
- 主管模式：一个调度者拆任务、收结果，其余各干各的
- 共享黑板：所有人读写同一份共享状态，适合彼此纠缠的探索
传少了、传多了、传含糊了，都是病：传少了，B 重复劳动；传多了，B 的上下文被碎片塞满，注意力被稀释；传含糊了，B 只能猜，猜错就是返工。
一个实用的小手段：给每次交接立“额度”——清单不超过二十条，结论不超过三行。限额不是抠门，它逼着每个角色在开口前，先替下一个角色做一次摘要。
好的编排不是让每个 Agent 知道一切，而是让每个角色只知道“该知道的那部分”。
常见的翻车姿势
多智能体系统的翻车，往往不是某个 Agent 不会干活，而是败在它们的关系上：
- 互相甩锅：A 说 B 给的输入不完整，B 说 A 的要求不清楚，转一圈，没人交付
- 客套死循环：两个 Agent 来回确认“你觉得行吗”“你说得对”，谁也不肯收尾
- 一致跑偏：五个 Agent 齐齐点头的错误结论——它们看的是彼此的结论，而不是独立证据
- 无节制繁殖：总指挥派了子指挥，子指挥又派了自己人，成本一级一级往上翻
这些坑有个共同解药：每个角色都要有明确的交卷标准，系统才会有终点。再配一层兜底——步数上限、预算上限，以及一个最终拍板的人或规则。没有终点线的团队，不会自己停下。
甩锅还有个根子：两边对“什么算合格”没有同一份文本。把验收标准写成清单，开工前发给所有角色，比事后反复协调便宜得多。
谁来拍板
编排说到底是回答三个问题：谁拆任务、谁汇总、谁说了算。
- 任务同质、量大：主管模式省心，一个调度者对着清单派活
- 任务串成一条线：接力最省，但要注意每一棒的交接格式
- 探索型、答案没人预先知道：共享黑板更有机会，但最容易失控，预算要捏紧
拿“每周行业简报”这种小项目当例子：搜集者扫指定来源，产出带出处的条目清单；写作者把清单组织成简报；审查者只核对“每条是否带来源、数字是否对得上原文”。三个角色、两次交接，就够了——再拆，就是在给自己找活干。
还有一件容易忽视的事：回退。拆出去的活干砸了，要能退回上一级——由调度者决定重派、换人，还是自己接手。没有回退路径的编排，一处卡死，全线停摆。
还有一样别省：日志。每一棒交接了什么，要能从记录里翻出来——不然出了问题，连“是谁把话传歪了”都查不清。
一个反直觉的结论
把话说回来：很多“多智能体赢过单 Agent”的案例，赢的不在数量，而在于拆开之后，每个角色拿到的上下文更干净。
那么反过来想——如果给单 Agent 同样干净的上下文，它常常更快、更省、还更稳。所以顺序永远应该是：先把手里的单 Agent 用足；上下文太杂、任务太散、或者确实需要独立复核时，再拆，并且按最小数目拆。
多一个角色，账上就多一份通信成本。这笔账，拆之前先算。
下一站
角色分好了，新的麻烦浮上来：每个角色面前都堆着一串要接的外部能力——写作者要查资料、审查者要读数据库、调度要发邮件。一样一样地写适配代码，写不完。
接口这摊子事，就是下一站：MCP。