多 Agent 协作有哪些常见的编排模式？各自适合什么场景？

参考答案

多 Agent 协作的编排模式主要有四种：顺序链式、并行扇出、主从委托和群组讨论。选哪种取决于任务的结构特征和对质量、效率的要求。

1）顺序链式

顺序链式是最简单的模式，多个 Agent 像流水线一样依次处理，前一个的输出就是下一个的输入。

比如内容创作场景：研究 Agent 收集资料 → 写作 Agent 生成初稿 → 审校 Agent 修改润色 → 排版 Agent 最终定稿。适合步骤明确、前后有依赖的线性任务，流程清晰可控，但整体延迟是各步骤延迟之和，4 个 Agent 每个跑 10 秒，总共就是 40 秒。

2）并行扇出

这是让多个 Agent 同时处理不同子任务，最后汇总结果。比如竞品分析场景：同时派 5 个 Agent 分别分析 5 个竞品，最后由汇总 Agent 整合出对比报告。如果每个分析要 30 秒，串行跑得 150 秒，并行只要 30 多秒。适合子任务之间相互独立的场景。

3）主从委托

这是设一个”管理者” Agent 负责拆解任务、分配工作、整合结果，其他”执行者” Agent 只管干活。管理者可以根据执行过程中的反馈动态调整分配，比如发现某个子任务失败了就重新派一个 Agent 去做。这种模式最灵活，适合复杂的、需要动态决策的任务。

4）群组讨论

是让多个 Agent 围绕同一个问题进行多轮讨论，互相补充、质疑、完善。适合需要多角度分析、决策质量要求高的场景，比如技术方案评审、风险评估。3-5 个不同角色的 Agent 讨论 3 轮，通常比单个 Agent 想一次的质量高不少。

扩展知识

四种模式的详细对比

维度	顺序链式	并行扇出	主从委托	群组讨论
延迟	各步骤之和	取决于最慢子任务	取决于管理者调度效率	轮数 × 单轮耗时
适合任务	线性流水线	独立子任务	复杂动态任务	决策评审类
容错性	差，一环断全链停	好，单个失败可重试	好，管理者可重新分配	中等
实现复杂度	低	中	高	高
Token 消耗	中	高，多个 Agent 并行	高，管理者需要额外推理	最高，多轮对话

顺序链式的进阶玩法

纯线性的链式有个致命问题：一旦中间某个 Agent 出错，后面全废了。改进方案是加一个路由节点，根据上一步的输出质量决定是继续往下走还是打回重做。

比如代码生成场景：需求分析 Agent → 代码生成 Agent → 代码审查 Agent，审查 Agent 如果发现代码有问题，不是直接往下走，而是把问题反馈回代码生成 Agent 重新生成。这种带反馈回路的链式，本质上已经是一种简单的有向图调度了。

LangGraph 就是基于这个思路设计的，它把 Agent 编排抽象成一个状态图，节点是 Agent，边是条件跳转，比纯链式灵活得多。

主从委托的核心难点

主从委托模式看起来很美，但管理者 Agent 的设计是最难的部分。它需要具备 3 个能力：

1）任务拆解能力，把一个复杂需求拆成合理的子任务，粒度太粗执行 Agent 搞不定，粒度太细管理开销爆炸

2）结果评估能力，执行 Agent 返回结果后，管理者要能判断质量是否达标，不达标就得重新分配或者换一个 Agent

3）异常处理能力，某个执行 Agent 超时了、返回了错误结果、或者拒绝执行了，管理者要有降级策略

Cursor 的 background agent 和 Claude Code 的 sub-agent 机制就是典型的主从委托，主 Agent 把子任务分发给子 Agent，子 Agent 在独立的 worktree 里执行，完成后结果回传主 Agent 整合。

Agent Teams 的兴起

2026 年起一个明显的趋势是 Agent Teams 概念的流行。不再是单个 Agent 单打独斗，而是让一组有不同专长的 Agent 组成团队。

比如一个软件开发团队可能包括：产品 Agent 理解需求拆解功能、架构 Agent 设计技术方案、开发 Agent 写代码、测试 Agent 写测试用例并验证、运维 Agent 处理部署和监控。这跟真实的人类团队分工非常像。

OpenAI 的 Swarm 框架、微软的 AutoGen、CrewAI 都是朝这个方向在做。它们的核心区别在于 Agent 之间怎么传递上下文、怎么协调冲突、怎么共享记忆。

混合编排是常态

实际项目中很少只用一种模式。比如一个复杂的数据分析任务：管理者 Agent 先把任务拆成”数据清洗””特征工程””模型训练””报告生成” 4 个子任务。数据清洗和特征工程有先后依赖，用顺序链式。模型训练可以同时跑 3 个不同算法的 Agent，用并行扇出。最终报告需要几个 Agent 讨论结论是否合理，用群组讨论。整体上是主从委托套着其他三种模式。

选模式时核心考虑几个因素：子步骤是否有严格先后依赖、子任务能否独立并行、执行过程中是否需要动态调整、决策是否需要多角度验证。

把这几个问题回答清楚，模式自然就出来了。

面试官追问

提问：多 Agent 协作中，Agent 之间的上下文怎么传递？每个 Agent 都要看到完整历史吗？

回答：不需要也不应该。完整历史传递会导致 Token 消耗爆炸，5 个 Agent 每个都看全量上下文，成本直接翻 5 倍。通常的做法是传递摘要或结构化中间结果。比如研究 Agent 跑完之后，不是把它的 20 轮对话历史全传给写作 Agent，而是把最终产出的研究报告传过去。管理者 Agent 可以维护一个共享状态对象，每个执行 Agent 只读写自己关心的字段。LangGraph 用的就是这种共享状态的方式，定义一个 State schema，每个节点只更新自己负责的部分。

提问：群组讨论模式怎么避免 Agent 之间互相附和、没有真正的对抗性思考？

回答：关键在 Agent 角色的 system prompt 设计。要给不同 Agent 赋予明确的、有冲突的立场。比如技术方案评审场景，一个 Agent 的角色是”安全审计员”，它的 prompt 里明确写着”你的职责是找出方案中的安全隐患，宁可误报也不能漏报”。另一个是”成本优化师”，关注的是资源消耗和预算。角色定义越尖锐，讨论越有碰撞。还可以加一个规则：每轮发言必须指出前一位发言者的至少一个问题点，强制对抗。

提问：多 Agent 系统中某个 Agent 陷入死循环了怎么办？

回答：三层防护。第一层是单次调用超时，每个 Agent 的单次 LLM 调用设一个 30 秒到 60 秒的超时。第二层是任务级别的最大轮次限制，比如一个子任务最多跑 10 轮，超过了就强制终止返回当前最佳结果。第三层是管理者 Agent 的全局监控，如果某个执行 Agent 连续 3 次返回相似的结果没有进展，管理者可以判断它卡住了，要么换一个 Agent 重做，要么降级处理跳过这个子任务。