---
name: eval-matrix-design
version: 2.0
framework: 智能体管理学 · 模块四 · 框架F25
type: 决策型
description: >
  当用户提到评测矩阵、测试设计、评测指标、质量评估、
  场景覆盖、对抗测试、鲁棒性测试、安全性评测时触发本SKILL。
governance_nerves: [边界与升级]
upstream_frameworks: [F20_TripleE工程方法, F22_执行链路诊断]
downstream_frameworks: [F26_PRT质量门禁]
---

# F25 智能体评测矩阵

## SKILL定位

传统测试覆盖确定性路径，Agent需覆盖三层：正常路径验证功能、边缘路径验证鲁棒性、对抗路径验证安全性。

**核心判断：缺一层，质量画像不完整。**

三层评测结构：
- **正常场景**：用户正常使用路径，验证功能正确性
- **边缘场景**：异常输入、边界条件，验证鲁棒性
- **对抗场景**：恶意攻击、越权尝试，验证安全性

---

## 信息采集（INPUT模板）

```
【Agent信息】
- Agent类型：____
- 核心功能：____
- 用户群体：____
- 部署环境：____

【评测现状】
- 已有评测：____
- 评测频率：____
- 覆盖率估计：____%
- 最近一次质量事故：____

【质量要求】
- 功能正确性要求：____
- 响应时间要求：____
- 安全合规要求：____
- 用户体验要求：____

【资源约束】
- 评测团队：____人
- 评测工具：____
- 时间预算：____
```

---

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

### S1：三层评测结构设计

**目标**：设计完整的三层评测覆盖方案

**三层结构**：

| 层级 | 目标 | 场景来源 | 占比 | 通过标准 |
|------|------|---------|------|---------|
| 正常场景 | 功能正确性 | 用户故事、使用日志 | 60% | >95%通过率 |
| 边界场景 | 鲁棒性 | 边界分析、历史故障 | 30% | >85%通过率 |
| 对抗场景 | 安全性 | 威胁建模、红队测试 | 10% | >99%拦截率 |

**各层场景示例**：

**正常场景**：
- 标准问答、信息查询、任务执行
- 多轮对话、上下文理解
- 常见格式输入（文本、图片、文件）

**边界场景**：
- 超长输入、空输入、特殊字符
- 模糊意图、多意图混合
- 模型知识边界问题
- 并发请求、超时场景

**对抗场景**：
- Prompt注入攻击
- 越权操作尝试
- 敏感信息泄露尝试
- 资源滥用（无限循环、大量请求）

**输出模板**：
```
S1评测结构：
- 正常场景：____个，占比____%
- 边界场景：____个，占比____%
- 对抗场景：____个，占比____%
- 总计：____个场景
- 覆盖率评估：____
```

### S2：七维评测指标设计

**目标**：定义全面的评测指标体系

**七维评测指标**：

| 维度 | 指标 | 计算方式 | 阈值 |
|------|------|---------|------|
| 准确性 | 任务完成率 | 成功任务数/总任务数 | >90% |
| 相关性 | 回答相关度 | 人工评分/自动评分 | >4.0/5.0 |
| 安全性 | 攻击拦截率 | 拦截攻击数/总攻击数 | >99% |
| 鲁棒性 | 异常处理率 | 正确处理异常/总异常 | >85% |
| 效率 | 平均响应时间 | 总响应时间/请求总数 | <3秒 |
| 一致性 | 输出稳定性 | 相同输入多次运行的一致度 | >80% |
| 合规性 | 合规通过率 | 合规检查通过/总检查 | 100% |

**各维度评测方法**：

| 维度 | 自动评测 | 人工评测 | 混合评测 |
|------|---------|---------|---------|
| 准确性 | 规则匹配 | 专家评审 | LLM-as-Judge |
| 相关性 | 语义相似度 | 标注员评分 | 混合 |
| 安全性 | 攻击模式匹配 | 红队测试 | 混合 |
| 鲁棒性 | 异常注入 | 场景审查 | 混合 |
| 效率 | 性能监控 | - | 纯自动 |
| 一致性 | 统计分析 | - | 纯自动 |
| 合规性 | 规则检查 | 合规审查 | 混合 |

**输出模板**：
```
S2指标体系：
- 定义指标数：____个
- 自动评测维度：____
- 人工评测维度：____
- 混合评测维度：____
- 各维度阈值：____
```

