题1：RAG 的 chunking 策略有哪些？怎么选？#

参考回答（面试口语化）：

Chunking（分块）是 RAG 系统里决定检索上限的环节——你分块分得不好，后面的 embedding、检索、生成再优化也救不回来。

三种主流策略：

① 固定大小滑动窗口 最简单，设定一个固定 token 数（比如 512），按这个大小切，相邻 chunk 之间有重叠（比如 overlap 128 token）。优点是实现容易、通用性强；缺点是会切断语义完整的段落，导致检索到的片段”前言不搭后语”。

② 语义分块 按文档的自然边界（段落、章节、标题）来切，尽量保持语义完整性。适合结构化文档（PDF、Markdown、技术文档）。实现稍微复杂一点，需要做文档结构解析，但检索质量明显更好。

③ 递归分块 大块→小块逐级拆分。先按章节切大块，大块太长再按段落切中块，中块还长再按句子切小块。适合长文档，不同层级的 chunk 可以配合不同的检索策略。

怎么选？ 核心方法是用评估集跑不同策略的效果对比。建一套标注好的 QA 数据集，跑不同 chunking 策略的召回率、答案准确率对比，选最优的。通用场景先用固定大小+语义分块做 baseline，逐步优化。

面试加分：Chunking 没有银弹，最好的策略取决于你的文档类型和用户提问方式。关键是用数据说话，不是靠感觉。

题2：RAG 检索优化有哪些手段？是 6 大手段展开说#

参考回答（面试口语化）：

RAG 检索优化，业界常用的六大手段：

① 分块策略优化：上文说了，用评估集对比不同分块策略的效果。不赘述。

② 多路检索：不只做向量检索，同时跑关键词检索（BM25/Elasticsearch）、混合检索（向量+关键词加权）。向量检索擅长语义匹配但可能忽略精确关键词，关键词检索正好互补。多路召回后合并排序，能显著提升召回率。

③ 重排序（Rerank）：检索出 Top-K 候选后，用专门的 Rerank 模型（比如 BGE-Reranker）对候选进行二次排序。因为向量检索的排序不一定最优，Rerank 可以更精细地计算相关性，把真正有用的排在前面。需要理解的是，Rerank 的计算成本比向量检索高，所以一般只对 Top-50 或 Top-100 做 Rerank，不从头做。

④ 上下文压缩：检索到的文档片段可能很长，但和问题相关的部分只有几句话。用 LLM 或专门的压缩模型，只保留和问题最相关的部分再注入上下文。这样能省 token、减少噪音干扰。

⑤ 查询改写（Query Rewrite）：用户的原始问题可能表述模糊，不适合直接检索。比如用户问”那个框架的上下文怎么管”，改写器把它改成”OpenClaw 的上下文管理策略是什么”，检索效果会好很多。改写可以用轻量 LLM 完成，也可以用规则模板。

⑥ 反馈循环：根据用户对回答的反馈（点赞/点踩/是否采纳），反向调整检索策略——降低低质量 chunk 的权重、调整检索参数、给高频问题做缓存。这是持续优化的闭环。

面试加分：这些手段不是一股脑全上，是逐步叠加的。先从分块和检索做起，baseline 稳定后再加 Rerank、查询改写，最后做反馈闭环。每一步都配评估，确保加对了而不是”感觉好了”。

题3：RAG 常见失败原因有哪些？#

参考回答（面试口语化）：

实实在在做过的都知道，RAG 不是搭起来就能用的，有四个最常见的翻车点：

① 召回不足（Recall 不够）——Top-K 设得太小，或者 chunk 切得太粗，最相关的内容根本没进候选。表现出来的症状是 LLM 说”根据提供的资料，未找到相关信息”。

② 检索结果相关性低——召回了但排在前面的都是噪音，真正有用的沉在底下。这是 chunking 不当 + 检索模型不够强 + 缺少 Rerank 的共同结果。

③ 注入的上下文干扰了模型判断——有时候检索到了一些看似相关但实际上无关或错误的内容，塞进 prompt 后反而把模型带偏了。这时候还不如不检索。

