2.9 KiB
2.9 KiB
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 的状态语义,让系统能稳定区分:
supportedno_evidencededupedfailed
下一步需要证明 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 运行时语义
预期面试表达
完成后可以这样描述:
我不仅有一个可演示的 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.mdmvp/demo/payment-timeout-acceptance.mdsrc/main/java/com/superbiz/agent/service/DiagnosisTraceService.javasrc/main/java/com/superbiz/agent/service/ToolTraceSummaryService.javasrc/main/java/com/superbiz/agent/domain/entity/DiagnosisSession.javasrc/main/java/com/superbiz/agent/domain/entity/ToolInvocation.javaopenspec/specs/evidence-trace-hardening/spec.md