从 Workflow 到 Multi-Agent：如何选择 Agent 项目架构

最近做 Agent 项目的时候，很容易被一些很热闹的词带着走：Multi-Agent、Supervisor、Planner、Tool-Calling、Memory、Graph、Workflow、Human-in-the-loop。每一个词看起来都很有道理，也都能写出一套很漂亮的架构图。但是到真正落地时，我们还是会回到几个朴素的问题：

• 这个任务的路径到底是不是确定的？
• 失败以后能不能恢复？
• 每一步的输入输出能不能被检查？
• 用户需要的是一个“会聊天的助手”，还是一个“能稳定完成流程的系统”？
• 我们希望模型自由发挥，还是希望模型只在某些节点上发挥？

如果只从技术名词出发，很容易把 Agent 项目做成一团看起来很智能、实际很难调试的东西。更稳妥的方式，是先把 Agent 当成一种工程系统，而不是当成一个“更聪明的聊天机器人”。一个 Agent 项目真正复杂的地方，通常不是模型本身，而是模型怎样和状态、工具、知识库、权限、日志、评估、人类确认一起工作。

图：抽象网络节点结构。图片来源：Ecliptic Graphic / Unsplash。

这篇文章想整理一套比较务实的判断方式：大多数 Agent 项目不应该一开始就追求完全自治，而应该先用 workflow 做骨架，再在需要弹性的地方嵌入 agentic 节点。 至于 master + sub Agent，或者说 Supervisor + Worker，更适合作为 workflow 中的一种组织方式，而不是替代 workflow 的全部。

1. 常见词汇的概念

在讨论架构之前，先解释一下常见概念。

1.1 Workflow

Workflow 指的是流程大体由开发者预先定义好。系统知道第一步做什么，第二步做什么，什么时候分支，什么时候结束。

例如一个论文辅助阅读工具可以这样设计：

1. 上传 PDF；
2. 解析正文、图表和参考文献；
3. 切分文档并建立索引；
4. 根据用户问题检索相关片段；
5. 生成回答；
6. 给出引用来源；
7. 如果引用不足，提醒用户而不是强答。

这里也可以调用大模型，也可以让模型判断问题类型，但系统的骨架是确定的。它的优点是稳定、可测试、可恢复，也更容易做权限控制。缺点是弹性有限，遇到开放性任务时，流程可能显得死板。

1.2 Agent

Agent 更强调模型能够根据当前状态自行决定下一步动作。它可能会先搜索，再调用工具，再反思，再补充检索，最后输出答案。这个过程不是完全写死的，而是在一个循环中由模型选择。

一个典型 Agent loop 可以写成这样：

1
2
3
4
5
6
观察当前任务和状态
选择下一步动作
调用工具或生成中间结果
读取工具返回
判断是否继续
输出最终结果

这种方式适合任务路径不固定的场景，比如开放式研究、代码修复、数据探索、复杂文档问答等。它的风险也很明显：如果没有边界，Agent 可能会反复调用工具、偏离目标、消耗过高，或者在错误方向上越走越远。

1.3 Master + Sub Agent

很多人说的 master + sub Agent，本质上更接近 Supervisor + Worker 或 Orchestrator + Worker。一个上层 Agent 负责理解任务、拆分任务、分配任务、汇总结果；多个子 Agent 分别负责检索、规划、代码、验证、写作等工作。

这种结构听起来像“一个聪明的总指挥带着一组专家”，但工程上需要克制。Supervisor 不应该是一个无所不能的黑盒，它更应该是一个上下文管理器、任务分发器和终止条件判断器。如果 Supervisor 既负责规划、又负责全部推理、还负责工具调用、验证和总结，那么所谓多 Agent 只是把复杂性换了一个名字。

1.4 Multi-Agent

Multi-Agent 不等于“多个角色名”。如果只是写了几个 prompt，比如“你是规划师”“你是工程师”“你是审稿人”，但它们看见同样的上下文、能调用同样的工具、输出格式也没有约束，那么系统并不会因为角色变多而变得可靠。

真正有用的 Multi-Agent，通常体现在四件事上：

• 上下文隔离：每个 Agent 只看到自己需要的信息；
• 工具隔离：不同 Agent 只能调用和职责相关的工具；
• 输出契约：每个 Agent 都有清晰的输入输出结构；
• 验证闭环：某个 Agent 的输出会被另一个节点检查，而不是直接进入最终答案。

