洞察
研究报告2026-08-05 · 17 分钟读

并行读,串行写:2026 年 Agent 编排架构的收敛点

两年里最激烈的架构争论正在收敛。把三方材料——一方的立场反转、一份趋势报告、一份失败分类研究——放在一起看,它们指向同一条判据;此前这条判据没有被作为统一标准交叉验证过。


2025 年 6 月,Cognition 发表《Don't Build Multi-Agents》。同期,Anthropic 发表《How we built our multi-agent research system》。两篇文章的标题针锋相对,被广泛解读为业界对 Agent 架构的路线分歧。

一年后,Cognition 的立场变了。他们的新文章标题是《Multi-Agents: What's Actually Working》,其中给出了一个具体的判据:多个 Agent 可以共同为一个任务贡献智能,但写入必须保持单线程。

这个判据不只是 Cognition 的经验总结。把它放回 Anthropic 的多 Agent 研究系统架构里,同样成立;再放到 MAST 失败分类的统计结果上,它直接对应其中占比近三分之一的一类失败。三方材料来源不同、立场不同、方法不同,却指向同一条线。

本文的主张是:2026 年这场争论的实际收敛点不在「用几个 Agent」,而在「哪些环节可以并行、哪些必须串行」。真正的分界线是读与写,而非 Agent 的数量。

数据来源见文末;其中第七节的企业案例为厂商报告转述的客户自述数据,非一手测量。第一方实践观察与引用数据分列。讨论范围限于架构与工程层面,不涉及模型训练与评测基准构建。

一、争论的实际走向

1.1 反对方的立场变了,但反对的理由没变

Cognition 最初的反对意见针对的是一种具体形态:多个 Agent 并行地对同一份产物进行写入。他们的新文章确认这类形态依然行不通——多个 Agent 同时写同一份产物的结构,问题一年后仍在。

变化的是他们承认了另一类形态确实有效:多个 Agent 各自贡献判断,而最终的写入动作保持单线程。他们给出了三种正在生产环境跑通的具体结构。

结构并行的部分串行的部分公开可查的佐证
代码评审环评审 Agent 以完全干净的上下文独立审查写代码的 Agent 单线程改平均每个 PR 发现 2 个缺陷,其中约 58% 为严重级
强模型咨询弱模型把难题交给强模型当工具问决策与执行仍在主 Agent两端都需是前沿模型;中端模型配强模型效果不佳
管理者—子 Agent子 Agent 并行执行被拆开的子任务管理者串行地合并与汇报该文未给出这一结构的单独效果数据
来源:Cognition《Multi-Agents: What's Actually Working》。三种结构的共同点是并行发生在信息获取与判断环节,写入与合并环节保持单点。同文另给出一项背景数据:该厂商在最大企业客群中的产品使用量 6 个月增长约 8 倍——这是产品整体的采用情况,不能归因于上述任何单一结构。

1.2 支持方的架构其实是同一个形状

Anthropic 的多 Agent 研究系统被视为多 Agent 路线的代表。但看它的实际结构:子 Agent 各自持有隔离的上下文窗口并行检索,每个子 Agent 向主 Agent 返回一份 1000 至 2000 token 的压缩摘要,由主 Agent 汇总。

并行的是检索——即读。串行的是汇总与结论——即写。与 Cognition 给出的判据完全一致。

两篇立场相反的文章描述的是同一个架构形状。

二、失败数据从反面印证同一条线

MAST(Multi-Agent System Failure Taxonomy)是目前对多 Agent 失败模式最系统的一份研究。研究方法为:跨 7 个主流多 Agent 框架收集 1642 条执行轨迹,其中约 150 条由人工专家标注,其余由经过校准的模型标注器标注(与人工标注一致性 κ=0.77),归纳出 14 种失败模式,聚为三大类。

失败类别占比典型表现
规范与系统设计问题37.2%任务边界不清、角色定义含糊、路由错误
Agent 间协调失配31.4%重复劳动、职责冲突、信息未传递
任务验证不足31.4%输出未校验、错误在链路中传播
来源:MAST 失败分类研究(arXiv:2503.13657,v3 口径)。

其中第二类(31.4%,协调失配)直接对应「多个 Agent 各自行动、彼此不一致」,这正是并行写入产生的问题类别。第一类(37.2%,规范与设计)中有一部分同样源于写入点不唯一——任务边界不清往往正是因为没有约定谁来写——但公开分类无法拆分出这一比例,本文不将其计入。

