MCP与工作流编排

5503 字约 18 分钟

AIAgentMCP工作流

2026-07-24

MCP 负责连接能力，工作流引擎负责管理执行状态。MCP 本身不是工作流引擎——它提供标准化的工具调用接口，但不管控步骤之间的流转逻辑、状态持久化和异常恢复。理解两者的分工，是设计可靠自动化系统的前提。

一、基本定义

MCP（Model Context Protocol） 是一个开放协议，标准化了 AI 应用与外部工具和数据源的连接方式。MCP 的核心能力是暴露工具和转发调用——它不关心调用发生在哪个业务阶段，也不管理调用之间的依赖关系。

工作流引擎（Workflow Engine） 是一类负责管理多步骤任务执行状态的组件。它定义步骤的先后顺序、处理条件分支、管理重试和回滚、持久化执行状态。典型代表包括 Temporal、Apache Airflow、AWS Step Functions、LangGraph 等。

两者的关系可以用一句话总结：MCP 解决「怎么调用工具」，工作流引擎解决「按什么顺序调用、失败怎么办、在哪里暂停」。

维度	MCP	工作流引擎
核心职责	工具发现、参数校验、调用转发	步骤编排、状态管理、异常恢复
状态	无状态（每次调用独立）	有状态（持久化执行进度）
流程控制	无（不关心调用顺序）	DAG、条件分支、循环、并行
错误处理	返回错误码和信息	重试、补偿、回滚、降级
持久化	不持久化	断点续跑、审计日志

二、单 Tool 调用 vs 多步骤工作流

理解 MCP 在工作流中的位置，首先要区分「单 Tool 调用」和「多步骤工作流」：

单 Tool 调用：Agent 发起一次 tools/call，Server 执行并返回结果。这个过程是原子的、无状态的。MCP 天然擅长这个层级。

多步骤工作流：一个业务目标需要多个步骤按特定顺序完成，步骤之间有数据依赖、条件判断和错误处理逻辑。例如「拉取 GitHub issue → 分析优先级 → 分配给团队成员 → 发送通知」——这涉及 4 个以上的工具调用，且有依赖关系和分支逻辑。

关键认知：MCP 的 tools/call 是单步操作。当你需要多步编排时，必须在 MCP 之上引入工作流控制逻辑——这个逻辑可以由 Agent 的 Planner 承担，也可以由独立的工作流引擎承担。

三、DAG（有向无环图）

DAG 是工作流编排中最基础的结构模型。它将任务分解为节点（Node），用有向边（Edge）表示依赖关系，且不允许环路。

在 MCP 场景中，DAG 的典型应用：

节点 A 和 C 可以并行执行（它们之间没有依赖）
节点 D 必须等待 B 和 C 都完成
节点 E 和 F 可以并行执行

MCP 在这个 DAG 中的角色：每个节点对应一个或多个 MCP Tool 调用。但 DAG 的调度逻辑（哪些节点可以并行、哪些需要等待）不在 MCP 层处理——这是工作流引擎或 Agent Planner 的职责。

DAG 的局限性：真实业务中经常出现循环依赖（如「处理完一条记录后检查是否还有下一条」），纯 DAG 无法表达这类逻辑，需要引入循环结构。

四、状态机

状态机（State Machine）是管理工作流执行进度的核心机制。每个工作流实例在任意时刻处于一个确定的状态，根据条件和事件在状态之间迁移。

一个典型的 MCP 工具调用工作流状态机：

MCP 不维护状态机——它不知道某个 Tool 是第一次调用还是第三次重试。状态管理必须由外部的 Agent 或工作流引擎实现。

状态持久化的关键数据：

当前执行到哪个节点
每个节点的输入和输出
重试次数和累计耗时
待执行的补偿操作列表

五、条件分支

工作流中经常需要根据上一步的结果决定下一步走哪条路径。条件分支的实现方式：

基于结果的条件：根据 MCP Tool 返回值判断。例如「查询用户等级」工具返回 vip=true，走快速通道；否则走普通通道。

基于异常的条件：工具调用失败时走降级路径。例如主数据源查询失败，切换到备用数据源。

基于外部输入的条件：等待人工审批后根据审批结果选择路径。

MCP 在条件分支中的角色很明确：提供数据（工具返回值作为判断依据）和执行操作（根据分支选择调用不同的工具）。分支判断逻辑本身由工作流引擎或 Agent 处理。

