一个主智能体排计划、上千个子智能体分段干活，Claude 动态工作流开放公测

从「派活」到「写程序」

ClaudeDevs 在 X 上的说法是，这是「一种新的多智能体编排方式，为最重的工作负载准备」。拆开看，关键在主智能体交出来的东西变了。

之前 Managed Agents 里的子智能体（subagents）更像主管派活：主智能体把任务切块、交给下属，再逐份读回报告。下属越多，回流到主线程的报告就越长，主智能体的上下文先被撑满。动态工作流换了个做法，主智能体生成的是一段可执行的计划，由这段程序负责在各个工人之间传递上下文、决定下一步跑什么，主线程只需要看最后的汇总。按第三方解读，这样主对话还能腾出手来继续和用户交流。

从 Claude 开发者文档看，启用方式是把智能体的多智能体类型设为 multiagent_20261001，在这个类型下动态工作流和子智能体两种机制默认都打开；只想用工作流的，要手动关掉子智能体。

半年里走完的三步

• 2026 年 4 月 8 日：Managed Agents 以公开测试形式上线，所有 Claude API 账户可通过 beta 请求头调用；当时多智能体协调、自我评估、记忆三项仍在单独申请的研究预览里。
• 2026 年 6 月前后：Claude Code 先行放出动态工作流的研究预览，可以在对话里直接要求 Claude 建一个工作流，执行中途保存进度，中断后能续跑。
• 2026 年 10 月 9 日（美国时间）：Managed Agents 侧的动态工作流转入公开测试。据第三方报道，单次运行最多可调度 1000 个智能体，这是整次运行的累计上限，不是同时在线的数量。

顺序很清楚：先在自家编程工具里验证编排逻辑，再把同一套能力搬到 API 平台卖给企业开发者。

24 小时时限比 1000 个智能体更能说明定位

「上千个智能体」容易成为标题，但更值得留意的是那条默认 24 小时的运行时限。一次普通的 API 调用以秒计，带工具调用的智能体任务以分钟计，到了 24 小时这个量级，它已经不像一次对话，更像一个提交到集群上的批处理作业：发起方不在线等结果，而是订阅事件流，隔一段时间回来看进度。

这也解释了官方挑的示例为什么是「审阅数百份文档」。这类任务天然可以切片、片与片之间依赖少，最后只需要合并结论，正好是分阶段并行最占便宜的形状。反过来，需要频繁来回确认、每一步都依赖上一步的任务，拆给一千个智能体只会多出一千份协调成本。

账单是另一面

ClaudeDevs 在公告里自己提醒了一句：工作流可能消耗大量 token，建议先从范围明确的任务试起。这句提醒不是客套。每个子智能体都要读自己那份材料、调用工具、写回结果，主智能体还要规划和汇总，token 用量是按智能体数量叠上去的。

另一个不太显眼的风险在汇总环节。并行越多，单个子智能体的小错就越容易被淹没在最终报告里，验收成本从「看一个回答」变成「抽查几百份中间产物」。动态工作流把执行规模放大了，审核规模没有跟着自动放大，这一段仍然得由使用方自己设计。