你有没有过这种体验：辛辛苦苦搭了个 LLM 智能体去自动点网页、敲命令、调界面，单次跑完看着成功率挺漂亮，结果上线之后才发现——它经常在一个错误步骤上死磕半天，要么把表单提交错了，要么把数据库改了，到最后任务整段崩盘，事后看 log 完全没法定位是哪一步开始偏的。

更让人头疼的是"最终任务成不成功"根本不是个好的部署信号。一个 web agent 也许最后提交了正确答案，但中间绕了 8 步错路、点击了 5 个死链；一个 mobile agent 也许最后找到了目标页面，但中间有 3 次误触。这种"事后才知道"的信息，部署的时候根本用不上。

部署真正需要的是步骤级信心估计：在每个动作执行之前，告诉我这一步有多大把握是"有用"的，让我有机会把它拦下来重做、扔给人审、或者换条路走。这篇 arXiv:2607.12397 的工作就是冲这个痛点来的，提出了一套叫 CEB（Critic Experience Bank） 的自进化判官框架——不训练、不需要 ground-truth 步骤标签，单靠执行反馈的"事后回顾"就让判官越用越准。

我读完整篇的最大感受是：思路极其朴素，但朴素得让人佩服。作者把判官"评判"这件事拆成了"在线打分 + 事后投票 + 检索增强"三件非常老派的事，却拼出了一个在三个 benchmark × 三个 backbone 上全面刷榜的方案。ECE 最大相对降幅 54 个点（InterCode-Bash + GPT-4.1），对 ground-truth oracle 校准空间能恢复 95 个点（Mind2Web + GPT-5.4）。这个数据有多硬？后文展开讲。

核心摘要

• 痛点：LLM 智能体在 web/mobile/shell 等外部环境执行动作，错误的中间动作会改变后续状态甚至不可逆；现有的 LLM 信心估计（token logit、verbalized confidence、CoT 自陈）只评估"生成"不评估"执行后果"，无法告诉部署者在执行前这一动作有多大可能有效。
• 方案：CEB（Critic Experience Bank）。固定权重的 LLM 判官 + 一个不断增长的经验库。轨迹跑完后，hindsight LLM 看到完整执行反馈，对每步投 V=5 次票，多数票当 pseudo-label 入库；新步骤来时，从库里检索 top-k productive + top-k unproductive 对比案例塞进判官 prompt。
• 效果：在 Mind2Web、AMEX、InterCode-Bash 三个数据集上，GPT-4.1/GPT-5.4/Qwen3-Next 三个 critic backbone 共 9 个组合，CEB 的 ECE、Brier、AUC 全部最优；ECE 相对最强无训练 baseline 最大降 54 个点；selective execution、task success、oracle 头空间恢复上也都最强。
• 我的判断：这是一篇工程上极其实用、思路朴素但能落地的中间件级工作。不抢新训练范式的风头，但把"怎么让一个冻结的判官自己越用越好"这件事做得很扎实。局限也很明显：起步阶段 bank 空、hindsight labeler 和 critic 共用同模型、没有淘汰机制。但作为 deployment 阶段的轻量外挂，性价比很高。

论文信息

• 标题：Critic Experience Bank: Self-Evolving Step-Level Confidence Estimation for LLM Agents
• 作者：Yaopei Zeng、Congchao Wang、JianHang Chen、Nan Wang、Yurui Chang、Lu Lin
• 机构：Pennsylvania State University、Virginia Tech、Purdue University、Amazon AGI
• 链接：arXiv:2607.12397
• 日期：2026/07/14

为什么"步骤级信心"是个真问题

先把动机讲清楚。LLM 智能体跟单次生成式 LLM 最大的区别在哪？它和环境有耦合。

• 一次"点错了"会把浏览器带到无关页面；
• 一次"敲错了 shell"会污染后续所有命令的工作目录；
• 一次"点错按钮"在 mobile GUI 上可能跳进死胡同；
• 一些动作（提交表单、删文件、改库）压根不可逆。

这就引出最终任务成不成功是个太粗的信号。它告诉你"这条 trajectory 行不行"，不告诉你"下一步该不该执行"。一个 web agent 也许最后成功了，但中间点了一个看起来极自信、其实把 DOM 状态搞坏的"对的错的"动作——事后总结的时候这种步骤通常被忽略，但部署时它才是真正应该被拦下来的。