六、循环

循环是工作流中比条件分支更复杂的控制结构。常见模式：

遍历循环：对集合中的每个元素执行相同操作。例如「遍历所有未处理的 issue，逐个分析并分类」。

条件循环：重复执行直到满足条件。例如「持续轮询部署状态，直到完成或超时」。

重试循环：操作失败后重复尝试。例如「调用 API 失败，等待后重试，最多 3 次」。

在 MCP 场景中，循环带来一个实际问题：上下文膨胀。如果 Agent 在循环中反复调用 MCP Tool，每次的 tool_result 都会累积在 LLM 上下文中。解决方案：

在工作流引擎层面管理循环，而非让 Agent 在单次对话中循环
每轮循环只保留摘要结果，不保留完整 tool_result
设置循环次数上限，防止死循环

七、人工审批

某些操作不能完全自动化，需要在流程中插入人工审批节点。这是工作流引擎的核心能力之一，MCP 本身不提供这个功能。

典型的人工审批场景：

场景	触发条件	审批内容
高风险操作	Agent 要执行删除/修改操作	操作类型、目标资源、影响范围
金额审批	涉及费用超过阈值	费用明细、业务理由
内容审核	生成内容需要人工确认	生成结果、数据来源
异常升级	自动处理失败或不确定	异常详情、建议方案

实现方式：工作流引擎在需要审批的节点暂停执行，将审批请求发送给指定人员，等待审批结果后恢复执行。MCP 可以在这个流程中扮演两个角色：

发送通知：通过消息类 MCP Server（Slack、邮件）发送审批请求
提供上下文：通过查询类 MCP Server 获取审批所需的背景数据

八、长任务

当一个工作流涉及大量 MCP 工具调用或耗时较长的操作时，面临以下挑战：

执行超时：单个 MCP Tool 调用可能超时。工作流引擎需要区分「工具正在执行」和「工具已经失败」，并设置合理的超时策略。

状态持久化：长任务可能跨越分钟甚至小时级别。如果中间进程崩溃，必须能从上次断点恢复。这要求工作流引擎持久化每个节点的执行状态和中间结果。

资源管理：长任务可能持有 MCP Server 端的资源（如数据库连接、文件锁）。工作流引擎需要在异常终止时确保资源正确释放。

进度反馈：长任务需要向用户提供进度信息。工作流引擎可以在每个节点完成后记录进度，由 Agent 或 UI 层展示给用户。

解决方案通常是分阶段执行：将长任务拆分为多个独立阶段，每个阶段有明确的输入、输出和检查点。阶段之间通过持久化存储传递状态，而不是依赖 LLM 的上下文窗口。

九、补偿事务

当工作流的部分步骤已经成功执行，但后续步骤失败时，需要补偿（Compensate） 已成功的步骤，使系统回到一致状态。这类似于分布式系统中的 Saga 模式。

示例场景：

步骤 1: 创建订单（成功）→ MCP Tool: order__create
步骤 2: 扣减库存（成功）→ MCP Tool: inventory__deduct
步骤 3: 处理支付（失败）→ MCP Tool: payment__charge
补偿 2: 恢复库存          → MCP Tool: inventory__restore
补偿 1: 取消订单          → MCP Tool: order__cancel

补偿事务的设计要点：

每个正向操作都需要对应的补偿操作：这不是 MCP 层需要关心的——MCP Server 只需要暴露 inventory__deduct 和 inventory__restore 两个独立工具，补偿逻辑由工作流引擎编排。
补偿操作本身也可能失败：需要设计兜底方案（如人工介入、告警）。
幂等性至关重要：补偿操作可能被执行多次，必须保证重复执行不会造成额外影响。

十、重试和幂等

重试是工作流中最常见的容错机制，但盲目重试可能导致数据不一致。核心原则：只有幂等操作才能安全重试。

幂等（Idempotent） 指同一操作执行多次和执行一次的效果相同。例如：

set_temperature(25) 是幂等的——无论调用多少次，温度都是 25°C
add_balance(100) 不是幂等的——调用两次会多加 100

MCP Tool 的幂等性设计策略：

策略	说明	示例
天然幂等	操作本身具有幂等性	写入固定值、设置状态
幂等键	客户端提供唯一 key，Server 去重	`idempotency_key: "order-123-create"`
条件执行	只在满足条件时执行	`update_if_version(expected_version=3)`
非幂等	操作天然不幂等，需要外部控制	发送消息、扣减余额