所以，多 Agent 的意义不是“让系统看起来更像一个团队”，而是把复杂任务拆成可观察、可限制、可替换的模块。

2. Workflow、Agent、Supervisor 的区别

可以先用一张表建立直觉。

如果只问“到底用 master + sub Agent 还是 workflow”，我的回答会比较明确：

默认先用 workflow。等你知道哪些步骤需要弹性，再把那些步骤做成 agentic 节点；等单个 agentic 节点已经太复杂，再拆成 Supervisor + Worker。

这不是保守，是工程上更容易走得远。Agent 项目最怕的不是不够智能，而是看起来很智能，但每一次出错都不知道为什么。

3. 为什么 Agent 项目首先是架构问题

一个完整的 Agent 项目，通常至少包含这些层次：

1
2
3
4
5
6
7
8
9
10
用户入口
  -> 任务理解与约束提取
  -> 流程编排与状态管理
  -> 模型调用
  -> 工具调用
  -> 知识检索
  -> 中间结果校验
  -> 人类确认
  -> 最终输出
  -> 日志、追踪、评估与回放

如果只把注意力放在调用哪个模型或者写几个 prompt，系统很快就会变得难以维护。在真实项目里，问题大部分出现在：

• 检索返回了很多片段，但模型不知道哪些可靠；
• 工具调用失败后没有重试策略；
• 多轮任务中状态越来越乱；
• Agent 生成了代码，但没有执行验证；
• 系统做了高风险操作，却没有人工确认；
• 线上出现错误后，只能看到最终回答，看不到中间轨迹；
• prompt 改了一点，旧任务的表现突然变差，但没有评估集可以比较。

因此，Agent 架构的核心是让模型在一个可观察、可约束、可恢复的系统里完成任务。

4. LangGraph 的价值：把 Agent 放进状态图

LangGraph 这类框架的一个重要价值，是把 LLM 应用从函数调用链推进到带状态的图。在图里，我们可以定义节点、边、条件分支、状态更新、检查点和中断恢复。这样，Agent 不再只是一个无限循环的黑盒，而是可以被拆成多个明确的步骤。

用 LangGraph 的视角看，一个 Agent 系统可以包含：

• State：当前任务的共享状态，例如用户目标、计划、检索结果、中间文件、错误日志；
• Node：一个具体步骤，例如意图识别、检索、代码生成、工具执行、结果验证；
• Edge：节点之间的流转关系；
• Conditional Edge：根据模型或规则决定下一步去哪里；
• Checkpoint：保存中间状态，方便恢复和回放；
• Interrupt：在关键步骤暂停，等待用户确认。

这对生产项目非常关键。因为真实业务并不是“一次 prompt 进去，一段答案出来”。更常见的情况是，系统要在多个步骤之间移动，并且每一步都可能失败、重试、等待确认或走向另一个分支。

可以把一个较稳的 Agent 项目理解为：

1
2
3
4
5
确定性流程负责边界
模型节点负责判断
工具节点负责行动
验证节点负责刹车
状态图负责把这些东西连起来

这也是为什么我倾向于把 LangGraph 看成 Agent 系统的编排层，而不只是写 Agent 的框架。它真正重要的地方，不是让我们多写几个 Agent，而是让 Agent 的行为有结构。

5. 常见 Agent 工作模式

参考 LangGraph、Anthropic、OpenAI Agents SDK、AutoGen 等资料以后，可以把常见模式整理成几类。它们不是互斥的，实际项目里经常组合使用。

我的经验是，能用前五种解决的，就不要急着上完全开放的 Agent Loop。因为前五种模式的结构更清晰，测试和排错也更容易。Agent Loop 应该更多使用在那些确实需要探索的工况中。

6. 推荐的架构：Workflow 骨架 + Agentic 局部

如果要从零开始做一个 Agent 项目，可以优先考虑下面这种结构。

1
2
3
4
5
6
7
8
9
10
START
  -> Intake: 理解用户目标、约束和风险
  -> Planner: 生成结构化计划
  -> Router: 判断任务类型和所需资源
  -> Context Builder: 检索知识、读取文件、准备工具上下文
  -> Worker Stage: 一个或多个 Agentic 节点完成具体任务
  -> Verifier: 检查事实、格式、代码、引用和风险
  -> Human Gate: 必要时请求用户确认
  -> Finalizer: 组织最终输出
END

这个结构有几个好处：

