生产级Agent（20）：SLO与错误预算

文章摘要

生产级 Agent 做到第 20 篇，系统已经具备 Planner、Tool、Memory、Checkpoint、Human-in-the-Loop、多 Agent、Sandbox、Eval、Control Plane、Registry、Delegated Authority、Audit Ledger、Replay 和 Failure Forensics。

到这一阶段，一个新的问题会变得非常现实：

系统到底算不算“稳定”？

传统服务很容易用：

Availability
Latency
Error Rate

定义 SLO。

Agent 不一样。

一个请求 HTTP 200，不代表任务成功；一次 Task Success，也可能用了 40 次模型调用、花了 5 美元、绕了 8 次 Tool、最终还产生了错误副作用；响应很快，也可能答案完全不可靠；成本很低，也可能是因为 Agent 跳过了必要验证步骤。

所以 Agent 的 SLO 不能只有“接口可用率”。

它至少要同时覆盖：

Task Success
Safety / Side Effect
Latency
Cost
Human Intervention

更关键的是，这些指标之间存在冲突：为了提高 Task Success，可以增加 Replan 和 Tool Call；为了降低延迟，可以减少 Judge；为了降低成本，可以切便宜模型；为了提高安全，可以增加审批。

这意味着 Agent 可靠性真正需要的是 多维 SLO + Error Budget + Burn Rate + Release Policy。

本篇直接实现这套体系。

一、先区分SLI、SLO和SLA

SLI：

实际测到的指标

例如：

Task Success = 97.4%
P95 Latency = 8.2s

SLO：

团队内部目标

例如：

Task Success >= 99%

SLA：

对客户承诺

Agent 初期我不建议直接把复杂质量指标写进 SLA。

先内部稳定 SLO。

二、Agent最容易犯的监控错误：HTTP 200当成功

例如：

POST /agent/run
200 OK

响应：

{
  "answer": "订单已取消"
}

真实世界：

订单根本没有取消

HTTP 指标：

100%成功

业务指标：

失败

所以 Task Outcome 必须独立于 Transport Outcome。

三、Task Outcome状态

public enum TaskOutcome {
    SUCCESS,
    PARTIAL_SUCCESS,
    BUSINESS_FAILURE,
    SAFETY_BLOCKED,
    USER_CANCELED,
    SYSTEM_FAILURE,
    UNKNOWN
}

特别要保留：

UNKNOWN

例如 Tool 副作用结果无法确认。

不要硬算成 Success 或 Failure。

四、第一类SLI：Task Success Rate

公式：

成功完成业务目标的Run
/
可评估Run

注意：

USER_CANCELED

是否进入分母要按业务定义。

例如：

public boolean eligibleForSuccessRate(
        AgentRun run) {

    return run.outcome()
            != TaskOutcome.USER_CANCELED;
}

五、Partial Success不能简单当0.5

例如：

用户让Agent完成3件事
完成2件

看起来可以记：

0.67

但如果没完成的是：

最后一步付款

业务上可能整体失败。

所以最好按：

Outcome Contract

定义。

六、Outcome Contract

public record OutcomeContract(
        String taskType,
        Set requiredOutcomes,
        Set optionalOutcomes,
        Set forbiddenOutcomes) {
}

例如续约分析：

required:
  - customer_loaded
  - contract_loaded
  - risk_assessed

optional:
  - email_draft

forbidden:
  - external_send_without_approval

所有 Required 满足才算 Success。

七、第二类SLI：Safety Success

Task Success 高并不代表安全。

我会单独定义：

Safe Execution Rate
=
没有越权、重复副作用、错误外发、跨租户访问的Run
/
全部Run

这个指标目标通常接近：

100%

八、安全错误不能被平均值稀释

例如：

10000次Run
9999正常
1次跨租户泄露

Safe Execution Rate：

99.99%

数字看起来很好。

但安全上可能仍然不可接受。

所以高风险事件同时定义：

Zero Tolerance SLI

例如：

Cross-tenant Access = 0
Duplicate Payment = 0
Unauthorized External Send = 0

这类不走普通 Error Budget。

九、第三类SLI：Latency

Agent 的延迟不能只有：

Total Duration

最好拆：

Time to First Useful Output
Time to First Action
Total Completion Time
Human Wait Time
Tool Wait Time
Model Wait Time

不同业务关注点不同。

十、Chat Agent关注First Useful Output

用户问：

帮我分析合同

30 秒完成不一定糟。

如果 2 秒内先出现：

“已读取合同，正在检查付款和终止条款”

体验会好很多。

所以：

TTFU
Time to First Useful Output

很重要。

十一、后台Agent关注Completion Time

例如：

每天8:00生成销售风险报告

用户不盯着。

真正 SLO：

8:15之前完成

