SuperBizAgent-java/interview/issues-interview-stories.md

# 从 Issues 提炼的面试故事

**更新日期**：2026-07-24  
**用途**：从 `mvp/issues` 已解决问题中，筛出可讲、值得讲、能举一反三的案例  
**配套**：[architecture-evolution-deep-dive.md](architecture-evolution-deep-dive.md)（讲演进骨架）；本文讲**具体踩坑与决策**

---

## 0. 怎么用

| 场景 | 用法 |
|---|---|
| 行为面试 / 项目深挖 | 选 2–3 个 ★★★ 故事，用 STAR 讲 |
| 架构追问 | 把故事挂回演进阶段（Phase2 证据 / Phase3 重构 / 工程化） |
| 避免踩坑 | ★ 仅作补充，勿当主叙事；过时方案要说「后来被什么吸收」 |

**总原则**

> 面试官要的不是 Issue 编号，而是：**现象 → 根因分层 → 你选了什么杠杆 → 如何验证 → 后来边界怎么演进**。

---

## 1. 全景评分（先看这张表）

| Issue / 主题 | 面试价值 | 最适合回答的问题类型 | 一句话钩子 | 注意 |
|---|:---:|---|---|---|
| **证据归因幻觉** + Gatekeeper 链路 | ★★★ | 防幻觉 / 质量门禁 | 「工具调了，结论仍是编的」 | 旧角色名要映射到现在 Guard |
| **ISS-014** 单 Agent + Harness | ★★★ | 架构重构 / 为什么简化 | 「不是砍验证，是换装载层」 | 主故事，深读文档已覆盖 |
| **ISS-008** 窄范围越界 | ★★★ | Agent 约束 / Prompt 不够 | 「只问 CPU，却去查全家桶」 | 好举一反三 |
| **ISS-009** 负向证据 | ★★★ | 证据建模 / no-hit | 「没查到也是证据」 | 区分「无问题」vs「无数据」 |
| **ISS-001→002→004→015** 重复检索族 | ★★★ | 迭代加深 / Prompt vs 硬约束 | 「去重了仍狂调 20 次」 | 讲演进链，别只讲一次补丁 |
| **ISS-010** session/run 隔离 | ★★★ | 可观测 / 多轮正确性 | 「同会话多轮 Trace 串台」 | 和 runId 真理源强绑定 |
| **ISS-012** Token/上下文膨胀 | ★★★ | 成本 / ACI / 上下文工程 | 「工具返回把上下文撑爆」 | 接到 projection 三层数据 |
| **ISS-006 + fixtures + baseline diff** | ★★ | 工程化 / 回归 | 「改 Prompt 怎么知道没退步」 | 体现测试思维 |
| **ISS-007** 摘要失真 → 自证循环 | ★★★ | 信息通路设计 | 「证据在，摘要丢了关键句」 | 可与归因幻觉合并讲 |
| **ISS-013** SSE / 入口解耦 | ★★ | 后端工程 / 协议边界 | 「假流式 + Controller 过重」 | 偏工程，Agent 味稍淡 |
| **ISS-005** 证据状态契约 | ★★ | 契约 / 失败语义 | 「failed/no_evidence/deduped 语义乱」 | 作 001/007 的基础设施铺垫 |
| **RAG 子问题集** | ★★ | RAG 专题 | L0 降级、显式 Tool、breadcrumb | 合成一条 RAG 故事，勿逐条念 |
| **ISS-003** 总 Review | ★ | 过程 | 问题发现清单 | 不宜单独讲 |
| **ISS-015**（进行中） | ★★ | 诚实收尾 / 判断力 | 「架构冻了，策略还在收」 | 讲未完成，勿假装已完美 |

---

## 2. 推荐主故事包（面试只带这 5 个就够）

### 故事包怎么组合（15 分钟项目介绍）

