企业官网建设流程全解析

1. 为什么我要自己造一个 AI 面试官，而不是继续背八股

面到第三轮的时候，候选人简历上写着"精通 RAG、Agent、LangChain、LangGraph"，我问了一句"你那个 RAG 系统里，检索回来的 chunk 是怎么做重排的"，对面沉默了大概十秒，然后开始背"我们使用了向量数据库……"。这种场景我一年能遇到几十次。问题不在候选人，在于市面上根本没有一个能真正"追问"的练习工具——你对着镜子背题，镜子不会反问你；你刷 LeetCode 式的题库，题目是死的，追问是活的。

所以我花了大概三周时间，把自己这些年做 RAG 和 Agent 项目时踩过的坑、面过的题、被问倒过的点，全部沉淀成了一个AI 面试官 Skill。它的核心定位很明确：不是题库，是面试官。它会根据你的回答动态追问，会揪住你项目里的模糊表述往下挖，会在你说"我们用了 LangGraph"的时候问你"为什么不用 LangChain 的 AgentExecutor，状态机那部分你是怎么设计的"。

这个 Skill 覆盖四个技术栈：RAG、Agent、LangChain、LangGraph。适合三类人：准备跳槽但项目讲不清楚的工程师、刚入门 LangChain 想验证自己理解深度的学习者、以及带团队想给下属做技术模拟面试的 Tech Lead。下面我把这个 Skill 的设计思路、追问机制、四个技术栈的考察重点、以及我自己实测下来最容易被问崩的几个点，完整拆开讲一遍。

2. 这个 Skill 的追问机制到底是怎么设计的

2.1 为什么"追问"比"出题"难十倍

普通的 AI 面试工具本质是"出题机"：从题库里抽一道题，你答完，它给个评分。这种工具的问题在于，它无法判断你答案里的信息密度。你说"我们用 RAG 提升了问答准确率"，出题机只会觉得你答了；但真正的面试官会立刻追问："提升前多少，提升后多少？用什么指标衡量的？是 hit rate 还是 answer relevancy？"

所以这个 Skill 的核心不是题目库，而是一套追问决策逻辑。我的设计思路是：把候选人的回答拆成若干个"可追问锚点"，每个锚点对应一个追问方向。锚点分三类：

• 技术名词锚点：你提到"重排""混合检索""状态机""工具调用"，每一个都是可深挖的点。
• 数字锚点：你说"准确率提升了 30%"，那就要问基线是多少、测试集怎么构建的。
• 模糊表述锚点：你说"做了优化""性能不错""效果挺好"，这些词在面试官耳朵里就是"你没做过"的信号，必须追问。

2.2 追问深度的三层递进

我在 Skill 里把追问设计成三层，模拟真实面试的压迫感：

第三层是最狠的。因为一个人可以背会"LangGraph 用状态图管理流程"，但只有真正用过的人才知道"当节点里做异步 IO 的时候，checkpointer 的写入时机如果不注意，会出现状态回滚"这种边界问题。

2.3 Skill 的输入输出结构

这个 Skill 本质上是一段结构化的提示词工程，输入是候选人的简历片段或项目描述，输出是一轮一轮的追问。核心结构大概是这样：

角色：资深 AI 工程面试官 考察栈：RAG / Agent / LangChain / LangGraph 追问策略： 1. 识别回答中的技术锚点、数字锚点、模糊锚点 2. 对每个锚点生成 1-3 层追问 3. 根据回答质量决定是否继续深挖或切换话题 4. 每轮结束给出"回答质量信号"（扎实/含糊/背题） 输出格式： - 当前追问 - 追问意图（为什么问这个） - 期望听到的关键词 - 危险信号（出现即扣分）

这里有个关键设计：追问意图要显式输出。为什么？因为练习者需要知道"面试官问这个到底想听什么"。很多人答不好不是不会，是不知道对方在考什么。把意图摊开，练习效率会高很多。

提示：这个 Skill 我建议配合语音输入使用。打字回答和口头回答是两回事，口头回答更容易暴露"背题感"，因为背的东西一旦被打断就接不上。