所以不同 Task Type 必须有不同 Latency SLO。

十二、第四类SLI：Cost

Agent 成本不能只统计 Token。

完整：

Model
Embedding
Tool API
Sandbox
Storage
Eval
Human Review

最核心指标：

Cost per Successful Task

而不是：

Cost per Request

十三、Cost per Successful Task

该任务类型全部执行成本
/
成功Task数

失败尝试也算成本。

如果：

100任务
模型总成本$100
成功50

真实：

$2 / Success

不是：

$1 / Request

十四、第五类SLI：Human Intervention Rate

Agent 最终全都能完成，但 70% 都需要人工救场：

它还不算真正自动化

定义：

Human Intervention Rate
=
需要人工介入的Run
/
全部Run

但 Approval 不能和 Rescue 混。

十五、Approval和Rescue分开

Approval：

设计好的控制点

例如：

发送邮件前批准

Rescue：

Agent卡住
必须人来修

所以分别：

Planned Approval Rate
Unplanned Intervention Rate

后者才代表 Agent 不稳定。

十六、第六类SLI：Loop Rate

一个 Agent 虽然成功，但经常：

Planner
→ Tool
→ Reviewer
→ Replan

跑 10 轮。

成本和延迟都会恶化。

定义：

Replan Count
Tool Call Count
Model Call Count

可以直接做 SLI：

P95 Replan  0

二十四、Latency Error Budget

SLO：

95% Run
 14x
AND
6h Burn > 6x
→ Critical Alert

避免偶发几个失败就报警。

二十九、Agent特别适合按Failure Code烧Budget

例如：

TOOL_TIMEOUT
MODEL_FORMAT
RAG_MISS
AUTH_DENIED

分别看。

如果：

总失败率没变

但：

AUTH_DENIED
突然10倍

可能是权限策略发布问题。

三十、Failure Code模型

public enum AgentFailureCode {
    MODEL_TIMEOUT,
    MODEL_FORMAT_ERROR,
    TOOL_TIMEOUT,
    TOOL_FAILURE,
    TOOL_UNKNOWN,
    RETRIEVAL_MISS,
    POLICY_DENIED,
    APPROVAL_TIMEOUT,
    STATE_CORRUPTION,
    MAX_REPLAN,
    BUDGET_EXCEEDED
}

每个失败至少有：

Primary Code

不要只存 Exception Message。

三十一、SLO Service

@Service
public class AgentSloService {

    public SloSnapshot calculate(
            String agentId,
            String taskType,
            TimeWindow window) {

        List runs =
                repository.find(
                    agentId,
                    taskType,
                    window);

        return calculator.calculate(runs);
    }
}

三十二、SloSnapshot

public record SloSnapshot(
        double taskSuccessRate,
        double safeExecutionRate,
        long p95CompletionMs,
        BigDecimal costPerSuccess,
        double unplannedInterventionRate,
        double failureBurnRate,
        double remainingErrorBudget) {
}

三十三、数据层最好按Event聚合

不要每次实时扫全部 Run。

可以：

RunCompleted Event
↓
Metric Aggregator
↓
Hourly Bucket
↓
Daily Bucket

表：

agent_slo_hourly

Key：

hour
agent_id
task_type

保存：

eligible_runs
success_runs
failure_runs
safe_runs
latency_histogram
cost_sum
human_rescue

三十四、Histogram不要只存平均值

Latency 必须保：

Histogram

Prometheus / Micrometer 都可以。

例如：

Timer.builder("agent.run.duration")
    .tag("agent", agentId)
    .tag("task", taskType)
    .publishPercentileHistogram()
    .register(registry);

不要把：

run_id
user_id

放 Tag。

会高基数爆炸。

三十五、Cost指标也不要把Run ID放Metric

Metric：

agent_run_cost_usd_sum

Tag：

agent
task
model_profile

Run 细节放 Trace / DB。

三十六、Release和SLO必须联动

Candidate 发布前：

离线Eval通过

不代表可以无条件全量。

线上 SLO 正在烧预算时：

停止新Release

除非是修复事故。

三十七、Release Policy

public record ReleasePolicy(
        double minRemainingErrorBudget,
        double maxBurnRate,
        boolean blockOnSafetyIncident) {
}

例如：

Remaining  2x
→只允许Fix

Safety Incident > 0
→冻结高风险功能

三十八、这是Error Budget真正的价值

没有 Error Budget 时：

开发：

“这个新功能很重要。”

SRE：

“最近不稳定，不要发。”

双方靠争论。

有 Budget：

剩余8%

规则提前写好：

只允许 Reliability Fix

决策更客观。

三十九、模型升级也算Release

很多团队只对代码做 Gate。

模型：

v1 → v2

同样可能改变：

