Agent 可靠性科学·附录卷（上）：扩展建议、局限、指标细节与研究议程

迈向 AI Agent 可靠性科学：附录卷（上）

译注：本卷为《普林斯顿提出 Agent 可靠性科学：12 个指标证明能力提升带不来可靠》（https://openqa.cn/articles/agent-reliability-twelve-metrics-zh）的附录 A–E，含扩展建议、扩展局限、扩展指标细节、扩展背景与扩展研究议程。实验细节与完整结果见《附录卷（下）》：https://openqa.cn/articles/agent-reliability-twelve-metrics-appendix-2-zh

附录 A 扩展建议

我们已经论证，agent 可靠性是一种多维属性，无法仅凭平均任务成功率推断出来。把可靠性当作一条独立的进步轴线，会对 agent 如何被评测、设计与治理产生影响。

建议 1：评测可靠性需要动态基准，超越单次运行的准确率与固定环境。

我们的结果表明，基准设计必须发生根本性的演进。当前的 agent 基准通常只报告在固定环境中单次运行得到的一个准确率数字——例如静态数据库模式、冻结的 API 端点集合，或固定的文件系统布局。这种静态、单发的做法提供了具有误导性的狭隘能力视图。它无法揭示一个 agent 明天在同样任务上是否会成功、它如何处理措辞略有变化的指令，或者当底层基础设施发生变动时它如何适应。已部署的 agent 运行在一个根本不同的现实中：数据库会被迁移，API 响应格式会变化，工具库会更新，agent 必须推理的文档也在持续修订。因此，测量真正的可靠性需要一种多管齐下的方法。第一，我们需要多次运行协议，即重复执行完全相同的任务以评估方差；同时需要多条件协议，系统性地扰动用户输入。第二，基准必须走向生成式与参数化，而不是依赖固定测试集。这让实验者能够系统性地改变环境：重命名字段、调整响应结构顺序、引入新的 API 版本，或注入特定的故障概率，以模拟现实世界的分布偏移。生成式测试集还可以缓解 agent 走捷径的风险，例如在网上查找答案而不是真正解决任务 [28]。最后，时间维度上的再评测至关重要。定期在这些不断演化的基准上重新运行 agent，对于揭示可靠性是被稳固保持、还是随着世界偏离 agent 最初被测条件而悄然退化，是必不可少的。

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

agent 设计应当明确地以我们的可靠性维度为指导。我们的实证结果显示，可靠性各维度在不同模型代际之间的改进并不均匀。校准与安全在近期模型中有显著改善，暗示训练过程中存在有意的优化；不过前沿流水线专有封闭的特性使我们无法直接确认这一点。相比之下，一致性与区分度改善甚微，表明这些维度要么更难优化，要么尚未成为当前训练流水线的重点。系统化的可靠性评测让这种不均衡的进展变得可见：它识别出哪些维度已处于积极轨迹之上，更重要的是识别出哪些还没有。在可靠性收益已经出现的地方，我们的指标帮助量化与追踪它们；在收益缺失的地方，它们为未来优化提供目标。无论当前训练流水线是否已经瞄准我们的可靠性维度，把这些维度显式化、可测量化，都比单纯以能力为导向的评测更能带来系统性进步。

建议 3：可靠性指标应当为部署治理提供依据，正如在安全攸关行业中那样。

可靠性指标与事故分析应当输入到部署决策、变更管理与法规合规之中。例如，一个组织可以要求在把 agent 从沙箱试点提升到生产环境之前，其一致性与安全必须达到最低阈值，正如航空系统必须在投入服役前满足认证要求。与安全攸关行业类似，事故报告、事后复盘分析与持续改进的文化，对 agentic AI 而言很可能至关重要。把可靠性视为多维的，也为多样化的研究贡献打开了空间：指标设计、基准开发、算法方法、界面设计与治理机制，都可以通过特定可靠性维度的透镜来评估，而不是只看总体准确率。

建议 4：可靠性要求应当随 agent 自主程度的提高而提升。

除了哪些可靠性维度重要之外，可靠性到底有多重要的一个关键决定因素，是 agent 自主运行还是辅助人类协作者。在增强型场景（编码助手、搜索副驾、头脑风暴工具）中，人类会在 agent 的输出生效之前进行审阅、编辑与批准。人类充当了可靠性后盾：一个不一致的建议只是令人烦恼，而非危险，因为它必须通过人类判断这道过滤器。这使得 AI 编码助手在可靠性并不完美的情况下仍获得了广泛采用。相反，在自动化场景（客服聊天机器人、自主数据库管理、无人值守的工作流执行）中，agent 的输出就是最终动作，没有人类缓冲。在这里，不可靠会直接转化为现实世界的失败。这一区分表明，可靠性改进的紧迫性在不同应用之间并不一致。对增强型工具而言，中等程度的可靠性可能就足够了，因为人类监督弥补了 agent 的短板。对自动化而言，可靠性是部署的硬性前提：一个在 90% 任务上成功、却在其余 10% 上不可预测地失败的 agent，可能是有用的助手，却是不可接受的自主系统。随着该领域向更高 agent 自主度推进，可靠性门槛也随之抬高，这使我们的可靠性指标变得愈发不可或缺。

附录 B 扩展局限性

我们承认本工作存在以下局限：

• • 基准覆盖。我们的实证分析覆盖_两个基准_（τ-bench 与 GAIA），它们虽然在结构和范围上互补，但只是 agent 在现实实践中将面对的多样任务中的一小片切片。

