对在 Windows 上跑智能体的人来说，这条新闻的价值不在「又多了一个功能」，而在 Anthropic 把瓶颈的位置说清楚了：智能体写代码越来越快，人类审代码的速度没变，于是队列越堆越长。**dynamic workflows（动态工作流，现场都叫 flows）**就是为此设计的编排层，官方定义是「a new type of multiagent orchestration, built for your most ambitious workloads」。功能在此前那个周五发布，由 Anthropic 技术团队成员 CJ Avilla 与 Harrison Stall 在 AI Engineer New York 现场拆解。来源：https://www.latent.space/p/claude-dynamic-workflows
关键事实
| 项目 | 内容 |
|---|---|
| 回答的问题 | Anthropic 动态工作流：把 Claude 智能体当操作系统进程来编排 |
| 简答 | Anthropic 在 AI Engineer New York 上介绍了 dynamic workflows（动态工作流）：面向 Claude Managed Agents 的多智能体编排层，官方定义是「为最 ambitious 的工作负载打造的新一类多智能体编排」。整场分享借 Unix 与 Linux 的历史说明真正的瓶颈——当你同时跑很多智能体时，卡住的是在 GitHub 上逐个批准 PR 的那个人。 |
| 阅读时长 | ~4 分钟 |
| 最后更新 | 2026-10-17 |
为什么开场要讲 Unix 和 Linux
两位讲者先从操作系统史讲起：Ken Thompson 做出最初的 Unix，Linux 则从一个人的项目长成一层层受信任的维护者。他们要说明的道理很朴素——大工程从来不靠某个英雄人物硬扛，靠的是结构：谁负责哪块、边界在哪、层与层之间怎么交接。
这套逻辑被原样搬到智能体上。今天的模型已经会写代码，但它没法在五十条并行工作流之间自己仲裁。于是 Anthropic 让一个主智能体站到「调度器」的位置，把有边界的小任务分给下面的子智能体。
「你会先变成瓶颈，再变成断点」
整场最值得记的一句，是 Avilla 描述缺少编排时的真实体感：
「现在很多在编排、管理大量智能体的人，可能都开始有这种感觉：自己成了瓶颈，成了断点——一堆智能体在往仓库里灌 PR，而我们坐在 GitHub 里一个个点批准，确认一切符合预期。」
这段话说中了失败模式：智能体变快了，评审队列没有变快。往一个「人审批」是瓶颈的流程里继续加智能体，只会让队列更长。
一条 flow 是怎么搭起来的
从分享和问答里能还原出四个部件：
- 一个主智能体负责拆任务、决定并行度。有人问「一个很小的触发条件会不会炸出几百个子智能体」，Stall 的回答是：「答案其实就是 evals 和更低的默认值」——真正的大任务通常要显式要求它加大并行。
- 有边界的子智能体。演示的自选股扫描器把工作拆成扫描、核对、汇报几段，而不是让一个智能体一口气跑完。
- 共享文件系统。子智能体靠文件交换数据。这同时也是限制：Stall 说没有 API 能让一个子智能体直接给另一个发消息。
- 可检查的调用图。在 Claude Console 里能看到主智能体到底把什么传给了子智能体。Avilla 的原话是：「你可以在这里看那一段 payload，深入理解整张图里每一次跳转到底发生了什么。」
成本、预算，以及「别告诉模型它有多少钱」
Anthropic 没有回避价格问题。在自选股扫描器的对比里，Avilla 说 flows 比单智能体方案「贵得多」，但「找出全部细节」的能力也「强得多」。
预算机制有三点值得先弄清楚：
- 模型运行时并不知道自己还有多少额度；
- 预算由开发者在会话层面设定；
- Stall 提到，把预算告诉模型可能会让智能体「有点焦虑」——玩笑背后是实话：预算是运营者的控制面，不是模型的规划输入。
「Dreaming」：给记忆做整理
被问到「重复跑同一类 flow 怎么越跑越便宜」时，Avilla 指向了 dreaming（研究预览）。按 Anthropic 文档的说法，一次 dream 会「读取现有记忆库和过去的会话记录，产出一个重新组织过的记忆库」，合并重复项、替换「过期或自相矛盾」的条目，并把新洞察浮出来。
放到 flow 语境里，这就是定期整理：子智能体依赖的那份记忆不会无限膨胀到没法用。Avilla 的说法是，它能「把跟这些会话相关的记忆库结晶、改良」。
但 flows 不会自我进化。有人问自选股流程能不能自己发现「扫描模型不够好」并改掉下一次的计划，Stall 明确说没有内建这个能力，只提出可以用 hill-climbing 加 dreaming 自己拼出来。
对桌面 / 本地智能体的四点启示
本站读者大多不是在跑大规模 Managed Agents，但这套瓶颈逻辑是通用的：
- 照搬主/从拆分。 就算只有一个桌面智能体，一段「什么都干」的超长提示词，也是同一个错误的单机版。每一步给一个有边界的任务和一个明确的产出。
- 把交接落在磁盘上。 flows 用文件系统传数据，因为文件可检查。Windows 上同样如此：一个带编号产物的作业目录，比把状态塞进聊天记录强——文件能打开、能 diff、能单独重跑某一步。
- 先定预算再并行。 每次运行设上限。Anthropic 那个「模型不该自己算预算」的立场，对本地跑法同样是好默认值。
- 人留在决策位，而不是留在按键位。 这场分享的主张是让评审去接住自动化检查抓不住的问题，而不是让评审消失。
如果你真正需要的，是在文件所在的这台机器上跑智能体——安装包、Office 文档、本地构建、Windows 工具链——那是另一半答案：[下载 MOOGH] 在本机运行、逐动作授权，而不是把工作送去沙箱。
常见问题
动态工作流现在能直接用吗？ Anthropic 在 AI Engineer New York 之前的周五发布该功能，并把它放在 Claude Managed Agents 体系里讲。具体可用范围以 Anthropic 官方文档为准，别拿会议报道当版本说明。
不用 Managed Agents 就不能用这套思路吗？ 能。主智能体/子智能体的拆分、基于文件的状态交接、显式预算，都是设计选择，套在任何智能体运行时上都成立，包括本地运行时。
为什么不干脆换一个更大的模型？ 因为单次pass 在大任务上会漏细节——讲者自己的对比就是 flows 找得更全、但更贵。这是覆盖率与成本之间的取舍，只有任务真的够大才划算。
相关阅读：