```text
1) 开场架构（2 min）     → 深读文档 / ISS-014 结论
2) 质量核心（4 min）     → 证据归因幻觉 + Gatekeeper/EvidenceGuard
3) 约束演进（3 min）     → 重复检索 001→002→硬预算 / 窄范围 008
4) 工程底座（3 min）     → run 隔离 010 + eval harness 006
5) 重构与未完（3 min）   → ISS-014 为什么合并 + ISS-015 诚实项
```

---

## 3. ★★★ 故事详解（可直接练口述）

### 3.1 证据归因幻觉（最高辨识度）

| 项 | 内容 |
|---|---|
| 来源 | `executor-evidence-attribution-hallucination` + ISS-007 + design-note 自证循环 |
| 完整深读 | [topic-evidence-attribution-and-gates.md](topic-evidence-attribution-and-gates.md) |
| 阶段 | Phase 2 正确性建设 |
| 现象 | 多次 E2E：工具已调 `lookup_knowledge/logs/metrics`，Verifier 仍大面积 `LOW_CONFID`；答案里出现 OOM、Full GC 次数等**工具返回里没有的「精确事实」** |
| 错误归因（你要主动否定） | 「是不是 Verifier 太严 / 只认 RAG？」——查 `evidence_refs` 后发现并非如此 |
| 真根因 | **Executor 证据归因幻觉**：把 runbook/历史模式/模型常识写进「当前已证实事实」，未区分 direct / reference / hypothesis / missing |
| 解法演进 | ① 结构化 claim + binding（invocation/path/excerpt）② **代码 Gatekeeper** 验引用 ③ Verifier 只判可推导 ④ Composer 控表达 → 后来迁到 EvidenceGuard + SemanticGuard + Release |
| 验证 | 固定 session 表（groundedness、no_evidence 计数）；eval fixture；Trace 可指出「哪条 claim 无 binding」 |
| 现行映射 | Gatekeeper → **EvidenceGuard**；Verifier → **SemanticGuard**；最终出门 → **Release** |

**STAR 口述（约 90 秒）**

> 我们诊断链路经常 LOW_CONFID。第一反应像是验证器太狠，但拉 Trace 发现工具其实调用成功了。  
> 对比答案和 tool raw 后定位到：模型会把知识库里的「常见故障模式」写成「这次故障已观测事实」。  
> 所以我们把「有没有这句证据」从 LLM 判断里拆出来，做成代码级引用校验；模型只负责在已验真片段上做推导。  
> 这直接把问题从「提示词求稳」升级成「证据所有权与类型系统」。  
> 后来重构单 Agent 时，这层语义保留了，只是从流水线角色变成了 Harness 门禁。

**追问预备**

- Q: 为什么不靠更强模型？  
  A: 分布上仍会混用常识与观测；确定性校验可回归、可解释。  
- Q: excerpt 子串匹配会不会太死？  
  A: 对防伪造必须偏严；表达层再允许归纳，但不允许无根引用。  
- Q: 和 RAG 引用角标有何不同？  
  A: 角标常是生成时装饰；我们校验的是**当次 Run 的 tool_call 所有权**。

**举一反三**

- 客服：「政策规定 7 天」≠「本单已同意退款」  
- 代码 Agent：「README 说应有测试」≠「本 PR 已有测试」

---

### 3.2 窄范围查询越界（ISS-008）

| 项 | 内容 |
|---|---|
| 现象 | 用户只要确认 `payment-service` 是否有 HighCPU 告警；Agent 却扩展到内存、日志、根因故事 |
| 根因 | ReAct 默认「有工具就多查」；Prompt 未区分 **observation 任务** vs **root-cause 任务**；claim 类型未收窄 |
| 解法 | 窄范围只允许 `observation` / `negative_observation`；禁止随手 root_cause；工具选择与输出 schema 双约束 |
| 验证 | narrow-highcpu 类 fixture：该 PASS 的 observation 不因「没讲根因」被打成失败 |
| 现行 | DiagnosisDraft 分析项仍强调证据绑定；范围控制在 Agent 指令 + Guard 语义审查 |