那现有的 LLM 信心估计方法能不能用？作者说：用，但很难直接用。原因在于它们都是"response-level framing"——给定 prompt 和当前上下文，对模型生成的内容打个分。但 agent 部署关心的是"执行后果"，关心的是"这条动作在类似上下文里执行后到底有没有推进任务"。这两个问题在信息维度上不对等。

为了说明这点，作者在 Mind2Web 上画了一张图：

图 1：Mind2Web 上 step-level 信心估计的校准（ECE）和排序质量（AUC）随轨迹深度的变化。PPL/ME 的 ECE 越往后越高，AUC 甚至低于 0.5（反向）；CEB 全程稳定保持低 ECE 和高 AUC。

这张图非常关键。PPL 和 ME（token 不确定性类方法）随着轨迹变长，ECE 几乎线性爬升，AUC 掉到 0.5 以下——说明它们不是没用，是反着用。Verbalization 类的（直接问模型"你有多确定"）表现略好但也一般。CoT 加分但有限。CEB（红色实线）是唯一一条从头到尾稳定维持在低 ECE、高 AUC 的曲线。

这说明什么？传统的"我对当前 prompt 有多确定"在 agent 场景里彻底失效了。你必须把"过去类似动作执行得怎么样"这条证据流喂进去。

方案：自进化判官 + 经验银行

CEB 的核心架构就一张图：

图 2：CEB 的双线架构。上半部分"在线步骤信心估计"：agent 提出动作 \(a_t\)，冻结的 LLM 判官 \(f_\theta\) 在执行前给出信心 \(\hat{z}_t\)，可选触发人工干预；下半部分"经验库更新"：轨迹 \(\tau\) 完成后，hindsight LLM \(g_\phi\) 看完整 \((s, a, o)\) 给每步投 pseudo-label，组装成 record 写入 bank。Bank 检索时返回 top-k productive + top-k unproductive 对比样例。

一句话讲清楚核心 idea：判官不变，变的是它眼前看到的证据。

具体分三步：

1) 在线打分：每步让 LLM 评一次当前动作

给判官 \(f_\theta\) 输入当前任务 \(q\)、状态 \(s_t\)、历史 \(h_{<t}\)、候选动作 \(a_t\)、以及从经验库里检索出来的对比样例 \(\mathcal{R}_t^{\pm}\)，让它输出一个 0-1 之间的分数 \(\hat{z}_t\)：

判官的权重 \(\theta\) 始终冻结。任何"进化"都只能通过往 prompt 里塞更多、更相关的过往经验来实现。

2) 事后投票：hindsight LLM 看到执行反馈再回头判断

这一步是 CEB 最巧的设计。等整条轨迹跑完，环境把 \(o_{1:T}\) 全部吐出来之后，hindsight LLM \(g_\phi\) 看到完整 (s, a, o) 序列，对每一步独立判断"这步是 productive 还是 unproductive"。为了降低单次判断的噪声，采 V=5 次做多数票：

把这条 step 打包成 record \(e_t = (q', s', a', \tilde{o}', \hat{y}', \hat{z}', \chi')\) 入库。其中 \(\chi'\) 是"在线信心和事后伪标签是否一致"的标志位——它把"判官以前在哪些情境下自信错了"显式地暴露给判官自己。这个设计我觉得是细节但非常关键。

3) 检索：top-k 对比样例怎么挑

检索 key 是 task ‖ state ‖ action 的拼接，用 TF-IDF + cosine 相似度做 top-k。关键 trick 是 class-split：

• \(\mathcal{B}^+\)：所有 pseudo-label 为 1（productive）的 record
• \(\mathcal{B}^-\)：所有 pseudo-label 为 0（unproductive）的 record

检索时从正负两个桶各取 k 个，强制让 prompt 里既有"类似情境成功了"的例子，也有"类似情境失败了"的例子。作者在 ablation 里专门做了去掉对比的实验（只检索 positive），结果 ECE 涨 +0.065——是消融里掉得最狠的组件之一。