第三类(31.4%,验证不足)指向另一个问题,见第五节。

MAST 测得的失败率区间跨度很大(41% 至 86.7%),但需要说明的是,这是跨不同框架、不同模型、不同基准任务的测量,不是同一框架在生产环境中的差异。它能支持的结论只有一条:在同类任务上,不同实现之间的可靠性差距可以达到两倍以上。

三、为什么是读与写

读操作可以并行,因为多份读取之间不产生冲突。两个 Agent 同时检索同一份资料,各自得到的结论可以不同,冲突在汇总时暴露,由汇总方裁决。信息的冗余是有益的——它提供了交叉验证的机会。

写操作不能并行,因为写入的目标是同一份状态。两个 Agent 同时修改同一份代码、同一个文档、同一条记录,冲突不会在汇总时暴露,而是直接产生一个双方都没预期的结果。而且大模型不具备传统并发编程中的锁语义——它不知道自己正在与另一个 Agent 竞争,也不会在冲突时退让。

这个区别在传统分布式系统里是常识。多 Agent 系统的特殊之处在于:Agent 的「写」往往不表现为显式的数据写入,而表现为「做了一个决定」。当两个 Agent 各自做出了关于同一件事的决定,冲突已经发生,但系统里没有任何地方记录了这次冲突。

MAST 归类为协调失配的那 31.4%,典型形态正是这一种:不是数据被写坏了,是两个 Agent 对同一件事有了不同的理解,然后各自据此行动。

3.1 一个必须处理的反驳:并行写并非不可实现

分支隔离后合并、写入分片各自持有唯一属主、乐观并发加冲突检测,这些都是在生产中跑通的做法。因此「并行写一定失败」的说法并不成立。

但这些做法有一个共同点:仲裁由系统提供,不由模型提供。一旦引入分片属主或分支合并,每一份状态在语义上仍然只有一个写入者。这与本文的判据不矛盾,恰恰是它的实现形式。真正失败的是另一类——多个 Agent 对同一份状态自由写入,并指望模型自己协调。

四、并行读的代价:乘数大,且尾部不可预测

并行读的收益有公开的量化结果。Anthropic 的多 Agent 研究系统(主 Agent 使用能力更强的模型,子 Agent 使用成本更低的模型)在研究类评估任务上,相对同等条件下的单 Agent 取得了 90.2% 的性能提升。

同一份材料给出了代价:多 Agent 系统的 token 消耗约为普通对话的 15 倍,而单 Agent 约为 4 倍。

第三个数字:在 BrowseComp 评估中,token 支出这一个变量就解释了约 80% 的性能方差,其余由工具调用方式与模型选择解释。

形态相对 token 消耗性能表现
普通对话基准
单 Agent约 4×基准之上
多 Agent(主从结构)约 15×相对单 Agent 提升 90.2%
来源:Anthropic 多 Agent 研究系统公开数据。同一评估中,token 支出单一变量解释约 80% 的性能方差。

把这三个数字放在一起:多 Agent 的性能优势,很大程度上由 token 支出驱动,而非架构本身产生的增量智能。并行读之所以有效,主要因为它让系统有能力读得更多、看得更广——这需要相应的成本。

如果性能提升主要由 token 支出驱动,那么在同等预算下,「换更强的单 Agent」与「上多 Agent」就是两个需要真正比较的选项,而不是后者必然更优。该对照目前没有公开实验,这里提出的是评估方法而非结论。

4.1 成本的复合放大

15 倍是正常运行下的基线。异常情况会在此基础上继续放大:子 Agent 递归地派生更多子 Agent,或某个工具返回超出预期的大体积结果并进入多个上下文,都可能使单次查询的成本再乘上一个量级。

这类放大不易预测,且往往在生产环境的真实负载下才出现。协调开销、上下文重复传递、验证层、重试循环——每一次 Agent 之间的交接都会叠加一次。

4.2 经济性的判据

由此得到一条判据:多 Agent 的经济性成立,当且仅当单次任务的价值高于其 token 成本。

这条判据把适用场景切得很清楚。法律尽调、竞争情报、生物医学文献综述这类任务,单次结果的价值足以吸收十几倍的成本乘数。消费级问答、常规客服、高频轻量查询则不能——在这些场景里,15 倍的成本乘数会直接吃掉全部毛利。

