四大多 Agent 架构详解（一）：Workflow 如何把固定流程变成可回放的系统

2026-09-20公众号文章

架构师（JiaGouX）

我们都是架构师！
架构未来，你来不来？

最近在一个企业在线客服接入大模型的项目里，模型能查资料、能调用工具，演示时反应也不错。可一到上线前，问题慢慢露了出来：资料版本有没有记全，基准测试能不能复现，敏感字段会不会被送到不该去的服务，最后的上线方案又凭什么下结论。

这几件事得按顺序查清楚。前一关没有过，后一关就不能接着往下走。

既然路径已经定了，为什么还要让一个 Agent 临场决定下一步交给谁？

Workflow 处理的就是这个矛盾。

当路径本来就稳定时，代码掌握路由权，Agent 负责节点内的工作，整条链路才更容易上线、排查和恢复。

Workflow 的职责边界

图 1：代码控制固定路径，Agent 在节点内完成检索、分析和工具调用；检查点与运行时状态决定能否继续。

图中有三类东西：绿色节点是 Agent 的执行边界，黄色节点是运行时的检查点，蓝色节点负责把顺序和状态串起来。先把这条边界看清，再看框架 API，就不容易把“能调用 Agent”和“能管理 Workflow”混成一件事。

先看一张地图

多 Agent 架构经常被放在一张图里比较，但它们首先是在处理不同的控制关系：谁决定下一步？

先把 Workflow 拆成三层：

层次	负责什么	不能替代什么
Agent 节点	检索、分析、生成、调用工具	不决定全局路由，不自行跳过检查点
Workflow 控制流	顺序、条件、重试、超时、终止	不替代节点内的推理和工具操作
运行时状态	当前节点、结果版本、证据、恢复点	不等于一段聊天历史

所以，Workflow 不是“低配版 Agent”，也不只是把几次模型调用用箭头连起来。它把不确定性留在节点内部，把路由、状态和恢复放在模型之外。

四种架构先只看一个问题：谁来决定下一步？

架构	谁决定下一步	信息流	主要代价
Workflow	代码和规则	固定链路或 DAG	规则变化通常需要改流程
Supervisor	中央 Agent	中心派发、汇总	中央上下文和决策容易成为瓶颈
Hierarchical	多层 Supervisor	层级上下行	跨层调试和权限边界更复杂
Swarm / Handoff	当前 Agent	平级接力	路由依据更难统一审计

这四种架构可以组合，但控制权的归属不能含糊。看每个框架时，都可以回到这张表：它究竟把“下一步”交给了代码、一个中央 Agent，还是当前正在工作的 Agent？

用同一条链路跑一遍

继续用“评估新模型是否适合接入在线客服”这个任务。最小的 Workflow 是：

资料收集 → 基准测试 → 安全审查 → 方案成稿

资料收集节点留下带来源的模型信息和版本记录；基准测试节点留下测试环境、样本、结果和复现命令；安全审查节点留下风险项、证据和处理建议；方案成稿节点只使用已经通过前置检查的结果。

节点之间传的应该是带版本和证据的结果，不是一句“测试完成”。下游至少要知道测了什么、在哪个环境里测、哪些用例失败，以及结果能不能进入下一步。

节点至少要带上这些字段：

input_ref       上游结果版本
node            当前节点
attempt         当前执行次数
output_ref      本次结果版本
quality_status  passed / failed / pending
next_action     由运行时规则计算出的下一步

next_action 不应该由 Agent 随口写一句“建议继续”来决定。节点结果先落库，运行时再根据检查点、重试预算和权限规则计算下一步。这样才能区分“Agent 没有完成”和“运行时没有放行”。

Agent 做节点，代码做控制流

以基准测试节点为例，Agent 可以在自己的边界内选择测试工具、定位失败原因、生成报告，并在预算内修正一次配置后重跑。

运行时管的是另一组事情：当前任务在哪个节点，节点最多重试几次，超时后标记为失败还是待人工确认，只有哪些结果才能进入安全审查，以及调度器重启以后从哪里继续。

这也是 Workflow 容易落地的原因。模型仍然有探索空间，但全局顺序、状态变更和恢复点都能在代码中找到。

