2026 年一开年，AI 工程圈被两股相反的力量挤在中间。一边是 Kimi K2 的 Agent Swarm spawn 300 个 agent 协同工作 4000 步，Moonshot 公布的 benchmark 上 BrowseComp 从 78.4% 拉到 86.3%；Claude Code 的 Dynamic Workflow 用 11 天把 Bun 从 Zig 移植到 Rust，75 万行代码，99.8% 测试通过。另一边，MAST 分类体系分析了七个主流框架上的 1,600 多条执行轨迹，78.7% 的失败来自规格设计和协调问题；Gartner 预测到 2027 年底超过 40% 的 agentic AI 项目会被取消。
这两组证据同时成立。矛盾不在多智能体行不行，在为什么同一套模式有些地方跑出了惊人的结果，有些地方连最基本的可靠性都保不住。答案不在 agent 的数量或质量上，在一个更隐蔽的机制里。
这里说的不是犯罪意义上的洗钱。它指的是一个机制：错误假设经过多层 agent 处理后，每一步没有拦截它，而是让它看起来更可信了，经过的处理步骤越多，产出看起来越像经过了严格审查，和洗钱把不干净的钱经过多层交易后看起来像合法收入是同一种结构。
先看一个具体的 bug。Anthropic 四月的 postmortem记录了一个通过了所有自动化检查、人工代码审查、单元测试、端到端测试和 dogfooding 的缺陷，花了一周多才被发现。原文是”made it past multiple human and automated code reviews, as well as unit tests, end-to-end tests, automated verification, and dogfooding”。写这段代码的 agent 做了一个错误假设，这个假设经过了至少五道处理工序：agent 自己写、agent 自己审、人审、自动化测试、端到端测试。全部通过，全部没有拦截到它。
错误假设能穿过审查链存活下来，这件事单智能体和多智能体都会碰到。但多智能体系统把问题拉高了至少一个量级。单智能体的场景里，错误假设藏在一次输出里。人审的时候，如果对这个领域足够熟悉，有可能在假设和不一致的事实之间发现裂缝。多智能体的场景里，错误假设不只是在一次输出里藏着，其他 agent 拿到这个输出以后，在上面继续建东西。Agent 2 基于错误假设写了一个 middleware。Agent 3 根据 middleware 的接口写了测试。Agent 4 补了文档。人审的时候，看到的是一个自洽的系统：middleware、测试、文档，互相印证，各自都对得上。它们对得上的原因不是假设本身正确，是它们全都基于同一个错误的根。这不是一个隐藏在输出里的缺陷。这是一个看起来自洽、实测自洽、文档也自洽的空中楼阁。
想象一个错误假设。一个 agent 基于它生成了输出。第二个 agent 拿到这个输出，做了一次重新组织、增加了一些引用、调整了格式。第三个 agent 基于结构化后的版本做分析，产出了一个带表格和分类的结论。你作为人，看到了第三个 agent 的输出：格式齐整、分类清晰、引用丰富。你做出判断：这套东西经过了三个 agent 的处理，应该是有依据的。
问题在于，第二个 agent 和第三个 agent 都没有验证第一个 agent 的假设是否正确。它们只是拿了假设，加工了呈现。第一个 agent 的原始假设是什么、它的上下文里缺了什么、它当时做了一个什么样的跳步，这些东西在第二和第三步里不是被纠正了，是被抹掉了。每一步清洗都让输出离原始的推理缺陷更远，离一份看起来可信的成品更近。这个过程把它叫洗钱：处理步骤越多，产出看起来越可信，但它和真相的距离没有变近。
Claude Code Dynamic Workflow 的验证机制提供了一个精确的例子。它的文档描述是”agents address the problem from independent angles, other agents try to refute what they found, and the run keeps iterating until the answers converge”。这听起来像科学方法。但 workers 和 verifiers 用的是同一个模型。同一个训练过程中产生的盲区被所有 agent 共享。当 verifier 的推理偏见和 worker 一致时，它检查的不是假设本身，是假设的表达是否自洽。自洽的输出在多轮交叉后变得更紧凑、更自洽、更一致，也更像是对的。但自洽不是正确，一致性不是独立性。在这个系统里，每多一轮交叉只多了一道洗钱工序。
这个机制解释了 MAST 分类体系的深层含义。78.7% 的失败被归因于规格问题和协调失效，但这个分类没有区分两件不同的事。
一种是 agent 没有理解彼此的意图。你吩咐第一层去搜索某个关键词，它搜了，它理解了。第二层理解错了，去读了另一份文档。这是纯粹的协调失败。
另一种是 agent 理解了彼此的意图，但在传递过程中把原始假设的不确定性洗掉了。第一层说”我猜可能是这样”，第二层接过来直接说”这是这样”，第三层基于”这是这样”做了一个分类。每一步都走了正确的流程，每一步都丢失了最初那个”可能”字。
在自然语言自由对话的多智能体系统中，第二种情况是默认行为。每个 agent 接到的都是前一个 agent 的总结，不是前一个 agent 的推理过程。总结去掉的是假设的脆弱性，“我猜可能是这样”。留下的是假设的硬度，“这是这样”。
Oh My OpenAgent 的 Sisyphus 框架是少数在设计层面对这件事做了防御的系统。它在三种不同的模型上跑三层独立审查：Prometheus（Claude Opus）做计划，Metis（Claude Opus）做 gap detection，找 Prometheus 漏掉的东西，Momus（GPT-5.2）做最后的计划验证，拒绝不满足标准的计划且没有重试上限。这里的设计意图不是让三个 agent 达成共识，而是利用三种不同模型之间必然存在的判断差异，在计划进入执行之前暴露被单一模型漏掉的假设缺陷。Sisyphus 没有依赖”多个 agent 互相验证”来保证质量，它依赖的是不同模型的不同盲区来增加假设被拦截的概率。
但即使这样，它也没有保证 Momus 的审查一定比 Prometheus 的计划更正确。它只是在错误假设进入执行层之前多放了一道不同材料的过滤网。
把洗钱机制翻译成工程语言：每个架构都有一个盲区距离：一个错误假设从产生到被人的眼睛看到之间，经过了多少步中间处理。这个距离不是技术细节，是系统的完整性上限。
Kimi Swarm 的盲区距离是最长的。RL 训练的协调器拆解任务、分派 agent、合并结果，人只在开头给目标、在结尾看成果。一个 300-agent、4000-step 的 swarm 里，错误假设从产生到被人看到，中间隔着整个 swarm 的全部工序。每道工序都在让假设离原始推理更远，离成品更近。当最终结果出错时，人需要重建整个 swarm 的上下文才能定位问题，而协调器的 RL 决策逻辑不可解释，GitHub issues里报告的无限循环只是一个症状。
Claude DW 把盲区距离缩短了一步。人在运行前审核脚本。假设的缺陷如果在脚本逻辑层面可见（交叉验证太弱、分支条件太模糊、任务分解忽略了一类边缘情况），人有机会在这里拦截。但它依赖两个条件。第一，人必须有足够的认知带宽来认真审核一个 Claude 写的 JS 编排脚本，而这个脚本本身也是 Claude 写的，也可能含有错误假设。第二，如果缺陷不出在脚本逻辑层而出在 worker 执行层的交叉验证里（同一个模型 spawn 的 agent 共享同样的推理盲区），脚本审核挡不住。Claude DW 的设计只是把盲区距离从”整个 pipeline”缩短到了”脚本审核之后的 worker 层”。
Pi 的盲区距离最短。Mario Zechner 的设计去掉了编排层、去掉了 sub-agent 黑盒、去掉了 plan mode。四个工具，不到 1000 token 的 system prompt。用户在每一步都能看到 agent 的 read、bash、edit。错误假设一旦产生，暴露的速度最快，前提是人真的在看。Pi 的 trade-off 不是架构层面的，是人机节奏层面的：盲区距离为零，但人的参与频率最高。
这三个系统之间没有绝对的好坏。盲区距离短的系统对人的认知投入要求高，对人的质量依赖也高。盲区距离长的系统依赖中间层的拦截质量，而当中间层在洗钱而不是拦截时，系统产出的不是更可靠的结果，是看起来更可靠的结果。
MAST 分类体系里 78.7% 的失败，本质上衡量的不是协调质量，是盲区距离。当 agent 之间用自然语言自由对话时，每个交接步骤都是一次隐式的洗钱，总结前一个 agent 的意图，去掉它的不确定性，把它变成下一个 agent 可以继续加工的材料。这个过程不是设计缺陷，是自然语言通信的固有行为。你不需要设计一个洗钱机制来洗钱，你只需要让 agent 用自然语言交接就够了。
你的 pipeline 图里，两个人类 checkpoint 之间最长的处理链有几道工序？把这个数字找出来。这个数字是你的架构对错误假设的放大倍数。
找这个数字的时候，不要把自动化测试、lint、类型检查算作拦截。自动化测试拦的是代码行为偏差，不是假设偏差。如果 agent 基于一个错误的前提写了正确的代码，测试通过。测试过不了的是实现错误，不是前提错误。拦截前提错误需要的是不同于执行层的判断，不同模型的独立审查、人的介入、或者把假设本身显式化为一个可以被验证的中间产物。
如果你当前的工作流是”让 agent 自由跑一段，然后人检查一次结果”，你的盲区距离就是这个跑的过程的步骤数。如果一段跑包含规划和执行两层，这两个 agent 之间靠自然语言交接，那它差不多是 2。如果不只一个 worker，多个 worker 的产出之间还互相引用了，那它每多一层就多一道工序。在 Claude DW 的脚本审核模式下，如果你的脚本审核是认真的，盲区距离可以压到 worker 并行执行的那一层。脚本逻辑层面的缺陷在审核时被拦截，worker 层的假设偏差仍然可能穿过。在 Sisyphus 的模式下，多层不同模型的独立审查把拦截率推到上限，但你得接受额外的 token 成本和更长的计划阶段。
这些选择不是技术路线之争，是在你的具体场景里回答一个具体问题：在 agent 的工作流里，错误假设通常出现在哪一步，最快的拦截方式是什么，以及你愿意为这个拦截付多少代价。
如果错误假设经常在你给 agent 的任务描述里就出现了，你说得太模糊，agent 补了一个不存在的约束，那多 agent 互相讨论只会加速洗钱。你需要的是一个能逼你澄清需求的机制，比如 Prometheus 的 interview 模式，或者 Pi 的”每一行都可见”让你在 agent 第一次走偏时就看见。如果错误假设经常出现在 agent 的执行过程中，它理解了你的目标但选了错误的实现路径，那让另一个不同模型的 agent 来审它的中间产物可能有用。如果错误假设很少，你的 harness 已经很成熟，agent 的输出直接可验证，那你不需要加任何中间层，单 agent + 强 harness 就是最优解。
有一种情况需要特别小心：你的多智能体系统在 demo 里表现很好，但上了生产就开始出一些说不清楚的错，而且这些错每次都不一样。检查一下你的中间层是拦截还是洗钱。如果一个 agent 的输出在传给下一个 agent 之前经过了自然语言总结，去掉了限定条件和不确定性表述，那这个总结不是为了帮助下一个 agent 做更好的判断，是为了让下一个 agent 不需要重建上一个 agent 的全部上下文。省上下文是对的，如果你省略掉的恰好在事后需要被追溯的东西，这个 claim 的置信度、这条路径的备选方案、这个假设的边界条件，那你不是在省上下文，你是在烧证据。
多智能体的讨论回到了一个最基础的问题上：你的 pipeline 的每一步，是在让错误更显眼，还是在让错误更好看。显眼的错误会被人抓住。好看的错误会被 release。