Dynamic Workflows 深度解析：Claude Code 为什么把多 Agent 编排写进可执行代码

把多 Agent 编排迁出聊天上下文，用可执行脚本承载复杂工程任务。

原文链接 ：AI小老六

导语

Claude Code 的 Dynamic Workflows 容易被误读成"多开几个 subagent"。这个理解太浅了。

真正的变化不在并行数量，而在控制平面。过去，复杂任务的拆分、等待、复核、返工，基本都压在主会话上下文里。模型一边看工具返回，一边改计划，一边记住哪些分支已经做过。任务小的时候，这种 ReAct 式循环很灵活；任务一大，主上下文很快变成一张堆满中间结果的临时白板，后面每一步都要先从这堆痕迹里找状态。

Dynamic Workflows 做的事，是把这张临时白板改造成一段可以执行的 workflow script。Claude 先写出调度策略，再交给 runtime 跑。脚本负责阶段、循环、并发、结果聚合和恢复状态；具体读文件、跑命令、做判断的活，仍然由一个个 subagent 完成。

这也是它最值得注意的地方：编排逻辑不再只是模型当场想出来的一串口头计划，而是一段可以执行、可以审查、可以保存、可以复跑的代码。你可以先看它打算怎么拆任务，再决定是否运行；跑完以后，还能把有效流程留下来，下次继续用。最后回到主会话的，也不再是几十份原始结果，而是一份被整理过的报告或补丁。

这篇文章只讨论一个问题：为什么"plan in code" 会成为 AI Coding 里的新原语，它适合什么任务，又不能解决什么问题。

控制平面：单 Agent 到顶的地方

单个 coding agent 的强项是临场判断。它可以边读仓库边调整路径，发现线索后立刻换方向。这也是它的软肋。所有观察、失败、修正、工具结果都进入同一条上下文轨迹，越往后越难分清哪些信息还有效。

Subagent 缓解了一部分问题。你可以把"查调用方""扫安全风险""读一批文件"这类局部任务派出去，让主会话少看一些细节。但 subagent 的结果通常还要回到主会话，由主 Claude 继续判断下一步。它隔离了执行过程，没有彻底搬走编排过程。

Agent Teams 再往前走一步。多个 Claude Code 成员可以形成一个小团队，适合讨论、互相试探、让用户随时插话。问题是，它仍然偏交互式协作。团队里谁接下来做什么，很多时候还要靠 lead、用户和成员之间的对话推进。

Dynamic Workflows 切的是另一刀：把"谁来调度"从会话层转到脚本层。

图：从单会话 Agent 到 Dynamic Workflows 的控制平面迁移

这个变化听起来像实现细节，其实是架构边界。只要编排还在聊天上下文里，复杂任务就会被上下文长度、人工协调和中间状态污染拖住。编排进入代码后，任务才有机会变成一个可以审查、可以保存、可以复跑的执行单元。

Plan in Code：Workflow Runtime 到底接管了什么

Dynamic Workflows 不是让一个更大的 Claude 接管全部工作。它拆成了三层。

第一层是 Claude。它根据用户目标生成 workflow script，设定阶段、并发、循环、schema 和终止条件。结束后，它再读最终结果，向用户解释发生了什么。

第二层是 runtime。它像一个不带业务理解的调度器，按脚本执行阶段，跟踪每个 agent 的返回值，处理并发、重试和同会话恢复。它不自己理解代码，不直接修 bug，也不直接跑 shell。

第三层是 subagent。真正读仓库、查资料、运行测试、写补丁的还是它们。每个 subagent 继承当前会话的工具权限，在自己的局部上下文里完成任务。

层级	负责什么	不负责什么
Claude	写 workflow script，解释最终结果	逐条阅读所有中间结果
Workflow runtime	执行脚本、管理阶段、保存中间状态	自己判断业务含义
Subagents	读文件、跑命令、调用工具、输出结构化结果	决定整个流程怎么走
Script variables	保存阶段产物、验证状态、去重结果	替代最终的人类审查

这也是它和普通 subagent 最大的区别。普通模式里，十个 subagent 的返回会像十份报告一样塞回主会话。Workflow 模式里，十份结果先进脚本变量，脚本可以去重、过滤、校验，只把必要结论交回来。

我更愿意把它理解成"上下文卸载"，而不是"并行增强"。并行只是表层收益，真正值钱的是中间状态不再挤占主上下文。

命令式脚本：为什么它不等于静态 DAG

