先看证据
把机制串起来
多智能体编排不是简单地“多开几个 Claude”，而是要决定任务怎么拆、哪些部分并行、结果如何传递与核验。动态工作流把这些决定交给模型生成的编排程序；每个子 agent 可有独立上下文，减少长对话带来的跑题与自我确认，但并行也会增加 token 和协调成本。
Claude 先为任务制定计划，再生成 JavaScript 工作流程序，由程序启动子 agent、收集输出并控制信息流；拓扑因此可以随任务变化，而不是固定一套 coordinator 加固定 roster。工作流可将任务分发给各自拥有独立上下文的 agent，再综合结果；也可采用对抗式验证、方案竞赛，或循环执行直到达到停止条件。阶段化、可核验的工作单元能降低单个 agent 同时规划与执行时跑题或过早结束的风险，但“可核验”不等于结果必然正确，仍需明确检查标准。并行可能缩短
['适合可拆分、结果能独立检查的长任务', '先小范围试跑；并行会增加 token 消耗', '明确验收标准，汇总后再做测试或人工审查', '限制工具与文件权限；必要时用隔离 worktree']
编排权从开发者手里移到了哪里
Anthropic 推出的 Dynamic Workflows，是 Claude Managed Agents 中面向复杂任务的一种多智能体编排方式。Anthropic 技术人员 CJ Avilla 和 Harrison Stall 在 AI Engineer New York 相关讨论中介绍了这套思路：由 Claude 规划任务、生成编排程序，再启动和协调子 agent，而不是要求开发者事先写好固定的协调者与子 agent 名单。
这项变化值得技术负责人细读，因为它改变的不是单纯的并发数量，而是谁来决定任务如何拆分、结果怎样流动。过去，开发者要先设计 agent 拓扑；现在，模型获得了生成这套拓扑的权限。人工搭建胶水逻辑的负担可能下降，但“怎么拆才算合理”也更直接地变成了运行时决策。
从固定名单到生成一段工作流
在 Anthropic 对机制的说明中，Claude 会先形成计划，再生成 JavaScript workflow 程序，用它拆分子任务、并行启动 agent、收集结果并安排信息流。常见组织方式包括先分发再综合、用对抗式验证检查结论、让多个方案竞争，或循环执行直到达到停止条件。开发者仍可预先提供专门的子 agent，也可以选择 agent 使用的模型，以及是否在独立 worktree 中运行。
活动中展示的股票观察名单扫描器，把这个机制落在一个容易理解的例子上：扫描阶段将不同股票分派给拥有独立上下文的 agent，之后再进入复核阶段，检查发现并生成报告。这里的关键不只是并行读取，而是把工作分成离散、可验证的阶段。若结果需要复核，系统就有机会在汇总之前暴露分歧，而不是把多个 agent 的输出简单拼接起来。
Unix 是设计线索，不是功能说明
Anthropic 把这类 agent 系统与 Unix 的演进相提并论：大型工程需要的不只是一个聪明执行者，还需要清晰的组织方式、可复用的工具和可信的维护层级。这个类比有助于理解为什么多智能体不能只靠“再加几个 agent”扩容。不过，Unix 的启发不等于 Dynamic Workflows 就是 Unix，也不意味着它与另一套工具共享同一实现。
公开材料里有一处容易被混为一谈的背景：AI Engineer 页面记录的 Claude Agent SDK 工作坊，重点是 Bash、文件系统等 Unix 基础设施；Dynamic Workflows 则是 Anthropic 另行说明的多智能体编排功能。两者都涉及 agent 如何借助结构化环境完成工作，但不是同一个产品或同一场材料。把它们合并成“工作坊发布了 Dynamic Workflows”，会模糊功能边界，也会把设计类比误当成技术细节。
大项目案例不是普遍性能承诺
Anthropic 用 Bun 从 Zig 移植到 Rust 的案例展示了这类工作流可以尝试处理很大的工程任务：博文报告约 75 万行 Rust、从首个 commit 到合并用了 11 天，既有测试套件通过率为 99.8%。但这组数字来自 Anthropic 对案例的描述，不是独立评测；材料还注明代码当时尚未投入生产。它说明一次特定尝试的规模和进度，不能单独证明相对人工或单 agent 更快、更便宜或更可靠。
并行度本身也不是越大越好。演示问答中，Anthropic 的回答强调评测和较低的默认值，并指出特别宏大的任务通常需要明确鼓励更高并行度。另一条容易误读的数字是文档所说的单个 session 最多 25 个子线程：这是 subagents 文档中的限制，不能直接当成 Dynamic Workflows 的并行 agent 上限。评估容量时，技术团队需要确认数字对应的产品和运行机制，而不是把相近术语下的限制互相套用。
把省下的编排工作换成运行时治理
Dynamic Workflows 缓解了一个实际瓶颈：当许多 agent 同时交付结果，负责人可能被大量 PR 和人工验收拖住。但自动拆分并没有消除验收，而是把验收压力前移到任务定义和评测设计上。团队需要为每个阶段设定可检查的产物与停止条件，并判断哪些结论必须经过独立复核。否则，模型生成的工作流只是更快地制造出难以审查的结果。
成本和恢复也要纳入设计。Anthropic 提醒，并行 agent 会增加 token 消耗；开发者可以设置 session budget，但模型运行时并不知道自己还有多少预算。材料还称中断后可恢复会话并继续，这有助于避免从头重跑已完成工作，却不等于任务正确性或总成本得到保证。对技术负责人，一个稳妥的起点是先选范围有限、结果能被测试或检查的任务，设置保守默认值，再用评测决定是否扩大并行度。