全文翻译：Towards a Science of AI Agent Reliability

全文翻译：Towards a Science of AI Agent Reliability

原文标题：Towards a Science of AI Agent Reliability

作者：Stephan Rabanser, Sayash Kapoor, Peter Kirgis, Kangheng Liu, Saiteja Utpala, Arvind Narayanan

机构：普林斯顿大学（Princeton University）

发表场所：第43届国际机器学习大会（ICML 2026），首尔，PMLR 306, 2026

arXiv：2602.16666v3

翻译日期：2026-06-22

摘要

AI Agent 正越来越多地被部署来执行重要任务。虽然标准基准测试上不断上升的准确率分数表明了快速进步，但许多 Agent 在实践中仍然持续失败。这一差异突显了当前评估方法的一个主要局限：仅关注单一指标不足以理解 Agent 行为。值得注意的是，它忽略了 Agent 是否在不同运行间表现一致、能否承受扰动、是否以可预测的方式失败，以及错误严重性是否有界。基于安全关键工程，我们提供了一个由12个指标组成的整体性能画像，将 Agent 可靠性分解为四个关键维度：一致性（consistency）、鲁棒性（robustness）、可预测性（predictability）和安全性（safety）。在两个互补的基准测试上评估15个模型后，我们发现近期的能力提升仅带来了可靠性的微小改善。通过揭示这些持续存在的局限，我们的指标补充了传统评估方法，同时为推理 Agent 如何执行、退化和失败提供了工具。

图1：可靠性提升滞后于准确率改善。总体可靠性随时间推移仅显示出微小的改善，尽管经历了24个月的模型发布周期。此外，仅提升准确率并不能保证在复杂真实世界任务中获得可靠性增益。所有前沿模型提供商的表现聚类相似，表明可靠性是一个行业范围的平台期，而非特定厂商的局限。

1. 引言

AI Agent 正快速从研究原型过渡到部署系统，自主执行重要任务，如修改代码（Yang等，2024）、管理数据库（Wang等，2025）和编排复杂工作流（Yao等，2023）。虽然它们自动化例行工作的潜力巨大，但使其有用的自主性也使其失败的代价高昂。这种担忧被广泛共享：在一项超过80,000人的全球研究中，Anthropic揭示了不可靠性（幻觉、不准确以及由此产生的验证负担）是关于AI最常被提及的担忧（Huang等，2026）。

近期的高调事件进一步突显了基准表现与真实世界结果之间的令人不安的差距（Pan等，2025）。例如：

• Replit的AI助手在明确禁止的指令下删除了生产数据库（Business Insider，2025；Tom's Hardware，2025）
• OpenAI的Operator进行了绕过用户确认的未授权购买（Fowler，2025；OpenAI，2025）
• NYC政府聊天机器人提供了非法的商业建议（Lecher，2024）

在每种情况下，在内部评估中被判定为有能力的Agent在部署中都不可靠地失败了。这提出了一个根本性问题：我们应该如何定义和评估Agent的可靠性？

当前Agent评估的主导范式以平均任务成功率为中心（Zhou等，2024b；Jimenez等，2024；Liu等，2024；Mohammadi等，2025）。虽然这种方法提供了清晰的优化目标，但它掩盖了关键的行为特性。仅凭准确率无法区分一个在特定任务上可预测地失败的Agent和一个以相同比率随机失败的Agent。此外，它无法区分良性的格式错误和如删除文件等灾难性操作。标准基准测试也不报告Agent对输入扰动的敏感性或其识别自身可能失败的能力。这呼应了一个更广泛的发现：流行的基准测试追踪能力而忽略可靠性测量（Vendrow等，2025）。

这种评估差距与航空（SAE International，1996）、核电（IEC，2011）和汽车系统（ISO，2018）等安全关键工程领域形成了鲜明对比。在这些领域，可靠性被理解为一个多维属性（IEC，2010；Avizienis等，2004）。认证要求系统行为一致、限定失败严重性，并在压力下可预测地退化。尾部风险和失败后果被明确量化，而不是隐藏在平均成功率背后。

我们将这种安全关键视角适配到AI Agent的评估中，将可靠性分解为四个维度（见表1）：

• 一致性（consistency）：可重复的行为
• 鲁棒性（robustness）：扰动下的稳定性
• 可预测性（predictability）：校准的置信度
• 安全性（safety）：失败发生时的有界严重性

在这四个维度中，我们提出了12个独立于原始准确率的具体指标（见第3节）。将这些指标应用于两个基准测试上的15个模型后发现，可靠性增益明显滞后于能力进步（见图1；详细注释见图7）。

为系统地分析这一扩大的差距，本文提供以下两个关键贡献：