实际运行时，系统还要记下一条事件链，不能只留下最后一段文字：

node_started
tool_called
artifact_written
quality_checked
node_succeeded
node_failed
retry_scheduled
workflow_paused

这些名字不是框架统一规定的格式，但先把它们记下来，排查和恢复才有抓手。任务中途停住时，可以知道最后成功写入了哪个结果；重放时，可以从最近的稳定节点继续，避免把已经完成的模型调用全部再跑一次。

检查点要放在节点边界

固定顺序不代表失败以后只能从头开始。假设基准测试在第三组用例上超时，运行时可以保存超时原因、输入版本和日志，按节点策略重试；超过预算，就把任务标记为失败或待处理，不能让方案成稿节点把测试当成已经通过。

同样，安全审查发现某个接口会把敏感字段发送到不允许的外部服务时，任务应停在安全审查节点，或者退回修改输入。成稿 Agent 不能用一段解释把风险“写过去”。

每个节点都需要自己的完成条件：

节点	最低完成条件	未通过时的动作
资料收集	来源可访问，版本和时间已记录	补来源或暂停
基准测试	环境、数据切片和结果可复现	在节点内重试，超预算后升级
安全审查	风险项有证据，阻断条件已处理或明确升级	退回修改或人工确认
方案成稿	只引用通过检查点的结果	不生成发布结论

检查点的作用，是让错误尽量停在靠近源头的地方。上游结果一旦带着错误进入下游，后面的 Agent 往往只会把它写得更完整，未必能重新核实事实。

节点失败后的重试、暂停与恢复

图 2：检查点把失败分成可重试和需暂停两类，人工处理后从稳定节点恢复，而不是把整条链路重跑一遍。

关键在于失败后的每条分支都有可以检查的状态：重试从哪一版输入开始，暂停时留下了什么证据，人工处理以后从哪个稳定节点恢复。没有这些记录，所谓恢复通常只是重新跑一遍。

同一条 Workflow，五种框架表达

把同一条链路分别放进 LangGraph、CrewAI、Microsoft Agent Framework、OpenAI Agents SDK 和 Claude Agent SDK，差异主要出在控制流落在哪一层。这里不做星级比较，只看它们怎样表达这条固定流程。

框架	固定链路通常落在哪里	需要单独核对的地方
LangGraph	`StateGraph` 、节点、边和条件边；状态是显式对象	路由、状态、持久化和调试可以被单独检查。官方文档把预先确定的 Workflow 与动态决定工具的 Agent 分开，也提供 prompt chaining、parallelization 和 evaluator-optimizer 等模式。
CrewAI	角色、任务以及顺序流程或 Flow 组织节点	表达业务角色和任务关系比较直观，但要单独核对当前版本的状态持久化、流式和失败恢复能力。
Microsoft Agent Framework	由应用代码组合顺序、条件和并行步骤	更适合把“节点是什么”和“步骤怎样连”拆开看；具体 Builder/API 随版本变化，不能沿用旧文章的类名判断能力。
OpenAI Agents SDK	应用代码控制调用顺序；子 Agent 可以作为 `agents as tools` 被调用	子 Agent 作为工具返回结果时，控制权仍在外层；`handoff` 则会把控制权交给另一个 Agent，两者的信息流不要混写。
Claude Agent SDK	如果把它作为节点执行单元，固定顺序仍需要外部调度层包住	从这里能看出：框架提供 Agent Loop，不等于自动提供业务 Workflow；节点契约、检查点和恢复策略仍要由应用负责。

这张表只比较表达方式，不是当前版本能力排名。LangGraph 的文档明确展示了 StateGraph、条件边、持久化和调试；OpenAI Agents SDK 的文档明确区分了 agents-as-tools 和 handoffs。CrewAI、Microsoft Agent Framework 和 Claude Agent SDK 的具体 API，仍要以对应版本的官方文档和实际运行结果为准。

