Files
SuperBizAgent-java/mvp/issues/archived/ISS-006-diagnosis-eval-harness.md
T

2.9 KiB
Raw Blame History

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 运行时语义

预期面试表达

完成后可以这样描述:

我不仅有一个可演示的 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