开源Python SDK：用SRE理念衡量AI Agent可靠性

当Agent「执行成功」却没完成任务

AI Agent的一个隐蔽问题是：它可以顺利跑完所有步骤、返回结果，却完全没做到它本该完成的事。链路追踪（Tracing）和可观测性工具能告诉我们Agent「做了什么」，但无法回答一个更关键的问题——这个Agent到底靠不靠谱，能不能放心部署上线？

一位开发者在Reddit上分享了他为解决这个问题而开源的项目 Agent Reliability，一个专注于衡量AI Agent可靠性的Python SDK。它的核心思路是把SRE（站点可靠性工程）中成熟的可靠性度量方法，迁移到Agent的世界里：先定义清楚什么叫「可靠」，再对它进行一致、可重复的量化测量。

核心设计：把「不确定」和「失败」分开

这个SDK最值得关注的地方，是它在语义设计上的克制与严谨。传统评测容易把所有非成功状态都算作失败，导致可靠性分数失真。Agent Reliability引入了更精细的结果分类：

明确的三态结果

PASS / FAIL / UNKNOWN 三种显式结果状态
UNKNOWN 不会人为拉低可靠性分数——无法判断的情况不应该被当作失败对待，这是很多评测体系容易踩的坑
评测器（evaluator）自身的执行失败，与Agent的失败严格区分——如果是你的评测脚本挂了，不该记在Agent头上
测量健康度（measurement health）与Agent可靠性分开追踪——先确保「你的尺子是准的」，再谈「被测对象好不好」

这套区分逻辑背后，是一个朴素但常被忽视的工程原则：可靠性度量本身也可能出错，混淆「测量失败」和「被测对象失败」会让整个评估结论失去意义。

SLO 与错误预算语义

项目引入了SRE体系里的两个关键概念：

可靠性聚合（reliability aggregation）：把多次测量结果汇总成整体可靠性指标
SLO 与 error-budget 语义：像对待线上服务一样，为Agent设定可靠性目标，并追踪错误预算的消耗
可在测试/CI中使用的 SLO 断言：这意味着你可以把「可靠性不达标就构建失败」写进流水线

把可靠性检查嵌入CI，是这个项目相对新颖的一点——它试图让Agent的可靠性像单元测试通过率一样，成为可以卡在发布门槛上的硬指标。

SLO（Service Level Objective，服务级别目标）和错误预算（Error Budget）是SRE体系中的核心概念。SLO是对某项服务可靠性的量化承诺，例如「99.9%的请求在200ms内成功返回」；错误预算则是SLO允许的最大失败空间——99.9%的SLO意味着每月有约43分钟的「可用失败配额」。当错误预算耗尽时，团队通常会暂停新功能发布，优先修复稳定性问题。将这套逻辑迁移到Agent评测中，意味着你可以为Agent设定诸如「在生产请求中，95%的任务必须被判定为PASS」的目标，并在CI中自动检测当前错误预算消耗是否超标——一旦超标即阻断发布，这与传统软件工程中把测试通过率设为发布门禁的思路完全一致。

Local-first：无账号、无API Key、零强制依赖

与许多需要托管服务、账号和API Key的评测平台不同，Agent Reliability刻意选择了**本地优先（local-first）**的路线：

不需要注册账号、不需要API Key、不需要托管服务
基础包零强制运行时依赖
提供本地的人类可读与机器可读报告
内置确定性（deterministic）评测器
可选的 OpenTelemetry 互操作能力

安装也非常简单：

pip install agent-reliability

PyPI地址：https://pypi.org/project/agent-reliability/

零依赖和本地化的设计，降低了在生产环境中引入的顾虑——它不会把你的Agent执行数据强制上传到第三方，也不会给现有技术栈带来沉重的依赖负担。确定性评测器的选择同样重要：如果评测本身不可复现，那可靠性数字就没有参照价值。

OpenTelemetry（OTel）是云原生可观测性领域的开放标准，由CNCF维护，旨在统一Traces、Metrics、Logs三类遥测数据的采集与传输协议。支持OpenTelemetry互操作意味着Agent Reliability产生的可靠性指标可以通过标准协议导出，与Jaeger、Grafana、Datadog等现有可观测性平台无缝集成，而无需为每个平台单独适配。对于已经在生产环境中部署了OTel基础设施的团队，这一设计使得Agent可靠性指标可以直接并入现有监控大盘，而非另起炉灶。

它不想做什么

作者特意划清了边界：这不是又一个链路追踪系统，也不是提示词/评测的仪表盘产品。 市面上这类工具已经不少。这个项目瞄准的是一个更聚焦、也更难回答的问题：

我们如何确认一个Agent「足够可靠」到值得信任并部署？

换句话说，Tracing解决的是「发生了什么」，而Agent Reliability想解决的是「我能不能信它」。这两者是互补而非竞争关系。

作者征求的三个真实问题

项目仍在演进中，作者明确表示欢迎对API和语义设计的批评，并抛出了三个值得所有Agent开发者思考的问题：

你现在是怎么衡量Agent可靠性的？ 大多数团队目前还停留在人工抽查或简单的成功率统计。
哪些失败最难被检测到？ 那种「执行成功但结果错误」的静默失败，往往是最危险的。
SLO式的可靠性度量对你的工作流有用吗？ 把服务可靠性的成熟范式搬到Agent上，是否真的可行。

值得关注的方向

随着越来越多的团队把AI Agent推向生产环境，「怎么证明它可靠」正在从一个学术话题变成工程刚需。Agent Reliability的价值不仅在于代码本身，更在于它提出的框架思路：用SRE的严谨态度对待Agent，把可靠性变成可定义、可测量、可断言、可纳入CI门禁的工程指标。

对于正在生产环境运行Agent的团队来说，这个开源项目至少提供了一个可以直接上手试用、且不需要任何托管成本的起点。如果你正被「Agent到底靠不靠谱」的问题困扰，它可能是一个值得关注并参与反馈的实验。