工作流引擎的重试策略：

重试条件: 网络超时、5xx 错误、临时性故障
不重试条件: 4xx 错误、业务逻辑错误、权限不足
退避策略: 指数退避（1s → 2s → 4s → 8s）
最大重试次数: 3 次（可配置）
超时上限: 累计不超过 60s

注意：MCP 协议层面不提供重试机制。重试逻辑由 Agent 或工作流引擎实现。对于非幂等工具，工作流引擎必须配合幂等键或事务机制来保证安全重试。

十一、断点续跑

断点续跑是指工作流在中断后，能从上次成功执行的位置继续运行，而不需要从头开始。这是长任务和高可靠工作流的核心需求。

实现断点续跑的关键要素：

状态持久化：每个节点执行完成后，将节点 ID、输入参数、输出结果持久化到外部存储
幂等保证：重新执行某个节点时，不能因为之前的部分执行而产生副作用
检查点设计：合理设置检查点粒度——太粗会导致大量重复执行，太细会增加持久化开销

在上图中，节点 4 执行失败。恢复时从节点 4 开始重试，节点 1-3 跳过（已完成）。

MCP 在这个场景中的限制：MCP 本身不保存调用历史，不记录「哪些操作已经成功执行」。断点续跑完全依赖工作流引擎的状态管理能力。MCP Server 端可以通过幂等键支持断点续跑——当工作流引擎重新发送同一个请求时，Server 能够识别并返回之前的结果。

十二、Agent 自主规划 vs 确定性工作流

这是工作流编排中一个核心的架构选择：

确定性工作流（Deterministic Workflow）：流程预先定义，步骤固定，分支条件明确。适合业务流程清晰、合规要求高的场景。

特征	说明
流程定义	预先编排（代码或配置文件）
执行路径	可预测、可审计
异常处理	预定义的降级和补偿逻辑
适用场景	财务流程、审批流程、数据管道
MCP 角色	纯粹的工具执行通道

Agent 自主规划（Autonomous Planning）：Agent 根据当前状态和目标，动态决定下一步调用什么工具。适合探索性强、难以预定义流程的场景。

特征	说明
流程定义	运行时由 LLM 动态生成
执行路径	不可完全预测
异常处理	Agent 自主判断重试或换策略
适用场景	研究探索、代码调试、数据分析
MCP 角色	工具执行通道 + 结果反馈

混合模式是实践中最常见的方案：

关键节点的流程用确定性工作流保证可靠性，开放性的子任务交给 Agent 自主规划。MCP 在两种模式下提供的能力是一样的——工具发现、调用和结果返回。区别在于谁来决定调用顺序：是预定义的流程定义，还是 Agent 的 LLM 推理。

十三、MCP 在工作流中的位置

MCP 在整个工作流架构中处于工具执行层，是工作流引擎（或 Agent）与外部系统交互的标准化接口：

┌─────────────────────────────────────────────┐
│              用户/触发器                        │
├─────────────────────────────────────────────┤
│           工作流编排层                          │
│  ┌──────────┬──────────┬──────────────┐     │
│  │ DAG 调度  │ 状态管理  │ 重试/补偿/审批 │     │
│  └──────────┴──────────┴──────────────┘     │
├─────────────────────────────────────────────┤
│           Agent 层（可选）                     │
│  ┌──────────┬──────────┬──────────────┐     │
│  │ Planner  │ Memory   │ ReAct 循环    │     │
│  └──────────┴──────────┴──────────────┘     │
├─────────────────────────────────────────────┤
│           MCP 层                              │
│  ┌──────────┐         ┌──────────────┐      │
│  │MCP Client│         │ MCP Client   │      │
│  └────┬─────┘         └──────┬───────┘      │
│  ┌────┴─────┐         ┌──────┴───────┐      │
│  │MCP Server│         │ MCP Server   │ ...  │
│  │(数据库)   │         │(消息通知)     │      │
│  └──────────┘         └──────────────┘      │
├─────────────────────────────────────────────┤
│           外部系统                             │
│  PostgreSQL / Slack / GitHub / 文件系统 ...   │
└─────────────────────────────────────────────┘

MCP 不跨越自己的边界：

