在同一 DeepSeek deepseek-flash 模型、相同冻结观测和相同硬预算下，对 12 个公开案例运行两套取证策略，共 24 次实际调查。顺序按案例交替，所有调用均有供应商返回的用量记录。
| 指标 | 逐页取证 | 速览与定向查证 |
|---|---|---|
| 完成报告 | 12 / 12 | 12 / 12 |
| 首选故障服务命中 | 12 / 12 | 12 / 12 |
| 耗时中位数 | 23.52 秒 | 15.59 秒 |
| 总 Token | 1,083,460 | 501,653 |
| 模型调用次数 | 108 | 60 |
调查耗时降低 33.7%，总 Token 降低 53.7%，模型调用减少 44.4%。
优化包括证据速览、指标变化排序、日志去重、定向搜索、适用技能，以及取证轮数由 8 轮调整为 4 轮。两种策略均另留一轮提交报告。因此收益属于整套取证策略，不能单独归因于日志压缩或某个框架。
原始记录：
样本来自 RCAEval，包含 7 个故障组合，属于已使用数据的回归验证。耗时只含调查阶段，不含数据下载；少量工作台验证与批次短暂同时运行，供应商与本机负载会影响耗时。首选服务命中不代表每项原因描述均已人工核实，证据范围校验也不等同于语义正确性。
这里没有企业生产流量、人工计时对照或生产故障恢复时长。结果不外推为企业人力节省或生产准确率。历史早期策略没有取得相同收益；本页展示的是冻结的最终配对回归，源码和样本说明保留供复核。
| 检查 | 结果 | 记录 |
|---|---|---|
| 真实进程中断 | 20 次均恢复原任务，未重复创建工单，证据数量保持一致 | 逐次记录 |
| 审批与执行边界 | 6 组检查通过，覆盖拒绝、过期、参数修订、版本变化及恢复验证 | 检查记录 |
| 自建服务故障恢复 | 5 类故障各 3 次，共 15 次 | 演练记录 |
| 访问范围 | 5 项拒绝检查与 2 项正对照通过 | 检查记录 |
中断测试使用真实进程、Redis 与 PostgreSQL，诊断内容为明确标注的 fixture。故障演练使用实际自建服务。这些是工程验证，不是模型自动修复生产故障的成绩。
先按 运行指南 启动服务，再下载回放数据：
make data配置自己的真实模型后运行以下命令；这一步会产生供应商调用费用：
source scripts/env.sh
uv run --project services/agent-service python eval/runner.py \
--cases 12 --split test --variants legacy,compact \
--max-model-requests 280 --max-total-tokens 3500000 --max-cost-usd 1.5费用限制需要配置可靠的输入、输出单价；没有价格时只执行请求数、Token 与期限限制。结果保存在新的 eval/results/<批次ID>/，不会覆盖本页公开的冻结记录。模型响应具有波动，复跑结果不保证与表格完全相同。