Anthropic 发布 Claude 动态工作流：多智能体编排新范式与测试时计算优化

Anthropic 技术团队成员 CJ Avilla 和 Harrison Stall 今日在纽约 AI Engineer 大会上。

AI Engineer New York 2026 大会（链接）今早以一系列工作坊拉开帷幕，其中 Anthropic 重点探讨了如何编排其 Claude Managed Agents。备受关注的是一项于周五宣布（链接）的全新功能——动态工作流（dynamic workflows），演讲者反复将其简称为“flows”。

Flows 被定义为“一种新型的多智能体编排方式，专为最具雄心的工作负载而构建。”

CJ Avilla 和 Harrison Stall 均为 Anthropic 的技术团队成员。他们开场时回顾了过去的操作系统项目——从 Ken Thompson 构建最初的 Unix 操作系统，到 Linux 从单人开发（Linus Torvalds）演变为拥有多层可信维护者的体系。这一历史给出的启示是：为了实现 Anthropic 所设想的动态工作流那种宏大且雄心勃勃的项目，智能体也需要同等水平的组织架构。

---

由 Union.ai 赞助

构建主权 AI 工厂

顶尖的工程团队正在打造 AI 工厂，不仅掌控数据、算力和基础设施，还在自己的云上运行持久化的运行时环境。

Union.ai 为您的工作流提供持久性，使其能够适应变化、按需调整基础设施资源，并在故障后恢复，无需重新执行已完成的任务。

直接通过 AWS Marketplace 开始使用，并 免费试用 Union.ai 30 天。

欲了解更多详情，欢迎莅临 AI Engineer New York 大会 #48 展位。

---

Avilla 表示：“我认为，许多现在正在编排和管理大量智能体的同行，可能会开始感受到这种成为瓶颈和断点的压力，因为众多智能体贡献了海量的 PR（Pull Requests）。我们坐在 GitHub 前，忙着审批 PR，并确保一切按预期运行。”

从智能体名册到动态工作流

两人指出，动态工作流在 Claude Code 中最初源于“为每个任务配备一个执行框架（harness）”这一概念。但 工作流的运行时长可以超过单个智能体或固定名册的限制。 其基本理念是：由 Claude 自主选择智能体的组织方式。

“工作流本质上是多智能体编排的下一个版本，” Stall 表示，“你可以让 Claude 完全自主地编排其整个多智能体拓扑结构。”

其运作机制如下：主智能体首先制定完成任务的计划。随后，Claude 编写一个编排程序，该程序负责启动智能体、收集结果并管理信息流动。

图片 来自 Anthropic

此前，Claude Managed Agents 要求开发者配置一个协调器以及一组子智能体名册。而在动态工作流中，由 Claude 自行决定如何划分和编排工作。

Stall 说道：“在多智能体编排的多个不同阶段中，它能够完成离散且可验证的工作单元，而无需你手动管理这些环节之间的任何连接关系。”

不过，Avilla 指出，用户如果愿意，也可以引入专家型子智能体。

他说：“在智能体配置中传入预先配置好的子智能体也是可行的。”

以上所有功能均可在 Claude Console 中使用，这是开发者通过 API 访问 Claude 时所使用的界面——这也是 Claude Managed Agents 的核心意义所在。

Claude Console，Managed Agents 功能所在的位置。

演示者随后展示了一个相对简单的工作流：股票自选列表扫描器。尽管这与 Anthropic 所鼓励的那些宏大、雄心勃勃的项目相去甚远，但它确实阐明了基本模式：扫描阶段将各个股票代码分发给拥有独立上下文的 Agent，随后的审查阶段则在生成报告之前对发现的结果进行检查。

Q&A：预算限制与自我改进的局限

观众问答环节揭示了一些潜在问题。一位观众询问 Claude 如何决定一个任务需要多少个 Agent，以及一个简单的股票代码扫描是否会触发数百个子 Agent？

Stall 回答说：“答案实际上是评估（evals）和更低的默认值。”他指出，对于雄心勃勃的任务，通常需要通过明确的方式鼓励更高程度的并行化。

Agent 编排中一个长期存在的担忧是如何控制 Token 预算。有人问，主导 Agent 是否知道自己有多少可用资金？

Stall 回复说，模型在运行过程中并不知晓其预算，但开发者可以设置会话预算。他补充道，告知模型其预算可能会让 Agent 变得“有点焦虑”，这一说法引来了观众的阵阵笑声。

股票自选表示例中的扫描器界面。

一个相关的问题是，开发者如何让重复的流程随着时间推移变得更便宜、更高效？

除了要求 Claude 检查产生的成本外，Avilla 建议利用一项相对较新的功能：做梦（dreaming）。在文档中，“做梦”被定义为一项研究预览功能。“做梦”会“读取现有的记忆存储以及过去的会话记录，然后生成一个新的、经过重组的记忆存储”，其中合并了重复项，替换了“过时或相互矛盾的条目”，并“浮现出新的见解”。

Avilla 将“flow”语境下的“做梦”（dreaming）描述为能够 “结晶化并从根本上改进与这些会话相关的记忆存储。”

针对股票观察列表的例子，有人提问 该观察列表 flow 能否自我改进？ 例如，识别出其扫描模型存在不足，并调整下一次计划运行的参数？

Stall 表示这并非内置功能，但他和 Avilla 建议可以利用 爬山算法（hill-climbing）和“做梦” 来优化这一循环。

Managed Agents 的“大脑/双手”概念概览。

另一位听众问道：如何查看子代理（sub-agents）的具体行动？

Avilla 回答说，开发者始终可以通过 Claude Console 内部的图形化功能进行检视。

“你可以看出，主代理（lead agent）实际传递给子代理的是什么？ 你可以在这里查看该数据载荷（payload），从而深入理解整个图中每一次状态转换究竟发生了什么。”

另一个有趣的问题是 子代理之间能否相互通信？

Stall 表示，代理们共享一个文件系统，并利用它来交换信息，但开发者无法通过 API 直接指示一个工作流中的子代理向另一个子代理发送消息。

Flows 成本更高，但专为大型任务设计

在股票观察列表扫描器的对比中，Avilla 指出 flows 的成本比单代理方案“高得多”，但也 “在捕捉所有细节方面有效得多”。

设定预算是关键！

更大的问题是 flows 实际上能有多大的野心？ 一位听众询问动态工作流是否能支持大型科学研究项目，并提到了 OpenAI 最近宣布的关于 纳维–斯托克斯千禧年大奖难题（Navier–Stokes Millennium Prize problem） 的证明。

虽然 Stall 不愿透露 Anthropic 如何处理大型科学计算问题的具体细节，但他表示 他们的目标是让普通用户也能解决这些问题。

“Flows 本质上是一种将测试时算力投入到难题中的方法，从而更快地从模型中获得更强的能力，”他说。“我们认为，尤其是作为一项 API 服务，释放这种技术的潜力是我们实现此类发现或科学进步的第一步，使其能够被广大公众轻松使用。”