从“对话”到“编排”：Claude Code 动态工作流背后的软件工程范式转移

最近一周，我的推特信息流几乎被 Claude Code 的“动态工作流”（Dynamic Workflows）刷屏了。

如果你只看了那些“震惊！AI 自动重写 75 万行代码”的标题党，你可能会觉得这又是一个类似 Devin 的营销噱头。但作为一名长期关注 AI Agent 演进的开发者，在深度拆解了它的底层逻辑并阅读了内置脚本源码后，我想说：这可能是自 ReAct 模式提出以来，AI Agent 领域最重要的一次工程范式转移。

它标志着 AI 从“基于对话的反复横跳”，正式进入了“基于代码的确定性编排”时代。

一、为什么传统的 Agent 模式走到了死胡同？

在动态工作流出现之前，我们使用 AI Agent 的逻辑通常是：Prompt -> Loop -> Reflection。

无论是 AutoGPT 还是各种复杂的 LangGraph 工作流，本质上都在做一件事：让 LLM 在一个长对话上下文中，不断地通过 ReAct（推理-行动）循环来尝试解决问题。这种模式有三个难以逾越的“毒点”：

1.上下文膨胀与幻觉：所有的思考过程、中间结果、工具调用记录都堆在 Context Window 里。随着任务变复杂，Token 成本呈指数级增长，更致命的是，长上下文会显著拉低模型的推理精度。

2.不可控的随机性：即便你写了 500 行的 System Prompt，Agent 在第 50 步操作时依然可能因为前面的某个小干扰而“跑偏”。

3.难以调试与复用：Agent 的执行路径像个黑盒。你很难精准地告诉它：“在第 3 步和第 5 步之间，我要你并发执行 10 个搜索，并且必须通过三方校验。”

Claude Code 的动态工作流（Dynamic Workflow）给出的解法极其暴力且优雅：既然 LLM 擅长写代码，那就让它在处理复杂任务前，先给自己写一段 JavaScript 编排脚本，然后由一个受控的运行时（Runtime）去执行。

二、硬核拆解：动态工作流的“编排 API”

当我们输入 ultracode 或者运行 /deep-research 时，Claude 并不是在直接和你聊天，而是在后台生成了一段 .js 脚本。

通过对 deep-research 源码的逆向（你可以通过 /workflows 视图中的 View raw script 看到），我发现了几个核心的编排原语，这才是干货所在：

API 原语	功能描述	软件工程视角
phase(title)	定义任务阶段	类似于 CI/CD Pipeline 的 Stage，提供进度可视化和状态隔离。
agent(prompt, options)	产生一个原子化的子代理	将复杂任务拆解为无状态的微服务调用，支持 schema 强制结构化输出。
pipeline(input, ...steps)	流式处理管道	实现并发处理与数据流转，类似于函数式编程中的 pipe。
parallel(tasks)	并发执行	真正发挥 LLM 吞吐能力的利器，可以同时调起几十个模型实例。
log(message)	确定性日志	记录中间决策，而非漫长的对话。