另外还加了一个 \(\rho_t\) 重复信号：如果当前动作跟过去 3 步任意一个前缀匹配，就在 prompt 里高亮提醒判官"这可能是死循环"。

实验：三数据集 × 三 backbone 全胜

主实验在三个 agent benchmark 上跑：Mind2Web（web 导航，1009 条轨迹）、AMEX（mobile GUI，1000 条）、InterCode-Bash（shell 任务，200 条）。判官 backbone 三个：GPT-4.1、GPT-5.4、Qwen3-Next-80B-A3B-Instruct。9 个 dataset-critic 组合，CEB 在 ECE、Brier、AUC 三个指标上全部最优。

主表（Table 1 精简版）

数据来源：Table 1 完整数据；Brier 列因篇幅省略，CEB 在所有 Brier 列同样最优。

几个值得点出的细节：

• ECE 降幅 14 到 54 个点。最大 54 个点是 InterCode-Bash + GPT-4.1（baseline 最强 0.392 → CEB 0.181）。相对降幅 14 个点是 Mind2Web + GPT-5.4（baseline 0.205 → CEB 0.176），但绝对值已经是所有方法里最低的。
• Token 不确定性（PPL/ME）经常是负向贡献。在 Mind2Web 和 InterCode-Bash 上 AUC < 0.5，这种置信度排序是反的——"高自信"其实在指错的方向。AMEX 是个例外，mobile GUI 上动作短、token 概率比较信息量，但校准（ECE）依然烂。
• Verbalization 的校准也普遍不靠谱。GPT-4.1 在 Mind2Web 上 ECE 飙到 0.725，比 CEB 差了不止一个量级。说明"问模型有多大把握"这件事在 agent 任务上基本是无效信号。

消融（Table 3，Mind2Web + GPT-5.4）

几个有意思的发现：

1. 对比检索（+0.065）和 TF-IDF 检索（+0.042）是最值钱的两个组件。这其实非常符合直觉——CEB 的核心价值就是"给判官看对比例子"，去掉任何一端都崩。
2. Multiple sample vote（V=5）也很重要，去掉后 ECE 涨 0.028。hindsight LLM 单次判断确实有噪声，多数票是必要的。
3. 重复信号 ρ_t 反而是最不重要的组件（+0.017）。但作者说补这个很便宜，保留。
4. Static（无 bank）baseline 的 ECE 是 0.318——也就是说，整个 CEB 框架的"经验"价值就是把 ECE 从 0.318 拉到 0.176，差不多砍掉一半。这个数字其实在表里比"54% 相对降幅"更直观。

自进化曲线（Figure 3）

图 3：累积 ECE 随任务流长度变化，5 个随机 stream 顺序平均。Static 判官（绿线）从头到尾基本是一条平线，CEB（红线）随着 bank 积累持续向下。任务数 30 时差距 +0.073，50 时 +0.104，150 时 +0.136，完整流 +0.142。

这张图是 CEB "self-evolving" 卖点最直观的证据。

• 起步阶段（0~10 任务）CEB 和 Static 几乎没区别——bank 太空，检索不到什么有用的。
• 30 任务之后差距开始拉开。
• 150 任务之后差距稳定在 0.14 左右。

我之前做类似系统时也观察到类似曲线：memory-based 方法最大的弱点就是冷启动。前 N 条任务基本是"白干"，必须熬过这个阶段才能开始享受到经验库的红利。CEB 没解决冷启动问题，但给了一个比较干净的曲线告诉你"用多久能见效"——30 条任务是个挺舒服的临界点。

Reliability Diagrams（Figure 4）

图 4：Reliability diagram——横轴是判官给的分箱，纵轴是该分箱里实际正确率。理想情况是所有柱贴在对角线上。CEB 的柱形最贴对角线，CoT 偏向高估，P(True) 散得很开，ME 直接塌在 0.5 附近的高分箱。

这张图比数字更直接。CEB 是唯一一个在高分箱（0.8~1.0）里柱形能贴到对角线的——意思是"判官说 90% 把握的时候，10 次里确实对 8~9 次"。其它方法都是"判官说 90% 把握的时候实际只对 30~50%"，典型的"过自信"。