3. RAG 部分：从"你用过"到"你调过"的追问链路

3.1 检索环节的追问重点

RAG 是这四个栈里最容易被"假装做过"的。因为搭一个 demo 太容易了——LangChain 几行代码就能跑通一个向量检索问答。但面试官要区分的是"跑过 demo"和"上过生产"。

我的 Skill 在 RAG 部分的追问，第一刀永远砍在检索环节。典型链路：

1. "你的知识库多大？多少文档、多少 chunk？"——判断规模。
2. "chunk 怎么切的？固定长度还是语义切分？overlap 设了多少？"——判断是否调过参数。
3. "检索用的是什么？纯向量还是混合检索？"——判断技术选型深度。
4. "召回 top-k 设的多少？为什么？"——判断是否有调优经验。
5. "检索回来的结果，你怎么判断它是不是真的相关？"——这一刀最狠，直接问 hit rate。

大部分人到第 3 步就开始含糊了。因为 demo 阶段大家都是similarity_search一把梭，根本没考虑过混合检索、重排这些生产级问题。

3.2 重排与评估：区分度最高的两个点

如果候选人扛过了检索环节，我会立刻切到重排（Rerank）和评估。这两个点是区分度最高的，因为它们是"从能用到好用"的分水岭。

重排的追问逻辑是：先问"你用了 rerank 吗"，如果用了，问"用的什么模型，cross-encoder 还是 API"；如果没用，问"为什么不用，是延迟考虑还是效果已经够了"。这里没有标准答案，关键是看你能不能说出取舍理由。

评估的追问更直接："你怎么知道你的 RAG 系统效果好？"如果回答"感觉还行"或者"用户反馈不错"，基本可以判定没做过量化评估。真正做过的人会提到hit rate、MRR、answer relevancy、faithfulness这些指标，会说"我构建了一个 200 条的小测试集，人工标注了标准答案"。

3.3 一个真实的追问案例

我拿自己之前的一个项目描述喂给这个 Skill，它给出的追问链路是这样的：

项目描述："基于 LangChain 搭建了一个企业知识库问答系统，支持多轮对话。"

追问 1：多轮对话的历史是怎么管理的？是拼接进 prompt 还是有独立的记忆模块？ 追问 2：如果用户第二轮的问题和第一轮完全无关，你的检索会受历史影响吗？ 追问 3：知识库更新的时候，向量库怎么同步？全量重建还是增量？ 追问 4：如果检索不到相关内容，你的系统怎么处理？直接说"不知道"还是让 LLM 硬答？

这四个问题，每一个都对应一个生产环境的真实坑。第 2 个问题尤其阴——很多人做多轮对话就是把历史一股脑塞进 prompt，结果检索 query 被历史污染，召回质量暴跌。这个坑我踩过，所以专门设计进了 Skill。

4. Agent 部分：工具调用、记忆、并发三座大山

4.1 工具调用不是"能调就行"

Agent 部分的追问，我设计的第一座山是工具调用。现在用 LangChain 或 LangGraph 写个能调工具的 Agent 太简单了，但面试官要问的是：

• 你的工具描述（description）是怎么写的？有没有因为描述不清导致 LLM 选错工具？
• 工具调用失败了怎么办？有没有重试机制？重试几次？
• 多个工具的参数有依赖关系时，你怎么保证调用顺序？
• 工具返回的结果太长，超出上下文了怎么处理？

这几个问题里，工具描述是最容易被忽略的。很多人写工具就是@tool装饰器一挂，description 随便写一句。但实际生产中，工具描述的质量直接决定 Agent 的可靠性。我自己的经验是，工具描述要写得像给新人看的 API 文档——说清楚什么时候用、什么时候不用、参数什么含义、返回什么格式。

4.2 记忆管理：短期与长期的分界

第二座山是记忆。Agent 的记忆分短期（对话历史）和长期（跨会话知识）。追问链路：