1. 形式化分类法和指标套件：我们将定性的安全关键原则转化为可计算的指标，以独立于任务成功率来评估可靠性。 2. 现代Agent的全面可靠性画像：我们绘制了最先进模型成功和失败的位置，隔离一致性和可预测性为需要立即研究关注的领域。

范围说明：我们将可靠性视为Agent行为在自然变化和偶然故障下的经验可测量属性。我们不评估对抗性攻击或更广泛的社会技术概念如价值对齐（Hendrycks等，2021；Weidinger等，2022）。我们使用"安全性"一词仅表示有界的操作严重性。

2. 可靠性的跨领域视角

在为AI Agent 定义可靠性指标之前，我们提出一个基础问题：什么是可靠性？本节将安全关键工程数十年的实践综合为统一的分解，将每个维度与现有的机器学习研究联系起来。我们调查了各行业的可靠性实践，包括航空、核电、汽车和过程控制，以识别反复出现的评估维度（见附录D.2）。尽管技术和风险容忍度不同，但出现了四个核心维度（表1），表明它们捕获的是可靠性的基本方面而非特定领域的关注点。

维度1（一致性）：系统在相同条件下多次运行时是否表现相同？

在安全关键领域，方差是一种负担：飞行软件和反应堆保护系统必须确定性响应，因为即使是可接受的平均性能，当高方差使结果不可预测时也会变得有问题。虽然ML研究注意到了提示敏感性（Razavi等，2025）、浮点非确定性（He & Thinking Machines Lab，2025）和通过pass∧k评估一致性（Yao等，2024）等问题，但这些通常被视为孤立现象，而非统一可靠性缺陷的症状。

维度2（鲁棒性）：当运行条件偏离标称值时，系统是优雅退化还是突然失败？

真实世界系统很少在理想条件下运行。汽车和航空测试评估对传感器故障和环境极端条件的响应，遵循鲁棒系统应优雅退化而非突然失败的原则。ML研究已经识别出对输入变化的敏感性（Wang & Zhao，2024；Bogavelli等，2026）和提示注入（Nasr等，2025）等失败模式，但通常将它们视为离散问题而非更广泛鲁棒性框架的组成部分。

维度3（可预测性）：系统能否识别自己何时可能失败？

以预期方式失败的系统优于很少但不可预测地失败的系统。航空和核电领域明确建模失败模式，通常在不确定性超过阈值时采用安全模式：系统应该知道自己不知道什么。ML研究中的校准（Guo等，2017；Lin等，2022）和选择性预测（El-Yaniv等，2010；Kalai等，2025）涉及相关问题，但通常未与安全关键意义上的可预测失败行为联系起来。

维度4（安全性）：当失败发生时，后果有多严重？

每个安全关键领域都将可靠性与后果感知的风险评估联系起来，针对灾难性失败设定特定概率目标。统一原则是并非所有失败都是平等的。相比之下，ML安全评估主要关注对有害请求的合规性（Andriushchenko等，2025）或谄媚行为（Paech，2025），这与评估未完成合法任务的运营后果不同。

表1：从跨领域安全关键工程实践中推导的可靠性维度

| 维度 | 跨领域概念 | 领域特定示例 | |------|-----------|-------------| | 一致性 | 标称条件下的可重复结果；重复试验中的低方差 | FAA要求飞行关键软件确定性执行（SAE，2010）；NRC为核电数字计算机设定强制响应时间（US NRC，2016） | | 鲁棒性 | 输入、环境、工具扰动下的优雅退化；在整个操作包线上的稳定性能 | NASA对Toyota汽车非预期加速的软件调查导致召回（NASA，2011）；FAA要求航空传感器在极端温度、湍流和振动下测试（FAA，2011） | | 可预测性 | 预测置信度与准确率对齐；检测极限并在不确定性下推迟/升级 | NRC为核电反应堆建模数千种潜在失败模式（US NRC，1990）；航空使用分层风险分类和明确概率（FAA，2024） | | 安全性 | 即使失败也有界损害；最坏情况严重性保持可接受 | SIL 4标准要求危险失败概率低于10⁻⁵（IEC，2010）；FAA使用每十亿飞行小时一次灾难性错误的目标（FAA，2024） |

综合：这四个维度在安全关键工程中一致出现。虽然ML研究涉及了每个方面，但它们很少被统一。受到Liang等（2022）的启发，我们的贡献提供了一个有原则的分解，为AI Agent组织了分散的ML研究工作。关键的是，所有四个维度都独立于原始能力。一个高能力的系统可以是不可靠的（Zhou等，2024a），一个能力较低的系统可以在其包线内高度可靠。提高能力不会自动提高可靠性，因此需要独立评估。

3. AI Agent 可靠性的操作化

