架构

AI 工作流设计：多步骤智能体流程的五种模式

作者：IdeaBosque最后更新：2026年9月1日

核心要点

到 2026 年 8 月，通过 OpenAI 的 MCP 工具调用达到 1 月水平的 98 倍，仅 8 月就翻了一倍以上（AAIF）——一个用户请求现在触发包含多次调用的工作流，这使工作流设计而非提示词设计成为生产纪律。
Gartner 预测到 2028 年每个智能体工作流的 AI 推理成本将上升五倍以上——每 token 价格下降的同时每工作流成本上升，因为智能体工作流消耗的 token 比聊天高出多个数量级。
MCP 路线图将 Tasks 改造为官方扩展（SEP-2663），并新增 Multi Round-Trip Requests（SEP-2322），使多步骤流程能在无状态服务器上存活——协议现在假设工作运行时间长且跨越多轮。
OpenAI 声明其失准监控器可能暂停"智能体长时间运行的任务"，且 API 任务会停止而非恢复——生产工作流必须能从持久状态恢复，而不是从活进程恢复。
一个 38 工具的 RFQ 模块在代码中运行所有这些模式——由 guard 强制的状态转换、15 分钟 TTL 上的幂等预留释放、以及报价时冻结的 FX 快照。

据Agentic AI Foundation 的使用分析，ChatGPT 用户的 MCP 工具调用在 2026 年 8 月达到 1 月水平的 98 倍——而且仅 8 月就翻了一倍以上。Resend 的 MCP 流量从供应商一侧讲述了同样的故事：4 月 106,719 次调用，8 月 1,062,650 次。协议自己的维护者在新的 MCP 路线图中给出了运营结论："现代智能体工作负载不再适合标准的请求-响应模式。循环可以运行更长时间，服务器可以推送流式结果，并且显然需要在中途引导工作。"

聊天从来不是难的部分。难的是工作流：一个 RFQ 背后的目录查询扇出、必须在 ERP 写入之前到达的审批、在报价中途超时的供应商 API、在定价与预订之间不能漂移的汇率。Gartner 预测到 2028 年每个工作流的推理成本将上升五倍以上，即使每 token 价格在下降，因为智能体工作流在多次调用中进行推理、谈判和自我追问。本文定义了决定多步骤智能体流程能否承受这种负载的五种工作流级模式——扇出、检查点、补偿、持久状态和度量分支——并将每种模式锚定在一个注册了 38 个 MCP 工具、对接 GraphQL 后端的可用 RFQ 实现上。

工作流是你设计的单元。下面的图表把五种模式压缩成一分钟：并行读取扇出、带两个人工闸门的串行写入主干、失败时的类型化补偿，以及将它们联系在一起的持久状态规则。

模式 1：读取扇出，写入串行

第一个工作流决策是依赖图的形状。大多数多步骤智能体流程大部分是并行的：一个 RFQ 需要来自三个供应商目录的价格档、五个行项目的批量可用性、以及客户细分——这些彼此互不依赖。将这些步骤串行化会使延迟按步骤数倍增，也会使任何一次超时的影响半径倍增。正确的默认做法是并行发起所有独立读取，只串行化写入链——链条中每一步都消费上一步的输出。

报价工作流中的写入链之所以严格有序，是出于业务原因而非技术原因：请求确认 → 报价创建 → 可用性预留 → 分期计划。我们的 RFQ 引擎用代码中的 operation guards 强制这一点——RequestOperationGuard 拒绝从未确认的请求创建报价，QuoteOperationGuard 在报价通过可编辑窗口后拒绝行项目修改。工作流模式在所有系统中都相同：批量加载器后面的并行读取、承载状态变更写入的窄串行主干、以及放在代码而不是提示词中的 guard。一个每次运行都"自行决定"排序的智能体，是一个没有不变量的工作流。

模式 2：人工检查点是状态，不是提示词

第二个模式决定人所在的位置。在仅提示词的设计中，"提交前询问用户"是模型可以遵循也可以不遵循的建议。在工作流设计中，检查点是持久状态：流程停在具名状态中，持久化继续所需的一切，只有人工操作才能使其向前推进。9 月 1 日，OpenAI 披露其生产失准监控器可以自动停止潜在的未授权活动——并诚实地指出了代价：安全防护"偶尔可能将合法活动标记为潜在网络滥用……这可能包括与网络安全没有直接关系的工作，或智能体长时间运行的任务"——这个区别从此变得具有运营紧迫性。在 ChatGPT 和 Codex 中，用户会被要求审查暂停的任务；在 API 上，任务直接停止。

为那个世界构建的工作流把暂停视为设计出的状态，而不是异常：运行记录显示完成了什么、什么在等待、恢复路径是什么。我们 RFQ 引擎的两个便捷工具——confirm_request_and_create_quotes 和 confirm_quote_and_create_installments——之所以存在，正是因为人工闸门位于它们之间：人工确认，然后多步骤的机械工作作为一次被审计的调用运行。Camunda 对 1,150 名高级 IT 领导者的调查发现 71% 的组织使用 AI 智能体，但只有 11% 的用例到达生产；跨越这道鸿沟的工作流，是那些审批作为系统能停留数小时的状态、而不是系统提示词里一句话的工作流。在运行时层执行检查点的机制位于《Loop Engineering：为什么智能体运行时是新的中间件》；工作流模式是：在发布任何东西之前，决定哪些步骤为人停下、流程从什么状态恢复。

