Anthropic动态工作流：Claude多智能体编排新范式

在AI Engineer New York 2026大会上，Anthropic的技术团队成员CJ Avilla和Harrison Stall分享了一个刚刚发布的新功能——动态工作流（dynamic workflows），或者按照演讲者反复使用的简称"flows"。这个功能被定义为"一种全新的多智能体编排方式，专为最宏大的工作负载而构建"。

从Unix到Agent：组织架构的启示

Avilla和Stall的开场颇具深意。他们从Ken Thompson构建原始Unix操作系统讲起，一路延伸到Linux从Linus Torvalds一人发展为多层可信维护者的演进历程。这个类比指向一个核心洞察：智能体要完成Anthropic设想的宏大项目，需要与操作系统项目同等水平的组织架构。

Avilla道出了许多开发者的真实困境："我们中很多人在编排和管理大量智能体时，可能开始感受到成为瓶颈甚至断裂点的压力——大量智能体贡献了成吨的PR，而我们坐在GitHub里试图审批这些PR并确保一切按预期运行。"

这个问题并非Anthropic独有。随着AI编程工具普及，开发者从写代码转向审查AI生成的代码，角色变了，瓶颈感却更强了。动态工作流正是对这一痛点的直接回应。

Unix维护者模型指的是Linux内核等大型开源项目采用的分层信任结构：Linus Torvalds作为最高维护者，下辖若干子系统维护者（如网络、文件系统），再往下是各驱动和模块的维护者，最底层是贡献补丁的开发者。每个补丁需经逐级审查才能合入主干。这一模型之所以能支撑数万贡献者协作数十年，关键在于职责分层和信任传递：高层维护者不必审查每一行代码，只需信任下级维护者已把关。演讲者用此类比多智能体编排——主导智能体不必亲自处理每个子任务，只需编排、信任并汇总下级智能体的产出。这也解释了为何“让Claude自己决定拓扑结构”是自然演进：开发者扮演的角色从“写死协调逻辑”退化为“定义目标与验证边界”，与Linus从写代码退化为合并维护者类似。

动态工作流如何运作

据两位演讲者介绍，动态工作流的概念起源于Claude Code中的"a harness for every task"理念，但flows能运行的时间跨度远超单个智能体或一组智能体。核心思路是：让Claude自己选择智能体的组织方式。

Stall解释说："Flows本质上是多智能体编排的下一代版本，你可以让Claude完全编排它自己的多智能体拓扑结构。"

具体机制是：主导智能体（lead agent）先制定完成任务计划，然后Claude编写一个编排程序，由该程序启动智能体、收集结果并管理信息流。与之前需要开发者配置协调者和子智能体名册的方式不同，动态工作流让Claude自行决定如何划分和编排工作。

"在多智能体编排的多个不同阶段中，它能够完成离散的、可验证的工作单元，而你无需管理这些环节之间的任何互连，"Stall表示。不过Avilla也补充，用户仍可在智能体配置中传入预配置的专家子智能体。

这套功能目前在Claude Console中可用，也就是开发者通过API访问Claude的界面。

多智能体编排（multi-agent orchestration）指用多个LLM驱动的智能体协作完成单个智能体难以胜任的任务，通常涉及任务分解、角色分配、结果汇总和冲突消解。常见拓扑包括：协调者-工作者（一个主智能体分派任务给子智能体）、流水线（智能体按阶段串行处理）、辩论/投票（多个智能体独立求解后交叉验证）。此前开发者需手工选择拓扑并编写调度代码（如LangGraph、AutoGen等框架）。动态工作流的区别在于把“选择拓扑”本身交给Claude：主导智能体先规划，再由Claude生成编排程序（本质上是一段调度代码），运行时按需实例化子智能体。这意味着拓扑是运行时动态生成的，而非开发时静态配置，因此同一flow在不同输入下可能展开成完全不同的协作图。

股票监控示例：简单场景下的模式验证

演讲者展示了一个相对简单的股票观察列表扫描器工作流。虽然这远不及Anthropic鼓励的宏大项目，但清晰展示了基本模式：扫描阶段将个股代码分发给具有隔离上下文的智能体，随后的审查阶段检查发现结果并生成报告。

