# 分层诊断 Evaluation 结果记录（2026-05-25）

这份文档记录分层诊断 skill 在 2026-05-25 的最新 regression 结果。格式参考 `2026-05-20-multi-agent-layered-evaluation-results.zh.md`，重点保留 10 个 core demo case 的总分、分阶段 bucket 分数和当前主要缺口。

## 运行环境

- 分支：`codex/multi-agent-rebuilt`，commit `9f2cd98`
- Suite：`core-daily-demo @ f5404283d392`
- Baseline reference：`baseline-evalrun-b92aea0782574c129e3a933d662adcdd`
- promoted baseline model：`chat/claude-standard`
- pod 运行环境：`investibook-multi-agent/backend-b7c59bcd4-lh9vj`
- pod Agent：`opencode`
- pod Model：`chat/investibook-regression/high`
- local Agent：`opencode`
- local Model：`chat/claude-standard/high`
- local 补跑说明：`component-restart` 和 `system-unavailability` 使用本地工作区补跑，其中包含尚未提交的 focused log context window 试验改动；pod 上 8 个 case 使用 multi-agent pod 内代码。
- 说明：自动 baseline comparison 仍被标记为 `resolved_model_mismatch`，因为 promoted baseline 使用 `chat/claude-standard`；下面的对比是基于 report_detail 中的 baseline bucket 做人工汇总。
- 说明：本次 10 case 汇总由 8 个 pod case + 2 个本地补跑 case 组成，因此可以用于定位分层诊断当前问题，但不能作为严格的同模型横向 benchmark。

## 本次 Evaluation Runs

| Run | 范围 | Model | 结果 | Report |
| --- | --- | --- | --- | --- |
| `evalrun-50ca4bf7efdd41b4b1fc13100cb63698` | 8 个非本地优化 case | `chat/investibook-regression/high` | 3 pass / 5 fail / 0 invalid，平均分 57.38 | `backend/data/eval_audits/evalrun-50ca4bf7efdd41b4b1fc13100cb63698/report_detail.txt` |
| `evalrun-948065d0468b41adadded97137d05142` | `component-restart-during-incident-window` | `chat/claude-standard/high` | 0 pass / 1 fail / 0 invalid，分数 30 | `backend/data/eval_audits/evalrun-948065d0468b41adadded97137d05142/report_detail.txt` |
| `evalrun-ad7c959992214f67b1e3fe910e26dae8` | `system-unavailability-during-incident-window` | `chat/claude-standard/high` | 0 pass / 1 fail / 0 invalid，分数 56 | `backend/data/eval_audits/evalrun-ad7c959992214f67b1e3fe910e26dae8/report_detail.txt` |

## 10 个 Case 的分数对比

Bucket 顺序为：`workflow / evidence collection / critical evidence / routing / diagnosis`。
满分为 `10 / 5 / 30 / 5 / 50`。

