现在看到 Tool Calling就想给 Agent 挂十几个工具看到 LangGraph就想先画一张复杂的流程图看到多 Agent又很容易把检索、规划、执行、总结分别包装成一个 Agent。最后系统里 Agent 的数量越来越多但效果未必更稳定排查问题反而更困难。我之前也会下意识地认为多 Agent 应该比单 Agent 更“高级”。真正做过 RAG、工具调用和 Agent Workflow 后我现在更倾向于另一种判断单 Agent、工作流和多 Agent 不是三个逐级升级的版本而是三种不同的控制方式。选哪一种关键不在于任务看起来有多复杂而在于哪些步骤可以由代码确定哪些决策必须交给模型以及任务之间是否真的需要独立的上下文和角色。先把三个概念分清楚1. 单 Agent模型自己决定下一步单 Agent 通常由一个模型、一套指令和一组工具组成。用户给出目标后模型判断是否调用工具、调用哪个工具、拿到结果后是否继续执行直到输出最终答案。比如企业知识助手收到“查询报销制度并帮我整理出差申请需要的材料”后可以先调用知识库检索工具再根据检索结果组织答案。整个过程中任务目标和对话上下文都在同一个 Agent 内。它的优势是结构简单、上下文完整、迭代速度快。只要工具边界清楚一个 Agent 就能完成不少看起来复杂的任务。但它的问题也很直接决策权主要交给模型。工具越来越多、指令越来越长、分支越来越复杂后模型可能选错工具、遗漏步骤或者在失败后反复重试。2. 工作流由程序控制主干模型处理不确定部分工作流的核心不是有多少个节点而是执行路径主要由代码、状态机或有向图控制。例如处理一份文档时系统可以固定执行文件校验 → 内容解析 → 信息抽取 → 结果审核 → 数据入库。信息抽取和结果审核可以使用模型但先执行什么、失败后走哪条分支、是否允许入库都由程序决定。这里可能有多个模型节点但它仍然不一定是多 Agent。因为这些节点没有各自持续的目标、记忆和行动循环只是在确定流程中完成一个局部能力。工作流的优势是稳定、可测试、可观测。代价是灵活性较弱新增业务分支时需要调整流程设计。3. 多 Agent多个自治角色协作完成任务多 Agent 不是“多调用几次模型”而是系统中存在多个相对独立的决策主体。每个 Agent 通常拥有自己的角色指令、工具、上下文甚至终止条件再通过管理者调度或 Agent 之间的移交完成任务。例如生成一份行业研究报告可以让研究 Agent 搜集材料让数据 Agent 分析指标让审阅 Agent 检查论证最后由主 Agent 汇总。不同子任务需要的工具和上下文明显不同而且部分工作可以并行这时多 Agent 才有实际价值。它带来的并不只是能力拆分还有协调成本任务如何分派、上下文传多少、结果如何验收、冲突如何处理、失败由谁重试这些都要额外设计。不要先问“任务复杂不复杂”“复杂任务用多 Agent简单任务用单 Agent”听起来合理但实际不够准确。一个步骤很多的任务如果步骤固定、输入输出明确工作流往往比多 Agent 更合适。反过来一个步骤不多的任务如果需要不同领域的独立判断也可能适合多个 Agent。我现在更关注下面四个问题。第一执行路径能不能提前确定如果 80% 以上的步骤可以提前写成规则就优先使用工作流。能用if/else、状态机和重试策略稳定表达的逻辑没有必要让模型每次重新推理。例如审批流程中的权限校验、金额判断、状态更新本质上都是确定性逻辑。模型可以负责理解用户意图、提取申请信息但不应该决定是否绕过审批。如果路径无法预先枚举需要模型根据中间结果持续选择下一步才更接近 Agent 的适用范围。第二任务是否真的需要角色隔离把 Prompt 分成“规划”“执行”“总结”三段并不意味着一定要创建三个 Agent。很多时候它们只是同一个任务的三个阶段用普通工作流节点就够了。只有当不同角色需要明显不同的工具、规则或上下文并且把所有内容塞进一个 Agent 已经造成干扰时拆分才有意义。例如财务分析和法律合规需要不同知识、工具与风险边界适合隔离而“检索后总结”通常没有必要拆成两个自治 Agent。第三子任务能否独立完成和验收多 Agent 最适合可分解、可独立执行、可验证的任务。主 Agent 给出明确输入子 Agent 返回结构化结果主 Agent 能判断结果是否合格。如果子任务之间高度依赖前一个 Agent 的一句模糊输出就会改变后续所有步骤多 Agent 只会放大误差。上下文在多次转交中还可能被压缩、误解或丢失。所以能不能拆的关键不是“能否给它起一个角色名”而是能否定义清楚输入、输出和验收标准。第四失败成本是否允许模型自治生成报告的某个段落不理想可以重新生成但涉及付款、删除数据、提交审批等写操作时错误成本完全不同。失败成本越高越应该用确定性流程包住 Agent限制工具权限、校验参数、保证幂等在关键动作前加入人工确认。多 Agent 并不会自动带来安全性反而可能让责任链更长。用同一个例子看三种架构假设我们要做一个企业助手支持“查询制度、创建待办、提交请假申请”。第一版完全可以采用单 Agent给它三个边界清晰的工具根据用户意图选择调用。开发成本最低也最适合快速验证需求。当请假申请增加固定规则后可以演进成工作流Agent 负责理解请假时间和原因程序负责检查余额、日期冲突和审批人用户确认后再提交。这里真正增加的是确定性控制而不是 Agent 数量。如果以后系统扩展到人事、财务、IT 运维等多个领域每个领域都有大量相似工具和独立权限单 Agent 开始频繁选错工具这时可以考虑多 Agent入口 Agent 负责路由领域 Agent 只看到本领域的指令和工具。这个演进过程说明架构通常不是一步到位的单 Agent 验证需求 → 工作流固化稳定路径 → 在明确的领域边界上拆分多 Agent。不是每个系统都要走到最后一步。停在单 Agent 或工作流完全可能就是最合理的结果。三种方案怎么对比判断维度单 Agent工作流多 Agent执行路径模型动态决定程序预先控制多个 Agent 协作决定灵活性高中低高稳定性取决于模型和工具设计通常最高取决于协调机制上下文集中容易共享按节点传递状态分散需设计交接调用成本较低可控通常更高调试难度中低高适合任务开放式、工具规模可控步骤明确、失败分支可枚举可并行、角色边界清楚的复杂任务还要注意一个经常被忽略的问题模型调用次数并不等于系统复杂度的全部。多 Agent 还会增加路由、交接、结果汇总和重复上下文的成本。一次任务原本需要两次模型调用拆分后可能变成路由一次、三个子 Agent 各一次、汇总一次。如果效果没有明显提升这种拆分就不划算。我的选择原则如果现在让我从零设计一个 Agent 系统我会按下面的顺序判断普通代码能解决吗能确定实现的部分先用代码。一个模型加工具能解决吗能就先做单 Agent并建立评测集。是否存在固定步骤和高风险动作有就引入工作流把关键路径收回来。单 Agent 的问题是否来自明确的职责冲突只有确认工具重叠、指令冲突或上下文干扰后再拆多 Agent。拆分后能否独立评测每个 Agent不能就暂时不要拆。这里最重要的一点是先测再拆。不能因为一次调用失败就认定单 Agent 不够用。先检查工具名称、参数描述、RAG 结果、上下文和 Prompt再通过评测确认失败是否具有稳定模式。如果单 Agent 在某一类任务上持续失败而这一类任务又能形成清晰的专业边界多 Agent 才是在解决问题。否则它很可能只是在转移问题。