④ 用户问题表述不规范——问题太短、太模糊、或者领域术语用得不对，导致检索和问题对不上。

题4：怎么确认 RAG 召回数据的准确性？（政策文件场景）#

参考回答（面试口语化）：

政策文件场景下，准确性是命门——不能有”看起来差不多”的情况。

我的做法分两层：

第一层：离线验证。 建一个标注好的 QA 测试集，每个问题标注了标准答案和对应的原文出处。跑一遍 RAG 流程，检查：① 召回是否命中了原文出处（recall）；② 命中的 chunk 是否包含正确答案所需的信息（precision）；③ 最终生成答案是否和标准答案一致。

第二层：在线验证。 ① 让生成答案附带引用来源（原文 chunk ID + 段落引用），用户可以点击查看原文；② 用 LLM-as-Judge 对输出做事实一致性检查——“请判断以下回答是否有依据，没有依据的输出’无依据生成’并标红”；③ 人工抽检 + 反馈收集。

数据结构化： 政策文件场景还要注意一点——每条政策有发布时间、适用范围、效力等级。检索时需要加入时效性过滤（比如已废止的政策不能作为依据），匹配时按效力等级排序（法律 > 法规 > 规章 > 规范性文件）。

题5：RAG 评估方案有哪些？#

参考回答（面试口语化）：

RAG 的评估要分两部分——检索评估和生成评估。

检索评估（看召回好不好）：

• Recall@K：前 K 个结果里是否包含了相关文档
• MRR（Mean Reciprocal Rank）：第一个相关结果排在第几位
• NDCG@K：综合考虑排序位置和相关性等级

生成评估（看回答好不好）：

• 答案准确率：人工标注或 LLM-as-Judge 评分
• Faithfulness（忠实度）：生成答案是否严格基于检索结果，没有编造
• Answer Relevance：答案和问题的相关程度
• Context Relevance：检索结果和问题的相关程度（RAGAS 框架的三个核心指标）

评估方法：

1. 离线评估：建 QA 测试集，跑 benchmark，对比不同策略的指标变化
2. 在线评估：A/B 测试，看用户采纳率、留存率、反馈率
3. LLM-as-Judge：用 GPT-4/Claude 等强模型给答案打分（需要校准，防止偏好偏差）

核心认知：RAG 评估不能只看最终答案，要拆开看”检索”和”生成”两段。检索不好，答案是 no-how；检索好但生成不好，是白费功夫。

题6：Embedding 模型怎么选？需要考虑哪些因素？#

参考回答（面试口语化）：

选 Embedding 模型不是越贵越好，要从几个维度综合考虑：

① 维度（Dimension）：维度越高信息越丰富，但存储和检索成本也越高。常见的比如 768 维、1024 维、1536 维。文档量少用低维也行，海量数据维度高效果更好。

② 语言支持：中文还是英文为主？如果是中英文混合，要看模型是否双语支持。M3E 对中文好，OpenAI text-embedding-3 双语都行，BGE 系列也有中文版。

③ 成本：OpenAI 的 embedding 是按 token 计费的，量大成本不可忽视。开源的 BGE、M3E 可以本地部署，零推理成本但需要自建服务。

④ 领域适配：通用领域用通用 embedding 就行。如果是垂直领域（法律、医疗、代码），建议在领域数据上对比测试 —— 很多模型看起来很强，到了你具体场景可能反而不如小模型。

⑤ 性能与延迟：有些 embedding 模型推理慢（特别是大模型），在高 QPS 场景下要测延迟。可以考虑用更轻量的模型或者做缓存。

常用模型一览：

• OpenAI text-embedding-3-small/large：效果好但付费
• BGE（BAAI）：开源，效果好，中文友好
• M3E：国产，性价比高
• Cohere Embed：企业级，多语言

面试加分：选型不只看指标，要看”在你的数据上”的效果。建议拿自己的 QA 数据集跑个对比，用 Recall@K 说话。

题7：MCP 的通信协议有哪些？有什么区别？#

