Agent 越用越"自信",却越来越错——EDV 用三权分立堵住经验学习的自我确认陷阱
你有没有遇到过这种情况:一个 LLM 智能体刚部署的时候挺机灵,跑着跑着却开始反复犯同一个错,而且犯得理直气壮。你去翻它的记忆库,发现里面赫然记着一条"成功经验"——可那条经验本身就是错的。
这事我自己踩过坑。当时做的是一个带长期记忆的工具调用 Agent,思路很朴素:让它自己执行任务、自己总结哪步走对了、自己把"成功"的做法写进记忆下次复用。听起来无懈可击对吧?结果上线一段时间后,某些任务的成功率不升反降。排查了半天才意识到问题出在哪——它把一条"看起来很合理但其实是错的"轨迹当成功经验存了下来,然后每次遇到类似任务都去检索它、强化它。错误就这么滚雪球了。
这篇 6 月底挂出来的论文(arXiv:2606.24428)给这个现象起了个挺贴切的名字——自我确认陷阱(Self-Confirmation Trap)。更重要的是,它给了一个我看完觉得"对,就该这么干"的解法——EDV,一个 Execute-Distill-Verify 的三段式框架。
核心摘要
经验驱动的自我进化,是 LLM 智能体在开放世界里持续变强的关键。但现在主流的经验学习方法几乎都是单智能体闭环:同一个 Agent 既当运动员(执行任务)、又当裁判(判断哪些该写进记忆)。问题在于,执行和评估用的是同一个推理过程、同一个视角——一条内部自洽但客观错误的轨迹,从 Agent 自己的角度看就是"我做对了",于是被当成功经验存下来,后续不断被检索复用,错误持续累积。这就是自我确认陷阱。
EDV 的破局思路是三权分立:执行(Execute)阶段让多个异构 Agent 并行探索同一任务、产出多样化轨迹;蒸馏(Distill)阶段派一个第三方 Agent 对这些轨迹做横向对比、提炼候选经验,避开执行者的自我美化;验证(Verify)阶段由执行组用共识机制投票,只有通过的经验才写入共享或私有记忆。三个角色一解耦,经验学习就从"孤独的自我反思"变成了"协作式构建 + 入库前过滤"。
效果上,在 τ²-bench、Mind2Web、MMTB 三个长程基准上 EDV 都稳定超过强基线:τ²-bench 平均 Pass@1 做到 86.6(对比 Router 的 83.5、单模型无记忆的 76–80),MMTB 总分 58.10。更狠的是效率——RETAIL 子集上平均推理 token 消耗比 ReasoningBank 降了 24.5 个点,还做得更好。
我的判断:这篇论文最值钱的地方不在于"多智能体协作"这个壳——这个大家都在玩——而在于它把多智能体从"提升任务求解"挪到了"提升经验构建本身的可靠性"上,并且用一个污染实验硬核地证明了自我确认陷阱是真实存在、真会造成损失的。这不是又一篇蹭 Agent memory 热度的工作。
论文信息
- 标题:Escaping the Self-Confirmation Trap: An Execute-Distill-Verify Paradigm for Agentic Experience Learning
- 作者:Shiding Zhu, Yudi Qi, Yajie Wang, Jiaze Li, Chao Song, Yaorui Shi, Yibo Miao, Hanqi Gao, Kai Zhang
- arXiv:2606.24428 (cs.CL),2026 年 6 月 23 日提交
- 代码:https://github.com/shidingz/EDV
问题在哪:运动员兼裁判,这事本身就不靠谱
先把"经验学习"这件事讲清楚。一个 Agent 在环境里跑任务,会产生一条轨迹——状态、动作、观察交替出现的序列。跑完之后,我们希望它能从中提炼出可复用的经验,存进记忆,下次遇到类似任务直接检索来用。这套思路在 ReasoningBank 这类工作里已经比较成熟了。
但论文一上来就盯住了一个被大家忽略的结构性缺陷:在缺乏明确 ground truth 的开放世界里,执行和评估被耦合在了同一个推理过程中。
什么意思?Agent 跑完一条轨迹,然后还是这个 Agent 来判断"这条轨迹算不算成功、值不值得写进记忆"。问题是,如果这个 Agent 在执行时就有某种系统性的认知偏差,那它在评估时大概率会复现同样的偏差——它看不出自己错在哪,因为错的恰恰是它的"看法"本身。
论文把这个用一个条件概率讲得很干脆。设 \(c(\tau) \in \{0,1\}\) 是轨迹的客观正确性,\(v_{\pi_\theta}(\tau) \in \{0,1\}\) 是 Agent 自己的批准决策。单智能体闭环里,执行和评估都用同一个策略 \(\pi_\theta\),于是:
这个概率会被显著抬高。翻译成人话:一条客观上错误的轨迹,被 Agent 自己盖章"通过"的概率高得离谱。 一旦写进记忆,它就会被反复检索、复用,错误就持续累积。
论文举了个特别具体的例子,我觉得比公式更能说明问题。一个航班改签任务:单智能体系统反复尝试用旅行凭证(travel certificate)去支付,但它没识别出一个隐藏约束——凭证根本不能用于修改已有预订。可它每一步的动作在局部上都"看起来连贯",所以从它自己的视角这条轨迹合情合理,于是在自我验证里被判成功、存进记忆。结果呢?以后每次遇到类似的改签任务,它都会重新掉进这个坑。
这就是关键。问题不在于 Agent 蠢,而在于它没有一个外部视角来戳破自己的自洽幻觉。
下面这张图把传统做法和 EDV 的差别摆得很清楚:
图1:上半部分是现有做法——单个 Agent 跑出轨迹后自蒸馏(Self-Distillation)直接写入记忆,整条链路是一个人闭环。下半部分是 EDV——一个异构 Agent 池(图中能看到不同厂商的模型图标)并行产出多条轨迹(Traj. 1~n),经过蒸馏得到候选经验(Candidate Experience),再经过 Verify 这道关卡,最后才分别写入共享记忆库(Shared Memory Bank)和私有记忆库(Private Memory Bank)。注意那朵带购物车的"Verify"云——它就是堵住错误经验入库的闸门。
所以论文真正的命题不是"怎么收集更多经验",而是:怎么在经验写进记忆之前,就把错误和噪声过滤掉? 进一步,它问了一个挺有意思的问题——多智能体协作,能不能不只是用来把任务做得更好,而是用来让"经验构建"这件事本身更可靠?
方法核心:Execute-Distill-Verify,三个角色各管一摊
EDV 的整体设计可以拆成两层:经验构建阶段(离线,把高质量经验攒出来)和推理使用阶段(在线,新任务来了检索经验来用)。
先说一个贯穿始终的设定:异构 Agent 池 \(\mathcal{A} = \{A_1, \dots, A_K\}\),每个 Agent 用不同的基座模型或提示策略。对每个任务,EDV 随机采样一个子集当执行组,再随机挑一个当蒸馏 Agent。这个"随机"很重要——它避免了某个 Agent 长期固化成某种角色、带来持久的偏置。
整体流程看这张图:
图2:左侧粉色区是 STAGE 1 经验构建——Agent x/y/z 循环协作,产出三样东西:Ability Matrix(能力矩阵)、Shared Memory Bank(共享记忆库)、Private Memory Bank(私有记忆库)。中间蓝色区是 STAGE 2 推理使用的"选择与检索"——先用 Model Selector 根据能力矩阵匹配最合适的求解模型,然后判断 Match Found?有就直接取共享记忆,没有就降级去查私有记忆。右侧是最终基于检索到的记忆做推理输出。整套设计的精妙之处在于:构建是离线、可并行的,在线只需轻量查找。
Execute:让异构 Agent 并行铺开解空间
执行阶段构造一个异构执行组 \(\mathcal{A}_{\text{exec}}\),组里每个 Agent 独立和环境交互,各自产出一条候选轨迹:
这一步的意义,论文说得很到位:它要的不是简单地多试几次,而是用异构性去暴露不同的成功/失败模式。 同一个任务,GLM 可能走通了一条路、MiniMax 可能卡在另一处——这种差异本身就是信息。你想想看,如果三个 Agent 都是同一个模型,那它们大概率会犯同样的错,多试几次也是白搭。异构才是关键。
Distill:派个"第三方"来做横向对比
这是我觉得整个框架里最聪明的一刀。蒸馏阶段引入一个第三方蒸馏 Agent \(A_{\text{distill}}\),它不参与执行,只负责对执行组产出的那一堆轨迹做跨轨迹对比,输出候选经验集 \(\mathcal{E}_{\text{cand}} = \{e_1, \dots, e_m\}\)。
注意这里和传统做法的本质区别:传统的自蒸馏是执行者复述自己那条"最佳"轨迹——但它有选择偏置,它会美化自己的决策。而第三方蒸馏 Agent 不复述任何单条轨迹,它做的是识别多条轨迹之间的有用差异,把这些差异提炼成可泛化的经验。这就把"执行者中心的自我总结"换成了"中立第三方的对比分析"。
图3:左侧 Execute——Agent x 和 Agent y 在同一个环境(ENV)里各自跑出多条轨迹(Traj. x₁~xₙ、y₁~yₙ),图里能看到轨迹被标了对错(✓/✗)。中间 Distill——Agent z 作为第三方,对所有轨迹做对比分析,一边做 Experience Generation 产出候选经验 e₁~eₘ,一边 Update Ability Matrix(更新能力矩阵)。右侧 Verify——候选经验经过那朵购物车云的共识投票,根据投票结果分别写入 Agent X 的私有库、Agent Y 的私有库,或者大家都认可的共享记忆库。这张图把"谁干什么、信息怎么流"讲得最透。
Verify:共识投票,默认拒绝
这是 EDV 真正中断自我确认陷阱的那道关卡。验证组就等于执行组(\(\mathcal{A}_{\text{verify}} = \mathcal{A}_{\text{exec}}\)),每个执行者基于自己的执行上下文,对每条候选经验给一个二元判断 \(V_j(e) \in \{0,1\}\)。
然后是一套严格的默认拒绝(default-reject)策略:
- 全票通过 → 写入共享记忆库(这是大家都认可的通用经验)
- 部分通过 → 写入对应 Agent 的私有记忆库(只对特定 Agent 有效)
- 其余情况 → 直接丢弃
这个设计的潜台词是:宁可错杀,不可放过。 默认拒绝意味着只有真正经得起多方检验的经验才能入库。第三方蒸馏已经过滤了一道,共识验证再补一刀,残余的错误经验在这里被拦下。
推理时:能力矩阵 + 分层检索
构建好的记忆怎么用?新任务 \(q_{\text{test}}\) 来了,系统先查 Ability Matrix 选出最合适的求解器(哪类任务谁更擅长),然后做分层检索——先查共享记忆库,不够再查这个求解器的私有记忆库。检索到的经验拼进任务上下文,指导后续推理。
整个在线流程没有多智能体协调的开销,就是选模型 + 查记忆,很轻。
实验:数据说话,而且有几个点我得单独拎出来
实验设置
三个长程基准:τ²-bench(复杂约束求解,双控制对话环境)、Mind2Web(Web 交互)、MMTB(多工具任务执行)。异构模型池是 Mimo-V2-Flash、GLM-4.7-FP8、MiniMax-M2.1 三个。构建记忆时随机抽两个组执行组、另一个当蒸馏 Agent。
基线设计得挺讲究,这点我要夸一下——它不只是和"无记忆"比:
- NM(No Memory):单模型裸跑,测内在能力
- RB(ReasoningBank):代表性的单智能体记忆学习方法,这是主要对手
- Judge:推理时用 LLM-as-Judge 裁决多个异构输出
- Router:推理时用能力矩阵选最合适的模型
后两个尤其关键——它们能回答一个尖锐的质疑:EDV 的提升到底是因为"经验构建更好",还是单纯因为"用了多个模型 + 推理时挑一个"? 如果 EDV 只是赢在模型多,那它应该和 Judge/Router 差不多才对。
主结果:τ²-bench 上甩开 Router 3 个点
| 方法 | 骨干模型 | AIRLINE | RETAIL | TELECOM | Avg. |
|---|---|---|---|---|---|
| NM | Minimax-M2.1 | 61.5 | 82.2 | 85.5 | 76.4 |
| NM | Mimo-V2-Flash | 64.5 | 79.2 | 91.7 | 78.5 |
| NM | GLM-4.7-FP8 | 64.0 | 78.1 | 96.6 | 79.6 |
| RB | Minimax-M2.1 | 66.0 | 83.3 | 87.7 | 79.0 |
| RB | Mimo-V2-Flash | 64.0 | 83.3 | 94.7 | 80.7 |
| RB | GLM-4.7-FP8 | 66.0 | 82.5 | 97.2 | 81.9 |
| Judge | Ensemble | 66.0 | 84.7 | 93.9 | 81.5 |
| Router | Ensemble | 68.0 | 85.2 | 97.2 | 83.5 |
| EDV (Ours) | Ensemble | 72.0 | 88.6 | 99.1 | 86.6 |
读这张表我注意到两件事。第一,EDV 平均 86.6,比最强的 Router(83.5)还高 3.1 个点——这说明它的优势不是来自模型集成本身,因为 Router 已经用上了同样的模型池。多出来的部分,只能归因于经验构建质量。第二,RB 这个单智能体记忆方法,平均也就 79–82,比裸模型(NM)提升相当有限,有些情况下甚至接近——这恰恰暗示了单智能体经验学习的天花板。
Mind2Web 上的结果更有意思,因为它带了理论上界。比如 Cross-Task 设置,EDV 做到 EA 48.62 / AF1 63.10 / SSR 43.17 / SR 4.76(SR 上界是 24.21);Cross-Website 是 EA 44.79 / AF1 55.64 / SSR 36.56;Cross-Domain 是 EA 43.39 / AF1 56.38 / SSR 39.57。三种泛化设置下都稳定优于强基线。坦率讲,SR(完整任务成功率)这个绝对数看着不高,但 Mind2Web 本身就是出了名的难,且有检索约束,这里更该看的是相对提升。
MMTB 上 EDV 总分 58.10,同样压过 Router(55.96)、Judge(54.79)。单工具子项 A_sgl 做到 84.38,并行多工具 A^P 从基线的十几二十提到 37.50。
三个我觉得最能打的实验
第一,记忆质量审计(5.3)。 这个实验我特别喜欢,因为它不绕弯子,直接人工打分(5 分制,τ²-bench RETAIL):
| 维度 | RB | EDV | 方向 |
|---|---|---|---|
| Groundedness/Correctness | 3.72 | 4.41 | 越高越好 |
| Actionability | 3.58 | 4.32 | 越高越好 |
| Specificity | 3.64 | 4.27 | 越高越好 |
| Noise/Hallucination | 1.21 | 0.63 | 越低越好 |
| Potential Harm if Reused | 1.08 | 0.51 | 越低越好 |
最关键的是后两行:EDV 写入记忆的噪声/幻觉降了一半,复用时的潜在危害也降了一半。这直接坐实了"EDV 在源头过滤了低质量信息"这个核心主张。光说成功率高没用,得证明记忆质量本身真的更好——这个实验做到了。
第二,记忆污染实验(5.4)。 这是全文我觉得最硬核的一招。作者故意往 RB 的 RETAIL 记忆里注入了占总量 10% 的"错误但内部连贯"的经验(比如错误的支付规则)。结果?RB 在 RETAIL 的 Pass@1 从 82.5 直接掉到 77.2,掉了 5.3 个点。
这个实验的妙处在于,它把"自我确认陷阱的危害"从一个理论担忧变成了一个可测量的损失。10% 的污染就能让性能崩这么多——而单智能体方法恰恰最容易产生这种污染。论证闭环了。
第三,效率(5.6)。 这点反直觉但很重要:你可能觉得多智能体框架肯定更贵,但 EDV 的经验构建是离线、可并行的,在线推理时一点多智能体协调开销都没有。更妙的是,因为记忆质量高,推理反而更省——RETAIL 上平均 token 消耗比 RB 降了 24.5%,还做得更好。本质上它把成本从"反复的在线搜索"转移到了"高质量的离线经验构建"。
消融:每一刀都砍在该砍的地方
渐进式范式消融(Table 4,RETAIL,Pass@1)是我读得最仔细的一张表,因为它逐步拆解每个设计带来多少收益:
| # | 配置 | 执行 | 蒸馏 | 验证 | Pass@1 | Drop |
|---|---|---|---|---|---|---|
| 1 | Basic SA | 1 | Self | None | 83.3 | -5.3 |
| 2 | SA + Self-Verify | 1 | Self | Self | 83.2 | -5.4 |
| 3 | SA + Indep. Verifier | 1 | Self | External | 84.5 | -4.1 |
| 4 | MA + Self-Distill | 2 | Executor | Executor | 85.9 | -2.7 |
| 5 | MA + Third-Party Distill | 2 | External | Distill | 87.1 | -1.5 |
| 6 | EDV (Full) | 2 | External | Executor | 88.6 | — |
这张表讲了一个挺完整的故事:
- 自检救不了自己。给单智能体加显式自我验证(行 1→2),Pass@1 从 83.3 反而微降到 83.2。自我确认陷阱是单智能体的结构性问题,自己监督自己等于没监督。
- 光解耦验证还不够。给单智能体配独立验证器(行 3),只涨了 1.2 分到 84.5。为什么?因为只有一条轨迹,参考太少了——验证器没东西可对比。轨迹多样性是前提。
- 多智能体执行 + 第三方蒸馏才真正放出价值(行 4→5)。执行者自蒸馏(85.9)因为选择偏置浪费了大部分信息增益,换成中立第三方蒸馏(87.1)才把跨轨迹的可泛化经验提取出来。
- 共识验证是最后的质量守卫(行 5→6,87.1→88.6)。第三方也有认知盲区,执行组的一致投票再过滤一遍残余错误。
四个机制环环相扣,缺一个掉一截。这种消融做得很诚实,没藏着掖着。
组件消融(Table 5)则验证了 Ability Matrix(移除掉 2.0 分)和记忆分层(只用共享掉 2.9 分、只用私有掉 2.7 分)都是必要的。论文还给了记忆使用的细账:共享记忆检索率 72.3%、每次命中带来 3.2% 增益;私有记忆覆盖 31.8% 的任务、每次命中 1.8% 增益。私有记忆专门补那些"近三分之一任务里的个性化边缘 case",扁平结构替代不了。
附录里还有几个值得一提的数:训练收敛上,RB 在第 2 个 epoch 后就停滞甚至下降(0.830→0.815),而 EDV 一路涨到 Epoch 4 的峰值 0.909;检索经验数量上,RB 在 1 条经验时见顶(0.825)后被低质量经验拖累退化到 0.793,EDV 则单调上升到 3 条时的 0.886。这个对比特别能说明问题——RB 不是不会用经验,是它的经验本身有毒,越用越糟。
我的判断:好在哪,以及哪里还能再追问
先说我被打动的地方。
这篇论文的核心洞察——经验学习的瓶颈不在数量而在构建可靠性——我觉得是真的抓到了点子上。现在一堆 Agent memory 的工作都在卷"记得更多、检索更准",但很少有人正面回答"万一你记的东西本身就是错的怎么办"。EDV 把"执行/蒸馏/验证"三权分立的设计,本质上是给经验构建引入了外部视角和制衡,这个思路是对的,而且那个污染实验把危害量化得很扎实,不是空谈。
第三方蒸馏那一刀尤其漂亮。它精准地切中了自我总结的选择偏置——你让运动员复盘自己的比赛,他总会美化;你让一个没下场的第三方来对比所有人的录像,反而能看出真问题。
但有几个地方我会打个问号。
一是成本结构。 离线构建虽然可并行,但毕竟要跑多个异构大模型、多条轨迹、还要蒸馏和投票,这个构建成本到底多大?论文强调在线省 token,但没太细讲构建端的总开销。对于任务分布稳定、值得一次性攒经验的场景这没问题,但如果任务长尾、经验复用率低,这笔离线投入未必划算。
二是异构性的依赖。 EDV 的有效性高度依赖 Agent 池的异构程度——消融里也说了,同质化的多智能体等于白搭。但"凑齐几个能力相当又互补的异构模型"这件事本身有门槛,而且模型选择对结果的影响有多大,论文没做这方面的敏感性分析。换一套弱一些、或者同质化高一些的模型池,EDV 的优势还剩多少?这个我挺好奇。
三是共识机制的保守性。 默认拒绝 + 全票才进共享库,质量是有了,但会不会过滤掉一些"少数派正确"的经验?也就是只有一个 Agent 走通了一条非常规但正确的路,其他 Agent 因为没走过而投了反对票——这条宝贵经验就被丢了,或者只能进私有库。论文里 τ=0.9 时性能下降也侧面印证了"过严会误杀"。这个 precision/recall 的权衡,还有调优空间。
跟同期工作比,EDV 的定位我觉得是清晰的:它不是在 memory 检索或存储结构上做文章(那是 ReasoningBank 那条线),而是在经验生成的可信度这个更上游的环节切入。这个角度相对新,工程上也好落地——三个阶段都是模块化的,你完全可以在现有的 Agent memory pipeline 上加一道第三方蒸馏 + 共识验证。
收尾:如果你也在做带记忆的 Agent
实话说,看完这篇论文,我第一反应是想回去把我那个翻过车的 Agent 改一改。如果你也在做经验/记忆驱动的智能体,有两个点我觉得可以直接借鉴:
第一,别让执行者自己当裁判。哪怕你没条件搞多个异构模型,至少可以引入一个独立的验证步骤——用不同的提示、不同的视角去审一遍要写入记忆的内容。自我确认陷阱是结构性的,自检解决不了。
第二,记忆入库要有"默认拒绝"的门槛。宁可少记一些,也别让错误经验污染记忆库。那个 10% 污染掉 5 个点的实验,值得每个做 Agent memory 的人记在心里。
至于这个方向往后会怎么走——我猜"经验构建的可靠性"会慢慢从一个被忽略的细节,变成 Agent 自我进化系统里的标配模块。毕竟,一个会自我学习的系统,如果学的东西本身是错的,那它学得越快,死得越惨。
论文和代码都开源了(https://github.com/shidingz/EDV),感兴趣的可以去翻翻 Prompt 设计,Distill 和 Verify 那两段提示词在附录 B 里写得挺细的。
觉得有启发的话,欢迎点赞、在看、转发。跟进最新 AI 前沿,关注我