SLO 与生产运营

Agent 服务有多层可靠性目标

入口层保证请求接纳和事件流；依赖层覆盖模型、检索、Tool 和状态存储；Run 层要求完成、恢复或明确失败；业务层要求最终结果正确且无违规副作用。四层用同一 Trace 关联，避免 API 成功掩盖任务失败。

先按任务等级定义服务模型。例如查询建议允许降级为只读答案，付款执行则必须有审批、幂等与对账。不同等级的成功事件、坏事件和恢复路径不同，不能用一个全站“99.9% 成功率”代替。

选择用户可感知且可行动的 SLI

请求接纳率、流建立率、依赖可用率

请求接纳只说明入口接受；流建立说明用户收到有效首事件；依赖可用率用于诊断。端到端 availability 的好事件应是 Run 在时限内到达允许终态，分母排除需有明确、稳定规则。

TTFT、交互响应、任务完成和审批等待分开

Time to First Token（TTFT）影响即时反馈，任务完成时间影响价值交付，审批等待属于外部或人工阶段。分别测量并保留端到端时钟；只优化 TTFT 可能让后续 Tool 链更慢。

任务成功、人工接管、未知结果和回退率

质量 SLI 来自业务后置条件、抽样评测与用户结果。未知结果和未对账副作用应单列为坏事件，不能暂时计成功。人工接管可能是安全设计，不一定是失败，但上升会消耗运营容量，应按场景设目标。

每成功任务 Token/费用、步骤数和资源消耗

效率按成功任务归一化，并同时看分布。失败任务的无效循环、重试风暴和审批积压会扩大资源；平均 Token 下降若来自提前失败，不是优化。

SLO 绑定场景和风险

SLO 文档包含用户旅程、SLI 查询、目标、窗口、排除规则、数据延迟和 Owner。高风险任务可能要求更低未知结果率而允许更高延迟；交互式问答则更重视 TTFT。Provider 故障仍计入用户结果，另以依赖指标定位和谈判。

错误预算为 1 - SLO，用于决定发布速度和可靠性投入。质量 SLI 若依赖抽样 Judge 或人工审核，应说明覆盖率、抽样概率与评测延迟，不能与实时 availability 混用一个告警时钟。

告警必须指向可处置问题

使用快燃烧与慢燃烧多窗口监控错误预算：前者捕获大面积故障，后者捕获持续退化。Google SRE 的 SLO 告警方法强调用燃烧率联系错误比例和预算消耗，而不是对每个内部指标设置静态阈值。

告警附带 Provider、Tool、租户、版本和任务切片，以及代表性 Trace。循环、成本失控、审批积压与未知副作用是 Agent 特有信号。低流量高风险事件不适合等统计窗口，应使用事件型告警并立即停止相关能力。

Runbook 围绕恢复路径

Runbook 从识别失败层和影响范围开始，给出熔断、路由、降级、暂停新 Run、恢复卡住任务和副作用对账的具体命令或控制面入口。每个动作写前置条件、风险、Owner、预期信号和撤销方式。

通信与升级、证据保全、用户通知同样属于恢复。模型或 Tool 超时后不能只重启服务；值班者还要查询幂等键、外部回执和状态账本，决定重试、补偿或人工处置。Runbook 通过 GameDay 验证，不以文档存在为完成。

容量规划考虑长连接和多步放大

容量模型从每个任务的模型/Tool 调用次数分布、并发 Run、流式连接时长、队列深度和审批等待出发。平均每请求一次调用会掩盖 P99 的循环与重试；应使用扇出和服务时间分布估算峰值。

Rate Limit 需要令牌桶、队列和背压协同。无抖动的同步重试会形成风暴，过长队列则让任务在执行前已过期。按租户公平调度，为关键任务预留容量，并为低价值任务定义快速失败或降级。容量演练应包含 Provider 限流和审批积压。

事故复盘进入评测和架构

复盘记录时间线、触发因素、影响、控制失效和恢复证据，重点问监控、回归门禁与架构为何未阻断。行动项可以是新增 Golden Case、Trace 字段、Runbook 步骤、发布护栏或消除单点，不以“提醒团队注意”收尾。

每个行动项有 Owner、期限和效果指标。新增告警应通过历史回放或故障注入证明能更早检测且可行动；新增测试应先复现事故，再证明修复后失败。完成文档不等于风险下降。