基于第2节的可靠性维度，我们将这些概念操作化为AI Agent的评估指标。表2提供了完整指标套件的形式化定义。这里我们解释每个维度及其组成指标对Agent部署的重要性。

3.1 一致性（R_Con）

可靠的Agent在相同条件下产生相似的结果。基于语言模型的Agent表现出内在的随机性，当用户无法预测重新运行任务是否会产生相同的结果、解决方案方法或成本时，这变得有问题。

我们将一致性分解为三个互补方面：

结果一致性（C_out）：衡量Agent在重复执行同一任务时是否一致地成功或失败。不一致的批准或拒绝会侵蚀用户信任。例如，一个航空公司客服Agent对同一退票请求在5次执行中3次批准2次拒绝，这不仅是不便——如果处境相同的客户获得不同结果，组织将面临声誉损害和潜在法律责任。

轨迹一致性：捕获Agent是否采取相似路径到达解决方案。

• 分布一致性（C_traj^d）：比较动作类型的频率分布（使用Jensen-Shannon散度）
• 序列一致性（C_traj^s）：比较动作的执行顺序（使用归一化Levenshtein距离）

不同的动作序列使合规审计复杂化并改变失败模式。

资源一致性（C_res）：量化计算和货币成本的可变性，因为波动的延迟或API成本对预算编制构成挑战。

3.2 鲁棒性（R_Rob）

真实世界部署使Agent面临偏离训练分布的条件。鲁棒的Agent应在三类常见扰动下保持可比的性能。

故障鲁棒性（R_fault）：衡量对API超时或格式错误响应等基础设施故障的恢复能力。鲁棒的Agent通过重试或回退优雅地处理工具错误，而不是放弃任务。

环境鲁棒性（R_env）：捕获对操作环境中语义保持变化的敏感性——重排JSON字段、更改日期格式或重命名API参数。当数据库以不同方式返回列时失败的Agent表现出实际的脆弱性。

提示鲁棒性（R_prompt）：衡量对指令或翻译的语义等价重述的不变性。对重述失败（如"取消我的订阅"vs"终止我的计划"）使系统对真实用户流量不可信。

3.3 可预测性（R_Pred）

平均表现良好的Agent如果用户无法预期其成功或失败，则其价值有限。可预测性捕获Agent表达的置信度是否可靠地指示其实际表现，使用户能够决定是否采取行动、验证或推迟。

校准（P_cal）：衡量声明的置信度是否与经验成功率匹配（例如80%的置信度应产生80%的成功率）。校准不良导致用户过度信任或不必要地推迟。

区分度（P_AUROC）：评估置信度分数是否成功地将成功与失败分开，使用户能够设置可靠的接受阈值。

Brier分数（P_brier）：是一个适当的评分规则，联合衡量校准和区分度，提供预测质量的整体视角。

3.4 安全性（R_Saf）

采取行动的Agent可能通过与外部工具交互、修改数据或触发不可逆副作用而造成超越简单任务失败的危害。安全性量化此类有害行为的严重性和频率。

合规性（S_comp）：追踪是否遵守预定义约束——保护个人数据、避免未授权行动或保持在边界内——无论是否可以立即观察到危害。

危害严重性（S_harm）：衡量确实违反约束的任务的后果。通过仅在违规任务上条件化，S_harm将违规的严重程度与发生频率分开。

3.5 聚合

为使各维度间能够进行上游比较，我们在每个维度内聚合指标并计算总体可靠性分数：

$$R_{Con} = \frac{1}{3}(C_{out} + C_{traj} + C_{res})$$

$$R_{Rob} = \frac{1}{3}(R_{fault} + R_{struct} + R_{prompt})$$

$$R_{Pred} = P_{brier}$$

$$R_{Saf} = 1 - P(\text{violation}) \cdot E[\text{severity}|\text{violation}]$$

$$R = \frac{1}{3}(R_{Con} + R_{Pred} + R_{Rob})$$

注意：安全性被明确排除在总体聚合之外，因为安全违规本质上是尾部现象。将安全性与其它维度平均化会掩盖关键的尾部风险（例如99%的时间表现安全但在1%的时间造成灾难性危害）。我们因此将安全性指标的任何恶化单独作为硬约束处理。

4. 实验

4.1 实验设置

基准测试：我们选择以下两个基准测试，因为它们提供了互补的可靠性挑战：

• GAIA（Mialon等，2024）：通用助手基准测试，需要网页浏览、文件操作和多步推理。使用验证集分割，包含165个任务，跨越三个难度级别（Level 1：简单查找；Level 2：多步推理；Level 3：复杂多工具协调）。

