为什么采用多 Agent，而不用单 Agent 或纯脚本？

核心回答

我会根据流程是否确定、是否需要独立上下文与能力边界，以及拆分收益能否覆盖协作成本来选择。任务复杂本身，不足以证明需要多 Agent。

• 纯脚本或固定工作流适合步骤、分支和验收条件已经明确的任务。用普通代码处理数据、调用接口和生成文件，执行顺序更容易控制；其中也可以包含一次或几次模型调用。
• 单 Agent 加工具适合需要根据反馈动态决定下一步，但任务目标集中、工具集合和上下文仍可管理的场景。它可以连续调用多个工具，不必按工具数量拆 Agent。
• 多 Agent适合能划分为清楚子目标、需要独立上下文或不同工具配置的任务；独立子任务还可以并行。代价是增加派发、上下文交接、结果合并、失败恢复和调用成本。

例如企业研搜可以把公开搜索、内部数据库和私有文档交给不同专家，主 Agent 汇总并生成报告。但如果需求只是按固定条件查一张表再套模板，脚本或单 Agent 更直接。是否保留多 Agent，应在同一批任务上比较质量、耗时、成本和故障处理，而不是预设它一定更准确。

展开说明

1. 先判断真正需要拆开的是什么

脚本不等于完全不能用大模型。比如“校验参数、查业务接口、让模型写摘要、生成文档”，如果处理顺序确定，可以由普通代码或工作流串起来。只有当系统需要根据工具反馈选择新问题、改变搜索方向或补充步骤时，动态 Agent 的价值才更明显。

单 Agent 也能使用搜索、数据库和文档工具，并处理多轮反馈。若一个上下文窗口足以容纳相关信息，目标始终一致，单 Agent 往往更容易追踪整体状态。仅为了复用提示词或输出格式，可以使用函数、模板或 Skill，不必新建独立执行角色。

多 Agent 更有价值的情况，是子目标之间存在明确边界。例如公开资料研究需要大量搜索上下文，数据库分析需要表字段、统计口径和查询结果，私有文档问答又依赖另一套资料。分别执行可以减少互不相关的上下文干扰，让每个角色只接触与任务相关的工具描述，再把必要结论和证据交给主 Agent。实际数据权限仍要由工具和服务端执行，角色名称与提示词本身不能保证权限隔离。

2. 拆分必须能说明输入、输出和合并方式

以研搜项目为参考，主 Agent 通过 DeepAgents 注册三个自定义业务专家：网络专家用 Tavily 查公开信息，数据库专家用 SQL 工具查内部业务数据，知识库专家通过 RAGFlow 获取内部文档答案。主 Agent 自己掌握附件读取、Markdown 和 PDF 工具，负责最终交付。

这项拆分的理由是信息来源和执行上下文不同，而不是要求三个角色使用不同的大模型。每次委派需要给出清楚的研究子问题、已确认约束和预期结果；专家返回结论、依据和缺失项，主 Agent 再判断是否足以回答原问题。

独立的外部政策检索和内部销量统计可以分别执行；如果后续分析需要前一步得到的商品名单，就必须等待该结果。最后也要有明确的汇总者，检查时间口径、来源和结论是否一致。把任务拆开却没有约定怎样重新组合，容易出现各部分都完成、最终答案却漏项的问题。

确定性的部分继续用代码处理。例如路径解析、文件转换和事件封装，不需要为了“多 Agent”再安排一个角色。实际系统可以同时包含普通函数、固定工作流和动态专家委派。

3. 收益和代价需要一起验证

拆分可能带来上下文隔离、专业工具配置和独立分支并行，但并行速度收益取决于任务依赖、模型或工具限流，以及最慢分支和汇总耗时。增加 Agent 也可能增加重复检索、模型调用和信息摘要损失；多个角色使用相似模型或相同证据时，还可能重复同一种错误。

状态管理也不会自动变简单。需要知道每项子任务属于哪次执行、依赖什么、何时超时，以及哪些结果已被主 Agent 使用。专家失败时，要能有限重试、跳过可选分支或说明缺失，避免角色之间反复转交。共享业务操作的幂等和写入归属，同样需要应用实现。

验证时可以让脚本、单 Agent 和多 Agent 在相同任务与条件下完成同一个目标，比较最终可验收结果、端到端耗时、工具与模型调用成本、失败恢复，以及修改一项业务规则的维护工作量。若多 Agent 只增加中间消息，未解决可观察的问题，就应考虑合并角色或改回固定流程。

常见追问

一个 Agent 提示词写长一些，能否代替多 Agent？

有时可以。若职责仍然集中，整理提示词、按需加载知识和精简工具就可能解决问题。若多个子任务需要各自较大的工作上下文、不同执行策略或独立维护，拆分才更有意义；应先定位单 Agent 的实际瓶颈。

多 Agent 是否更容易保证正确？

不能由 Agent 数量判断。独立检查者和不同证据来源可能帮助发现错误，但需要明确检查规则和冲突处理。多个角色共享错误前提，也可能给出一致的错误答案，最终仍要按业务结果和证据验收。

长链路是否就适合多 Agent？

链路长而步骤固定时，显式工作流可能更清楚；任务短但需要两个独立领域的完整分析时，也可能值得委派。更有用的判断是目标边界、上下文规模、工具配置和依赖关系，而不是只数步骤。

对应教程

参考资料