你的 Agent 一次跑对下次还行吗：Pass^k 把一致性差距砍到一半

IBM 这套方案叫 ALTK-Evolve，之前那篇博客介绍过它怎么把 Agent 自己的过往轨迹蒸馏成可复用的 guideline，再在推理时注回上下文。原来那一版优化的是平均通过率；这次新加的 Consistency Analyzer，目标换成了压 consistency gap。

图 2：Consistency Analyzer 与 Guideline Generator 的两段式流水线：从轨迹到 scorecard 再到 guideline，最终写回 Agent 记忆并按需注入。图片来源：IBM Research / Hugging Face Blog

分两段：

第一段：诊断。给一条已录制的轨迹，分析器逐个决策点做受控重采样——把上下文原样重放到那一步，让模型一次输出 k 个 completion（默认 k=5），看这 k 个结果分歧有多大。分歧度落到一张 consistency score card 上，直接标出哪几步最可能在下次翻转。

三个工程细节值得留意：

1. 不需要 ground truth。分析器测的是「同一步的一致性」而不是「这一步对不对」，所以对无法回放全流程的生产环境也能用——你只要有 trace log，不必再挂真环境、真工具、真接口。
2. 一步只花一次调用。每个决策点是一次 API 请求带 n=k 的采样参数，不是端到端把任务重跑 k 遍。整条轨迹的诊断成本大致是 轨迹长度 × 一次 completion。
3. 完全黑盒。不看 logits、不看模型内部、不做任何插桩。你手上有的 trace 就够。

第二段：生成 guideline。每一个被标出的「flat 步」进入 guideline 生成器，产出一条 ALTK-Evolve 格式的自然语言指导，进入既有的存储/检索管道，下次相似上下文命中时自动注入。

作者给了 AppWorld 上的一条真实样例，任务是「我 SimpleNote 里的清单勾了几件」：

Guideline 1：数笔记里那种复选框式标记时，用行首锚定的正则，别用普通子串计数——笔记标题里常常在图例行也复用同一个符号。

Guideline 2：查笔记的查询结果永远做一次多条命中的校验，确认是「那条」笔记再往下走。

注意这两条不是任务专属的琐碎 trivia。「字符串计数踩到重复符号」「不校验搜索结果就直接用」是任何长上下文 Agent 都可能翻的通用错误。分析器盯的不是失败、而是不稳定——它捕捉的是「这次侥幸做对但下次可能做错」的步骤，不是「已经错了」的步骤。

结果：24.4pp → 12.0pp，且 Mean@5 一分不掉

评测在 AppWorld test_normal 的 168 个任务上跑：每个任务先用一条基线轨迹生成 consistency guideline，再用 5 次全新的 run 测 Pass^5。结果：

图 3：引入 Consistency Guideline 后，AppWorld 各难度层 Pass^5 的绝对提升。汇总层 +16.0pp，中等层 +22.9pp，困难层 +14.3pp。图片来源：IBM Research / Hugging Face Blog

• 汇总层：Pass^5 从 53.0% 抬到 69.0%（+16.0pp），Mean@5 从 77.4% 抬到 81.0%。一致性差距从 24.4pp 压到 12.0pp——差不多减半。原来「有时能做有时不能」的任务里，接近三分之一变成了「每次都稳过」。
• 中等难度：+22.9pp（相对提升 44%），是三个层里绝对增幅最大的。
• 困难层：+14.3pp（相对 45%）——绝对增幅小是因为基数低（31.7%），相对幅度和中等层几乎打平。
• 简单层：+12.2pp——Easy 本来就有 77.2%，天花板不高。

作者特别强调一条硬约束：Mean@5 不许下降。任何靠牺牲平均通过率去换 Pass^k 的方案，本质只是把不可靠性换了个地方藏，不是真解决。结果上三个难度层的 Mean@5 都是持平或者上升，没有出现「用稳定性换掉能力」的 trade-off。

泛化：不是给这条轨迹打补丁

最容易被质疑的一点是：「你从这条 run 里蒸馏出来的 guideline，是不是只对这条 run 有用？」

