一条新闻背后的两种世界观
2026 年 10 月上旬，Anthropic 为 Claude Managed Agents 平台加入了 dynamic workflows（动态工作流）：一个主 Agent 负责制定计划、把任务分发给子 Agent、最后合并结果，单次执行最多可以并行跑起 1000 个子 Agent。启用方式很简单——选用 multiagent_20261001 这个 Agent 类型即可。
Anthropic 给出的成绩单相当漂亮：团队在一个 11.6 万行的代码库里人为埋入了 70 个 bug，单个 Agent 每轮只能找到 14 到 27 个，而动态工作流稳定命中 66 个。接近满分的找回率，靠的不是更聪明的单模型，而是 sheer scale——纯粹的数量。
有意思的是，就在几乎同一时间，OpenAI 的一位资深 Codex 工程师公开称「Agent 蜂群（agent swarm）是对 token 的巨大浪费，质量收益为零」。两家头部实验室，对同一个技术方向给出了截然相反的判断。这已经不是工程细节之争，而是关于「Agent 可靠性从哪里来」的世界观之争：一边认为可靠性来自更聪明的单体，一边认为可靠性来自受控的并行冗余。
这篇文章想认真算一算这笔账。
动态工作流到底做了什么
先把事实钉牢。Anthropic 的 Managed Agents 托管基础设施此前已经存在，这次新增的是「动态工作流」这一编排层。它的运行模式是经典的 map-reduce 式结构：
- 主 Agent 拆解任务：理解目标，生成执行计划，确定子任务的粒度和边界；
- 分发：把子任务交给一批子 Agent，每个子 Agent 在自己的上下文里独立工作，互不干扰；
- 合并：子 Agent 完成后，主 Agent 汇总、交叉验证、去重，形成最终结果。
这个结构本身并不新鲜——过去两年里，LangGraph、CrewAI、AutoGen 以及各家自研框架都在做类似的编排。真正的变化在于三件事：
第一，规模上限被拉到了 1000。 此前多数编排框架在实践中跑十几到几十个子 Agent 就会遇到稳定性问题；托管平台把并发、重试、状态管理都收进基础设施层之后，「一千个」第一次成为一个可以认真讨论的数字。
第二，编排本身成为平台能力而非用户代码。 用户不再需要自己写调度器、处理子 Agent 崩溃重试、维护中间状态。这降低了门槛，也意味着可靠性责任从应用层上移到了平台层。
第三，官方坦率地警告成本。 Anthropic 自己承认这种模式会烧掉「a lot of tokens」，建议从小规模起步。这种明示成本的姿态值得肯定——它等于承认了：这不是默认开启就万事大吉的功能，而是一笔需要算账的投入。
66/70 意味着什么，又不意味着什么
那个 70-bug 测试值得仔细拆。单 Agent 每轮 14-27 个、动态工作流稳定 66 个，差距确实是碾压级的。但这个数字背后有几个结构性原因，它们恰好说明了并行编排「什么时候有效」：
覆盖率问题天然适合并行。 找 bug 的本质是覆盖率问题：每个 bug 藏在代码的不同角落，一个 Agent 的注意力窗口有限，扫过的地方就那么多。1000 个 Agent 各扫一片，覆盖率自然指数级上升。这与「多陪审团」的冗余投票不同——冗余解决的是「判断不稳定」，并行解决的是「视野不够宽」。前者适合答案聚合（多数投票即可，蜂群的 token 效率确实存疑），后者适合空间搜索（不并行就是做不完）。OpenAI 工程师批评的「swarm」更多指前者；Anthropic 展示的是后者。两者其实都在说对了自己看到的那一半。
上下文隔离是隐性收益。 单 Agent 读 11.6 万行代码必然超出上下文窗口，只能采样式阅读，丢 bug 是必然的。子 Agent 各自带一小片代码的干净上下文，反而让每个局部都得到「完整阅读」的待遇。这提示我们：并行的价值不只是快，还有每个执行单元拥有更干净的上下文——这是单线程放大模型也买不到的。
但「在不同任务类型上是否成立仍待验证」——这是原文自己的保留意见，也是最重要的一句话。找 bug 是结果可枚举、可验证的任务；换成写一份战略分析、做一次架构决策，产出无法枚举验证，1000 个并行意见合并起来可能是一片噪声。可验证性，是暴力并行成立的前提条件。
成本这道算术题
真正决定这项技术命运的，不是 66/70，而是每个 bug 的成本。
做一个粗略的量级估算：假设单 Agent 每轮找到约 20 个 bug 消耗一份上下文的 token，那么找全 70 个 bug，单 Agent 需要多轮重复运行且永远有残漏；动态工作流一次性调度 N 个子 Agent，token 总量是单次的 N 倍以上（还要加上主 Agent 合并结果的开销）。也就是说，你用数量级的 token 增量，换来了从「永远漏掉一半」到「接近全覆盖」的质变。对安全审计、遗留系统改造这类「漏掉一个代价极高」的场景，这笔账算得过来；对日常 code review，大概率算不过来。
这正好呼应了本期日报里另一个数据点：Asana 用 GPT-6 Astra 与 GPT-6.1 Sol 分层路由，把浏览器 Agent 的成本降了 76 倍、提速 5 倍——核心思路是「贵模型只做难步骤」。两条新闻放在一起读，2026 年 Agent 工程的主旋律其实非常清晰：
- 并行解决覆盖，分层解决成本，两者会组合使用。 未来的合理架构很可能是：主 Agent 用强模型做规划与合并，中间层按难度路由，叶子层用便宜模型大规模并行。Anthropic 的动态工作流给出了叶子层的上限，Asana 给出了路由层的样本。
- NVIDIA 在 KDD Cup 的经验补上了第三块拼图：把工程重心放在 harness（工具环境与流程脚手架）上，而不是迷信模型。编排、路由、harness，这三样都不是模型能力，而是模型之外的系统设计——Agent 竞争的焦点正在从「谁的模型强」转向「谁的系统设计好」。
值得警惕的三件事
一是熵的增加。 1000 个子 Agent 意味着 1000 个可能出错的位置：幻觉、重复劳动、相互矛盾的结论、合并时的信息丢失。主 Agent 的合并能力成为新的单点瓶颈——如果合并质量差，前面的并行只是更贵地生产垃圾。
二是验证被悄悄转嫁。 66/70 听起来很美，但用户侧拿到 1000 个 Agent 的产出时，谁来验证？官方测试里 bug 是自己埋的、答案自己知道；真实世界里没有 ground truth。产出越多，验证负担越重——这又回到「可验证任务才适合并行」的约束。
三是规模成为新的护城河。 当编排能力由平台托管，token 消耗由平台计量，「能跑 1000 个 Agent」在技术上开放给所有人，在经济上却只对预算充足者真实可用。计算资源在 Agent 时代的集中度问题，会以新的形式重现。
结语：并行是工具，不是答案
Anthropic 的动态工作流把「多智能体」从框架层的一个选项，变成了平台层的一等公民，并用一个漂亮的实验证明了它在可验证、宽搜索类任务上的价值。而 OpenAI 工程师的泼冷水同样有价值：如果任务不需要覆盖率和干净上下文，蜂群就是烧钱。
真正的答案在两个极端之间，而且已经写在最近的工程实践里：用可验证性判断该不该并行，用分层路由控制成本，用扎实的 harness 兜住下限。 1000 个 Agent 不是终局，它只是把「如何组织智能」这个问题，第一次摆到了系统设计的正中央。
参考来源：The Decoder、Anthropic Docs、OpenAI Codex 工程师评论、Asana 浏览器 Agent 案例、NVIDIA KDD Cup 2026 复盘