1. "你的 Agent 有记忆吗？短期还是长期？"
2. "短期记忆怎么存的？内存还是持久化？"
3. "长期记忆用什么方案？向量库还是结构化存储？"
4. "记忆太多导致上下文爆炸，你怎么压缩？"

第 4 个问题是分水岭。真正做过长对话 Agent 的人，一定处理过上下文压缩问题。常见方案有滑动窗口、摘要压缩、重要性筛选。能说出"我用 LLM 对历史做摘要，保留关键信息"的人，基本可以确认做过。

4.3 并发：Agent 上生产的真正门槛

第三座山是并发。这个问题我在热词里看到"ai agent 怎么扛并发"，说明很多人卡在这。我的 Skill 里专门设计了一组并发追问：

• 你的 Agent 单次请求耗时多少？瓶颈在哪？
• 多个用户同时请求，你的 LLM 调用怎么限流？
• 如果 Agent 里有长时间运行的工具，怎么避免阻塞？
• 状态管理在并发下会不会串？

这里有个很实际的坑：LangGraph 的 checkpointer 在并发场景下，如果 thread_id 设计不当，会出现状态串扰。这个问题不实际压测根本发现不了。我在 Skill 里把它设计成一个"高危追问"，答不上来会标记为"缺乏生产经验"。

5. LangChain 与 LangGraph：从会用 API 到理解抽象

5.1 LangChain 的追问：你是在用还是在堆

LangChain 的追问核心是抽象理解。因为 LangChain 封装太厚，很多人是"照着文档拼"，根本不知道底层发生了什么。典型追问：

• Runnable接口的核心方法是什么？invoke、batch、stream的区别？
• LCEL 的管道符|底层是怎么实现的？
• MultiVectorRetriever解决什么问题？什么时候该用它？
• LangChain 的 Agent 和 LangGraph 的 Agent，本质区别在哪？

最后一个问题是杀手锏。能答清楚的人，说明他理解了两者的设计哲学差异：LangChain 的 AgentExecutor 是"循环调用直到没有工具调用"，而 LangGraph 是"显式的状态图，你可以精确控制每一步的流转"。这个区别在简单场景下无所谓，但在需要人工介入、条件分支、循环控制的复杂场景下，就是天壤之别。

5.2 LangGraph 的追问：状态、节点、边

LangGraph 是这四个栈里最新的，也是最能区分"真会"和"跟风"的。我的追问设计围绕三个核心概念：

状态（State）：

• 你的 State 是怎么定义的？用 TypedDict 还是 Pydantic？
• 多个节点同时更新 State 的同一个字段，怎么处理冲突？
• Reducer 函数你用过哪些？

节点（Node）：

• 节点里做的是纯计算还是 IO？
• 节点抛异常了，图会怎么走？
• 条件边（conditional edge）的判断逻辑写在哪？

边（Edge）：

• 普通边和条件边的区别？
• 怎么实现循环？循环终止条件怎么设？
• 怎么实现"人工介入"（human-in-the-loop）？

这里我特别想说的是Reducer。LangGraph 里多个节点更新同一个 State 字段时，默认是覆盖，但如果你用Annotated[list, add]这种 reducer，就是追加。这个机制不理解，写多节点图的时候必然出 bug。我在 Skill 里把它设成必问项。

5.3 一个 LangGraph 工具调用的追问实例

热词里有"langgraph 工具调用"，我拿这个场景设计了一组追问：

场景：用 LangGraph 实现一个带工具调用的 Agent。

追问 1：你的图里有几个节点？分别是什么职责？ 追问 2：工具调用的结果怎么回填到 State？ 追问 3：如果 LLM 决定调用工具，但工具执行失败，图怎么处理？ 追问 4：怎么防止 Agent 陷入无限工具调用循环？ 追问 5：这个图和直接用 LangChain 的 AgentExecutor 比，优势在哪？

第 4 个问题是实战必踩的坑。Agent 有时候会反复调用同一个工具，尤其是工具返回结果不明确的时候。LangGraph 里你需要自己设一个计数器或者用条件边来终止。这个不实际跑过根本想不到。