从这个任务看，差异更具体：LangGraph 可能把四个节点和状态字段直接画成图；CrewAI 可能先从角色和任务关系开始；OpenAI Agents SDK 需要由应用代码决定何时调用哪个子 Agent；Claude Agent SDK 可以作为执行节点，外层仍要维护顺序和验收。它们都能参与 Workflow，但“谁掌握路由”不能因为换了 SDK 就自动消失。

Workflow 的代价也很明确

路径固定，带来可预测性，也意味着端到端延迟会沿节点累加。资料收集、测试、审查和成稿不能同时开始时，并行收益就很有限。

顺序明确，带来容易回放，也意味着上游判断错了，错误会沿链路向下游传播。Google Research 对多种 Agent 系统的研究把顺序依赖、通信成本和错误传播放在同一个分析框架里：任务的依赖结构，应该先于 Agent 数量进入架构选择。

代码掌握路由，带来清晰的审计，也意味着流程变化需要改代码。产品规则频繁变化、分支越来越多时，Workflow 可能变成一棵难维护的条件树。

有一个实用的信号：如果运行时开始反复问模型“现在调用哪个 Agent”“是否跳过这一步”“失败后回到哪里”，说明代码已经在模拟 Supervisor。继续往固定管线里塞条件，未必比承认需要动态调度更简单。

什么时候优先选 Workflow

我会先看路径是否稳定，再决定系统里是否需要多个 Agent。

审批、ETL、固定内容流水线、模型评测和部署检查，通常具备这些特征：步骤顺序大部分时间不变；输入输出可以写清楚；节点结果能用规则、测试或人工审批验收；失败可以在边界重试或暂停；任务需要审计、回放和明确的权限范围。

相反，如果下一步取决于刚刚发现的事实，需要临时选择专家，或者用户意图在对话中持续变化，固定流程会开始显得笨重。此时再评估 Supervisor、层级协作或 handoff，因为问题已经从“节点怎么执行”变成了“谁来决定下一步”。

先把能确定的部分交给代码

多 Agent 系统里，模型最容易接管的往往是路由：下一步做什么、什么时候结束、失败后回到哪里。

对于这些本来就能写清楚的规则，我更倾向于先交给代码。Agent 在节点内部保留探索空间，运行时把状态、重试、超时、检查点和恢复边界管住，出问题时也能查清是哪一步出了问题。

Workflow 的价值，落在可重放、可验收，以及中途停下后还能继续。

当路径无法提前写死时，问题才会变成：谁来决定下一步？这就是下一篇要展开的 Supervisor。

参考资料

Anthropic，Multi-agent coordination patterns: Five approaches and when to use them（https://claude.com/blog/multi-agent-coordination-patterns）
Google Research，Towards a science of scaling agent systems: When and why agent systems work（https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/）
LangGraph，Workflows and agents（https://docs.langchain.com/oss/python/langgraph/workflows-agents）
OpenAI Agents SDK，Tools：Agents as tools（https://openai.github.io/openai-agents-python/tools/）
OpenAI Agents SDK，Handoffs（https://openai.github.io/openai-agents-python/handoffs/）
CrewAI，Flows（https://docs.crewai.com/en/concepts/flows）
Microsoft Agent Framework，Workflows（https://learn.microsoft.com/en-us/agent-framework/workflows/）
Claude Agent SDK，Overview（https://platform.claude.com/docs/en/agent-sdk/overview）

如喜欢本文，请点击右上角，把文章分享到朋友圈

如有想了解学习的技术点，请留言给若飞安排分享

因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享

·END·

相关阅读：

从 ReAct 到 Agent Team：一个医疗系统研发任务里的信息流与责任边界
面试官：讲一讲多 Agent 协作如何保持一致性
来自 Google 的多智能体最佳实践
Claude 做方案，Codex 写代码：多模型协作怎么交接才稳
Harness工程还没唱罢，Environment工程已然登场
DeepSeek Harness 底层原理深度解析

版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!

架构师

我们都是架构师！

关注架构师(JiaGouX)，添加“星标”

获取每天技术干货，一起成为牛逼架构师

技术群请加若飞：1321113940 进架构师群

投稿、合作、版权等邮箱：[email protected]

前往微信阅读全文

内容来自公众号，可前往微信查看原文。