AI Workflow 定义的四次演进：从 Markdown 到 JS 脚本，再到分布式多 Agent

写在前面

“用 AI 自动化研发工作流”——这个目标几乎每家技术公司都在说。

但很少有人认真讨论：Workflow 本身应该怎么定义？用什么技术形式表达它？

这看起来是个次要问题，实际上是个核心问题。Workflow 的定义方式，决定了它能否可靠执行、能否被监控、能否在 Agent 迭代后保持稳定，以及能否在团队内共享和复用。

这篇文章是对过去一段时间在企业 AI 平台实践中，Workflow 定义方式演进的完整复盘。

四个技术阶段的演进

阶段一：Markdown 提示词描述工作流

最初的做法：用自然语言和 Markdown 格式描述工作流，放置在指定目录，让 Agent 按描述执行。

优点：门槛低、灵活、人类可读，能快速表达复杂的业务意图。

根本局限：LLM 在执行 Prompt 描述时是在\”解读\”而非\”执行\”——同一份描述每次运行都是一次新的解释过程，无法保证步骤严格按顺序和条件执行。

这不是 Prompt 质量的问题，而是这种表达形式的理论上限。你可以写出完美的 Markdown，LLM 仍然会在某些运行时偏离预期的步骤顺序，跳过某些检查，或在分支条件上产生不一致的判断。

阶段二：脚本编排（平台内置方案）

一些企业 AI 平台提供了内置的流程编排脚本语言，用于替代自然语言描述，获得确定性的控制流。

进展：解决了执行确定性的问题——流程的执行顺序由代码控制，而不是 LLM 的解读。

遭遇的硬限制：编排层与 Skill 层割裂。如果脚本只能调用固定的工具集（比如只能调用 bash 命令），而无法调用 Skill 层定义的 AI 能力，那么 Workflow 的执行就被严重限制了。

这揭示了一个关键需求：Workflow 的编排层需要能够无缝调用 AI Skill。

阶段三：Workflow 定义为大 Skill（过渡方案）

为了绕过编排层与 Skill 层的割裂，一种常见的过渡方案是：把整个工作流打包为一个大型 Skill，里面包含完整的步骤描述。

这个方案带有四个先天缺陷：

阶段四：原生 JS Workflow（当前最可行形式）

以 Claude Code 为代表的企业 AI 编码平台，引入了以 JS 脚本为基础的原生 Workflow 机制，每个 phase 可做代码级控制，通过 prompt 方式指定 Agent 完成任务。

这是目前最接近工程可用的形式，也引入了新的边界问题——后面详细讨论。

AI Workflow 的核心矛盾：表达力 vs 执行确定性

这四个阶段的演进，本质上是在两个极端之间寻找平衡点：

• 自然语言：表达力强，能处理歧义和上下文依赖，人类可读写——但 LLM 执行时不可预测，无法保证流程的执行确定性
• 代码