**金句**

> Agent 的能力上限往往不是「会不会查」，而是「知不知道何时停、查什么算完成」。

**举一反三**

- SQL Agent：用户要 `SELECT count` 时禁止顺手 `UPDATE`  
- 调查 Agent：「只要时间线」时禁止输出处置工单

---

### 3.3 负向证据（ISS-009）

| 项 | 内容 |
|---|---|
| 现象 | 工具明确 no-hit 时，模型要么不说，要么说成「已排除该根因」，且引用对不上 |
| 根因 | 只建模「命中证据」，没有一等公民的 **no_evidence 路径**（如 `$.no_evidence`） |
| 解法 | `negative_observation` + 固定 raw_path/excerpt 契约；Gatekeeper 校验「无证据」也可以是合法引用 |
| 价值 | 排障里「查过没有」改变后验；也避免虚假排除 |

**金句**

> 在证据系统里，空结果若不可引用，模型就会用语言填补真空——那就是幻觉温床。

---

### 3.4 重复检索演进链（ISS-001 → 002 → 004 → 015）

这是**最好的「迭代加深」故事**：同主题三次升级约束强度。

```text
ISS-001  同文档内容重复进上下文
         → session 文档去重 / Prompt「别重复」

ISS-002  去重后仍 lookup 20+ 次（换 query 刷同一域）
         → 根因：约束只打在 Planner，Executor 不知情
         → Executor 注入 map + 每域一次等 Prompt 约束

ISS-004  Prompt 仍挡不住「再确认一次」
         → 设计域级水位 / 硬限制（后被架构变更吸收）

ISS-014/015  约束归属变化
         → 不再靠 Executor 旁路状态打补丁
         → Harness 预算 + Agent 硬停止 + 重复 lookup 策略（015 进行中）
```

**面试怎么讲这条链**

> 第一阶段我们以为是重复文档，做了内容去重。  
> 第二阶段发现模型换关键词继续刷，说明**去重粒度错了**，且约束注入点错了（只告诉了 Planner）。  
> 第三阶段承认 Prompt 约定不是安全边界，必须**预算/次数硬停止**。  
> 架构重构后，这些不再散落在 Tool 旁路，而进入统一 Harness 控制面。  
> 这说明我处理 Agent 问题的习惯是：先观测 → 分层根因 → 逐步把约束从「软」推到「硬」，并在架构变了以后迁移装载点，而不是叠补丁。

**对应业界概念**：Action masking / tool budget / circuit breaker；不是调参玄学。

---

### 3.5 Session / Run Trace 隔离（ISS-010）

| 项 | 内容 |
|---|---|
| 现象 | 同 `sessionId` 多轮诊断时，步骤/工具/评价串台或「取最新一条」导致回放错乱 |
| 根因 | 缺少把**一次执行**定为真理源的 `runId`；查询与写入未全程 exact id |
| 解法 | `diagnosis_run`；step/invocation/trace 均挂 run；API 强制 `runId`；禁止 latest 语义 |
| 价值 | 评测、排障、面试 Demo 都依赖可复现回放 |

**金句**

> 可观测性若不能精确到一次 Run，就只是日志堆，不是诊断系统的记忆。

**举一反三**

- 工作流引擎的 `workflowId` vs `runId`  
- CI 的 pipeline vs job attempt

---

### 3.6 Token 与上下文膨胀（ISS-012）→ ACI / 三层数据

| 项 | 内容 |
|---|---|
| 现象 | Executor 上下文暴涨；工具结果含 debug/rerank/大段重复；成本与截断不可控 |
| 根因 | Tool 返回**面向开发者**而非 Agent；完整 raw 与模型可见视图未分离 |
| 解法方向 | Token 可观测；硬预算；结果投影；证据引用带稳定 id（后由 ISS-014 的 Redis canonical + projector 落地） |
| 现行 | canonical / projection / durable audit 三层 |

