你的仪表盘以三种不同方式统计了那次重试

一个 Agent 运行了。计划步骤（plan-step）崩溃了。工具调用（tool-call）步骤在经历了两次 500 错误重试后，在第四次尝试时成功了。用户得到了他们的答案。

那算是多少个事件？问产品，这是一个事件 —— 用户得到了有效结果，因此转化漏斗统计了一次转化。问 SRE，那是三个失败加上一个成功，底层步骤的错误率是 75%。问财务，那是四次计费推理，两次重试的工具调用，以及大约四倍于产品部门预测的单位成本。每个团队的仪表盘都是正确的。但它们也是不可调和的，一旦有人试图调和它们 —— 通常是在事故回顾期间 —— 他们会发现团队已经基于三个相互矛盾的可信度图景运行了数月之久。

问题不在于一个团队是对的而其他团队是错的。而是“Agent 失败了”是一个定义不明确的短语，一个健康的观测堆栈必须在三个不同的层面回答这个问题，而这些层面之间不能相互矛盾。大多数堆栈在构建时都假设一个定义就足够了。

为什么单一错误率在 Agent 边界不再适用

对于无状态的 HTTP 服务，“它是否失败了”是明确的。5xx 是失败。在一次或多次 5xx 重试后的 2xx，按照所有标准的 SRE 惯例，仍然被视为成功 —— Google SRE 工作手册将最终结果正确时的重试视为成功预算的一部分。包括 Microsoft 重试风暴反模式指南在内的重试预算文献也表示同意：分别统计尝试次数和尝试结果，但对最外层调用报告用户可见的成功。

Agent 以三种方式打破了这一惯例。首先，工作单位不再是单个调用。用户的任务是一个由计划步骤、工具调用、模型调用、检索步骤以及有时嵌套的子 Agent 组成的不透明图谱。每个步骤都有其自身的失败语义，并且步骤成功与任务成功之间的关系是非单调的 —— 一个步骤可以以导致任务失败的方式成功（模型自信地调用了错误的工具），或者以导致任务成功的方式失败（工具返回 500 错误，而 Agent 重新路由到了一个恰好更便宜的不同工具）。

其次，每一次重试都是一次计费推理，而且大多数重试都会重新运行整个不断增长的上下文窗口，而不仅仅是失败的部分。“一个成功的任务”与“一个经过三次重试才成功的任务”之间的成本差异不是 1 比 1 —— 它经常是 1 比 8 或 1 比 12，因为第三次重试在上下文中携带了第二次重试的失败输出。那些基于干净的成功计数构建单位经济模型的财务团队会偏差一个数量级，而且直到发票寄到时他们才会意识到这一点。

第三，重试有时就是工作本身。一个能够验证其自身输出并在失败时重试的自我修正 Agent，在 SRE 的意义上并不是“在失败后成功” —— 它是在执行其设计。将验证步骤的失败计为事故会使正常运行中的错误率受到污染。将它们计为成功则会掩盖真正的收敛失败，即 Agent 在放弃之前重试了三十次。

单一的错误率指标在三个不同问题的重压下崩溃了：用户是否得到了他们想要的，系统是否在预算内运行，以及每个组件是否按设计运行。大多数团队回答了其中一个问题，并假设另外两个也会随之解决。但事实并非如此。

明确命名这三个层面

最清晰的出路是停止试图让一个指标服务于三个受众。构建三个层面，并让每个团队订阅其所需的层面。

Task outcome（任务结果） 是用户可见的答案。定义在追踪（trace）顶部的用户请求，是否以用户认为成功的状态结束？这在任务级别是二进制的，也是产品经理唯一应该看的数字。重试在这一层是不可见的。一个尝试了四次才产生正确答案的任务是一个单一的成功；一个尝试了一次却产生了一个自信的错误答案的任务是一个单一的失败。转化漏斗、激活曲线、“功能是否正常运行”等问题都生活在这里。

Step outcome（步骤结果） 是每个组件的健康状况。对于追踪中的每个 span —— 计划调用、工具调用、检索、模型推理 —— 这次尝试本身成功还是失败了？这是 SRE 所需要的，因为这是你可以将工具的可靠性与其 SLO 进行对比、检测退化的检索索引或注意到特定模型版本发生回退的层面。步骤层统计每一次尝试。一个在成功前重试了三次工具的任务是三次步骤失败加上一次步骤成功，无论任务层报告了什么。这里的仪表盘看起来像经典的服务仪表盘，AI Agent 的可观测性文献一致认为这是诊断层。

Budget consumption（预算消耗） 是财务部门关注的。从头到尾，这项任务消耗了多少计费单位 —— 输入 token、输出 token、工具调用、推理 token、缓存与非缓存读取 —— 汇总了每一次尝试和每一次重试？相对于所做的工作，这是单调增加的；对于给定的任务，它永远不会减少。第一次尝试就成功的任务成本为 1x；第四次尝试才成功的任务成本为 4x 或更多，具体取决于上下文的增长。Token 分摊手册都一致认为这应该是与结果指标分开的独立账本，他们是对的：结果和成本是独立的轴。

这三个层面不应被相互折算。 “正确的”任务成功率不是步骤成功率的平均值，每个成功任务的成本也不是通过总 token 数除以任务数得出的。每一个都是对同一底层追踪的不同聚合，每一个都汇总给不同的利益相关者。

层与层之间的交汇点揭示了什么

加载中…