IBM Research 在最新研究中指出，代理的平均成功率掩盖了重复执行时的不稳定性，提出了一致性差距（consistency gap）概念并用 Consistency Analyzer 在 ALTK-Evolve 框架上检测与生成规避翻转决策的指南。实验证明该方法能显著缩小一致性差距，提高多次运行的稳定通过率，但并非完全消除不确定性，需权衡额外推理成本与记忆管理。
一个人工智能代理完成任务，并不意味着它下次还会以同样的方式完成。IBM Research团队在Hugging Face发布的一篇文章指出，当前许多代理评测把“平均成功率”当作可靠性的近似值，却忽略了同一个任务在重复执行时可能出现不同结果的问题。
这项研究发表于2026年9月15日，标题为《Your Agent Aced the Task. Will It Do It Again?》。研究背后的技术报告则早在9月8日提交至arXiv，题为《Closing the Consistency Gap: Self-Evolving Agents That Learn to Stay on Course》。两者属于同一项研究链条：前者面向工程实践，后者给出完整的方法与实验细节。
平均准确率掩盖了什么
研究团队以AppWorld中的ReAct代理为例。由GPT-4.1驱动的代理在同一任务上重复运行五次，平均每次运行的成功率为77.4%。但如果要求一个任务五次都成功，只有53.0%的任务满足条件。
两者之间相差24.4个百分点，研究人员将其称为“一致性差距”（consistency gap）。换句话说，约四分之一的任务并非完全超出代理能力，而是处在一种更难处理的状态：代理有时能做对，有时会在执行过程中走向另一条路径并失败。
这与常见的Pass@k指标并不相同。Pass@k只要求多次尝试中至少成功一次，适合可以验证结果并允许重试的场景；Mean@k反映多次运行的平均通过率；而Pass^k要求所有运行都成功，更接近企业用户对“同样请求应当稳定完成”的期待。研究报告把Mean@k与Pass^k之间的差值定义为一致性差距。
这一差距也意味着，单一的“代理准确率”可能同时混合了能力和稳定性两个维度。一个代理可以具备较强的任务能力，但仍然无法在生产环境中稳定复现结果。
不稳定可能发生在一个决定上
IBM团队的解释是，代理的执行轨迹由许多连续决定组成，包括选择哪个API、填写什么参数、是否重试，以及如何解释工具返回的信息。每一个决定都来自模型对下一个词元的概率分布。
当某个候选词元的概率明显高于其他候选时，决定相对“尖锐”，轻微的系统扰动通常不足以改变结果。但如果多个候选接近，分布就会变得“平坦”，很小的变化也可能让模型选择不同的词元。一个单独的分歧，可能进一步改变后续工具调用和上下文，最终令整条任务轨迹发生变化。
因此，即使使用温度为零的贪心解码或固定随机种子，也不一定能消除所有差异。研究人员强调，解码设置控制的是如何从分布中选出结果，并不等于模型在每一步都拥有一个足够稳定的首选答案。
这类问题的重要性在金融对账、合同义务检查和企业系统操作等场景尤其明显。在这些任务中，“偶尔成功”与“可以依赖”之间存在实际差别。
Consistency Analyzer如何寻找翻转点
研究提出的方案建立在IBM此前的ALTK-Evolve框架之上。ALTK是一个面向代理生命周期的开源中间件工具包，目标是通过模块化组件处理工具调用错误、输出验证和其他常见故障。新方法在此基础上增加了一种专门针对一致性的指南。
流程分为两个阶段。第一阶段是检测。Consistency Analyzer读取一条已经完成的代理轨迹，在每个决策点重新采样多个完成结果，默认一次请求五个候选答案，然后比较输出变化。它不需要访问模型内部logits，也不需要重新执行工具调用或再次把任务完整跑一遍，因此属于黑盒分析。
第二阶段是生成指南。系统把检测到的高风险决策点转换成自然语言规则，并存入ALTK-Evolve的记忆与检索流程。未来遇到相似任务时，这些指南会被注入提示词，用于提醒代理避开此前容易翻转的决策。
文章给出的例子与笔记查询有关：如果任务要求统计带复选框标记的内容，代理可能把标题或图例中的同一符号也计算进去。生成的指南因此建议使用按行锚定的正则表达式，而不是简单的字符串计数；另一条指南则要求在处理笔记搜索结果时确认是否存在多个匹配，并核对目标笔记。
这些规则并不是对某一道题的硬编码。研究团队的观点是，字符串计数错误、搜索结果未核验等决策模式，可能出现在多个不同任务中，因而可以形成可迁移的经验。
实验显示差距缩小，但并非消除
在AppWorld test_normal数据集的168个任务上，研究团队先为每个任务生成一条基线轨迹，再用Consistency Analyzer形成指南，最后在五次新的运行中测试效果。
结果显示，Pass^5从53.0%提升至69.0%，Mean@5则从77.4%提升至81.0%。一致性差距因此从24.4个百分点缩小到12.0个百分点。研究团队称，这意味着此前不稳定的任务中，接近三分之一变成了五次运行全部通过的任务。
不同难度的任务收益并不相同。中等难度任务的Pass^5绝对提升为22.9个百分点，困难任务提升14.3个百分点，简单任务提升12.2个百分点。研究报告还指出，平均准确率并未下降；在这个实验中，提升重复成功率并不是以牺牲平均能力为代价。
指南在相似任务上的表现也提供了一个重要信号。对于同一场景中的不同任务变体，Pass^5提升了13.0个百分点，低于同任务评测的16.0个百分点，但仍显示出一定的迁移能力。换用gpt-oss-120b后，同任务提升为6.0个百分点，相似任务提升为8.7个百分点，说明这些指南可能捕捉到的是较一般的失败模式，而不仅是记住某条轨迹。
不过，这些数字来自研究团队自己的AppWorld实验，且依赖五次运行、特定代理架构和模型组合。它们说明方法在该测试设置下有效，并不能直接证明所有代理或生产工作流都会获得相同幅度的改善。
对代理开发者而言，评测需要增加一个问题
研究团队建议，代理评测不应只报告Mean@k，也应同时报告Pass^k。前者回答“代理平均有多强”，后者回答“用户重复提出同一个请求时，它是否每次都能完成”。在任务难度提高时，一致性差距可能进一步扩大，因此只看一个总平均分会更加容易误导。
这项工作也提出了一个现实的工程取舍：Consistency Analyzer不需要评分器或真实环境中的完整重放，但每个决策点仍然需要额外的模型调用。对于生产流量，离线分析和已有轨迹可能比重新执行一项不可重复、代价高或涉及真实数据的任务更可行；但额外推理成本、记忆库不断增长，以及指南之间可能发生冲突，仍需要在部署中评估。
更广泛地看，代理可靠性正在从“能否完成一次”转向“能否被持续依赖”。近期关于基准测试究竟测量什么的BenchMIRT分析也指出，单一基准分数可能混合多个能力信号。二者共同指向同一个变化：评测不能只追求一个更高的排行榜数字，还要说明结果在什么条件下产生、是否可以复现，以及失败究竟发生在哪里。
对于编程代理和长期工作流，另一个相关问题是如何保存并调用过去的经验。Hugging Face此前推出的funes记忆工具强调保留原始会话证据；ALTK-Evolve则试图把代理轨迹中的不稳定决策提炼成可检索指南。二者解决的问题不同，但都表明，代理的下一阶段竞争可能不只在模型参数和上下文窗口，也在于系统能否从过去的执行中形成可靠、可核验的工作记忆。
IBM研究的结论并不是代理已经变得稳定，而是提供了一种测量和改善稳定性的路径。对企业用户而言，真正需要追问的或许不再只是“它成功过吗”，而是“在相同条件下，它能否一次又一次成功”。