MissionFlows 对比 Workflows：自适应 Agent 执行如何取代静态 DAG

传统工作流引擎（Airflow DAG、Temporal、Prefect）都建立在一个前提上：执行路径在第一步运行之前就已经确定。任务图、控制流边、失败重试、条件分支——全部提前写死。

Agentic 系统正在打破这个前提。你不再定义路径，而是定义一个 mission，让 LLM 驱动的 Agent 在运行时决定步骤。SFTP 失败，Agent 转用 API；凭证过期，它自动刷新；主端点宕机，它选择备份。Mission 保持不变，执行路径动态涌现。

Workflow 提供的三大保证

传统工作流引擎给予开发者三项核心能力：

1. 确定性的执行图：运行前即可可视化 DAG，每个节点和边都显式可见。
2. 检查点边界：状态在任务边界保存，重试逻辑声明式定义。
3. 审计追踪：清楚知道哪些任务运行、顺序如何、返回什么。

这些保证让工作流易于调试。管道失败时，打开 UI，看到红色节点，检查日志，修复任务。失败面被 DAG 结构所限定。

DAG（有向无环图） 是传统工作流引擎的核心数据结构：节点表示任务，有向边表示任务间的依赖关系，「无环」保证不会出现循环死锁。执行前，引擎对 DAG 做拓扑排序，得到唯一的合法执行顺序（或并行批次）。正因为图在执行前就已固定，引擎才能静态地做依赖分析、并行调度和关键路径计算。文章所说的「确定性的执行图」正源于此：只要 DAG 不变，任何一次运行的节点与边集合都完全相同。这与 MissionFlow 中由 Agent 运行时选择动作、路径事后才浮现的模式形成根本对立。

幂等性与声明式重试也是工作流可靠性的隐含前提。任务边界保存状态，要求每个任务可安全重放（如通过幂等键或去重表），否则重试会产生重复副作用。max_attempts、backoff: exponential 这类声明式策略之所以有效，是因为引擎只关心「同一个任务失败了几次」，而不关心失败的原因——重试逻辑与任务语义解耦。MissionFlow 恰恰放弃了这种解耦，让 Agent 根据失败原因选择重试、换方法或升级。

MissionFlow 放弃了什么

MissionFlow 用「目标 + 护栏」替代 DAG。Agent 收到的是类似「确保文件在 17:00 前安全送达目的地并验证处理完成」这样的任务，而非一份步骤清单。

Agent 自行决定使用哪种协议（SFTP、API、S3 预签名 URL）、如何处理凭证过期（刷新 token、申请新凭证、升级给人工）、以及什么算成功（文件传输完成、校验和验证、下游系统确认）。

这种模式引入三种新的失败模式：

• 推理漂移：Agent 误解 mission，走了满足字面目标但违反隐含约束的路径。
• 无界探索：没有明确护栏时，Agent 可能尝试数十种方法，消耗 token 和时间却不收敛。
• 不可复现的失败：相同 mission 和相同输入可能产生不同执行路径，调试难度大幅上升。

没有 DAG 的可观测性

传统工作流 UI 渲染带绿红节点的图，一眼看出执行路径。MissionFlow 需要不同的可观测性模型。

推理步骤的追踪日志

不记录任务边界，而是记录推理步骤。每一步捕获四类信息：Agent 观察到了什么（如 SFTP 超时）、决定了什么（查询服务注册表）、做了什么（调用注册表 API）、学到了什么（找到替代端点）。这种日志结构替代了 DAG 可视化，通过读取 trace 重建执行路径。

传统分布式追踪（如 OpenTelemetry 的 span/trace 模型）以「调用跨度」为单位，假设每一次操作都有明确的开始、结束和父子关系。MissionFlow 的推理轨迹无法直接映射到这种模型：一次 Agent 推理可能产出零个或多个工具调用，也可能先推理再观察再推理，形成嵌套的「思考—行动—观察」循环。实践中通常采用 ReAct 风格的步骤序列作为一等记录单元，每个步骤显式标注观察、决策、动作、结论四要素。这样即使最终路径不可复现，事后也能逐帧重建「Agent 当时为什么这么走」，把不可复现的执行变成可复盘的推理链，这是调试 MissionFlow 的核心手段。

推理中途的状态检查点

工作流在任务边界做检查点。MissionFlow 需要在推理中途做检查点，因为 Agent 可能决定暂停、请求人工输入或等待外部条件。检查点包含 mission 定义、推理轨迹、当前上下文（凭证、端点、部分结果）以及 Agent 下一步计划。Agent 崩溃或超时后，可从最近检查点恢复。

护栏作为可执行约束

护栏是限制搜索空间的约束，由编排层而非 LLM 执行：

• 允许的工具：Agent 可调用 sftp_transfer、api_upload、s3_presigned_url，但不能用 ssh_exec。
• 凭证范围：可刷新 token，但不能申请新 API key。
• 时间预算：30 分钟内必须完成，否则升级。
• 审批门禁：使用未列入白名单的备用端点需人工批准。

Agent 提出动作，编排器在执行前用护栏检查。