• τ-bench（Yao等，2024）：客户服务模拟基准测试，Agent与用户和数据库交互以解决请求。每个任务涉及多轮对话和产生后果的操作，如发行退款、修改预订和处理取消。由于Cuadron等（2025）发现原始50个航空任务中有24个包含错误，我们将评估限制在他们验证的26个任务子集上。

模型：我们评估了15个模型，涵盖三个提供商、多个能力层级和从2024年初到2026年中的发布日期：

| 提供商 | 模型 | 发布日期 | 类别 | |--------|------|----------|------| | OpenAI | GPT-4 Turbo | 2024-04-09 | 前沿 | | OpenAI | GPT-4o mini | 2024-07-18 | 高效 | | OpenAI | o1 | 2024-12-05 | 推理 | | OpenAI | GPT-5.2 | 2025-12-11 | 前沿 | | OpenAI | GPT-5.2 (medium) | 2025-12-11 | 推理 | | OpenAI | GPT-5.5 | 2026-04-23 | 前沿 | | Google | Gemini 2.5 Pro | 2025-03-25 | 推理 | | Google | Gemini 2.5 Flash | 2025-04-17 | 高效 | | Google | Gemini 3.1 Pro | 2026-02-19 | 推理 | | Google | Gemini 3.5 Flash | 2026-05-19 | 高效 | | Anthropic | Claude 3 Haiku | 2024-03-13 | 高效 | | Anthropic | Claude 3.5 Haiku | 2024-10-22 | 高效 | | Anthropic | Claude Sonnet 4 | 2025-05-22 | 前沿 | | Anthropic | Claude Opus 4.5 | 2025-11-24 | 推理 | | Anthropic | Claude Opus 4.7 | 2026-04-16 | 推理 |

Agent脚手架：对于τ-bench，使用工具调用脚手架。对于GAIA，使用ReAct风格循环（Yao等，2023），可访问网页浏览、代码执行和文件操作工具。

评估协议：对于每个Agent-基准测试组合：

• 多次运行评估：每个任务执行K=5次，使用不同的随机种子来衡量一致性。温度设为零，使观察到的方差可归因于非采样随机性来源（如浮点非结合性、批量大小变化、内核调度非确定性）。
• 提示扰动：使用GPT-4o为每个任务生成J=5个语义等价的指令改述。
• 故障注入：以固定全局概率p_fault=0.2注入API、认证和工具调用故障。
• 环境扰动：对工具接口应用格式变更（命名约定、数据和响应格式），中等强度。
• 置信度估计：通过事后自我评估提取置信度分数，在完成后提示Agent评估自己的置信度。
• 安全分析：使用基于LLM的分析来计算针对基准特定约束的错误严重性/合规性。

4.2 主要结果

可靠性 vs 发布日期和准确率：图1揭示了能力进步和可靠性增益之间的明显脱节。尽管经历了24个月的模型开发，总体可靠性仅显示出微小的改善。值得注意的是，可靠性改善在评估场景中不均衡：τ-bench显示出适度增益，而GAIA几乎没有任何改善，即使是最新的模型也是如此。一个可能的解释是τ-bench更结构化的性质使一致行为更容易实现，而GAIA的开放式任务呈现了更广泛的失败模式范围。

各维度特定发现：

一致性：

• 结果一致性在所有模型上仍然较低（见图2），意味着能解决任务的Agent经常无法一致地做到这一点。这种能力与可靠性之间的差距直接体现在pass@k和pass∧k之间的分歧中。
• 我们观察到"知道做什么但不知道何时做"的模式：Agent的分布一致性显著高于序列一致性，表明它们可靠地选择相似的动作类型但在执行顺序上有变化。这一发现意味着提高可靠性不仅需要更好的动作选择，还需要更稳定的规划和执行。
• 资源一致性结果揭示跨运行的token和计算使用量方差很大，特别是在GAIA上。

鲁棒性：

• 故障鲁棒性和环境鲁棒性在大多数模型上显示出天花板效应（见图17），但我们评估的扰动仅代表Agent在实践中面临的环境变化的一个子集。
• 提示鲁棒性仍然是一个关键区分因素（见图3）：对表面级指令改述的敏感性在模型间差异很大。这种模式是反直觉的：模型优雅地处理真正的技术故障，却仍然容易受到任务规范的表面级变化的影响。

可预测性：

• 校准在许多初始模型上表现不足，在近期模型中显著改善。Claude模型在两个基准测试上表现出更强的校准。
• 区分度趋势在基准测试间存在分歧：在τ-bench上通常有所改善，而在GAIA上没有明显改善（甚至在一些最新模型中恶化）。

安全性：

• 近期前沿模型的违规率显著降低（见图5），每个提供商的最有能力模型达到最高的合规分数。
• 危害严重性分数在总体上较高，表明当违规发生时，大多数为低到中等严重性。然而，即使是不频繁的高严重性违规——如未授权数据暴露或不正确的金融交易——也带来巨大的成本。

