过去我们谈 AI 编程助手，通常想到的是：用户提出需求，模型修改代码，再运行测试。

但 Claude Code、Codex、ZCode 等新一代 Coding Agent 正在出现一种更值得关注的模式：Dynamic Workflow（动态工作流）。

它解决的并不是“让 AI 更聪明”，而是一个更工程化的问题：

当任务变得足够复杂时，如何让 Agent 不只是自己一步步干活，而是动态生成一个适合当前任务的执行流程？

一、先理解 Agent Loop

最基础的 Coding Agent，其实就是一个循环：

用户提出目标
    ↓
LLM 判断下一步
    ↓
调用工具
    ↓
得到结果
    ↓
LLM 再判断
    ↓
调用下一个工具
    ↓
……

例如修复一个 Bug：

读取代码
 → 搜索调用链
 → 修改代码
 → 运行测试
 → 发现失败
 → 分析错误
 → 再次修改
 → 再测试

这里最重要的特点是：下一步是什么，运行过程中才知道。

这种模式对于“小任务”非常有效。

但任务规模变大后，就会出现问题。

例如要求 Agent：

检查整个项目 500 个文件中的安全问题。

如果全部由一个主 Agent 自己调度，它不仅要分析代码，还需要记住：

哪些文件已经检查？
哪些结果需要验证？
哪些任务可以并行？
哪些任务失败了？
哪些结果需要重新检查？

此时，Agent 的上下文开始同时承担“思考”和“调度”两种工作。

二、Dynamic Workflow 是什么？

Dynamic Workflow 的核心思想是：

让 LLM 负责生成“怎么做”，让程序负责执行“怎么组织”。

于是架构从：

Main Agent
 ↓
Tool
 ↓
Main Agent
 ↓
Tool
 ↓
Main Agent

变成：

Main Agent
   ↓
生成 Workflow
   ↓
Workflow Runtime
   ├── Agent A
   ├── Agent B
   ├── Agent C
   └── Agent D
   ↓
汇总结果
   ↓
下一阶段

以 Claude Code 的 Dynamic Workflow 为例，Workflow 本身可以用 JavaScript 表达，通过 agent()、parallel()、pipeline() 等方式组织多个 Agent。

例如：

const files = await findSecurityFiles();

const results = await parallel(
  files.map(file =>
    agent(`检查 ${file} 是否存在安全问题`)
  )
);

const verified = await agent(`
验证以下安全问题：
${JSON.stringify(results)}
`);

return verified;

这里真正值得关注的不是 JavaScript，而是：

Agent 把“执行路径”从自己的上下文中抽离出来，变成了一个可以被程序管理的结构。

三、为什么偏偏使用 JavaScript？

因为很多复杂任务其实存在一种“结构性”。

比如全仓库安全审查，虽然我们事先不知道：

哪个文件有问题？
有多少漏洞？
需要怎么修复？

但是它的组织结构却非常明显：

发现候选文件
      ↓
并行分析
      ↓
汇总结果
      ↓
验证高风险问题
      ↓
输出报告

这就是一个典型的：

Fan-out
   ↓
Parallel
   ↓
Fan-in
   ↓
Verify

LLM 擅长处理“内容的不确定性”，而代码擅长表达“结构的确定性”。

于是两者形成了非常自然的分工：

LLM：
这个任务应该怎么拆？

JS：
拆完以后如何并行、循环、重试、汇总？

Sub Agent：
每个具体任务怎么解决？

LLM：
根据结果，下一阶段还需要做什么？

四、它和普通 Workflow 有什么不同？

普通 Workflow 是人工提前定义：

A → B → C → D

Dynamic Workflow 则是：

用户目标
   ↓
LLM 动态设计
   ↓
Workflow
   ↓
执行

所以它介于传统 Workflow 和完全自主 Agent 之间。

可以粗略理解为三个层级：

Static Workflow
    ↓
固定流程，人工定义

Agent Loop
    ↓
每一步都由 LLM 决定

Dynamic Workflow
    ↓
LLM 动态生成流程
程序负责执行结构

这也是它最有价值的地方。

五、什么场景最适合？

Dynamic Workflow 并不是所有任务都值得使用。

例如：

“修改这个函数，然后运行单元测试。”

直接 Agent Loop 就够了。

但下面这些任务非常适合：

1. 大规模 Code Review

发现大量目标文件
 → 并行分析
 → 汇总
 → 二次验证

2. 大型 Refactor

扫描旧 API
 → 分类
 → 批量修改
 → 测试
 → 修复失败
 → 再测试

3. Framework Migration

例如：

Django 旧版本
 → 找受影响代码
 → 分组迁移
 → 并行修改
 → 测试
 → 处理兼容性问题

4. 陌生代码库分析

Agent 可以不断探索，但探索本身也可以形成结构：

寻找入口
 → 找核心模块
 → 找依赖关系
 → 分析子系统
 → 汇总架构

这些任务具有一个共同特点：

问题本身高度不确定，但解决问题的组织方式存在重复结构。

六、对 Agent Harness 的真正启发

Dynamic Workflow 更深层的意义，其实不是“多 Agent”。

真正重要的是：

哪些控制逻辑应该交给 LLM，哪些应该交给程序。

一个成熟的 Agent Harness 往往应该把两者分开：

LLM
负责：
推理、判断、拆解、选择策略

Harness / Code
负责：
权限、状态、并发、重试、循环、超时、工具调用、终止条件

可以把它总结成一句话：

LLM 决定路径，代码保证路径能够可靠执行。

因此，Dynamic Workflow 并不是要取代 Agent Loop。

恰恰相反，它是在 Agent Loop 之上增加了一层“程序化的结构”。

当任务只是“修改一个函数”时，Agent 自己走就够了。

当任务变成“检查 1000 个文件、迁移整个项目、批量验证大量结果”时，把结构从 LLM 上下文中拿出来，交给 Workflow Runtime 管理，就会变得非常有价值。

这可能正是下一代 Coding Agent 从“会写代码的聊天机器人”走向“真正的软件工程 Agent”的一个重要演进方向。