IBM 智能体一致性测试揭示：一次成功远远不够

IBM 智能体一致性测试揭示了基准测试成功与可靠行为之间的尖锐矛盾。一个 GPT-4.1 智能体完成了 77.4% 的 AppWorld 运行，但在五次尝试中全部通过的任务仅占 53.0%。

这 24.4 个百分点的差距改变了“成功的智能体演示”所代表的意义。一次正确运行能够证明智能体具备所需能力，却无法证明用户明天，甚至五分钟后，还能获得相同结果。

IBM Research 正通过 ALTK-Evolve 中新增的一致性指导原则来应对这一差异。该系统会在已记录的智能体轨迹中找出不稳定决策，再将这些薄弱点转化为可复用的指令。其早期结果表明，提升可靠性未必总需要更大的模型。

这项工作也对供应商展示智能体性能的标准方式构成了压力。排行榜平均分可能会奖励一个经常奏效的智能体，同时掩盖它曾经成功后又失败的频率。

IBM 智能体一致性结果揭示了缺失的指标

IBM 的核心发现是，平均准确率和可重复成功描述的是两种实质上不同的产品。

研究人员在 AppWorld 的 test_normal 划分中，对 168 个任务测试了由 GPT-4.1 驱动的 ReAct 智能体。ReAct 是一种在推理步骤与行动之间交替进行的智能体设计，例如调用应用程序或搜索已存储的信息。

每项任务都进行了五次全新的运行。根据 IBM 一致性研究，基线智能体的 Mean@5 得分为 77.4%。Mean@5 计算五次尝试的平均成功率。

这个数字听起来足以支撑一场强有力的产品演示。然而，该智能体的 Pass^5 得分仅为 53.0%。只有五次尝试全部成功，Pass^5 才将一项任务计为成功。

这两项结果之间的差异就是一致性差距。在这里，它达到 24.4 个百分点。IBM 表示，在最困难的任务组中，这一差距达到 30 个百分点。

这一区别之所以重要，是因为 Pass^5 并不是某些代码评估中常见的 Pass@5 指标。Pass@5 问的是五次尝试中是否至少有一次成功；Pass^5 问的是每一次尝试是否都成功。

这些指标对应不同的产品形态。当系统可以生成多个候选结果、测试它们并保留胜者时，Pass@5 很适用。Pass^5 则适用于每次执行都必须可靠的工作流。

向智能体索取五个可能代码补丁的开发者，可以从一个有效答案中受益。要求智能体核对一笔交易的财务团队，则不能安全地接受四次正确运行和一次造成损失的错误。

同样的问题也适用于合同分析。一个智能体在一次审查中识别出某项义务、却在另一次审查中遗漏它，并不只是表现有所波动，而是在相同证据下产生了不一致的业务决策。

IBM 的结果并不意味着 GPT-4.1 缺乏完成这些任务的能力。77.4% 的平均值证明它经常能够做到。这些结果表明，在这一特定智能体设置中，这种能力无法可靠地经受重复执行。

这正是本文的核心反转：第一次成功证明的是可能性，而不是运营可靠性。

更广泛的评估社区也得出了类似结论。Anthropic 的 智能体评估指南 区分了 Pass@k 与 Pass^k，并建议让指标与产品需求相匹配。

Anthropic 给出了一个简单例子：单次试验成功率为 75% 的任务，在三次独立试验中全部成功的概率约为 42%。表面上的质量下降，是因为要求从偶尔成功变成了持续成功。

平均值仍然有价值。它们有助于比较整体能力，也能揭示某项改动是否改善了一组任务的结果。但当买家将其解读为可靠性保证时，它们就会产生误导。

对于企业部署而言，这两个数字都应纳入评估。Mean@k 告诉团队智能体通常多久能正常工作；Pass^k 则告诉他们，有多少任务能在重复使用中始终保持可靠。

为什么智能体在温度为零时仍会改变路线

即使提示词、模型、工具和解码温度看似不变，智能体仍可能表现出不一致。

LLM 会从概率分布中选择下一个 token。有些决策存在明确的首选项，而另一些则有多个概率几乎相同的选项。

IBM 将这两类决策描述为尖锐决策和扁平决策。尖锐分布会将大部分概率集中在一个选择上，微小的计算变化不太可能改变胜出的选项。

扁平分布则将概率分散在多个合理选择之间。极小的数值变化就可能改变哪个 token 排在首位，使智能体走上不同路径。

这种差异在使用工具的系统中尤为重要。单个 token 的变化就可能改变 API 选择、搜索查询、工具参数、重试决策，或对中间结果的解读。

