大模型厂商正在把软件工程的战场从单体推理拖入军团作战。Anthropic 近日在其托管智能体平台推出名为动态工作流的新架构,配置标识为 multiagent_20261001。这套系统由一个主导智能体制定计划,把工作拆解并分派给大量子智能体,官方宣称单次执行支持多达 1000 个 Agent 协同运行。在针对 11.6 万行代码、植入 70 个缺陷的测试中,单智能体仅能捕获 14 到 27 个漏洞,而这套动态架构连续三次捕获了 66 个 Bug。

表面上看,这是一次对单体上下文推理的彻底超越。但在狂欢背后,这项技术既非无限并发的超级蜂群,也非放之四海皆准的银弹。翻开技术规范与工程细节,真正支撑起效率提升的是编排解耦机制,而制约其落地的则是真实的并发硬顶与文件写入死穴。

拆解千数神话:生命周期总额与 64 并发上限

外界对动态工作流的第一反应,往往聚焦在千枚智能体同时起飞的科幻感。然而在真实系统架构中,并行与并发存在根本区别。Anthropic 官方开发文档清晰界定了两个技术指标:单次工作流生命周期内最多运行 1000 个 Agent,但底层 Managed Agents API 的并发执行线程上限实际上只有 64 个。

这意味着系统运作机制不是一千个模型实体在某一秒同时向代码库开火,而是一套严密的分批排队机制。主智能体通过动态划分阶段,以最高 64 个活跃并发为水管口径,逐批完成任务的派发、执行、验证与资源回收。将生命周期内生成的智能体累计总数包装成并行神话,是科技传播中屡试不爽的放大镜,但工程实施团队在测算响应延迟与吞吐时必须保持清醒。

Claude 动态工作流执行口径还原 标称执行总额 1,000 生命周期累计创建上限 真实底层硬顶 64 API 活跃并发线程数 排查基准召回率 94.3% 70 个埋点漏洞命中 66 个

真正具有技术含金量的跨越,在于 Anthropic 解决上下文过载的手法。以往的多智能体框架之所以容易崩溃,是因为中央协调器需要把所有交互历史塞进同一个对话窗口,随着子任务增加,主模型迅速失忆或失焦。动态工作流的核心机制,在于编排逻辑本身由 Agent 直接生成为可执行代码。主智能体通过编写调度脚本来完成任务切分、扇出与验证,把原本昂贵的提示词通信转变成轻量的代码运行时。

路线对撞:Anthropic 的动态扇出与 OpenAI 的保守委派

超大规模智能体编排落地,随即引爆了行业路线的分歧。此前,OpenAI Codex 团队的一位资深工程师曾公开发难,直指所谓智能体蜂群是对 Token 的严重浪费,且在核心质量上毫无收益。

左侧6枚探针收敛成本,右侧64路探头矩阵密集追求覆盖(示意图)
左侧6枚探针收敛成本,右侧64路探头矩阵密集追求覆盖(示意图)

两家领头羊对智能体协作的态度截然不同。OpenAI 走向了极其保守的收敛路线,其 Codex 架构采用基于 Harness 的委派机制,默认配置仅允许 6 个并发子 Agent 运行。OpenAI 的赌注压在长程编码会话、沙箱隔离以及上下文压缩上,主张通过高精度的单体会话与极小规模委派来完成复杂任务。

两派智能体协作架构对比 Anthropic 动态代码化编排 • 策略:编排调度生成为脚本,任务高频扇出 • 规模:生命周期 1000 节点,64 并发池 • 适用:超大代码库只读审计与分片排查 状态:官方承认高消耗,建议从小规模测起 OpenAI Harness 委派模式 • 策略:沙箱隔离,强上下文压缩 • 规模:默认 6 个并发子 Agent • 适用:长程深度推理与单点逻辑重构 评价:直斥蜂群是无质量增益的算力浪费

Anthropic 则试图在基础设施层直接固化编排能力,把大规模拆解的调度成本压到最低。但这一路线无法回避成本问题。Anthropic 官方在指引中坦承这些工作流会消耗大量计算资源,因此建议开发者从小规模测起。

大规模分发不仅考验模型的理解力,更考验工程预算能否承受几何级数增长的开销。

在企业实际采购场景中,一个由 64 个并发智能体全速运转半小时的任务,其开销可能迅速突破数十美元。如果缺乏严格的终止条件与重试拦截,自动化系统很容易演变为财务失控的漏洞。


94% 战绩背后:只读排查的红利与改写代码的死穴

测试中高达 94% 的缺陷召回率确实亮眼,但这组数据隐藏着极其关键的前提:挖掘代码缺陷是一个天生适合并行的任务。

只读分片排查互不干扰,多节点协同修改则引发写锁竞争与撕裂
只读分片排查互不干扰,多节点协同修改则引发写锁竞争与撕裂

在排查漏洞时,庞大的代码库可以被切割成数百个互不干扰的独立切片。智能体只需要读取属于自己的文件片段,对照语法规范或上下文逻辑输出检测报告。这里没有时间序列上的相互依赖,也没有状态共享带来的竞态冲突。单智能体在此类场景下的溃败,往往是因为长文本记忆衰减与注意力涣散;而多智能体通过分治策略,自然能将覆盖率推向极致。

评估维度只读分片代码审查(当前测试场景)协同修复与代码合并(实际工程落地)
操作模式多节点独立读取、局部逻辑分析多节点协同写入、修改交叉文件
依赖关系低耦合,各模块互不影响高耦合,涉及类型传递与接口一致性
冲突风险无写入竞争,结果仅需追加聚合极高,面临共享文件系统冲突与死锁
扩展效益并行度越高,缺陷检出率越接近极限智能体超过阈值后,合并成本压垮产出

一旦将场景从“寻找缺陷”切换为“编写补丁”,整个系统的复杂度会发生指数级坍塌。Anthropic 的技术文档明确注明,工作流中的多个智能体在同一个执行环境中共享同一套文件系统。而 OpenAI 的工程指南也曾特别警示,当多个智能体修改重叠文件时,必须建立严密的协同协议。

  • 风险.当数十个智能体试图针对相互调用的跨文件逻辑同时提交修改时,文件锁竞争、类型定义冲突以及逻辑回归将接踵而至。原本高效的并行,会退化为漫长而昂贵的冲突仲裁。

代码审计的 94% 召回率不能直接等同于软件工程全自动化能力的到来。对于研发效能负责人而言,当前动态工作流最具确定性的商业价值,依然停留在存量代码安全审计、全仓合规性巡检等只读类任务;至于让数百个 Agent 协同完成从需求拆解到提交上线的主干开发,目前仍需等待更成熟的代码写入协同方案。