作者做了两组对照。第一组还是 GPT-4.1，把 guideline 用到同一 AppWorld 场景下的另一条相关任务（比如同样是清单类查询、但目标不同）——Pass^5 提升 +13.0pp，只比 same-task 少了 3 个点。也就是说 guideline 不是死记轨迹，而是抓到了某种「这类步骤容易翻」的模式。

第二组更有意思：把整套流程搬到一个弱得多的模型 gpt-oss-120b 上。基线 Pass^5 只有 10.1%，加 guideline 后 same-task 抬到 16.1%（+6.0pp），而similar-task 的提升 +8.7pp 反而超过了 same-task。作者的解读：在弱模型上，同类型的失败模式更普遍，一条 guideline 覆盖到的相似步骤反而更多。这条数据把「shortcut 记忆一条轨迹」的怀疑基本排除了。

中国团队为什么该管一下 Pass^k

IBM 这套东西的价值主张，落到国内在做 Agent 的团队身上，值得对着自己的现状对一遍：

第一，甲方问的「上次能行为什么这次不行」，学名叫 consistency gap。 过去很多团队交付时给的是「测过 20 条 case，成功 17 条」的 Mean@k 数字，甲方复测踩到那三次翻车才发现说不清。这不是你的评测方法错了，而是你没做另一个数——Pass^k。哪怕先从 Pass^3 开始报，都能提前把「看着能打其实不稳」的场景挑出来。

第二，托管 API 不承诺决定性。 上面反复讲的浮点非结合性、batch 抖动，通义千问、DeepSeek、豆包、Kimi 一个不落。国内团队常见的做法是「把 temperature 关了、seed 定死」当护身符，然后在验收前发现同一批 prompt 的输出漂了，再花两周查代码——查不出的原因是根本不在代码里，在托管端。要接受这条约束，把 Pass^k 当作和吞吐、延迟同级别的可观察指标去跟。

第三，Consistency Analyzer 和 Self-Consistency 不是一回事，别混。 Wang 等人 2022 年的 Self-Consistency（多次采样投票）是运行时每条 query 都重跑 k 次，成本乘 k、每次都花；IBM 这套是离线扫一遍历史轨迹、生成永久的 guideline 存起来，下次同类上下文自动带进去，运行时只多一次检索。前者的成本随流量线性放大，后者是一次性投入。你如果预算不够跑 self-consistency，Consistency Analyzer 这条路值得先试。

第四，什么场景值得上、什么不用。 简单的一次性 QA、意图分类，Pass^k 通常已经很接近 Mean@k，consistency gap 小到不必单独治理；ReAct/Tool-Use 这类会连续做十几个决策的长轨迹、每步都能翻的场景，才是这套方法的甜点区。财务对账、报销审批、合同条款校验、供应链单据比对——所有「链条长且不能失手」的国内落地场景都归这一类。

第五，落地路径。 参考顺序：先把评测口径从 Mean@k 加一列 Pass^k、看差距；差距小于 5pp 可以先不管；差距 10pp 以上把 ALTK-Evolve 拉下来对着现成 pipeline 跑一遍；如果模型是通过国内 API 网关走的，注意做一次基线复测——不同副本策略下的 flat 分布数量可能和 OpenAI 直连时的观察不完全一致。

上手清单

• 报数：所有 Agent 评测在 Mean@k 旁边并列 Pass^k，最少 k=3。
• 警戒：Hard 难度层的 Pass^k 通常是最坏情况，别只看 Aggregate。
• 不要先换模型：一致性和能力是两根轴。换更大的模型可能提 Mean@k，但对 consistency gap 无必然改善。
• 诊断成本：一条轨迹的分析开销约等于 决策步数 × 一次 k=5 completion，可以在生产 trace 上离线做，不用回放环境。
• 仓库入口：ALTK-Evolve https://github.com/AgentToolkit/altk-evolve，含 Consistency Analyzer 与 guideline 生成模块；完整方法论 arXiv 技术报告。

如果你手上有一条正在爬坡的 Agent 项目，最小可执行动作只有一条：把 Pass^3 的数拿出来看一眼。看到那个差距的第一反应通常是「原来不是我评估口径的问题」——那就是这套方法的入场券。