单 Agent 与多 Agent 选型

30 秒回答

1. 任务复杂度评估维度（步骤数、工具种类、信息依赖、容错要求）
2. 单Agent适用场景与局限（简单任务、低延迟、资源受限）
3. 多Agent核心优势（并行化、专业化、容错隔离）
4. 架构决策的关键权衡（延迟vs质量、成本vs效果、维护复杂度）

回答与解析

答案要点

• 任务复杂度评估维度（步骤数、工具种类、信息依赖、容错要求）
• 单Agent适用场景与局限（简单任务、低延迟、资源受限）
• 多Agent核心优势（并行化、专业化、容错隔离）
• 架构决策的关键权衡（延迟vs质量、成本vs效果、维护复杂度）

决策框架：从任务特征出发

评估任务复杂度的四个维度：

• 步骤深度：是否需要>5步的链式推理
• 工具多样性：是否跨领域工具（搜索+代码+数据库+API）
• 信息依赖：子任务间是串行依赖还是可并行
• 容错要求：单点失败是否导致全局崩溃

单Agent架构

适用场景

• 明确边界的一次性任务（如单轮问答、简单工具调用）
• 延迟敏感场景（客服实时响应<500ms）
• 资源受限环境（边缘设备、低成本部署）

核心优势：实现简单、延迟可控、状态管理单一

关键局限：上下文爆炸（长任务导致KV Cache膨胀）、工具冲突（频繁切换降低专注度）、无法并行

多Agent架构

适用场景

• 复杂工作流（如"调研→分析→报告生成"全流程）
• 需要领域专家协作（代码Agent+测试Agent+评审Agent）
• 高可用要求（单个Agent失败可降级重试）

核心优势

• 专业化：每个Agent专注单一能力，Prompt更精准
• 并行化：独立子任务同时执行，缩短总耗时
• 容错隔离：失败范围可控，支持局部重试

主要代价：通信开销（Agent间状态同步）、编排复杂度（需要调度器/仲裁者）、调试困难（分布式追踪）

快手的实践权衡

最终建议：从单Agent起步，当观察到"上下文长度>8k且工具切换>3类"时，考虑拆分为多Agent。

口语版讲法(约4分钟)

• 本质是任务复杂度评估与架构权衡
• 单Agent适合简单、低延迟场景，多Agent适合复杂工作流
• 落地常见混合架构，用调度器协调
• 风险：通信开销、编排复杂度、调试困难
• 我的判断：从单Agent起步，遇到上下文>8k或工具切换>3类再拆分

这道题我觉得本质上是在问，怎么把任务拆解成Agent能处理的形式，以及拆到什么粒度最合适。不是简单说单Agent好还是多Agent好，而是要看任务本身的复杂度。

具体我会从四个维度来评估：步骤深度，比如需不需要超过5步的链式推理；工具多样性，是不是要跨领域调工具，比如搜索加代码再加数据库；信息依赖，子任务之间是串行等结果还是能并行跑；容错要求，单点失败会不会让整个流程崩掉。

先说单Agent。它最适合边界明确的一次性任务，比如单轮问答、简单工具调用，还有延迟敏感的场景，像客服实时响应要求500毫秒以内，或者资源受限的边缘设备。优势很明显，实现简单、延迟可控、状态管理单一。但局限也突出：上下文太长会导致KV Cache膨胀，频繁切换工具会降低专注度，而且没法并行。

多Agent就反过来，适合复杂工作流，比如从调研到分析再到报告生成这种全流程，或者需要领域专家协作，像代码Agent加测试Agent再加评审Agent。核心优势是专业化，每个Agent专注单一能力，Prompt可以写得更精准；并行化，独立子任务同时跑，缩短总耗时；还有容错隔离，失败范围可控，支持局部重试。但代价不小，通信开销、编排复杂度、调试困难，这些是绕不开的。

举个例子，电商直播运营助手。选品、定价、话术生成，这三件事依赖的数据和逻辑完全不同，用单Agent硬撑，Prompt会变得臃肿，上下文很容易超8k，工具切换也频繁。拆成多Agent，每个专注一块，调度器协调，整体效果会好很多。

这里有个坑，就是通信开销。如果Agent间状态同步太频繁，或者调度器设计得不好，多Agent的延迟可能比单Agent还高。所以上线我会特别关注编排层的性能，确保调度器本身不是瓶颈。

我自己的倾向是，从单Agent起步，别一开始就上多Agent。当观察到上下文长度超过8k，或者工具切换超过3类，这时候再考虑拆。真正落地，常常是混合架构，比如内容安全审核，初审Agent快速过一遍，复审Agent处理可疑内容，人机协同。说白了，这不是二选一，而是根据任务特征动态调整。

另外，多Agent的调度策略本身也是个值得深入的话题，比如用ReAct还是Tree-of-Thoughts来协调Agent间的依赖和冲突，不同策略对效果和延迟影响很大。

所以我会把架构决策看成一条连续谱，从单Agent到多Agent，中间还有很多混合形态。关键是找到那个平衡点，既不过度设计，也不欠设计。

关键一句:多Agent的调度策略选择（如ReAct vs Tree-of-Thoughts）对效果和延迟影响很大

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你正在给电商做一个商品推荐Agent，一开始任务很简单，就是个单轮问答。后来业务方说要加多步流程，比如先搜商品、再比价、最后写推荐理由。你会在什么时候决定把它拆成多个Agent？

2. 问法 2 · 层层追问

   你设计Agent系统时，任务复杂度怎么判断？……比如步骤多了、工具种类杂了，你觉得是继续用单Agent还是拆成多Agent？……各自的优缺点你分析一下？

3. 问法 3 · 直球架构

   直接说，设计一个Agent系统时，怎么根据任务复杂度决定用单Agent还是多Agent架构？分别分析适用场景和优劣，包括延迟、质量、成本、维护这些方面的权衡。