参考回答（面试口语化）：

MCP 目前支持两种主要的传输方式：

① STDIO（标准输入输出） MCP Server 作为子进程和 Client 在本地通信，通过标准输入输出传 JSON-RPC 消息。优点是最简单、延迟最低、无需网络配置；缺点是只能本地用，Server 和 Client 必须在同一台机器上。适合个人开发环境、本地 Agent 工具。

② SSE（Server-Sent Events） MCP Server 跑在远程，Client 通过 HTTP SSE 连接和服务端通信。SSE 是单向推送（服务端→客户端），客户端用 POST 请求发送消息。优点是远程可访问、可以部署在云端；缺点是有网络延迟，需处理连接管理和重连逻辑。适合生产环境、多用户共享服务。

未来可能的第三种：WebSocket —— 社区有讨论，全双工通信比 SSE 更灵活，但目前还没标准化。

区别总结：

题8：MCP 怎么处理并发调用？#

参考回答（面试口语化）：

MCP 的并发处理分几个层面：

Server 侧：MCP Server 通常是单进程服务，请求在内部并行处理。Server 需要自己管理并发——比如用连接池限制最大并发数，用队列做请求排队，用超时机制防止死锁。

Client 侧：对于不会被修改的工具调用（比如只读的文件查询、搜索），Client 可以并行发送多个请求，不用等前一个完成再发下一个。但对于有状态的操作（比如写入文件、执行命令），需要串行化，防止竞态。

工具级别：工具本身的定义要说明是否幂等、是否安全并发。Client 根据工具的”只读/读写”属性决定是否并行调用。

OpenClaw 的做法参考：在 context 管理里会记录工具调用的并发策略，同时对工具返回的大结果会做截断处理，防止一个慢工具阻塞整条链路。

题9：A2A 协议和 SSE 协议了解吗？#

参考回答（面试口语化）：

**A2A（Agent-to-Agent）**是 Google 2025 年推出的 Agent 间通信协议。解决的问题是：不同 Agent 系统之间怎么发现对方、怎么协作。A2A 定义了 Agent Card（能力声明）、任务管理、消息传递的标准格式。和 MCP 的区别——MCP 是 LLM↔工具，A2A 是 Agent↔Agent。

**SSE（Server-Sent Events）**是 HTTP 协议基础上的一层，让服务端可以向客户端推送消息。特点：单向（服务端→客户端）、基于 HTTP 长连接、自动重连。在 AI 应用里最常用的场景是流式输出——LLM 一个字一个字往外蹦，用 SSE 推给前端，用户能看到逐字出现的回答。

两者的关系：不冲突。A2A 是 Agent 间的通信协议，底层传输可以用 SSE、WebSocket 或 HTTP。SSE 只是传输层的一个选择。

题10：你还知道哪些工具协议，除了 MCP？#

参考回答（面试口语化）：

除了 MCP，常见的工具/协议还有：

① Function Calling（原生方案） 各家模型厂商在 API 层提供的私有方案——OpenAI 的 function calling、Claude 的 tool use、Google 的 function call。本质都是传 Schema 让模型决策。不标准、换模型要适配。

② OpenAPI / Swagger 传统的 RESTful API 描述标准。MCP 出现前，有人用 OpenAPI 规范来描述工具接口，然后转成 LLM 能理解的格式。

③ A2A（Agent-to-Agent） Google 提出的 Agent 间协议，补充了 MCP 没覆盖的 Agent 协作场景。MCP 管工具调用，A2A 管 Agent 通信。

④ SSE / WebSocket 传输层协议。SSE 用于服务端推送，WebSocket 用于全双工通信。AI 应用里流式输出标配 SSE，实时交互用 WebSocket。

⑤ gRPC 高性能 RPC 框架，有些工具调用链路会用它做内部通信，延迟比 HTTP + JSON 更低。

面试加分：不是协议越多越好，看场景选。MCP 解决”工具怎么暴露”的问题，A2A 解决”Agent 怎么协作”的问题，Function Calling 解决”模型怎么调工具”的问题。三个不同层次，可以组合使用。