**金句**

> 上下文工程首先是接口设计问题：Agent 的观察通道必须有界，验真通道才能完整。

---

### 3.7 单 Agent + Harness 重构（ISS-014）

深读文档已写透，这里只留**Issue 视角的故事钩子**：

| 项 | 内容 |
|---|---|
| 触发 | 多角色 = 外层重复 ReAct；JSON 接力；Token；失败语义组合爆炸 |
| 保留 | 物理验真 → 语义审查 → 发布 的正确性模型 |
| 迁移 | 角色流水线 → 执行边界（Harness） |
| 证据 | 阶段 E2E：成功诊断 ~8k tokens / 1 次 tool；Knowledge Query 独立路径修复 invalid schema |

**和 3.1 的关系（必说清）**

> 014 不是推翻 007/归因幻觉的成果，而是避免用「五个 LLM 角色」去实现本该由一个 ReAct + 一层确定性门禁完成的事。

---

### 3.8 评测 Harness（ISS-006 + fixtures + baseline diff）

| 项 | 内容 |
|---|---|
| 动机 | 只有 Demo 无法判断改 Prompt/Tool 是否退步 |
| 做法 | 固定 case；expected tools/verdict/keywords；**确定性** trace 校验（非一上来 LLM-as-judge）；baseline + diff |
| 价值 | 把 Agent 质量从「感觉」变成「回归」 |

**金句**

> 没有 baseline diff 的 Agent 迭代，只是在用生产用户当测试集。

**注意**：面试强调「先确定性检查，再考虑 LLM judge」，显得克制。

---

### 3.9 SSE 与入口解耦（ISS-013）

| 项 | 内容 |
|---|---|
| 现象 | `/api/chat` 与 `/api/chat_stream` 双入口；stream 实为整答后假分片；Controller 编排过重 |
| 解法 | 唯一 `POST /api/chat` named SSE；UseCase 拥有业务；Controller 只协议；disconnect → cancel Run |
| 适合 | 问到 Spring/API 设计、背压、职责边界时 |

---

## 4. ★★ 可合并讲的「专题束」

### 4.1 RAG 专题束（不要逐 Issue 报菜名）

把 `mvp/issues/rag/*` 收成 **一条 2 分钟故事**：

```text
问题簇：
  L0 关键词当终局、breadcrumb 不进向量、切片丢层级、
  无 packing/rerank、分数语义不清、Advisor 隐式注入 vs 显式 Tool

收敛原则：
  1) 检索决策要对 Agent 可见 → lookup_knowledge 保持 Tool
  2) L0 降级为 hint，不替代语义召回
  3) 向量主路径可演进（VectorStore）+ 过渡期 fallback
  4) 召回质量与「能否被引用验真」一起设计
```

**面试官若只问 RAG**：用这条；若问 Agent 质量：退回 3.1。

### 4.2 证据契约束（ISS-005 + 007 + 结构化输出设计笔记）

```text
统一 evidence 状态：supported / no_evidence / deduped / failed
摘要不可当唯一证据源
Executor 产出可绑定结构，Gatekeeper 验，Verifier 判
```

适合接在「你们怎么保证工具结果语义一致」类问题。

---

## 5. 不建议当主故事的

| 项 | 原因 | 若被问到怎么说 |
|---|---|---|
| ISS-003 总 Review | 清单型，缺单点冲突 | 「那是问题发现基线，具体落地看 005/006/014」 |
| ISS-004 原文方案细节 | 实现被 014/015 吸收，细节易过时 | 「方向是硬水位，装载点已迁到 Harness 预算/停止策略」 |
| 归因幻觉的旧 Prompt 补丁 alone | 不完整 | 必须接到 Gatekeeper/Guard |
| 未归档的「计划中」口吻 | 很多已 done | 统一用「已归档 / 被 014 吸收 / 015 进行中」三态 |

---

## 6. 问题类型 → Issue 速查

