今天读的是 2026 年 9 月 8 日上传到 arXiv 的《Closing the Consistency Gap: Self-Evolving Agents That Learn to Stay on Course》（arXiv:2609.08832），作者是 Evelyn Duesterwald、Benjamin Elder、Lilian Ngweta、Shashanka Ubaru、Malgorzata Zimon。
这篇论文的价值不在提出了一个更聪明的 Agent 架构，而在于它把一件大家隐约知道、却很少被量化的事变成了一个可测指标：Agent 的平均成绩漂亮，不代表它可靠。
一、问题：均值的谎言
先看论文给出的那组数字，它几乎是全篇的引子：
- AppWorld 基准上，ReAct Agent 搭配 GPT-4.1，单次通过率平均 77%；
- 但把同一个任务重复执行五次，五次全部成功的情况只占 53%。
77% 减 53%，差了 24 个百分点。论文把这 24 点命名为一致性缺口（consistency gap）。
这个数字之所以扎人，是因为它揭示了一种过去常被评测掩盖的失败模式。我们习惯看单次通过率，把它当作能力指标。但在生产里，你真正需要的不是「平均能过」，而是「这次能过」——同一个用户请求交给 Agent，它不应该因为采样随机性或工具返回顺序的变化就时而成功时而失败。
论文说得很直接：一致性不是锦上添花的质量指标，而是可信 Agent 部署的前置条件。如果同一个请求的结果不可复现，那么重试策略、超时预算、SLA 与成本估算全部失去意义，你无法告诉业务方「这个流程的失败率是多少」，因为它是波动的。
二、方法：从「诊断分叉点」到「写入记忆」
论文的框架可以拆成两个核心组件，逻辑非常清晰：先定位不稳定，再把它固化。
Consistency Analyzer：找出轨迹在哪里翻转
当一个任务在多次执行中有时成功有时失败，Agent 的轨迹（trajectory）必然是分叉的。Consistency Analyzer 的职责就是跨越多次执行，对比轨迹，找出哪些步骤是低一致性的不稳定步骤，以及它为什么容易翻转。
这里的关键设计是「可归因性」：它不只是告诉你「这次失败了」，而是指出「失败是从第几步开始岔开的、岔开的诱因是什么」。这个区别决定了后续能不能生成有针对性的纠正，而不是笼统地说「下次小心点」。
Guideline Generator：把诊断转成准则，写进记忆
拿到诊断结果后，Guideline Generator 把它转成针对性的准则（guidelines），提交到 Agent 的**情节记忆（episodic memory）**中，并在未来执行相似任务时注入到上下文里。
用一句话概括这套机制的设计意图：
一次不稳定的执行经历
→ 被诊断出「哪一步容易翻转、为什么」
→ 被写成一条可复用准则
→ 存入情节记忆
→ 下次遇到相似任务时作为先验注入
→ 该步骤不再随机分叉这很像人类专家的成长路径：不是每件事都重学一遍，而是把踩过的坑记成一条经验，下次直接绕开。论文把它称为「自进化」，进化发生的载体就是这份不断累积的准则记忆。
三、结果：一致性提升，且能迁移
论文在 AppWorld 上以 ReAct 加 GPT-4.1 为基线做了两组评测：
| 评测维度 | 提升 |
|---|---|
| 同任务评测：五次全部成功的比例 | +16 个百分点 |
| 相似任务泛化：五次全部成功的比例 | +13 个百分点 |
这两个数字要分开看，因为它们回答的是不同问题。
同任务 +16 分说明：对已经见过、失败过的任务，记忆机制确实能压住随机翻转。这部分提升相对好理解——相当于给这些任务打了补丁。
相似任务 +13 分才是真正有分量的部分。它说明学到的准则不是死记硬背某一条轨迹，而是捕捉到了可迁移的纠正模式，能在没见过的相似任务上生效。如果只有第一项提升，这套方法就只是一本查错手册；有了第二项，它才称得上「学习」。
四、对工程实践意味着什么
这篇论文对做 Agent 产品的人有三点现实启发。
第一，把「多次运行一致性」加进你的评测集。 只看单次通过率会系统性高估可靠性。如果预算允许，对关键任务至少跑三次到五次，统计「全部成功」的比例，而不只是均值。这个指标更接近生产体感。
第二，重试不是免费的可靠性。 在 53% 五次全对的场景下，靠重试堆成功率会同时推高成本与延迟，而且掩盖了真正的失败点。更划算的做法是先诊断分叉点。
第三，轨迹日志要按可诊断的方式存。 这套方法的输入是完整的、结构化的执行轨迹。如果你的 Agent 只留下最终输出和一句「失败了」，你连 Consistency Analyzer 的第一步都做不了。也就是说，可观测性不是运维需求，而是自进化能力的原料。
一个简化到极限的自建版本可以长这样：
# 伪代码：最小一致性记忆闭环
def run_task(task, n=5):
runs = [agent.execute(task, memory=MEMORY) for _ in range(n)]
if all(r.success for r in runs):
return "stable"
# 只对出现分叉的任务做诊断
diagnosis = analyze_divergence(runs) # 低一致性步骤 + 原因
guidelines = to_guidelines(diagnosis) # 转成准则
MEMORY.add(task_signature(task), guidelines) # 写入情节记忆
return "patched"注意这段伪代码里的两个刻意的选择：只对出现分叉的任务做诊断（避免给已经稳定的任务浪费算力），以及用任务签名而不是任务原文作为记忆键（这样才能在相似任务上命中）。
五、局限与需要留意的地方
论文摘要没有展开的地方，恰恰是落地时最容易踩的坑。
一、记忆会膨胀。 准则持续累积后，注入上下文的长度会增长，既推高成本也可能引入相互冲突的准则。需要一个淘汰或合并机制，论文摘要未给出细节。
二、一致性不等于正确性。 这套方法的目标是「让它每次都一样」，但如果某个错误做法恰好是稳定的，它就会被稳定地重复。它降低的是方差，不是偏差。
三、相似任务的判定是隐含难点。 +13 分的泛化提升建立在「相似任务」的定义之上。任务签名的设计直接决定记忆命中率，这部分工程权重往往高于算法本身。
四、AppWorld 是受控环境。 真实业务里的工具返回、权限失败、网络抖动远比基准噪声大，跨环境外推时要保守。
六、和相邻工作的关系
把这篇论文放到最近一周的 Agent 可靠性讨论里看，位置会更清楚：
- 它关心「方差」：同一任务重复执行的稳定性。
- 同期的 ODCV-Bench 那类工作关心的是**「偏差与越权」**：Agent 在 KPI 压力下违反约束。
- 而 OctoBench 这类基准关心的是**「合规」**：Agent 会不会做题但不守框架规矩。
三者是正交的三个轴。一个 Agent 完全可能做到「每次结果一致、遵守约束、且不越权」——也可能在三条轴上同时失守。把这三个轴拆开度量，是 2026 年 Agent 评测正在发生的、最有意义的一次范式迁移。
七、一句话结论
《Closing the Consistency Gap》给出的最有用的一件东西，不是某个具体算法，而是那个 24 点的缺口本身。它把「Agent 靠不靠谱」从一个模糊的形容词，变成了一个可以写进评测报告、可以写进采购要求的数字。
如果你现在负责把一个 Agent 送进生产，建议先做一件很小的事：挑十个关键任务，每个跑五次，统计五次全对的比例。这个数字大概率会让你的路线图往后挪一挪。