Files

T

zhuyongxin de5a5b09d9 docs(interview): refresh materials for single-agent harness narrative

Archive pre-refactor interview notes and add current deep-dives on
architecture evolution, issue-derived stories, and evidence gates.

2026-07-24 18:14:49 +08:00

16 KiB

Raw Blame History

从 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，就只是日志堆，不是诊断系统的记忆。

举一反三

工作流引擎的 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 分钟故事：

问题簇：
  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 用于区分「做过功能」和「有质量体系」。

16 KiB Raw Blame History Unescape Escape

从 Issues 提炼的面试故事

0. 怎么用

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

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

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

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

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

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

3.3 负向证据（ISS-009）

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

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

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

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

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

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

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

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

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

5. 不建议当主故事的

6. 问题类型 → Issue 速查

7. 与架构演进的挂载图

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

9. 源文件索引

10. 自测

16 KiB

Raw Blame History