---
name: sli-slo-pyramid
version: 2.0
framework: 智能体管理学 · 模块五 · 框架F28
type: 决策型
description: >
  三层SLI/SLO金字塔——为智能体建立成本层、性能层、质量层三层指标体系，
  通过Error Budget机制管理质量与成本的平衡。触发词：SLI、SLO、Error Budget、
  质量目标、指标体系、Agent监控、质量门禁
governance_nerves: [意图管理, 边界与升级]
upstream_frameworks: [F27_AgentOps成熟度评估, F30_CPTA成本核算]
downstream_frameworks: [F29_Agent绩效考核, F32_风险治理框架]
---

# F28 三层SLI/SLO金字塔

## SKILL定位

**核心命题**：传统SRE的指标体系（可用性/延迟/错误率）在Agent场景有三个盲区——任务是否真正完成、成本是否可控、质量是否稳定。三层金字塔解决这个问题。

**三层结构**：

```
        ┌─────────────┐
        │   质量层     │  ← 用户感知：任务完成率、准确率、满意度
        │  (Quality)   │
        ├─────────────┤
        │   性能层     │  ← 系统表现：延迟、吞吐、可用性
        │ (Performance)│
        ├─────────────┤
        │   成本层     │  ← 经济可行：CPTA、Token效率、工具调用成本
        │   (Cost)     │
        └─────────────┘
```

**关键认知**：三层之间存在制约关系——追求质量会推高成本，追求性能会牺牲质量，追求成本会限制性能。Error Budget是管理这个三角关系的核心机制。

---

## 信息采集（INPUT模板）

```yaml
slo_input:
  # 一、Agent基本信息
  agent:
    name: ""                    # Agent名称
    type: ""                    # 类型（客服/分析/创作/执行）
    task_domain: ""             # 任务领域
    daily_task_volume: 0        # 日均任务量
    business_criticality: ""    # 业务关键性（高/中/低）

  # 二、成本层指标
  cost_layer:
    cpta_current: 0             # 当前CPTA（元/任务）
    cpta_target: 0              # 目标CPTA
    token_cost_ratio: 0         # Token成本占比（%）
    tool_call_cost_ratio: 0     # 工具调用成本占比（%）
    human_review_cost_ratio: 0  # 人工审校成本占比（%）

  # 三、性能层指标
  performance_layer:
    p50_latency: 0              # P50延迟（秒）
    p99_latency: 0              # P99延迟（秒）
    availability: 0             # 可用性（%）
    throughput: 0               # 吞吐量（任务/小时）
    retry_rate: 0               # 重试率（%）

  # 四、质量层指标
  quality_layer:
    task_completion_rate: 0     # 任务完成率（%）
    accuracy_rate: 0            # 准确率（%）
    user_satisfaction: 0        # 用户满意度（1-5）
    hallucination_rate: 0       # 幻觉率（%）
    escalation_rate: 0          # 升级率（%）

  # 五、当前Error Budget消耗
  error_budget:
    budget_period: ""           # 预算周期（周/月）
    consumed: 0                 # 已消耗（%）
    remaining: 0                # 剩余（%）
    burn_rate: 0                # 消耗速率
```

---

## 执行分析引擎（S1-S4四步法）

### S1：定义SLI（Service Level Indicators）

**任务**：为每层选择可量化、可追踪、与用户价值对齐的指标。

**SLI选择标准**：
1. **用户可感知**：指标变化用户能感受到
2. **可量化采集**：有明确的数据来源和计算方式
3. **可归因**：指标变化能追溯到具体原因
4. **可行动**：指标异常时有明确的应对措施

**三层SLI模板**：

```yaml
sli_definitions:
  cost_layer:
    - name: "CPTA"
      formula: "总成本 / 业务语义成功任务数"
      unit: "元/任务"
      data_source: "成本追踪系统"
      collection_frequency: "实时"
    - name: "Token效率"
      formula: "有效Token / 总Token"
      unit: "%"
      data_source: "LLM API日志"

  performance_layer:
    - name: "任务P99延迟"
      formula: "P99(任务完成时间)"
      unit: "秒"
      data_source: "链路追踪系统"
    - name: "端到端可用性"
      formula: "成功响应数 / 总请求数"
      unit: "%"
      data_source: "API网关日志"

  quality_layer:
    - name: "业务语义完成率"
      formula: "业务判定成功数 / 总任务数"
      unit: "%"
      data_source: "人工抽样 + LLM-as-Judge"
      judge_prompt: "评估Agent是否真正完成了用户任务..."
    - name: "幻觉率"
      formula: "含幻觉的输出数 / 总输出数"
      unit: "%"
      data_source: "事实核查Agent"
```

### S2：设定SLO目标（Service Level Objectives）

**任务**：为每个SLI设定合理的目标值，基于业务需求而非技术能力。

**SLO设定原则**：
1. **基于用户期望**：用户能容忍多大延迟？多低的准确率？
2. **基于业务价值**：这个Agent的业务影响有多大？
3. **基于历史数据**：过去30天的表现基线是什么？
4. **留有Error Budget**：SLO不能设为100%，需要给改进留空间

**目标设定模板**：

