# Executor 证据归因幻觉

**状态**：待规划
**严重程度**：高
**发现时间**：2026-07-07
**来源**：Trace Workbench 复核 / 最近 Chat 诊断会话低置信分析
**关联**：ISS-005（证据链补齐与降级契约收敛）、ISS-006（固定诊断评测集与回归 Harness）、`chat-verifier-agent`、`diagnosis-playbook-skills`

---

## 背景

最近连续多条 Chat 诊断会话都被 Verifier 判定为 `LOW_CONFID`。这些会话并不是没有调用工具；相反，它们大多完成了 `lookup_knowledge`、`query_metrics`、`query_logs` 等证据工具调用。

问题出在 Executor 的最终答案：它拿到部分真实工具返回后，将以下三类内容混在一起输出为“本次事故结论”：

1. 本次工具直接返回的事实。
2. runbook、知识库或历史案例里的通用模式。
3. 模型基于经验补全的推断。

Verifier 随后逐条核查 `executor_final_answer`，发现大量关键事实没有对应工具证据，于是按规则输出 `LOW_CONFID`。

---

## 现象

最近 5 条 Chat 诊断会话均为低置信：

| session | verdict | groundedness_score | direct_evidence | indirect_support | no_evidence |
|---|---:|---:|---:|---:|---:|
| `e2e-mysql-skill-rag-20260706-2355` | LOW_CONFID | 0.50 | 2 | 14 | 5 |
| `e2e-mysql-skill-rag-20260706-2312` | LOW_CONFID | 0.37 | 4 | 11 | 14 |
| `e2e-mysql-skill-rag-20260706-2255` | LOW_CONFID | 0.10 | 1 | 2 | 18 |
| `e2e-mysql-skill-rag-20260706-2242` | LOW_CONFID | 0.53 | 3 | 9 | 4 |
| `e2e-mysql-skill-rag-20260706-2230` | LOW_CONFID | 0.20 | 1 | 2 | 11 |

典型无证据断言：

- `order-service 出现 OutOfMemoryError: Java heap space`
- `OrderService.processLargeOrder() 内存泄漏导致 JVM OOM`
- `频繁 Full GC（10 分钟 15 次，平均 850ms）`
- `users + user_profiles 慢查询 2.8s，全表扫描`
- `UPDATE orders 锁等待 2.1s`
- `user-service DB 查询超时 5.2s~5.8s`

这些事实要么没有出现在工具返回中，要么属于其它服务或历史案例，不能作为当前会话的直接事实。

---

## 根因判断

这是一个经典的 Agent 幻觉问题，但更准确地说是：

**Executor 的证据归因幻觉。**

Executor 已经调用了工具，但在综合答案阶段没有严格区分：

- `direct evidence`：工具本次实际返回的事实
- `reference / runbook`：流程指导、历史模式、建议方向
- `hypothesis`：基于已知证据的推测
- `missing evidence`：还没有被工具证实的内容

因此它会把“可能相关的历史模式”写成“当前事故事实”，并把“建议排查方向”写成“已确认根因”。

---

## 影响

- Verifier 正确拦截后，最近 Chat 会话长期停留在 `LOW_CONFID`。
- 用户侧结果虽然带免责声明，但仍难以直观看出哪些内容是真实证据、哪些只是推测。
- 评测里 verdict 分布会被 Executor 输出质量拖低，掩盖工具链本身是否已经足够。
- 面试讲解时容易被追问：既然工具都调用了，为什么答案仍然不可信？

---

## 本 issue 目标

收紧 Executor 的最终输出契约，避免把未证实内容写成确认结论。

完成后应做到：

1. Executor 最终答案明确分区：
   - `已证实事实`
   - `合理推测`
   - `证据缺口`
   - `建议动作`
2. `已证实事实` 只能来自本轮 evidence tools 的返回。
3. runbook / skill / 知识库中的流程和历史案例不得直接作为本次事故事实。
4. 其它服务的证据不得迁移为当前服务事实。
5. 根因结论必须绑定至少一条直接或间接证据；否则只能放入 `合理推测` 或 `证据缺口`。
6. Verifier 的 `LOW_CONFID` 缺口应能直接映射回 Executor 的分区错误。

---

## 范围

### In scope

- 修改 `chat-executor-prompt.md`，加入证据分区和证据归因规则。
- 必要时在 `ChatService.buildChatExecutorAgent(...)` 中注入更明确的最终答案格式约束。
- 增加 focused tests，覆盖 Executor prompt 中的证据边界规则。
- 增加或更新诊断 eval fixture，验证 unsupported claims 不会出现在确认结论中。
- Trace Workbench 可继续消费 Verifier 缺口展示低置信原因。

### Out of scope

- 不放宽 Verifier 的 PASS 判定矩阵。
- 不通过调高 `verifier.low-confidence-threshold` 掩盖问题。
- 不把 runbook 或 skill 内容写入 `tool_invocation` 伪装成事实证据。
- 不新增数据库 schema。

---

## 验收标准

- 对 MySQL 连接池耗尽类 case，Executor 输出中：
  - 已证实事实只包含工具返回的服务、指标、日志、慢 SQL 等事实。
  - OOM、Full GC、连接泄漏等未证实内容只能出现在推测或证据缺口中。
  - 不再把 `order-service` / `user-service` 事实混入 `payment-service` 当前事故。
- Verifier 对同类会话的 `no_evidence` 数量明显下降。
- 若证据不足，最终用户输出明确说明“当前无法确认根因”，而不是补全一个完整事故故事。
- 评测报告能捕捉 unsupported confirmed claims 的回归。

---

## 相关文件

- `src/main/resources/prompts/chat-executor-prompt.md`
- `src/main/resources/prompts/chat-verifier-prompt.md`
- `src/main/java/com/superbiz/agent/service/ChatService.java`
- `src/main/java/com/superbiz/agent/service/ToolTraceSummaryService.java`
- `src/test/java/com/superbiz/agent/service/ChatServiceSequentialAgentTest.java`
- `mvp/eval/`