# ISS-006 固定诊断评测集与回归 Harness

**状态**：进行中（sm-flow）
**严重程度**：高
**发现时间**：2026-07-04
**来源**：P1-B 面试打磨项
**依赖**：ISS-005 / `evidence-trace-hardening`

---

## 背景

MVP 已经具备可追溯证据链、Verifier 质量门禁、trace API 和固定 demo 流程。上一阶段 `evidence-trace-hardening` 进一步统一了 evidence tool 的状态语义，让系统能稳定区分：

- `supported`
- `no_evidence`
- `deduped`
- `failed`

下一步需要证明 Agent 在一组固定诊断场景下的表现，而不是只依赖单次 demo。

---

## 问题

当前项目能演示一次支付超时诊断，但还缺少稳定的评测基线：

- 每次改 prompt、工具、Verifier 或检索逻辑后，无法快速判断是否退化。
- 只能人工看 trace，缺少结构化通过 / 失败结果。
- 缺少面试时能展示的指标，如 evidence coverage、verdict 分布、工具调用数量和耗时。

---

## 目标

建立一个轻量的固定 case 评测 harness，用于验证 MVP Agent 的诊断质量和证据链完整性。

第一版不做 LLM-as-judge，优先做规则化校验：

- 固定 5 个 MVP 诊断 case
- 每个 case 定义 expected root-cause keywords、required evidence tools、allowed verdicts
- 基于 trace 结果校验 evidence coverage、verifier evaluation、tool invocation、final answer shape
- 输出 JSON 和 Markdown 报告

---

## 范围

### In scope

- 评测 case 定义文件
- trace 规则校验器
- eval runner 或测试入口
- JSON / Markdown 报告输出
- demo 文档和 devflow 记录

### Out of scope

- 不引入 LLM-as-judge
- 不要求完整离线 LLM runtime
- 不新增生产 API
- 不修改 Chat 主链路
- 不修改 evidence trace 运行时语义

---

## 预期面试表达

完成后可以这样描述：

```text
我不仅有一个可演示的 Agent，还给它建立了固定 case 的回归评测。
每次修改 prompt、工具或 verifier 后，都可以跑同一批诊断 case，
检查证据覆盖、verdict 分布、工具调用成本和关键结论是否退化。
```

---

## 初始候选 case

| Case | 目标 |
| --- | --- |
| payment-timeout | 支付接口超时，验证知识库 + 日志 + 指标证据 |
| mysql-pool-exhausted | 数据库连接池耗尽，验证日志和知识库证据 |
| redis-timeout | Redis 连接超时，验证日志依赖证据 |
| slow-response | P99 响应时间过高，验证指标 + 慢请求日志 |
| jvm-memory-risk | JVM 内存 / OOM 风险，验证指标 + 系统事件日志 |

---

## 相关文件

- `mvp/demo/README.md`
- `mvp/demo/payment-timeout-acceptance.md`
- `src/main/java/com/superbiz/agent/service/DiagnosisTraceService.java`
- `src/main/java/com/superbiz/agent/service/ToolTraceSummaryService.java`
- `src/main/java/com/superbiz/agent/domain/entity/DiagnosisSession.java`
- `src/main/java/com/superbiz/agent/domain/entity/ToolInvocation.java`
- `openspec/specs/evidence-trace-hardening/spec.md`