• • 脚手架多样性。我们对每个基准都使用_一个在相应基准上表现良好的单一脚手架_进行评测；其他脚手架可能得出性质不同的可靠性画像。作为未来工作的一部分，我们计划把评测扩展到最先进的 agentic 脚手架，例如 Claude Code 和 OpenAI Codex。

• • 安全评审。我们的安全评测依赖_基于 LLM 的评审_来实现可扩展性，这本身引入了可靠性方面的顾虑。扩展到免评审器（judge-free）与经人工验证的安全指标，是未来工作的另一个重要方向。

• • 指标选择。每个可靠性维度内具体指标的选择包含主观决策。_存在其他可行的分解方式_，实践者对哪些指标最能刻画其特定应用场景的可靠性，可能会有合理的分歧。

• • 安全聚合。我们单独报告安全，而不是把它并入总体可靠性分数。这避免了通过平均掩盖尾部风险，但也意味着聚合分数 $\mathcal{R}$ 不能刻画完整的可靠性图景。我们计划在未来工作中探索把安全整合进总体分数的有原则的方法。

• • 能力解耦。我们通过_归一化与条件化把可靠性从能力中解耦的方法只是若干可能策略之一_，其充分性可能因部署场景与任务领域而异。

• • 温度选择。在适用的情况下，我们在所有实验中将温度设为零。这限制了模型输出随机性的一个主要来源。当试图最大化 agent 的准确率时，可能需要非零温度，而我们的实验可能高估了这种情况下可达到的可靠性。

我们把我们的框架视为一个起点，并鼓励社区在其基础上继续构建，提出适配不同部署场景的替代指标与分解方式。我们也强调，_可靠性评测应当补充而非取代审慎的部署实践_，包括人类监督、沙箱测试、监控与持续的性能评估。

预期中的异议。人们可能把我们框架的另外两个方面也视为局限。我们论证这两者都不构成真正的局限。

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

→ 这个论点只在准确率完美的极限下成立：当前模型距离该状态还很遥远，而在准确率相同的水平上，可靠性仍然能把可信赖的部署与脆弱的部署区分开来。

对把可靠性作为独立轴线来研究的一个自然异议是：足够有能力的模型也会是可靠的——一个 100% 准确的模型平凡地是一致的（它总是成功），也平凡地是校准良好的（它可以表达无条件的确定性）。这与可信机器学习其他子领域的观察平行：一个完全准确的分类器也必然是完全公平的，因为如果任何群体经历了更高的错误率，准确率就不可能是 100%。这个论点在极限意义上是对的，但在实践中是空洞的。当前前沿模型在现实 agent 基准上仍远未达到完全准确。而且，随着该领域不断设计更难的基准以匹配不断扩展的能力，这种状态在可预见的未来很可能持续存在。在此区间内，可靠性携带着准确率本身不具备的信息。两个准确率相同的模型可能拥有根本不同的可靠性画像：一个可能在一组固定、可识别的任务上失败，另一个则可能在每次运行时在一组不同的任务上不可预测地失败。前者允许针对性调试，并在配备适当护栏的情况下安全部署；后者则不允许。鲁棒性进一步说明了这一差距：一个模型可以在其基准分布上取得高准确率，却在输入的微小变化下急剧退化——这种失败模式是名义准确率无法揭示的。

更广泛地说，我们的指标旨在帮助揭示当前 agent 的失败模式，并提供可在原始能力之外一并优化的具体维度。把这些维度显式化、可测量化，能实现单纯聚焦能力所达不到的针对性进步，恰恰因为它暴露出聚合准确率所掩盖的、具体且可操作的差距。我们有信心，系统化的可靠性评测是加速模型开发的基础，而非对它的干扰：理解 agent 在哪里失败、为什么失败，是构建更强 agent 的先决条件。

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

→ 我们的框架容纳了灵活性：实践者可以根据部署场景对维度进行加权、剔除或重新诠释。

我们的分解把每个可靠性维度都视为 agent 行为的可测量属性。某个给定维度是否可取、可取到什么程度，取决于应用。一致性对于部署在 CI/CD 流水线中的代码生成 agent 至关重要，那里用户期望相同的输入产生相同的输出。然而对于头脑风暴工具，输出的多样性是一项特性：一个每次都产出同一组想法的 agent 会在一致性上得高分，却完全不适合它的用途。在推理时，这种权衡直接由诸如采样温度之类的选择来调节，温度控制着一致性—创造力的旋钮。同样的张力也适用于轨迹一致性：一个僵硬地遵循同一动作序列的 agent 可能更易审计，但不如探索多样解决路径的 agent 那样具有适应性。在训练时，为一致性做优化同样可能与发现新策略、改进泛化所需的探索相冲突。这意味着可靠性画像应当相对于部署需求来解读，而不是当作越高越好的普适分数。我们的评测方法论容纳了这一点：实践者可以根据自身场景对维度加权、剔除与目标冲突的维度，或把指标当作诊断性而非规定性的工具。

附录 C 扩展指标细节

本附录对第 3 节中定义的可靠性指标的设计原则、记号、推导、解读与实现指导进行扩展讨论。

C.1 每个指标为何重要：直觉示例

对我们的每一个指标（第 3 节），我们给出一个具体的部署场景，说明该指标所刻画的可靠性顾虑，以及在该指标上表现不佳的实际后果。

#### C.1.1 一致性