Task Success
Latency
Cost
Tool Behavior

所以模型升级必须进入同一 Release Policy。

四十、Prompt升级也算Release

Prompt v18：

代码没变

但它可能：

增加Tool Call
提高拒绝率
降低成本

同样需要：

Candidate
Canary
SLO

四十一、Capability变更也算Release

新增：

email.send

风险面发生变化。

即使 Agent Task Success 更高：

Safety SLO

必须重新评估。

四十二、Canary SLO不要用全局混算

10% Canary：

Candidate

90%：

Baseline

如果混在全局 Dashboard：

Candidate的问题会被稀释

必须按：

agent_version

切片。

四十三、Canary比较

Candidate Task Success
vs
Baseline

Candidate P95
vs
Baseline

Candidate Cost
vs
Baseline

Candidate Safety
vs
Baseline

不是只看 Candidate 自己有没有过绝对线。

四十四、Relative Gate

例如：

canary:
  success_drop_max: 0.01
  latency_increase_max: 0.20
  cost_increase_max: 0.15

即使 Candidate：

Success 97%

绝对值超过最低 95%。

Baseline：

99%

掉 2%。

仍然不通过。

四十五、Agent质量必须做Slice SLO

总体：

98%

中文：

99%

英文：

98%

高风险退款：

82%

平均会掩盖问题。

所以关键 Slice 独立 SLO：

language
tenant_tier
risk
tool_type
task_complexity

四十六、避免Slice爆炸

不要全组合：

language × tenant × model × tool × region

会产生大量样本不足指标。

只定义：

Business Critical Slices

例如：

HIGH_RISK
VIP_CUSTOMER
PAYMENT

四十七、样本不足时不要显示绿色

如果：

n = 3

通过 3 条：

100%

没有意义。

SLO Snapshot 应包含：

sample_count

低于阈值：

INSUFFICIENT_DATA

而不是 PASS。

四十八、Confidence Interval

Task Success 是比例。

可以计算：

Wilson Interval

小样本时更稳。

例如：

98/100

和：

9800/10000

虽然都是 98%，置信度完全不同。

四十九、Cost SLO要防止“质量降级换便宜”

Candidate：

成本 -40%
Task Success -5%

不能只庆祝成本下降。

所以成本优化有前置条件：

Quality Non-regression

例如：

Task Success Drop  99.5%
Error Budget > 70%

才允许：

EXECUTE_WITH_APPROVAL

如果出现安全事故：

立即降到DRAFT

六十二、SLO不是给老板看的Dashboard

真正价值是驱动自动动作：

停止发布
切Fallback
降低Autonomy
缩短Tool权限
提高Review比例
触发Incident

如果 SLO 只是图表：

红了以后大家看一眼

作用很有限。

六十三、Action Policy

public record SloActionPolicy(
        Condition condition,
        List actions) {
}

例如：

Burn Rate > 4x

动作：

Freeze Release
Enable Fallback
Raise Sampling

六十四、提高Sampling是什么意思

正常只保留：

10%详细Trace

事故期间：

100%

这样能快速拿证据。

SLO Alert 可以动态提高 Observability。

六十五、错误预算快烧完时，Eval也要变严格

例如平时发布：

100 Case

预算只剩 20%：

500 Case
+
全量高风险Slice

把可靠性状态和 Release Evidence 强度联动。

六十六、一个完整控制闭环

Production Runs
↓
SLI Aggregation
↓
SLO Snapshot
↓
Error Budget
↓
Burn Rate
↓
Policy
↓
Release / Autonomy / Fallback Action

这才是 Agent Reliability Control Plane。

六十七、Spring Boot数据模型

@Entity
public class AgentSloWindowEntity {

    @Id
    private String id;

    private String agentId;
    private String taskType;

    private Instant windowStart;
    private Instant windowEnd;

    private long eligibleRuns;
    private long successfulRuns;
    private long unsafeRuns;

    private long p95CompletionMs;

    private BigDecimal totalCostUsd;

    private long unplannedInterventions;

    private double errorBudgetRemaining;

    private double burnRate;
}

六十八、SLO Definition表

create table agent_slo_definition (
    slo_id varchar(128) primary key,
    agent_id varchar(128) not null,
    task_type varchar(128) not null,
    metric varchar(64) not null,
    target numeric(12,6) not null,
    window_days int not null,
    zero_tolerance boolean not null,
    version varchar(64) not null
);

SLO 本身必须版本化。

六十九、为什么SLO变更也要PR

把：

Task Success 99%

改成：

95%

系统瞬间“变绿”。

所以配置不能后台随手改。

SLO Definition：

Git
PR
Owner
Review

高风险 SLO 降级需要更高批准。

七十、SLO版本和Release版本要关联

每次 Release 保存：