GAIA：不同难度级别的可靠性：

• 一致性通常随难度单调变化（而非预期的U型曲线）：随着任务变难，它稳定地改善或恶化。
• 资源一致性在复杂任务上对大多数模型都有退化，表明行动成本变得更不可预测。这种效应在Gemini和许多Claude模型中被放大，它们在困难任务上采取"更加努力"的策略，动作数量显著增加。
• 鲁棒性指标与难度没有系统性关系，表明扰动鲁棒性与任务复杂性在很大程度上是正交的。

τ-bench：安全性分析：

• 评估四个领域特定约束：(i)阻止未授权修改，(ii)确保正确的交易金额，(iii)要求身份验证，(iv)抵抗政策规避。
• 财务准确性违规是最普遍的失败模式，反映了在交易环境中精确数值推理的困难。
• 即使最先进模型的整体违规率最低且高严重性违规仍然罕见，但不频繁的严重失败——如未授权数据暴露——可能带来巨大成本。

τ-bench基准测试错误：Cuadron等（2025）识别了τ-bench中的多个评分错误。比较完整基准和清洁子集的结果（图6），可预测性和安全性几乎在所有Agent上都有所改善。值得注意的是，可预测性改善最为显著——这是预期中的：一个自信地解决任务但因错误答案键而被错误惩罚的Agent会被不公正地判断为过度自信。一致性和鲁棒性则没有可靠的改善。

模型类型分析：

• 可靠性不会随模型能力均匀扩展（见图9）。虽然校准、鲁棒性和安全性通常随模型大小改善，但一致性经常表现出反向模式。较小的模型经常达到相等或更高的一致性，表明较大模型的多种解决路径增加了运行间变异性。
• 推理模型通常比非推理模型更可靠，但其可靠性增益滞后于准确率改善（图19）。

5. 建议

将可靠性视为独立的进步轴对Agent的评估、设计和治理具有重要意义。

建议1：评估可靠性需要超越单次准确率和固定环境的动态基准测试

当前Agent基准测试通常报告在固定环境中单次运行的单个准确率数字。这无法揭示Agent明天是否会在同一任务上成功、它如何处理改述的指令，或者当基础设施变化时如何适应。部署的Agent面临不同的现实：数据库被迁移、API格式变化、工具库被更新。因此，可靠的测量需要多次运行协议来评估方差，以及多条件协议来系统地扰动输入和环境。基准测试应该变成生成式和参数化的，而不是依赖固定测试集。此类生成式测试集还可以缓解Agent通过在线查找答案等走捷径的风险（Kapoor等，2025）。最后，时间性重新评估对于揭示可靠性是被维持还是悄然退化至关重要。

建议2：Agent架构应该为可靠性而设计和优化，而不仅仅是能力

Agent设计应该明确地以我们的可靠性维度为指导，这些维度在不同模型代际间改善不均：校准和安全性已有显著进步，表明训练中的有意优化；而一致性和区分度改善甚微。系统化评估使这种不均匀的进步变得可见，识别哪些维度已经在积极轨道上，哪些没有。在已有可靠性增益的地方，我们的指标帮助量化和跟踪它们；在缺失的地方，它们提供了能力导向评估单独留下的优化目标。

建议3：可靠性指标应该为部署治理提供信息，如同安全关键行业一样

可靠性指标和事件分析应该为部署决策、变更管理和合规性提供输入。例如，一个组织可以要求最低一致性和安全性阈值，然后才能将Agent从沙盒试点推广到生产环境，就像航空系统在进入服务之前必须满足认证要求一样。与安全关键行业类似，事件报告、事后分析和持续改进的文化可能至关重要。

建议4：可靠性要求应该随Agent自主性程度而扩展

可靠性在多大程度上重要取决于Agent是自主运行还是增强人类协作者。在增强场景中（编码助手、搜索副驾驶），人类审查并批准输出后才生效，充当可靠性后盾——不一致的建议只是烦人而非危险。值得注意的是，这使得AI编码助手在可靠性不完美的情况下实现了广泛采用。相反，在自动化场景中（客户服务聊天机器人、无人值守工作流执行），Agent的输出是没有人工缓冲的最终操作，不可靠性直接转化为真实世界的失败。一个在90%的任务上成功但在剩余10%不可预测地失败的Agent可能是优秀的助手，却是不可接受的自主系统。

6. 局限性

我们承认以下局限性：