这个示例的价值在于让开发者直观理解flows的"分而治之"逻辑——每个子智能体在独立上下文中工作，避免信息污染，最终由主导智能体汇总。

预算控制与自我改进的边界

观众问答环节暴露了几个值得关注的实践问题。

关于Claude如何决定任务需要多少智能体、简单的股票扫描是否会触发数百个子智能体，Stall的回答是："答案其实就是评估和更低的默认值。"他提到，宏大的任务通常需要明确鼓励更大的并行化。

Token预算控制是一个持久关注点。有人问主导智能体是否知道自己有多少可用资金。Stall回答说，模型在运行时并不知道自己的预算，但开发者可以设置会话预算。他还提到，告知模型预算可能会让智能体"有点焦虑"，引发现场笑声。

关于如何让重复运行的flows随时间变得更便宜高效，Avilla建议使用另一个较新的功能： dreaming。根据文档定义，dreaming是一个研究预览功能，它"读取现有记忆存储和过往会话记录，然后生成一个新的、重新组织的记忆存储"，合并重复项、替换过时或矛盾的条目、浮现新的洞察。Avilla将dreaming在flow语境下描述为能够"结晶并基本上改进与那些会话相关的记忆存储"。

对于股票观察列表flow能否自我改进的问题——比如识别到扫描模型不足并更改下次计划运行——Stall表示这并非内置功能，但可以结合爬山法和dreaming来改进循环。

**测试时计算（test-time compute）**指在推理阶段而非训练阶段投入更多算力来提升模型表现，典型手段包括思维链、自洽性采样（多次采样投票）、best-of-N、树搜索等。其核心假设是：对困难问题，让模型“多想一会儿”或“多试几次”，效果可媲美扩大模型规模。动态工作流把这一思路扩展到多智能体层面——不是让单个模型多想，而是让多个智能体在隔离上下文中并行探索不同路径，再由主导智能体汇总。这种“并行采样+汇总”的结构天然适合搜索空间大、单点易遗漏的任务（如全库代码审计、文献综述）。但代价是token消耗随智能体数量近似线性甚至超线性增长，因此测试时计算的收益必须与成本权衡，这也是演讲者反复强调预算控制和dreaming优化的原因。

可观测性与成本权衡

子智能体行为的可见性方面，Avilla确认开发者始终可以通过Claude Console内的图形功能进行检查。"你可以看出主导智能体实际传了什么给子智能体，你可以在这里查看payload，深入理解整个图中每次转换实际发生了什么。"

子智能体之间能否直接通信？Stall表示智能体共享文件系统，可以通过它交换信息，但开发者无法通过API直接指示一个工作流子智能体给另一个发消息。

成本方面，Avilla在对比中明确表示，flows的成本"高得多"，但在"找到所有细节方面也有效得多"。这是一种典型的能力-成本权衡：单个智能体可能遗漏细节，而多智能体并行扫描能覆盖更全面的信息。

宏大科学问题的可能性

有人问到动态工作流能否支撑大型科研项目，并引用了OpenAI最近关于Navier-Stokes千禧年大奖难题的证明声明。Stall没有透露Anthropic如何计算大型科学问题的具体细节，但表示让普通用户也能攻克这些问题正是他们的目标。

"Flows基本上是一种将测试时计算投向困难问题并从模型中更快获得更多能力的方式，"他说。"我们认为，特别是作为API服务，释放这种力量是我们让这类发现或科学进步被大众广泛实现的第一步。"

这个愿景值得认真对待。测试时计算（test-time compute）已成为提升模型能力的重要路径，而flows本质上是在多智能体层面系统化地扩展测试时计算。如果这条路走通，未来复杂科研问题的求解可能不再是大实验室的专利。

但从股票扫描器到Navier-Stokes证明之间，跨越的鸿沟不容小觑。当前flows在预算控制、自我改进、智能体间通信等方面仍有明确限制，距离支撑宏大科研项目还有相当距离。Anthropic将其定位为"第一步"，是务实的表述。