迅雷 Agent 一面：RAG、MCP 与 Java 并发八股

《面试题目》

1. 项目深挖：意图识别你们怎么知道意图分得就是对的？指标有量化吗？如果用户两次提问问法相似、但实际意图不同，你们怎么判断出来？
2. 记忆混乱怎么优化的？如果记忆里能捞到之前有类似对话，你的 Agent 怎么让他知道应该按照之前的方案做，还是应该用一个新的方案？
3. RAG 你怎么看？现在很多说法说 RAG 不能用了，从多个方面分析一下，以及 LLM Wiki。
4. 你觉得 reranker 对召回之后的优化到底能达到什么地步？底层原理是什么（从 transformer 的角度说一下）？重召回是以 topK 还是 topP 返回的？
5. chunk 方式：如果分片，片与片之间怎么联系？索引存在 DB 里吗？
6. Skill 的原理说一下。
7. 如果让你写一个 MCP，应该怎么做？接入方式有哪些，比如 stdio？
8. 如果你们多人开发想要有一个开发规范，应该怎么做？现在 AI Native 开发，想让大家遵守怎么办？如果用 CLAUDE.md，大家用的 Coding Agent 不一样，又怎么办？
9. 八股：concurrent 包的内容，线程池有几种创建方式（Executor）？
10. Spring Bean 的生命周期。

《参考解析》

RAG「能不能用」这个问题该怎么正面回答：结论先给——死掉的是「把文档切碎丢进向量库、top-k 拼进 prompt」这种朴素 RAG，不是检索增强本身。要分场景说：知识更新频繁、答案必须带出处、私有数据不能进训练的场景，检索仍然是最便宜可控的方案；真正被替代的是那些「一次检索就够」的低难度问答，因为长上下文模型直接把整篇文档塞进去效果更好。工程上的演进方向是把 RAG 做成 Agent 的一个工具：查询改写与多路召回（向量 + 关键词 + 结构化查询）、按需多轮检索（先看目录再取章节）、用 reranker 重排、把结果做引用标注，再加上评测集（召回率、答案忠实度分开测）。「LLM Wiki」这类结构化知识库可以理解为把非结构化文档预编译成带链接的条目，让检索粒度从「块」变成「条目」，好处是可维护可追溯，代价是构建与同步成本，适合稳定的领域知识，不适合每天变的业务数据。

reranker 的原理与它的能力边界：初筛用的是双塔（bi-encoder）：query 和 document 各自独立编码成向量，只靠向量相似度比较，文档向量可以离线算好，所以能扫百万级，但两边从未交互，细粒度的语义差异分辨不出来。reranker 是交叉编码器（cross-encoder）：把 query 和 doc 拼成一条序列一起送进 transformer，靠 self-attention 做 token 级交互，最后输出一个相关度分数，精度明显更高；代价是每个候选都要跑一次前向，复杂度随候选数线性增长，所以只能对召回后的几十到一两百条做重排。因此它提升的是「候选集合内部的排序质量」（TopN 命中率、nDCG），救不回召回阶段就漏掉的文档——面试官追问底层原理时，把这一点讲清楚比背公式更加分。至于 topK / topP：重排之后一般是按分数取固定条数（topK）进上下文，必要时加一个分数阈值截断低分文档；topP（核采样）是生成阶段的解码参数，控制的是下一个 token 的候选集合，和召回返回完全不是一回事，两者混答会直接暴露理解深度。K 的取值要结合上下文预算做实验，塞太多低分块反而会引入噪声、稀释关键信息。

chunk 怎么切、片与片之间怎么建立联系：切分粒度先看内容形态——纯文本用固定长度加重叠（overlap 一般 10%~20%），文档类按标题层级和段落切，代码按函数/类切，表格和图片单独处理。片间联系有四种常用做法：① 重叠窗口，保证跨边界的句子不被截断；② 父子块（small-to-big），用小块做检索命中、命中后把所属的大块或整节喂给模型，兼顾召回精度和上下文完整性；③ 元数据关联，每个 chunk 带上文档 id、章节路径、前后块 id，检索时先按元数据过滤再向量召回，需要时按前后 id 扩展邻域；④ 给每个 chunk 生成一句上下文说明再嵌入（contextual retrieval），把「这段在讲什么」补进向量里，明显改善孤立小块的召回。存储上通常是：向量进向量库（pgvector / Milvus 之类）并带元数据做过滤，原始文本和文件进对象存储或关系库，需要结构化查询的字段单独建索引——索引放 DB 还是向量库不是二选一，而是按「过滤条件走 DB、相似度走向量库」分工。

Skill 与 MCP：一个管上下文，一个管能力接入：Skill 的本质是「按需加载的提示词 + 参考资料 + 可选脚本」的打包，模型平时只看到一个精简的 name/description 列表（几十个 token），判断当前任务相关后才去读完整的 SKILL.md 和附带文件，靠这种渐进式披露把上下文省下来；所以写好 Skill 的关键是描述里写清「什么时候用、什么时候不要用、产出长什么样」。MCP 则是把工具、资源、提示词标准化的协议：写一个 server 就是定义工具的 name、description、JSON Schema 参数和 handler，用官方 SDK 注册，再通过 stdio（本地进程，由客户端拉起）或 streamable HTTP 暴露给客户端；接入方在客户端配置里声明 server，客户端负责拉取工具清单、塞进模型的 tool 定义、管理进程生命周期与鉴权。几个容易踩的点：工具的 description 决定模型会不会选它，要写得像给新人看的说明；参数校验必须在 server 侧再做一遍，不能只信模型给的 JSON；stdio 模式下千万不要往 stdout 打日志，那会污染 JSON-RPC 帧，日志一律走 stderr。

意图识别怎么评测，以及 AI Native 团队的规范怎么落地：意图识别这类分类问题最容易被追问「你怎么知道分得对」，答题要点是评测闭环：先建带标注的评测集（从线上真实会话里采样、覆盖长尾与易混样本），用混淆矩阵看具体是哪两类在混，把「相似问法不同意图」的 case 单独成组做回归；线上用路由结果 + 用户行为（是否打断、是否重问）做弱标注持续监控。工程上不要只靠一次分类：先用规则/关键词兜住高频明确意图，再用模型分类并输出置信度，低置信度走澄清追问或状态机确认，而不是硬猜一个路由。至于团队开发规范，落到 AI Native 场景有两个抓手：把规范写成机器可读的单一来源（一份规则文件，各家的入口文件只做引用，避免多份拷贝漂移），再把硬规则尽量变成确定性检查（lint、格式化、CI 门禁、预提交钩子），让 Agent 无论用哪个工具都在同一道闸门内工作；软规则则写进 review 清单，靠评审而不是靠祈祷。