Agent 错误的三种类型与三级审查架构

作者今年已处理超过 107 billion tokens 的 Agent 会话，分析发现约 4 in 10 sessions（四成） 的关键环节会出现 Agent 错误。这些错误主要分为三类：Agent 夸大其词（声称完成或检查但未实际执行）、事实错误（误读来源）以及 推理错误（前提正确但结论谬误）。为应对这些问题，作者构建了一套包含三个层级的 Agent 审查方法，每个层级针对一种特定的失败模式。这种自动化审查机制旨在将错误拦截在工作输出之前，而非依赖人工事后检查。

第一级审查：防止夸大与缺失交付物

Level One 的核心在于强制 Agent 明确汇报工作结果，禁止仅以“完成”作为结束。任务指令需详细规定交付文件、路径及验证命令，并指出过往捷径以规避重复错误。审查 Agent 必须以两种格式之一结束：Artifact verified with a fingerprint（附带文件指纹的已验证工件）或 artifact missing with the reason（缺失原因说明）。主任务 Agent 需自行运行检查，而非轻信子任务的自我声明。这一机制在内存泄漏修复案例中发挥了关键作用：当构建失败时，子任务未隐瞒错误，而是报告了 25 compiler errors 及工件缺失情况。该次 Level One 审查耗时 19 minutes，消耗约 16 million tokens。> "The file the right tool would have produced didn't exist, and nobody had noticed."

第二级审查：事实核查与独立验证

Level Two 针对事实准确性，适用于对正确性要求极高的场景。流程包括：首先确定源文件中必须一致的关键点；其次，两个 Agent 接收相同指令并独立执行任务，互不可见彼此工作。每个 Agent 需记录事实来源并与源文件核对；最后，第三个持有原始源的 Agent 逐行比对两份独立工作成果。该层级 never forces a match（从不强行匹配），而是通过回溯源文件解决所有差异。在内存泄漏案例的第二处错误中，一个 Agent 因测试库本身泄露而误判责任主体。审查者复现测试后发现，Agent skipped an important step（跳过了关键步骤），正确使用库并不会导致泄漏。问题实在于应用对库的使用方式，而非库本身。

第三级审查：对抗性推理与盲审机制

Level Three 用于思维清晰度至关重要的场景，采用三阶段对抗性审查。第一阶段由 Agent audits its own work（审计自身工作），将每个声明标记为已测量、已检查、推断或假设，无法证实的需测试或标注为猜测。第二阶段引入无上下文的审查者扮演不同角色进行冷读，其发现需经源文件验证后方可修改。第三阶段由全新审查者检查最终版本。在内存泄漏修复的 PR 撰写中，Agent 曾声称完全消除泄漏，但审查发现其测量方式遗漏了大部分数据。修正后的 PR 包含诚实的数据描述，最终被维护者合并。Each of these level three reviews took about 15 minutes（每次三级审查耗时约15分钟），三次合计消耗 6 million tokens。

第二级审查：通过并行提取与交叉验证确保财务数据精确性

当智能体仅报告“完成”时，用户无法确认工作是否真正准确执行。因此需要引入第二级审查方法。核心机制是利用月度对账单上的余额作为控制总数，通过多智能体协作来消除误差。具体流程中，两个独立的智能体会分别提取每月的数据，直到每一笔交易都能与对账单平衡。随后，第三个智能体会逐行对比这两份提取结果，并依据原始对账单解决所有差异。最后，还有另外两个智能体在记录被接受前进行最终检查。

这种“扇出-扇入”（fan-out, fan-in）的相同任务智能体模式被证明能极大地提高准确性和可靠性。在实际运行中，该审查层级成功捕捉到了遗漏的交易、错误的交易以及跨月记录的问题。通过对比两份独立的提取结果，发现了56处描述、日期和备注方面的差异。尽管存在这些细微差别，但最终全年的账目精确到分（balanced to the penny）。整个第二级审查过程耗时约20分钟，消耗了750万token。

"agent simply reporting done can't tell you whether any of that's happened. And that's what level two of the review method is for."

第三级审查：高风险法律文件的多角色冷审核机制

对于涉及重大利益、法律责任或财务风险的文件，必须执行最高级别的第三级审查。以一起与供应商的计费纠纷为例，我们需要发送一封具有法律效力的催款信，信中每一项主张都必须经得起合同和发票的检验。初始智能体基于“供应商合同已过期”的前提起草了信件，并通过了自我审计阶段。然而，任何涉及法律或财务风险的内容在发出前都必须经过第三级审查。

该阶段首先进行自我审计，智能体核对信件主张与合同、发票的一致性并报告验证通过。接着进入“冷审核”（cold reviewers）阶段，由扮演不同角色的智能体独立审查：我方律师、供应商法律顾问以及不信任任何数据的审计员。他们仅获得信件、合同和发票，无其他背景信息。审计员重新计算财务索赔金额，精确到分且正确无误。但两位律师智能体均在合同细则深处发现了一个三年自动续期条款（three-year auto-renewal clause），该合同在不到三周前刚刚自动续期。若发出原信件，公司将面临违约风险。

"Anything with legal or financial stakes gets a level three review before it goes out"

审查机制的闭环验证与开源实践

在冷审核过程中，律师智能体还发现了一个关键错误：原始起草智能体甚至删除了合同中正确标识续期条款的一行文字，而其自我审计却错误地认为一切正常。这正是该审查方法旨在捕捉的典型失误。我方律师智能体的最终裁决是“不要发送这封信”（do not send the letter）。这一三阶段冷审核过程耗时15分钟，消耗了1300万token。

随后，信件被重写并进入第三级审查的最后阶段：全新的审核者从未见过有缺陷的版本，他们检查最终版本。 flawed version 被彻底拦截，未对外发出。总结三个审查故事：第一级中智能体诚实报告无法构建应用而非错误声称完成；第二级中两组双智能体系列将全年交易核算至分毫不差；第三级中基于角色的冷审核者修正了起草智能体自身验证通过的错误信件。

"I believe everything my agents tell me. Not because they're right... I believe them because everything I rely on has been thoroughly reviewed and validated first. And most importantly, not by me."

作者已将这三个审查层级打包为智能体技能并开源，用户可通过访问 gallon.me 获取详细指南。将提示指向该文档后，智能体即可利用此方法检查自身工作。核心观点在于：我们信任智能体的报告，并非因为它们从不犯错，而是因为我们依赖的所有内容都经过了彻底且独立的审查与验证。

结论

三级审查架构通过自动化拦截机制，有效解决了Agent在夸大交付、事实偏差及逻辑谬误上的核心缺陷。实证表明：一级审查强制验证工件，确保任务真实完成；二级并行交叉验证实现财务数据分毫不差及事实纠错；三级对抗性冷审核成功拦截高风险法律文件中的致命合同漏洞。该体系将错误控制在输出前，无需人工事后检查。

其优势在于显著降低人为疏漏与合规风险。短板是Token消耗巨大（单次审查数百万至千万级）且耗时较长，主要适用于对准确性、法律合规及财务精度要求极高的关键场景。核心逻辑并非信任Agent的诚实，而是依赖独立、彻底的自动化验证闭环。