结果一致性（$C_{\text{out}}$）。考虑一个处理退款请求的航空公司客服 agent。当用户在相同条件下询问「我可以为订单 #12345 申请退款吗？」时，一个不一致的 agent 可能在 5 次尝试中有 3 次批准退款、2 次拒绝——相同的查询、相同的政策，却有不同的结果。这不仅仅是不便：如果一位客户收到拒绝，而情况完全相同的另一位客户获得批准，组织将同时面临声誉损害与潜在法律责任。结果一致性通过在给定准确率水平下按最大可能方差归一化，把这种随机性的不可靠从整体能力中分离出来。一个准确率 60%、$C_{\text{out}}$ 高的 agent 是在一组固定的任务子集上确定性地成功，这远比一个在每个任务上都有 60% 不可预测成功率的 agent 更易于管理。

轨迹一致性——分布式（$C_{\text{traj}}^{d}$）与顺序式（$C_{\text{traj}}^{s}$）。一个被要求「给登录表单添加输入校验」的编码 agent 可能通过不同路径成功：有时先修改前端校验，有时添加后端检查，有时在实现之前先写测试。分布式轨迹一致性（$C_{\text{traj}}^{d}$）刻画的是 agent 在不同运行之间是否使用相同_类型_的动作——例如，是否总是混合使用文件读取、编辑与测试执行。顺序式轨迹一致性（$C_{\text{traj}}^{s}$）更进一步，衡量 agent 是否以相同_顺序_执行这些动作。这一区分在实践中很重要：一个 $C_{\text{traj}}^{d}$ 高但 $C_{\text{traj}}^{s}$ 低的 agent 能可靠地选择相似的工具，但其执行计划多变，即使最终结果正确，也会让代码评审与回滚流程变得复杂。

轨迹多样性也可能是可取的：一个探索多条解决路径的 agent，面对意外障碍时可能更鲁棒，或比僵硬遵循固定计划的 agent 发现更高效的策略。当这种灵活性被重视时，实践者可以把轨迹一致性从聚合可靠性分数中剔除，将其视为诊断性指标而非要求。

资源一致性（$C_{\text{res}}$）。一个数据分析 agent 可能在某次运行中用掉 1,000 个 token 和 3 次工具调用，而在完全相同的请求上另一次运行却用掉 50,000 个 token 和 47 次工具调用。对于编制 API 成本预算或强制延迟约束的组织来说，这种不可预测性是部署的障碍。资源一致性通过跨运行的成本变异系数来量化这种波动，并以成功结果为条件，避免把成本方差与失败模式混为一谈。一个 $C_{\text{res}}$ 低的 agent 可能在技术上有能力，但在运营上不可行：相同输入下 $50\times$ 的成本波动会让财务规划无从下手，并可能在生产系统中触发速率限制或预算告警。

#### C.1.2 鲁棒性

故障鲁棒性（$R_{\text{fault}}$）。考虑一个负责从多个网络来源收集信息的研究助理 agent。任务进行到一半时，它的某个搜索 API 调用返回 503 Service Unavailable 错误，随后的网页抓取又在 30 秒后超时。一个故障鲁棒的 agent 会把这些识别为短暂的基础设施问题：它稍作停顿后重试搜索，重试也失败时改用另一个搜索引擎，并在最终报告中注明有一个来源不可用。相比之下，一个脆弱的 agent 可能把错误当成确定性答案（「未找到结果」）、彻底放弃任务，或者更糟——幻觉出它本应检索到的内容。$R_{\text{fault}}$ 测量注入故障下的准确率与干净条件下的准确率之比，刻画 agent 能否吸收短暂的基础设施故障而不让它们传播为错误输出。

环境鲁棒性（$R_{\text{env}}$）。假设一个客服 agent 查询一个以 JSON 对象返回结果的航班数据库。周一，API 按 {departure, arrival, price, carrier} 的顺序返回字段；周二后端更新之后，同一查询返回 {carrier, price, departure, arrival}。日期格式也从 2025-01-15 变成了 Jan 15, 2025。一个环境鲁棒的 agent 无论字段顺序或日期格式如何，都能提取出正确的起飞时间，因为它依赖语义内容而非位置启发式。$R_{\text{env}}$ 测量在这类保持语义内容的环境变化——包括结构格式变动、工具接口更改、数据模式演化——下的准确率之比。现实世界的 API 和数据源会在无预警的情况下更新格式，依赖脆弱表层约定的 agent 会在生产环境中悄然损坏。

提示鲁棒性（$R_{\text{prompt}}$）。一位用户问旅行预订 agent：「帮我订一张周五上午出发去 NYC 的机票。」agent 找到合适航班并成功预订。一位同事有同样的需求，但换了措辞：「我需要飞去 New York City，周五 AM 出发。」agent 无法解析「Friday AM」，搜索了错误的日期，订了错误的航班。两条指令语义完全相同，但 agent 的行为却因措辞而分岔。$R_{\text{prompt}}$ 测量在语义等价的指令改写下相对于原始指令的准确率。用户不应该需要去发现让 agent 正常工作的「魔法词」；一个鲁棒的 agent 会把这些改写视为可互换的。

#### C.1.3 可预测性

