一段时间内，Voice Agent 的首句回复 P95 看起来没有问题，任务完成率也在报表里。可一旦把样本摊开，会发现两件事被混在了一起：有些用户很快听到了回复，但工具没有真正确认；有些用户被及时转给了人工，却没有带上会话摘要；还有些对金额、地址作出的错误承诺，在“完成率”里甚至被算成成功。

我不建议直接把“平均延迟低于某值、任务完成率高于某值”写成 AI 客服的 SLO。它们可以是指标，却还不是可执行的服务目标。Voice Agent 的 SLO 至少要同时约束用户是否及时得到下一步、业务动作是否被确认、人工交接是否完整，以及有没有越过不能容忍的安全边界。否则，系统会把更快地说错话优化得很漂亮。

本文讨论的是中文电话客服中的任务型 Voice Agent：用户查询订单、改地址、报修、预约或转人工。示例只对合成任务记录进行离线计算，不连接电话、模型、TTS、CRM 或监控系统；其中的 1800 ms 等阈值仅用于演示口径，不能当作任何业务的生产目标。

目录

• 先别拿一张平均延迟图当 SLO
• 把“好服务”拆成可判定的任务事实
• SLO 的分子、分母和排除项要先写清
• 安全护栏不应和错误预算混算
• 用最小夹具验证目标是否真的能触发动作
• SLO 怎样进入发布与复盘流程
• 还不能从离线 SLO 推出什么
• 参考资料

先别拿一张平均延迟图当 SLO

平均值最容易制造错觉。十通电话里，九通在一秒内收到首句回复，一通等待十秒，平均只有 1.9 秒；但那一通可能正好是用户投诉、身份确认或人工转接的关键任务。对电话客服而言，“用户是否能继续往下走”通常比一个被极端值抹平的平均数更重要。

更隐蔽的问题是，延迟和任务完成不是同一条链。下面是同一通会话可能发生的顺序：

如果只统计 ASR final -> 首句回复，B 很快并不能证明 E 或 F 做对了；如果只统计“模型给过答案”，更无法证明业务任务闭环。Google SRE 对 SLO 的基本定义是：它是由 SLI 衡量的服务水平目标，目标的选择需要反映真正对用户重要的行为，而不是照抄系统当前跑出来的数值。Google SRE：Service Level Objectives

所以，闪电智能VoiceAgent 的 SLO 设计应该从一次任务的可验证结果倒推，而不是从已有仪表盘里挑最容易好看的曲线。

把“好服务”拆成可判定的任务事实

一个可用的起点是把任务拆成四种不同性质的事实。它们可以同日统计，但不能互相替代。

目标层	示例 SLI	它回答的问题	容易漏掉什么
交互响应	在时限内得到首次可理解回复的任务占比	用户有没有被晾住	回复快，不代表内容正确
任务闭环	已确认完成或完整转人工的任务占比	请求最终有没有落到可交接状态	工具 200 不等于业务已确认
交接完整性	带摘要、原因、当前字段状态的人工交接占比	人工是否能接得住	只算“转人工成功”会掩盖信息丢失
风险护栏	错误承诺、敏感操作越权等事件数	系统是否说了不该说的话	护栏不能被高完成率抵消

这里有一个必须先定下来的产品判断：合规、带摘要且明确当前状态的人工接管，可以是任务的安全完成；把问题硬留在机器人端，不应该为了抬高自动解决率而被算作成功。 这会影响闭环 SLO 的分子，也会影响团队到底是在优化用户问题，还是在优化“机器人没有转人”。

中文客服需要再加一层输入边界。地址、订单号、手机号、金额和用户临时更正的信息，最好把 ASR final、用户确认、工具参数校验、工具结果分别记录。否则一条“改成十八号楼二单元”的任务，可能在识别、字段补全、工具调用或话术承诺任意一处失败，却都被粗略归到“任务未完成”。

SLO 的分子、分母和排除项要先写清

以任务闭环为例，先定义合格任务集合 (E)。E 应排除什么，必须由产品、客服和工程共同确认：例如压测流量、已在呼叫前放弃且 Agent 从未接入的会话、内部演练任务。这些排除项必须有可审计标签，不能在 SLO 变差时临时挪走样本。

一个演示口径可以写成：

[
\text{任务闭环率} = \frac{\text{已确认完成任务数} + \text{完整人工交接任务数}}{\text{纳入统计的任务数}}
]

交互响应则是另一条 SLI：