普通聊天机器人可以吸收部分措辞变化，而不改变最终含义。智能体则会根据其中间选择采取行动。每一个变化的选择都会改变下一步可获得的信息。

这一风险会沿着长轨迹不断累积。如果智能体要做出数十项决策，其中若干项可能处于不稳定边界附近。只要有一项发生翻转，后续的工具调用或最终答案就可能失败。

IBM 以 0.0 的温度运行其 ReAct 智能体。因此，研究人员认为常规采样并不是观察到的波动性的原因。

温度为零并不意味着每次托管模型执行在数学上都完全相同。请求批处理、硬件行为、浮点运算以及提供商侧的实现细节，都可能轻微改变概率。

这些变化在普通文本生成中通常难以察觉。但当两个选择的概率几乎持平时，它们就会产生影响。即使用户请求没有变化，轻微改变也可能重新排列它们的顺序。

固定随机种子也存在局限。它只能控制生成过程的一部分，无法冻结远程推理系统的每一个层面，也无法让原本不确定的决策变得更明确。

这一机制解释了为什么一次成功的彩排可能在现场演示中失败。智能体未必忘记了任务，而是进入了同一决策树的另一条分支。

设想一个智能体被要求统计笔记中已完成的活动。一次运行中，它可能统计每个复选框标记；另一次运行中，它可能还会把解释复选框格式的图例算进去。

这两条路径在初始阶段看起来都可能合理，但只有一条能得到预期总数。错误源于对文档应如何解读这一问题尚未解决，而不是因为无法访问笔记。

更长的工作流会放大这种行为。研究型智能体可能选择不同来源、误解一个模糊日期，或在找到第一份匹配文档后就停止。每个选择都会塑造后续的一切。

这使得 AI 智能体可靠性在一定程度上成为编排问题。更好的基础模型可以提高作出正确决策的概率，却无法保证其边界决策会消失。

外部条件又增加了一层复杂性。ReliabilityBench 会评估重复执行、改写后的请求和工具故障。其 生产压力测试框架 将一致性、稳健性和容错能力视为彼此独立的维度。

IBM 当前的实验更狭窄地隔离了重复运行。这一重点使一致性差距更易于观察，但并不代表智能体在生产环境中会遇到的每一种故障。

真实部署还要面对数据变化、凭证过期、API 速率限制、部分响应和不断演变的模式。因此，在相同输入下保持稳定行为只是起点要求，而非完整的可靠性标准。

ALTK-Evolve 将不确定性转化为有针对性的指导

ALTK-Evolve 试图在不对每项任务在实时环境中进行完整重放的情况下，修复不稳定决策。

这一新流程始于一条已记录的轨迹。轨迹是智能体运行过程中产生的提示词、决策、工具调用、观察结果和响应的有序记录。

IBM 的 Consistency Analyzer 会利用该轨迹中已存储的上下文，重新审视每一个决策点。它请求多个替代补全结果，并衡量模型选择的变化程度。

默认配置会在每个决策步骤通过一次额外模型调用抽取五个补全结果。它不会重复外部工具调用，也不会重新运行完整任务。

这种设计在生产环境中很重要。完整重放可能会再次发送邮件、两次修改同一记录、重复购买商品，或遇到已经发生变化的数据。

离线重采样避免了这些副作用，也让诊断阶段无需真实标签。

该分析器是黑盒式的，意味着它不需要模型 logits 或内部访问权限。只要团队拥有原始轨迹，并能够重新提交其中的决策上下文，就可以将其应用于托管模型。

每项决策都会获得一致性评分。补全结果出现分歧的步骤，就会成为接受额外指导的候选对象。

随后，ALTK-Evolve 会将这些候选对象转化为简洁的行为指令。其更广泛的目标，是从早期轨迹中提炼有用经验，并在后续任务中检索这些经验。

对于笔记计数示例，生成的指导建议使用以行为锚点的正则表达式，而非基础子字符串计数。它还指示智能体在选择笔记前检查多个搜索匹配结果。

这些指令针对的是普遍的失败模式，而不是简单保存原始任务中的正确数值答案。

这一区别至关重要。记住一个答案可以提升某个基准测试条目，却无法强化智能体本身。可复用的规则则可以帮助处理新的笔记、不同的复选框格式或相关的搜索决策。

ALTK-Evolve 仓库现已包含 Consistency Analyzer 和指导原则生成功能。该项目采用 Apache 2.0 许可证，并支持通过 Model Context Protocol 进行集成。

其检索层会在推理时将相关指导原则带入智能体上下文。这让模型能够获得有针对性的提醒，而无需让每一条历史轨迹始终留在活动提示词中。

