Agent 学习笔记 24：多 Agent 协作：什么时候一个 Agent 不够用

多 Agent 很有吸引力：规划者、研究员、开发者和审查者各司其职。但如果任务本身没有清晰边界，把一个 Agent 拆成五个，通常只会增加消息、成本和责任推诿。

先判断是否真的需要拆分

适合多 Agent 的任务往往可以并行、需要不同工具或上下文，或者存在明确的生产与审核角色。线性短任务、共享状态高度耦合的任务，用一个 Agent 加几个确定性步骤通常更简单。

常见协作模式

Supervisor 模式由主 Agent 分派和汇总；流水线模式让产物按固定顺序传递；并行专家模式独立研究后合并；辩论模式用于暴露观点冲突。模式选择应服从任务结构，而不是框架示例。

用户目标 -> Supervisor -> 专家 A / 专家 B -> Reviewer -> 汇总与交付

交接必须传递结构化产物

只发一段聊天消息，很容易丢失约束。交接包应包含子目标、输入、已知事实、产物位置、未解决问题和验收标准。共享状态需要定义所有权，避免两个 Agent 同时改同一份文件或重复执行副作用。

成本和错误会一起放大

每个 Agent 都可能误解任务，汇总者也可能覆盖少数意见。系统要限制最大并发、总 token、重试和会话轮次，并为关键产物设置独立验证。能够并行不代表应该并行。

这章给我的启发

多 Agent 的价值来自分工边界，而不是角色数量。先让任务可以被清楚地拆分、交接和验收，再引入多个 Agent，协作才会带来吞吐而不是混乱。