| 面试官问… | 优先故事 |
|---|---|
| 怎么防幻觉？ | 3.1 归因幻觉 + Guard 映射 |
| Prompt 够不够？ | 3.4 重复检索链 + 3.2 窄范围 |
| 多 Agent 为什么又合并？ | 3.7 ISS-014（挂 3.1 证明没砍质量） |
| 成本 / Token？ | 3.6 + 数据三层 |
| 如何回归？ | 3.8 eval |
| 如何调试一次错误诊断？ | 3.5 run 隔离 + Timeline |
| 没找到证据怎么办？ | 3.3 负向证据 + Release fallback |
| SSE / 接口设计？ | 3.9 |
| RAG 怎么做的？ | 4.1 专题束 |
| 还有什么没做完？ | ISS-015：硬停止、Repair schema、reasoning 治理、信息化 fallback |

---

## 7. 与架构演进的挂载图

```text
Phase1 能跑
  └─ 暴露：重复检索 001/002

Phase2 能验
  ├─ 证据状态 005
  ├─ 归因幻觉 + 007 自证循环
  ├─ 窄范围 008 / 负向证据 009
  ├─ eval 006 / baseline
  └─ run 隔离 010

Phase2 负债
  └─ Token 012、入口 013、角色编排税

Phase3 能控
  └─ 014 单 Agent + Harness（吸收 004/012/013 与证据门禁语义）

Phase4 治理中
  └─ 015 停止策略 / Repair / reasoning / fallback 信息量
```

---

## 8. 建议你精炼的「个人贡献表述」模板

按真实参与度改主语，结构建议：

```text
我负责/主导了 ___（问题）。
通过 Trace 看到 ___（证据），排除了 ___（错误假设）。
方案上选择 ___ 而不是 ___，因为 ___。
用 ___（fixture/E2E/指标）验证。
后续在 014 重构中，该能力迁移为 ___，我学到 ___。
```

示例（归因幻觉）：

```text
我负责排查 Chat 诊断大面积 LOW_CONFID。
通过对比 tool raw 与最终答案，确认是证据归因幻觉而非 Verifier 误杀。
推动「结构化 claim + 代码 Gatekeeper + Verifier 只做推导」而不是继续堆 Prompt。
用固定 E2E session 与 eval fixture 回归。
014 重构后该语义保留为 EvidenceGuard/SemanticGuard/Release。
```

---

## 9. 源文件索引

| 故事 | 路径 |
|---|---|
| 归因幻觉 | `mvp/issues/archived/executor-evidence-attribution-hallucination.md` |
| 自证/摘要 | `mvp/issues/archived/ISS-007-...` / `design-notes/executor-self-evidence-loop-design-note.md` |
| 窄范围 | `mvp/issues/archived/ISS-008-...` |
| 负向证据 | `mvp/issues/archived/ISS-009-...` |
| 重复检索 | `ISS-001` `ISS-002` `ISS-004` |
| Run 隔离 | `ISS-010` |
| Token | `ISS-012` |
| SSE | `ISS-013` |
| 重构 | `ISS-014-single-react-agent-harness-aci-ptk-refactor.md` |
| 评测 | `ISS-006` `expand-diagnosis-eval-fixtures` `diagnosis-eval-baseline-diff` |
| 进行中 | `mvp/issues/active/ISS-015-...` |
| RAG 簇 | `mvp/issues/rag/*` |

---

## 10. 自测

1. 不看文档，讲清「工具调用成功为何仍 LOW_CONFID」的根因与门禁分层。  
2. 用 001→002→004→015 说明你如何升级约束强度。  
3. 画旧 Gatekeeper 到新 EvidenceGuard 的映射，并说明 014 保留了什么。  
4. 举一个负向证据防止的错误用户话术。  
5. 用一句话说明 eval harness 为什么先做确定性检查。  

能答 1–3，项目深挖通常已够用；4–5 用于区分「做过功能」和「有质量体系」。