一提到 workflow，很多人会想到 Airflow、Argo、GitHub Actions：先画一张有向无环图，把依赖关系定死，再按图执行。这个类比有用，但容易误导。Dynamic Workflows 不是先让人画图，再让 runtime 照着走。

它的入口是一段命令式 JavaScript 。脚本里可以写 while，可以写 if，也可以根据上一阶段返回了多少结果，临时决定下一阶段要开几个 agent。也就是说，流程的形状不是预先画死的。它会在运行时长出来。

这里要分清两件事：程序结构和执行轨迹。

程序结构可以有环。比如"一直扫描，直到连续两轮没有新发现"，这在代码里就是一个 while。静态 DAG 很难自然表达这种逻辑，因为 DAG 在定义上不能有回边。

但某一次真实运行的轨迹，仍然可以摊平成 DAG。第 1 轮扫描、第 2 轮扫描、第 3 轮扫描，在运行记录里是不同节点；每个节点只依赖之前已经产生的结果，不会反过来依赖未来。循环在代码里是环，落到一次执行里就被展开成时间线。

javascript 复制代码

let dryRounds = 0
const confirmed = []

while (dryRounds < 2) {
  const candidates = await parallel(files.map(file => agent(scanPrompt(file))))
  const fresh = dedupe(candidates).filter(notSeenBefore)

  if (fresh.length === 0) {
    dryRounds += 1
    continue
  }

  dryRounds = 0
  confirmed.push(...await parallel(fresh.map(item => agent(verifyPrompt(item)))))
}

这就是它和传统 DAG 编排器的差异：传统工具的拓扑通常在运行前就定好了；Dynamic Workflows 的拓扑由脚本执行过程生成。代码层面更像一个会长出图的程序，运行层面又保留了可追踪、可审计的 DAG 轨迹。

Parallel 和 Pipeline：并行不是一股脑全扔出去

写 workflow 最容易犯的错，是把所有并发都叫 parallel。

parallel 更像批处理屏障。你把一批任务同时发出去，等它们全部回来，再进入下一阶段。它适合全局去重、统一排序、交叉裁决这类场景。比如安全扫描先让 20 个 agent 各扫一片，等全部结果回来，再让一个 verifier 统一判断哪些是真问题。

pipeline 更像流水线。每个 item 可以独立向下游流动，不必等其他 item。比如文件迁移时，一个文件完成分析后就可以进入改写和测试，不必等全仓库其他文件都分析完。否则，一个慢文件会拖住所有快文件。

调度形态	适合任务	错用后果
Parallel	全局去重、统一裁决、多路交叉验证	慢任务拖住下一阶段
Pipeline	文件级迁移、批量转换、每项独立验证	如果需要全局视图，会漏掉冲突
Loop	反复修复、直到连续无新增、测试失败回滚	终止条件不清会空转
Fan-out / Fan-in	大范围搜索后集中汇总	汇总 schema 不稳定会污染结论

Dynamic Workflows 的工程价值，往往就藏在这些调度细节里。它把并发、屏障、循环和验证写进脚本，让这些过程可查、可改、可保存，而不是只把 agent 数量拉高。

图：可视化自动化平台与代码化 workflow runtime 的控制方式差异

和 n8n、Coze、Dify：相似处和真正的分界线

把 Dynamic Workflows 和 n8n、Coze、Dify 放在一起比较，不算错。它们都属于"把 LLM 和工具放进预定义流程"的范畴。真正跑流程时，控制流沿着既定路径执行，不会让某个 LLM 每一步自由选边。

但如果说区别只是"流程由 AI 自动生成"，又不够。

维度	n8n / Coze / Dify	Dynamic Workflows
流程作者	人提前搭建，之后反复运行	Claude 针对当次任务写脚本，也可以保存
表达载体	可视化节点图、声明式配置	JavaScript workflow script
拓扑形态	多数是静态图，循环靠专门节点	可以写循环、条件和动态扇出
节点能力	HTTP、转换、单次 LLM 调用、固定连接器	完整 subagent，可读写代码和调用工具
运行语境	自动化平台、业务集成、webhook	Claude Code 会话、代码仓库、开发工具链
主要价值	把稳定业务流程产品化	把复杂工程任务临场拆解并执行

一句话说清楚：n8n 这类工具是人把流程图画好，让系统跑；Dynamic Workflows 是 Claude 把当次任务写成代码，让 runtime 跑。AI 的介入主要发生在"写编排脚本"和"节点内执行任务"这两个位置，不是 runtime 每一步都在自由发挥。

