面试题 · 评估
搜索「并行」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在设计Agent系统时，如何根据任务复杂度决定采用单Agent还是多Agent架构？请分析各自的适用场景和优劣。
评估任务复杂度的四个维度：
适用场景
按学习路线查看教程、项目和面试题。
核心优势：实现简单、延迟可控、状态管理单一
关键局限：上下文爆炸（长任务导致KV Cache膨胀）、工具冲突（频繁切换降低专注度）、无法并行
适用场景
核心优势
主要代价：通信开销（Agent间状态同步）、编排复杂度（需要调度器/仲裁者）、调试困难（分布式追踪）
| 场景 | 推荐架构 | 原因 |
|---|---|---|
| 短视频智能客服 | 单Agent | 响应快、流程标准化 |
| 电商直播运营助手 | 多Agent | 需同时处理选品、定价、话术生成 |
| 内容安全审核 | 混合架构 | 初审Agent+复审Agent，人机协同 |
最终建议：从单Agent起步，当观察到"上下文长度>8k且工具切换>3类"时，考虑拆分为多Agent。
场景切入
假设你正在给电商做一个商品推荐Agent，一开始任务很简单，就是个单轮问答。后来业务方说要加多步流程，比如先搜商品、再比价、最后写推荐理由。你会在什么时候决定把它拆成多个Agent？
层层追问
你设计Agent系统时，任务复杂度怎么判断？……比如步骤多了、工具种类杂了，你觉得是继续用单Agent还是拆成多Agent？……各自的优缺点你分析一下？
直球架构
直接说，设计一个Agent系统时，怎么根据任务复杂度决定用单Agent还是多Agent架构？分别分析适用场景和优劣，包括延迟、质量、成本、维护这些方面的权衡。
这道题我觉得本质上是在问，怎么把任务拆解成[[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，中间还有很多混合形态。关键是找到那个平衡点，既不过度设计，也不欠设计。