AI框架为何需要原生Workflow：从不确定规划到确定性交付

为什么 Claude Code、Codex、Qoder 写代码越来越溜，但一到发布流水线、CI 自动化这类多步骤工程任务就频频翻车？漏步骤、乱顺序、结果不可复现、无容错机制——你以为是模型不够强？其实是所有主流 AI 框架都缺了一块核心拼图——显式 Workflow。

本文从行业现状出发，系统梳理大模型自主规划的不确定性缺陷，分析主流厂商至今不开放 Workflow 的深层原因，阐述框架必须引入 Workflow 作为原生扩展能力的核心理由，并提出一套与现有框架完全兼容的可插拔 Workflow 技术方案。

一、行业现状：现有 AI 框架的能力边界

主流 AI 智能体客户端均对外提供统一的扩展机制，开发者无需修改核心 SDK，即可全方位自定义智能体的行为与能力：

• 智能体/子智能体提示词：定义智能体角色、行为约束与执行规范
• 技能（Skill）：封装原子化可复用的执行能力（文件处理、打包发布、文档生成等）
• MCP 协议：标准化外部资源访问能力（本地文件、Git 仓库、远程接口等）
• 工具（Tool）：拓展第三方生态功能

上述所有扩展，完美解决了智能体能做什么的问题，但始终无法解决智能体必须按什么顺序、什么规则执行的问题。

当前所有多阶段任务的执行顺序，完全依赖大模型实时推理动态生成，框架层面不存在任何声明式、固定、可审计的流水线定义。

二、核心痛点：大模型动态规划的不确定性缺陷

纯智能体自主调度的最大问题是执行结果不可控、不稳定，这对于版本发布、CI 自动化、文档部署、标准化编码等生产级工程任务是完全不可接受的。

2.1 大模型自主规划的常见不稳定问题

• 遗漏关键步骤：受上下文压缩、推理偏差影响，大模型经常跳过前置校验、产物生成、结果核验等必填流程
• 执行顺序错乱：颠倒任务依赖关系，出现”先发布后构建”“先生成文档后产出产物”等逻辑错误
• 执行逻辑不一致：相同任务每次推理策略不同，最终执行结果参差不齐，无法复现
• 容错机制缺失：多阶段流水线无统一的重试、回滚、断点续跑规则
• 无标准化校验关卡：无法强制实现执行前条件校验、执行后产物合规校验

简言之：大模型推理足够灵活，但极度不稳定；纯自主智能体无法支撑生产级的稳定任务交付。

2.2 主流厂商至今不开放 Workflow 的原因

所有 AI 客户端内部都存在隐式内置工作流（例如代码编辑流程：读取 → 分析 → 修改 → 测试 → 提交），但没有任何厂商将其开放为用户可自定义、可插拔的原生顶层扩展能力，核心原因分为商业定位与架构成本两类：

• 产品营销定位：主打”全自主 AI 规划”的智能化体验，暴露固定人工流水线会削弱产品智能感知价值
• 场景适配偏差：主流客户端主打单次、短时的临时任务（修 Bug、写代码），缺少长周期、强依赖的工程流水线场景沉淀
• 工程成本规避：显式工作流需要配套 DAG 解析、依赖校验、关卡拦截、断点续跑等复杂能力，研发成本极高
• 行业标准缺失：AI 框架生态术语碎片化，暂无统一的 Workflow 原语规范

三、为何必须引入 Workflow 作为原生核心概念

Workflow 并非用来替代智能体推理，而是对现有框架体系的关键能力补全，需要与提示词、技能、MCP、工具平级，成为框架原生扩展能力。

3.1 补齐框架缺失的「执行规范层」

现有扩展定义了智能体的能力边界与可用资源，而 Workflow 定义了不可被大模型推理篡改的强制执行规范，固化步骤顺序、前置依赖、参数传递、校验规则、重试策略、分支逻辑等核心流水线规则。

3.2 实现确定性的任务交付

针对版本迭代、批量处理、CI 流水线等标准化重复任务，Workflow 可以保证每一次执行的步骤顺序、校验规则完全一致，彻底解决大模型推理漂移、步骤遗漏的核心问题。