6. 我实测下来最容易被问崩的五个点

6.1 指标说不清

"提升了准确率"但说不出基线、测试集、指标定义。这是最致命的。面试官一听就知道你没做过评估。正确做法是：任何效果描述都要带数字和口径，比如"在 200 条自建测试集上，hit rate 从 62% 提升到 81%"。

6.2 选型说不出理由

"我们用了 LangGraph"但问为什么不用 LangChain 就卡壳。技术选型没有对错，但必须有理由。哪怕理由是"团队更熟悉"也比"不知道"强。

6.3 边界没考虑过

问"什么情况下会失效"就答不上来。任何方案都有边界，RAG 在知识库覆盖不到的问题上会失效，Agent 在工具描述模糊时会选错工具。能主动说出边界的候选人，可信度直接翻倍。

6.4 并发没压过

问"QPS 多少""瓶颈在哪"就含糊。哪怕你没做过大规模压测，至少要知道自己系统的单次耗时和主要瓶颈（通常是 LLM 调用）。

6.5 版本细节记不清

LangChain 和 LangGraph 迭代很快，API 经常变。面试官如果问"你用的哪个版本""这个 API 在新版本里改了吗"，答不上来不致命，但如果你能说"我用的是 0.2.x，后来 0.3 改了 xxx"，会显得你一直在跟进。

7. 怎么把这个 Skill 用出最大效果

7.1 别把它当题库刷

这个 Skill 的正确用法是：拿你自己的项目描述喂进去，让它追问你。刷题库没用，因为面试官问的是你的项目，不是标准题。你把自己的项目讲一遍，让 Skill 追着问，问到答不上来的地方，那就是你的知识盲区。

7.2 录音回听

我强烈建议练习的时候录音。因为很多"背题感"你自己意识不到，但回听的时候特别明显——语速突然变快、语调变平、被打断后接不上，这些都是背题的信号。真实面试里，面试官一听就知道。

7.3 按栈分阶段练

不要一次练四个栈。建议顺序是：先 RAG（最基础），再 LangChain（工具层），然后 Agent（综合），最后 LangGraph（进阶）。每个栈练到能扛住三层追问，再进下一个。

7.4 把追问意图当学习大纲

Skill 输出的"追问意图"和"期望关键词"，其实就是这个技术点的知识大纲。你答不上来的地方，对应的就是你需要补的知识。比如追问意图是"考察是否理解混合检索的适用场景"，那你就去补 BM25 和向量检索各自的优劣。

8. 关于 Skill 本身的一些设计取舍

8.1 为什么不做成自动评分

我一开始想加自动评分，后来放弃了。因为面试这件事，评分是次要的，暴露盲区才是主要的。一个 0-100 的分数对你没帮助，但"你在 LangGraph 状态管理上答得含糊"这个反馈对你有帮助。所以 Skill 只输出"回答质量信号"，不输出分数。

8.2 为什么覆盖四个栈而不是一个

因为真实面试里，这四个栈是交织的。面试官问 RAG 的时候可能突然切到 LangChain 的 Retriever 抽象，问 Agent 的时候可能问你 LangGraph 怎么实现。单独练一个栈，到了真实面试还是会断片。

8.3 后续可以扩展的方向

这个 Skill 目前是纯文本追问。后续我想加两个东西：一是代码追问，让候选人写一段 LangGraph 的图定义，Skill 针对代码追问；二是系统设计追问，给定一个场景（比如"设计一个支持 1000 QPS 的 RAG 服务"），让候选人做系统设计，Skill 从架构层面追问。

我自己用这个 Skill 练了大概两周，最大的感受是：以前我以为自己懂 LangGraph，被追问之后才发现我只是会用 API。状态管理的 reducer 机制、并发下的 checkpointer 行为、条件边的异常处理，这些都是在被追问的过程中才真正搞清楚的。如果你也在准备 AI 方向的面试，或者想验证自己对 RAG 和 Agent 的理解深度，拿自己的项目去喂它，被问崩几次，比刷一百道题都管用。