先记住这个答案
没有普遍成立的最低拆分条件。优先用单 Agent 加工具做基准；当子任务上下文相互污染、失败会级联、或并行能明显降低关键路径延迟，且这些收益在评测中稳定超过 token 重复、协议与协调成本时，拆成多 Agent 更合理。类型不同本身既不是必要也不是充分条件。
- 上下文隔离是强信号而非门槛
- 要限制失败级联再考虑拆
- 并行收益须覆盖协调成本
拆分 vs 加工具：内部机制差异
单 Agent 加工具通常由同一模型在同一任务循环中调用工具，上下文主要共享；工具扩展能力，但不天然提供隔离。模型在长上下文中切换多个子任务时，前后信息可能互相干扰，也可能因上下文压力遗漏约束。是否“按序”取决于实现，工具调用也可并发。
多 Agent 通常让不同子任务拥有独立 system prompt、对话历史或工具权限，便于聚焦和限制爆炸半径；但也可被设计成共享状态。代价是 token 重复、通信协议、状态同步与协调开销。因此不是在“单 Agent 做不到”时才拆，而是当评测证明隔离、失败边界或并行收益稳定超过这些成本时才拆。
工程场景：企业知识库问答系统
假设：拆成两个检索 Agent，一个只访问内网文档，另一个只访问公网，各返回结构化摘要，再由主 Agent 汇总。这样可降低内网上下文污染公网提示的风险，两条检索路径也可并行；某一路失败可被限制在分支内，主 Agent 重试、降级或标注缺口，而不是天然“互不影响”。
这是用额外 token、编排复杂度和可能的汇总延迟，换取隔离与潜在并行收益。采用前应与单 Agent 加工具基准做 A/B：比较关键信息遗漏率、端到端延迟、token 成本、失败恢复时间和人工复核负担，只有收益稳定可衡量才保留拆分。
边界：不是所有任务都适合拆
当子任务强依赖彼此的中间结果时，强行拆分会引入大量同步开销。例如编写一个需多次修改同一文件的代码任务，若拆成多个 Agent 分别改不同模块，合并冲突会频繁，导致返工。此情形下单 Agent 加工具、按序处理反而更高效。
另一失效场景是上下文重叠度过高：各 Agent 都需要几乎相同的长上下文。此时每个 Agent 都重复传递相同信息，token 成本按倍数增长，而单 Agent 可共享记忆。处理方式：使用共享向量库或共同工具，限制传递上下文宽度。
容易答错的地方
- 多 Agent 总是更高效
- 多 Agent 显著增加 token 消耗与调度复杂度。若任务简单且可单上下文处理，单 Agent 加工具通常更省成本、更快，也更易调试。
- 只要任务不同类型就要拆 Agent
- 类型差异既不是必要条件也不是充分条件。同类任务也可为并行或投票而拆；不同类型任务若共享上下文、强耦合或无并行收益，用路由、提示链或单 Agent 加工具更合适。最终看评测中的隔离、失败边界、并行与协调成本。
面试官还会怎么问？
当子任务上下文有重叠但又需隔离时怎么处理？
可在子 Agent 上下文中只放必要片段，共享数据放向量库或专用工具。避免传整个对话历史，这可降低重叠 token 成本，但需设计好检索。
拆成 3 个以上 Agent 的最小可用判据是什么？
不存在通用的“3 个以上最小判据”。在已有拆分有效的前提下，每新增一个 Agent 都应有可衡量的边际收益：输入输出清晰、失败可局部重试或补偿、职责不被前序结果强耦合、且不全量复用同一上下文。若只是复制上下文或频繁等待彼此中间结果，应合并或用工作流。
单 Agent 加工具失败重试和拆分后失败重试有何差异？
若单 Agent 没有检查点，重试可能重走较长链路；拆分后常可只重试失败子任务并复用已完成结果，可能节省成本。但这不是拆分天然保证：单 Agent 也可做检查点，多 Agent 也需设计幂等、下游补偿与部分结果合并。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。