1. 外层流程明确，系统不会无限游走；
2. 中间状态可以保存，失败后可以从某个节点恢复；
3. 每个节点都能单独评估；
4. 需要灵活判断的地方仍然可以用 Agent；
5. 高风险操作可以自然插入人工确认。

更具体一点，可以把状态设计成下面这样：

1
2
3
4
5
6
7
8
9
10
11
12
TaskState:
  user_goal: 用户原始目标
  constraints: 时间、格式、权限、预算等约束
  task_type: 当前任务类型
  plan: 分步骤计划
  retrieved_context: 检索或读取到的上下文
  artifacts: 已生成的文件、代码、表格、报告等
  decisions: 关键决策记录
  tool_results: 工具调用结果
  errors: 错误与重试历史
  risks: 需要提醒或人工确认的风险
  final_answer: 最终输出

状态设计不要贪多，也不要把整段对话原样塞进去。好的状态应该像项目看板，它不记录所有废话，只记录后续节点真正需要的信息。

7. Supervisor + Worker 应该怎么用

Supervisor + Worker 是一个很常见也很有用的模式，但它需要边界。

一个比较健康的 Supervisor 通常负责：

• 判断用户目标；
• 拆分任务；
• 分配给合适的 Worker；
• 汇总 Worker 的结果；
• 判断是否需要继续；
• 在预算或轮次达到上限时停止。

它不应该同时承担所有细节工作。Worker 也不应该只是换了名字的同一个大模型。如果要拆 Worker，最好按照能力和工具边界拆，而不是按照人设拆。

例如一个科研辅助 Agent 可以这样分：

这样拆的意义在于，每个 Worker 的输入输出和权限都不一样。Retriever 不需要写文件，Writer 不需要跑危险命令，Executor 不需要决定整篇报告的结构。系统因此更清楚，也更安全。

如果所有 Worker 都能做所有事，那么 Supervisor 只是在把同一个问题转发给多个不受约束的模型，复杂度会上升，可靠性却不一定上升。

8. 什么时候选择 Workflow，什么时候选择 Multi-Agent

可以从任务的不确定性来判断。

8.1 适合 Workflow 的情况

如果任务路径基本确定，优先 workflow。

比如：

• 发票识别与报销审批；
• 固定格式的数据分析报告；
• 企业知识库问答；
• 论文 PDF 摘要；
• 日志分类与告警；
• 简历筛选；
• 标准客服流程。

这些任务不是不能用 Agent，而是没有必要让 Agent 拥有太多自由。系统真正需要的是稳定、可控和可解释。

8.2 适合 Supervisor + Worker 的情况

如果任务可以拆分，但拆分方式需要根据具体问题动态变化，可以考虑 Supervisor + Worker。

比如：

• 写一份长篇调研报告；
• 修复一个不熟悉的代码仓库；
• 对多个方案做技术选型；
• 从很多文档中整理项目架构；
• 结合检索、代码、表格和写作完成综合任务。

这类任务有一个共同点：目标明确，但路径不完全确定。Supervisor 可以先规划，再按需要调用不同 Worker。

8.3 适合 Agent Loop 的情况

如果任务路径很难预先定义，每一步又依赖上一步的观察结果，可以使用 Agent Loop。

比如：

• 自动调试一个复杂报错；
• 在网页或系统中探索信息；
• 根据实验结果不断修改代码；
• 做开放式数据探索；
• 在沙箱中尝试多种解决方案。

但 Agent Loop 最好满足几个条件：

• 有最大轮次和预算；
• 有清晰终止条件；
• 工具是安全受限的；
• 关键动作可回滚；
• 最终结果能被验证。

如果这些条件都没有，完全自治的 Agent 很容易变成一个难以预测的成本中心。

9. 一个面向研究助手的架构例子

假设我们要做一个面向科研或工程领域的 Agent 系统。用户可能会问：

请帮我调研某个方向，整理主要方法，比较优缺点，并给出一个可实现的技术路线。

这个任务看似只是“写报告”，实际包含很多子任务：

• 明确研究边界；
• 搜索资料；
• 判断资料质量；
• 提取方法；
• 对比方法；
• 结合实际条件做取舍；
• 写成自然、可靠的文章；
• 给出参考资料。

