主题
高频面试题
多 Agent 协作有哪些常见的编排模式？各自适合什么场景？
面试官问多 Agent 编排，真正想看的是你能否判断“什么时候该拆、怎么拆、谁控流、怎么合并结果”，而不是罗列几个框架名。
面试官角度分析，想考什么
多 Agent 有哪些常见编排模式？
考分类：Supervisor、Orchestrator-Workers、Handoff、层级、网络协作、评审辩论。这些模式的核心区别是什么？
考控制流：谁决定下一步、状态怎么共享、结果怎么合并。什么时候不该上多 Agent？
考取舍：任务不可拆、上下文强耦合时单 Agent 更稳；多 Agent 会带来协调成本、循环调用和验证难题。
可直接抄走的 30 秒参考答案
text
常见多 Agent 编排模式有几类：Supervisor 用一个主控 Agent 路由和汇总，适合客服分流和企业助手；Orchestrator-Workers 把任务拆给多个 worker 并行做，适合深度研究和批处理；Handoff 是控制权移交，适合客服、售前、技术支持；Hierarchical 是多层管理，适合大型复杂任务；Network 或 Swarm 更去中心，适合探索型场景但生产风险高；另外还常加 Critic 或 Evaluator 做评审。选择时看任务是否可拆、状态怎么共享、谁控流、结果怎么验证，以及多 Agent 的成本和延迟是否值得。面试回答详解，知其所以然
多 Agent 不是“Agent 越多越强”。它解决的是职责、上下文、工具和并行性的问题，同时引入协调成本。面试里最好先讲判断标准，再讲模式。
1. 什么时候该拆成多 Agent
适合拆分的信号：
- 任务天然可分解：比如调研、写作、合规审查、代码实现、测试验证可以分开。
- 工具集差异大：客服订单 Agent 和技术排障 Agent 用的工具完全不同。
- 上下文边界清晰：Research Agent 不需要看到 CRM 写入细节，Reviewer 不需要继承 Coder 的推理污染。
- 可以并行探索：多个独立子问题可以同时查证，最后汇总。
- 需要独立制衡：生成、评审、合规、事实核查最好由不同角色完成。
不适合拆分的信号：
- 任务很短、路径固定、一个 workflow 就能解决。
- 子任务高度耦合，拆开后每个 Agent 都缺上下文。
- 对延迟和成本极敏感，多轮 LLM 调用无法接受。
- 没有 trace、评估和状态管理能力，出错后无法复盘。
2. Supervisor / Router 模式
Supervisor 模式是最常见的中心调度。一个主 Agent 负责理解用户目标、选择下一个 worker、汇总结果和决定停止。
text
User -> Supervisor -> Researcher / Coder / Analyst / Writer -> Supervisor -> Final适合：
- 用户请求可以路由到明确角色。
- worker 工具集差异大。
- 需要统一出口和统一安全策略。
- 客服分流、企业助手、内部运营工具很常见。
风险：
- Supervisor 是单点瓶颈。
- 路由错误会让后续全部偏掉。
- worker 输出格式不稳定时，汇总层会很痛苦。
3. Orchestrator-Workers 并行工作者模式
Orchestrator 先把任务拆成多个子任务，多个 worker 并行执行，最后聚合。它和 Supervisor 很像，但更强调“一次拆分、多路并行、集中合并”。
text
复杂问题 -> Orchestrator 拆成 N 个独立子问题
-> Worker 1 / Worker 2 / Worker 3 并行执行
-> Aggregator 合并、去重、验证适合：
- 深度研究、竞品分析、文档批处理、代码库分模块审查。
- 子任务相互独立，结果可以并行产生。
- 质量优先于 token 成本。
风险：
- 子任务拆得不好会重复劳动或漏掉关键方向。
- 汇总层要处理冲突、重复、来源可靠性和置信度。
- 成本可能是单 Agent 的数倍甚至十几倍。
4. Handoff 控制权移交模式
Handoff 模式里，当前 Agent 判断自己不适合继续处理时，把控制权移交给另一个 Agent。用户后续可能直接和新 Agent 交互。
text
Triage Agent -> Billing Agent -> Refund Agent -> Human Agent适合：
- 客服、售前、技术支持、IT 服务台等分诊场景。
- 任务类型明确，但分支很多。
- 每个 Agent 都有强领域身份和专属工具。
风险：
- 移交条件写不好会来回跳转。
- 上下文交接摘要不完整会丢信息。
- 用户体验上要让用户知道当前由谁处理、为什么移交。
5. Hierarchical 层级模式
层级模式是 Supervisor 的递归版本：顶层 Agent 管多个中层 Agent，中层再管 worker。
text
Top Coordinator
-> Research Team Lead -> Web / Paper / Data Agents
-> Engineering Lead -> Backend / Frontend / QA Agents
-> Compliance Lead -> Policy / Privacy Agents适合：
- 大型任务、长任务、组织结构天然分层。
- 子任务还能继续拆分。
- 不同层级需要不同模型和预算。
风险：
- 层级越深，信息损失越严重。
- 错误会沿汇报链放大。
- 调试需要非常好的 trace 和状态快照。
6. Network / Swarm 去中心协作模式
Network 模式允许 Agent 之间自由通信，没有固定中心。Swarm 更强调轻量 Agent 之间的 handoff 和局部决策。
适合：
- 开放式探索、头脑风暴、模拟组织讨论。
- 研究原型和低风险场景。
- 需要多个 Agent 动态互相补充信息。
风险：
- 容易循环、跑偏、重复讨论。
- 状态和责任边界不清。
- 生产环境很难审计和保证 SLA。
面试里可以直说：去中心多 Agent 很酷，但生产默认不优先，除非有很强的状态机、预算上限和退出机制。
7. Debate / Evaluator / Critic 模式
这类模式不一定是完整拓扑，更像协作策略：一个 Agent 生成答案，另一个 Agent 审查、反驳、投票或打分。
text
Generator -> Critic -> Generator 修正 -> Evaluator 验收适合：
- 高质量写作、事实核查、代码 review、合规审查。
- 需要降低幻觉或补充遗漏。
- 有明确 rubric 或测试可以验证。
风险：
- 评审 Agent 也会错，不能神化 LLM-as-judge。
- 多轮批评可能增加成本但不提升质量。
- 没有证据或测试时，辩论容易变成语言游戏。
8. 选型口诀
- 任务分类明确：选 Supervisor / Router。
- 子任务可并行：选 Orchestrator-Workers。
- 用户请求需要分诊转接：选 Handoff。
- 任务天然多层组织：选 Hierarchical。
- 开放探索和实验：可以尝试 Network / Swarm。
- 需要质量制衡：加 Critic / Evaluator。
- 流程固定、风险高：优先 Workflow，不要强行多 Agent。
面试官追问3个问题
追问一：Supervisor 和 Orchestrator-Workers 有什么区别？
- 考察点：是否能区分持续路由和一次拆分并行。
- 回答方向：Supervisor 更像循环中的中心路由，每轮决定下一个 Agent；Orchestrator-Workers 更强调先拆成多个相对独立任务，并行执行后聚合。两者可以组合。
追问二：多 Agent 为什么可能比单 Agent 更差？
- 考察点：是否理解协调成本。
- 回答方向：会带来上下文割裂、重复工作、冲突决策、错误传播、延迟增加、成本增加和 trace 复杂。任务不可分或缺少评估时，单 Agent 往往更好。
追问三：结果合并怎么做？
- 考察点：聚合和验证能力。
- 回答方向：要求 worker 返回结构化结果、证据来源、置信度和不确定性；聚合层去重、冲突检测、按来源质量排序；关键任务用 evaluator、测试或人工确认。
扩展知识
多 Agent 和 Workflow 的边界
如果 worker 只是执行固定 prompt，没有自主工具选择和多步决策，那更接近 workflow。只有当多个 Agent 各自有状态、工具和决策权时，才更像多 Agent 系统。
text
固定控制流 + 固定节点 = Workflow
动态决策 + 独立角色 + 工具权限 = Multi-Agent状态共享的三种方式
- Shared State：所有 Agent 读写同一个状态对象，便于汇总，但要防并发冲突和污染。
- Message Passing：Agent 之间只传消息和 artifacts，边界清晰，调试友好。
- Blackboard：所有 Agent 在共享工作区读写证据、计划和结果，适合研究和规划，但需要锁和版本。
生产里更推荐 message passing + artifact store，别让所有 Agent 直接共享完整上下文。
多 Agent 的验证出口
多 Agent 最怕“每个子任务看起来都完成了，合起来却不能用”。所以系统要有出口条件：
- 是否满足用户目标？
- 子任务是否都有可追踪 artifact？
- 关键结论是否有来源或测试？
- 冲突是否被解决或标注？
- 高风险动作是否审批？