多Agent协作的核心困局，再强的模型，也绕不开分布式系统的底层逻辑

最近读了两篇极具启发的文章它们来自完全不同的领域却指向了同一个颠覆性结论AI Agent的多人协作本质上不是模型能力的问题而是一个经典的分布式系统问题。无论未来的大模型变得多聪明若不解决分布式协作的核心矛盾多Agent系统的可靠性和效率就永远存在天花板。一篇来自形式化验证研究者Kiran用严谨的数学证明打破了“等下一代模型就好了”的幻想另一篇则出自拥有35年软件工程师经验的Michael Rothrock他用97天、5109次关卡检查的实证数据给出了一套可落地的多Agent协作设计与验证框架。一个偏理论推导一个重实践落地却异曲同工地告诉我们分布式系统几十年积累的理论、协议和工程经验才是AI Agent时代最稀缺、也最容易被忽视的核心能力。很多人在做多Agent协作时都陷入了一个认知误区觉得当前系统效率低、易出错是因为Agent的模型不够聪明只要等更强大的模型问世所有协作问题都会迎刃而解。但这两篇文章用理论和实践双重证据证明这是一种典型的“避重就轻”甚至可以说是一种投降主义多Agent协作的核心矛盾是结构性的协调问题与模型的“智商”无关再强的模型也无法突破分布式系统的底层约束。误区破除“等下一代模型就好”是自欺欺人的幻觉Kiran在研究中提到他经常听到这样的论调当前多Agent系统的协作乱象根源在于模型不够智能无法精准理解人类需求等下一代更强的模型出来就能实现无缝协作。作为长期深耕形式化验证的研究者他认为这种想法不仅不切实际还会误导多Agent系统的发展方向。他的反驳很直接模型的能力提升确实能解决部分细节问题但多Agent协作的核心是协调问题这是一种结构性矛盾与模型的聪明程度无关。为了证明这一点Kiran将多Agent软件开发过程进行了形式化建模让我们看清了协作的本质。假设我们给多Agent系统一个自然语言指令比如“帮我开发一个食谱追踪APP”。这个指令看似明确实则存在大量模糊地带用专业术语来说就是“欠定义”的满足这个指令的合法程序不止一个而是一个庞大的集合Φ(P)。当我们安排n个Agent并行开发时每个Agent都会产出一个组件φᵢ而协作的核心共识条件是必须存在某一个φ ∈ Φ(P)使得每个φᵢ都是它的细化。简单来说所有Agent在并行工作的过程中必须收敛到对同一个指令的统一理解上而且一个Agent的设计决策会直接约束其他Agent的可选空间反之亦然。这并不是我们想象中“各写各的、最后拼接”那么简单而是多个Agent联合完成的“程序合成”过程而这个过程的本质就是分布式系统中最核心的“分布式共识”问题。无论Agent多聪明只要无法达成统一的共识协作就会陷入混乱。Kiran还专门论证了一个关键观点为什么自然语言指令一定是欠定义的因为唯一能给出精确、无歧义软件规约的方式就是写出代码本身。只要你还没落到代码层面任何自然语言指令都存在歧义Agent就必须在工作过程中做出自主的设计决策。而这些决策之间的冲突正是协作矛盾的根源。有人可能会提出疑问既然共识这么重要那用一个“管理者Agent”来管理代码仓库比如git repo不就能解决问题吗Kiran给出了否定答案这只是硬编码了一种并发控制方式并没有解决根本问题。比如一个Agent的设计决策被合并后其他Agent基于旧代码完成的工作该如何重新适配出现冲突时该如何协调很多时候部分Agent的工作会因为共识冲突而被完全丢弃这不仅降低了效率还会引发新的协作矛盾。FLP定理多Agent协作的“不可能三角”为了进一步说明多Agent协作的底层约束Kiran搬出了分布式系统领域的经典结论——FLP定理。这个定理由Fischer、Lynch、Paterson三位学者在1985年提出它明确指出在任何异步分布式系统中只要有一个节点可能崩溃就不存在一个确定性协议能保证所有正常节点在有限时间内达成共识。乍一看这个定理似乎和多Agent协作无关但只要我们仔细对应就会发现它的每一个前提都能在多Agent系统中找到对应场景。首先多Agent之间的消息传递是异步的一个Agent什么时候读取另一个Agent发来的消息取决于它自身的推理进度和工具调用情况没有固定的时间约束其次Agent的“崩溃”是完全可能发生的比如Agent陷入死循环的bash脚本比如不小心执行了pkill自己的指令又或者工具调用超时、永远不返回结果这些情况都相当于分布式系统中的“节点崩溃”。这就意味着无论Agent的模型多强大多Agent系统都不可能同时保证以下三个核心目标这就是多Agent协作的“不可能三角”第一个是安全性即产出的软件是正确的符合最初的指令需求第二个是活性即系统总能达成共识并正常终止工作第三个是容错性即部分Agent出现“崩溃”时系统仍能正常运行。我们只能在这三个目标中选择两个无法三者兼得。很多人可能会觉得Agent最终总会停下来所以“活性”是必然能保证的。但Kiran提醒我们“停下来”不等于“达成共识”。他在研究中见过一种非常常见的困境两个Agent来回翻转同一个设计决策A把方案改成一B又改回方案二循环往复直到系统被迫终止却始终没有达成统一的共识。这种情况就是典型的“有终止、无共识”违背了活性的核心要求。不过Kiran也给出了一个有意思的推论如果所有Agent都运行在同一台机器上那么通过ps \| grep claude这样的指令就可以充当某种“故障检测器”。早在1996年Chandra和Toueg就证明过只要有故障检测器哪怕这个检测器不完全可靠共识也有可能达成。这意味着给Agent增加一个“检查其他Agent是否存活”的工具或许能在一定程度上缓解协作困境提高共识达成的概率。拜占庭将军问题多Agent“误解”的硬边界除了FLP定理另一个制约多Agent协作的核心理论是Lamport在1982年提出的拜占庭将军问题。这个问题源于一个经典假设一群拜占庭将军围攻一座城市他们分散在城市周围只能通过信使传递消息其中部分将军可能会叛变发送虚假消息、误导其他将军最终导致攻城失败。而拜占庭将军问题要解决的就是“在存在叛变将军的情况下如何让忠诚的将军达成共识”。对于多Agent系统来说这个问题听起来似乎有些夸张毕竟Agent不会像人类一样“故意叛变”、搞破坏。但Kiran指出Agent对指令的误解在效果上和拜占庭故障完全一致。一个误解了需求的Agent虽然没有主观恶意但其产出的组件、做出的决策都会与其他试图正确执行指令的Agent产生冲突本质上就是在“对抗”整个协作系统。拜占庭将军定理给出了一个无法突破的硬边界在n个节点中如果拜占庭节点即误解指令的Agent的数量f gt; (n-1)/3那么共识就不可能达成。翻译成通俗的话就是如果你安排了n个Agent来开发一个系统只要超过三分之一的Agent误解了你的指令那么这次协作就注定会失败。更关键的是这不是靠更聪明的模型就能解决的问题。因为如Kiran之前所说自然语言指令本身就是欠定义的只要没有落到代码层面歧义就永远存在Agent的误解也就无法完全避免。哪怕模型再强大也只能降低误解的概率无法消除误解本身。不过Kiran也给出了实用的建议虽然我们无法提高“误解容忍度”的上限但可以通过外部验证手段降低误解发生的实际概率。这些外部验证手段包括测试、静态分析、形式化验证等它们的核心作用是把“拜占庭故障”转化为“崩溃故障”让误解了指令的Agent在执行过程中就被检测出来要么停下来要么被纠正而不是继续产出错误的组件、干扰其他Agent的工作。而崩溃故障在FLP定理的框架下显然更容易处理。Kiran在结论中特别强调他并不是说多Agent开发是不可能的事实上现在已经有很多人在用Agent写出能正常运行的软件。但问题在于这些成功案例大多是通过一些临时的、非系统化的机制隐式地解决了协作问题却很少有人去讨论这些机制的保证条件和失败模式。而分布式系统领域已经有40年的积累有精确的形式化描述、成熟的定理还有清晰的场景化技术选型规则。更聪明的Agent只能缩小算法中的常数却无法消除这些底层约束的上界。从理论到实践5109次实验揭示的协作真相如果说Kiran的研究从理论层面解释了“多Agent协作为什么难”那么Rothrock的实战研究则用大量数据回答了“多Agent协作该怎么做”。作为拥有35年经验的软件工程师Rothrock在8个项目中用自主AI Agent编写生产代码历时97天完成了5109次关卡检查最终提出了一套完整的多Agent协作设计与验证流水线框架。他的核心主张只有一句话可靠性不是模型的属性而是编排的属性。这句话听起来简单却直击多Agent协作的核心和分布式系统的核心思路高度一致。分布式系统的研究者很早就不再指望单个节点变得绝对可靠而是通过设计合理的协议让一群不可靠的节点组成一个可靠的系统。而Rothrock明确表示AI Agent本质上就是另一种“不可靠组件”。核心前提用户的意图是不可观测的在进入具体的实验数据之前Rothrock先划了一条非常关键的边界用户的意图是不可观测的它只存在于用户的脑子里。我们在多Agent系统中看到的所有产物无论是需求规约、开发计划、设计方案还是最终的代码都只是用户意图的“降维投射”每一次投射都会丢失一部分信息。这就意味着我们设计的所有验证关卡都无法验证“产物是否符合用户真正的意图”只能验证“这些投射之间是否一致”。比如代码是否和设计方案一致设计方案是否和开发计划一致开发计划是否和需求规约一致。但没有任何一个关卡能直接判断“这是不是用户真正想要的东西”。这也是为什么多Agent系统必须设置“上报路径”的原因当验证关卡无法判断产物的合理性时回到人类那里是唯一能从源头补回意图信息的办法。同时这也提醒我们如果需求规约本身就模糊、不完整甚至存在错误那么再完美的验证关卡也只会用完美的一致性产出错误的结果。流水线能保证的是对规约的忠实度而不是对用户意图的忠实度。关键发现Agent的错误是有结构的可预测的Rothrock在实验中设置了四道审查关卡分别是计划审查、设计审查、文件级代码审查、全局代码审查共进行了5109次检查其中1450次检查明确拒绝了Agent的产出。他对这些拒绝原因进行了分类发现了一个令人意外的结果87%的错误是可预测的而且具有明显的结构特征具体可以分为三类。第一类是遗漏错误占比49%主要表现为需求没有覆盖到、边界情况没有处理、必要的功能没有实现。比如开发食谱追踪APP时Agent忘了设计“食材过期提醒”功能或者没有处理“用户输入异常食材名称”的边界情况。第二类是系统性错误占比38%指的是同一类问题反复出现比如Agent总是在循环逻辑中出现语法错误或者总是忽略代码注释的要求。第三类是不一致错误占比12.7%主要表现为系统内部逻辑自相矛盾比如设计方案中规定“食谱按热量排序”但代码中却按时间排序。这个发现非常重要它意味着Agent的失败模式不是随机的而是有规律可循的。只要我们掌握了这些规律就可以对症下药设计针对性的验证关卡提高错误检出率。更有意思的是不同的验证关卡能抓到的错误类型也有明显差异。计划审查主要抓遗漏错误占比达到54%因为计划阶段的核心是覆盖需求最容易出现的就是“忘了做”设计审查主要抓系统性错误占比48%因为设计阶段需要确定统一的规范一旦规范出现问题就会导致后续反复出现同类错误。还有一个非常扎眼的数据文件级代码审查对“不一致”错误的检出率是0%。原因很简单文件级代码审查的“窗口太窄”只能看到单个文件的代码无法感知跨文件、跨模块的上下文自然也就发现不了跨上下文的逻辑矛盾。而这种不一致错误只有到全局代码审查阶段才能被有效检出——这也提醒我们多Agent协作的验证必须有“全局视角”不能只关注单个组件的正确性。核心权衡分解任务用“遗漏”换“不一致”在实验过程中Rothrock还发现了一个关键的权衡关系把任务拆得更细会把“不一致”类错误转化为“遗漏”类错误。这个结论看似反直觉实则符合分布式协作的底层逻辑。原因很直接当任务被拆解得足够细时每个Agent只需要关注自己负责的小任务上下文被大幅缩小。一个只看单个任务的Agent看不到兄弟任务的设计决策自然也就不太会产生跨上下文的逻辑矛盾。但与此同时由于任务拆分过细Agent很容易忽略任务之间的关联从而出现“忘了做”的遗漏错误。实验数据也完美支撑了这个结论11小时的发布弧任务拆分较细不一致错误率只有10%而更长的特性弧任务拆分较粗不一致错误率则达到了19.8%。显然这是一笔划算的交易——遗漏错误比不一致错误好检测得多。Rothrock表示一个简单的清单就能发现缺失的测试或没处理的边界情况但要发现不一致错误审查者往往需要同时在脑子里维护两套互相冲突的状态难度要大得多。这也和前文Kiran的结论相互呼应多Agent协作的核心是共识而拆分任务本质上是降低了共识的难度用可轻易检测的遗漏错误换取了难以检测的不一致错误。Trust Topology验证流水线的四个诊断属性为了让验证流水线更高效、更可靠Rothrock提出了“Trust Topology”信任拓扑的概念并总结了四个核心诊断属性用来评估验证关卡的有效性避免做无用功。第一个属性是重叠率。如果两道验证关卡80%的时间都在拒绝同一类问题那就意味着你实际上只拥有一道关卡只是重复执行了两遍。这是一种严重的资源浪费我们需要的是不同类型、不同视角的关卡形成互补而不是同一道关卡的重复执行。Rothrock引用了Brown等人的“Large Language Monkeys”研究来解释这一点多数投票在样本数增加到一定程度后会遇到明显的瓶颈当验证信号高度重叠时继续增加采样次数收益会非常低。第二个属性是验证放大。上游关卡会约束下游关卡需要检查的范围而且上游关卡的作用域越广拒绝率越高对下游的约束作用就越强。Rothrock的实验数据显示计划审查的拒绝率最高达到61%因为它覆盖了整个项目的需求和方向一旦计划被拒绝后续的设计、开发工作就不需要继续推进从而避免了资源浪费。反之如果上游关卡薄弱有问题的产出会一路传递到下游在整个流程中浪费大量资源。这也能解释Lightman等人在过程奖励模型研究中反复观察到的规律逐步验证往往比只看最终结果更有效在中间步骤设置关卡能直接限制后续步骤的产出范围减少错误传递。第三个属性是确定性天花板。确定性检查比如类型检查、lint检查、自动化测试等能给出硬保证确保代码的结构正确性而且成本极低几乎可以忽略不计。但这些检查也有局限性它们只能覆盖结构正确性无法保证语义正确性。比如代码能正常编译、通过lint检查、符合schema规范但可能仍然不符合用户的实际需求做了“无用功”。再多的算力、再多的采样也无法突破这个确定性天花板。而LLM验证器虽然能覆盖一部分语义缺口但没有形式化保证可靠性会分成两层确定性的地板可证明的结构正确和随机性的增益可估算的语义正确。第四个属性是活性约束。每增加一道验证关卡都会进一步缩小可接受输出的空间提高验证的严格性。但如果关卡设置过多、过于严格就可能导致99%的输出都被拒绝系统陷入无限重试的循环违背了活性要求。Rothrock的实验系统中首次通过率是55%他表示再多增加一道关卡就可能滑向“重试风暴”导致系统无法正常终止。三层验证架构让不可靠的Agent组成可靠的系统基于以上发现Rothrock设计了一套三层验证架构核心目标是让一群不可靠的Agent组成一个可靠的协作系统。这三层架构从低到高分别是确定性检查、随机性检查和人类判断每层都有明确的定位和作用。第一层是确定性检查包括测试、lint检查、类型检查等成本近零能提供可证明的结构正确性保证。这一层的核心作用是“低成本筛错”快速排除那些明显不符合规范、存在语法错误的产出避免这些错误进入后续流程浪费更高成本的验证资源。第二层是随机性检查主要是LLM审查成本中等提供概率性的语义正确性保证。这一层的核心作用是“进一步筛选”检查那些结构正确但可能存在语义错误、逻辑矛盾的产出同时对错误进行初步分类和处理。第三层是人类判断也就是我们常说的“Oracle”神谕成本最高但能提供最接近用户意图的ground truth。这一层的核心作用是“最终决策”处理那些LLM无法判断、存在严重歧义的问题补回用户意图的信息。这套架构能正常运行的关键是“oracle routing”神谕路由机制LLM审查者不仅负责验证还负责分流把问题分成“可以自动修复”和“需要人类决策”两类只有后者才上报给人类。如果没有这个机制人类就需要审查所有产出不仅成本极高而且效率极低这套架构也就失去了实际意义。更重要的是这三层之间的边界不是固定的而是可以动态演化的。当随机性关卡反复拒绝同一类错误时这个错误模式就可以被编码成确定性检查规则——上个月还需要LLM判断的问题这个月可能就变成了一条正则表达式或者一条lint规则从而降低验证成本提高效率。同样当人类反复做出同一类架构决策时这个决策也可以被编码成LLM规则减少人类的介入提高系统的自动化程度。这意味着多Agent系统的优化不是靠换更大的模型而是靠验证拓扑本身的演化——通过不断将随机性验证转化为确定性验证提高确定性天花板同时让人类介入的范围不断后撤实现系统效率和可靠性的双重提升。反直觉建议Build Bigger Verifiers, Not Bigger Generators基于97天的实证研究Rothrock给出了一个与行业直觉相反的核心建议与其把计算预算砸在更大的生成模型上不如投在验证器上。他解释说模型大小本质上是一个“活性参数”——验证关卡定义了什么是“合格的产出”更大的模型只是提高了一次通过验证的概率但无法解决协作中的结构性矛盾。从架构设计的角度来说更高效的做法是用小模型先提出初步方案然后用低成本的确定性关卡快速筛掉明显的错误只有通过筛选的幸存者再进入大模型验证器进行进一步审查。这样一来我们只用大模型的价格购买了几百token的评判服务而不是几千token的生成服务大幅降低了成本同时提高了验证效率。Rothrock引用了两项研究来支撑这个观点。Lu等人的研究发现用不同模型家族做验证比用同一个模型家族进行自我验证效果好得多。因为同家族的模型更容易接受与自己推理风格相似的错误答案验证的客观性和准确性会大打折扣。而Snell等人的研究则发现优化测试时计算资源在生成和验证之间的分配效果相当于把模型参数放大14倍——这意味着合理分配资源比单纯增大模型规模性价比更高。这也与Rothrock自己的Vibe Coding经验相符好的验证机制比强大的生成能力更重要。不过Rothrock也指出了一个目前尚未解决的开放问题Agent被验证关卡拒绝后再次尝试修改并通过验证的概率只有31%。这是整个流水线最薄弱的一环——Agent擅长生成新的方案但不擅长根据反馈修改错误。很多时候反馈不仅不能让Agent逼近正确答案反而会让它越改越偏陷入“修改-拒绝-再修改-再拒绝”的循环。这个问题还需要更多的研究和实践来解决。殊途同归分布式系统思维才是多Agent协作的破局之道把Kiran的理论研究和Rothrock的实践探索放在一起看我们会发现两个人虽然从不同角度出发却得出了完全一致的结论多Agent协作的核心是分布式系统问题而分布式系统领域40年来积累的理论、协议和工程经验正是破解多Agent协作困局的关键。Kiran用形式化方法告诉我们多Agent协作存在绕不过去的理论边界FLP定理揭示了“安全性、活性、容错性”的不可能三角拜占庭将军问题则给出了“误解容忍度”的硬上限。这些约束与模型的能力无关再强的模型也无法突破。我们能做的不是寄希望于下一代模型而是正视这些约束用分布式系统的理论来指导多Agent协作的设计。Rothrock则用5109次实证数据验证了分布式系统思维在多Agent协作中的可行性把可靠性从“模型属性”转化为“编排属性”通过设计多层、异构的验证关卡让不可靠的Agent组件组成一个可靠的系统。他还补充了很多Kiran理论框架中没有覆盖到的实践洞察用户意图不可观测所以需要上报路径Agent的错误有结构所以可以针对性设计验证关卡任务分解是在遗漏和不一致之间做权衡所以需要合理拆分任务验证拓扑可以动态演化所以可以通过优化验证机制持续提升系统效率和可靠性。现在很多人在做多Agent协作时还在走两条弯路一条是“临时凑活”用非系统化的机制解决协作问题却忽略了失败模式和保证条件导致系统可靠性不稳定另一条是“迷信模型”把所有希望都押在下一代模型上却忽视了协作的结构性矛盾最终陷入“模型越强协作越乱”的困境。而Kiran和Rothrock的研究给我们指了一条明路多Agent协作不需要“等下一代模型”也不需要“临时凑活”而是要回头向分布式系统学习。分布式系统研究者40年前就在解决“不可靠节点如何协作”的问题他们积累的FLP定理、拜占庭将军定理、共识协议、验证机制等都可以直接复用在多Agent系统中帮助我们突破协作困局。如果你也在做多Agent系统或者关注AI coding agent的发展这两篇文章都值得细细品读。Kiran的文章能帮你建立对多Agent协作边界条件的直觉避免陷入“模型万能”的误区Rothrock的文章则能给你一套可直接复用的设计与验证框架让你在实践中快速落地多Agent协作提高系统的可靠性和效率。