Claude Code 动态工作流能让 AI 当场编写调度脚本，并行调用上百个智能体处理任务。这不再是简单对话，而是一套为当前任务量身打造的执行框架，正在颠覆我们对 AI 编程的认知。
一个 Agent 搞不定的活，就让一百个 Agent 来干！
搞过大型代码迁移的人都懂那种绝望。五百个文件要改，每个文件改法还不一样，手动改到天荒地老，让 AI 一个对话窗口从头干到尾也经常翻车。
不是 AI 不够聪明，是它干着干着就开始偷懒了。安全审计清单上列了五十项，它查完三十五项就拍拍屁股说搞定了。你让它自己检查自己的成果，它怎么看怎么顺眼，硬是找不出毛病。任务拖得太久，原始目标在上下文压缩中一点点流失，到最后连当初为什么要做这事都模糊了。
但 Anthropic 在 2026 年 5 月底给 Claude Code 加了一个新功能，直接把游戏规则改了。
这个叫 Dynamic Workflows 的东西，能让 Claude 当场写一份 JavaScript 调度脚本，在后台并行调度几十到上百个智能体同时干活。你的主对话窗口不用被占用，脚本跑完直接给你一份最终报告。
这不是把任务拆开给你看，而是把整个编排计划写成一段可复用的代码交给运行时执行。
默认 Harness 的三种死法
先搞清楚一件事。Claude Code 本来就有默认的执行框架，官方管它叫 harness。这个默认 harness 是为常规编码任务设计的，在一个上下文窗口里既要规划又要执行。
对大多数日常编码来说够用了。但 Anthropic 自己承认，一旦任务变成长期运行、大规模并行、高度结构化或者带有对抗性，默认 harness 就会出三种毛病。
第一种叫 Agentic laziness，翻译成人话就是智能体偷懒。复杂任务做到一半就宣布完工。安全审计五十项只查了三十五项，剩下的十五项？不存在的。
第二种叫 Self-preferential bias，自我偏好。同一个智能体在同一段上下文里既干活又检查自己的成果，它能给自己挑出毛病才有鬼。让它验证自己的输出，它十有八九给自己开绿灯。
第三种叫 Goal drift，目标漂移。对话轮次一多，上下文每次压缩都会丢掉一些信息。边缘情况的约束条件，比如“别碰那个模块”“别改那个配置”，到后半程就慢慢消失了。
这三个毛病本质上是一回事：一个智能体在一个上下文窗口里扛了太多事。
把计划从脑子里掏出来，塞进代码里
Dynamic Workflows 的解法非常朴素。别让一个智能体在一个上下文窗口里既当爹又当妈，把任务拆成多个独立智能体，每个智能体拿自己的上下文窗口和自己的目标。
关键区别在于谁拿着计划。
用子智能体或者智能体团队的时候，Claude 自己是编排者。它每一轮决定下一步生成什么、分配给谁，每一步的结果都塞进上下文窗口里。
动态工作流不一样。计划从 Claude 的脑子里搬出来了，搬进了一段 JavaScript 脚本里。脚本掌握着循环、分支和中间结果，Claude 的上下文窗口只负责最终答案。
这意味着什么？意味着主会话不用记住每个分支的细节了。循环跑多少轮、分支怎么走、什么时候合并结果，全是代码在管。真正需要模型判断的地方才交给模型。
代码执行不消耗主上下文窗口。这就是动态工作流能支撑比普通子智能体并行更大规模编排的根本原因。
官方给的对比表很清楚。子智能体每轮只能委派几个任务，智能体团队只能协调少数几个长期运行的同伴，动态工作流单次运行可以调度几十到上百个智能体。被中断之后，子智能体和智能体团队都得重来，动态工作流能在同一个会话里恢复。
六种核心编排模式
Thariq 总结了六种 Claude 在构建工作流时常用的编排模式。
第一种是分类路由：先让一个分类智能体判断任务类型，然后根据类型路由到不同的智能体或行为。或者最后用分类器决定输出格式。适用于需要先判断再动手的场景。
第二种是扇出合成：把一个任务拆成很多小步骤，每个步骤派一个独立智能体去跑，然后把所有结果合成一份。特别适合步骤数量大、或者每个步骤需要自己干净的上下文窗口以免互相干扰的情况。合成步骤是一个屏障，等所有扇出的智能体都跑完，再把它们的结构化输出合并成一个结果。
第三种是对抗验证：每派一个干活智能体，就另外派一个智能体专门来挑它的毛病。按照规则或标准去验证输出。这跟让同一个智能体自己检查自己完全是两码事。
第四种是生成过滤：针对一个主题生成一堆想法，然后用规则或验证去过滤，去重，只返回质量最高、经过检验的想法。
第五种是锦标赛：不让智能体分工合作，让它们互相竞争。派 N 个智能体用不同方法去解决同一个任务，然后用评审智能体两两对比结果，直到决出冠军。
第六种是循环直到完成：任务工作量不明确的时候，循环派智能体直到满足停止条件为止。没有新发现了，或者日志里没有新错误了，就停下来。
这些模式不是孤立的。Claude 在构建工作流的时候会把它们组合起来用。
Bun 重写：十一天的极限测试
最能说明动态工作流威力的是一个真实案例。
Jarred Sumner 用动态工作流把 Bun 从 Zig 重写成了 Rust。七十五万行 Rust 代码。从第一次提交到合并，十一天。现有测试套件通过了 99.8%。
怎么做到的？
一个工作流负责把 Zig 代码库里每个结构体的字段映射到正确的 Rust 生命周期。下一个工作流负责把每个 .zig 文件转成行为一致的 .rs 文件，几百个智能体并行工作，每个文件配两个评审智能体。然后修复循环驱动构建和测试套件，直到全部跑通。代码合并之后，还有一个通宵运行的工作流专门处理不必要的数据拷贝，给每个优化点单独开了一个 PR。
这不是人类能手动完成的速度。这也是动态工作流最极致的展示。
什么时候该用，什么时候千万别碰
动态工作流最适合的任务类型很明确。
代码库范围的漏洞扫描。五百个文件的迁移。需要多来源交叉验证的研究问题。值得从多个独立角度起草的困难计划。间歇性失败的概率性 bug 复现。上千条记录的分拣和排序。
但动态工作流不是万能的。
它会消耗明显更多的 token。官方自己都说了，建议先从范围可控的任务开始，感受一下 token 消耗量。
大多数常规编码任务根本不需要五个评审智能体围着转。改一个函数、修一个 bug、加一个 feature，默认 harness 就够了。只有当你觉得“这事一个对话窗口搞不定”的时候，才值得让 Claude 去写一个工作流。
开 ultracode 模式要谨慎。在 effort 菜单里打开 ultracode 之后，当前会话里每一个实质性任务 Claude 都会自动规划工作流。token 消耗会显著增加，单任务耗时更长。做完复杂任务记得把 effort 降回 high，这个设置只在当前会话生效。
一个还没答案的问题
动态工作流把计划从上下文搬进了代码，这个思路解决了大问题。但有一个细节我一直在想。
官方说工作流被中断之后可以恢复。恢复之后从断点继续。但恢复的到底是什么状态？脚本变量里的中间结果能完整保存吗？子智能体的上下文窗口能重建吗？如果某个子智能体跑到一半被杀了，恢复之后是重新跑还是接着跑？
官方文档里提了一嘴“可恢复”，但没有展开说技术细节。这个问题不搞清楚，长任务运行到一半出点岔子，到底是整个重来还是真的能续上，差别巨大。
Bun 重写那种级别的任务跑了十一天。十一天里不可能不出任何状况。他们到底是怎么处理中断和恢复的？没看到公开的技术细节。
这事还没完。