Anthropic 于 2026 年 10 月 9 日发布公告，宣布为 Claude 管理智能体（Claude Managed Agents）引入动态工作流（Dynamic Workflows）。按照官方说明，这一能力让主智能体负责任务规划与分派，把一个大任务拆成多个子任务交给子智能体并行处理，子智能体完成后再把结果汇总回主流程，单次执行最多可协调 1,000 个 AI 智能体。官方给出的典型场景是把代码库审查这类大型工程任务拆成多部分并行推进。对正在评估智能体平台的企业而言，真正值得关注的不是"1000"这个数字本身，而是这种主从编排到底在哪些任务上有价值、它的可控性边界在哪里，以及选型时该怎么核验。
动态工作流与固定编排的核心差异
要理解动态工作流的价值，先要看清它和传统固定编排的区别。过去的多智能体方案多采用预先定义好的静态流水线：开发者提前写死步骤和分支，流程按固定图谱执行。这种做法在任务结构稳定、步骤可预测时足够用，但面对规模和形态都不确定的任务就会吃力。
Anthropic 对动态工作流的官方定义是：一段由 Claude 自行编写、用来大规模编排子智能体的 JavaScript 脚本，开发者可以复跑这段脚本。换句话说，编排逻辑不再完全由人工预设，而是由模型根据当前任务在运行时生成"harness"（任务框架）。官方博客举的例子很能说明问题：如果要核查一份报告里的每一条事实陈述，可以让一个智能体先识别出所有待核查的论断，再为每一条论断分派一个子智能体去逐一核实，甚至再加一个验证智能体去检查来源质量。另一个例子是对上千个条目排序——直接把 1000 多行塞进一个提示词，质量会退化且超出上下文窗口，而动态工作流可以用"锦标赛式"两两比较，每次比较都是一个独立智能体，没有任何单一上下文需要容纳全部条目。
这里的实际价值在于：动态工作流把"单个上下文装不下的大任务"切成了"每个子任务都能被独立上下文高质量处理的小块"。对企业来说，大规模代码审计、跨仓库迁移、交叉验证式研究这类任务，正是传统单智能体或固定对话模式难以胜任的场景。
1,000 并行上限：先看清它到底指什么
公告中"单次最多 1,000 个"的表述容易让人误以为是同时在跑的并发数，但官方文档说得更明确：1,000 是单次运行的智能体总额（agents total per run），作用是防止脚本陷入失控的循环，而不是并发规模。
真实的并发受更严格的参数约束。按照 Claude Code 官方文档，默认最多 16 个智能体并发，当可用 CPU 更少时（比如在受限容器内）会更少；若要调整，需要把 CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS 设为 1 到 256 之间的值，并且要求 Claude Code v2.1.269 或更高版本。此外，单次 parallel() 或 pipeline() 调用最多接受 4,096 个条目，超出会被运行时直接报错，而不是悄悄丢弃部分负载。在扇出（fan-out）模式下，共享首个智能体提示词缓存前缀的其他智能体，默认会在首个智能体之后最多 5 秒才启动，以便复用缓存而非各自重复处理。
对成本和可控性的含义就清晰了：生命周期总额决定了一次运行最多能"消耗"多少智能体，而并发上限决定了同一时刻真正占用的资源规模。企业评估成本时，更应盯住并发度、每个子智能体的 token 消耗与缓存命中情况，而不是被"1000"这个总量数字带偏预期。官方同时提示可以设定规模指引（size guideline）、在触及用量上限时暂停与恢复运行，这些都是把大规模并行关进"可控笼子"的机制。
企业选型应核验的几件事
从选型视角看，这项能力目前的可用范围是明确的：官方文档说明动态工作流在所有付费计划、通过 Anthropic API 以及 Amazon Bedrock、Google Cloud 的 Agent Platform、Microsoft Foundry 上均可使用；Pro 用户需在 /config 的对应选项中手动开启。企业若已在上述云平台有部署，接入路径相对顺畅。
但有几点需要在真实环境里核验，而不是照搬演示结论。第一是并发与版本门槛：默认 16 并发、最高 256、且依赖特定客户端版本，这意味着"大规模并行"在不同机器和容器配置下表现差异很大，必须按自身算力实测。第二是共享状态下的协同问题：多个子智能体共享同一文件系统时，仍可能出现协同瓶颈，涉及写冲突、顺序依赖的任务需要谨慎设计编排逻辑。第三是适用场景的边界——动态工作流擅长的是可拆分、可并行、各子任务相对独立的任务（代码库审计、批量迁移、交叉核查）；而 Anthropic 自己在 9 月发布的电商 Agent 架构指南里也指出，在某些场景下单个 Claude 在标准智能体循环中配合技能与工具，质量反而持续优于子智能体拆分。换言之，"拆得越多越好"并不成立，拆解能力的价值取决于任务是否天然适合并行。
企业在验证稳定性时，建议用自己的真实任务做小规模试跑，重点观测：相同任务多次运行结果是否稳定、子智能体失败时能否恢复、总成本与并发度的关系，以及共享文件系统下的一致性表现。这些指标比厂商演示里的单一检出率更能反映生产可用性。
软盟资讯观察
从趋势判断看，动态工作流代表多智能体编排正从"人工预设固定流水线"走向"模型运行时自生成编排脚本"，这是 Agent 从演示走向工程化的一个关键信号。让 Claude 自己写 harness、按任务形态临时组织子智能体，降低了复杂编排的开发门槛，也让"大任务拆解"这件事第一次具备了可复用、可规模化的工程框架。对已在主流云平台部署的企业，这是值得纳入技术储备的方向。
从机会与风险两端看，机会在于代码审计、大规模迁移、交叉验证式研究这类"单上下文装不下"的任务，终于有了结构化的并行解法，适合率先在内部工程场景试点并沉淀编排模式。风险则在于认知落差：公告里的"1000"是生命周期总额而非并发数，真实并发默认仅 16、上限 256，还受 CPU、版本和共享文件系统协同能力制约；若按"同时 1000 路"去规划成本和交付预期，很容易踩坑。更要警惕把厂商演示中的检出率等效果数据直接当成自家落地指标——Anthropic 自己的电商架构指南就承认，并非所有任务都适合子智能体拆分。理性的做法是先用自有任务小规模实测，再决定投入节奏。