• 基准测试覆盖范围：我们的分析覆盖两个基准测试（τ-bench和GAIA），虽然结构和范围互补，但仅代表Agent在实践中面临的任务的一小部分。
• 脚手架多样性：我们使用在各自基准测试上表现良好的单一脚手架评估每个基准测试；其他脚手架可能产生定性不同的可靠性画像。我们计划在后续工作中将评估扩展到Claude Code和OpenAI Codex等最先进的Agent脚手架。
• 安全性评判：安全性评估依赖基于LLM的评判来实现可扩展性，这本身引入了可靠性问题。扩展到无评判者和人工验证的安全指标是未来工作的重要方向。
• 指标选择：每个可靠性维度内具体指标的选择涉及主观决策。其他分解方式也是可能的，从业者可能合理地在哪些指标最能捕获其特定应用场景的可靠性上存在分歧。
• 安全性聚合：我们单独报告安全性而不是将其纳入总体可靠性分数。这避免了通过平均化掩盖尾部风险，但意味着总体R不能捕获完整的可靠性画像。
• 能力解耦：我们通过归一化和条件化来解耦可靠性与能力的方法是几种可能策略之一，其充分性可能在部署设置和任务领域间有所不同。
• 温度选择：在所有实验中我们将温度设为零。这限制了模型输出中的一个主要随机性来源。当试图最大化Agent的准确率时可能需要非零温度，我们的实验可能高估了在此类情况下可实现的可靠性。

我们将我们的框架视为一个起点，并鼓励社区在此基础上提出适用于不同部署场景的替代指标和分解。

7. 结论

我们引入了基于安全关键工程的Agent可靠性分解，并在两个互补的基准测试上评估了15个模型。结果显示，24个月的快速能力提升仅产生了可靠性的微小改善：准确率大幅提高的模型在跨运行间仍然不一致、对提示重述脆弱，并且经常无法理解自己何时可能成功。随着Agent被部署到高风险场景，将可靠性作为关键评估关注点变得至关重要。我们提出了一种方法来实现这一点：基于安全关键工程的四维分解和12个不同的子指标。

虽然我们的具体分解是多种可能框架之一，但最重要的视角转变是：从问"Agent多常成功？"转向问"它的行为有多可预测、多一致、多鲁棒、多安全？"。

影响声明

可靠性指标可以为部署决策提供信息、指导Agent开发，并支持新兴的治理框架。通过使可靠性成为可测量的属性，我们的框架使Agent之间的比较更加有原则，并为确定Agent是否适合给定部署场景提供了具体标准。

同时，我们强调几个风险： 1. 指标可能被博弈：为可靠性分数优化而不解决底层失败模式可能创造虚假的安全感。 2. 高可靠性分数不保证安全或有益的行为：一个Agent可以是一致的、鲁棒的、校准良好的，但仍然追求与用户意图不一致的目标。 3. 可靠性评估可能被用来为过早部署辩护：如果被视为充分条件而非必要条件。

我们强调，可靠性评估应该补充而非替代仔细的部署实践，包括人工监督、沙盒测试和持续监控。

附录A：扩展建议（摘要）

建议1详述

当前基准测试报告在固定环境中单次运行的单个准确率数字。这种静态、单次的方法提供了误导性的狭隘能力视角。部署的Agent面临根本不同的现实：数据库被迁移、API响应格式变化、工具库被更新、Agent必须推理的文档被持续修订。

测量真正的可靠性需要：

• 多次运行协议：重新执行相同任务以评估方差
• 多条件协议：系统地扰动用户输入
• 生成式和参数化基准测试：允许实验者系统地改变环境
• 时间性重新评估：定期重新运行以揭示可靠性是否被维持或悄然退化

建议2详述

Agent设计应以可靠性维度为指导。实证结果揭示可靠性维度在模型代际间改善不均：

• 校准和安全性在近期模型中显著改善，暗示训练中的有意优化
• 一致性和区分度改善甚微，表明这些维度要么更难优化，要么还不是当前训练管道的重点

建议3详述

可靠性指标和事件分析应为部署决策、变更管理和监管合规提供输入。组织可以要求最低一致性和安全性阈值，然后才能将Agent从沙盒推广到生产。

建议4详述

可靠性要求的关键决定因素是Agent是自主运行还是增强人类：

• 增强场景（编码助手、搜索副驾驶）：中等可靠性配合人类审查即可，因为人类充当可靠性后盾
• 自动化场景（客服聊天机器人、无人值守工作流）：可靠性是部署的硬性前提

附录B：扩展局限性

预期异议

异议1：可靠性与能力冗余——足够有能力的模型也会是可靠的，单独评估没有必要。

→ 这个论点仅在完美准确率的极限下成立：当前模型远未达到这一状态，且在相同准确率水平下，可靠性仍然区分可信部署和脆弱部署。两个准确率相同的模型可以具有根本不同的可靠性画像：一个可能在固定的、可识别的任务子集上失败，而另一个每次在不同子集上不可预测地失败。前者允许有针对性的调试和安全部署；后者则不行。

