在多 Agent 系统中，任务可以分给不同的 Agent 并行完成，但任务拆分之后，谁负责协调执行、传递结果，以及决定下一步该调用哪个 Agent，仍然需要一套编排机制。
Anthropic 最近给出了新的实现方式：由 Claude 根据任务需求生成一段编排程序，让程序负责启动子 Agent、衔接不同阶段、处理返回结果，再将执行情况交回主 Agent。原先需要主 Agent 持续参与的部分协调工作，由此可以交给后台程序完成。
10 月 9 日，Anthropic 为 Claude Managed Agents 上线 Dynamic Workflows（动态工作流），目前处于 Beta 阶段。10 月 12 日，在 AI Engineer New York 2026 大会的工作坊上，Anthropic 技术人员 CJ Avilla 和 Harrison Stall 进一步介绍了这套机制。
在大会分享中，Anthropic 工程师借 Unix 和 Linux 项目从个人开发走向大规模协作的过程说明，随着越来越多 Agent 参与软件开发，任务组织和协调本身也会成为瓶颈。Dynamic Workflows 就是 Anthropic 为此尝试的新机制。
把多 Agent 的执行计划写进程序
开发者把多 Agent 用到真实项目中时，常常会发现：把任务分出去只是第一步，更费心的是把整个过程串起来。例如让主 Agent 同时派几个子 Agent 查资料并不难，麻烦的是，每份结果都要回到主对话里，再由主 Agent 逐一处理、安排后续任务。任务一多，上下文就容易被中间结果塞满。
在主 Agent 直接调用子 Agent 的模式下，主 Agent 负责派发任务、阅读返回结果，再决定如何继续。子 Agent 可以并行工作，但后续的协调仍由主 Agent 推进。
动态工作流（Dynamic Workflows）则将一部分协调逻辑写进程序。Claude 根据任务需求生成编排程序，确定任务如何拆分、分成哪些阶段，以及不同 Agent 的工作如何衔接。随后，这段程序由服务器在后台执行，负责启动 Agent、传递中间结果，并根据执行情况推进后续任务。
这里的编排程序并非一份供模型阅读的任务清单。它包含实际执行逻辑，例如并行启动多个 Agent，将上一阶段的结果作为下一阶段的输入，按照检查结果决定是否重新执行某个任务，以及在子 Agent 失败时选择继续或终止。
与传统子 Agent 委派方式相比，区别在于谁来决定后续执行步骤。此前，子 Agent 返回结果后，往往需要主 Agent 再进行一次推理，决定下一步操作。Dynamic Workflows 则允许编排程序直接根据返回数据继续执行。主 Agent 不必参与每一次任务交接，可以在后台工作流运行期间处理其他事情，并在运行结束后查看最终结果。
Anthropic 在 Claude Platform 的 Multiagent orchestration 官方文档中，对传统 Subagents 与 Dynamic Workflows 进行了专门比较：前者由主 Agent 根据子任务的返回结果，逐步决定后续操作；后者则将循环、条件分支和结果传递等逻辑交给编排程序执行，中间数据可以保存在程序变量中，无需每次都返回主 Agent 重新处理。
大会现场用股票观察列表扫描任务来进行演示：第一阶段把不同股票分配给拥有独立上下文的 Agent，后续阶段检查扫描结果，再生成报告。这一例子展示了工作流如何把分散执行、集中复核和最终汇总连接起来。
开发者也仍然能够约束参与任务的 Agent。官方支持预定义 Agent 与临时定义的 inline agent：前者使用事先设置的模型、提示词和工具；后者按当前任务创建，并沿用主 Agent 的模型及相关工具配置。开发者可以关闭临时创建能力，只允许工作流调用指定名单中的 Agent。因此，动态生成执行计划与预先配置专业 Agent 可以同时存在。例如，开发者保留一个专门负责审查的 Agent，再让 Claude 自己决定何时调用它。
动态工作流减少了开发者预先设计任务执行路径的工作，但并没有取消开发者对系统行为的约束。哪些 Agent 可以参与、能够调用哪些工具、允许产生多少费用，以及什么结果才算任务完成，仍然需要开发者通过配置、权限策略和业务校验机制确定。
1000 个 Agent 是累计上限，预算也有执行边界
如果一个简单的任务也启动大量 Agent，怎样避免过度调用？多 Agent 的成本如何控制？这是很多开发者关心的问题。
根据 Anthropic 官方文档，单次动态工作流最多可以累计启动 1000 个 Agent，但同时运行的 Agent 线程上限为 64，单次工作流默认最长运行 24 小时。也就是说，1000 个是整个运行周期内累计启动的数量，并不意味着 Claude 可以同时调度 1000 个 Agent，更不代表它已经能够稳定完成如此规模的多 Agent 任务。
这些限制明确了动态工作流的执行边界，但对于一个任务究竟应该启动多少个 Agent，Anthropic 还没有给出通用答案。在现场问答中，Stall 提到，目前主要依靠评测和较低的默认设置来控制 Agent 数量；对于更复杂的任务，通常还需要明确引导模型提高并行度。他同时表示，模型运行时并不知道自己可用的预算，开发者可以设置会话预算。
成本同样需要具体看。在股票观察列表扫描的现场演示中，Avilla 表示，动态工作流比单 Agent 方案花费更多，但也能发现更多细节。
在成本控制方面，Managed Agents 提供会话级预算机制，平台根据模型 Token、网页搜索及会话运行时间等消耗，按公开标价累计费用。达到预算上限后，系统会停止发出新的模型请求，任务随之暂停；开发者可以通过调整预算恢复执行。
不过，这并不是一个能够立即中断所有计算的硬性开关。已经发出的模型请求仍会完成，在多个 Agent 并行运行时，最终消耗可能超过预算上限。此外，由于预算按公开标价计算，其统计结果也可能与企业实际结算金额存在差异。
这也解释了为什么“主 Agent 少读一些中间结果”不能直接推出“整体更省钱”：每个参与工作的 Agent 都会产生推理消耗，额外的复核环节也需要计算资源。
工作流能自己变得更好吗？
现场问答中，还有一个值得关注的问题：如果一个动态工作流需要反复执行，它能否根据之前的运行结果不断改进自己，让任务完成得更快、成本更低？
一位听众以股票观察列表扫描为例提问：假如系统发现目前使用的扫描模型效果不好，能否在下一次定时运行时主动更换模型，或者调整原有的执行流程？
Stall 明确表示，Dynamic Workflows 目前没有内置这样的自我改进能力。不过，他和 Avilla 提到了两种可能的改进方式：Hill-climbing（爬山法）和 Anthropic 正在研究的 Dreaming 功能。
Dreaming 可以理解为一种面向 Agent 历史经验的记忆整理机制。按照 Anthropic Dreams 官方文档的定义，它会读取已有的记忆库和过去的会话记录，将重复的信息合并，替换过时或相互矛盾的内容，并从历史会话中提炼新的经验，最终生成一份重新组织的记忆库。
这一过程不会直接覆盖原始记忆库。Dreaming 会生成一份独立的新记忆库，开发者可以检查其中的内容，再决定是否将其用于后续会话。目前，该功能仍处于研究预览阶段，需要申请访问权限才能使用。
Avilla 在现场解释，Dreaming 可以帮助 Agent 将此前会话中的经验进一步提炼和固化。对于需要反复运行的工作流，这意味着开发者有机会把过去执行过程中发现的问题、积累的信息和有效的处理方式，整理成后续任务可以参考的记忆。Managed Agents 的记忆机制允许开发者将记忆库附加到新的会话中，让 Agent 在不同会话之间延续相关信息。
但整理记忆与优化工作流仍然是两回事。Dreaming 本身不会判断应该启动多少个 Agent、采用什么模型，也不会自动修改 Claude 生成的编排程序。Hill-climbing 则提供了另一种思路：通过反复评估和局部调整，尝试寻找效果更好的配置或执行策略。不过，Anthropic 此次并没有公布将这些机制整合到 Dynamic Workflows 中的完整实现。
因此，Claude 目前已经能够根据任务动态生成多 Agent 编排程序，但工作流还不能自动形成“执行、评估、修改、再次验证”的完整改进循环。要让它在重复任务中持续优化，开发者仍需要设计评测指标、记录运行结果，并决定如何将历史经验用于下一次执行。
Agent 能接力，但还不能自由“群聊”
在动态工作流中，各个子 Agent 虽然拥有独立的对话上下文，却并非彼此隔绝。根据 Anthropic 的 Workflow Runs 官方文档，它们既可以通过编排程序传递结果，也可以借助会话沙箱中的共享文件系统交换信息。
具体来说，信息传递主要有两种方式。第一种由编排程序负责：一个 Agent 完成任务并返回结果后，程序可以将相关内容作为输入交给下一个 Agent。例如，先由一个 Agent 分析代码，再把分析结果交给另一个 Agent 进行复核。第二种则通过共享文件系统完成：不同 Agent 可以将中间产物写入文件，供其他 Agent 读取和使用。
但这种协作方式与 Agent 之间直接互发消息仍有区别。Stall 在现场问答中解释，开发者目前不能通过 API，直接要求工作流中的某个子 Agent 向另一个子 Agent 发送消息。Agent 之间的任务衔接，主要依赖编排程序定义的执行逻辑和共享数据。
这也与普通 Subagents 的交互方式存在差异。传统子 Agent 的线程可以保留，主 Agent 能够继续向其发送后续消息；而动态工作流中的子 Agent 线程不能以同样方式追加消息，并会在工作流运行结束时归档。
共享文件系统还带来了另一个工程问题：上下文隔离并不等于文件访问隔离。 虽然每个 Agent 的对话历史相互独立，但它们能够访问同一会话环境中的共享文件。因此，在处理代码、配置文件或敏感数据时，开发者仍需要考虑文件覆盖、共享状态冲突，以及不同 Agent 的访问权限。
对于需要“先分析、再复核、最后汇总”的多阶段任务，动态工作流已经能够通过程序完成任务接力。但如果希望多个 Agent 持续相互讨论、随时向对方发送消息，就不能将这种编排机制直接等同于一个支持自由通信的多 Agent 网络。
程序执行完成，任务仍需验收
多个 Agent 能按流程接力，并不意味着每一步都能顺利完成。对于长任务，开发者还需要分清一件事：工作流结束了，是否就代表任务做完了？
关于长任务可靠性，官方文档有一条尤其需要注意：工作流返回 completed，仅表示程序执行结束。即使部分线程的任务失败，或者某个线程没能创建，整个运行仍可能以 completed 结束。
官方还区分了程序错误和任务结果不完整两种情况。如果工作流代码执行失败，或者某个子 Agent 的失败未被工作流处理，运行可能以 program_error 结束。但如果编排程序捕获了失败并继续运行，最终仍可能返回 completed。因此，程序能够处理错误，并不等于业务任务已经成功。
这意味着，一项批量审查任务可能已经生成汇总报告，却仍有部分材料未被成功读取。如果应用只检查最终状态，就可能把一份不完整的报告当成全部任务完成。
因此，验收不能只看状态，还要检查任务覆盖范围、失败项和关键结果。代码任务可以结合测试与构建结果；文档审查则应保留未处理材料清单，并明确哪些结论经过了复核。
模型生成的编排程序本身也可能出错，包括执行失败、超时和 Agent 数量超限。同一份工作还可能因重试而创建新的线程。如果工具会向外部系统写入数据，开发者还要处理重复调用的问题，避免一次重试重复提交同一条记录。具体业务所需的校验和恢复机制，仍然不可缺少。
Dynamic Workflows 将一部分原本由主 Agent 负责的调度工作交给了程序执行，让 Claude 能够根据任务需求临时组织多 Agent 协作。至于这种方式能否在真实项目中取得更好的效果，还需要衡量任务完成率、失败恢复能力和整体执行成本。尤其当 Agent 数量不断增加时，如何验证中间结果、管理共享状态和控制计算开销，仍然是开发者需要解决的问题。
参考链接：
https://platform.claude.com/docs/en/managed-agents/multiagent-orchestration
https://platform.claude.com/docs/en/managed-agents/workflow-runs