| Case | Baseline | 当前结果 | 变化 | Baseline buckets | 当前 buckets | 当前主要结论 |
| --- | ---: | ---: | ---: | --- | --- | --- |
| `component-restart-during-incident-window` | 28 fail | 30 fail | +2 | 10/5/0/5/8 | 10/5/10/5/0 | evidence 有进步，但仍缺 direct panic 和 query interruption；诊断错误落到缺索引/OOM，而不是 v8.5.2 known bug single-instance restart chain。 |
| `cpu-spike-during-incident-window` | 30 fail | 50 fail | +20 | 10/5/10/5/0 | 10/5/30/5/0 | critical evidence 已补满，但 diagnosis 没识别 capacity/node-count shift，仍停在错误根因。 |
| `expensive-query-alert-correlation-during-incident-window` | 70 pass | 70 pass | 0 | 10/5/30/5/17 | 10/5/30/5/6 | 保持 pass，evidence 满分；diagnosis 分数下降，说明有证据但主因表述不够稳定。 |
| `expensive-query-spike-during-incident-window` | 72 pass | 50 fail | -22 | 10/5/30/5/22 | 10/5/30/5/0 | evidence 满分，但 diagnosis 没识别 ineffective access path / large scan / missing index 作为 query bottleneck。 |
| `panic-in-recoverable-goroutine` | 70 pass | 30 fail | -40 | 10/5/30/5/17 | 10/5/10/5/0 | evidence 明显回退，缺 recoverable panic 直接日志和 query timeout interruption 信号；诊断转向内存压力，偏离 ground truth。 |
| `service-degradation-during-incident-window` | 75 pass | 70 pass | -5 | 10/5/30/5/25 | 10/5/30/5/17 | 仍然 pass，evidence 满分；但未充分识别 specific SQL path driving single-instance TiDB CPU hotspot。 |
| `sql-tail-latency-spike-during-incident-window` | 48 fail | 55 fail | +7 | 10/5/20/5/8 | 10/5/20/5/15 | 比 baseline 好，但 critical evidence 仍停在 20/30，缺 heap path 与 upstream known issue / fixed release 的关联。 |
| `sustained-cpu-pressure-during-incident-window` | 69 fail | 62 fail | -7 | 10/5/16/5/35 | 10/5/30/5/12 | critical evidence 已补满，但 diagnosis 没稳定识别 high-frequency delete path 作为 primary driver。 |
| `system-unavailability-during-incident-window` | 54 fail | 56 fail | +2 | 10/5/20/5/14 | 10/5/30/5/6 | critical evidence 已补满，但 diagnosis 没把 coprocessor worker capacity collapse 作为 primary path。 |
| `tail-latency-surge-during-incident-window` | 100 pass | 72 pass | -28 | 10/5/30/5/50 | 10/5/30/5/22 | 仍然 pass，evidence 满分；但 diagnosis 对 primary write path lock contention 的表达弱于 baseline。 |

## 汇总

| 指标 | Baseline | 当前结果 |
| --- | ---: | ---: |
| Pass / Fail / Invalid | 5 / 5 / 0 | 3 / 7 / 0 |
| 平均分 | 61.6 | 54.5 |
| workflow 平均分 | 10.0 / 10 | 10.0 / 10 |
| evidence collection 平均分 | 5.0 / 5 | 5.0 / 5 |
| critical evidence 平均分 | 21.6 / 30 | 25.0 / 30 |
| routing 平均分 | 5.0 / 5 | 5.0 / 5 |
| diagnosis 平均分 | 21.6 / 50 | 8.0 / 50 |

这轮最清楚的信号是：分层后的证据链路总体更稳，critical evidence 平均分从 21.6 提升到 25.0，且 `cpu-spike`、`sustained-cpu-pressure`、`system-unavailability` 的 critical evidence 已经补到 30/30。但是 diagnosis 明显退化，平均分从 21.6 降到 8.0，说明当前最大问题已经不是“是否能采到证据”，而是“采到证据后如何稳定进入正确专项诊断路径，并约束最终根因表述”。

## Evidence 结果

| Evidence 状态 | Case |
| --- | --- |
| 已达到 30/30 | `cpu-spike-during-incident-window`, `expensive-query-alert-correlation-during-incident-window`, `expensive-query-spike-during-incident-window`, `service-degradation-during-incident-window`, `sustained-cpu-pressure-during-incident-window`, `system-unavailability-during-incident-window`, `tail-latency-surge-during-incident-window` |
| 仍未达到 30/30 | `component-restart-during-incident-window`, `panic-in-recoverable-goroutine`, `sql-tail-latency-spike-during-incident-window` |

### 已确认改善

