多智能体协作，很多时候是伪需求
多智能体是个很吸引人的概念：规划者、执行者、审查者，各司其职，互相检查，像一个团队。听起来很美好，实际跑起来问题一大堆。
我踩过的三个坑
坑一：信息在传递中失真
规划 Agent 输出的任务描述，执行 Agent 理解偏差，审查 Agent 又按自己的标准判断。三轮下来，原本一句话能说清的需求，变成了一段谁都不完全认同的文字。
这是因为每次交接都是一次"有损压缩"。Agent 之间传的不是事实，是各自对事实的概括。
坑二：成本和时间翻倍
三个 Agent 串行，调用次数是三倍，延迟也是三倍。如果还有互相 review 的循环，可能五到八次。用户体验上就是"等了半分钟，出来一个还不如单 Agent 的结果"。
坑三：错误被放大而不是被纠正
本以为审查 Agent 能兜住执行 Agent 的错误。实际是：执行错了，审查没看出来，还给了个"通过"的结论——两个 Agent 都错了，但你只有一个错误的信心。
什么时候真的需要多个 Agent
不是没有场景，但要满足条件：
- 任务确实可并行，比如同时分析十个竞品的官网，每个独立处理
- 角色差异足够大，比如一个负责检索、一个负责写作、一个负责事实核查，它们的输入输出格式完全不同
- 有明确的裁判标准，审查方不是"再想一遍"，而是跑具体规则
反过来，如果只是"让它多想想""让它检查一下"，那不需要多 Agent，在提示词里加一步自查就够了。
我现在的默认做法
单 Agent + 清晰的工作流。具体是把任务拆成几个阶段，每个阶段是一个独立的模型调用，中间用代码做校验和转换。
比如写一份行业分析：
- 调用模型提取关键词（输出 JSON 数组）
- 用代码拿关键词去检索，拿到资料
- 调用模型基于资料写大纲（输出 JSON）
- 用代码检查大纲结构是否完整（章节数、是否有结论）
- 调用模型逐节展开
- 用代码做格式和长度检查
每一步都是确定性的，出错能定位到具体环节。这比"五个 Agent 开会"可靠得多。
多 Agent 适合探索，工作流适合生产。 上线的东西，我更愿意用后者。