单 Agent vs 多 Agent 选型边界判断

不是所有问题都需要多 Agent。选型的核心问题：什么时候单 Agent 就够了？什么时候必须上多 Agent？

对比分析

维度	单 Agent	多 Agent
架构	简单	复杂
适用任务	简单、明确	复杂、需要协作
可扩展性	低	高
调试难度	低	高
通信开销	无	有
成本	低	高（多倍 LLM 调用）
可靠性	单点故障	冗余、容错

选型决策树

graph TD

    Q1{任务是否可拆分为独立子任务?} -->|是| Q2{子任务是否需要不同专业能力?}

    Q1 -->|否| Single[单 Agent]

    Q2 -->|是| Q3{是否需要并行处理?}

    Q2 -->|否| Single

    Q3 -->|是| Multi[多 Agent]

    Q3 -->|否| Q4{可靠性要求是否极高?}

    Q4 -->|是| Multi

    Q4 -->|否| Single

选型原则

优先单 Agent 的场景

场景	理由
任务简单明确	单 Agent 足以胜任
流程固定	用 Chain 而非 Agent
预算有限	多 Agent 成本高
需要快速迭代	单 Agent 调试简单
实时性要求高	多 Agent 通信有延迟

应该用多 Agent 的场景

场景	理由
复杂多步任务	需要拆分并行
需要多种专业能力	不同 Agent 专精不同领域
可靠性要求高	交叉验证降低错误
需要多轮讨论	Debate 模式达成共识
大型项目	层级模式委派任务

混合策略

实际应用中，常见的混合策略：

策略	说明
主 Agent + 工具	单 Agent 调用多个工具，简单有效
主 Agent + 专家 Agent	复杂子任务委派给专家 Agent
分阶段	简单阶段单 Agent，复杂阶段多 Agent

核心原则：从最简方案起步，只在确实需要时才引入多 Agent。多 Agent 带来的复杂度必须被其收益证明是值得的。

---

速记卡（面试闪卡）

Q1：一句话讲清「单 Agent vs 多 Agent 选型边界判断」到底是什么？

A：判断任务何时用单 Agent、何时必须上多 Agent 的选型边界问题。

Q2：选型决策树 —— 怎么理解？

A：像医院分诊台——按症状逐级分流。逐层问：任务能否拆成独立子任务？是否需不同专业能力？是否需并行？可靠性要求是否极高？全否就单 Agent，否则上多 Agent。

Q3：选型原则 —— 怎么理解？

A：像装修——刷墙自己来（单 Agent），整栋改建才请多工种团队（多 Agent）。优先单 Agent（任务简单/流程固定/预算紧/实时）；多 Agent 用于复杂多步、多种专业能力、高可靠、多轮讨论。

Q4：混合策略 —— 怎么理解？

A：像小公司——小项目老板自己干，难活雇专家顾问，不同阶段换打法。主 Agent+工具、主 Agent+专家 Agent、分阶段，按需逐步升级复杂度，而非一步到位。

Q5：快速问答 —— 怎么理解？

A：像考前自测小抄——把边界浓缩成三连问：简单明确用单 Agent、复杂多步/高可靠用多 Agent，从最简方案起步，只在确实需要时才引入多 Agent。

Q6：核心速记主线有哪些？

• 对比：单 Agent 简单低成本、单点故障；多 Agent 复杂高成本但冗余容错

• 决策树：按”可拆分→需不同能力→需并行→可靠性”逐级判断是否上多 Agent

• 原则：优先单 Agent，仅在复杂/多专业/高可靠时引入多 Agent

• 混合：主 Agent+工具/专家/分阶段，逐步升级而非一步到位

口诀

A：单多 Agent 怎么选，先看任务能否拆

简单明确自己干，复杂并行才组团

优先单兵省成本，多兵容错保安全

混合分阶段升级，最简起步不蛮干

相关链接

• 八股文学习路线图

• 全局导航

---

快速问答

问题	参考答案
什么时候用单 Agent？	任务简单明确、流程固定、预算有限、需要快速迭代、实时性要求高
什么时候用多 Agent？	复杂多步任务、需要多种专业能力、可靠性要求高、需要多轮讨论
如何选择？	从最简方案起步，只在确实需要时才引入多 Agent。多 Agent 的复杂度必须被其收益证明是值得的