我会用这样的结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
用户问题
  -> Intake Node
     提取主题、目标读者、篇幅、时间范围、是否需要代码

  -> Planning Node
     生成结构化调研计划

  -> Retrieval Stage
     并行检索官方文档、论文、项目文档、已有笔记

  -> Analysis Stage
     对资料分组，提炼共识和分歧

  -> Architecture Stage
     形成候选架构：workflow、supervisor-worker、agent loop、混合方案

  -> Verification Stage
     检查是否有过时信息、来源不明判断、逻辑跳跃

  -> Writing Stage
     生成最终博客、报告或设计文档

这里的核心不是“让一个 Agent 一口气写完整篇文章”，而是把研究过程拆开。检索和写作可以是两个不同节点；分析和验证也应该分开。这样做出的文章会更稳，也更容易解释“为什么最后选择这个架构”。

对于类似 EnerAgentic 这样的垂直领域研究助手，也可以采用类似思想：

• 外层 workflow 管理“文档解析 - 检索 - 推理 - 工具执行 - 结果验证 - 报告生成”；
• 内部用专业 Agent 完成规划、检索、仿真建模、代码执行、结果解释；
• 对于 MATLAB、Python、数据库写入等高风险操作，加入工具权限和人工确认；
• 对每次回答保留引用、工具日志和关键推理摘要。

也就是说，垂直领域 Agent 的关键不是简单堆叠多个角色，而是把领域知识、工程工具、推理过程和验证机制放到同一个有状态系统里。

10. Agent 项目的工程重点

10.1 状态管理比记忆更重要

很多 Agent 项目会很早讨论 memory，但更基础的是 state。

Memory 更像长期偏好或历史知识；State 是当前任务正在发生什么。对于多数业务系统，先把 state 做清楚，比急着做长期记忆更重要。

例如：

• 当前任务走到哪一步；
• 已经检索了哪些资料；
• 哪些工具调用失败过；
• 用户确认了哪些动作；
• 哪些约束不能违反；
• 当前输出是否通过验证。

这些都属于 state。如果 state 混乱，memory 再丰富也很难救回来。

10.2 工具要小而清楚

Agent 调用工具时，工具设计非常关键。一个好工具应该有：

• 清晰的名字；
• 明确的参数 schema；
• 简短但足够的说明；
• 可预测的返回格式；
• 失败时明确的错误信息；
• 尽量幂等的行为；
• 必要的权限限制。

不要给 Agent 一个含糊的万能工具，比如 do_anything(task)。这种工具看起来灵活，实际上会让系统失去边界。更好的方式是把工具拆成可理解的小动作，例如 search_docs、read_file、run_tests、create_report、request_approval。

10.3 验证节点不是装饰

Agent 系统里，Verifier 很容易被低估。很多项目只在最后让模型反思一下，但这往往不够。

更可靠的验证包括：

• 代码是否能运行；
• 引用是否真的支持结论；
• 表格数字是否前后一致；
• 输出格式是否符合要求；
• 是否触发安全或权限风险；
• 是否遗漏用户明确约束；
• 是否超过预算或轮次。

能用程序验证的，就不要只让模型判断。模型适合做语义判断，但格式、测试、数字、文件是否存在这些事情，应该尽量交给确定性工具。

10.4 Human-in-the-loop 要放在正确位置

人类确认不应该只出现在系统失败以后，而应该出现在高风险动作之前。

比如：

• 删除或覆盖文件；
• 发送邮件；
• 提交代码；
• 调用付费接口；
• 修改数据库；
• 访问敏感数据；
• 对外发布内容。

一个成熟的 Agent 系统，不是完全不需要人，而是知道什么时候应该停下来等人。

10.5 评估要从第一天开始

Agent 项目很容易在 demo 阶段惊艳，到了维护阶段变得痛苦。原因之一是没有评估。

可以从一个小而真实的评估集开始：

• 10 个常见任务；
• 5 个困难任务；
• 5 个容易误导系统的任务；
• 5 个需要拒绝或确认的高风险任务。

每次改 prompt、换模型、改工具、改检索策略，都跑一遍。评估不一定一开始就很复杂，但必须能比较。否则系统改着改着，很难知道自己是在进步还是在漂移。

11. 几个常见误区

11.1 误区一：Agent 越多越智能

Agent 数量增加，首先增加的是通信成本、状态复杂度和调试难度。只有当职责、上下文、工具、输出都能被清楚隔离时，多 Agent 才有意义。

11.2 误区二：Planner 写得越详细越好

计划太粗会失控，计划太细会僵硬。比较好的计划应该描述目标、步骤和验收条件，但不要把每个微小动作都写死。否则后面的 Agent 没有调整空间。

