AI 智能体 SLA 模板：准确率、延迟、人工接管与可审计性
AI 智能体服务水平协议是一份合同附件。它规定什么叫任务成功、如何测量、何时必须转交人工、供应商要保留哪些证据，以及智能体未达到约定标准时如何处理。只写 uptime 不够。API 可以返回 HTTP 200，智能体却可能引用不存在的来源、调用错误工具、重复付款，或把客户丢进无人处理的队列。
本模板针对已经选定工作流和候选供应商后的签约阶段。如果还在定义建设范围，请使用 AI MVP 范围模板。如果正在决定试点是否值得进入生产，请使用 AI 试点终止或扩展评分卡。如果仍在核查供应商的安全与数据承诺，请先使用欧盟 AI 供应商安全问卷。这份 SLA 从这些材料结束的地方开始，负责持续生产义务、证据和补救。
本文是技术与商业起草工具，不构成法律意见。方括号内数字与示例目标只是谈判起点。正式签署前，请让合格律师根据工作流、风险分类、适用法律、行业规则与责任安排调整。
需要一套真正能产出这些证据的智能体架构吗？
规划可审计 AI 智能体可直接复制的 AI 智能体 SLA 合同附件
把下面内容放入服务附件、Statement of Work 或订单。填完每个方括号。任何字段如果没有责任人、计时起点、分母或证据来源，就还不具备可执行性。
AI 智能体服务水平附件，[工作流名称]
版本 [1.0] · 生效日 [日期] · 客户负责人 [姓名] · 供应商负责人 [姓名]
1. 范围。支持的任务类别 [列表]、渠道 [列表]、语言 [列表]、服务时段 [时区]、获授权工具 [列表]、月任务量 [范围]、最大并发 [数值]，以及明确排除的用途 [列表]。
2. 合格任务。生产服务在收到完整输入、有效身份验证和约定客户配置后接受的请求。排除测试流量、有证据的滥用和客户造成的无效输入。重试、供应商所选依赖的故障和失败尝试不得删除。
3. 成功完成任务。智能体实现获批准的业务结果，满足输出 schema 与 policy 校验，仅使用获授权工具，不产生重复或未授权副作用，不含重大幻觉，并在延迟上限内进入允许的终态。月度 SLO：合格任务成功率 ≥ [98.0]%。
4. 重大幻觉。虚假、捏造、自相矛盾或无依据的事实、引用、工具参数或动作，已经或有合理可能改变任务结果，或造成重大的财务、法律、网络安全、隐私、人身安全、客户或声誉损害。SLO：未受控的严重等级 1 事件为 0，裁定质量样本中的发生率 ≤ [1.0]%。
5. 工具调用成功。预定的获授权工具收到有效参数，仅执行一次，除非需要幂等重试，返回经验证结果，并准确产生预定状态。SLO：首次尝试成功率 ≥ [97.0]%，最终成功率 ≥ [99.0]%。每次调用和重试都保留在 telemetry 中。
6. 延迟。从任务被接受到完成、安全拒绝，或携带完整上下文进入 handoff 的端到端时间。交互任务：p50 ≤ [5] 秒，p95 ≤ [15] 秒，p99 ≤ [30] 秒。异步任务：p95 ≤ [5] 分钟。首 token 时间单独报告，不能代替完成延迟。
7. 升级与人工接管。[100]% 的强制触发条件必须路由至 [队列]，并带有任务摘要、来源、已尝试动作、工具结果、原因、风险级别和建议下一步。服务时段内人工确认 p95 ≤ [15] 分钟。完整 handoff 包进入队列时，人工计时开始。
8. 依赖与降级模式。附件 [X] 列出每项依赖、责任人、fallback 和 timeout。依赖不可用时，智能体不得编造结果或重复副作用。它必须保存已接受工作，进入获批准的降级模式，并在 [时间] 内恢复、拒绝或升级。
9. 变更。评测集、grader、prompt、模型、供应商、routing、retrieval 来源、工具 schema 和 guardrail 都要版本化。计划中的重大变更须提前 [30] 天通知，提交冻结 baseline 的回归报告，并在上线前获得客户批准。紧急变更须在 [1] 个工作日内通知并具备已测试 rollback。
10. 证据与保留。供应商每月交付 SLO 报告，并按要求提供任务级证据。经过隐私过滤的 trace 可查询 [90] 天，归档 [12] 个月，除非法律或数据附件要求不同期限。访问、脱敏、legal hold 和删除规则写入附件 [Y]。
11. 事件等级与补救。确认、遏制、恢复、根因报告、service credit、rollback、暂停和解约权遵循下表。除非主合同明确约定，service credit 不替代对保密、隐私、安全、知识产权或未授权动作的其他补救。
防止 SLA 争议的测量规则
| 字段 | 合同定义 |
|---|---|
| 测量周期 | 按 [时区] 的自然月统计，提供日常运营 dashboard，不得追溯删除失败任务。 |
| 记录系统 | 供应商 telemetry 与客户任务 ID 对账。客户可导出原始指标事件和版本登记表。 |
| 质量样本 | 每月至少 [200] 个合格任务的分层随机样本，外加所有投诉、人工 override、高风险动作和疑似重大幻觉。总量较低时审查全部任务，并披露样本限制。 |
| 裁定 | 能用确定性校验的先校验，其余由受过训练的 reviewer 按书面 rubric 判断。Reviewer 可以看证据，但不能看到供应商希望得到的结论。争议交由 [客户领域专家或独立第三方]。 |
| 分段 | 按任务类别、语言、渠道、风险级别和模型版本报告。优秀的总分不得掩盖失败的关键分段。 |
| 排除项 | 只有列明的排除项有效。每个被排除任务仍保留 trace、reason code、证据和持续时间。笼统的“第三方问题”不够。 |
| 版本 | 每次测量记录当时的 prompt、模型、供应商、工具、retrieval corpus、policy 和评测集版本。 |
公式应保持简单：成功任务率 = 成功的合格任务 / 全部合格任务 × 100。不要用已经结束的 agent run 作为分母。那会把 timeout、死循环和失败 handoff 排除掉，而这些正是客户花钱要求控制的故障。
1. 用业务结果定义成功任务
“模型返回了答案”不等于完成。客服智能体的成功条件可以是：答案符合政策并引用获批准来源，CRM 只更新一次，客户获得正确解决方案或进入正确人工队列。发票智能体的成功条件可以是：必填字段都与原始单据一致，置信度规则已执行，未经指定审批不得发起付款。
每个任务类别都要写自己的完成判定。安全拒绝可以是正确行为，但除非商业模型明确约定，不应算作已完成业务结果。分别报告 straight-through completion、安全拒绝和人工接管，避免供应商靠把所有任务升级来达标。
2. 把重大幻觉写成严重等级定义
NIST 生成式 AI Profile使用 confabulation 描述被自信表达的虚假或错误内容。合同还需要更窄的重大性测试：主张或动作是否无依据或错误，它是否能够改变结果或造成实际损害？
错别字、无害的风格问题或明确标注的不确定性不属于重大幻觉。捏造退款政策、引用不存在的法律条文、虚构客户同意、给出错误银行账号，或基于虚构状态调用工具，都属于重大幻觉。错误草稿若被强制 verifier 在对外产生影响前拦截，仍然是质量缺陷，但不是未受控的等级 1 事件。两个数字都要保留，遏制可以降低等级，不能抹掉证据。
3. 同时测量工具首次成功和最终成功
只看最终成功会奖励 retry storm，只看首次成功又忽略安全恢复能力。两者都要报告，每次尝试都保留在 trace 中。成功调用必须满足五点：正确且获授权的工具、有效参数、执行时仍有权限、响应得到验证、预定状态只改变一次。
退款、预订、发送邮件和写数据库等动作必须使用幂等键。未授权调用、重复不可逆动作或绕过强制审批，都自动判为失败并触发约定事件等级，即使下游 API 返回 success。
4. 把整个工作流放进延迟计时
测量客户买到的体验，不是最快的模型 span。计时包括 routing、retrieval、模型调用、工具执行、validator、retry 和供应商控制的排队时间。只有在完成、安全拒绝或完整 handoff 时停止。随后单独启动人工响应 SLO。
Google SRE 关于 SLO 的指南建议用百分位数，因为平均值会隐藏长尾。p50 表示典型体验，p95 用于运营承诺，p99 用于合理的最差体验。交互、语音、batch 和高风险审批任务需要不同目标。
5. 把升级触发条件和上下文包写进合同
强制触发条件应是可观测规则，不能只依赖模型自报“信心不足”。常见触发包括超出范围、缺少必需来源、写工具超过 retry budget 后仍失败、客户记录冲突、达到 policy 阈值、受监管决定、用户要求人工、疑似 prompt injection，或动作金额超过审批门槛。
只有当任务进入指定队列，并携带足够上下文让人工无需重建对话就能处理时，handoff 才算成功。测量触发识别、路由正确率、上下文完整率、确认、解决和 reopen rate。英国 ICO 的人工审查指南还建议记录人工 override 及其理由，这些数据应进入下一版评测集。
6. 分配依赖不可用的责任，不要把它隐藏
列出模型 API、vector store、身份服务、CRM、支付服务、客户数据源和人工队列。每项都要写明谁选择并控制、timeout、retry budget、fallback、数据保存行为和事件责任人。
客户控制的故障可以在有证据的时段内免于质量 credit，但仍要出现在依赖与降级报告里。供应商自己选择的模型提供商不能成为笼统免责条款。供应商也许控制不了上游宕机，却能控制 timeout、circuit breaker、排队、fallback、防重复与如实告知用户。
7. 冻结评测基线，但不要冻结学习
对测试用例、预期结果、rubric、grader、类别权重和抽样方式进行版本管理，每次 release 保存 hash。任何一方都不能为了让当前系统通过而删除难例、把失败改成通过，或更换 grader。
新风险仍要加入评测集。实用做法是双报告：冻结 baseline 与拟议新版本并行运行一个完整测量周期，展示各类别 delta，批准后从指定日期启用新版。保留隐藏 holdout 并检查测试污染。NIST AI RMF要求记录测试集、指标和工具，在接近部署的条件下评估，并持续监控生产表现。
8. 把模型供应商变更当成生产 release
重大变更包括供应商、模型家族、snapshot、routing、system prompt、工具 schema、retrieval corpus、安全 policy 或 grader。在供应商支持时固定版本。OpenAI 自己的 API 兼容性指南也提醒不同 snapshot 的 prompting 行为可能改变，并建议固定模型版本和实施 eval。
要求提前通知，按任务分段提交回归证据，数据路径改变时重新做安全审查，披露成本和延迟变化，指定批准人并保留 rollback。遇到上游强制退役，供应商必须及早提交迁移证据，让客户能在批准后继模型、切换 fallback 或暂停受影响任务之间选择。
9. 保存能证明指标的 trace，不是盲目保存一切
每个任务需要唯一任务 ID 与 trace ID、任务类别、时间戳、actor 与 tenant、模型和 prompt 模板版本、retrieval 文档 ID 与修订号、工具名与脱敏参数、结果状态、retry、审批、handoff 事件、最终处置、指标 reason code 和关联 incident。只有数据附件允许时才保存原始 prompt 或 output。
OpenTelemetry 的 GenAI observability 指南展示智能体、模型与工具 span，也明确提醒消息可能含敏感数据。访问控制、脱敏、存储区域、legal hold、导出和删除必须与 retention 一起约定。如果客户在争议时拿不到证据，“我们有日志”就不是审计条款。
10. 把事件等级连接到遏制与商业补救
下列数值是可编辑起点。响应时间要与服务时段、风险和支持价格相匹配。
| 等级 | 示例触发条件 | 运营承诺 | 合同补救 |
|---|---|---|---|
| 严重等级 1，关键 | 未授权不可逆动作、个人数据泄露、造成严重影响且未受控的重大虚假内容、大范围不安全输出，或审计证据丢失。 | [15] 分钟内确认，[60] 分钟内禁用或遏制，[4] 小时内恢复安全服务，通知指定联系人，保存证据，并在 [5] 个工作日内提交根因和预防报告。 | 立即暂停受影响自治能力，供应商承担 rollback 成本，返还受影响月费的 [25]%；[一次] 未修复或 [六] 个月内 [两次] 重复事件触发解约权。 |
| 严重等级 2，重大 | 月度质量或延迟 SLO 未达标、重复工具故障、重要分段 handoff 失效，或依赖 fallback 不能工作。 | [1] 个工作小时内确认，[1] 个工作日内缓解，[2] 个工作日内恢复，[5] 个工作日内提交整改计划。 | 每个核心 SLO 返还受影响月费的 [10]%，当月上限 [25]%，并强制整改。滚动 [六] 个月内 [三个] 月度违约触发解约权。 |
| 严重等级 3，轻微 | 孤立且不重大的缺陷、非关键 metadata 不完整，或不影响客户的报告延迟。 | [1] 个工作日内确认，[10] 个工作日或约定 release 内修复。 | 修复并进入改进 backlog。重复同类事件合并升级为等级 2。 |
Credit 应根据双方可见证据自动产生，不应依赖只有供应商才能计算的短申诉期。它还必须有升级路径。10% 的退款不能让未授权付款变得可以接受。对适用的受监管金融机构，DORA 第 30 条提供了值得参考的合同机制：精确的定量与定性服务目标、重大变化通知、持续监控、审计权、纠正行动和退出计划。DORA 不适用于所有买方，但这些机制依然有用。
为什么模型提供商的 SLA 覆盖不了你的智能体
上游 SLA 是架构输入，不是客户结果。例如 Vertex AI Platform SLA用服务器端错误率定义 downtime，并给出分级 credit。它不会承诺智能体选对工具、引用真实来源或完成业务流程。你的供应商合同必须把上游可用性转成端到端设计，再增加质量、handoff 与审计义务。
因此成本也要和可靠性一起写。能守住 SLO 却把成本提高十倍的 fallback，可能保住连续性却毁掉 business case。用 AI 智能体每次成功行动成本管理商业分母，并约定谁承担 retry、备用提供商、人工返工和事件修复。
欧盟采购与合规语境
不要声称使用本模板就自动合规。分类与义务取决于预期用途和行业。如果适用欧盟《人工智能法案》的高风险规则，其正式文本在第 12、14 和 15 条涉及自动日志、人工监督、准确率、稳健性与网络安全。欧盟公共采购社区还提供 AI 模型合同条款，同时说明它并非完整合同，必须按场景定制。
商业 SLA 应与数据处理协议、安全附件、知识产权、AI 使用限制、监管角色、保险、责任和退出协助并列，而不是替代它们。英国 ICO 的 AI 合同与第三方指南明确建议在采购前确定可接受准确率，并把准确率 KPI 或 SLA 写入供应商合同。
"真正困难的不是在 98% 和 97% 之间选一个数字，而是定义分母、保留失败 trace，并约定智能体自信地答错时供应商必须做什么。做到这些，指标才会变成合同。"
AI 智能体 SLA 常见问题
什么是 AI 智能体 SLA？
合同中应如何测量 AI 智能体准确率？
什么是重大幻觉？
模型提供商宕机应排除在 SLA 之外吗？
评测集或模型变更时怎么办？
生成式 AI SLA 应包含哪些补救措施？
AI SLA 和 AI 验收标准是一回事吗？
最终思考
有用的 AI 智能体 SLA 会把一个工作流绑定到一个分母、一条证据链和一种后果。它不会抽象承诺模型准确，而是明确哪些任务计入、怎样才算完成、哪些错误属于重大、人工计时何时开始、依赖与变更如何处理，以及违约后供应商承担什么。
方括号里的数字应来自你的试点证据，而不是供应商 benchmark。然后让工程团队证明 trace、评测登记表、handoff 队列、rollback 与月报确实能够生成。如果系统无法提供证据，合同条款就只是表演。
研究来源
资料于 2026 年 7 月 19 日研究并核对。标准、供应商条款与监管实施可能变化，签署前请再次核查最新原文。
- NIST AI 600-1，生成式人工智能 Profile，confabulation 与风险控制。
- NIST AI RMF Core，测试集记录、近生产评估与持续监控。
- 欧盟条例 2024/1689，《人工智能法案》，第 12、14、15 条。
- 欧盟条例 2022/2554，DORA，适用金融机构的第 30 条。
- ICO，AI 合同与第三方，准确率尽调、KPI 与审计条款。
- Google SRE Book，Service Level Objectives，指标、百分位数、测量周期与 error budget。
- Google Cloud Vertex AI Platform SLA，上游 uptime、排除项与 credit。
- OpenTelemetry，GenAI observability，智能体、模型与工具 trace，以及敏感内容。
- OpenAI API 兼容性指南，模型 snapshot、固定版本与 eval。
- AgentSLA: Towards a Service Level Agreement for AI Agents，智能体服务质量规范研究。
想把 SLA、eval 与 audit trail 设计成一个生产系统吗？
讨论你的 AI 智能体