企业官网建设流程全解析

现在看到 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 系统，我会按下面的顺序判断：

1. 普通代码能解决吗？能确定实现的部分，先用代码。

2. 一个模型加工具能解决吗？能，就先做单 Agent，并建立评测集。

3. 是否存在固定步骤和高风险动作？有，就引入工作流，把关键路径收回来。

4. 单 Agent 的问题是否来自明确的职责冲突？只有确认工具重叠、指令冲突或上下文干扰后，再拆多 Agent。

5. 拆分后能否独立评测每个 Agent？不能，就暂时不要拆。

这里最重要的一点是先测再拆。不能因为一次调用失败，就认定单 Agent 不够用。先检查工具名称、参数描述、RAG 结果、上下文和 Prompt，再通过评测确认失败是否具有稳定模式。

如果单 Agent 在某一类任务上持续失败，而这一类任务又能形成清晰的专业边界，多 Agent 才是在解决问题。否则，它很可能只是在转移问题。