两边也在靠近。Coze、Dify 会加入 code node 和更强的 agent node；Dynamic Workflows 也能把脚本存进项目目录，变成可复用模板。但它们的初始重心不同。一个更像业务自动化平台，一个更像代码环境里的临场编排器。

图：探索期协作和生产期跑批适合不同的多 Agent 形态

Agent Teams：探索期和生产期不要混用

Agent Teams 和 Dynamic Workflows 最容易被混在一起，因为它们都在讲多 agent。

我觉得区分方法很简单：需要讨论时用 Agent Teams，需要跑批时用 Dynamic Workflows。

Agent Teams 的优势是探索。你可以让几个成员从不同角度看同一个问题，中途插话、改 prompt、追问某个成员。它适合需求还不稳定、方向还没定、需要人参与判断的场景。

Dynamic Workflows 的优势是生产化。它更关心任务图、失败重试、结构化输出、可保存脚本、恢复状态和大规模并发。它不适合你每五分钟插一句"等一下，换个方向"。

问题	Agent Teams	Dynamic Workflows
谁持有计划	lead、成员和用户共同推进	workflow script
中间结果在哪	多个会话和协作流里	script variables 和 runtime 状态
是否适合插话	适合	不适合高频插话
典型规模	几个成员的小团队	数十到上百个 subagent
最适合	方案探索、技术评审、多视角讨论	批量迁移、审计、研究、长链路自动化

这两者不是替代关系，更像研发流程的前后两段。先用 Agent Teams 把思路跑清楚，等流程稳定后，再沉淀成 workflow。前者帮你找路，后者帮你按路跑完。

图：快速原型空间和生产级 agent runtime 的边界不同

LangGraph：被冲击的是原型空间，不是生产运行时

Dynamic Workflows 出来后，很多人会问 LangGraph 会不会被打掉。答案没那么戏剧化。

它确实会冲击 LangGraph 的一部分使用场景。过去不少开发者用 LangGraph，并非业务真的需要持久状态、节点级人工介入和长期运行，只是想做一个多步 agent，又没有现成的执行器。现在，如果任务主要发生在代码仓库、研究报告、审计、迁移这些开发者工作流里，让 Claude 直接写 workflow 往往更快。

但 LangGraph 的核心价值不在"帮个人少写几段编排代码"。它更像生产级 agent runtime：长期运行、durable execution、human-in-the-loop、memory、可观测性、多模型后端、自建部署。这些能力不是 Claude Code 里的 Dynamic Workflows 现阶段要完整替代的东西。

维度	Dynamic Workflows	LangGraph
主要用户	开发者、研究员、AI power user	应用工程团队、平台团队
编排方式	Claude 动态生成脚本	开发者显式定义 graph、state、edge
状态恢复	围绕 Claude Code 任务执行	durable execution 是核心能力
人工介入	更像计划确认和阶段审批	可在节点级暂停、修改状态、继续执行
生态绑定	强绑定 Claude Code	更接近模型和运行时无关

所以更准确的判断是：Dynamic Workflows 会压缩 LangGraph 在"开发者自用、多步自动化、快速原型"里的空间；LangGraph 仍会留在"生产级 agent 系统建设"里。一个像强执行终端，一个像长期运行的工程底座。

如果未来 Dynamic Workflows 补齐更开放的 runtime、跨模型编排、节点级 HITL 和完整观测，那才会更深地碰到 LangGraph 的护城河。现在还不到那一步。

什么时候该用：四个判断条件

Workflow 不是越大越该用。更实用的判断是看任务是否同时满足四个条件。

第一，可拆。任务能拆成很多相对独立的单元，比如文件、服务、历史会话、API、模块。

第二，可验。结果能被编译、测试、规则、引用、日志或人工抽检验证。没有验证信号，workflow 只是把不确定性并行放大。

第三，可收敛。任务不能只靠一次判断结束，需要通过发现、复核、修正逐步逼近答案。

第四，值得复用。这个流程以后还会再跑，比如发版前检查、全仓库安全扫描、定期架构偏差审计。

适合的任务包括：

全仓库 bug 扫描、安全审计、性能热点排查。
框架替换、API 弃用迁移、跨语言移植。
需要多路独立研究和交叉验证的报告。
release readiness 检查、长尾清理、自动开 PR 的维护工作。
历史会话、日志、文档库这类大批量信息提炼。