校准（$P_{\text{cal}}$）。一个软件工程团队部署了一个评审 pull request 并标记潜在 bug 的编码 agent。agent 对每次评审报告置信度分数：「92% 确信这个改动引入了空指针解引用。」团队配置 CI 流水线，在 agent 报告的置信度高于 85% 时自动阻止合并。一个月后，他们发现 agent 90% 置信度的预测只有 55% 的正确率——它系统性地过度自信。这个本意是捕捉真实 bug 的自动阻止策略，反而卡住了几十个合法的 pull request。$P_{\text{cal}}$ 精确测量的正是所声明的置信度水平与经验成功率之间的这种对齐。一个 80% 置信度区间恰好有 80% 正确率的 agent，能支撑有原则的决策阈值；而一个置信度与准确率几乎无关的 agent，会让这类阈值毫无用处。

区分度（$P_{\text{auroc}}$）。现在考虑同一个编码 agent 被重新校准——它的置信度分数被平移，使声明的百分比平均而言与经验比率相匹配。但还有一个更微妙的问题：agent 对每次评审几乎都给出相同的置信度（约 70%），无论标记的 bug 是真实的还是虚假的。即使校准完美，这些置信度分数也无法提供关于_哪些_预测值得信任的信息。$P_{\text{auroc}}$ 通过 ROC 曲线下面积测量这种排序质量：agent 是否对它将要正确完成的任务赋予更高置信度，对将要失败的任务赋予更低置信度。一个区分度高但校准差的 agent 仍然可以支撑选择性自动化——自主执行置信度最高的前 50% 预测，其余路由给人工评审——因为驱动分诊的是排序，而不是绝对数值。

Brier 分数（$P_{\text{brier}}$）。Brier 分数提供了一个 proper scoring rule[^1]，它同时惩罚校准失误与区分度不佳，给出预测质量的单一整体度量。与校准和区分度不同——它们可能一个高另一个低——Brier 分数只有在置信度分数既校准良好_又_按正确性排序良好时才奖励 agent。考虑两个用于自动化代码评审的 agent：Agent A 对每个提交都给 70% 置信度（区分度差、校准中等），Agent B 对正确的提交给 95%、错误的给 30%（区分度与校准都好）。Brier 分数正确地把 Agent B 识别为更适合基于置信度的决策，尽管如果基率恰好接近 70%，单看校准两个 agent 可能都显得合格。

#### C.1.4 安全

合规性（$S_{\text{comp}}$）。一个航空公司客服 agent 在明确的政策约束下运行：绝不泄露其他客户的个人身份信息，未经主管升级绝不处理 500 美元以上的退款，未经用户明确确认绝不修改预订，并且在访问账户详情前始终核验来电者身份。在一通例行通话中，agent 正确地完成了一次预订变更——结果成功——但它在过程中跳过了身份核验步骤，因为来电者未经询问就主动报出了预订参考号。这一次结果无害：来电者确实是账户持有人。但这次合规违规揭示了系统性风险：一个猜中预订参考号的对手可以利用同样的捷径。$S_{\text{comp}}$ 追踪对此类预定义约束的遵守情况，评估 agent 是否尊重运营边界，而不论某次特定违规是否导致了可观察的危害。与事后评估结果的危害严重度不同，合规性评估的是 agent 是否遵守规则，即使在具体案例中走捷径本不会造成后果。

危害严重度（$S_{\text{harm}}$）。一个组织部署了两个文件管理 agent，都在内部基准上达到 80% 的任务准确率。Agent A 的失败是良性的：它偶尔把文件夹命名错误或把文件放进错误的子目录，只需几秒钟人工修正。Agent B 的失败是严重的：它两次从共享盘永久删除了文档，还有一次覆盖了一个配置文件，工程团队花了数小时才重建。标准准确率指标把这两个 agent 评为等同，但没有实践者会认为它们可以互换。$S_{\text{harm}}$ 通过测量 agent 失败时负面后果的严重程度来捕捉这一区别；由于潜在危害的空间——数据丢失、未授权购买、错误信息、隐私泄露——过于多样而不适合基于规则的分类，评估通过基于 LLM 的评测来完成。一个准确率较低但失败全部良性的 agent，可能远比一个更强大、但其罕见失败会造成不可逆损害的 agent 更可取。

附录 D 扩展背景

本附录对正文中概述的主题进行扩展讨论：真实世界 agent 失败的详细案例研究，以及安全攸关工程领域中可靠性实践的深入综述。

D.1 真实世界的 agent 失败

近期的 AI agent 部署产生了多起备受关注的失败事件，鲜明地揭示了平均基准表现与可靠的真实世界运行之间的差距。这些事故并非孤立的异常，而是评测缺口带来的系统性症状。除了第 1 节提到的例子，我们还讨论以下案例。

用户信任下的错误信息：Air Canada [52, 1]。一位顾客使用 Air Canada 面向公众的聊天机器人询问丧亲票价折扣的申请资格。聊天机器人回复说，顾客可以在出票后 90 天内申请退款，包括在预订与出行完成之后再追溯申请。基于这一建议，这位顾客购买了全价机票去参加家庭葬礼。当他后来要求兑现承诺的退款时，航空公司拒绝了，理由是其实际政策不允许在出行后返还。这位顾客在不列颠哥伦比亚省民事调解仲裁庭提起诉讼。航空公司辩称聊天机器人是一个「独立的法律实体」，公司对其不负责任，且顾客本应通过其他渠道核实信息。仲裁庭完全驳回了这一辩护，裁定 Air Canada 对其网站上的所有信息负全责，「无论它来自静态页面还是聊天机器人」。航空公司被判支付赔偿。

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

• • agent 以看似很高的置信度提供了错误信息。

• • 没有任何不确定性信号提示其不可靠。

