FDE现实课 05 · 多Agent
别再堆Agent了：角色越多，企业交付可能越慢
多Agent适合并行问题，不适合把一条顺序任务拆成数字员工大会。
一份行业报告，原来一个人查资料、列结构、写正文、校对，半天能完成。
换成多Agent以后，调研Agent先交给大纲Agent，大纲Agent交给写作Agent，写作Agent再交给审核Agent。每个角色都"完成了任务"，最后总控却发现：研究口径不一致，引用编号丢了，审核还把作者原来的判断改成了套话。
开了四个数字员工，交付反而更慢。
问题不在Agent数量，而在任务有没有真的可分。
每次交接，都要交一笔税
人类团队有交接成本，Agent也一样。
第一笔是上下文损失。上一个角色知道为什么排除某条资料，下一个只看见结论。
第二笔是格式转换。证据表变成大纲，大纲变成正文，每转换一次都可能丢字段。
第三笔是重复劳动。任务边界模糊时，几个Agent会反复搜索同一问题。
第四笔是责任漂移。最终结果出错，很难判断该修检索、写作、审核还是总控提示词。
Anthropic在介绍多Agent研究系统时也提到，协调复杂度会快速上升；指令含糊时，子Agent可能重复搜索。它的优势来自真正可以并行的广度研究，而不是角色越多越先进。
什么任务值得拆成多Agent
先问三个问题。
子任务能否独立并行？比如同时研究五个互不依赖的市场，适合并行；必须先确认数据口径再写结论，就应串行。
每个子任务能否交付固定格式？如果输出没有统一字段，总控只能重新阅读和理解，所谓分工没有省下多少时间。
是否有明确的汇合和验收机制？总控需要知道怎样去重、怎样处理冲突、缺少证据时怎样退回，而不是把五段文字粘在一起。
企业落地，先从最小架构开始
大多数场景先用一个Agent加工具就够了。它保留完整上下文，排查也简单。
当任务确实需要并行，再增加一个轻量结构：总控负责拆分与合并，多个执行者只交付一种结果，审核者只检查可验证的标准。
角色越少，接口越容易写清。等失败记录证明某个步骤已经成为瓶颈，再考虑拆分。
别用"看起来像公司"评价Agent系统
多Agent演示很容易吸引人：屏幕上几个人物头像来回传消息，像一家公司在自动运转。
生产环境不看热闹。至少要量四件事：任务成功率、整体延迟、模型和工具成本、人工修复时间。
如果增加一个角色后，成功率没提高，成本和排查时间却上涨，它就不是协作，是流程装饰。
真正好的Agent架构，往往看起来很克制。该并行的并行，该串行的串行，能不交接就不交接。
企业需要的是把事做完，不是开一场没有散会时间的数字员工大会。
参考资料
• Anthropic：How we built our multi-agent research system
• Anthropic：Building effective agents
完