不适合的任务也要说清楚：

一两个文件的小改动。
需要你频繁中途拍板的探索任务。
支付、安全策略、权限模型这类高风险代码的直接自动修改。
没有测试、没有规则、没有可观察反馈的大型开放式判断。

我会把选型压成一句土办法：跑腿用 subagent，讨论用 Agent Teams，流水线和循环用 Workflow。

图：规模化 workflow 需要同时管理成本、验证与权限边界

已知限制：上限提高了，治理问题也来了

Dynamic Workflows 抬高了 Claude Code 能处理的任务上限，但它不是免费魔法。它把问题从"模型能不能开始干活"变成"后台跑起来以后怎么管住"。

几个硬约束需要提前记住：

限制	工程含义
需要 Claude Code v2.1.154 或更高	低版本排查功能不可用没有意义
并发最多 16 个 subagent	大任务不是无限并发，低 CPU 机器可能更少
单次运行最多 1000 个 agent	防止循环失控，也限制超大任务形态
运行中不接受普通人工输入	需要签核就拆成多个 workflow
脚本本身不能直接读写文件或跑 shell	所有实际操作通过 subagent 完成
跨会话不可恢复	退出 Claude Code 后不要指望原地续跑

成本也要单独算。几十个 subagent 并行，外加 verifier、adversary、fix loop，token 消耗会明显高于普通对话。前面提到的历史会话分析，一次 11 个 agent 就能吃掉几十万 token。任务越大，预算越应该写进流程设计，而不是跑完再惊讶。

更麻烦的是透明度。后台跑一个长 workflow 时，人不再逐步盯着每一次判断。你必须在 prompt 和脚本里写清楚范围、退出条件、验证方式和失败处理。否则它可能跑很久，产出一堆看似认真但没多少价值的中间物。

失败模式	常见表现	应对方式
Token 失控	任务越跑越贵，超出预期	先小范围试跑，分阶段放大
错误放大	早期误判进入后续流程	强制加入 verifier / adversary
任务跑飞	后台忙很久，结果不聚焦	明确成功条件和退出条件
治理真空	团队都会跑，但没人解释风险	模板版本化，统一权限和预算策略

这也是我对 Dynamic Workflows 最谨慎的地方。它确实把上限抬高了，但同时把任务设计能力放大了。问题拆得好，它能把并行、验证和复用优势打出来；问题边界含糊，它只会更快地制造混乱。

落地顺序：先学会治理，再扩大半径

如果一个团队刚开始试 Dynamic Workflows，我不建议第一步就上全仓库迁移。

更稳的顺序是三步。

先跑低风险任务，比如 /deep-research、小范围代码巡检、文档和实现偏差检查。目标先别定成省多少时间，先摸清它怎么消费 token、怎么失败、怎么恢复。

再把有效流程沉淀成模板。比如安全审计模板、release 前检查模板、历史会话分析模板。模板里写清楚输入、范围、并发规模、验证节点、输出 schema 和人工确认点。

最后再把大迁移、大审计、跨模块重构交给 workflow。到这一步，团队已经知道怎么设边界、怎么控制预算、怎么审查结果，而不是把一个不确定的大任务直接扔进后台。

图：从低风险试跑到仓库级任务的落地顺序

结语

Dynamic Workflows 的核心价值，不在于让 Claude 多叫几个帮手。更大的变化是，复杂任务的过程控制从聊天上下文里被拿出来，变成了一段可执行的代码。

这件事会改变 AI Coding 的任务边界。以前适合模型的，是局部、短链路、强交互的工作；现在一些长链路、可拆分、可验证的工程任务开始有机会被模型稳定接住。真正更常见的用法会是安全扫描、发版检查、批量迁移、研究报告和仓库级巡检。

但它不会让复杂任务自动变简单。Workflow 把编排写成代码，也把错误、成本和治理问题写进了代码。以后使用它的门槛，不只是会不会写 prompt，而是能不能设计一个边界清楚、验证充分、成本可控的执行流程。

我的判断是：Dynamic Workflows 不是 Agent Teams 的替代品，也不是 LangGraph 的终结者。它更像 Claude Code 里的新运行层，专门处理那些单个 agent 装不下、手动 subagent 又协调不过来的任务。用得好，它是大规模 AI 工程自动化的加速器；用得粗，它只是一个更贵、更快的混乱制造机。