在多 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 针对这个问题给出的尝试。
1 把多 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 官方文档（https://platform.claude.com/docs/en/managed-agents/multiagent-orchestration）中对传统 Subagents 与 Dynamic Workflows 做了专门对比：前者由主 Agent 根据子任务返回结果逐步决策；后者则把循环、条件分支和结果传递都交给编排程序，中间数据可以保存在程序变量里，不需要每次都回到主 Agent 重新处理。
大会现场用股票观察列表扫描任务展示这一机制：第一阶段把不同股票分配给拥有独立上下文的 Agent，后续阶段检查扫描结果，再生成报告。这个例子直观展示了工作流如何把分散执行、集中复核和最终汇总串联起来。
开发者仍然可以约束参与任务的 Agent。官方支持预定义 Agent 与临时定义的 inline agent 两种方式：前者使用预先配置好的模型、提示词和工具；后者按照当前任务临时创建，并沿用主 Agent 的模型和相关工具配置。开发者也可以关闭临时创建能力，只允许工作流调用指定名单中的 Agent。因此，动态生成执行计划和预先配置专业 Agent 可以同时存在。例如，开发者保留一个专门负责审查的 Agent，再让 Claude 自己决定何时调用它。
动态工作流降低了开发者预先设计任务执行路径的工作量，但并没有取消对系统行为的约束。哪些 Agent 可以参与、能调用哪些工具、允许产生多少费用、什么结果才算任务完成，这些仍然需要开发者通过配置、权限策略和业务校验机制来确定。
2 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 都会产生推理消耗，额外的复核环节同样需要计算资源。
3 工作流能自己变得更好吗？
现场问答中，还有一个值得关注的问题：如果某个动态工作流需要反复执行，它能否根据之前的运行结果不断改进自己，让任务完成得更快、成本更低？
一位听众以股票观察列表扫描为例提问：假如系统发现目前使用的扫描模型效果不好，能不能在下一次定时运行时主动更换模型，或者调整原有的执行流程？
Stall 明确表示，Dynamic Workflows 目前没有内置这样的自我改进能力。不过，他和 Avilla 提到了两种可能的改进方式：Hill-climbing（爬山法）和 Anthropic 正在研究的 Dreaming 功能。
Dreaming 可以理解为一种面向 Agent 历史经验的记忆整理机制。按照 Anthropic Dreams 官方文档（https://platform.claude.com/docs/en/managed-agents/dreams）的定义，它会读取已有的记忆库和过去的会话记录，合并重复信息，替换过时或相互矛盾的内容，并从历史会话中提炼新经验，最终生成一份重新组织过的记忆库。
这一过程不会直接覆盖原始记忆库。Dreaming 会生成一份独立的新记忆库，开发者可以检查其中的内容，再决定是否将其用于后续会话。目前该功能仍处于研究预览阶段，需要申请访问权限才能使用。
Avilla 在现场解释，Dreaming 可以帮助 Agent 将此前会话中的经验进一步提炼固化。对于需要反复运行的工作流，开发者有机会把过去执行中发现的问题、积累的信息和有效的处理方式，整理成后续任务可以参考的记忆。Managed Agents 的记忆机制（https://platform.claude.com/docs/en/managed-agents/memory）允许开发者将记忆库附加到新的会话中，让 Agent 在不同会话之间延续相关信息。
但整理记忆与优化工作流仍然是两回事。Dreaming 本身不会判断应该启动多少个 Agent、采用什么模型，也不会自动修改 Claude 生成的编排程序。Hill-climbing 则提供了另一种思路：通过反复评估和局部调整，尝试寻找效果更好的配置或执行策略。不过，Anthropic 此次并没有公布将这些机制整合到 Dynamic Workflows 中的完整实现。
因此，Claude 目前已经能够根据任务动态生成多 Agent 编排程序，但工作流还不能自动形成“执行、评估、修改、再次验证”的完整改进循环。要让它持续优化，开发者仍需要设计评测指标、记录运行结果，并决定如何把历史经验用于下一次执行。
4 Agent 能接力，但还不能自由“群聊”
在动态工作流中，各个子 Agent 虽然拥有独立的对话上下文，却并非彼此隔绝。根据 Anthropic 的 Workflow Runs 官方文档（https://platform.claude.com/docs/en/managed-agents/workflow-runs），它们既可以通过编排程序传递结果，也可以借助会话沙箱中的共享文件系统交换信息。
具体来说，信息传递主要有两种方式。第一种由编排程序负责：一个 Agent 完成任务并返回结果后，程序可以把相关内容作为输入交给下一个 Agent。例如先由一个 Agent 分析代码，再把分析结果交给另一个 Agent 复核。第二种通过共享文件系统完成：不同 Agent 可以把中间产物写入文件，供其他 Agent 读取使用。
但这种协作方式与 Agent 之间直接互发消息仍有本质区别。Stall 在问答中解释，开发者目前不能通过 API 直接要求工作流中的某个子 Agent 向另一个子 Agent 发送消息。Agent 之间的任务衔接，主要依赖编排程序定义的执行逻辑和共享数据。
这也与普通 Subagents 的交互方式不同。传统子 Agent 的线程可以保留，主 Agent 能够继续向其发送后续消息；而动态工作流中的子 Agent 线程不能以同样方式追加消息，并会在工作流运行结束时归档。
共享文件系统还带来另一个工程问题：上下文隔离并不等于文件访问隔离。 虽然每个 Agent 的对话历史相互独立，但它们能够访问同一会话环境中的共享文件。因此，在处理代码、配置文件或敏感数据时，开发者仍需考虑文件覆盖、共享状态冲突，以及不同 Agent 的访问权限。
对于需要“先分析、再复核、最后汇总”的多阶段任务，动态工作流已经能够通过程序完成任务接力。但如果希望多个 Agent 持续相互讨论、随时向对方发送消息，就不能把这种编排机制直接等同于一个支持自由通信的多 Agent 网络。
5 程序执行完成，任务仍需验收
多个 Agent 能按流程接力，并不意味着每一步都能顺利完成。对于长任务，开发者还要分清一件事：工作流结束了，是否就代表任务做完了？
关于长任务可靠性，官方文档有一条尤其需要注意：工作流返回 completed，仅表示程序执行结束。即使部分线程的任务失败，或者某个线程没能创建，整个运行仍可能以 completed 结束。
官方还区分了程序错误和任务结果不完整两种情况。如果工作流代码执行失败，或者某个子 Agent 的失败未被工作流处理，运行可能以 program_error 结束。但如果编排程序捕获了失败并继续运行，最终仍可能返回 completed。所以程序能够处理错误，并不等于业务任务已经成功。
这意味着，一项批量审查任务可能已经生成汇总报告，却仍有部分材料未被成功读取。如果应用只检查最终状态，就可能把一份不完整的报告当成全部任务完成。
因此，验收不能只看状态，还要检查任务覆盖范围、失败项和关键结果。代码任务可以结合测试与构建结果；文档审查则应保留未处理材料清单，并明确哪些结论经过了复核。
模型生成的编排程序本身也可能出错，包括执行失败、超时和 Agent 数量超限。同一份工作还可能因重试而创建新线程。如果工具会向外部系统写入数据，开发者还要处理重复调用问题，避免一次重试重复提交同一条记录。具体业务所需的校验和恢复机制，仍然不可缺少。
Dynamic Workflows 将一部分原本由主 Agent 负责的调度工作交给了程序执行，让 Claude 能够根据任务需求临时组织多 Agent 协作。至于这种方式能否在真实项目中取得更好的效果，还需要衡量任务完成率、失败恢复能力和整体执行成本。尤其当 Agent 数量不断增加时，如何验证中间结果、管理共享状态和控制计算开销，仍然是开发者需要解决的问题。
参考链接：
更多关于多 Agent 编排与 Claude 平台的实战经验，欢迎到云栈社区与开发者一起交流。
发表于 2 小时前
|
查看: 7|
回复: 0