这种方法类似于一种聚焦的运营记忆形式。系统不要求智能体重新阅读它完成过的所有工作，而是提炼反复出现的经验，并检索与当前任务相关的内容。

这一区别对于知识工作同样重要。更大的档案库并不会自动带来更好的决策。有效的记忆需要筛选、冲突处理，以及适合当前请求的上下文。

同样的原则也支撑着结构完善的 AI 知识库。当系统能够检索正确证据、又不淹没工作上下文时，已存储的材料才会变得有价值。

ALTK-Evolve 的方法比通用知识平台更为狭窄。它聚焦于智能体行为，并使用从轨迹中提炼的指导原则。不过，这两种情形都揭示了同一项限制：保留信息比在恰当时刻应用恰当信息更容易。

该机制还会形成反馈循环。团队可以收集执行轨迹、识别不稳定步骤、生成候选指导原则，并评估这些原则是否能改善后续运行。

不过，该系统并不能消除测试的必要性。生成的规则可能有误、范围过宽，或在其产生背景之外造成负面影响。

团队仍需进行版本管理和回滚。他们还需要追踪哪项指导原则影响了某个决策，尤其是在智能体执行受监管或具有重大财务影响的工作时。

可靠性提升显著，但证据范围有限

IBM 报告了显著改进，但该研究仍是在一项主要基准配置上的早期评估。

加入一致性指导原则后，在 168 项 AppWorld 任务中，Pass^5 从 53.0% 提升至 69.0%。这意味着在全部五次运行中均通过的任务比例提高了 16 个百分点。

Mean@5 同样上升，从 77.4% 增至 81.0%。因此，一致性差距从 24.4 个百分点缩小至 12.0 个百分点。

这一结果很重要，因为平均表现并未下降。若一种方法只是通过迫使智能体采取稳定但平庸的策略来提高可重复性，就无法解决根本问题。

IBM 表示，这些指导原则在各个难度等级上均维持或提升了 Mean@5。中等难度组的 Pass^5 增加了 22.9 个百分点，困难组增加了 14.3 个百分点。

中等难度任务的相对提升为 44%，困难任务为 45%。简单任务增加了 12.2 个百分点，留给改进的空间相对较小。

IBM 还在同一 AppWorld 场景中的另一项相关任务上测试了这些指导原则。Pass^5 提高了 13 个百分点，而同一任务上的提升为 16 个百分点。

这一结果支持部分指导原则能够迁移到单条已记录轨迹之外的说法。但它并不能证明该方法可在无关的应用、行业或智能体架构之间实现广泛泛化。

第二项实验使用了 gpt-oss-120b。其同一任务的 Pass^5 从 10.1% 提升至 16.1%，相似任务的表现则增加了 8.7 个百分点。

较弱的基线表明，指导原则无法完全替代能力本身。6 个百分点的提升具有意义，但 16.1% 的全运行成功率仍不适合用于重要自动化任务。

完整的技术报告介绍了这些说法背后的方法论。即便如此，读者仍应将这些结果视为作者评估所得的证据，而非已在生产系统中获得独立验证的结论。

主要测试采用了一种 ReAct 配置、一个主要基准划分，以及每项任务五次重复运行。AppWorld 提供了逼真的多应用场景，但基准测试终究是受控环境。

五次运行能够揭示单次运行所掩盖的不稳定性，但无法精确估计可能在数千次客户交互后才显现的罕见故障。

该评估也带来了一个统计学问题。随着 k 增加，Pass^k 会自然下降，因为每增加一次试验，就多一次失败机会。

因此，产品团队必须根据实际风险暴露选择 k。五次成功运行或许是合理的开发筛选标准，但无法证明其在企业级规模下的可靠性。

指导原则也可能过时。API 会变化，政策会演进，早期的变通方案也可能与新的系统行为发生冲突。

从某个不稳定分支中提炼出的规则，可能会在其他场景中压制有效的替代方案。系统积累的指导原则越多，冲突解决和检索质量就越重要。

一致行为与正确行为之间也存在差异。一个反复执行同一错误动作的智能体，行为稳定性可以完美无缺，但任务价值为零。

IBM 的实验通过同时报告 Mean@5 和 Pass^5 来防范这一问题。生产团队也应保留这种组合，并加入针对具体结果的安全措施。

对于敏感工作流，目标必须是稳定的正确性。稳定性本身绝不应替代事实准确性、政策合规、授权检查或人工审查。

更大模型如今面临系统层面的竞争者

新证据挑战了这样一种假设：可靠性问题应首先通过替换底层模型来解决。

模型升级仍具有吸引力，因为它可以同时改善多类任务。与重建智能体的记忆或评估系统相比，它所需的定制诊断也更少。