以下为我们的观察,非引用结论:国内中小企业的 AI 预算多按月固定,而非按任务价值浮动。在这种预算结构下,即使某个任务在单次价值上算得过账,成本的波动幅度本身也构成约束。

五、可验证性决定可委托性

Anthropic 在 2026 年的趋势报告中给出了一组看似矛盾的数据:工程师在大约 60% 的工作中使用 AI,但报告称只能「完全委托」其中 0% 至 20% 的任务。

报告将其称为协作悖论,并给出了关键线索:工程师系统性地把「容易核对对错」的任务交出去,把依赖设计判断的任务留给自己。也就是说,决定一个任务能否交给 Agent 的不是难度,而是验证其输出的成本。

这一机制我们在另一篇《验证危机:AI 编码的瓶颈已经不在生成侧》里做了完整论证,本文只取它在编排架构上的一个推论。

把这一推论放回编排架构:Agent 在编码场景推进最快,是因为编译器、测试、类型检查器构成了一批低成本的自动验证器;而在缺少此类验证器的领域,即使模型能力继续提升,委托比例也不会显著上升——瓶颈不在生成侧。

MAST 中 31.4% 的失败来自验证不足,与协调失配同为 31.4%,并列第二。对编排设计的直接含义是:先把验证器建起来,再扩大并行规模;顺序反过来,产出规模的上限等于人工复核的上限。

六、长任务的门槛正在从单步质量转向状态一致性

2026 年 Agent 能力最直观的变化是任务时长。Anthropic 报告中的一个案例:一个编码 Agent 在包含 1250 万行代码的开源库上实施特定方法的实现,单次运行连续工作七小时完成,结果与参考实现相比数值精度达到 99.9%。

七小时的自主运行意味着大量的工具调用、多次失败恢复,以及跨越远超单个上下文窗口的信息量。这里的技术门槛不在于单步推理的质量,而在于跨越长时间跨度维持一致的状态。

Cognition 列出的未解决问题也集中在状态传递上:较弱的模型如何学会何时向上求助;上下文如何在 Agent 之间传递而不淹没接收方;子 Agent 的发现如何影响兄弟 Agent 正在进行的工作。

在并行读、串行写的结构里,子 Agent 之间默认互不通信——这正是它安全的原因。但当一个子 Agent 发现了会影响其他子 Agent 前提的信息时,这条信息只能等到汇总阶段才被处理,此时其他子 Agent 可能已经基于错误前提完成了工作。

这是并行读、串行写架构的固有代价,目前没有公认的解法。缩短汇总周期可以缓解,但会削弱并行带来的收益。

七、规模化的公开披露与其含义

2026 年公开的企业部署数据显示,Agent 带来的收益不主要体现在「同样的工作做得更快」,而体现在「做了本来不会做的工作」。

组织公开数据性质
TELUS创建 13,000+ 定制 AI 方案;工程代码交付快 30%;累计节省 50 万小时,平均每次 AI 交互节省 40 分钟规模化内部工具
Zapier全组织 89% 采用率,内部部署 800+ AI Agent非工程岗位扩散
Fountain筛选快 50%、入职快 40%、候选人转化 2 倍;某物流客户新中心全员配齐从一周以上降至 72 小时内层级式多 Agent 编排
某厂商法务团队市场素材审核从 2–3 天降至 24 小时,由无编程经验的法务人员自建工具完成领域专家直接实现
四例均为厂商报告中的客户自述数据,未经独立验证;此处用于观察方向而非量级。来源见文末。

报告中另一组数据:约 27% 的 AI 辅助工作属于「本来不会做」的任务——规模化的实验、原本不值得投入工时的内部工具、探索性分析。同一份报告指出,工程师报告的是单任务耗时下降,但产出总量的增长幅度远大于耗时的下降幅度。

近三成的增量工作说明,边界扩展是一条被普遍低估的价值路径,而不只是既有工作的成本压缩。对企业而言,这个区别决定了投入的评估方式:如果按「替代多少人力」评估,多数项目算不过账;如果按「解锁了多少原本不做的事」评估,结论会完全不同。

89% 的采用率与 800 个以上的内部 Agent 也指向同一方向:这个量级的 Agent 数量难以全部对应原有岗位。

八、对落地的几条判断

综合上述材料,我们给出四条可操作的判断。这些判断是我们的观点,不是引用来源的结论。

