把多 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 CodeWorkflow 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 轮扫描在运行记录里是不同节点每个节点只依赖之前已经产生的结果不会反过来依赖未来。循环在代码里是环落到一次执行里就被展开成时间线。letdryRounds0constconfirmed[]while(dryRounds2){constcandidatesawaitparallel(files.map(fileagent(scanPrompt(file))))constfreshdedupe(candidates).filter(notSeenBefore)if(fresh.length0){dryRounds1continue}dryRounds0confirmed.push(...awaitparallel(fresh.map(itemagent(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 / DifyDynamic Workflows流程作者人提前搭建之后反复运行Claude 针对当次任务写脚本也可以保存表达载体可视化节点图、声明式配置JavaScript workflow script拓扑形态多数是静态图循环靠专门节点可以写循环、条件和动态扇出节点能力HTTP、转换、单次 LLM 调用、固定连接器完整 subagent可读写代码和调用工具运行语境自动化平台、业务集成、webhookClaude Code 会话、代码仓库、开发工具链主要价值把稳定业务流程产品化把复杂工程任务临场拆解并执行一句话说清楚n8n 这类工具是人把流程图画好让系统跑Dynamic Workflows 是 Claude 把当次任务写成代码让 runtime 跑。AI 的介入主要发生在“写编排脚本”和“节点内执行任务”这两个位置不是 runtime 每一步都在自由发挥。两边也在靠近。Coze、Dify 会加入 code node 和更强的 agent nodeDynamic Workflows 也能把脚本存进项目目录变成可复用模板。但它们的初始重心不同。一个更像业务自动化平台一个更像代码环境里的临场编排器。图探索期协作和生产期跑批适合不同的多 Agent 形态Agent Teams探索期和生产期不要混用Agent Teams 和 Dynamic Workflows 最容易被混在一起因为它们都在讲多 agent。我觉得区分方法很简单需要讨论时用 Agent Teams需要跑批时用 Dynamic Workflows。Agent Teams 的优势是探索。你可以让几个成员从不同角度看同一个问题中途插话、改 prompt、追问某个成员。它适合需求还不稳定、方向还没定、需要人参与判断的场景。Dynamic Workflows 的优势是生产化。它更关心任务图、失败重试、结构化输出、可保存脚本、恢复状态和大规模并发。它不适合你每五分钟插一句等一下换个方向。问题Agent TeamsDynamic 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 WorkflowsLangGraph主要用户开发者、研究员、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 looptoken 消耗会明显高于普通对话。前面提到的历史会话分析一次 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 工程自动化的加速器用得粗它只是一个更贵、更快的混乱制造机。推荐阅读RAG 负责召回LLM Wiki 负责沉淀团队知识系统为什么不能只做检索Agent Harness 架构真相Prompt Cache 如何决定 Skill、MCP 与 SubAgent 设计Claude Code 如何压缩上下文Microcompact、Prompt Cache 与 cache_edits 工程拆解平台智能化到了分水岭为什么配置代码化才是 AI Coding 的下一代接口为什么 AI Coding 难进生产环境深入了解 Everything-Claude-Code