3.3 构建「确定性约束 + 灵活性推理」的混合范式

最优的智能体执行模式，既不是完全自主规划，也不是硬编码固化，而是工作流刚性约束 + 智能体柔性推理的混合模式：

• Workflow（刚性层）：锁定必填步骤、依赖关系、校验规则，保障任务执行一致性
• 智能体（柔性层）：负责动态参数解析、运行时异常处理、边界场景适配、实时决策优化

3.4 完善 AI 框架完整扩展体系

完整闭环的 AI 框架扩展体系，应当包含六大平级原语，形成「角色定义 → 资源访问 → 原子能力 → 生态拓展 → 执行规范 → 智能适配」的完整能力闭环：

1. 智能体/子智能体提示词（角色与行为定义）
2. MCP（外部资源访问标准）
3. 技能（原子可执行能力）
4. 工具（第三方能力拓展）
5. 工作流 Workflow（流水线执行规范）
6. 智能体实时推理（动态场景适配）

四、技术方案：可插拔 Workflow 扩展机制

我们提出一套与现有 AI 框架完全兼容的原生 Workflow 扩展方案，复用现有扩展加载逻辑，零侵入框架核心代码。

4.1 核心设计原则

• 统一扩展模式：与技能、提示词机制一致，独立 Markdown 文件定义、框架统一注册、启动注入上下文——Workflow 文件与 SKILL.md 采用完全相同的组织方式
• 声明式 Markdown 定义：以人类可读的 Markdown 文档描述流水线（而非晦涩的 YAML/JSON 配置），包含阶段表格、依赖关系图、输入输出契约
• 阶段-技能绑定：每个执行阶段明确绑定负责 Agent 与对应 Skill，Skill 是阶段的”单一事实来源”，Workflow 只编排顺序与依赖，不重复 Skill 内部细节
• 无侵入混合执行：Workflow 管控整体流程规范与质量关卡，智能体依托 Skill 完成具体执行
• 质量关卡（Gate）：阶段之间设置显式校验门禁，未通过则阻塞下游，由跨阶段的质量守护 Agent（如 Auto Iteration Sentry）持续校准
• 模板可复用：支持初始发布、增量发布、CI 自动化、文档流水线等多场景工作流模板，子工作流可引用与组合

下图展示了一个真实工程架构项目中，workflows/ 目录与 skills/ 目录平级共存的目录结构——工作流定义文件与技能定义文件采用完全一致的组织方式，框架启动时统一加载：

4.2 Workflow 核心定义内容

每一个 Workflow 文件是一份结构化 Markdown 文档，以人类可读的方式编排任务流水线，核心包含以下要素：

① 元数据头

Workflow 名称、所属层级（主工作流 / Agent 子工作流）、关联工作流链接（上一步/下一步/相关子流程）、负责 Agent、所用 Skill 清单、输入前置条件与输出产物说明。

② 阶段定义表（Stage Table）

以表格形式列出每个阶段的：阶段编号、绑定 Skill、负责 Agent、阶段目的/产出物、下游消费者。每个阶段对应一个原子化 Skill 调用——Workflow 只声明”做什么、谁来做、按什么顺序”，Skill 的 SKILL.md 才是”怎么做”的单一事实来源，避免信息重复。

③ 依赖关系 DAG 图

用 ASCII 流程图直观展示阶段间的执行顺序与并行关系，标注哪些阶段必须串行、哪些可以并行、为什么必须这个顺序。复杂场景下支持分批任务派发（Pass 1 / Pass 2），实现”上游设计任务”与”下游实现任务”的分层调度。

④ 质量关卡（Gate）

阶段之间设置显式校验门禁：前置条件检查（环境、依赖、产物是否就绪）、后置产物核验（文档/代码/安装包是否合规）、未通过则阻塞下游阶段。跨全流程的质量守护 Agent（如 Auto Iteration Sentry）持续审查各阶段输出，发现异常自动拦截或触发重试。

⑤ 产物流转契约

明确每个阶段产出什么文档/代码/产物（如 requirement.md、solution.md、安装包），以及这些产物被哪些下游阶段消费。这确保 Agent 知道”我需要什么输入、我的输出给谁用”。

⑥ 执行模式与循环机制

