多 Agent 协作听起来很强：一个 Agent 分析需求，一个写代码，一个跑测试，一个做审查。问题是，如果没有清楚的分工，多几个 Agent 只是多几份混乱。
真正有用的多 Agent 系统，不是“人多力量大”，而是把复杂任务拆给合适的角色，并且让每一次交接都可检查。
本文要点
- 简单任务不要上多 Agent，单 Agent 更快也更稳。
- 多 Agent 适合任务大、角色差异明显、可以并行的场景。
- 协作最怕三件事：边界不清、上下文乱传、没人负责最终结果。
- 好的多 Agent 流程一定有协调者和验证环节。
什么时候才需要多 Agent
不是所有复杂任务都需要多 Agent。
如果一个任务路径很短，比如“修一个 TypeScript 报错”，单 Agent 通常更合适。因为拆出去的沟通成本，比任务本身还高。
多 Agent 适合三种情况。
第一，任务天然有不同专业角色。比如做一次代码审查，安全风险、性能问题、测试缺口、产品影响，关注点不同。让不同角色分别看，结果会更全面。
第二，任务可以并行。比如一个仓库有前端、后端、脚本、文档四块变更，彼此依赖不强，可以分开分析，再汇总。
第三，任务失败成本高，需要独立复核。比如自动生成迁移脚本后，最好再让验证 Agent 检查数据风险，而不是让写脚本的 Agent 自己说没问题。
任务怎么拆才合理
拆任务的核心不是“拆得越细越好”，而是每个子任务都要有清楚的输入、输出和完成标准。
一个坏的拆法是：
- Agent A：看一下代码。
- Agent B：也看一下代码。
- Agent C：总结一下。
这三个任务重叠严重，最后很可能得到三份相似意见。
一个更好的拆法是：
- 架构 Agent：只看模块边界和数据流。
- 测试 Agent：只看测试覆盖和回归风险。
- 安全 Agent：只看权限、注入、敏感信息。
- 协调 Agent：合并发现，去重，按严重程度排序。
这样每个 Agent 都知道自己负责什么，也知道不用管什么。
角色怎么分
多 Agent 系统里，至少需要四类角色。
协调者负责拆任务、分配角色、收集结果和处理冲突。它不一定做具体工作，但要对最终结果负责。
执行者负责完成具体子任务，比如写代码、查日志、跑测试、整理数据。
验证者负责检查执行结果是否可靠。验证者最好不要和执行者是同一个角色，否则很容易只验证自己已经相信的东西。
汇总者负责把多个结果合成一份用户能读懂的输出。它要去重、排序、标风险，而不是简单拼接。
实际项目里，一个 Agent 可以兼任多个角色，但角色边界必须写清楚。否则出了问题，很难知道是任务没拆好，还是执行没做好。
交接怎么做
多 Agent 协作最容易坏在交接。
交接不是把全部上下文复制给下一个 Agent。上下文越多，重点越容易丢。更好的做法是传递结构化信息：
- 目标：你要完成什么。
- 范围：你只需要看哪些文件或数据。
- 已知事实：前一个 Agent 已经确认了什么。
- 待判断问题：你需要回答什么。
- 输出格式：你要返回什么字段。
比如给测试 Agent 的交接可以这样写：
目标：评估本次改动的测试缺口。
范围：只看 src/pages/posts、src/layouts、public/images/articles。
已知事实：这次主要是文章内容和图片资源修改。
待判断：是否有缺失图片、frontmatter 错误、构建风险。
输出：按严重程度列出问题，并给出验证命令。这种交接比“你也帮忙看看”可靠得多。
哪些情况不要用
第一，任务太小不要用。多 Agent 会带来调度成本，小任务直接做更快。
第二，边界拆不开不要用。如果每个 Agent 都要读同一堆上下文、做同一类判断，就没有拆分价值。
第三，没有验证机制不要用。多个 Agent 给出多个答案，不代表答案更对。没有统一验证，只会让结果更难判断。
第四，时间很紧不要用。多 Agent 适合并行，但前提是任务能并行。如果任务本身是强顺序流程，多 Agent 不一定快。
结论
多 Agent 协作的价值，不在于多派几个“助手”，而在于把复杂任务拆成可检查的角色分工。
如果任务很小、边界不清、没有验证，就用单 Agent。只有当任务足够大、角色差异明显、交接可以结构化时，多 Agent 才会真正提高质量。