下游价值：信心到底能不能拿来用

校准好不等于有用。作者做了两个下游实验。

Selective execution（Table 4）

按信心排序，把最低 b% 的步骤扔回去重做或人工审核，看剩下的步骤里正确率多高。

PPL/ME 是反着用的——扔掉最低自信的步骤后，正确率反而从 0.198 掉到 0.114/0.124，说明它们把正确答案排在低自信那边。CEB 在 b=50% 时把保留步骤正确率拉到 0.288，绝对涨幅 +0.090，比 CoT 的 +0.036 高出两倍半。

Task success under review budget（Table 5）

更接近真实部署场景的实验：每条任务预算 m 次"把最低自信步骤送去人工修正"，看最终任务成功率。

CEB 持续最接近 Oracle（"把真正错的步骤送审"），且几乎每行都比 CoT 高。这块说实话我觉得绝对涨幅不算大（m=3 时 Mind2Web 比 CoT 高 1.1 个点），但方向是对的——在 m 预算紧的时候，CEB 的排序优势能换到一点真实成功率。

离线重生成（Figure 5，附录 G）

图 5：按信心挑出 b% 的步骤重新生成，看 (a) 单步正确率 (b) 整任务平均 step 准确率。CEB（红线）紧跟 Oracle（绿虚线），PPL/ME 反而掉到 Random（灰虚线）之下。

这张图跟 Figure 4 是同一组实验的不同切面，结论一致：CEB 拿来选"哪些步骤值得花算力重做"这件事上，是真的能用的。

和 Oracle 还差多少：CEB 用 hindsight label 拿到了多少

这个表非常震撼。作者把经验库里的 hindsight pseudo-label 换成 ground truth step label 跑了一遍——Mind2Web 上 CEB（0.176）几乎追平 Oracle（0.169），差 0.007；AMEX 也有 61% 头空间被恢复。

这个对比的核心信息是：hindsight 投票这套机制已经提取了 ground truth 能给的几乎所有信息。继续提升的关键不在"label 质量"，而在"检索质量"和"判官对样例的消化能力"。

我读到这一段的时候愣了一下——大部分 self-training / self-distillation 的工作都死在 label noise 上。CEB 居然用 V=5 的多数票就基本把这条噪声路径堵死了，确实是个不小的工程胜利。

我的判断：值不值得用、值不值得深读

优点

• 零训练、零标注：API-only 模型也能用，不需要 trainable verifier、不需要 GT step label。对部署方极其友好。
• 三个数据集三个 backbone 全胜：说明不是某个特定模型/任务的过拟合，是真的"通杀"。
• 核心组件 ablation 干净：对比检索、TF-IDF 检索、多次投票各自贡献清晰，没有那种"消融掉一个东西只掉 0.001 然后说这个也重要"的注水现象。
• Oracle 对比说明 label noise 不是瓶颈：暗示后续工作可以从"提升检索"和"提升判官对样例的消化"两个方向走。

局限（作者自己 limitation 也写明了一些）

• 冷启动：前 10~30 条任务基本没收益。这在低流量部署场景下是致命问题——如果你一个月就跑 5 条任务，bank 永远长不大。
• hindsight labeler 和 critic 共用同一模型：理论上让独立 labeler（比如 GPT-5 评 Qwen3 的步骤）可能进一步去偏，但作者没做。
• 没有 bank 淘汰/压缩：作者明确承认——长流量下 bank 会无限膨胀，需要做 eviction 或 summarization。
• TF-IDF 检索 vs dense retrieval：附录 F 表 11 显示在简单 web 任务上 TF-IDF 够用，复杂时可能不够。dense retrieval 是未来工作。
• “Online” 和 “离线” 这两套评估混着报：Main table 是 online streaming（轨迹顺序处理，bank 不偷看未来），但 Figure 5 是离线重生成。部署时一定要分清。
• 没用置信度做 replanning 的闭环实验：作者明确说"This does not claim a closed-loop replanning policy"。所以"自信心→重做→再打分"这个完整闭环还没验证。

工程落地建议

如果你正在做生产级 agent，这套方案是门槛最低的中间件之一。直接的好处：