支持多种执行模式：一次性执行（如初始发布）、定时自驱动循环（如每月1号/15号增量发布）、智能跳过（无代码变更时自动跳过部署）、反馈闭环（线上问题→每日分流→修复→批量发布）。

⑦ 任务粒度依赖与阻塞

多 Agent 协作场景下，任务可以按特性粒度（per-feature）设置 Depends On 依赖关系——任务可提前创建但被阻塞，待前置任务完成后自动解锁，实现细粒度并行推进（如特性A代码完成后即可启动其E2E测试，无需等待整个应用开发完毕）。

4.3 混合执行运行时流程

1. 框架启动：统一加载已注册的工作流（workflows/）、技能（skills/）、提示词、MCP 资源，每个 Agent 目录下独立维护自己的子工作流
2. 任务匹配与分批派发：根据用户任务类型匹配对应工作流蓝图，按照依赖关系分批派发任务（如 Pass 1 派发设计阶段任务，Pass 2 派发实现阶段任务），注入智能体上下文
3. 基准锁定：智能体将工作流作为唯一官方执行基准，按照阶段表格依次执行绑定的 Skill，禁止跳过任何强制步骤或质量关卡
4. 柔性执行：在每个阶段内部，智能体依托大模型推理完成动态参数解析、异常处理、可选分支优化——Workflow 管”必须做哪些事、按什么顺序”，Skill 管”具体怎么做”
5. 关卡校验：框架依据质量关卡规则，逐阶段校验前置条件与后置产物；跨阶段守护 Agent 持续审查输出，异常则拦截或重试
6. 阻塞与解锁：设置了 Depends On 依赖的任务在前置任务完成前保持阻塞状态，前置完成后自动解锁，支持细粒度并行
7. 循环与闭环：一次性工作流执行完毕后结束；循环型工作流（如增量发布、日常问题分流）在完成一轮后自动创建下一轮定时任务，形成持续运转的自动化闭环

五、行业价值与厂商建议

当前主流 AI 智能体客户端普遍陷入「智能性与稳定性不可兼得」的困境。缺失显式 Workflow 能力，导致智能体仅能适配轻量临时任务，无法承载企业级标准化工程交付场景。

我们建议所有 AI 框架厂商（Claude Code、Qoder、CodeBuddy 等主流客户端）将 Workflow 正式纳入框架原生扩展能力：

• 开放独立的工作流配置目录与注册能力
• 统一工作流 DAG 定义规范与上下文注入逻辑
• 搭建「固定工作流约束 + 柔性智能体推理」的混合执行引擎
• 提供工程场景通用的官方工作流模板

六、总结

技能、MCP、提示词解决了智能体能做什么的问题，而 Workflow 解决了智能体如何稳定、标准、可复现地做事的核心问题。

纯大模型动态规划无法实现生产级稳定交付。唯有引入可插拔、声明式的 Workflow 原生扩展能力，采用工作流规范约束 + 智能体智能适配的混合模式，才能兼顾 AI 智能体的灵活性与工程落地的稳定性，真正实现可信赖、可复现、可审计的工业级 AI 任务交付。

Workflow 是现代 AI 框架架构的最后一块核心拼图，行业亟需将该能力标准化、正式化。

感悟

世间大部分事物本就天然存在，我们所做的从来不是创造，只是总结与规范化。数学定理在被人类发现之前，就早已客观存在；软件开发的设计模式亦是如此，开发者早已在日常编码中下意识运用，只是后续才被归纳、抽象成统一规范。

同理延伸到 AI 领域，在 AI Skill 被正式定义为框架概念前，我们早已通过精细化拆分 Prompt、按需加载不同能力片段，实现了技能式的调用逻辑。而 Workflow 的诞生也是一样，行业内开发者早已在落地中，隐性定义、实践着各类任务流水线。

从数学规律、软件设计模式，到 AI 技能、再到 AI 工作流，本质都是将零散的隐性实践、碎片化经验，提炼为显性、标准化、可复用的通用规范，最终让 AI 智能体的任务交付更加高效、稳定、通用。

如果你在团队中正在实践 AI 工程化工作流，或者对 AI 框架架构有自己的见解，欢迎在评论区交流讨论。