从一个智能体，到一千个并行分身
Anthropic 在 10 月的平台更新里，给 Managed Agents 加了一种新的多智能体形态：一个主导智能体可以把任务分发到最多 1000 个并行子智能体，让它们同时推进，再把结果汇总。与之配套的是动态工作流（Dynamic Workflows）的测试版——主导智能体能写一段程序，分多个阶段调起一群智能体并合并产出，而不需要团队自己搭一套编排器。
官方给出的一个具体场景是代码库测试：在同样的任务里，这种并行编排抓出了 70 个隐藏缺陷中的 66 个，而单个智能体只找到 27 个。对需要批量审查文档、大规模调试的工程团队来说，等于把「fan-out 到很多智能体」这件事，从自研编排降成了配置开关。
并行有用，但账要算清楚
这则数字很能说明问题，也要冷静看待。它指向的是「可并行的可分解任务」——审查、扫描、对照这类工作，拆得越细、铺得越开，收益越明显。但它并没有回答多智能体规模化的老问题：当任务需要强协作、上下文要跨智能体反复对齐时，协调成本会快速吃掉并行的红利。
此前业界就有人泼过冷水，认为一味堆叠智能体，边际收益会迅速衰减。Anthropic 这步更像是把「大规模并行」做成了一项可被直接调用的基础设施能力，而不是声称它解决了一切。对工程团队而言，真正的取舍在于：哪些任务值得铺开一千个分身，哪些任务宁可让少数智能体慢慢把上下文对齐。
怎么用才划算
务实的起点是先用小规模并行验证任务的可分解度，确认收益后再放大 fan-out 规模，而不是默认开满 1000 路。文档审查、回归测试、日志扫描这类天然可并行的活儿，适合一次性铺开大批量子智能体；而需要长上下文、跨智能体反复对齐的协作型任务，硬铺并行只会让协调开销反噬收益。把「可分解」当门槛，才能把并行的红利真正落进口袋。