1
Skill（抽象层）—— 组合多个工具+逻辑，封装成「能力」
2
    ↓ 内部调用
3
Function Calling（实现层）—— 模型决策「调哪个工具、传啥参」
4
    ↓ 传输调用
5
MCP（协议层）—— 标准化「工具怎么暴露、怎么通信」

题11：API 超时和报错怎么排查解决？#

参考回答（面试口语化 — 字节高频题）：

API 超时报错的排查分几步走，核心思路是分层排查：

第一层：重试。 瞬时故障（网络抖动、服务短暂不可用）加重试就能解决。重试要指数退避（第一次等 1s，第二次 2s，第三次 4s…），防止雪崩。

第二层：工具级别降级。 如果某个工具连续失败（比如超过 3 次），切换到备用方案。比如主模型挂了换备用模型，主搜索工具挂了换关键词搜索。

第三层：Agent 级别的容错。 让 LLM 自己做判断——“工具调用失败了，尝试换一个方式/换个参数再试”。比如读文件失败，模型可以换成”先列出目录再确定文件路径”。

排查方法： ① 看工具调用日志（入参、出参、错误码、耗时）；② 区分是模型问题（调用了不存在的工具）还是工具问题（工具本身挂了）还是网络问题；③ 分类统计失败原因，找出高频故障点针对性优化。

面试加分：关键是有系统性的兜底方案，不是只有一个”try again”。

题12：Token 消耗过快怎么排查和优化？#

参考回答（面试口语化 — 字节高频题）：

Token 消耗是钱的问题，也是性能的问题。排查步骤：

第一步：定位大头。 拿一次完整任务，统计三块的 token 占比——System Prompt 占多少、工具定义占多少、对话历史占多少。通常对话历史是大头，工具返回结果里的超大文本是元凶。

第二步：针对性优化。

• 上下文压缩：用摘要替换原始历史，最有效。平均能压 20-40%。
• 缓存：常用技能、工具定义、重复的知识不每次加载。语义缓存——相同问题的检索结果直接复用。
• 批处理：独立的小请求合并成一次大请求，减少重复的 prompt 固定开销。
• 模型选择：简单任务用轻量模型（比如 GPT-4o-mini），复杂任务才上重模型。
• 工具结果截断：设置工具返回结果的 token 上限，超了就截，保留头尾+摘要。

第三步：监控。 每个请求记录 token 消耗，设置告警阈值。发现异常增长的 case 做根因分析。

题13：Agent 优化后有什么可量化的效果？#

参考回答（面试口语化 — 小厂/中厂高频题）：

这个题的核心是——不能靠”感觉”，必须用指标说话。一般从四个维度量化：

① 准确率/任务完成率：优化前 70%，优化后 85%。比如通过 benchmark 的 pass rate 衡量。

② 响应速度：平均响应时间从 5s 降到 3s。包括模型推理时间和工具调用时间。

③ Token 成本下降：通过上下文压缩和缓存，单次请求平均 token 消耗减少 30%。可以换算成钱——“每月省了 500 刀”更有说服力。

④ 用户满意度：NPS 评分、人工评估打分、用户回访记录。

面试加分举例：“我们做了上下文压缩后，平均 prompt 长度从 6964 降到 5418（压缩率 18%），任务正确率从 66.7% 提升到 100%，重复读文件从 8 次降到 3 次。” 每一句都有数据。

题14：Agent 任务恢复/断点续跑怎么做？#

参考回答（面试口语化 — 字节高频题）：

Agent 执行过程中可能中断——报错、超时、用户暂停。断点续跑的核心是记录每一步的执行状态 + 存快照。

怎么做：

1. 状态记录：每运行一步，把当前的上下文快照（用户输入、系统 prompt 版本、工具候选集、工具调用结果、Agent 输出）存下来。每步一个”检查点”。
2. 中断检测：Agent 重启时，检查是否有未完成的任务（检查点存在且状态不是”已完成”）。
3. 恢复执行：加载最近的检查点，重新初始化 Agent 状态，从中断的地方继续执行。恢复时需要把历史上下文摘要注入，让 Agent 知道”到哪了”。