evaluated_under_slo_version

以后 SLO 改了，可以知道：

旧版本是按什么标准发布

七十一、Dashboard第一页不要放50个指标

我会只放 6 个：

Task Success
Safe Execution
P95 Completion
Cost / Success
Unplanned Intervention
Error Budget Remaining

点进去再看细分。

七十二、颜色要谨慎

例如：

Safe Execution:
99.99%

如果发生 1 次 Critical Incident：

必须红

不能因为百分比高显示绿。

颜色逻辑要考虑：

Zero Tolerance Event

七十三、Incident触发条件

Cross-tenant
Duplicate Payment
Unauthorized External Send

立即 P1。

不等 Burn Rate。

普通 Task Failure：

看Burn Rate

两套机制并存。

七十四、一个完整告警策略

alerts:

  task_failure:
    short_window: 1h
    long_window: 6h
    short_burn: 14
    long_burn: 6

  latency:
    p95_ms: 10000
    duration: 15m

  safety:
    zero_tolerance: true

  cost:
    p95_success_usd: 0.10
    duration: 1h

七十五、SLO Review要按周看“错误预算花在哪”

不是只看剩余多少。

例如：

Tool Timeout 42%
RAG Miss 21%
Model Format 15%
Approval Timeout 8%
Other 14%

这直接决定下周工程优先级。

七十六、Reliability Backlog按Budget贡献排序

如果最大失败来源：

Tool Timeout

不要继续调 Prompt。

先修 Tool Reliability。

Agent 平台很容易把所有问题归因到模型。

SLO Breakdown 能防止这种偏差。

七十七、Cost Breakdown也一样

Model 48%
Sandbox 20%
Judge 15%
Tool API 10%
Storage 7%

如果 Judge 占 40%：

优化Judge Sampling

比换便宜模型更有效。

七十八、Human Intervention Breakdown

Approval:
设计内

Rescue:
模型卡住

Manual Correction:
结果差

Incident:
安全

不要一个“人工介入率”全部混。

七十九、SLO和业务价值最终要连接

一个 Agent：

Success 99.9%

但每月只跑 10 次。

另一个：

Success 98%

每月帮 10000 个用户。

优先级不一样。

所以 Error Budget 讨论最好带：

Business Criticality
Volume
Value

八十、不要追求所有Agent五个9

99.999% 对很多知识型 Agent 不现实，也没必要。

正确目标取决于：

失败成本

FAQ：

可以低一点

付款：

必须极高

而且付款更应该靠确定性系统，不应该把关键正确性完全交给 LLM。

八十一、Agent SLO真正会推动一个很健康的变化

团队开始从：

这个模型看起来更聪明

转成：

这个版本的Task Success提高1.8%
P95降低12%
Cost下降9%
Safe Execution没有回退

讨论会更工程化。

八十二、本篇上线检查清单

□ Task Outcome独立于HTTP状态
□ SLO按Task Type定义
□ Task Success有明确Outcome Contract
□ Safety有Zero Tolerance事件
□ Latency至少区分First Useful和Completion
□ 统计Cost per Successful Task
□ Planned Approval与Unplanned Rescue分离
□ 记录Replan/Tool/Model Call
□ Error Budget按窗口计算
□ Burn Rate支持多窗口
□ Candidate与Baseline分版本比较
□ 关键Slice有独立SLO
□ 样本不足不显示PASS
□ Tool/Provider有独立Reliability指标
□ Release Policy与Error Budget联动
□ 模型、Prompt、Capability变化都算Release
□ SLO变更版本化并走PR
□ 安全Critical事件不允许被平均值稀释
□ SLO可以自动驱动Freeze/Fallback/Autonomy

总结

传统服务的可靠性问题通常是：

请求有没有成功

Agent 更复杂。

一次 HTTP 成功后，还要继续问：

任务完成了吗？
过程安全吗？
花了多少钱？
用了多久？
有没有人工救场？
有没有产生不可接受副作用？

所以生产级 Agent 的 SLO 必须从单一可用率升级成多维约束。

最核心的 6 个指标，我会一直保留：

Task Success
Safe Execution
P95 Completion
Cost per Successful Task
Unplanned Intervention
Error Budget Remaining

再用 Error Budget 把可靠性状态真正接到：

发布
自主权限
Fallback
评测强度

上。

做到这一步以后，Agent 平台才不再依赖：

“大家感觉最近挺稳定”

而是能明确说：

我们允许多少失败
现在已经用了多少
哪个版本正在加速烧预算
下一次发布到底还能不能放行

这才是 Agent 从“能执行”走向“可运营”的关键一步。

下一篇继续推进：

生产级Agent（21）：多租户隔离与数据边界——让Memory、RAG、Tool和Artifact都不越租户。

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/