对基于大模型的 Agent 服务而言，SLA 违约的难点不在于赔偿意愿，而在于违约事实能否被精确量化。传统 API 的响应时间、可用性可以用网关日志直接判定，但 Agent 在单次任务中可能经历多轮推理、工具调用和重试，单看某一次请求是否超时并不能代表整体服务质量。因此，赔偿机制必须建立在可观测、可对账、可审计的指标之上，否则即使合同写了赔付比例，也很容易被认定为口径不一致。
要解决赔偿与改进问题，需要把 SLA 从静态条款变成工程系统的一部分。下面从违约判定、赔偿计算、自动对账和改进闭环四个环节展开说明。
一、先定义 Agent SLA 的违约判定边界
Agent 服务不能只用一个“可用性 99.9%”来概括。它的任务执行链路通常包括推理、工具选择、工具调用、结果汇总等阶段，每个阶段都可能成为延迟或失败来源。合理的做法是把 SLA 拆成三层指标：任务级响应时间、任务成功率、关键步骤准确率。其中任务成功率的判断不能只看 HTTP 200，还要看 Agent 是否完成了用户预期的动作，比如是否成功写入数据、是否返回了可验证的结果。
工程上可以先实现一个轻量级监控器，记录每次任务的耗时和异常类型。下面是一个基础示例，用来判断单次任务是否超过约定的响应时间，并记录违约事件。
import time
from datetime import datetime
class AgentSLAMonitor:
def __init__(self, sla_seconds=30):
self.sla_seconds = sla_seconds
self.breach_events = []
def run(self, task_id, handler, *args, **kwargs):
start = time.time()
try:
result = handler(*args, **kwargs)
elapsed = time.time() - start
if elapsed > self.sla_seconds:
self.record_breach(task_id, "latency", elapsed)
return result
except Exception as exc:
elapsed = time.time() - start
self.record_breach(task_id, "error", str(exc))
raise
def record_breach(self, task_id, breach_type, detail):
event = {
"task_id": task_id,
"type": breach_type,
"detail": detail,
"time": datetime.utcnow().isoformat()
}
self.breach_events.append(event)
这个监控器只解决单次任务的可观测问题，真正判定违约还需要按时间窗口聚合。例如每 10 分钟统计一次成功率，如果成功率低于 95% 且持续两个窗口，才触发违约。这样能避免偶发抖动被误判为系统性违约，也更容易和合同条款对齐。
另外，Agent 的任务状态需要持久化。如果任务因为外部工具超时而中断，必须能在数据库中查到该任务的最终状态，而不是只有一条模糊的日志。状态可以设计为 pending、running、succeeded、failed、partial_success 五类，其中 partial_success 通常也要计入违约，因为它意味着用户体验受损。
二、赔偿机制：从合同条款到自动对账
赔偿方式没有统一标准，但常见的有四种：按次赔付、比例扣减、信用返还和阶梯赔付。按次赔付最简单，适合违约事件清晰且影响面小的场景；比例扣减更适合月度账单结算，比如当月可用性低于 99% 时，按差额比例扣减服务费；信用返还可以把赔偿金额存为账户余额，减少退款流程；阶梯赔付则对连续违约设置更高惩罚，倒逼服务方尽快恢复。
下表对比几种方式的特点，实际落地时可以组合使用。
| 赔偿方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 按次赔付 | 单次任务影响明确 | 计算简单，客户感知强 | 高频违约成本波动大 |
| 比例扣减 | 月度或季度结算 | 与整体服务水平挂钩 | 需要精确的聚合指标 |
| 信用返还 | 长期合作客户 | 减少退款流程，增强粘性 | 资金占用和服务成本滞后 |
| 阶梯赔付 | 连续或重大违约 | 激励快速恢复 | 合同条款较复杂 |
计算赔付金额时，建议把公式固化到代码中，避免人工计算错误。下面是一个按成功率和任务单价计算赔付金额的函数示例。
def calc_compensation(breach_count, total_tasks, price_per_task, credit_rate):
if total_tasks == 0:
return 0.0
success_rate = 1 - breach_count / total_tasks
if success_rate >= 0.99:
return 0.0
base = breach_count * price_per_task
penalty = base * credit_rate
return round(min(penalty, price_per_task * total_tasks), 2)
自动对账流程需要包含四个步骤：采集违约事件、按任务去重、生成赔付单、发送通知。每个赔付单必须带唯一幂等键，通常用 task_id 加违约时间窗口生成，防止重复赔付。举例来说，如果同一任务同时产生超时和错误两类事件，只能计为一次违约，否则会出现重复扣减。
对账结果应该定期生成报告，包含违约明细、聚合成功率、赔付金额和计算依据。这份报告既是对客户的交代，也是内部复盘的基础。不要只给一个总额，否则客户无法核对，后续争议仍然存在。
三、改进闭环：用错误预算推动稳定性
赔偿只是事后补偿，不能替代改进。Agent 服务的稳定性提升需要引入错误预算机制。错误预算是 SLO 允许的失败余量，例如月度成功率达到 99%，意味着允许 1% 的错误预算。当违约事件消耗错误预算后，团队应当暂停新功能发布，集中修复导致违约的根因，而不是继续叠加不确定性。
改进动作可以从几个方向切入。第一是重试和退避，对瞬时超时或第三方工具偶发错误，增加指数退避重试；第二是降级策略，当主模型不可用时，切换到备用模型或返回预置的兜底答案；第三是工具结果缓存，对高频且结果稳定的查询减少重复调用；第四是任务拆分，把长链路任务拆成多个可独立重试的子任务，避免全链路失败。
下面是一个简单的降级配置示例，描述 Agent 在连续失败达到阈值时的行为。
retry_policy: max_attempts: 3 backoff: exponential fallback: enable: true default_response: "当前服务繁忙，已记录任务并稍后重试" switch_to_backup_model: true
改进闭环需要把违约事件、根因分析和后续动作关联起来。每次违约触发后，系统应自动创建一条 incident 记录，标明影响范围、持续时间、责任环节和补救措施。如果同类根因反复出现，就说明此前的改进没有生效，需要升级处理。
同时要监控错误预算消耗速度。可以在告警规则中设置：当月度错误预算消耗超过 80% 时通知技术负责人，达到 100% 时自动冻结发布流程。这样错误预算就从理论概念变成实际约束，团队才有动力解决稳定性问题。
四、实施中的三个关键注意点
第一是幂等控制。自动对账系统最容易出现的问题就是重复赔付。除了赔付单的唯一键外，还需要在数据库层建立唯一约束，确保即使消息重复投递，也不会生成两条赔付记录。第二是审计留痕。所有违约判定、金额计算和赔付操作都必须有不可篡改的日志，建议使用只追加存储或带哈希链的审计表。第三是指标口径一致。合同里写的“成功”和工程里定义的“成功”必须完全一致，最好在合同附件中给出明确的判定规则和示例，否则发生争议时仍然缺少裁判依据。
从长期看，Agent SLA 违约处理不应被当作客服流程，而应作为稳定性工程的一部分。赔偿能安抚用户，但真正减少违约的是可观测性、自动化对账和错误预算驱动的改进机制。把这些能力提前落地，违约事件才会从损失变成推动系统优化的信号。