模式 3：每个前进步骤都需要补偿路径

第三个模式是教程跳过的那个：什么来撤销一个步骤。长时间运行的工作流会在半途失败——供应商 API 在五行中的第四行返回错误、智能体正在定价时预留过期、报价已批准但付款计划失败。没有补偿链的工作流把每次失败变成手动清理。有补偿的工作流把每次失败变成一个类型化、幂等的反向操作。

报价实现展示了这一解剖结构。可用性预留以 15 分钟 TTL 过期，失败面被枚举为类型化错误——HOLD_NOT_FOUND、HOLD_ALREADY_EXPIRED、AVAILABILITY_INSUFFICIENT——每个映射到不同的恢复动作：复查、重新获取、或转给人工。释放预留是幂等的，因此网络分区后的重试不会双重释放，确认预留也绝不会重复扣减。工具调用包裹在带指数退避的重试装饰器中，每次调用的状态、时长和载荷（超过 400KB 时卸载到对象存储）都落入审计记录。这就是被泛化的模式：前进步骤获取资源；补偿步骤释放它们；每个补偿都可以安全地运行两次。如果你的工作流说不出每一步的撤销方式，它就不是工作流——它是一个还没遇到供应商宕机的演示。

模式 4：无状态协议，有状态工作流

第四个模式解决了 2026-07-28 MCP 规范中一个表面上的矛盾。该规范移除了协议级会话和初始化握手（SEP-2575、SEP-2567），使服务器无需保持状态即可水平扩展；路线图将 Tasks 改造为官方扩展（SEP-2663），同时 Multi Round-Trip Requests（SEP-2322）取代了服务器发起的请求，使 elicitation 流程仍能在任务中途工作。协议是无状态的；承载状态的是工作流。具体来说：每个请求必须自包含到达，工作流的状态存放在持久、可检查的记录中——而不是服务器的内存里。

这一架构选择使上一个模式变得可存活。在我们的 RFQ 引擎中，预留的 hold_token 和 hold_expires_at 直接位于报价行项目上，汇率在报价时用 fx_rate_locked_at 时间戳冻结——是快照，不是活引用。任何服务器实例都能接手下一个请求；重启的进程从记录恢复，而不是从内存。Astra 的警告使可恢复性成为平台交互要求，而不只是崩溃容错：如果前沿模型的安全防护暂停了你 38 小时的无人值守运行，能存活的工作流是那个把状态保存在进程之外的工作流。我们在《MCP 无状态协议：对 B2B 部署意味着什么》中介绍了无状态规范的部署机制；在工作流层面，规则很简单——把每一步都当作暂停前的最后一步来设计，让下一步可以从审计轨迹中重建。

模式 5：按测量数据分支，不按模型判断

第五个模式治理条件分支。多步骤工作流包含决策点——这一行是否有足够利润可报价、这一批是否动销慢到需要标记、这一客户细分是否解锁折扣档。让模型即兴决定这些分支会把方差重新引入唯一需要确定性行为的地方。工作流的答案是测量闸门：数据携带标志，分支读取它们。

在 RFQ 引擎中，每个报价行项目携带从批量记录加载的 guardrail_price_per_uom 和 slow_move_item——"按目录价报价"与"标记为毛利复核"的分支读取两个字段，而不是让模型估算毛利。折扣规则由四个层级作用域（全局、细分、商品、供应商商品）作为数据组合而成，而不是作为推理步骤。这也是工作流设计与成本相遇的地方：Gartner 的推理分析警告"将任务路由到智能体推理模型会使供应商推理成本至少增加五倍"，并推荐"高度优化的推理分层、路由与编排"。基于存储标志分支的工作流把模型推理保留给需要它的步骤——定价判断、异常解释、谈判起草——让类型化数据决定其余部分。同样的纪律也出现在数据平台中，Dagster 的编排上下文工作将物化事件视为工作流消费而非重新推导的运营上下文。

五种模式，各一句话

读取扇出、写入串行——形状是业务不变量，用 guard 编码。检查点是系统能停留的状态，因为平台本身就会暂停你。补偿是每个前进步骤的一等公民步骤，构造上即幂等。状态存在于持久记录中，不在协议或进程里。分支读取测量标志，把模型推理留给为之定价的步骤。这些模式都不需要框架迁移；它们都需要按步骤决定谁拥有它——模型、运行时，还是人。

一个代表性构建

一个每周处理 200 个团队预订 RFQ、横跨酒店、航班和活动的中型旅游运营商，基于这些模式重建了它的报价工作流。读取并行发起——五个目录、批量可用性、价格档——通过一个单一 MCP 模块，该模块在 11 个领域 mixin 中暴露 38 个工具，每个工具的模式都是类型化的，每次调用都被审计。写入主干串行：请求确认、组装报价并在报价时锁定 FX、以 15 分钟 TTL 和幂等释放获取预留、安排分期计划。两个人工闸门位于资金承诺之处——请求确认和报价确认——每个闸门都是流程可以停留数小时的持久化状态。当供应商 API 在定价中途超时，类型化错误将该行路由到复查，而不是破坏报价。报价周转时间从三天的手动查询降到四小时以内，每次写入都有人工批准。结果是为精简团队提供了报价能力，而不是替代人手。