Claude Code Dynamic Workflow 调研笔记

一句话结论

Claude Code 的 Dynamic Workflow 本质是:把原本靠对话临场推进的 agent 编排,外化成受限 runtime 执行的 JS workflow。它解决的是大任务的可控性、可恢复性、可扩展性,而不是让模型输出变成绝对确定。

1. 终点在解决什么问题

  1. 大规模任务(全仓库改造、审计、迁移)在普通 agent loop 下容易出现上下文膨胀、步骤丢失、恢复困难。
  2. 动态工作流把“计划和中间状态”放到脚本变量与运行时,而不是全部放在会话上下文里。
  3. 通过分阶段并行 + 结果聚合 + 交叉验证,目标从“单次回答”升级为“可复跑、可审计的流程产物”。

2. 工作原理(简化模型)

  1. 触发方式:任务中显式要求 workflow,或使用更高 effort 档位(如 ultracode),或调用内置 workflow 命令。
  2. Claude 先生成 workflow 脚本(JS)。
  3. runtime 在隔离执行环境按脚本调度多个 subagents 并行执行(fan-out/fan-in)。
  4. 中间结果主要存放在 workflow 变量,不持续回灌主会话上下文。
  5. 汇总阶段做一致性校验/反驳后收敛,输出最终结论。
  6. 运行支持暂停与恢复(受会话边界和平台限制约束)。

3. “确定性”到底是哪一层

流程编排可分为两层:

  • 更确定的是流程骨架:阶段、依赖、并发、重试、终止条件。
  • 仍不确定的是语义执行:子代理内容生成仍是概率过程。

因此它不是把结果变成确定机,而是把不确定性收敛到执行单元,把编排从隐式对话规则变成显式可执行规则。

4. JS 能力边界:为什么必须受限

Dynamic Workflow 不是“任意 Node.js 自动化脚本”。工程上必须是受限 runtime:

  1. 工作流脚本负责编排,不直接拥有完整系统权限。
  2. 真实的读写文件、命令执行通常由被调度 agent 在受控权限下完成。
  3. 并发、预算、权限、暂停恢复都由 runtime 统一管理。

这样做的目的不是限制能力,而是保证:

  • 安全边界(权限可控)
  • 可观测性(知道每一步发生了什么)
  • 可恢复性(中断后可继续)
  • 可治理性(预算与资源可管理)

5. 可不可以不用元语,只用自然语言模拟?

可以,但只能替代“表达层”,难替代“运行时保证”。

即:

  • 可以把 spawn/retry/join/verify 元语改写成 prompt 协议;
  • 但执行约束从 runtime 保证,退化为模型“自觉遵守”。

主要代价:

  1. 稳定性下降:同一句 prompt 在不同轮次可能产生不同执行结构。
  2. 可恢复性下降:缺少显式状态机/checkpoint。
  3. 可观测性下降:并发与失败原因难追踪。
  4. 治理成本上升:runtime 的职责重新转移回 agent 自己管理。

关键观点:复杂度没有消失,只是从系统层转移回了模型层。

6. Agent 架构的本质:路由 + 工具生态

稳定的体系不是”全模型化”,而是分层:

  • 模型层(控制面):任务理解、分解、路由决策、策略搜索。
  • 工具层(数据面):检索、计算、执行、校验、持久化。

控制面的核心职责是路由:快速判断何时用 agent 推理,何时直接调工具。这看似简单,但能决定整体效率。比如代码格式化,无论是 ESLint/Prettier 还是编辑器内置的自动保存配置,成本接近零、可靠性接近100%;如果用 agent 去做同一件事,推理成本高、速度慢、还容易出错。

工具生态的完整性和可用性是约束因素。现阶段大多数 agent 只能访问基础工具(文件操作、代码执行)。但成熟的工具生态远超这个范围:package managers、lint rules、schema validators、build systems、测试框架、配置管理等。关键是让 agent “知道”这些工具存在,以及何时调用。Cursor、Windsurf 等编辑器的成功,本质就是把 IDE 的所有工具都暴露给 LLM。

一句话:LLM 做控制面(做好路由),确定性工具做数据面(高可靠性)

7. 收敛

  1. Dynamic Workflow 的价值,不是“更聪明回答”,而是“更可治理执行”。
  2. 自然语言可以模拟元语,但不能替代 runtime 提供的约束与保证。
  3. 真正工程护城河在 runtime 和 verifier,不在 prompt 花样。

官方来源(便于复查)