这两天多智能体编排这条线上有个变化值得记一笔：Anthropic 把「动态工作流」放到了 Claude 托管智能体平台上，而且是公开测试，不再需要单独申请研究预览资格。它最反常识的地方不在规模，而在于——编排程序不再由开发者写，而是由主智能体自己写。
一、事实梳理：谁在什么时候发了什么
先把可核实的事实摆齐。
- 时间线：10 月 9 日进入公开测试，由 Anthropic 通过开发者账号对外宣布，外媒同日跟进报道；10 月中旬的 AI Engineer New York 大会上，官方工程师进一步做了解读，并用了 Unix 与 Linux 从个人项目长成分层维护者社区的类比，来说明智能体也需要类似的层级结构。
- 功能定位：官方把「工作流」定义为「一段由智能体编写的程序，用来运行多个智能体并合并它们返回的结果」。一次执行叫一次工作流运行，由服务器在后台异步执行，主智能体不必等它跑完。
- 规模数字：单次工作流运行在其整个生命周期内最多可启动 1000 个智能体，并发线程上限 64。
- 开启方式：把智能体配置里的多智能体类型设为指定版本值即可，默认同时打开工作流与传统子智能体两项能力，也可以各自单独开关。开发者也可以在 Claude Code 里跑一条命令走引导流程。
- 目前状态：仍是 beta，调用需要带对应测试版请求头，暂不支持零数据留存，也没有公布定价、失败恢复和并行执行时的资源隔离细节。
需要说明的是，官方内部测试的成绩属于厂商口径，尚无独立复核。
二、它和过去的多 Agent 编排差在哪
这才是这篇的重点。过去做多智能体，常见的两种形态是：开发者把编排逻辑写死成一张有向无环图，或者用平台预置的几个子智能体串起来。OpenClaw 多 Agent 怎么配 里讲的那种「人来配子代理、人来定任务怎么分」，以及 DeerFlow 2.0 这类 SuperAgent 指挥子代理的框架，都属于这一类——结构在人手里。
动态工作流把这两件事都交给模型：主智能体不仅派活，它还负责写那段调度程序，程序里指定要开多少个智能体、分成哪几个阶段、结果怎么合并。开发者能影响的只有系统提示词——告诉它在什么情况下适合开工作流，剩下的结构由模型现场决定。而且触发权只在智能体自己手上，外部发一个事件是触发不了的。
换个说法：以前是「人画生产线，机器按线跑」，现在是「人说明目标，机器自己搭线」。这个变化和 AI Agent 任务规划的三种范式 是同一条演进线索，只是这次从单智能体的规划，上升到了多智能体的组织。
三、怎么开起来、跑起来是什么样
从官方文档披露的形态看，跑起来是这样一幅画面：
- 由阶段组成。一次运行可以分成若干阶段。官方文档给的例子是：第一阶段三个智能体并行读合同，第二阶段由另一个智能体基于前面的结果做核对汇总。程序还可以在阶段内循环某一步，比如反复改草稿直到通过审查或达到设定轮数。
- 每个智能体有自己的会话线程。都在独立线程里工作，可以列出、读取、流式查看，运行时挂在同一个运行 ID 下面。
- 共享同一份文件沙箱。同一批运行的智能体共用沙箱里的文件，这是它们能协作的基础，也是后面要说风险的地方。
- 两种智能体来源。一种是工作流里临时定义的内联智能体，沿用主智能体的模型；一种是开发者预先建好、列进清单的预定义智能体，清单最多二十个。想让部分子智能体用别的模型，就得走预定义这条路。
- 进度靠事件流看。阶段事件表示里程碑，线程级事件表示哪个子智能体在干活、什么时候完成，不需要轮询。这套事件驱动的可观测方式，和 AI Agent 流式输出与进度事件 讲的是同一层基础设施。
四、官方那个测试是怎么做的
官方给出的对比测试场景很具体，值得完整转述：团队在一个 11.6 万行的代码库里人为埋了 70 个漏洞，然后比较单智能体与动态工作流的表现。结果是单智能体每次运行能找出 14 到 27 个漏洞，而动态工作流稳定找到 66 个。
为什么能提升，官方给的解释也符合直觉：把代码拆开，分给上下文互不干扰的多个智能体分别扫，再加一道交叉核验环节，绕开了单个智能体上下文容量有限这个天花板。这不是「模型变聪明了」，而是「分工让覆盖面上去了」。
不过要同时记住两件事。第一，这是厂商自己的基准，场景是天然可拆分的代码扫描，效果能否迁移到别的任务类型，官方自己也说需要用户拿真实负载验证。第二，理论上限和实际跑法是两回事——并发线程 64 意味着 1000 这个数字是「整个生命周期累计」，而不是真的同时有一千个在跑。
五、影响分析：三方各有什么变化
对开发者来说，省掉的是编排代码，增加的是理解成本。不用再手写那张 DAG，但要学会用提示词去约束模型什么时候该开工作流、什么时候不该开。这一步如果写不清楚，触发会变得随机，账单也会变得随机。
对平台竞争来说，「编排」正式成了平台原生能力。这类能力一旦被产品化，比拼的就不再是「谁家模型分数高」，而是谁家的运行时更稳、事件更全、成本更可控。托管化的 Agent 运行服务 和 开源的控制平面 会把这条线越掰越开。
对用它的团队来说，最大的变化在成本口径。并行不是免费的：以前算的是「一次任务多少 token」，现在要算「一次工作流运行多少 token，其中多少花在重复核验上」。判断值不值得，得先把并行收益折算成一个可比的单位，这套算法在 AI Agent 成本怎么算 里已经讲过；如果还要评估并发上限和排队时长，Agent 压测与容量评估 那套方法可以直接搬过来用。
还有一个容易被忽略的影响：并行会把错误也放大。一千个智能体里有一个权限配错，影响面是一个的千倍。子智能体共享沙箱这件事，本身就需要 沙箱隔离 和 权限管理 两条线一起收，否则规模越大越危险。
六、三盆冷水
- 第一盆：厂商口径没有独立复核。66 比 14 到 27 这个对比很有冲击力，但它来自官方内部测试，任务类型单一。真要上生产，得用自己的样本重跑一遍，别拿别人的基准当自己的验收标准。
- 第二盆：token 账单存在真实争议。一位 OpenAI 的高级工程师近期公开把智能体集群称为对 token 的巨大浪费，Anthropic 自己也承认这些工作流可能消耗大量 token，并建议从小规模开始。业内比较一致的建议是：优先用在文档审阅、代码扫描这类天然可拆分的并行任务上；步骤强依赖、必须串行的活，用单个智能体反而更便宜。
- 第三盆：关键细节还是空的。定价没公布，失败恢复怎么处理没说，多个智能体并行跑代码时的资源隔离也没给方案。它仍然是 beta，接口带版本号本身就说明还会变。企业级场景里，零数据留存这类合规能力缺失也可能直接卡住采购。
七、老达点评
这件事我的判断是：它的分量不在「1000」这个数字上，而在「谁来写编排」这个问题换了个答案。
过去两年多智能体一直有个尴尬——编排逻辑写得越复杂，能适应的任务就越窄，因为人预先画好的流程图，碰到没想过的任务就废了。让模型自己写编排程序，等于承认「任务结构应该由理解任务的一方来定」。这个方向我觉得是对的，而且它顺带解决了一个老问题：以前搭多智能体，工作量的大头在工程而不是在业务，现在这部分被平台吃掉了，门槛确实降下来了。
但也别急着上。真要试，我的建议是三步：第一步挑一个天然可拆分的任务，比如一批文档的交叉审阅，用十几份文件先跑通；第二步把这次运行的 token 账单和人工做同一件的成本摆在一张表上比，不看绝对数看比值；第三步再决定要不要放量，并且同时把子智能体的工具权限收一遍。
还有一点值得提前想：一旦编排由模型现场生成，流程就不再是一份可以审计的流程图了。以前能拿一张图说清「谁在什么时候做什么」，现在得靠运行记录和阶段事件复盘。可观测性和审计这条线，接下来会比现在更吃重。
八、总结
把这件事压缩成几句：Anthropic 把多智能体编排做成了平台原生能力，主智能体自己写调度程序、按阶段并行开子智能体、单次运行上限 1000 个、并发 64；官方给出的代码扫描测试从十几个漏洞提升到 66 个；开启只需改一个配置字段，但触发权只在智能体自己手上；限制同样明显——仍是 beta、定价与失败恢复未公布、token 开销争议很大。
对读者来说，最有参考价值的一条经验不是「能不能开一千个」，而是要先把任务能不能拆这件事想清楚。能拆的任务，多智能体是放大器；拆不开的任务，多智能体只是把账单放大。
