一千个并行的子Agent：可靠性买得来吗？——Anthropic 动态工作流的豪赌与代价
一条新闻背后的两种世界观 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 以及各家自研框架都在做类似的编排。真正的变化在于三件事： ...