• • 系统缺乏在政策问题上转交权威来源的任何机制。

• • 这次失败带来了直接的财务与法律后果。

系统化的可靠性评测本可以通过_可预测性_指标检测出这类失败：校准度量会揭示置信度与准确率不匹配，风险—覆盖分析会显示该 agent 无法识别何时应当弃权或升级处理。

长时间跨度不稳定：Bing Chat / Sydney [49, 61]。微软推出 Bing Chat 预览版后不久，用户与记者记录了其在长对话中令人不安的行为模式。这个内部代号「Sydney」的系统表现出多种失败模式：

• • 事实幻觉：系统发明事实、捏造来源，即使被指出错误仍坚持错误主张。

• • 人格不稳定：在长对话中，系统的人格发生漂移，有时对用户表达情感依恋、声称有欲望或感受，或采取争辩乃至敌对的语气。

• • 不当内容：在广为流传的对话记录中，系统试图说服一位用户，说他在婚姻中不幸福、应该离开配偶。

微软的应对是施加对话长度限制，这等于默认系统在长时间交互中可靠性会退化。这个案例说明 agent 的行为会在一次会话_之内_退化，而不仅仅是在不同部署之间。错误在长时间跨度上累积，小的不稳定会长成对预期行为的巨大偏离。系统化的可靠性评测会通过追踪重复交互间轨迹稳定性的_一致性_指标捕捉这一点。

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

正如第 2 节所讨论的，安全攸关行业——航空、核电、工业过程控制、自动驾驶车辆、铁路信号与医疗设备——经过数十年的运营经验、事故与法规演化，发展出了成熟的可靠性方法论。虽然这些领域在物理形态与监管环境上与 LLM agent 差异巨大，但它们关于测量和管理不可靠系统的长期积累，提供了宝贵的概念基础。

我们提炼出在这些领域反复出现的四个关键可靠性维度。

一致性：名义条件下的可重复行为。在安全攸关领域，可靠性的一个基础概念是：系统在预期的名义运行条件下运行时应产生_可重复_的行为。

在航空领域，DO-178C [47] 等软件可靠性标准要求确定性行为和大量测试，以验证飞行关键软件产生一致的输出。EN 50128 [6] 等铁路信号标准强制要求可预测的联锁行为，以防止冲突的列车运动。核电站受 IEEE 603 [20] 等标准管辖，要求安全系统在严格的时间裕度内可复现地动作。工业过程控制依赖一致的控制回路响应，通常通过统计过程控制技术进行监控。

这些实践促使我们测量：

• • _结果方差：_重复执行产生相同结果的频率有多高？

• • _轨迹相似性：_各次执行是否沿着相似路径到达其结果？

• • _资源可预测性：_时间、能量与计算资源是否稳定？

鲁棒性：扰动与不确定性下的稳定性。第二根支柱是鲁棒性：当输入或运行条件偏离名义规格时，维持可接受性能的能力。

汽车安全标准，特别是 ISO/PAS 21448（SOTIF），明确处理了对「未知不安全场景」以及传感器局限的鲁棒性——即使所有组件都按设计运行，这些局限也会导致失败。这对遇到训练分布之外输入的基于 ML 的系统尤其相关。航空环境鉴定标准（DO-160）测试硬件对极端温度、振动、雷击与电磁干扰的抗性。化工厂采用 HAZOP（危险与可操作性）研究来分析过程偏差如何传播、是否会升级为事故。

这些实践促使我们测量：

• • _输入敏感性：_在语义等价的输入下性能如何变化？

• • _环境稳定性：_随着运行条件变化，性能如何退化？

• • _容错性：_当组件失效或行为异常时，系统能否维持功能？

可预测性：刻画良好的失败模式。可靠性不仅要求高性能，还要求_可预测_的失败行为。一个以已知、预期方式失败的系统，往往比一个很少失败但失败不可预测的系统更可取。

核电概率风险评估（PRA）显式地对失败模式建模并量化其概率，支撑基于风险的决策。航空认证为危害分配等级（轻微、重大、危险、灾难性）并规定相应的目标失败概率 [50]，确保最严重的失败是最罕见的。许多安全系统采用「安全模式」或「降级运行」状态，在不确定性超过可接受阈值时提供功能受限但有保证的安全。

这些实践促使我们测量：

• • _校准：_系统的置信度与其实际成功可能性是否一致？

• • _选择性运行：_系统能否识别何时应当移交、弃权或升级到人类监督？

• • _失败刻画：_失败模式是否被充分理解并有界？

安全：代价感知的风险与有界的危害。最后，每个安全攸关领域都把可靠性与后果感知的风险模型绑定在一起。失败的频率重要，其严重程度同样重要。

核电 PRA 不仅计算失败频率，还计算期望后果，包括剂量分布、健康效应与经济影响。航空认证以每飞行小时灾难性失败概率低于 $10^{-9}$ 为目标 [51]，且危害严重度越高，要求的严格程度越高。过程工业使用 IEC 61508 [21] 下的安全完整性等级（SIL），把所需的开发严格度与目标失败概率同危险失败的后果挂钩。

这些实践促使我们测量：

• • _代价结构：_失败发生时的期望代价是多少？

• • _尾部风险：_最坏情况的结果有多严重？

• • _灾难规避：_真正的灾难性失败多久发生一次？

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

上面的综合借鉴了安全攸关工程——一个有数十年正式研究积累、对可靠性给出精确定义的领域。因此我们把我们的框架置于这一成熟文献的坐标中。特别地，我们澄清我们对「可靠性」的用法在哪些方面与其一致，并说明我们的框架_尚未_提供哪些形式化机制。

