1000个Agent上限背后，Claude把调度写成了程序

让主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推进。

动态工作流则将一部分协调逻辑写进程序。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数量不断增加时，如何验证中间结果、管理共享状态和控制计算开销，仍然是开发者需要解决的问题。