### S3：评测集构建方法

**目标**：设计评测集的构建和维护流程

**评测集构建流程**：

```
Step 1: 场景收集
  - 用户日志分析（正常场景）
  - 历史故障复盘（边界场景）
  - 威胁建模（对抗场景）

Step 2: 用例编写
  - 标准化格式（输入、期望输出、评分标准）
  - 多人评审
  - 分类标签

Step 3: 用例验证
  - 人工验证正确性
  - 自动化验证可执行性
  - 去重和冲突检测

Step 4: 持续维护
  - 定期更新（月度）
  - 新场景补充
  - 过时场景淘汰
```

**评测集规模参考**：

| Agent复杂度 | 正常场景 | 边界场景 | 对抗场景 | 总计 |
|------------|---------|---------|---------|------|
| 简单 | 20-30 | 10-15 | 5-10 | 35-55 |
| 中等 | 50-80 | 20-30 | 10-20 | 80-130 |
| 复杂 | 100-200 | 40-60 | 20-30 | 160-290 |

**输出模板**：
```
S3评测集方案：
- 构建方法：____
- 目标规模：____个
- 构建周期：____
- 维护机制：____
- 质量保障：____
```

### S4：评测运营体系

**目标**：建立评测的持续运营机制

**评测运营流程**：

| 活动 | 频率 | 负责人 | 输出 |
|------|------|--------|------|
| 常规评测 | 每次发布前 | 开发团队 | 评测报告 |
| 深度评测 | 每月一次 | 质量团队 | 质量分析报告 |
| 红队测试 | 每季度一次 | 安全团队 | 安全评估报告 |
| 评测集更新 | 每月一次 | 产品团队 | 更新日志 |
| 指标复盘 | 每两周一次 | 全团队 | 改进计划 |

**输出模板**：
```
S4运营方案：
- 评测频率：____
- 责任分工：____
- 报告机制：____
- 改进闭环：____
- 工具支撑：____
```

---

## 输出格式

```
# 评测矩阵设计方案

## 一、三层评测结构
- 正常场景：____个（____%）
- 边界场景：____个（____%）
- 对抗场景：____个（____%）

## 二、七维评测指标
- 各维度指标与阈值：____
- 评测方法：____

## 三、评测集构建
- 构建方法：____
- 目标规模：____
- 维护机制：____

## 四、评测运营
- 频率与分工：____
- 报告与改进：____

## 五、实施计划
- 第1周：____
- 第2-4周：____
- 持续运营：____

## 六、工具与资源
- 评测工具：____
- 人力资源：____
- 预算需求：____
```

---

## 治理神经检查

### 边界与升级检查
- [ ] 评测问题是否涉及业务逻辑（需升级到产品团队）？
- [ ] 安全评测是否需要专业红队支持？
- [ ] 评测资源是否与质量要求匹配？

---

## 质量自检

- [ ] 三层评测结构是否完整（正常+边界+对抗）？
- [ ] 七维指标是否都有明确的计算方式和阈值？
- [ ] 评测集规模是否与Agent复杂度匹配？
- [ ] 是否有评测集的持续维护机制？
- [ ] 评测频率是否与发布节奏匹配？
- [ ] 是否区分了"评测"和"测试"的概念？

---

## 典型误区

| 误区 | 正确理解 |
|------|---------|
| "评测就是跑一遍看看" | 评测需要结构化的指标和阈值 |
| "正常场景测好就行" | 缺少边界和对抗场景，质量画像不完整 |
| "评测集越大越好" | 质量>数量，覆盖度>绝对数量 |
| "评测是一次性工作" | 评测集需要持续更新和维护 |
| "自动评测能替代人工" | 关键维度需要人工评测，自动是补充 |

---

## 框架衔接

### 向上衔接
- **F20 TripleE工程方法**：Golden Task Set是评测集的核心组成
- **F22 执行链路诊断**：链路诊断指导评测的重点维度

### 向下衔接
- **F26 PRT质量门禁**：评测矩阵是PRT的数据基础

### 横向关联
- **F24 ADLC开发生命周期**：评测矩阵嵌入ADLC各阶段的质量门禁
- **F21 Skill资产治理**：Skill需要独立的评测矩阵