写在前面
"用 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，里面包含完整的步骤描述。
这个方案带有四个先天缺陷：
- 执行准确性问题未解决：本质上还是用 LLM 解读自然语言，确定性没有提升
- 无节点级监控：整个 Workflow 是一个黑盒，无法知道哪个环节失败
- 概念混淆：把 Workflow 编排逻辑混入了原本应该是原子能力的 Skill
- 无法跨 Agent 协作：所有逻辑在单个 Agent 的上下文里，不支持分布式执行
阶段四：原生 JS Workflow（当前最可行形式）
以 Claude Code 为代表的企业 AI 编码平台，引入了以 JS 脚本为基础的原生 Workflow 机制，每个 phase 可做代码级控制，通过 prompt 方式指定 Agent 完成任务。
这是目前最接近工程可用的形式，也引入了新的边界问题——后面详细讨论。
AI Workflow 的核心矛盾：表达力 vs 执行确定性
这四个阶段的演进，本质上是在两个极端之间寻找平衡点：
- 自然语言：表达力强，能处理歧义和上下文依赖，人类可读写——但 LLM 执行时不可预测，无法保证流程的执行确定性
- 代码：执行确定性强，可版本管理，可测试——但对非开发者有技术门槛，且刚性结构会限制 Agent 对意外情况的自适应处理
目前最合理的设计原则是：用代码控制流程结构（执行顺序、分支条件、检查点），用自然语言定义每个节点内部的任务语义。
// 代码控制流程结构（确定性）
phase('Bug分析')
const analysis = await agent('分析这个 Bug 的根因', { schema: BUG_ANALYSIS_SCHEMA })
// 检查点由代码控制，不由 LLM 决定
if (analysis.confidence < 0.8) {
await waitForHumanConfirmation('分析置信度不足，请人工确认')
}
// 下一阶段也由代码触发，不依赖 LLM 的"判断"
phase('代码修复')
const fix = await agent(`基于以下分析修复代码：${JSON.stringify(analysis)}`)
当前原生 Workflow 的评估
核心优势
执行确定性：Phase 的执行顺序、条件分支、循环逻辑由 JS 代码控制，Workflow 的"骨架"不会因每次运行而漂移。
节点级可观测性：每个 Phase 的执行状态可被追踪，实时视图清楚呈现 Workflow 跑到哪里、哪个环节失败。相比 Prompt-based Workflow 的黑盒执行，这是质的提升。
Skill 调用可行：在 JS 脚本中通过 prompt 方式显式指定 Agent 调用某个 Skill，准确性高于纯 Prompt 描述，Skill 调用与 Workflow 编排的割裂问题基本可解。
Workflow 作为可管理的代码资产：JS 脚本可被 git 管理、code review、团队共享和持续迭代，是 Workflow 从一次性用法成为可复用资产的前提。
关键局限
跨进程 / 跨容器编排不支持
原生 Workflow 的执行模型是单 session 内的主从关系：一个主 Agent 读取 Workflow 定义，在执行过程中动态 spawn subagent，所有 Agent 共享同一个 session 上下文。
但企业 Agent Platform 的设计目标通常是多进程的平级协作：开发 Agent、测试 Agent、需求管理 Agent 各自运行在独立的容器中，是独立的进程。这两种模型在根本上是不兼容的。
工具生态锁定风险
原生 JS Workflow 格式与执行引擎是特定工具的私有格式。如果后续决策切换 AI 编程工具，当前积累的 Workflow 脚本资产无法直接迁移，需要从头重新实现。在 AI 工具选型尚未稳定的阶段，这是一个需要显式权衡的战略风险。
行业现状：AI Workflow 领域尚无跨平台标准
当前主流 AI Workflow 工具的定义格式各自为政：
| 工具 | Workflow 形式 |
|---|---|
| Claude Code | JS 脚本，phase-based，session 内执行 |
| OpenAI Codex | API 层 function calling + thread |
| LangGraph | Python DAG，图结构 |
| 自建平台 | 各自定义 YAML/JSON spec |
碎片化的直接后果：不同工具之间的 Workflow 资产无法横向复用，团队一旦切换工具，Workflow 的积累需要重来。传统 BPM 领域从私有格式走向 BPMN 2.0 标准花了约十年，AI Workflow 领域正处于类似的早期混沌阶段。
建议：解耦 Workflow 意图层与执行引擎
针对行业标准未形成、工具格式碎片化的现状，建议采用意图层与执行引擎解耦的设计策略：
短期：不直接以任何工具的原生格式作为企业 Workflow 的存储格式。用厂商无关的格式（YAML / JSON spec）描述 Workflow 的"意图层"——包含：这个 Workflow 要完成什么目标、有哪些 phase、每个 phase 的输入输出和成功标准、检查点在哪里。执行引擎作为可替换的适配层，将 spec 渲染为目标平台的原生格式运行。
中期：建立企业内部的 Workflow spec 标准，为不同执行引擎提供转译层。初期成本较高，但能获得真正的可移植性，Workflow 的业务知识积累不会因工具切换而归零。
分布式多 Agent 场景下的架构选择
当 Agent Platform 的目标是让多个专栈 Agent（开发 Agent、测试 Agent、需求管理 Agent）协同工作时，Workflow 的状态由谁来持有，是架构层面的关键问题。
三种架构模式
模式一：平台作为编排者
Agent Platform（workflow engine）
├── 维护 Workflow 状态机
├── 根据当前 phase 决定调用哪个 Agent
├── 向目标 Agent 发送任务 spec（输入 + 成功标准）
├── 等待 Agent 返回结果
└── 根据结果推进到下一个 phase
最大优点是职责清晰：Agent 只需要关心"把这个任务做好"，不需要知道自己处于哪个业务流程的哪个环节。Workflow 的业务逻辑变化不会影响 Agent 的实现，Agent 的能力升级也不会影响 Workflow 的定义。
模式二：Orchestrator Agent 模式
增加一个特殊的"编排 Agent"类型，它运行在自己的容器里，负责读取 Workflow 定义、维护状态、通过平台 API 调用其他 Agent。
适合 Workflow 逻辑复杂、需要 AI 判断来决定流转路径的场景。代价是引入了额外的 Agent 类型，系统复杂度上升。
模式三：共享工作空间 + 事件驱动
各 Agent 不直接通信，通过共享的工作空间（如 Git 仓库、任务看板）来协作。Workflow 定义了每个 Agent 在什么触发条件下介入，完成后产出什么工件并触发下一个事件。
鲁棒性最强（任意一个 Agent 故障不影响其他 Agent），但 Workflow 的整体状态难以可视化，debug 困难，不适合需要强审计和监控的企业场景。
推荐：平台编排 + Agent 执行
对于企业 Agent Platform，推荐模式一作为主架构，遵守以下原则：
Agent 不持有 Workflow 知识：开发 Agent 不应该知道自己是某个端到端工作流的一部分。它只应该知道收到了什么任务输入，完成后需要输出什么。Workflow 的业务知识在平台层，Agent 的技术能力在 Agent 层，两者不要混合。
Workflow phase 与 Agent 的映射在平台层维护：每个 Workflow phase 定义"需要什么类型的 Agent"，由平台负责找到对应的 Agent 实例并分配任务。这样 Agent 的实例扩缩容不影响 Workflow 定义，Workflow 的流转逻辑变化也不需要改动 Agent。
Agent 对外暴露标准任务接口：每个 Agent 应该有一个统一的任务接收接口——接受结构化的任务 spec（目标、输入、成功标准、约束条件），返回结构化的结果（产出物、状态、置信度）。
Workflow 状态持久化在平台：平台需要维护每个 Workflow 实例的状态（当前 phase、各 phase 的输入输出、历史执行记录）。这既是监控和审计的基础，也是支持断点续跑的前提——某个 phase 失败后，可以从上一个成功检查点重新触发，而不需要整个 Workflow 重跑。
一个具体场景的架构示意
以"需求分析 → 开发 → 测试"端到端工作流为例：
触发：PM 提交需求描述
[平台 workflow engine]
Phase 1: 需求分析
→ 调用需求管理 Agent（输入：原始需求描述）
→ 输出：结构化需求 spec（验收标准、拆分子任务）
→ 人工检查点：PM 确认 spec
Phase 2: 开发
→ 调用开发 Agent（输入：需求 spec + 代码库上下文）
→ 输出：代码变更 + 单元测试 + 实现说明
→ 自动门禁：代码编译通过、单测覆盖率达标
Phase 3: 测试
→ 调用测试 Agent（输入：代码变更 + 需求 spec）
→ 输出：测试报告 + 缺陷列表
→ 分支条件：无缺陷 → 准入合并；有缺陷 → 打回 Phase 2
各 Agent 之间无直接通信，全部通过平台层传递输入输出
这个架构中，每个 Agent 各自在自己的容器里独立运行，平台负责任务分发和状态流转，Workflow 的端到端视图在平台层是完整可见的。
总结
AI Workflow 定义的四次演进，每次都在解决上一阶段暴露的新问题：
- Markdown → 脚本编排：解决执行确定性
- 脚本编排 → 大 Skill：解决 Skill 调用（但引入新问题）
- 大 Skill → 原生 JS Workflow：同时解决确定性和 Skill 调用
- 原生 JS Workflow → 解耦意图层：解决工具锁定和跨进程协作
行业标准未形成，工具格式碎片化，是当前 AI Workflow 工程的现实。在这个阶段，解耦 Workflow 意图层与执行引擎是降低工具切换成本的务实策略；对于分布式多 Agent 场景，平台作为编排者是职责最清晰的架构选择。
欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
更多实用知识和有趣产品，欢迎访问我的个人主页