判断一:架构评审先问写入点在哪

评估一个多 Agent 方案时,第一个该问的问题不是用了几个 Agent、用什么框架,而是:系统里有几个写入点。如果超过一个,需要明确说明冲突如何被检测与裁决。答不上来的方案,大概率会落入 MAST 中协调失配的那 31.4%。

判断二:验证器先于规模

见第五节:不存在低成本自动验证手段的领域,扩大生成侧投入不产生额外产能。

判断三:验证方必须与实现方异源

由同一个模型、同一套提示词生成实现与其验证逻辑,二者共享同一组假设,因而系统性地对同类错误免疫。验证方应来自不同厂商的模型,且不应被告知实现方的设计意图。

判断四:按解锁的新工作评估投入,而非按替代的人力

27% 的增量工作与产出总量的增长幅度说明,Agent 投入的主要回报在边界扩展。以人力替代为口径的评估会系统性低估其价值,并导致投入方向偏向已有流程的自动化,而非新工作的开辟。

九、尚未解决的问题

  • 并行读的兄弟 Agent 之间的信息传递:一个子 Agent 的发现如何及时影响其他子 Agent 的前提,目前没有既不牺牲并行收益、又能保证一致性的公开解法。
  • 跨模型的能力升级判断:较弱的模型何时应当把问题上交给更强的模型,目前依赖提示词约定而非模型自身的判断能力。Cognition 指出中端模型与前沿模型的搭配效果不佳,说明这一判断本身需要较强的能力。
  • 长任务的状态一致性:七小时级别的自主运行已经实现,但跨越该时长维持状态一致的方法仍以工程手段为主,缺少通用机制。
  • 多 Agent 失败率的区间过宽:41% 至 86.7% 的跨度说明目前缺少可复用的架构基线,团队之间的实践水平差异大于框架之间的差异。

十、结论

把 2026 年的三方材料放在一起看,单 Agent 与多 Agent 的对立并不成立。被判定失败的是并行写入,被验证有效的是并行读取加单点合并——立场相反的两方,描述的是同一个架构形状。

在这个形状之上,有四条约束决定了它能走多远。第一条是成本:并行读的性能提升很大程度由 token 支出驱动,成本乘数大且尾部不可预测,其经济性只在单次任务价值足够高时成立。第二条是验证:任务能否被委托,取决于验证其输出的成本,而非任务本身的难度;这解释了为什么编码是推进最快的领域,也预测了哪些场景会长期停留在辅助位置。第三条是状态:长时任务的门槛已经从单步推理质量转移到跨时间跨度的状态一致性,而并行 Agent 之间的信息传递至今没有既保留并行收益、又保证一致性的公开解法。

第四条是价值口径:公开披露显示,Agent 带来的收益有相当部分落在「本来不会做的工作」上,而非既有工作的提速。以人力替代为口径评估投入,会系统性低估这一部分,并把投入引向已有流程的自动化。

对于正在做架构选型的团队,本文的最短检查清单是四个问题:写入点有几个,验证器是否存在,成本乘数与尾部风险有多大,价值按什么口径计。

参考来源

  • Anthropic,《2026 Agentic Coding Trends Report》:八项趋势预测,及正文引用的全部企业案例数据出处。
  • Cognition,《Multi-Agents: What's Actually Working》:三种生产环境验证过的多 Agent 结构,及其代码评审数据。
  • Cognition,《Don't Build Multi-Agents》(2025):并行写入型多 Agent 的问题分析,本文讨论的立场起点。
  • Anthropic,《How we built our multi-agent research system》:子 Agent 隔离上下文的架构描述,及 90.2% 性能提升、15× token 消耗、80% 性能方差由 token 支出解释等公开数据。
  • Anthropic,《Effective context engineering for AI agents》:子 Agent 向主 Agent 回传 1,000–2,000 token 压缩摘要的具体数值出自此文。
  • MAST: Why Do Multi-Agent LLM Systems Fail?(arXiv:2503.13657):跨 7 个框架 1600+ 条标注轨迹,14 种失败模式的分类与占比。
文中标注为第一方实践观察的部分,来自一次编排层重构:三轮异源盲审、九个可复现缺陷,同源测试在同期未能暴露其中任何一个。该案例用于印证第五节的推论,样本量不足以支撑独立结论。

想把这些落到你的业务里?

少谈概念,先聊清你的场景。

继续阅读 / More