护栏与提示词约束的本质区别在于执行位置。写在系统提示里的规则（如「不要使用 ssh_exec」）只是软约束，LLM 可能因上下文漂移、注入攻击或推理失误而违反，且违反后无人拦截。真正的护栏位于 Agent 与工具之间的编排层，是一个确定性的策略执行点（PEP）：Agent 只能「提出」工具调用意图，编排器在执行前用规则逐一校验，不通过则拒绝并回写拒绝原因，让 Agent 重新规划。因此护栏必须用可判定、无歧义的形式表达——工具白名单、凭证 scope、时间预算、审批门禁——而不是自然语言。这也是文章强调「由编排层而非 LLM 执行」的原因：约束的可信度不能依赖于被约束者自身。

没有预定义重试逻辑的失败恢复

工作流中重试逻辑是声明式的：max_attempts: 3、backoff: exponential。MissionFlow 中，Agent 自行判断是重试、换方法还是升级。

Agent 驱动的重试

Agent 观察失败、推理原因、决定下一步：

• 临时性失败（网络超时）→ 重试同一动作。
• 永久性失败（凭证无效）→ 换一种方法。
• 模糊失败（500 错误）→ 查日志或查询监控系统。

编排器记录推理并执行护栏，但不规定恢复策略。

升级边界

当 Agent 无法推进时升级给人工：尝试三种方法均失败、需要白名单外工具、截止时间临近且信心不足。升级边界把潜在无限搜索变成有人参与的有限搜索。

版本化 Mission 定义

工作流以代码版本化——提交 YAML 到 Git。MissionFlow 以 prompt 和护栏版本化，包括目标声明（自然语言）、护栏配置、上下文 schema。修改 prompt 可改变执行路径而不改动代码。

提示漂移

DAG 是确定性的，相同输入产生相同路径。MissionFlow 不是。模型更新、temperature 设置、token 预算变化都可能改变行为。缓解手段包括：固定 LLM 版本和参数、记录每一步的完整 prompt 和响应、运行验证已知场景执行路径的回归测试。但 MissionFlow 的回归测试更难，因为你测试的是结果而非路径。

缓解提示漂移还需要区分结果等价与路径等价两种测试目标。传统工作流的回归测试断言执行路径（节点序列、重试次数），因为路径确定，任何偏离都意味着 bug。MissionFlow 中同一 mission 有多条合法路径，断言路径会大量误报，因此只能断言结果不变量：文件是否在截止时间前送达、校验和是否通过、是否触发了预期升级。为兼顾可观测性，可额外记录路径级别的「软断言」，如「不得调用白名单外工具」「总步数不超过 N」，作为护栏而非正确性判据。此外，固定 LLM 版本只是必要条件，模型供应商侧的静默更新、工具返回格式的细微变化同样会导致漂移，因此 prompt、模型版本、参数和工具 schema 应作为一组不可变配置一起版本化并记录进每条 trace。

架构：编排器、Agent、工具层

MissionFlow 系统分为三层：

层级	职责
编排器	接收 mission、执行护栏、记录推理步骤、管理检查点、处理升级
Agent	接收 mission 和上下文、推理下一步、提出工具调用、解释结果
工具层	执行动作（SFTP 传输、API 调用、数据库查询）、返回结果

编排器是有状态的，维护 mission 状态、推理轨迹和检查点历史，但不进行推理。Agent 是无状态的，接收 mission、当前上下文和推理轨迹，返回下一步动作。工具层同样无状态，每个工具是接受参数并返回结果的函数。

案例：文件传输 Mission

一个文件传输 mission 定义三个部分：目标（17:00 前安全传输并验证处理）、护栏（允许工具、凭证范围 refresh_only、30 分钟预算、未列出端点需审批）、上下文（文件路径、目的地、截止时间）。

编排循环的逻辑很简单：Agent 推理下一步 → 检查是否违反护栏 → 执行工具 → 记录 trace → 更新上下文 → 检查点。编排器事先不知道 Agent 会用 SFTP 还是 API，它只执行护栏并记录 trace。

何时使用 MissionFlow

用 MissionFlow	用 Workflow
执行路径依赖无法预测的运行时上下文	执行路径已知且稳定
失败恢复需要推理原因而不仅是重试	重试逻辑简单且声明式
Mission 涉及多个可用性和能力不同的系统	系统和协议固定
需要适应性多于可复现性	需要可复现性和确定性调试

MissionFlow 不是工作流的替代品，而是针对不同类问题的不同抽象。管道稳定、失败模式明确时，工作流更简单也更好调试。

技术判断

执行路径无法预先确定时用 MissionFlow——多备用方案的集成场景、根因未知的故障响应、跨异构系统的数据管道。

执行路径稳定时避免 MissionFlow——可观测性和调试复杂度更高，你会失去让工作流易于推理的确定性图。

准备好投入可观测性基础设施——推理追踪日志、检查点管理、护栏执行、升级边界，MissionFlow 的工具生态远不如工作流成熟，需要自建插桩。

从护栏开始——没有明确约束，Agent 会无界探索。上线前先定义允许工具、凭证范围、时间预算和审批门禁。

来源：From Workflows to MissionFlows (Dev.to)