什么是Multi agent

回复 群友 6932： 一句话：一个 agent 干不明白，才拆成多个 agent 分工，不是"多个模型一起想更聪明"。 关键要分清两种情况： 一是真正的 multi agent。每个 agent 有自己的上下文窗口、自己的工具集、自己的角色边界，彼此之间通过文件、消息或者接口契约传结果。典型形态是主从式：主 agent 只做编排（拆任务、排依赖、盯进度），干活的 subagent 带全新上下文在自己工作区里干，干完只回传结果摘要和改动清单。好处是主 agent 的上下文不被代码细节污染，长任务才跑得下去，而且子任务可以真并行。 二是假的 multi agent，也就是同一个模型换了几个 system prompt 互相聊。角色扮演式的"产品经理 agent + 架构师 agent + 程序员 agent"基本属于这一类，看着热闹，实际是在一个上下文里自问自答，收益很小，还容易互相强化幻觉。 什么时候值得用： 任务能干净切开，每块有明确的输入输出契约、能机械验收（跑测试、能编译、过 lint）。 子任务耗时长或者量多，并行能真正省时间。 上下游职责不同、需要独立审查——写代码的和审查的不能是同一个上下文，不然它给自己打分。 上下文量级超出单个窗口能承受的范围。 什么时候别用：任务本身是串行链条、块与块之间要反复来回改、或者你只有一个不熟悉的小项目要摸清。这时候上 multi agent 只会让你花更多时间调试协作产生的幻觉，先串行跑通一条完整链路更重要。 两个常见坑： 一是层数堆太多。两层（编排 + 干活）通常够，最多三层。层数越多，信息在传递中损耗越大，某个子任务跑偏了你根本定位不到。 二是以为多 agent 自带正确性。它不带。准确率要靠机制兜：写完和审查分角色、每轮自动跑测试和 lint 失败就打回、以契约文件为准不以某次对话为准、子 agent 给结论必须附证据。没有这套反馈闭环，多几个 agent 只是多几份自信的错答案。 你手头具体是什么场景？说清楚了我可以直接判断该不该拆、按什么边界拆。