单 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，中间还有很多混合形态。关键是找到那个平衡点，既不过度设计，也不欠设计。