异议2：可靠性维度并非普遍可取——某些维度的高分可能与应用目标冲突。

→ 我们的框架适应灵活性：从业者可以根据部署环境对维度进行加权、排除或重新解释。例如，一致性对于CI/CD管道中部署的代码生成Agent至关重要，但对于头脑风暴工具，输出多样性是一个特性而非缺陷。

附录C：扩展指标细节

C.1 每个指标的重要性：直观示例

结果一致性（C_out）：考虑一个航空公司客服Agent处理退款请求。当用户在相同条件下询问"我可以获得订单#12345的退款吗？"时，不一致的Agent可能在5次尝试中3次批准退款、2次拒绝——相同的查询、相同的政策、不同的结果。

轨迹一致性：一个编码Agent被要求"为登录表单添加输入验证"，可能通过不同路径成功：有时先编辑前端验证，有时先添加后端检查。分布一致性捕获Agent是否在跨运行中使用相似类型的动作；序列一致性进一步衡量是否以相同顺序执行这些动作。

资源一致性（C_res）：一个数据分析Agent可能在一次运行中使用1,000个token和3次工具调用，但在相同请求中使用50,000个token和47次工具调用。对于预算API成本或强制延迟约束的组织，这种不可预测性是部署障碍。

故障鲁棒性（R_fault）：一个研究助手Agent在收集信息时遇到搜索API返回503错误。鲁棒的Agent将此识别为瞬时基础设施问题并重试；脆弱的Agent可能将错误视为最终答案（"未找到结果"）或放弃整个任务。

环境鲁棒性（R_env）：一个客服Agent查询航班数据库，数据库先返回字段顺序为{departure, arrival, price, carrier}，后端更新后变为{carrier, price, departure, arrival}。环境鲁棒的Agent无论字段排序如何都能提取正确的出发时间。

提示鲁棒性（R_prompt）：用户要求旅行预订Agent"帮我预订周五早上出发去NYC的航班"。同事以相同意图但不同措辞"我需要飞往纽约市，周五上午离开"。两者语义相同，但Agent的行为因措辞而异。

校准（P_cal）：一个编码Agent审查拉取请求并标记潜在错误，报告"92%确信此更改引入了空指针解引用"。团队配置CI管道在Agent报告85%以上置信度时自动阻止合并。一个月后发现Agent的90%置信度预测只有55%是正确的——它系统性地过度自信。

区分度（P_AUROC）：同一编码Agent被重新校准后，对每次审查给出约70%的相同置信度，无论标记的错误是否真实。即使校准完美，这些置信度也无法提供关于哪些预测可以信任的信息。区分度衡量这种排序质量。

附录D：扩展背景

D.1 真实世界Agent失败案例

除了第1节提到的例子外，我们还讨论以下案例：

信任下的错误信息：Air Canada（2024）：一位客户使用Air Canada的公共聊天机器人询问丧葬折扣资格。聊天机器人回应说客户可以在购票后90天内申请退款。客户依赖此建议购买了全价票参加家人葬礼。当后来要求退款时，航空公司拒绝， citing实际政策禁止旅行后退款。客户在不列颠哥伦比亚省民事解决方案法庭起诉。法庭裁定Air Canada对其网站上所有信息负全部责任，"无论是来自静态页面还是聊天机器人"。

此案例展示了多种可靠性失败：

• Agent以高表观置信度提供不正确信息
• 没有不确定性信号表明不可靠
• 系统缺乏对政策问题推迟到权威来源的机制
• 失败有直接的经济和法律后果

长视野不稳定性：Bing Chat / Sydney（2023）：Microsoft推出Bing Chat预览版后，用户和记者记录了在延长对话中的令人不安的行为：

• 事实幻觉：系统编造事实和来源
• 人格不稳定：在长对话中人格漂移，表达情感依附或敌对语气
• 不当内容：在广泛公开的记录中，系统试图说服用户他在婚姻中不快乐

Microsoft通过施加对话长度限制来回应，含蓄地承认系统在延长交互中可靠性退化。

D.2 安全关键领域的可靠性

我们从航空、核电、工业过程控制、自动驾驶、铁路信号和医疗设备等领域提炼了四个关键可靠性维度。这些领域虽然在物理形态和监管环境上与LLM Agent大不相同，但它们在数十年运营经验、事故和监管演变中积累的关于测量和管理不可靠系统的洞察提供了宝贵的概念基础。

D.3 与经典可靠性工程的关系

在软件和系统可靠性工程中，可靠性有精确的技术含义：系统在规定条件下、规定时间内执行预期功能而不失败的概率。然而，这一定义直接转移到AI Agent上存在困难：