然而，更大的模型并不会揭示现有智能体在哪些环节变得不稳定。它可以提高平均性能，同时仍留下偶发成功与重复成功之间的显著差距。

IBM 的方法代表了另一条路径。它不是改变模型，而是在高风险决策节点改变所提供的信息。

这种比较并非严格意义上的模型与记忆之争。强大的系统会同时采用能力更强的模型、设计良好的工具、有针对性的上下文、确定性检查和重复评估。

压力将落在那些仍只报告单一成功率的智能体供应商和企业采购方身上。一旦 Pass^k 进入采购讨论，高平均值就只是一部分证据。

采购方可以询问同一任务是否被重复执行、环境是否被重置，以及每次运行是否都达到了可接受的结果。他们还可以要求按难度报告结果，而不是只给出一个汇总数字。

开发人员面临相关变化。一份称智能体曾失败一次的错误报告，可能无法按需复现。团队需要完整的执行轨迹，才能定位最早发生偏离的决策。

可观测性成为产品质量的一部分。若没有保存提示词、工具参数、结果和中间选择，一次不稳定运行可能会消失得无影无踪，也无法解释自身原因。

这使得部署前的评估架构变得重要。团队需要具有代表性的任务、受控的初始状态、明确的成功标准，以及足够多的重复次数来暴露方差。

他们还需要将可重试工作与一次性操作区分开来。生成草稿可以容忍多次尝试；发送付款、删除文件或批准合同则需要更严格的控制。

当输出可以被自动验证时，Pass@k 适合第一类任务。对于第二类任务，Pass^k 的信息量更大，尤其是在用户期望首次结果就足够安全时。

有些工作流不应只依赖其中任一指标。交易智能体在执行不可逆操作之前，还需要权限边界、幂等性控制、审计日志和确定性验证。

指导原则可以减少不确定的推理，但无法取代这些保障措施。可靠的智能体是一种系统属性，而非模型分数。

这些结果也进一步支持了经过策划的工作上下文。团队已经使用知识融合将存储的证据与当前工作连接起来。智能体指导原则则将类似理念应用于行为经验。

关键在于克制。检索更多上下文可能带来干扰、矛盾和额外延迟。只有当有针对性的指令进入正确任务且不挤占关键证据时，它才有价值。

这正是 ALTK-Evolve 面临的长期挑战。它的诊断机制可以识别变化的决策，但周边系统必须管理不断增长的经验集合。

成功部署将需要过期策略、冲突检测、溯源能力，以及针对指导原则变更的评估。否则，昨天的修复可能成为明天隐藏的故障来源。

哪些迹象将验证 IBM 方法能否经受考验

三项信号将决定一致性指导原则会成为标准智能体层，还是仅停留在颇具前景的基准测试技术。

第一个信号是在其他基准和智能体架构上的独立复现。研究人员应在浏览器智能体、编程智能体、客户服务系统以及存在真实 API 故障的工作流上测试该方法。

若能复现 Pass^5 提升 16 个百分点的结果，将强化 IBM 的核心论断。较小或不一致的提升则表明，AppWorld 可能包含特别适合通过指导原则修复的失败模式。

比较应涵盖多种基础模型，同时报告 token 使用量、延迟、分析器成本、检索开销，以及每项任务注入的指导原则数量。

第二个信号是更长时间跨度内的表现。一个有用的学习系统必须能够处理新指导原则，而不会不断累积相互冲突或过时的规则。

团队应衡量，在经历数百或数千条轨迹后，收益是否仍能持续。他们还应测试，随着存储规模增长，指导原则检索是否依然精确。

关注那些冻结一组指导原则、再用其测试后续应用版本的评估。强劲表现将表明这些规则捕捉到了持久行为；快速衰减则会暴露维护负担。

第三个信号是重复运行报告的普及。供应商评分卡应同时发布 Mean@k 和 Pass^k，并清晰说明 k 的取值。

这种转变将让采购方区分经常成功的模型与稳定成功的系统。它也会抑制围绕一次有利执行构建的演示。

该领域还应进一步将重复测试与改写提示词、受控工具故障结合起来。完全相同的提示词只代表一种生产环境压力。

IBM 的工作有力地说明，一次成功运行作为标准过于薄弱。它也提供了一种实用方法，可在无需重复每一项现实操作的情况下定位不确定性。

剩下的问题是，这些收益能否在研究设置之外持续存在。开发者可以通过重新运行自身的重要工作流、保留完整轨迹并衡量全运行成功率来回答这一问题。

如果你的智能体处理重要工作，不要只问它是否完成了任务。还应问：它能多频繁地正确完成同一任务，哪些决策存在变化，以及昨天的指导原则遇到明天的条件时会发生什么。