11.3 误区三：把 RAG 当成万能知识层

RAG 能让系统拿到外部知识，但不能自动保证答案正确。检索质量、切分策略、重排序、引用呈现、上下文压缩都会影响最终结果。对于重要任务，RAG 后面最好接一个验证步骤。

11.4 误区四：用 prompt 代替权限

“请不要删除文件”不是权限控制。真正的权限控制应该发生在工具层和系统层。Agent 能不能调用删除工具、能不能访问某个目录、能不能提交操作，都应该由代码控制。

11.5 误区五：没有终止条件

开放式 Agent 最常见的问题之一是停不下来。一个任务至少应该有最大轮次、最大工具调用次数、最大预算，以及无法继续时如何降级的策略。

12. 框架选择的一点看法

现在 Agent 框架很多，不同框架的重点不完全一样。

如果项目目标是“把复杂流程稳定跑起来”，我会优先看 LangGraph 这类状态图框架。如果目标是“围绕文档和知识库做问答”，LlamaIndex 会很自然。如果目标是“研究多 Agent 协作形态”，AutoGen 和 Magentic-One 很有参考价值。如果已经在 OpenAI 生态中，Agents SDK 的 handoffs、guardrails、tracing 这些概念也很适合工程化落地。

但框架不是架构本身。真正需要先决定的是：

• 哪些步骤必须确定；
• 哪些步骤允许模型判断；
• 哪些工具可以自动调用；
• 哪些动作必须人工确认；
• 哪些输出必须验证；
• 出错后如何恢复。

这些问题想清楚了，框架选择反而会简单很多。

13. 一个比较稳的落地顺序

如果团队刚开始做 Agent 项目，可以按下面顺序推进。

第一步：先做普通 Workflow

把任务拆成明确步骤，用代码串起来。模型只负责其中一两个节点，例如意图分类、摘要、结构化抽取。

目标是先跑通完整闭环。

第二步：加入状态和日志

记录每一步输入、输出、工具调用、错误和耗时。此时不追求复杂智能，先保证能回放和排错。

第三步：把不确定节点改成 Agentic Node

找出流程中最需要弹性的地方。例如检索策略、代码调试、资料分析。只让这些节点具备循环和工具选择能力。

第四步：加入 Verifier 和 Human Gate

对重要输出做验证，对高风险操作做人类确认。这样系统才有刹车。

第五步：当单个 Agentic Node 太复杂时，再拆 Supervisor + Worker

只有当一个节点已经包含多个明显不同的职责时，才需要拆成多 Agent。拆分标准不是“看起来更高级”，而是“职责边界真的不同”。

这个顺序虽然慢一点，但系统会比较稳。很多 Agent 项目的长期质量，不取决于第一版有多炫，而取决于后面还能不能继续改。

14. 总结：让模型自由，但不要让系统失去边界

Agent 项目最吸引人的地方，是它让系统具备了一定的自主性。模型不再只是回答问题，而是可以读资料、调用工具、拆分任务、生成中间结果，甚至修正自己的错误。

但工程上，我们不能只追求自主性。一个真正可用的 Agent 系统，需要同时具备：

• 自主性：模型能在局部做判断；
• 可控性：系统知道边界在哪里；
• 可观察性：每一步发生了什么可以追踪；
• 可恢复性：失败以后能重试或回滚；
• 可验证性：最终结果不是只靠感觉；
• 可维护性：节点、工具、状态都能被替换和调整。

所以，关于“master + sub Agent 还是 workflow”，我最后的建议是：

先用 workflow 承担结构，再用 Agent 承担不确定性；先让系统可观察，再让系统更自治；先把单个任务闭环做好，再讨论多 Agent 协作。

如果用一句更短的话说，就是：workflow 是骨架，Agent 是肌肉，Verifier 是刹车，Human-in-the-loop 是安全带。

真正好的 Agent 架构，不是让每个环节都显得聪明，而是让系统在该聪明的地方聪明，在该稳定的地方稳定。

参考资料

• kramdown Syntax Documentation
• LangGraph: Workflows and Agents
• LangGraph: Persistence
• Anthropic: Building Effective Agents
• OpenAI Agents SDK: Agents
• Microsoft AutoGen: Magentic-One
• Google ADK: Workflow Agents
• LlamaIndex: Building an Agent

• Previous
  设定了 Temperature=0 为什么模型输出不同结果?