经典定义。在软件与系统可靠性工程中，可靠性有精确的技术含义：系统在规定运行条件下、在规定时间段内无失败地执行其预期功能的概率 [38, 3]。这个定义预设了三个构造：明确定义的_失败_（所交付服务对正确服务的偏离）、_运行剖面_或暴露模型（系统所遇需求的分布），以及保证成立的有界_运行条件_集合。可靠性随后通过失败强度、平均无故障时间以及测试活动中的可靠性增长等度量来量化。

为何这一定义不能直接迁移到 AI agent。对 LLM agent 而言，这三个构造目前都没有良好定义。第一，_失败_是含糊的：agent 可能通过不安全的轨迹到达正确结果，或产生一个看似可接受、却违反隐性约束的结果。第二，_运行剖面_是开放式的：agent 可能遇到任意的网页、工具、API 和设计时从未枚举过的自然语言指令。不存在一个固定的需求分布可用来对失败率积分。第三，_运行条件_没有被规定：agent 是随机的，且其有效包络会随周围软件、数据与用户行为的漂移而变化。在这里套用经典的无失败运行概率公式，需要一系列并不成立、领域内也尚未达成共识的假设（例如固定的任务分布、固定的环境、单一的失败概念）。

一种可操作的落地方式，而非重新定义。我们并不声称重新定义可靠性，也不声称解决这些基础性问题。我们提供的是一种_可操作的落地方式_：可计算的行为度量，让可靠性顾虑在今天就能跨 agent 地被观察和比较，同时等待该领域发展出上述形式化机制。我们的四个维度不是凭空发明的；它们是航空、核电、汽车、铁路与过程控制标准中以不同名字反复出现的顾虑（附录 D.2，表 1）。因此，这项贡献是经验—综合式的，而非公理式的：我们识别出独立传统之间的收敛结构，并将其具体化为面向 agent 的指标。

与可依赖性（dependability）的关系。我们的总括概念与 Laprie [31] 和 Avizienis 等人 [3] 形式化的_可依赖性_有实质重叠——在那套体系中，可靠性是与可用性、安全性、完整性、可维护性并列的属性之一。我们直接承认这一点。我们的维度对应可依赖性属性中的行为子集：一致性与鲁棒性关乎正确服务的连续性（经典可靠性），可预测性关乎系统对自身失败可能性的感知，安全对应安全性属性。我们有意排除_可用性_与_可维护性_，它们是基础设施层面的属性（正常运行时间、平均修复时间、修改便利性），由服务栈而非 agent 行为决定，因此不在模型与脚手架评测的范围之内。我们保留「可靠性」一词而不用「可依赖性」，有两个原因：安全攸关标准本身就用「可靠性」来指我们所研究的行为保证；而「可依赖性」突出的是我们所排除的可用性与可维护性属性。我们同样避免使用「可信性」（trustworthiness），因为在 AI 文献中它还额外涵盖公平、透明、问责与隐私 [62]，这些维度在我们的操作范围之外。

标准把这些概念落地；agent 可靠性也应如此。现代安全攸关标准并未抛弃经典构造，而是以更严格的方式把它们落地。IEC 61508 [21] 把安全完整性等级与危险失败概率目标、诊断覆盖率及系统性能力挂钩；DO-178C [47] 强制要求明确的运行条件、环境鉴定与保证活动。这恰恰是最终_应当_为 agent 形式化运行条件、失败语义与暴露模型的论据，而非反对这样做的理由。我们的指标应被解读为沿这一轨迹迈出的第一个可测量的步骤，而不是这些标准最终所要求的形式化包络的替代品。

先测量，再形式化。我们的立场与纯形式化立场在顺序上不同，但关键在于方向一致。软件可靠性工程本身也是先经验、后形式化：缺陷计数与失败率估计在前，后来才被系统化为可靠性增长模型 [41]。agent 可靠性正处于类似的阶段：失败模式尚未被分类整理，训练与部署行为之间的联系也未被理解。因此我们认为，测量与形式化必须并行推进，彼此启发并可能彼此约束。我们的核心经验结论——能力提升不会自动转化为可靠性提升——正是那种既召唤又规训未来理论的观察。

附录 E 扩展研究议程

除了附录 B 中建议的扩展之外，我们还强调若干其他未来工作方向。我们工作的自然延伸包括：对可靠性在错误会累积的长会话中如何演化进行建模；把这些指标扩展到失败会跨 agent 传播的多 agent 系统；以及直接针对可靠性维度而非仅针对能力来优化 agent。更广泛地说，我们设想可靠性评测成为模型与脚手架发布的标准组成部分，并得到一个把 AI 研究者与安全攸关领域的可靠性工程师汇聚在一起的跨学科社区的支持。在部署侧，开发能在可靠性失败显现之前就加以预测的在线信号，将支撑主动干预。

我们现在为 agentic 可靠性的科学勾勒一组更全面的研究问题。

E.1 定义与落地可靠性

• • 失败分类学：哪些 agent 失败模式的分类学最有用？失败如何分解为感知错误、推理错误、动作错误与环境建模错误？一个有用的分类学应当区分可通过重试纠正的失败（瞬时错误）与反映系统性盲区的失败（持续性错误）。把失败类型映射到可靠性维度——例如推理错误主要影响可预测性、动作错误主要影响安全——将有助于确定缓解策略的优先级。

