什么时候应该使用多 Agent，如何设计协作机制？

面试时怎么答

先回答“什么时候值得拆”：只有子任务边界清楚、能独立验收，并且并行收益大于通信与汇总成本时，多 Agent 才有意义。然后具体说明编排者怎样分派任务、限制预算、收集证据和解决冲突。不要拿角色数量当能力；追问方案优劣时，要与单 Agent 基线比较重复劳动、冲突和级联失败。

可以这样答：

多 Agent 适合可以明确拆分、子结果能够独立验收，而且并行节省的时间超过通信成本的任务。编排者负责拆分、预算和停止条件，Worker 返回结构化结果与证据，聚合器处理冲突和重复。它不天然优于单 Agent：任务耦合很强时，更多角色只会增加 token、状态同步和级联失败，因此必须先有单 Agent 基线。

核心回答

多 Agent 适合可并行探索多个方向、需要隔离专业上下文，或不同子任务需要不同工具和权限的复杂任务。常见结构是 Orchestrator-Worker：主 Agent 拆分任务并分配边界清晰的子任务，子 Agent 独立执行后返回结构化结果，主 Agent 负责去重、冲突处理和综合。它会增加通信、token、协调和错误传播成本，简单或强依赖顺序的任务通常不值得拆分。

展开说明

设计重点包括：

1. 任务划分：子任务应尽量独立，并明确输入、输出、完成条件和证据要求。
2. 拓扑选择：中心化编排易控制；点对点协商更灵活，但状态一致性和终止更难。
3. 共享状态：通过结构化任务表或事件存储同步，避免只靠自然语言转述全部历史。
4. 冲突处理：对重复、矛盾和缺失结果设置确定性合并规则或额外验证。
5. 权限隔离：每个子 Agent 只获得任务所需的工具和数据范围，不能继承主 Agent 全部权限。
6. 终止与预算：限制子 Agent 数量、深度、重试和总成本，防止递归扩张。

多个相同模型并不会自动带来观点独立性；共享训练偏差和错误来源仍可能让它们一致出错。

工程实践

先用单 Agent 建立质量、延迟和成本基线，再只拆分能并行且上下文互不依赖的部分。为每个子任务分配 trace_id 和父子关系，要求返回结论、证据、未解决项及置信边界。压测并发峰值、部分子任务超时和结果冲突，验证主 Agent 能降级完成。

常见追问

1. Orchestrator-Worker 与多个 Agent 自由对话有什么区别？ 前者由中心编排者分解、分配和验收，状态边界清楚；自由对话更灵活，但容易重复、冲突且难确定责任。
2. 多 Agent 为什么可能比单 Agent 更差？ 拆分不当会丢上下文，通信和聚合引入噪声，多个 Agent 还可能共享同一盲点，同时显著增加 token 与延迟。
3. 如何防止子 Agent 递归创建导致成本失控？ 设置全局并发、深度、token 和时间预算，子任务必须有可验收输出，并由编排器统一授权继续派生。

一句话复习

多 Agent 的价值来自可并行的任务分解和上下文隔离，而不是简单复制更多模型调用。

参考资料

• 面经主题：Datawhale 真实面试题中的多智能体系统
• 技术依据：AutoGen、Anthropic 多 Agent Research 系统实践