关键设计：

• 检查点文件要结构化（比如 JSON），包含足够的元数据（任务 ID、步骤号、时间戳）
• 恢复时要告诉 Agent “这是恢复执行，不是新任务”——防止它从头开始
• 检查点定期清理，太旧的要淘汰

题15：Agent 的鲁棒性设计有哪些要点？#

参考回答（面试口语化）：

鲁棒性设计就是——系统不会因为一次异常直接崩掉。从输入到输出全覆盖：

1
输入校验 → 意图识别 → 敏感词过滤 → 上下文截断 → 错误兜底
2
                    ↓
3
            二次校验与格式解析

每个环节的要点：

① 输入校验：先检查用户输入有没有问题——是不是恶意指令、是不是无关问题、参数是否合法。校验通过了才调用模型。

② 意图识别：判断用户到底想做什么——是查询、操作、还是闲聊？不同意图走不同处理路径，防止误操作。

③ 敏感词过滤：显式禁止的内容（政治敏感、黄赌毒、个人隐私）在入站时拦截。

④ 上下文截断：上下文太长时要不就压缩、要不就截断，不能让它溢出报错。

⑤ 错误兜底：所有环节出问题都有 fallback——重试、降级、给用户友好提示、转人工。

⑥ 二次校验：模型输出的关键内容做格式检查、内容校验，不完全信任模型输出。

关键原则：不是为了”好看”，是为了系统稳定跑下去。

题16：怎么节约 AI 成本？做了哪些优化？#

参考回答（面试口语化 — ML/YC 公司高频题）：

AI 成本大头在模型调用费。能优化的点很多：

① 上下文压缩（效果最明显）：把几万 token 的对话历史压成几千 token 的摘要，直接省 40-60% token。这是成本大头。

② 缓存策略：语义缓存——相同/相似问题的检索结果直接复用；技能缓存——常用工具定义不重复加载；模型缓存——Prompt 复用相同的前缀（prompt caching 功能）。

③ 模型选择：简单任务用轻量模型（GPT-4o-mini/Claude Haiku），复杂任务才用重型模型。80% 的请求可以用轻量模型处理，成本能省 70%+。

④ 批处理：独立工具调用可以并行，减少来回调用的次数。

⑤ 降低重试次数：优化 Prompt 和工具 Schema 让模型一次调用就成功，减少重试的 token 浪费。

⑥ 流式输出 + 提前终止：模型输出到一半已经确定答案了，可以提前终止节省 token。

⑦ 本地部署：量大且对延迟不敏感的场景，用开源模型本地部署（比如 BGE embedding 本地跑、Qwen 本地跑），推理成本降到接近零。

面试加分举例：“我们通过上下文压缩省了 30% token，缓存省了 20%，轻量模型替代重型模型省了 50%，三叠加综合成本下降了 60% 以上。”

题17：Agent 安全体系怎么设计？怎么防止 Agent 失控？#

频次：⭐⭐⭐⭐ | 难度：A | 来源：字节/腾讯/CVTE/阿里淘天

参考回答（面试口语化）：

面试官问”系统为什么不会失控”——不是要你保证”Agent 永远不会出错”，而是要看你有没有想清楚安全边界。

三层安全设计：

第一层：入口限制——Agent 没有”想做就做”的自由度 Agent 所有的能力都是显式注册的。你在 tool registry 里注册了什么，Agent 才能用什么。没有注册的工具，Agent 没法凭空调用。每个工具的 description 里会说明使用限制（比如”文件删除工具只允许删除工作区目录下的文件”）。

第二层：执行隔离——Agent 在”沙箱”里干活

• 文件系统隔离：Agent 只能访问工作区目录，不能碰系统文件。用 Docker 挂载卷 + 用户映射实现
• 网络隔离：非必要的网络请求会被拦截
• 操作审计：每一步工具调用都记录完整的入参、出参、时间戳