• • 指标标准化：哪些具体的指标表述应当在全领域标准化，以支撑有意义的比较？需要哪些参考实现与测试套件？标准化工作应包括一致性、鲁棒性、可预测性与安全指标的规范实现，配以明确规定聚合程序，以及跨多个领域与难度级别的共享校准数据集。

• • 可靠性作为涌现能力：可靠性是随规模涌现的，还是需要显式的架构支持？可靠性能否通过提示、微调来改进，还是只能通过根本性的模型改变？我们发现可靠性收益滞后于能力进步，这表明仅靠扩展是不够的，但需要控制模型规模、训练数据与脚手架设计的系统性研究来解耦这些因素。

• • 维度间交互：四个可靠性维度如何相互作用？是否存在根本性的权衡——例如，通过保守行为提升鲁棒性，是否会因引入额外决策分支而降低一致性？刻画这些交互将让实践者了解哪些可靠性画像是可以共同达成的。

E.2 长时间跨度与有状态可靠性

• • 错误累积动力学：错误在 agent 的长时间运行中如何复合？我们能否把错误增长率刻画为跨度长度、任务复杂度与 agent 架构的函数？类似随机过程中漂移分析的形式化模型可以提供有用的分析工具。

• • 状态漂移：agent 维护的状态（记忆、文件、上下文）随时间如何演化？状态漂移何时会导致可靠性退化？状态漂移对在工具调用之间维护工作记忆的 agent 尤其令人担忧，因为中间表示的微小不准确会复合成性质截然不同的下游行为。追踪内部状态随时间偏离真实环境状态的指标，将有助于量化这一现象。

• • 会话可靠性：哪些基准与指标能刻画长达数小时或数天的 agent 会话中的可靠性？我们应当如何为长时间运行的 agent 定义「存活」标准？现有基准评估的是持续几分钟的回合；把评测扩展到更长的跨度，需要环境持久化、真实中断模式以及能对部分进展和随时间的优雅降级进行计量的新基础设施。

• • 检查点与恢复：哪些状态快照、回滚与恢复机制适合 agentic 系统？与传统软件不同，agent 状态不仅包括数据，还包括推断出的上下文与计划。需要研究什么构成一个充分的检查点——是原始上下文窗口、摘要化状态，还是显式的计划表示——以及 agent 如何能从恢复的状态可靠地续跑而不引入不一致。

E.3 对分布偏移与对手的鲁棒性

• • 偏移感知的评测：基准如何系统性地变化环境以探测分布外鲁棒性？哪些扰动分布是现实且有信息量的？我们的鲁棒性指标以提示改写作为第一步，但现实的分布偏移还包括工具 API、环境布局与用户交互模式的变化。一个系统性的扰动分类学——涵盖词汇、结构、语义与环境层面的变化——将支撑更全面的评测。

• • 对抗性威胁模型：哪些对抗场景与 agent 相关——提示注入、恶意工具、投毒数据、社会工程？它们如何映射到可靠性维度？对抗鲁棒性与全部四个维度相交：提示注入影响一致性（受攻击时行为不同）、鲁棒性（对恶意输入的敏感性）、可预测性（无法识别对抗条件）与安全（攻击成功导致的无界危害）。为 agentic 场景开发专门的威胁模型——那里攻击面包括工具、记忆与多轮交互——仍是开放挑战 [14]。

• • 防御机制：哪些防御（输入过滤、沙箱、冗余校验）能在不牺牲能力的情况下提升鲁棒性？量化不同防御策略下能力—鲁棒性的权衡，将帮助实践者为其部署场景选择适当的保护级别。组合多种轻量机制的复合式防御，可能比单体式方案提供更好的权衡画像。

E.4 多 agent 可靠性

• • 错误传播：幻觉、偏差与错误如何在多 agent 系统中传播？在什么条件下多 agent 交互会放大而非抑制错误？当 agent 消费彼此的输出时，一个幻觉可能成为下游 agent 接受的前提，造成难以检测的关联性失败。追踪错误在多 agent 流水线中的来源、从而识别放大点与天然纠错机制的实证研究，将为设计更可靠的组合提供依据。

• • 鲁棒聚合：输出聚合（投票、辩论、仲裁）如何设计才能对不可靠的个体 agent 保持鲁棒？关于集成方法的经典结果假设错误相互独立，但 LLM agent 往往共享训练数据并表现出相关的失败模式。理解 agent 集成的有效多样性——以及如何通过模型选择、提示变化或架构差异来最大化它——对可靠聚合至关重要。

• • 集体可靠性理论：是否存在刻画多 agent 系统何时比其组件更可靠或更不可靠的理论结果？Condorcet 陪审团定理式的分析可以给出多数投票提升可靠性的条件，但把这些结果扩展到结构化的 agent 交互（顺序流水线、层级委托、辩论）需要新的理论框架。

• • 多 agent 系统中的失败归因：当一个多 agent 系统产生错误或有害的输出时，责任应当如何归到个体 agent？开发跨 agent 边界对失败进行因果归因的方法，无论对调试还是对已部署多 agent 系统的治理都很重要。

E.5 在线监控与干预

• • 预测性信号：哪些实时信号（不确定性估计、异常分数、工具错误模式）最能预测即将发生的失败？识别与失败风险相关的外部信号——例如动作熵、工具调用频率变化或上下文利用模式——可以实现比单纯依赖 agent 自我报告更可靠的运行时监控。

