很多团队给 Agent 设目标时，第一反应都是盯住成功率。表面上这很合理：任务成了就是成了，没成就是没成。但一旦系统进入真实生产环境，你很快就会发现“成功”这件事本身就过于粗糙。一个任务虽然最终完成，却可能经历了过多重试、过长等待、频繁人工接管，或者给出了业务上勉强能用但质量明显下滑的结果。如果这些情况都被算进“成功”，那成功率越高，也不一定代表系统越健康。
真正有用的 Agent SLO，必须把成功率之外的质量维度一起纳入：延迟是否可接受、重试是否过多、人工兜底是否在增加、输出是否稳定、业务结果是否仍在目标区间。Datadog 的 LLM Observability、OpenAI Evals 的实践材料，以及 LangSmith 的 observability 文档都在提醒同一件事：生产质量不是单一数字，而是运行链路、评估结果和业务表现共同组成的约束面。对 TaskPilots 来说，SLO 的价值正在于把链路追踪、运营审查和持续评估压缩成一组真正能指导放量、回滚和治理的阈值。
为什么这个问题重要
真实运行代价
只看成功率时，很多真实退化都会被掩盖。一个客服流程也许最终都能完成，但人工审核比例正在升高；一个研究助理链路也许还能产出结果，但平均等待时间已经翻倍；一个运营工作流也许输出仍然“合格”，但需要越来越多的补料和重复确认。表面上的成功掩盖了系统在成本、延迟和人工负担上的持续恶化。
- 运营团队看到的是接管变多、补救变多，仪表盘却仍然显示成功率稳定。
- 工程团队只能看到任务完成，没有看到完成路径正在变得越来越脆弱。
- 发布团队难以判断某次版本更新究竟是改善了体验，还是只保住了表面结果。
如果不处理会怎样
最先暴露的通常不是一次大故障，而是成功率和真实体验开始脱钩。起初只是客服觉得“最近系统变笨了”，之后变成 SLA 偶尔超时、人工升级越来越多，再往后就会出现业务指标持续下滑，但技术面板上看不出明显异常的局面。此时问题已经不再是监控不够，而是 SLO 本身定义错了。
继续沿用这种粗粒度目标，常见后果有四类：第一，团队会把大量灰色退化当成正常成功；第二，发布门槛会长期偏松；第三，回滚动作总是偏慢；第四，业务和工程团队会越来越难用同一套语言讨论质量问题。
适用场景
谁最需要这套方法
这套方法最适合那些已经进入生产阶段、链路不再是单轮回答，而是包含检索、工具调用、交接、人工审核和结果回传的团队。尤其适合三类场景：第一，任务看起来大多能完成，但团队明显感到质量在波动；第二，系统存在人工兜底节点，且人工负担是核心成本；第三，业务后果明确，不能接受“虽然最终完成，但体验和效率越来越差”的隐性退化。
- 客服和运营流程需要同时看完成率、接管率、等待时间和用户结果。
- 多 Agent 工作流需要区分是哪个 step、哪类 handoff 在拖累整体质量。
- 发布治理需要更精细的门槛，而不是只凭总体成功率决定是否放量。
什么时候先不要这么做
如果当前系统仍然是很短的原型链路，调用量很小、人工流程很少、业务目标也还没稳定，那么暂时不必急着设计复杂的多维 SLO。此时更重要的是先把成功定义、基础日志和最关键的失败样本沉淀好。另一类不适用边界，是任务本身高度探索、没有清晰完成标准，此时先硬设太多阈值，容易让团队陷入指标管理而不是问题发现。
推荐系统结构
核心角色与状态
更稳的做法，是把 Agent 质量 SLO 拆成至少四层。第一层是结果层，衡量任务完成率和业务完成度；第二层是效率层，衡量端到端延迟、重试次数和等待时间；第三层是稳定性层，衡量失败簇、回滚率和质量漂移；第四层是人工成本层，衡量人工接管率、人工修复时间和升级清晰度。这样一来，成功率不再是唯一结论，而只是其中一维。
- 结果层回答“任务最后有没有真正完成，并且完成得够不够好”。
- 效率层回答“系统为了完成这个结果付出了多少时间和重试成本”。
- 人工层回答“有多少本该自动完成的工作开始回流到人”。
与 TaskPilots 的映射
映射到 TaskPilots，可以把链路追踪作为 SLO 的证据来源，把运营审查作为人工接管和失败分类的信号来源，把持续评估作为发布前后的质量校验层。也就是说，TaskPilots 不该只统计“任务有没有完成”，还应同时跟踪 step 级延迟、handoff 失败、人工升级率和代表性评估样本表现。只有这样，SLO 才能真正跨越工程视角和运营视角，而不是只站在其中一边。
站内像 别只追工具日志，要追决策链 和 离线评估和在线 Canary，别只做其中一个 讨论的决策 trace 与双层发布验证，也正是多维 SLO 的上游输入。没有这些结构，SLO 很容易再次退化成一个单一成功数字。
风险与失效点
常见失控方式
第一种失控，是把 SLO 定义得过多过细，导致团队每天面对一屏阈值却不知道哪项最关键。第二种，是只选技术上容易采集的指标，例如延迟和错误率，却没有把人工接管和业务完成度纳入。第三种，是把所有失败都压成总体成功与否，导致关键灰色退化无法进入治理视野。第四种，则是 SLO 虽然定义了，但没有与发布门槛、灰度策略和回滚动作绑定，最后变成一个好看的说明文档。
- 成功率仍然很高，但人工接管率持续上涨，团队却没有及时触发预警。
- 业务完成度下降被误解释成模型波动，实际上是交接和检索层的退化。
- 阈值太多而优先级不清，导致所有告警都像噪声。
需要人工兜底的地方
涉及高影响发布、客户承诺、审批规则和高价值业务流程时，仍然需要人工兜底。人工的价值不是手动盯所有指标，而是在多维 SLO 发生冲突时帮助团队做判断。例如成功率稳定但人工接管率明显上升，或者延迟改善但业务完成度下降，这些情况都不适合只靠自动化阈值直接处理。比较稳的做法，是让人工能基于代表性 trace、失败簇和 SLO 变化一起判断是否继续放量、调整策略或直接回滚。
验证指标
上线前怎么验证
上线前最重要的，不是先画一组漂亮图表，而是验证这些 SLO 是否真的能描述质量退化。建议至少做三类验证：第一，用历史事故回放，检查多维 SLO 是否能及时反映问题；第二，用评估集对照，确认高频失败簇会在对应 SLO 上产生可解释变化；第三，做灰度演练，观察当某个维度恶化时，团队能否从阈值直接得出一致行动。OpenAI Evals 很适合做上线前的代表性样本校验，而 Datadog 和 LangSmith 一类观测资料则适合支撑运行层和追踪层的阈值设计。
- 验证高频失败簇是否会反映到成功率之外的某个关键 SLO 维度。
- 验证人工接管、重试和端到端延迟是否真的能预测用户体验恶化。
- 验证每个核心 SLO 是否都对应清晰的治理动作，而不是只留在展示层。
上线后怎么持续判断
上线后建议长期跟踪至少四类核心指标：故障定位时间、评估通过率、线上回滚率和业务转化指标。除此之外，还应补两类更直接的质量 SLO：人工接管率，以及重复重试率。前者衡量自动化是否正在把成本外溢给人工，后者衡量系统是不是靠多次试错才勉强完成任务。如果这两类指标持续恶化，而成功率仍然平稳，就说明当前成功率已经不再是可信的质量代理。
下一步 / FAQ
下一步建议
最实用的第一步，不是一次性定义十几个 SLO，而是先挑一条高价值链路，补齐四个最关键的质量维度：任务完成度、端到端延迟、人工接管率和业务结果。先让团队围绕这四项建立共同语言，再逐步加入重试率、handoff 失败率和评估通过率等更细指标。先把这组最小 SLO 用在真实灰度和复盘里，通常比一开始设计完整框架更快见效。
FAQ
成功率是不是就不重要了？ 不是。成功率仍然重要，只是它不能再作为唯一的质量代理。
SLO 维度会不会太多，团队记不住？ 所以应该先从最小关键集合开始，而不是一开始就把所有可测指标都纳入。
业务指标一定要放进 SLO 吗？ 对生产级 Agent 来说，通常值得。否则团队很容易只优化技术表现，而忽略真实结果。
最常见的组织阻力是什么？ 往往是工程和运营对“什么算质量下降”没有统一定义，所以需要先对齐语言，再对齐阈值。