zhuyongxin
de5a5b09d9
Archive pre-refactor interview notes and add current deep-dives on architecture evolution, issue-derived stories, and evidence gates.
16 KiB
16 KiB
从 Issues 提炼的面试故事
更新日期：2026-07-24
用途：从 mvp/issues 已解决问题中，筛出可讲、值得讲、能举一反三的案例
配套：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 分钟项目介绍）
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 |
| 阶段 | 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）
这是最好的「迭代加深」故事：同主题三次升级约束强度。
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，就只是日志堆，不是诊断系统的记忆。
举一反三
- 工作流引擎的
workflowIdvsrunId - 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 分钟故事：
问题簇：
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 + 结构化输出设计笔记）
统一 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. 与架构演进的挂载图
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. 建议你精炼的「个人贡献表述」模板
按真实参与度改主语，结构建议：
我负责/主导了 ___（问题）。
通过 Trace 看到 ___（证据），排除了 ___（错误假设）。
方案上选择 ___ 而不是 ___，因为 ___。
用 ___（fixture/E2E/指标）验证。
后续在 014 重构中，该能力迁移为 ___，我学到 ___。
示例（归因幻觉）：
我负责排查 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. 自测
- 不看文档，讲清「工具调用成功为何仍 LOW_CONFID」的根因与门禁分层。
- 用 001→002→004→015 说明你如何升级约束强度。
- 画旧 Gatekeeper 到新 EvidenceGuard 的映射，并说明 014 保留了什么。
- 举一个负向证据防止的错误用户话术。
- 用一句话说明 eval harness 为什么先做确定性检查。
能答 1–3，项目深挖通常已够用；4–5 用于区分「做过功能」和「有质量体系」。