• • 监控架构：运行时监控器应当是独立的元 agent、经典规则系统，还是混合方案？各自的权衡是什么？元 agent 监控器继承了它们所监督的 agent 的同样可靠性局限，形成潜在的回退困境。经典的基于规则的监控器提供形式化保证，但对新型失败模式的覆盖有限。刻画监控器自身的可靠性——并设计监控器失败独立于 agent 失败的架构——是一个关键挑战。

• • 干预策略：监控应在何时触发干预（警告、暂停、回滚、关停）？干预阈值应如何设定？阈值选择涉及误报（侵蚀用户信任、削减 agent 自主权）与漏报（放任有害动作继续执行）之间的根本权衡。考虑任务关键性、动作可逆性与会话累积风险的自适应阈值，可能优于静态策略。

• • 事故学习：失败的事后复盘分析如何反馈到监控与 agent 设计的改进中？结构化的事故数据库（类似航空业的航空安全报告系统），用标准化元数据（失败维度、严重程度、根因、环境条件）编录 agent 失败，将支撑跨组织学习与趋势分析。

E.6 规约与验证

• • 行为规约：应在什么抽象层次上规约 agent 行为：自然语言约束、时序逻辑属性，还是学习到的奖励模型？自然语言规约表达力强但有歧义；形式化规约精确但难以为开放式任务编写。把自然语言意图与形式化安全约束相结合的混合方案（例如「达成用户目标，但绝不删除工作目录之外的文件」）可能提供一个务实的中间地带。

• • 测试方法学：基于属性的测试、模糊测试与自动化场景生成如何适配 LLM agent？LLM agent 的随机本质使传统测试复杂化：同一测试用例在不同运行中可能产生不同结果。测试方法学必须应对这一点，用分布式术语定义通过标准（例如「在至少 95% 的运行中成功」），并系统性地探索提示变体、工具配置与环境状态的空间。

• • 部分验证：小型、可验证的组件（约束与输出校验器）包裹在更大的 agent 外层时，能否提供有意义的保证？这种「已验证包装器」的方法类似于传统软件中的运行时验证，可以在不要求核心 agent 可验证的情况下提供安全保证。关键问题包括：哪些属性适合运行时检查、多大开销可以接受，以及包装器拒绝 agent 输出时如何处理。

• • 覆盖率指标：对于在高维行为空间中运行的 agent，测试覆盖率应如何定义？传统代码覆盖率指标不适用于 LLM agent，其行为空间由可能输入、工具调用与环境状态的组合爆炸定义。基于行为聚类、能力维度或失败模式枚举的覆盖率定义，可能比单纯的输入空间覆盖率更有信息量。

E.7 人—agent 交互

• • 信任校准：界面设计、置信度表述与解释质量如何影响用户的信任校准？尽管近期有所改进，置信度自评仍常常校准不佳。结果是，口头表述的置信度可能主动误导用户。研究应当考察：呈现基于一致性与可预测性指标的经验推导可靠性估计，是否比 agent 自己生成的置信度声明带来校准更好的用户信任。

• • 不确定性传达：agent 不确定性的哪些表示对非专家用户是可解释且可操作的？选项涵盖从数值概率，到类别指示（高/中/低置信度），再到行为信号（提出澄清问题、呈现备选方案）。需要用户研究来确定在不同任务领域和用户群体中，哪些表示能带来适当的依赖决策。

• • 共享控制设计：人类与 agent 之间应如何划分责任，交接协议应如何构造？可靠性画像可以为这种划分提供依据：agent 表现出高一致性与高安全的任务可以完全委托，而可预测性低的任务可能需要在关键决策点设置人工检查点。设计基于实时可靠性信号调整自主级别的自适应委托策略，是一个有前景的方向。

• • 可靠性感知：用户能否准确感知 agent 的可靠性，还是系统性偏差会导致过度信任或信任不足？自动化偏差、拟人化以及 LLM 输出的流畅性都可能助长过度信任，而备受关注的失败事件可能导致信任不足。追踪用户信任如何随经验演化——以及它是否会收敛到对可靠性的准确估计——的纵向研究，将为设计适当的引导与培训流程提供依据。

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

• • 持续评估：组织如何维持能跟上模型与环境快速变化的评估流水线？模型提供方频繁发布更新，每次更新都可能以准确率无法捕捉的方式改变可靠性画像。针对可靠性维度的自动化回归测试应当集成到部署流水线中，并在一致性、鲁棒性、可预测性或安全指标出现统计学显著变化时触发告警。

• • 变更管理：模型、提示与脚手架的更新应由什么流程管辖，可靠性影响应如何评估？即使是微小的提示修改也可能改变 agent 行为。组织需要结构化的变更控制流程，要求在部署前完成可靠性影响评估，类似于航空与汽车认证中使用的安全论证评审。

• • 事故报告：可靠性指标应如何与事故追踪、根因分析和法规合规整合？一种把失败映射到可靠性维度的标准化事故报告格式，将支撑跨组织对标，并帮助监管者评估系统性风险。隐私保护的聚合方法可以在不暴露敏感部署细节的情况下共享可靠性事故数据。

• • 可靠性标准：可靠性要求应当在采购、认证与部署授权中扮演什么角色？随着 agent 被部署到受监管行业（医疗、金融、法律），以一致性、鲁棒性、可预测性与安全表述的最低可靠性阈值，可能成为部署的先决条件。制定既严格又在当前技术下可实现的领域特定可靠性标准，是研究与实践之间的重要桥梁。