传统 SLA 只回答了“系统活着吗”
经典软件服务通常关注可用率、响应时间、错误率、吞吐量和故障恢复时间。这些指标仍然重要：服务打不开、接口超时、任务队列堵塞，AI 同样无法创造价值。
问题在于，生成式 AI 和 Agent 具有概率性。同一个请求在不同上下文、数据状态和工具返回结果下，可能走出不同路径。HTTP 请求成功、页面正常返回，只能证明技术链路没有中断，不能证明 AI：
Microsoft 在 2026 年更新的 AI 可观测性指南中明确指出，在线率和错误率并不是衡量 AI 质量与可靠性的好指标；传统可观测性过度关注延迟、错误和吞吐量，无法覆盖 AI 会随输入、检索上下文、工具输出和策略判断而变化的行为。
因此，一个 AI 系统可能同时拥有“高技术可用性”和“低业务可用性”。如果合同、验收和运营看板只展示前者，供应商认为服务正常，业务团队却会逐渐放弃使用。
- 找到了正确且最新的业务数据；
- 选择了合适的工具并传入正确参数；
- 遵循了金额、权限和合规边界；
- 在证据不足时停止，而不是补全一个流畅答案；
- 遇到异常后正确转交人工并保留上下文；
- 最终完成了业务真正需要的结果。
企业需要的不是一个准确率，而是一组服务边界
不少项目已经开始补充“回答准确率”，但一个总准确率仍然不够。
首先，不同任务的风险并不相同。给内部会议纪要提炼要点，与修改客户价格、批准退款或提交合规材料，不能共用一个合格线。
其次，平均值会掩盖最重要的长尾。Agent 在大量简单问题上表现良好，仍可能在信息冲突、权限不足、工具超时、罕见业务规则或模糊指令下频繁失败。
再次，结果正确不代表过程可靠。一次任务可能碰巧得出正确答案，却调用了错误数据源；下次环境稍有变化，就会产生完全不同的结果。
Google Cloud 提出的生产 Agent 指标已经从单一输出分数扩展到工具选择准确率、参数幻觉率、计划遵循度、重复执行一致性和恶意请求拒绝率，并强调“每个成功任务的成本”比单独统计 Token 更有意义。AWS 在 Amazon 内部 Agent 实践中也将评估扩展到工具选择、多步骤过程、记忆检索、任务完成、错误识别与恢复等完整系统行为。
这些变化说明，企业不应要求供应商承诺一个脱离场景的“95% 准确率”，而应先把服务范围拆成可观察的任务类型和失效边界。
一份 AI 原生 SLA，至少要写清五类承诺
AI SLA 不必一开始就做成复杂合同附件。企业可以先从一条真实工作流入手，把以下五类承诺写进采购要求、验收标准和月度运营报告。
1. 任务成功承诺
先定义什么叫“完成”，而不是只统计调用次数或生成数量。
例如，订单核对任务的成功标准可能包括：匹配正确订单和合同版本、识别约定字段差异、引用可验证依据，并把超出阈值的问题送入指定队列。只有整条任务满足条件，才计为成功。
指标应按场景、风险等级和难度分层。对高频标准任务，可以约定成功率和处理时限；对低频高风险任务，更适合约定必须升级人工，不应强求自动完成率。
2. 安全失败承诺
可靠的 AI 并非永远给出答案，而是知道什么时候不能继续。
企业应衡量证据不足时的正确拒绝率、越权动作拦截率、关键数据冲突识别率和高风险任务升级率。同时也要观察误拦截：如果系统为了安全把所有复杂任务都推给人工，它同样没有交付价值。
因此，“完成率”必须与“安全退出质量”一起看。该做的做对，不该做的不做，才构成完整服务能力。
3. 人工接管承诺
很多 AI 服务写着“支持人工介入”，却没有规定人工多久响应、收到哪些信息、能否从中断位置继续。
真正可用的接管机制，需要约定升级触发条件、接管时限、上下文完整率和恢复路径。人工应能看到 Agent 使用的数据、已经调用的工具、失败位置和建议下一步，而不是让客户重新描述整个问题。
这类指标直接决定 AI 是减少工作，还是把复杂问题以更混乱的形式留给员工。
4. 质量退化与变更承诺
AI 服务会持续变化：模型更新，知识源刷新，工具接口调整，提示词和安全规则也会迭代。上线时通过验收，不代表三个月后仍保持相同表现。
SLA 应说明哪些变更需要通知客户，哪些关键场景必须重新评估，质量下降到什么程度触发告警、限流、回退或暂停。AWS 的 AgentOps 实践建议在生产环境持续抽样评估真实流量，当质量下降时进入人工复核或触发自动回滚；Microsoft 也建议将质量评估用于发布门禁和回归测试。
服务承诺的对象因此不应只是某个模型版本，而应是企业持续获得的任务能力。
5. 事件恢复承诺
传统故障恢复关注“多久恢复在线”，AI 事件还要回答“多久恢复可信”。
当 Agent 使用了错误知识、执行了不当动作或出现系统性偏差，企业需要知道：影响了哪些任务和客户，错误能否追溯，已执行动作如何撤销，修复后用什么案例复测，同类问题如何进入长期评估集。
因此，恢复指标除了平均修复时间，还应包括影响识别时间、错误任务定位完整率、可撤销动作恢复率以及修复后的回归验证结果。
SLA 不是法务在项目最后补的一张表
AI 服务等级必须由业务、技术、风险、采购和供应商共同定义。业务部门说明什么结果有价值、什么错误不可接受；技术团队确认哪些行为可记录、可测量、可回退；风险团队定义停止与升级边界；采购和法务再把这些要求转化为交付责任。
更现实的推进方式，是建立三层指标：
三层必须同时存在。只看基础层，会得到一套“在线但不好用”的 AI；只看价值层，又难以定位问题究竟来自模型、数据、工具、流程还是人员协作。
企业还应避免把所有指标都变成供应商单方面出具的月报。关键任务需要保留双方认可的测试集、抽样规则、数据口径和复核机制。评估集也不是一次性交付物：真实事故、人工推翻和新业务边界，都应持续沉淀为下一轮测试案例。
- **基础层**：在线率、响应时间、容量、接口错误和技术恢复时间；
- **任务层**：任务成功、安全拒绝、工具调用、证据质量、人工接管和一致性；
- **价值层**：周期缩短、积压减少、人工返工、客户结果和每个成功任务的总成本。
AI 商业交付正在从“提供能力”转向“承诺结果边界”
传统软件可以主要承诺稳定提供一个功能。AI 服务更接近持续运营的业务能力：它不仅需要运行，还需要在变化的业务环境中保持可接受的判断质量，并在不能可靠完成时安全退出。
这会改变企业选择 AI 供应商的方式。真正值得信任的供应商，不会只展示模型排名、演示效果和平台在线率，而应能够回答：服务在哪些任务上可靠，边界在哪里，如何持续测量，质量下降如何发现，失败后谁接管，业务怎样恢复。
对正在推进企业级 AI 的公司而言，可以从下一次项目评审开始换一个问题：不要只问“这个系统能否上线”，而要问“上线后，我们凭什么证明它仍在正确工作”。
当这一问题能被合同、数据和运营机制共同回答，AI 才不再只是一个保持在线的技术系统，而会成为企业可以放心依赖的服务能力。