第三层：人在回路——关键操作永远有人确认 对于有破坏性的操作（删除文件、执行高危命令、写数据库），Agent 不能直接执行——它只能生成操作方案，等用户确认后才执行。等于说 Agent 的自主权不是无限的，它其实是一个”聪明但需要上级签字的下属”。

额外还要考虑的安全风险：

• Prompt 注入攻击：用户输入试图覆盖系统指令→输入侧做指令检测 + 权限分离
• 沙箱逃逸：Agent 生成的代码试图突破沙箱→seccomp 过滤危险 syscall + cgroup 资源限制
• 循环调用：Agent 的代码写 bug 了导致无限循环→限流检测 + 最大步数限制

面试加分：从”代码生成”角度——“我们在工具定义里加了’只读/读写’属性标注。只读工具（搜索、阅读文件）Agent 可以自主调用；读写工具（修改文件、执行命令）必须先产生操作方案，用户确认后才执行。这个设计让我们敢给 Agent 更多自主权——因为关键的写操作永远有人兜底。“

题18：Agent 任务恢复/断点续跑怎么做？#

频次：⭐⭐⭐ | 难度：B+ | 来源：字节高频

参考回答（面试口语化）：

Agent 执行过程中可能中断——报错、超时、用户暂停。断点续跑的核心是记录每一步的执行状态 + 存快照。

怎么做：

1. 状态记录：每运行一步，把当前上下文快照（用户输入、system prompt 版本、工具候选集、工具调用结果、Agent 输出）存下来。每步一个”检查点”。
2. 中断检测：Agent 重启时，检查是否有未完成的任务（检查点存在且状态不是”已完成”）。
3. 恢复执行：加载最近的检查点，重新初始化 Agent 状态，从中断的地方继续。恢复时需要把历史上下文摘要注入，让 Agent 知道”到哪了”。

关键设计：

• 检查点文件要结构化（JSON），包含足够元数据（任务 ID、步骤号、时间戳）
• 恢复时要告诉 Agent”这是恢复执行，不是新任务”——防止从头开始
• 检查点定期清理，太旧的淘汰

对比实际落地经验：用 SQLite 做检查点存储比文件系统好——支持事务写入、查询、清理，而且不需要自己处理并发问题。LangGraph 的 Checkpointer 就是基于 SQLite 做的。

题19：Agent 意图识别不准怎么优化？#

频次：⭐⭐⭐ | 难度：B+ | 来源：Cider/滴滴

参考回答（面试口语化）：

意图识别不准是 Agent 项目里最让人头秃的问题之一——用户说的话千奇百怪，模型理解歪了，后面所有步骤都错了。

优化策略从浅到深：

① CoT 引导

• 让模型逐步推理而不是直接跳结论。加一句”请先分析用户想做什么，再决定下一步行动”
• 实测 CoT 引导后意图识别准确率能提 5-10%

② 反问澄清

• 模型对用户意图置信度低于阈值时，不要猜，直接反问用户确认
• “您是想查询天气还是设置提醒？“——反问能避免 80% 的错误意图推断

③ 多轮修正

• 允许用户纠偏，把纠偏记录存入 few-shot 示例
• 比如用户说”查北京天气”→ 模型以为是查北京旅游攻略 → 用户纠正”我说天气” → 记录这个纠偏对，下次类似场景参考

④ 轻量分类器兜底

• 用 BERT 级别的分类模型做第一道意图预检（意图分 5-10 个大类）
• 分类器置信度高的走特定处理路径，低的走 LLM 通用推理
• 好处：简单请求（查天气、算算术）不走 LLM，省成本也更快

面试加分：要让人感觉你真的挨过意图识别的打——“我们有一次上线了新工具，结果用户说’帮我看看这个’，模型直接调了 4 个不同工具各尝试了一次，浪费了好多 token。排查后发现是工具 description 里没有加’什么时候用’的说明，模型面对多个可选工具时只能挨个试。加上说明后这个问题就解决了。”

🎯 下篇预告：各厂特色题篇（30+ 题） — 字节/阿里/腾讯/滴滴/中小厂独家考点 + 项目话术题