不管理步骤之间的依赖关系 → 工作流引擎负责
不持久化执行状态 → 工作流引擎负责
不判断重试策略 → Agent 或工作流引擎负责
不处理审批流程 → 工作流引擎负责
不决定执行顺序 → 工作流引擎或 Agent Planner 负责

MCP 专注自己的职责：

暴露可用工具清单
校验调用参数
执行实际操作并返回结果
返回结构化错误信息

十四、Mermaid 综合图：MCP 在工作流上下文中的完整位置

MCP 负责连接能力，不等于完整的工作流引擎。 它是编排层与外部系统之间的标准化桥梁，提供工具发现、参数校验和调用执行，但不管控流程逻辑。

十五、设计原则

分层清晰：编排逻辑（工作流引擎）和工具执行（MCP）职责分离，不要将业务判断逻辑下沉到 MCP Server。
幂等优先：所有 MCP Tool 的设计应优先考虑幂等性，降低工作流重试的复杂度和风险。
检查点合理：长任务必须设置检查点，确保能从断点恢复。检查点粒度在「可接受的重做量」和「持久化开销」之间取平衡。
超时分层：MCP Tool 调用超时 < 工作流节点超时 < 整体工作流超时，三层超时独立配置。
错误分类明确：区分可重试错误（网络超时、5xx）和不可重试错误（参数错误、权限不足），不同错误走不同处理路径。
补偿成对设计：每个有副作用的 MCP Tool 都应该有对应的补偿 Tool，即使当前工作流不需要补偿，也为未来扩展留余地。
可观测性：工作流的每次 MCP 调用都应记录完整的 trace（调用参数、返回结果、耗时），方便调试和审计。
人在关键路径：高风险操作在工作流层面设计审批节点，不要依赖 MCP Server 自行判断。

十六、常见误区

误区	正确理解
MCP 能编排工作流	MCP 只做单步工具调用，编排逻辑在外部
Agent 的 ReAct 循环就是工作流	ReAct 是动态规划，缺乏状态持久化和补偿机制
重试就能解决所有失败	非幂等操作的重试可能造成数据不一致
长任务靠 Agent 上下文就行	LLM 上下文有限，长任务必须外部持久化
补偿是 MCP Server 的责任	补偿是工作流层面的编排逻辑，MCP 只暴露补偿工具
工作流引擎和 Agent 二选一	混合模式最常见：确定性步骤用工作流，开放步骤用 Agent
MCP Server 应该管理状态	MCP 设计为无状态，状态管理是工作流引擎的职责

十七、检查清单

工作流设计

明确区分确定性步骤和 Agent 自主步骤
定义了完整的 DAG 依赖关系
每个条件分支都有明确的判断条件和默认路径
设置了合理的循环次数上限

MCP Tool 设计

所有工具明确了幂等性特征
非幂等工具配合了幂等键机制
有副作用的工具都有对应的补偿工具
错误返回包含足够的上下文信息

可靠性设计

每个节点有超时配置
重试策略区分可重试和不可重试错误
长任务设置了检查点和断点续跑机制
补偿操作本身也具备幂等性

审批和人工介入

高风险操作有审批节点
审批超时有默认处理策略
审批请求包含足够的决策上下文

可观测性

工作流执行状态可查询
每次 MCP 调用有完整的 trace 日志
异常情况有告警通知
可以查看任意节点的历史执行记录

十八、关联笔记

MCP 核心能力：

MCP基础 — 协议的基本定义和核心概念
MCP Tool能力 — Tool 能力的设计规范和最佳实践
MCP与Agent协作 — Agent 如何通过 MCP 调用工具
MCP资源模型 — Resource 能力在工作流中提供数据输入

架构与设计：

MCP架构总览 — Host/Client/Server 三层架构
MCP Server设计 — Server 端设计模式，包括幂等性和补偿接口设计
MCP Client设计 — Client 端的调用管理和超时处理
MCP协议生命周期 — 协议初始化和通信流程

安全与可靠性：

MCP安全边界 — 工具调用的安全边界设计
MCP权限设计 — 分级授权在工作流审批中的应用
MCP错误处理 — 错误分类和重试策略

扩展阅读：

MCP能力设计指南 — 工具描述设计，影响 Agent 的工具选择准确率
MCP项目实践 — 完整项目中工作流与 MCP 的结合案例