• 接 API 模型就行，不需要重训 verifier；
• 可以按时间窗口切 stream（比如按 session、按天），bank 自然分片，不会污染跨用户的隐私；
• 经验库和判官解耦，未来换更强的判官只动 \(f_\theta\) 不动数据；
• retrieval depth k=2 是个非常便宜的 default，prompt 增长可控，token 成本不爆炸。

但要注意：

• 冷启动期建议并行跑一个 rule-based 信心 fallback（比如检测动作是否触发了危险 API），别让前 30 个任务裸奔；
• 监控 hindsight label 的 vote agreement rate——如果多数票越来越分化（V=5 里 3:2 越来越多），说明场景在漂移，bank 可能要重置；
• 别迷信 GT oracle 95% 那个数——它是"如果我用真 label 我能拿多少"的上界，不是 CEB 的实际能力。实际能力看 Main table 的 0.176 这种绝对值。

和同期工作比，CEB 在哪

把 CEB 放在 confidence estimation 这个大地图上：

CEB 的定位非常清楚：填补"没有 trainable verifier、没有 GT step label"这个真实部署的真空。上方的 trainable verifier 路线效果更强但部署门槛高（要标注数据、要训模型、还要适配不同 backbone），下方的 actor-side memory 路线改的是"怎么生成动作"而不是"怎么评估动作"。

所以 CEB 的"novelty"不在某个新算法，而在：

1. 第一次把 hindsight 投票机制用在判官侧而非 actor 侧；
2. 第一次把"经验库检索"作为校准信号（而非作为示例增强）；
3. 第一次在 streaming setting 下做到"模型不动，证据流在动"的自进化。

这套"no-train + no-label + streaming + 跨 dataset-critic 通用"是它在工程上特别值钱的地方。

几个我读完后还想追问的问题

1. 跨 domain 的 bank 怎么迁移？ 论文里 Mind2Web、AMEX、InterCode-Bash 三个 bank 是独立的。如果一个 agent 同时跑 web 和 mobile，bank 是合一起还是分开？ 检索 key 里 task 字段能不能把两个 domain 隔开？作者没做实验。
2. hindsight labeler 的"立场"问题。hindsight LLM 看到完整 trajectory 后能识别"走错路了"——但它会不会对模型自己刚做错的步骤给 too-harsh 的 negative label？比如模型在 step 3 犯了个错，step 4 看似"无效"其实在补救，但 hindsight 看到 step 3-4 都"没直接推进任务"就给两个 negative。这种级联错会不会污染 bank？论文里 vote V=5 和 oracle gap 0.007 间接说明不严重，但没正面分析。
3. retrieval key 的 TF-IDF 是凑合还是合理？ action 字符串往往很短（"click #button_id"），task 描述又长，state 是 HTML 摘要。这三段拼起来做 TF-IDF，权重怎么平衡？作者没展开。
4. 如果用户要求"零经验库冷启动也能用"呢？ 当前 CEB 起步就是 bank 空——能不能用一台 pretrained verifier 暖启动 bank？比如先跑一遍 GPT-5 做判官，产生的记录喂给 Qwen3 用。

收尾

读这篇论文最让我舒服的地方是作者没有发明新概念。hindsight voting、retrieval-augmented prompting、self-evolving memory——每一件都是工程里用烂了的老工具。但他们拼到一块儿、扣在"步骤级信心估计"这个之前没人认真做的部署问题上，效果就出来了。

工程上，如果你手头有 agent 在跑、想加个轻量信心估计层，CEB 的成本曲线是我目前见过最低的——不训练、不标数据、不改 actor、prompt 增量可控。它的限制也很清楚：冷启动、bank 膨胀、检索 key 的简单。如果你流量大、场景杂，可以把它当 fallback，跟 PRM/verifier 这种"贵但强"的方案做分层——贵的给小流量关键任务，便宜的 CEB 给大流量兜底。

这不算是颠覆性的方法论突破，但是一篇非常扎实、落地性极强的中间件级工作。在 agent 部署的"可靠性"这个问题上，CEB 至少把"无训练"这条线推到了一个能用的位置。

参考

• Paper: arXiv:2607.12397
• 代码：论文未在 abstract 页公开链接，实验细节见论文附录 B。