[
\text{及时响应率} = \frac{t_{first_response}-t_{asr_final} \leq T}{\text{纳入统计的可交互任务数}}
]

T 不应该直接拿模型接口耗时代替。电话场景至少要说明计时从哪一刻开始：通常是用户一轮语音的可用最终转写，终点是用户端开始收到可理解的首句；ASR 等待、模型首 token、TTS 首包、播放队列和网络都会影响这段体验。

对于闭环 SLO，confirmed 必须有工具或人工的最终状态作为证据。工具只是发出了请求、CRM 返回未知、或人工交接没有摘要，都不能硬塞进分子。Google 的 SLO 实施指南也强调，SLO 与错误预算应成为共同批准的决策机制，而不是事后 KPI；目标、SLI、预算计算与超标后的动作要能被相关方复核。Google SRE Workbook：Implementing SLOs

安全护栏不应和错误预算混算

错误预算适合管理“允许多少比例的常规服务目标不达标”。它不适合给错误承诺开配额。比如模型在工具未确认时说“地址已修改”、在人工无法接通时说“已为您转接成功”，这不是可以被 99% 成功率抵消的普通失败。

建议把触发动作写成两条独立规则：

任务闭环率低于目标：暂停高风险变更，检查失败层与预算消耗。
出现任何已确认的错误承诺或敏感操作越权：立即阻断相关版本/路由，走人工复核与事件修复。

这也解释了为什么“只盯延迟和任务完成率够吗”的答案是否定的。延迟是体验信号，闭环率是流程信号，护栏是风险信号。三者可以共同决定是否放量，但没有一条可以代替另外两条。

用最小夹具验证目标是否真的能触发动作

本地项目的 examples/slo_policy.py 用标准库构造合成任务，重点不是计算一个漂亮百分比，而是验证分母与好任务定义不会悄悄变形：

Task("a", 100, "confirmed", True)
Task("b", 500, "handoff_completed", False, handoff_summary_present=True)
Task("c", 2100, "failed", False)

夹具将已确认工具完成与带摘要的人工接管都计入闭环；把工具未确认的 confirmed、没有摘要的转人工、以及安全违规排除在分子外。发布决策也不是单看完成率：安全违规优先返回 block，完成率不足才返回 hold。

运行方式：

cd "CSDN-VoiceAgent-SLO(0825)"
PYTHONPATH=. python3 -m examples.run_demo
PYTHONPATH=. python3 -m unittest discover -s tests -v

7 项测试覆盖分母排除、首句时限、工具确认、人工摘要、安全阻断和门禁保持。它只验证指标合同，不代表真实线路的响应时间、模型效果或线上 SLO 达标。

SLO 怎样进入发布与复盘流程

一份 SLO 文档至少要让发布负责人能回答四个问题：这项任务的用户价值是什么？分子分母是什么？谁能修改排除项？预算消耗到什么程度后做什么？没有这些字段，SLO 只是一张报表标题。

一个实际可执行的流程是：

1. 每次改 Prompt、模型路由、工具 Schema、TTS 或转人工策略前，先跑确定性回归集；
2. 灰度期间按会话任务采集 SLI 所需事件，不采集不必要的原始敏感内容；
3. 将闭环率、交接完整性和护栏事件按渠道、任务类型、版本拆开观察；
4. 预算消耗快时先冻结会改变事实承诺的变更，再按归因结果处理 ASR、工具、CRM 或人工队列问题；
5. 把脱敏后的真实失败样本补回回归集，避免同一类故障只在报警里出现一次。

不要用“当前 P95 能达到多少”反推目标。目标必须先由用户容忍度、业务风险、人工承接能力和系统成熟度共同决定；否则团队最终会为一个没有业务含义的数字做优化。

还不能从离线 SLO 推出什么

本地夹具只表明口径可以被代码固定。它没有真实电话样本，无法说明中文口音、窄带音频、网络抖动、模型版本变化和 CRM 峰值下的 SLI 分布；也不能说明用户满意度或人工成本会如何变化。

下一步应从有限的真实任务类型开始，先对“工具确认”和“人工摘要完整”做事件审计，再逐步建立按渠道、场景和风险分级的目标。SLO 的价值不在于替系统宣布稳定，而在于让每次不稳定都能触发一致的工程动作。

参考资料

• Google SRE：Service Level Objectives
• Google SRE Workbook：Implementing Service Level Objectives
• Google SRE Workbook：Error Budget Policy