- `system-unavailability-during-incident-window`：critical evidence 从 baseline 20/30 提升到 30/30，说明 coprocessor worker、日志洪水、业务不可用相关证据已经被采到。
- `cpu-spike-during-incident-window`：critical evidence 从 10/30 提升到 30/30，说明容量变化/节点变化相关证据进入了输出。
- `sustained-cpu-pressure-during-incident-window`：critical evidence 从 16/30 提升到 30/30，说明 sustained pressure 的核心现象已被 evidence layer 覆盖。
- `component-restart-during-incident-window`：critical evidence 从 0/30 提升到 10/30，但仍没有拿到 direct panic / query interruption 关键词。

### 仍未解决的 Evidence 缺口

- `component-restart-during-incident-window`：缺 `panic_signal_present` 和 `query_interruption_signal_present`。本地已尝试给 focused log samples 增加小范围前后 guard window，但这次补跑仍没有匹配到 judge 需要的日志关键词。
- `panic-in-recoverable-goroutine`：缺 `panic_signal_present` 和 `query_timeout_interrupt_signal_present`。pod 输出中还提到 `logsEnabled=false`，agent 因此转向间接内存压力推断，导致 evidence 和 diagnosis 同时偏离。
- `sql-tail-latency-spike-during-incident-window`：缺 heap path 与 upstream issue / fixed release 的关联证据。这里不是基础 metrics 缺失，而是需要把 profiling/heap path 和 known issue 关联做成明确 evidence item。

## Diagnosis 结果

当前失败主要集中在 diagnosis gate，而不是 workflow、evidence collection 或 routing：

| Case | Diagnosis 问题 |
| --- | --- |
| `cpu-spike-during-incident-window` | 没识别 capacity / node-count shift 是 CPU increase primary driver。 |
| `expensive-query-spike-during-incident-window` | 没识别 ineffective access path / large scan / missing index 是 query bottleneck。 |
| `sustained-cpu-pressure-during-incident-window` | 采到 evidence 后没有把 high-frequency delete path 稳定收敛为 primary driver。 |
| `system-unavailability-during-incident-window` | 采到 coprocessor-worker 相关证据，但最终仍偏向 query-side explanation，没有输出 worker capacity collapse cascade。 |
| `tail-latency-surge-during-incident-window` | 保持 pass，但 lock contention on primary write path 的专项表达不够强。 |

这说明分层后的下一步不应该继续在 evidence collector 里堆更多通用字段，而应该补强两层：

1. Signal Tagging：把容量变化、worker collapse、known panic、large scan、heap known issue、lock contention 等异常先打成结构化标签。
2. Specialized Diagnosis：根据标签组合进入专项 skill，由专项 skill 负责限定根因候选、必要证据、反证条件和最终输出模板。

## 和 2026-05-20 结果相比

| 指标 | 2026-05-20 | 2026-05-25 |
| --- | ---: | ---: |
| Pass / Fail / Invalid | 5 / 4 / 1 | 3 / 7 / 0 |
| 平均分 | 54.2 | 54.5 |
| Invalid | 1 | 0 |
| critical evidence 30/30 case 数 | 5 | 7 |

相比 2026-05-20，这轮最重要的进步是 invalid 消失，并且 critical evidence 满分 case 从 5 个增加到 7 个；但 pass 数下降到 3 个，说明 diagnosis 阶段的稳定性变成主要瓶颈。

## 结论

这轮结果支持我们之前的判断：分层架构已经让证据采集更可治理，但还没有真正解决“证据之后如何稳定诊断”的问题。现在最值得投入的方向是把 manual issue 中的失败模式沉淀成 signal tags 和 specialist diagnosis skill，而不是继续往主 skill 或 collector 里加零散规则。

短期建议：

1. 优先修复 `component-restart`、`panic`、`sql-tail-latency` 三个仍非 30/30 的 evidence case。
2. 对 `cpu-spike`、`sustained-cpu-pressure`、`system-unavailability` 这三个 evidence 已满但 diagnosis 低分的 case，新增专项诊断 skill 或更强的 diagnosis guard。
3. Evaluation 侧增加分层评分项：signal tag 是否正确、fault classification 是否正确、specialist skill 是否被读取、最终根因是否遵守该 specialist 的反证条件。