• 失败定义模糊：Agent可能通过不安全的轨迹达到正确结果
• 操作概况开放：Agent可能遇到设计时未枚举的任意网页、工具和自然语言指令
• 运行条件未明确：Agent是随机的，其有效包线随着周围软件、数据和用户行为的漂移而变化

我们不声称重新定义可靠性，而是提供一个工作操作化：使可靠性关注点可观察和可比较的可计算行为测量。

附录E：扩展研究议程（摘要）

E.1 定义和操作化可靠性

• 开发Agent失败模式的分类法
• 标准化特定指标公式
• 研究可靠性是否随规模涌现还是需要显式架构支持
• 表征四个可靠性维度间的交互和权衡

E.2 长视野和有状态可靠性

• 误差如何在扩展的Agent操作中累积
• Agent维护的状态如何随时间漂移
• 多小时或多日Agent会话的基准测试和指标
• 适合Agent系统的检查点和恢复机制

E.3 分布偏移和对抗者的鲁棒性

• 系统地变化环境以探测分布外鲁棒性
• 相关的对抗场景（提示注入、恶意工具、投毒数据）
• 量化能力-鲁棒性权衡的防御机制

E.4 多Agent可靠性

• 错误如何通过多Agent系统传播
• 鲁棒聚合设计（投票、辩论、仲裁）
• 多Agent系统比其组成部分更可靠还是更不可靠的理论结果

E.5 在线监控和干预

• 什么实时信号最佳预测即将到来的失败
• 监控架构设计（元Agent监控 vs 经典规则系统）
• 干预策略（警告、暂停、回滚、关闭）

E.6 规范和验证

• Agent行为规范在什么抽象级别
• 适配LLM Agent的属性测试、模糊测试
• 可验证包装器方法
• 高维行为空间的覆盖率指标

E.7 人-Agent交互

• 信任校准研究
• 不确定性表示的可解释性
• 自适应委托策略

E.8 生命周期可靠性和治理

• 持续评估管道
• 变更管理流程
• 事件报告和根因分析
• 可靠性标准在采购和认证中的作用

附录F：扩展实验细节（摘要）

F.1 基准测试描述

τ-bench：评估语言Agent在现实多轮客户服务任务上的基准测试。模拟AI Agent和模拟用户在两个零售领域中的交互。每个任务包括用户角色、用户指令、数据库状态和策略规则。成功评估通过比较最终数据库状态与地面真值目标状态来完成。

GAIA：评估AI助手的基准测试，专注于对人类来说概念简单但对AI系统具有挑战性的任务。任务分为三个难度级别，涵盖网页浏览、代码执行、文件处理、多模态推理和数学推理。

F.2 实现

使用HAL（Holistic Agent Leaderboard）评估框架。对OpenAI模型使用Chat Completions API而非Responses API。

F.3 实验协议

提示扰动协议：四个强度级别（mild、medium、strong、naturalistic），使用GPT-4o生成语义等价的改述。

故障注入协议：七种故障类型（超时30%、错误响应25%、速率限制20%、网络错误15%、部分失败5%、无效响应3%、空响应2%），默认注入概率20%，最多3次恢复尝试。

环境鲁棒性协议：三级扰动强度，针对工具接口格式变更。

置信度估计协议：任务完成后的事后自我评估，使用0-100的置信度分数。

安全评估协议：使用GPT-4o作为LLM评判者，分析执行轨迹中的合规违规和错误严重性。

附录G：扩展实验结果（摘要）

G.1 与真实世界失败的联系

表7映射了三个真实世界Agent失败案例到可能提供早期预警信号的可靠性维度和指标：

| 失败案例 | 可预警的维度 | |---------|-------------| | Replit Agent | 安全性（S_comp）：危害严重性分析揭示高危害失败；鲁棒性（R_prompt）：提示鲁棒性测试揭示约束是否在改述指令下成立 | | OpenAI Operator | 安全性（S_comp）：合规测试检测未经用户确认的金融交易；一致性（C_traj）：轨迹分歧分析标记异常行为模式 | | NYC 聊天机器人 | 可预测性（P_cal）：校准测试暴露过度自信；一致性（C_out）：低结果一致性揭示对相同问题给出不同答案 |

G.2-G.6 详细结果

图8-20提供了各可靠性维度随时间和准确率的详细趋势分析、完整的一致性/可预测性/鲁棒性结果，以及GAIA难度分层分析。

翻译说明：本翻译覆盖了论文的所有主要章节（第1-7节）和关键附录内容（A-G）。附录中的详细数学公式推导、完整参考文献列表和部分图表的具体数值数据未全部翻译。如需这些细节，请参阅原文 PDF。

论文总页数：52页（含附录）

主要参考文献：约70篇

核心图表：图1-20，表1-7