```yaml
slo_targets:
  cost_layer:
    cpta:
      target: 2.5              # 目标CPTA（元）
      floor: 1.0               # 不可低于（说明质量可能下降）
      ceiling: 5.0             # 不可高于（说明成本失控）
      error_budget: 10%        # 允许10%的任务超标

  performance_layer:
    p99_latency:
      target: 30               # 目标P99延迟（秒）
      error_budget: 5%         # 允许5%的请求超标
    availability:
      target: 99.5             # 目标可用性（%）
      error_budget: 0.5%       # 允许0.5%不可用

  quality_layer:
    task_completion_rate:
      target: 95               # 目标完成率（%）
      error_budget: 5%         # 允许5%失败
    accuracy_rate:
      target: 98               # 目标准确率（%）
      error_budget: 2%         # 允许2%错误
```

### S3：建立Error Budget机制

**任务**：将SLO转化为可管理的Error Budget，建立消耗-响应机制。

**Error Budget计算**：

```
Error Budget = 1 - SLO目标

示例：
- SLO = 95%完成率 → Error Budget = 5%（每100个任务允许5个失败）
- 月度任务量 = 3000 → 月度Error Budget = 150个失败任务
- 当前消耗 = 80个 → 剩余 = 70个 → 消耗率 = 53%
```

**消耗-响应矩阵**：

```yaml
error_budget_policy:
  period: "月"
  
  thresholds:
    - range: "0-50%"
      status: "健康"
      action: "正常迭代，可部署新功能"
      human_involvement: "无需介入"
    
    - range: "50-80%"
      status: "关注"
      action: "加强监控，新功能需额外审查"
      human_involvement: "团队Lead知晓"
    
    - range: "80-100%"
      status: "警告"
      action: "冻结新功能，全力修复问题"
      human_involvement: "管理层介入"
    
    - range: ">100%"
      status: "超支"
      action: "紧急复盘，暂停部分功能，增加人工兜底"
      human_involvement: "高管介入"

  cross_layer_constraints:
    rule: "成本层Error Budget超支时，质量层SLO自动收紧2%"
    rationale: "防止以质量为名无限制推高成本"
```

### S4：LLM-as-Judge校准与治理

**任务**：对于质量层中需要主观判断的指标（如"任务是否真正完成"），建立LLM-as-Judge机制并持续校准。

**校准流程**：

```yaml
judge_calibration:
  step_1: "人工标注：每月抽样100条，人工判定成功/失败"
  step_2: "LLM判定：同一100条用Judge Agent判定"
  step_3: "一致性检查：计算人机一致性（Kappa系数）"
  step_4: "校准：一致性<0.8时，调整Judge Prompt或更换模型"
  
  calibration_schedule: "每月1次"
  minimum_agreement: 0.8       # 最低一致性要求
  
  judge_prompt_template: |
    请判断以下Agent输出是否真正完成了用户任务。
    任务描述：{task_description}
    Agent输出：{agent_output}
    判定标准：
    - 完成：输出直接解决了用户问题，无需进一步操作
    - 部分完成：输出提供了有价值信息但未完全解决
    - 失败：输出无关、错误或无法理解
    请输出判定结果和置信度（0-1）。
```

**治理神经检查**：
- **意图管理**：SLO目标是否真正反映用户期望，还是团队自嗨？
- **边界与升级**：Error Budget超支时，人类介入的边界是否清晰？

---

## 输出格式

```yaml
slo_pyramid_report:
  agent: "XX客服Agent"
  report_date: "2026-04-27"
  
  sli_summary:
    cost_layer:
      cpta: { current: 3.2, target: 2.5, status: "超标" }
      token_efficiency: { current: 72, target: 80, status: "偏低" }
    performance_layer:
      p99_latency: { current: 25, target: 30, status: "达标" }
      availability: { current: 99.7, target: 99.5, status: "达标" }
    quality_layer:
      completion_rate: { current: 93, target: 95, status: "未达标" }
      accuracy_rate: { current: 97, target: 98, status: "接近" }

  error_budget_status:
    cost_budget: { consumed: 75%, status: "关注" }
    quality_budget: { consumed: 90%, status: "警告" }
    performance_budget: { consumed: 30%, status: "健康" }

  cross_layer_tension: "质量层预算紧张，但成本层已超标——需要在质量和成本之间做取舍"
  
  recommended_actions:
    - "优先：降低CPTA（当前3.2，目标2.5）"
    - "关注：质量层Error Budget即将耗尽"
    - "建议：审查人工审校流程，减少不必要的升级"
```

---

## 质量自检

- [ ] 每层SLI是否至少有2个可量化指标？
- [ ] SLO目标是否基于用户期望而非团队能力？
- [ ] Error Budget是否设置了合理的消耗-响应阈值？
- [ ] LLM-as-Judge的校准是否达到Kappa≥0.8？
- [ ] 三层之间的制约关系是否在策略中体现？

---

## 典型误区

1. **"SLO越高越好"**：SLO=100%意味着没有Error Budget，团队会被束缚手脚
2. **"只看性能层"**：Agent的核心价值在质量层，性能达标但质量不达标毫无意义
3. **"Error Budget用不完就浪费了"**：Error Budget是管理工具，不是预算指标
4. **"LLM-as-Judge不需要校准"**：LLM判断会随模型版本漂移，必须定期校准

---

## 框架衔接

| 方向 | 框架 | 衔接关系 |
|------|------|----------|
| ↑ 上游 | F27 AgentOps成熟度评估 | M3跃迁需要本框架的SLI/SLO体系 |
| ↑ 上游 | F30 CPTA成本核算 | 成本层SLI依赖CPTA的精确计算 |
| ↓ 下游 | F29 Agent绩效考核 | SLO达标率是绩效评估的核心输入 |
| → 并行 | F32 风险治理框架 | Error Budget超支可能触发风险升级 |