适用人群：有志于或正在从事 AI 方向的前端/全栈工程师。

核心理念：

实战为王：聚焦真实面试中能体现工程能力的高频考题，而非空泛的概念。

直击考点：每题均标注「考察点」，助你洞悉面试官意图，答案按「结论 → 细节 → 延伸」组织，符合面试节奏。

工程差异：在 Agent、RAG、MCP、LangChain 等工程实战章节着墨更多，这是拉开差距的关键。

题量分布：
一、大模型基础 · 二、Prompt 工程 · 三、AI Agent 架构 · 四、RAG 检索增强生成 · 五、Function Calling 与 MCP · 六、Memory 与上下文管理 · 七、LangChain/LangGraph 框架 · 八、模型微调与私有化部署 · 九、前端 AI 集成 · 十、AI 提效篇 · 十一、综合场景题

一、AI 与大模型基础

面试官想确认：你对 LLM 有真实的“手感”，而非死记概念。

1. 什么是大语言模型（LLM）？它和过去的 NLP 模型本质区别是什么？

考察点：能否用一句话讲清 LLM 的本质。
答案：LLM 本质上是一个自回归概率模型，通过不断预测并生成下一个 Token 来输出内容。
- 核心区别：
  1. 任务范式转变：从过去“为每个任务训练一个模型”变为“一个模型，通过 Prompt 切换多种任务”。
  2. 规模产生质变：当参数量达到临界点后，模型会涌现出小模型不具备的推理、代码生成等能力。
一句话总结：LLM 是“自回归概率分布”+“大力出奇迹”的产物，不是真正意义上的“思考”。

2. GPT、Claude、Gemini、LLaMA、DeepSeek、通义、Kimi 这些怎么选？

考察点：是否具备根据业务场景进行技术选型的能力。

答案：选型不只看版本号，核心是匹配业务场景。

场景	首选模型	理由
复杂 Agent / 长任务	Claude (Anthropic)	工具调用最稳，长链路任务表现最佳。
通用业务 / 多模态	GPT (OpenAI)	生态最广，综合能力强，是通用基准。
超长上下文 / 多模态	Gemini (Google)	原生多模态和超长上下文是其杀手锏。
开源 / 学术研究	LLaMA (Meta)	开源生态的事实标准，适合作为微调底座。
开源 / 推理与代码	DeepSeek	推理能力出色，开源且性价比极高。
国内合规 / 私有化	Qwen (阿里), GLM (智谱)	中文优化好，开源生态完善，合规风险低。
中文长文档阅读	Kimi (Moonshot)	长上下文能力突出，中文信息抽取精准。
端侧 / 轻量部署	Mistral, Phi, Gemma	模型小，适合 IoT 或浏览器等资源受限环境。

3. Token 是什么？为什么按 Token 计费而不是字符？

考察点：对模型底层计费与资源消耗的理解。
答案：Token 是模型处理文本的最小语义单元，由分词器（Tokenizer）将文本切分而成。计费按 Token 而非字符，是因为模型的计算成本（FLOPs）与 Token 数量成线性关系，与字符数无关。
- 粗略换算（面试够用）：英文 1 Token ≈ 4 字符 ≈ 0.75 单词；中文 1 Token ≈ 1.5 汉字。
- 实战经验：预估成本时，建议额外加 1.3 倍 Buffer，以覆盖 System Prompt 在多轮对话中的反复计入。

4. 上下文窗口（Context Window）是什么？越大越好吗？

考察点：对模型能力边界的理性认知。
答案：上下文窗口是模型一次能处理的最大 Token 总数。并非越大越好。
- 三大反常识：
  1. “Lost in the Middle”：模型对长文本中间部分的内容关注度显著降低。
  2. 成本与延迟线性增长：处理超长上下文，计算量和耗时将急剧增加。
  3. 无法替代 RAG：直接塞入 50 篇文档，效果远不如 RAG 精准检索 5 个相关片段。
- 工程常态：通过滑动窗口、摘要压缩、向量检索等手段主动控制上下文大小。

5. Temperature, Top-p, Top-k, Seed 这几个参数怎么调？

考察点：对模型采样策略的理解。

答案：最常用的是 temperature，通常只调这一个。

参数	作用	代码/抽取场景	创意/闲聊场景
Temperature	控制随机性高低	0 - 0.3	0.7 - 1.0
Top-p	按概率累计截断	保持默认 0.9	保持默认 0.9
Top-k	按候选数截断	不常用	不常用
Seed	固定随机数种子，实现可复现	固定 Seed + T=0	不常用

实现完全可复现：固定 seed + temperature=0 + top_p=1，并关闭流式输出。

6. Embedding 是什么？和 LLM 的关系？

考察点：区分 Embedding 模型与 LLM 的能力边界。
答案：Embedding 模型将文本转换为固定长度的语义向量，通过向量间的距离（如余弦相似度）来衡量语义相关性。它与 LLM 是两个独立模型：
- LLM：负责“理解与生成”。
- Embedding 模型：只负责“表示”，不生成内容。
易错点：
- 维度不是越高越好：1024/1536 维是主流甜点，更高维度会显著增加存储和检索成本。
- 模型必须统一：换 Embedding 模型必须全量重建索引。
- 中文需专用模型：用英文 Embedding 处理中文效果会打折扣。

7. 余弦相似度 vs 欧氏距离怎么选？

考察点：向量检索的工程细节。
答案：向量检索中 99% 用余弦相似度，因为它只关注方向（语义）而不受向量长度影响。当所有 Embedding 向量都被归一化后，两者在数学上等价，选哪个主要看向量数据库的支持。

8. 模型「幻觉」（Hallucination）的根因是什么？

考察点：对模型根本局限的认知。
答案：幻觉是模型“概率最大化”这一架构决定的特性，而非 Bug。当训练数据缺失时，模型会基于统计相关性“编造”最可能的内容。
应对组合拳：
1. RAG：让答案有据可查，最有效。
2. Prompt 约束：明确要求“不知道就说不知道”。
3. 格式约束：强制输出 JSON 并带引用。
4. 后置校验：用代码或另一个 LLM 校验关键事实。
5. 低温度：Temperature 设为 0-0.3。
6. 微调：成本最高，作为最后手段。

9. 自回归（Decoder-only）和 Encoder-Decoder 区别？

考察点：对主流模型架构演变的了解。
答案：
- 自回归 (Decoder-only)：从左到右逐个 Token 生成，是 GPT、Claude、Llama 等当代主流 LLM 的架构。优点是架构简单，能通过 Prompt 统一所有任务。
- Encoder-Decoder：先编码整个输入再解码输出，代表模型是 T5、BART。在翻译、摘要等“输入-输出”明确的任务上效果更好，但目前已被 Decoder-only 的通用性所取代。

10. KV Cache 是什么？为什么能加速生成？

考察点：对推理加速技术的理解。
答案：在自回归生成中，每个新 Token 都依赖于前面所有 Token 的 K/V 值。KV Cache 的核心思想是缓存已计算好的 K/V 矩阵，新 Token 只需计算与已有 K/V 的注意力。这使得计算复杂度从 O(n²) 降至 O(n)。
- 延伸：Prompt Caching 进一步复用 System Prompt 的 KV Cache，对长 System Prompt 场景能大幅省钱。
- 瓶颈：KV Cache 本身也消耗显存，限制了推理服务的并发数。

11. 什么是 Streaming（流式输出）？

考察点：对提升用户体验的关键技术的掌握。
答案：模型每生成一个 Token 就立刻发送给客户端，无需等待完整生成。这能显著降低首 Token 时间 (TTFT)，极大提升用户体验。
前端实现方案：
1. SSE (Server-Sent Events)：最常用，基于 HTTP 的单向流。
2. WebSocket：适用于需双向通信（如中途打断）的复杂场景。

前端读取 SSE 代码片段：

const res = await fetch('/api/chat', { method: 'POST', body, signal });
const reader = res.body.getReader();
const decoder = new TextDecoder();
let buffer = '';

while (true) {
  const { value, done } = await reader.read();
  if (done) break;
  buffer += decoder.decode(value, { stream: true });
  // 按 \n\n 分包，解析 data: 字段
  let idx;
  while ((idx = buffer.indexOf('\n\n')) !== -1) {
    const chunk = buffer.slice(0, idx);
    buffer = buffer.slice(idx + 2);
    // 忽略 data: [DONE] 消息
    if (chunk.startsWith('data: ')) {
      const data = chunk.slice(6);
      if (data === '[DONE]') return;
      onDelta(JSON.parse(data));
    }
  }
}

12. System Prompt 是干什么的？应该放些什么？

考察点：对 Prompt 结构的理解。
答案：System Prompt 是设定整个对话**“底色”**的指令，模型每次回答前都会优先处理它。
四要素（建议按顺序）：
1. 角色定位：你是谁，你的专业领域。
2. 任务边界：能做什么，绝对不能做什么。
3. 风格格式：语气、长度、输出格式（如 JSON、Markdown）。
4. 兜底规则：不知道时说不知道，敏感问题处理方式。
实战经验：
- 关键约束放在 System Prompt 的开头和结尾。
- System Prompt 应保持稳定，便于触发 Prompt Caching 节省成本。

13. 多模态模型是什么？前端怎么用？

考察点：对模型能力发展的跟进。
答案：多模态模型能处理文本之外的信息，如图像（GPT-4o, Claude 3/4 Vision）、音频（Whisper, Realtime API）和视频（Gemini）。
前端场景：上传截图生成代码、设计稿转 HTML、录音转文字、报表截图智能摘要等。
注意：图片通常消耗 1k-2k Token，远贵于文本，需做大小压缩和格式优化。

14. 模型的「知识截止时间」（Knowledge Cutoff）是什么？

考察点：对模型时效性局限的认知。
答案：指模型训练数据收集的截止日期。在此之后发生的事件，模型一概不知。
工程对策：
1. RAG/联网搜索：注入最新信息。
2. 注入当前时间：在 System Prompt 中明确告知今天日期。
3. 强制拒答：要求模型对不确定的新信息直接说“不知道”。

15. RLHF、DPO、Constitutional AI 三个是什么？

考察点：对模型对齐（Alignment）技术的了解。
答案：三者都是为了让模型“听人话”的对齐技术。
- RLHF：先训练奖励模型，再用强化学习（PPO）微调。流程复杂但效果上限高。
- DPO：直接通过偏好数据优化，无需奖励模型。简单、稳定，是目前主流选择。
- Constitutional AI：让模型依据一套“宪法原则”自我批判和修正，减少人工标注依赖。

16. 推理（Inference）和训练（Training）的成本结构差异？

考察点：对成本模型的认知。
答案：
- 训练：一次性、极高昂。GPT-4 级别模型训练成本可达数千万至上亿美元。
- 推理：单次便宜，但累计成本巨大。在生产环境运行数月，推理总成本可能远超训练成本。
省钱重点：通过 Prompt Caching、压缩历史、控制 max_tokens、用小模型分流等手段优化推理成本。

17. 涌现能力（Emergent Ability）是真的吗？

考察点：对模型能力来源的思考。
答案：现象是真实存在的，尽管其成因有争议（部分研究认为是评估指标非线性导致）。工程上重要的是记住：当 7B 模型做不好某任务时，先尝试 70B 模型能否做到，而不是立刻去微调。

18. MoE（专家混合）和稠密模型的区别？

考察点：对模型架构优化的了解。
答案：
- 稠密模型：每次推理激活全部参数。
- MoE：模型包含多个“专家”子网络，每个 Token 仅路由到少数专家（如 8 选 2）。这使得总参数量巨大，但计算量（激活参数量）小，推理速度可接近更小规模的稠密模型。
- 代表：Mixtral, DeepSeek-V3。

19. 模型的"温度墙"为什么 Temperature=0 也不稳定？

考察点：对模型推理非确定性的深入理解。
答案：temperature=0 理论上应取最高概率 Token，但实际仍会有波动，原因包括：
1. 浮点数非结合律：多卡并行计算顺序不同导致结果微差。
2. 服务端并行调度：带来非确定性。
3. Top-p 默认值：需显式将 top_p 设为 1。
确保可复现：需同时满足 固定 seed + temperature=0 + top_p=1 + 单条请求 + 关流式。

20. 国产模型和海外模型在工程上最大的差异是什么？

考察点：对中国 AI 工程环境的理解。
答案：差异远不止“中文好不好”：
1. 合规与内容安全：国内模型需内置严格的内容审核与过滤机制。
2. 网关与限流策略：国产模型通常限流更宽松，价格更低。
3. 私有化部署生态：国产厂商（如 Qwen, DeepSeek, GLM）更重视并提供完整的私有化解决方案。
4. 工具调用成熟度：在 Agent 和 Function Calling 方面，Claude/GPT 仍领先，但 Qwen 等国产模型正在快速追赶。

二、Prompt 工程

面试官想确认：你是否具备通过调整输入来驾驭模型输出的硬功夫。90% 的惊艳 AI 应用，本质都是 Prompt 调得好。

21. Prompt 工程到底是什么？为什么花时间在它上面值得？

考察点：对 Prompt 价值的根本认知。
答案：Prompt 工程是用结构化的输入文本，引导 LLM 产生可控、稳定输出的技术。
为何值得：
1. 效果差异巨大：好 Prompt 与差 Prompt 的效果可能相差数倍。
2. 性价比最高：成本远低于微调，速度远快于换模型。
3. 问题根因：大多数情况下，模型表现不佳是因为“指令没写清”，而非“模型不行”。

22. Zero-shot / One-shot / Few-shot 的区别和适用边界？

考察点：对上下文学习（In-Context Learning）策略的掌握。
答案：
- Zero-shot：直接给指令，不给例子。用于模型已擅长的任务（翻译、总结）。
- One-shot：给一个例子，用于规范输出格式。
- Few-shot：给 2-5 个例子，用于输出格式特殊或业务规则复杂的场景。
最佳实践：
- 复杂格式 3-5 例足够，超过 5 个收益递减。
- 例子应覆盖边界情况（如空值、异常输入）。
- 与真实输入最相似的例子放在最后。

23. CoT（Chain of Thought）是什么？什么时候要/不要？

考察点：对引导模型推理技术的理解。
答案：CoT 是要求模型“先想后答”，将推理过程显式地写出来。常用触发词如“Let's think step by step”。
- 适用场景：数学题、多步推理、复杂规则判定。
- 不适用场景：
  1. 简单任务（翻译、抽取），CoT 会拖慢速度且无收益。
  2. 追求低延迟的场景，CoT 会使输出长度暴增。
  3. 内部已做隐式推理的模型（如 o1, DeepSeek-R1），加 CoT 可能产生干扰。

24. ReAct 是什么？和 CoT 的区别？

考察点：对 Agent 基础范式的理解。
答案：ReAct = Reason + Act，是 Agent 的核心范式。它让模型按照 思考 → 行动 → 观察 → 再思考 的循环执行。
与 CoT 的区别：CoT 只有“想”（Reason），而 ReAct 多了“想完之后调工具，并将结果带回来继续想”的步骤。

25. 怎么让模型严格输出 JSON？

考察点：对结构化输出技术的掌握。
答案：按可靠性从低到高排列：
1. Prompt 描述：最弱，模型容易“画蛇添足”。
2. JSON Mode：SDK 内置模式（如 response_format: { type: 'json_object' }），保证输出合法 JSON。
3. Function Calling / Tool：将输出定义为函数参数 Schema。强烈推荐，最稳。
4. Structured Output：在 Tool Calling 基础上增加 JSON Schema 强约束（OpenAI/Anthropic 支持）。
5. 约束解码：在推理引擎层强制只生成符合语法的 Token（如 outlines, jsonformer）。
兜底策略：解析失败时，用 jsonrepair 修复，或把错误信息连同原始输出一起喂给模型让它“自我修正”。

26. Prompt 写长了为什么效果反而变差？

考察点：对长上下文挑战的理解。
答案：三大根因：
1. Lost in the Middle：中间信息被忽略。
2. 指令冲突：内容过多，容易自相矛盾。
3. 稀释效应：核心指令被淹没在大量无关信息中。
优化策略：
1. 关键指令在开头和结尾重复强调。
2. 用 XML 标签显式分块（如 <context>, <task>）。
3. 静态背景知识挪到 RAG 中，Prompt 只保留当前任务。

27. 怎么写一个高质量的 Prompt？给你一个能直接套的骨架。

考察点：是否具备工程化的 Prompt 书写习惯。

答案：

# 角色
你是一名 [具体角色，越具体越好]。

# 任务
[一句话讲清楚要做什么]

# 输入
{{user_input}}

# 步骤（可选，复杂任务必加）
1. ...
2. ...

# 输出格式
[JSON Schema / Markdown 模板]

# 约束
- 必须...
- 不能...
- 当 [边界情况] 时，[怎么做]

# 示例（可选，复杂任务必加）
输入：...
输出：...

28. 为什么"不要做某件事"经常没效果？

考察点：对模型指令遵循机制的了解。
答案：模型对正向指令更敏感。“不要做 X”需要模型先理解“做X”再抑制它，路径更长。更好的做法是用“做什么”来代替“不要做什么”。
- ❌ 错误：不要使用复杂的词。
- ✅ 正确：使用日常简单的词汇，每句话不超过 15 个字，避免行业术语。

29. Prompt 注入（Prompt Injection）和越狱（Jailbreak）的区别？

考察点：对 AI 安全威胁的认知。
答案：
- Prompt Injection：用户输入夹带恶意指令，攻击的是“信任边界”，旨在让模型偏离 System Prompt。
- Jailbreak：用户输入旨在突破模型自身的对齐与安全限制，让其输出本不该输出的内容。
前端防御：
1. 结构化分隔：用 XML 等标签清晰区分系统指令和用户输入。
2. 输入/输出审核：使用轻量模型或关键词过滤。
3. 最小权限原则：工具调用和权限校验独立于模型决策。
4. 绝不在 Prompt 中放密钥。

30. 模型不听话怎么排查？

考察点：系统性的 Debug 能力。
答案：按顺序排查：
1. 指令冲突？System 和 User 指令是否矛盾？
2. Few-shot 例子带错？例子的权重大于指令。
3. 格式约束过严？比如既要求 JSON 又要求 Markdown。
4. Temperature 太高？业务任务应保持在 0-0.3。
5. Prompt 太长？关键指令被埋在中间。
6. 换个模型试试？不同模型在不同任务上表现各异。

31. 怎么调试/评估一个 Prompt？

考察点：是否有数据驱动的优化意识。
答案：别靠“点几下感觉还行”。最少应做到：
1. 建立测试集：准备 10-30 条涵盖各类场景的用例。
2. 脚本化评估：批量运行，统计通过率、Token 消耗、耗时。
3. 对比迭代：改完 Prompt 后重新运行，对比指标变化。
4. 错误分析：可视化失败的样本，寻找模式。
5. 接入可观测平台：如 LangSmith，用于线上请求的回放与调优。

32. Few-shot 例子放几个最合适？放哪里？

考察点：对上下文学习细节的掌握。
答案：
- 数量：简单任务 0-2 个；复杂格式 3-5 个；每种边界情况 1 个。
- 位置：放在 System Prompt 之后，User Input 之前，确保其稳定性，不与用户输入混淆。

33. 什么是 Prompt 模板？怎么管理？

考察点：对工程化实践的理解。
答案：Prompt 模板是将变量从 Prompt 中抽离，实现复用和版本管理。工程上严禁字符串拼接。
管理方案：
1. 框架内置：如 LangChain 的 PromptTemplate。
2. 纯文本模板：使用 Mustache、Handlebars。
3. 专用平台：如 LangSmith Hub、PromptLayer，用于团队级版本控制、A/B 测试和灰度发布。

34. Prompt Caching 是什么？为什么能省钱？

考察点：对成本优化技术的理解。
答案：模型（如 Anthropic, OpenAI）会缓存 Prompt 中不变的前缀部分（如长 System Prompt） 的 KV Cache。当下次请求使用相同前缀时，可直接复用。
收益：
- 成本降低：缓存部分 Token 计费可打折至 1/10 甚至更低。
- 延迟降低：TTFT 显著下降。
最佳实践：将不变的 System Prompt 和 Few-shot 例子放在前面，将变量放在末尾，以提高命中率。

35. Persona 是什么？什么时候要慎用？

考察点：对模型“角色扮演”的利弊认知。
答案：Persona 是为模型设定具体人格，如“你是一个温柔的客服小可”。
- 好处：风格一致，用户体验好。
- 慎用场景：
  1. 涉及专业判断（医疗、法律），人格化会导致用户错误信任。
  2. 容易被用于越狱。
  3. 多语言场景可能翻车。

36. 怎么压缩太长的 Prompt？

考察点：解决上下文超长问题的实战能力。
答案：按优先级操作：
1. 历史消息摘要：将旧轮次对话压缩为摘要。
2. RAG 化静态背景：将“产品介绍”、“政策”等长文本移出 Prompt，按需检索。
3. 缩写约定：在 System Prompt 中定义领域缩写。
4. Prompt Caching：让重复部分“免费”。

37. 什么时候不调 Prompt，直接微调？

考察点：对 Prompt 工程与微调适用边界的判断。
答案：
场景 Prompt 微调
输出格式固定且复杂 ❌ ✅
内化大量企业内部知识 ❌ (或RAG) ✅
高频调用，想压缩成本 — ✅
业务规则频繁变更 ✅ ❌
训练数据少 (< 200条) ✅ ❌
一句话：业务规则变得快、数据少 → Prompt/RAG；业务规则稳定、数据多、调用量大 → 微调。

场景	Prompt	微调
输出格式固定且复杂	❌	✅
内化大量企业内部知识	❌ (或RAG)	✅
高频调用，想压缩成本	—	✅
业务规则频繁变更	✅	❌
训练数据少 (< 200条)	✅	❌

38. Self-Consistency 和 Tree of Thoughts 是什么？

考察点：对高级推理技术的了解。
答案：
- Self-Consistency：让模型对同一问题做多次 CoT，通过投票选出最终答案。能提升复杂推理的准确率。
- Tree of Thoughts：让模型探索多个推理分支，形成树状结构，再从中选出最优路径。
代价：两者都极其消耗 Token，工程上仅用于评估或关键决策点。

39. Prompt 工程会不会被淘汰？

考察点：对岗位发展趋势的思考。
答案：不会，但会演化。
- 简单任务的 Prompt 将不再需要精雕细琢。
- 复杂工作流的 Prompt 编排（System、工具描述、Few-shot、输出约束的组合）会变得更加重要。
- “Prompt 工程师”的岗位会被合并到 AI Engineer 中，但“写好 Prompt”将是每个 AI 工程师的基本功。

40. 给一个真实场景：让模型把用户聊天记录里的退款诉求抽取成结构化 JSON。

考察点：综合运用 Prompt 工程解决实际问题的能力。

答案：

# 角色
你是一名客服质检专家。

# 任务
从用户和客服的对话中，抽取**退款相关的关键信息**，输出 JSON。
忽略与退款无关的闲聊。

# 输入
<conversation>
{{conversation}}
</conversation>

# 输出格式
```json
{
  "has_refund_request": true | false,
  "order_id": "string | null",
  "refund_reason": "string | null",
  "refund_amount": number | null,
  "agreed_by_agent": true | false | null,
  "evidence_quotes": ["原文片段1", "原文片段2"]
}

约束

不在对话里出现的字段一律返回 null，不要编造。
evidence_quotes 必须是对话原文，不要改写。
只输出 JSON，前后不要任何说明文字。

示例

输入：

用户：我之前买的耳机想退，订单是 A100，没什么问题就是不想要了
客服：可以的，明天处理

输出：
{"has_refund_request": true, "order_id": "A100", "refund_reason": "不想要了", "refund_amount": null, "agreed_by_agent": true, "evidence_quotes": ["想退，订单是 A100", "可以的，明天处理"]}

**追问点睛**：
1.  `evidence_quotes` 强制模型基于原文，**减少幻觉**。
2.  正式场景应升级为 **JSON Schema + Tool Calling**，注释只是兜底方案。

三、AI Agent 架构与设计模式

面试官想确认：你是否具备设计和实现复杂 AI 系统的能力。这是面试中最能拉开差距的章节。

41. 什么是 AI Agent？和普通 LLM 调用的区别？

考察点：对 Agent 核心概念的理解。

答案：Agent = LLM + 工具 + 记忆 + 规划，是一个能自主决策、调用工具、修正错误的闭环系统。

维度	普通 LLM 调用	Agent
控制流	单次问答	循环，直到任务完成
工具	无	有，并能自主选择
状态	无状态	有上下文和记忆
错误处理	失败即退出	自主重试或切换路径
典型任务	翻译、改写、摘要	写代码、跑命令、多步调研

经典例子：让模型“创建一个 React + Vite 项目”，普通模型只告诉你命令；Cursor 这类 Agent 会自己执行命令、看报错、修改文件，这才是 Agent。

42. ReAct Agent 怎么实现的？给个最小可运行骨架。

考察点：对 Agent 核心循环的实现能力。

答案：

def run_agent(user_input, tools, max_steps=10):
    history = [{"role": "system", "content": SYSTEM_PROMPT}]
    history.append({"role": "user", "content": user_input})

    for step in range(max_steps):
        # 1. 调用模型，传入工具定义
        resp = llm.chat(messages=history, tools=tools)
        msg = resp.choices[0].message
        history.append(msg)

        # 2. 判断是否需要调用工具
        if not msg.tool_calls:
            return msg.content  # 没有工具调用，直接返回最终答案

        # 3. 执行工具调用
        for call in msg.tool_calls:
            result = tool_registry[call.name](**call.arguments)
            history.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": str(result)
            })

    raise RuntimeError("达到最大步数仍未完成")

关键点：
1. LLM 自主决定“调工具”还是“给答案”。
2. 工具结果必须作为 ToolMessage 塞回 History。
3. 必须有 max_steps 防止死循环。
4. 工具的 schema 和 description 是模型理解的唯一依据。

43. Plan-and-Execute Agent 和 ReAct 的区别？

考察点：对不同 Agent 架构模式的了解。
答案：
- ReAct：边想边做。优点是灵活，缺点是一旦中间判断失误，容易“跑偏”。
- Plan-and-Execute：先一次性生成完整计划，再按步骤执行，必要时可回头修改计划。优点是路径稳定，缺点是对长程任务的一次性规划可能不周全。
工程实践：通常采用混合模式：先通过 Plan 生成粗粒度的大步骤，在每个大步骤内部，用 ReAct 循环来灵活执行。

44. Agent Loop 在工程里有哪些常见坑？

考察点：对 Agent 生产环境风险的认知。
答案：跑过 Agent 的人都被这些坑过：
1. 死循环/振荡：反复调用同一工具或在两个工具间横跳。
2. Token 烧得飞快：每轮都携带全量上下文。
3. 错误放大：早期的一个小误解被后续步骤无限放大。
4. 越权风险：模型可能调用危险工具（如 rm -rf）。
5. 不会停止：缺乏终止条件，永远在“再确认一下”。
硬性兜底：
1. 设硬上限：max_steps, max_tokens, max_duration。
2. 重复检测：同一工具同一参数连续调用 N 次即停止。
3. 工具白名单 + 危险操作二次确认。
4. 全链路日志：每步操作都落盘，便于事后回放。

45. Agent 怎么自己判断"任务完成了"？

考察点：对 Agent 终止条件的理解。

46. 单 Agent vs 多 Agent 怎么选？

考察点：对 Agent 架构复杂度的把控能力。
答案：复杂 Agent 产品基本都是多 Agent 架构。原因：
1. 决策准确率更高：每个子 Agent 只处理自己的专业领域，不受无关信息干扰。
2. Token 更省：不是每次都把所有工具描述塞进去，虽然调用次数变多但单次更便宜。
3. 可并行：主 Agent 派活，子 Agent 可以并发处理。
4. 多角色互相纠错：A 写代码 → B 评审 → C 验证，比单 Agent 自反思更靠谱。
什么时候不要多 Agent？
- 任务简单、步骤少、用户期望秒级响应。
- 团队连单 Agent 都还没跑稳。
类比：Cursor/Claude Code 早期是单 Agent，现在内部分了 Plan、Edit、Verify、Search 多个角色。

47. Reflexion / Self-Reflection 是什么？

考察点：对 Agent 自我改进机制的理解。
答案：让 Agent 跑完一轮后自己评估结果质量，如果不好就调整策略再跑一遍。

简化流程：

1. 跑一遍任务 → 拿到 result_v1
2. 让 LLM 评估 result_v1 的问题 → 拿到 critique
3. 把 critique 注入 Prompt → 再跑 → result_v2

适用场景：复杂推理、代码生成。对延迟敏感的不适合。

48. Agent 怎么处理"用户中途打断"？

考察点：对前端交互与后端协同的理解。
答案：前端必须做三件事：
1. 用 AbortController 取消正在进行的 fetch 请求。
2. 服务端识别到客户端断开后，立刻停止 LLM 调用和工具执行（OpenAI/Anthropic SDK 均支持中断）。
3. 已写入的状态（数据库、文件）要有回滚或标记为中断的机制。
4. 重新拉取对话时，将"被打断的轮次"状态显示给用户，让其决定继续还是重做。

49. Anthropic Agent SDK / Claude Code 这种 Agent 框架做了什么？

考察点：对主流 Agent 框架能力的认知。
答案：它们把 Agent 工程中的"脏活累活"封装成了开箱即用的能力：
- Tool Calling 标准协议：统一的 Schema 定义和错误处理。
- 多步骤循环：自动运行直到任务完成。
- 内置工具集：Read/Write/Edit/Bash/Search/WebFetch。
- 可观测性：每一步的日志、回放、调试能力。
- 权限模型：哪些工具可自动运行、哪些需用户确认。
- 子 Agent/多角色：内置任务分发能力。
建议：重点研究它们的 System Prompt 和工具 Schema，比自己从零写框架更值。

50. LangChain、LangGraph、CrewAI、AutoGen、Vercel AI SDK 选哪个？

考察点：技术选型能力。

答案：按场景选，不问"哪个最好"。

场景	推荐
前端/Next.js 快速做 Chat/流式	Vercel AI SDK
后端 Agent 工作流、链式调用	LangChain
多 Agent + 图编排、复杂路由	LangGraph
多角色协作模拟	CrewAI / AutoGen
低代码/企业内部应用	Dify / Coze / FastGPT

51. Agent 工具描述写不好会怎样？

考察点：对工具描述重要性的理解。
答案：模型理解工具全靠描述文本。写不好直接表现为：
- 该调没调：不知道这个工具能解决当前问题。
- 调错工具：两个工具描述太像，模型混淆。
- 传错参数：Schema 字段名、必填项、枚举值没写清。
- 传冗余参数：描述太长，模型脑补出不存在的字段。

好的工具描述模板：

name: search_user_orders
description: 根据用户 ID 查询该用户最近 30 天的订单列表，
  返回订单 ID、状态、金额。**仅用于查询，不能创建或修改订单**。
parameters:
  user_id (string, required): 用户的唯一 ID，类似 'U-12345'。
  limit (number, optional, default=10): 返回数量，最大 50。

经验：工具超过 15 个就要分组/分层加载，否则选错率飙升。

52. Agent 怎么调试？看哪些指标？

考察点：对 Agent 可观测性的理解。
答案：最少四件套：
1. 每步日志：Prompt + Tool Call + Result 全量落盘，可搜索。
2. 步数分布：均值、P95、超过 N 步的 Trace。
3. Token 消耗分布：哪些工具调用是"耗 Token 大户"。
4. 失败模式聚合：按错误类型聚类，判断是 Prompt 问题、工具问题还是模型问题。
工具推荐：LangSmith（最常用）、Langfuse、Helicone、Phoenix。

53. Human-in-the-loop（HIL）是什么？什么时候必加？

考察点：对 Agent 安全机制的理解。
答案：HIL 是指在 Agent 关键步骤让用户介入决策。
必加场景：
1. 不可逆操作：发邮件、付款、删数据。
2. 金额超阈值：如退款 > 500 元。
3. 跨权限操作：访问其他部门的数据。
4. 法律/合规风险点。
实现方式：Agent 跑到关键节点时，返回一个 pending 状态给前端，展示确认 UI，用户确认后再继续。状态持久化到 DB，断线可恢复。

54. Agent 的成本怎么优化？

考察点：对 Agent 成本结构的理解。
答案：一套组合拳：
1. 小模型分流：简单分类/路由用 7B 小模型，复杂任务才给大模型。
2. Prompt Caching：长 System + 工具描述全部缓存。
3. 工具结果裁剪：返回前砍掉不必要字段，别让模型读完整 SQL 输出。
4. 历史摘要：旧轮次定期压成几句话。
5. 并行调用：能并行的工具调用一定要并行。
6. 缓存层：常见问答先查缓存/向量库，再决定是否调模型。

55. LLM-as-Judge 是什么？

考察点：对模型评估方法的理解。
答案：用一个 LLM 评估另一个 LLM 的输出。
典型场景：
- Prompt 改进的 A/B 测试，让"裁判模型"打分对比。
- Agent 跑完后，判断"任务是否完成"。
- 给数据集打偏好标签，替代人工标注。
注意事项：
- 裁判模型要比被评估模型更强（如用 GPT-4 评判 Claude 3 可行，反过来不行）。
- 明确评估维度（准确性、相关性、格式、礼貌），别只让打个笼统分。
- 跑多个裁判取平均，减少裁判模型本身的偏差。

56. Agent 的延迟（Latency）怎么优化？

考察点：对实时性优化的理解。
答案：影响体感的几个关键动作：
1. Streaming：TTFT 从几秒降到 1 秒内。
2. 并行工具调用：多个工具同时跑而非串行。
3. 小模型预筛 + 大模型精排。
4. 预热/Keep-alive：减少连接建立开销。
5. Prompt Caching 高命中率。
6. 边缘部署/CDN：缩短首跳 RTT。

57. Agent 怎么测？写得了单元测试吗？

考察点：对 AI 系统测试策略的理解。
答案：能写，但要换思路：
- 确定性部分：工具函数、Parser、Router 按普通函数单元测试。
- LLM 调用部分：Mock 掉，或用录制/回放（VCR 模式）。
- 整体端到端：写一组业务测试用例，用 LLM-as-Judge 判通过，统计通过率作为回归指标。
心态：不要追求 100% 通过，AI 系统天然有不确定性，关注趋势——每次改动后通过率是涨还是跌。

58. AutoGPT、BabyAGI、Devin 这类"全自主 Agent"为什么不实用？

考察点：对 Agent 工程现实的理解。
答案：理论很美，工程上一堆问题：
- 目标偏移：开放性任务中模型容易越走越远。
- Token 爆炸：跑几小时花费上千美元。
- 错误传播：早期错误被无限放大。
- 没有 HIL 节点：跑错也没人拦。
- 可观测性差：跑完不知道为什么成功或失败。
教训：生产级 Agent 都是 "半自主 + 有边界 + 有 HIL" 的，绝不是完全放飞。

59. 怎么把现有产品改造成 Agent？

考察点：对 Agent 落地路径的理解。
答案：务实的四步走：
1. 选一个高价值 Workflow（如"客服处理退款"），别一上来就全产品 Agent 化。
2. 梳理所有手动步骤：每一步对应哪个内部接口。
3. 把接口包成 Tool：写好 Schema + 描述。
4. 写严格的 System Prompt：限制 Agent 只在这个 Workflow 内做事。
5. HIL 卡关键节点（涉及钱、不可逆操作）。
6. 小流量灰度：5% → 20% → 50% → 100%，看转化和投诉。

60. 一个 Agent 的"思考预算"应该怎么设？

考察点：对 Agent 资源管理的理解。
答案：三个维度，任一达到上限就优雅终止：
- 最大步数（max_steps）：8-20 是常见范围，超过基本是死循环。
- 最大 Token（max_total_tokens）：按业务复杂度估，如 50k。
- 最大耗时（max_duration）：用户能忍受的上限，通常 60-120 秒。
终止时：返回部分结果 + 明确说明"任务未完成"，不让用户空等。

61. Computer Use Agent 是什么？

考察点：对前沿 Agent 形态的了解。
答案：Anthropic 在 Claude 上开放的能力，模型直接看屏幕截图、移动鼠标、敲键盘，跨任意 GUI 应用操作。
工作流：
1. 客户端截屏给模型。
2. 模型返回 screenshot/mouse_move/mouse_click/key/type 等动作。
3. 客户端执行动作，再截屏。
4. 循环直到任务完成。
适用场景：
- 没有 API 的老软件操作。
- 跨多个软件协作的流程。
- 浏览器自动化（替代 Selenium）。
风险：慢（每步看截图）、贵（截图几千 Token）、安全风险大。
工程策略：优先用 API/MCP，Computer Use 是兜底方案。

62. Agent 评测有哪些常用 Benchmark？

考察点：对 Agent 评估体系的了解。

答案：

Benchmark	测试内容
SWE-bench	真实 GitHub Issue 修复，软件工程能力
GAIA	多步真实世界任务（搜索、计算、推理）
AgentBench	多种工具调用场景
WebArena	浏览器操作能力
OSWorld	桌面 GUI 操作能力
τ-bench	客服/业务流程 Agent

工程实践：通常不直接跑公开 Benchmark，而是自建业务 Case 集 + LLM-as-Judge 做回归测试。

63. Agent 的 Context Engineering 是什么？

考察点：对 2026 年新概念的了解。
答案：Context Engineering 是「精心构造 Agent 每一轮输入」的工程实践，被认为是比 Prompt Engineering 更高维的工作。包括：
- System Prompt 设计
- 工具描述精炼与排序
- 历史压缩/摘要策略
- 检索结果拼接与排版
- 思考预算控制（CoT、Reasoning）
- 格式约束（JSON Schema、XML 标签）
- 动态 Few-shot 示例选择
现实参照：Claude Code、Cursor 内部最复杂的不是模型，而是 Context Engineering。

64. Background Agent 和 Foreground Agent 区别？

考察点：对不同形态 Agent 的理解。
答案：
- Foreground Agent：用户直接对话的 Agent，重 TTFT、重交互、重打断。
- Background Agent：后台运行的 Agent，时长可达几分钟到几小时（如爬数据、跑测试、生成报告）。

工程差异：

维度	Foreground	Background
延迟	关键	不关键
状态	内存/Redis	必须持久化（DB/Checkpoint）
中断恢复	不需要	必须支持
失败重试	用户重发	自动重试
成本上限	较低	必须设预算守门员

65. Agent 的 Tool Selection 怎么优化？

考察点：对工具管理策略的理解。
答案：工具多了模型选错率飙升。优化套路：
1. 静态分组：按业务域分组，先路由再加载工具。
2. 动态加载：用轻量分类器先选 Top 5 工具，再喂主 Agent。
3. MCP Resources/Skills：把工具按粒度分层。
4. 工具描述加例子：模型容易抓"Example 里的关键词"。
5. 工具名加前缀：order_*、user_*、payment_*，命名上分组。
6. 历史命中加权：用户上下文里最近用过的工具优先级提高。

66. Agent 出错后怎么定位？看 Trace 看什么？

考察点：对 Agent Debug 能力的掌握。
答案：Trace 是 Agent 的"飞行记录仪"，按步骤回放：
1. 每步的 Prompt（System + History + Tools）。
2. 模型输出（Tool Calls 或 Final）。
3. 工具执行的入参/出参/耗时。
4. 上下文 Token 用量。
常见排错路径：
- 第一步就跑偏 → System Prompt/工具描述问题。
- 某步工具选错 → 工具描述太相似/排序有问题。
- 工具调对但执行错 → 业务接口 Bug。
- 跑到死循环 → 工具结果格式让模型困惑。
- 过早 Final → 终止条件太宽松。
推荐工具：LangSmith、Langfuse。

67. Agent 怎么做 Retry/Fallback？

考察点：对 Agent 容错机制的理解。
答案：不是简单的 try-catch，要分层处理：
- 工具调用失败：把错误信息塞回 Messages，让模型自己决定下一步。
- 模型超时/限流：客户端指数退避重试，或切到备用模型。
- 整段步数耗尽：保存进度，返回"任务未完成 + 已完成的部分"。
- 格式解析失败：把错误塞回去让模型"自我修复"。
- 检测到死循环：强制中断 + 报警 + 人工兜底。
铁律：不要让 Agent 静默失败，所有失败都要落日志 + 告警。

四、RAG 检索增强生成

面试官想确认：你是否真正做过 RAG 系统，能否讲清"为什么 RAG 比微调更常用"以及"切片/Embedding/检索/重排"四个环节的优化。

68. 什么是 RAG？为什么要发明它？

考察点：对 RAG 核心价值的理解。
答案：RAG = Retrieval-Augmented Generation：用户提问 → 去知识库检索相关片段 → 塞进 Prompt 增强上下文 → 模型基于此生成回答。
为什么需要：
- 模型不知道你公司的内部文档。
- 模型有知识截止日期，最新信息不知道。
- 模型会幻觉，没依据时会瞎编。
- 微调成本高，且对频繁更新的知识不友好。
一句话：RAG 用最便宜的方式，给模型"外挂"了知识库。

69. RAG 标准流程拆解？

考察点：对 RAG 全链路的掌握。
答案：
- 离线（建索引）：
  1. 加载（Loader）：读 PDF/Word/Markdown/Notion/数据库。
  2. 切片（Splitter）：按 Token/段落/语义切成小块。
  3. Embedding：每块算向量。
  4. 入库：向量 + 元数据进向量库。
- 在线（查询）：
  1. Query 预处理：改写、拆解、补全。
  2. 检索：向量召回 + 关键词召回（Hybrid Search）。
  3. 重排（Rerank）：用 Cross-Encoder 重新打分排序。
  4. 拼接：Top-N 片段填入 Prompt。
  5. 生成：LLM 输出回答（带引用）。
关键：90% 的 RAG 问题出在切片和检索环节。

70. 文档怎么切片（Chunking）？什么大小合适？

考察点：对 RAG 中最易出错环节的理解。

答案：

策略	说明	适合
固定 Token	如每 500 Token 切一块	简单粗暴，通用
按段落/标题	按 `\n\n` 或 `#` 切	Markdown/结构化文档
递归切分	大→小，多级 Fallback	LangChain 默认
语义切分	按句子向量相似度切	长文，效果好但慢
Late Chunking	先 Embedding 整段再切	新方法，召回更好

切片大小：
- 太小（< 100 Token）：语义不完整，召回散。
- 太大（> 1000 Token）：召回准但浪费 Token。
- 常用值：300-600 Token + 50-100 Overlap。

71. Embedding 模型怎么选？

考察点：对 Embedding 模型选型的理解。
答案：按场景选：
- 中文场景：bge-m3、Qwen-embedding、jina-zh。
- 英文/多语言：text-embedding-3-large、bge-large-en。
- 私有化：bge、m3e（开源，可自部署）。
- 资源紧/维度敏感：bge-small（384 维）。
易错点：
- 一份索引必须绑定一个 Embedding 模型，换模型要全量重建。
- 维度越高存储和检索越贵，1024/1536 是甜点。
- Query 和 Document 用同一个模型，且 Query 端常需加前缀（如 Query:...）。

72. 向量数据库怎么选？

考察点：对向量数据库选型的理解。

答案：

场景	推荐
已有 PostgreSQL，量不大	pgvector
中量，快速上手	Chroma（本地/内存）
中大型，高性能	Qdrant、Weaviate
大型，企业级，国内开源	Milvus（生态最全）
Serverless 托管	Pinecone、Vercel Vector
已有 ES 集群	Elasticsearch dense_vector

原则：别一上来就上 Milvus，小规模时 pgvector 完全够用，运维成本低一个数量级。

73. 检索召回准不准？怎么改进？

考察点：对检索质量优化的理解。
答案：如果用户问 X 但召回的都是 Y，按顺序排查：
1. 切片是否合理（最常见根因）。
2. Embedding 模型是否适合中文/业务领域。
3. Query 改写：将口语化 Query 改写为更标准的检索 Query。
4. 加入 BM25/关键词召回做 Hybrid：向量擅长语义，BM25 擅长精确词。
5. Reranker 重排：召回 50 条 → 重排 Top 5 → 塞 Prompt。
6. 元数据过滤：按部门/时间/文档类型先过滤再检索。
7. 检查文档本身：很多时候是文档质量差，不是 RAG 不行。

74. 什么是 Hybrid Search（混合检索）？

考察点：对检索策略的理解。
答案：向量检索 + 关键词检索（BM25/Elasticsearch）两路同时召回，再合并打分。
为什么有效：
- 向量召回擅长语义相似但用词不同（"忘记密码" ↔ "登录不上"）。
- BM25 擅长精确匹配（产品编号、报错代码、专有名词）。
合并算法：常用 RRF（Reciprocal Rank Fusion），简单稳定。

75. Reranker 是什么？为什么向量召回还不够？

考察点：对重排环节价值的理解。
答案：
- 向量召回用的是 Bi-encoder：Query 和 Doc 各自编码后比相似度，速度快但精度有限。
- Reranker 是 Cross-encoder：把 Query 和 Doc 拼起来一起进模型，输出相关性分数。精度高，但每对都要算一次，慢。
工程标准做法：
1. 向量召回 30-100 条候选。
2. Reranker 重排选 Top 5-10。
3. 把 Top 拼进 Prompt。
常用模型：bge-reranker、Cohere Rerank、Jina Reranker。

76. 什么是 GraphRAG / Agentic RAG？

考察点：对 RAG 进阶方向的了解。
答案：
- GraphRAG：把文档抽取成「实体+关系」的知识图谱，回答时不仅检索片段还检索实体关系。适合"涉及人物/公司/关系网络"的复杂问答。微软研究院主推。
- Agentic RAG：用 Agent 来驱动 RAG，模型自己决定要不要查、查几次、查完够不够、要不要再查。适合多跳推理（A→找B→再查C）。LangGraph 的图编排天然支持。

77. RAG 怎么评估效果？

考察点：对 RAG 评估体系的理解。
答案：最少四个指标：
1. 召回率（Recall）：理应被检索到的片段，实际召回了多少。
2. 精确率（Precision）：检索到的片段里有多少真正相关。
3. 回答正确率：用 LLM-as-Judge 判断回答是否准确（需 Ground-truth 集合）。
4. 引用准确率：回答里引的片段是否真正支持该回答。
工具：RAGAS（最常见）、TruLens、DeepEval。

78. RAG 中怎么减少幻觉？

考察点：对 RAG 场景下幻觉治理的理解。
答案：RAG 不会自动消除幻觉，需要工程手段：
1. 强制要求引用：每个事实必须用 [片段编号] 注明出处。
2. 拒答提示：如果检索片段中没有相关内容，必须回答"不知道"。
3. 后置校验：用第二个 LLM 检查引用是否真的支持回答。
4. 检索阈值：相似度低于 X 的片段不参与生成。
5. Self-RAG/反思 RAG：模型先判断需不需要检索，再判断检索结果够不够。

79. 长文档怎么处理？

考察点：对长文档 RAG 策略的理解。
答案：几个套路：
1. 层次摘要：每章/每节先做摘要，问答时先用摘要定位章节，再下钻到具体片段。
2. 结构化目录：把目录抽出来当索引，先定位章节再精检索。
3. 多粒度索引：句子级 + 段落级 + 章节级都建索引，按问题类型选。
4. 元数据驱动：用文档类型/章节/日期等元数据缩小检索范围。
5. 超长上下文模型补刀：定位到某一章后，把整章塞进 200k 上下文一次性问。

80. RAG 的 Prompt 模板长什么样？

考察点：对 RAG Prompt 设计的掌握。

答案：

你是一名 [角色]，根据以下检索到的资料回答用户问题。

# 规则
1. 仅基于下面的资料回答，资料里没有的内容请回答"我不确定"。
2. 每个事实都要标注引用编号，如 [1]、[2]。
3. 如果资料之间有冲突，请同时列出并说明。

# 资料
[1] {{chunk_1}}
[2] {{chunk_2}}
[3] {{chunk_3}}

# 用户问题
{{question}}

# 输出格式
回答：...
引用：[1], [2]

记住三点：强约束、强引用、强拒答。

81. 长上下文模型出来后 RAG 还需要吗？

考察点：对 RAG 与长上下文关系的判断。
答案：需要，原因如下：
- 成本：1M 上下文一次几美元，RAG 一次几分钱。
- 延迟：长上下文 TTFT 慢得多。
- 效果：Lost in the Middle，关键信息不一定能用上。
- 可解释性：RAG 能告诉用户"答案出自哪个文档"，长上下文做不到。
- 数据范围：企业知识动辄 GB/TB 级，根本塞不进任何上下文。
结论：长上下文是 RAG 的互补，不是替代。

82. RAG 的离线评估和在线评估区别？

考察点：对评估体系的理解。
答案：
- 离线：准备标注好的 Query + 期望答案，每次迭代跑全量。便宜、可重复。
- 在线：用真实用户流量看转化率、点踩率、停留时间、追问率。贵但真实。
标准做法：离线主导迭代 + 在线小流量验证 + 用户反馈回灌。

83. Contextual Retrieval 是什么？

考察点：对 Anthropic 检索增强技巧的了解。
答案：Anthropic 2024 年推出的技巧。核心：切片之前，先用 LLM 给每个 Chunk 加一段「上下文说明」，交代它在原文中的位置和关系。
例子：
- 原 Chunk："上一财年净利润同比下降 3.4%。"
- 加上下文："以下内容来自 ABC 公司 2025 年 Q4 财报中关于经营业绩的章节：上一财年净利润同比下降 3.4%。"
效果：召回率显著提升（论文称 +35%-50%）。代价是预处理多调一次 LLM，靠 Prompt Caching 压成本。适合碎片化文档/简短切片的场景。

84. 父子切片（Parent-Child Chunking）是什么？

考察点：对高级切片策略的理解。
答案：核心矛盾是：小切片召回不准，大切片占 Token。
做法：
- 小 Chunk 用于检索（如 200 Token，语义精确）。
- 大 Chunk 用于喂模型（如 800 Token，上下文完整）。
- 每个 Small Chunk 有 parent_id 指向 Large Chunk。
流程：Query 召回 Small Chunks → 找它们的 Parent → 用 Parent 内容喂模型。
效果：召回更准、上下文更全，生产 RAG 常用套路。

85. 多向量检索（Multi-Vector Retrieval）是什么？

考察点：对进阶检索策略的了解。
答案：一个 Chunk 不止存一个向量，而是存多个：
- 原文向量。
- 用 LLM 生成的"假设问题"向量。
- 摘要向量。
- 关键词向量。
检索时：这些向量都参与召回，最后合并去重。
好处：用户问题和文档表述不一致时，"假设问题"能命中；长文档的多角度都能覆盖。
代价：存储多倍 + 入库慢，适合关键文档。

86. ColBERT 和 Dense Retrieval 区别？

考察点：对检索模型演进的了解。
答案：
- Dense Retrieval（普通向量检索）：Query 和 Doc 各压成 1 个向量，比相似度。
- ColBERT：Query 和 Doc 都保留每个 Token 的向量，检索时做 Token 级别的匹配（MaxSim）。
ColBERT 优势：召回精度更高（Token 级匹配能抓细节），比 Cross-encoder 重排快很多。
劣势：存储成本几十倍上升，索引复杂，工程实现少。
选型：精度 > 速度 → Cross-encoder Rerank；速度 + 中精度 → ColBERT；速度 + 低成本 → Dense。

87. RAG 的"幻觉引用"怎么处理？

考察点：对 RAG 输出质量控制的理解。
答案：模型可能引用根本不在召回片段里的内容。两步处理：
1. 结构化输出强约束引用：每个事实必须带 [N] 编号。
2. 后置校验：用代码/第二个 LLM 检查引用编号对应的 Chunk 是否真的支持该事实。
校验失败处理：
- 软：标红显示"此条未找到出处"。
- 硬：直接删掉无引用的句子。
铁律：不要相信"已经在 Prompt 里要求带引用"，模型还是会编。

88. RAG 的索引更新策略？

考察点：对 RAG 运维的理解。

答案：

策略	说明	适合
全量重建	定期（每天/每周）完全重新算	文档变化不频繁
增量更新	监听 Webhook，文档变了就更新对应 Chunk	文档变化快
软删除	标记 deleted，检索时过滤	频繁删除
版本化	每篇文档保留多个版本，按时间查	法规/历史溯源

工程要点：
- Chunk 必须有 doc_id 元数据。
- 删除/更新走异步队列，不阻塞业务写。
- 检索时按 valid=true 过滤。
- 大量更新后跑回归测试，召回质量可能波动。

89. RAG 的"冷启动"问题怎么解？

考察点：对 RAG 初期困境的理解。
答案：新业务文档少，用户问的超纲，回答质量差。
解法：
1. 承认局限：拒答 + 转人工，比瞎答好。
2. FAQ 补齐：让运营手写常见问题+答案，直接进知识库。
3. 从客服日志/历史工单蒸馏：把已答问答对入库。
4. 联网检索兜底：库里没有的允许走搜索 API。
5. 缩小用户期望：UI 文案明确"我能回答 XX 类问题"。

90. RAG 的"重排"什么时候必须做？

考察点：对 Reranker 价值的判断。
答案：以下情况几乎必加 Reranker：
- 召回 Top-K 中相关度参差不齐。
- 业务专有名词多（产品编号、报错码）。
- 多语言混合。
- 文档质量不均。
- 用户问题口语化严重。
跳过 Reranker 的代价：召回的 Chunk 顺序差 → LLM 看到 Prompt 时把"无关 Chunk"也当事实 → 幻觉。多花 200ms 一次重排，省一堆幻觉。

五、Function Calling / 工具调用 / MCP

面试官想确认：你是否真正写过 Agent，能讲清 Function Calling 的完整流程和 MCP 解决的问题。

91. Function Calling 是什么？背后的机制？

考察点：对 Function Calling 本质的理解。
模型不会直接执行任何函数。它的工作是：
1. 收到 Prompt 和工具列表（含 name/description/parameters schema）。
2. 模型判断该调用哪个工具、参数是什么，以 JSON 形式吐出来；
3. 你的代码读到这个 JSON → 实际执行函数 → 把返回值拼成 ToolMessage 喂回模型；
  4.模型基于新结果继续决策。
本质上 Function Calling = 模型负责"决策 + 参数生成"，你的代码负责"执行 + 反馈"。
好的，从第92题继续。

92. Function Calling 一次完整流程？

考察点：对 Function Calling 调用链路的掌握。

答案：

tools = [{
  "name": "get_weather",
  "description": "查询某城市当前天气，返回温度和天气状况。",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "城市名，如'北京'"}
    },
    "required": ["city"]
  }
}]

messages = [{"role": "user", "content": "北京今天天气怎么样？"}]

# 第一次调用：模型决定调工具
resp = llm.chat(messages, tools=tools)

if resp.tool_calls:
    for call in resp.tool_calls:
        result = TOOLS[call.name](**call.arguments)
        messages.append(resp.message)
        messages.append({
          "role": "tool",
          "tool_call_id": call.id,
          "content": str(result)
        })

# 第二次调用：模型基于工具结果继续
final = llm.chat(messages)
print(final.content)  # 北京今天 26 度，晴

要点：
- 同一次回答可能返回多个 tool_calls（可并行执行）。
- tool_call_id 必须对得上，否则模型会困惑。
- 工具执行失败也要把错误塞回去，让模型自己决定（重试/换工具/报错）。

93. 工具描述写得好不好直接决定调用准不准？

考察点：对工具描述重要性的深入理解。
答案：模型理解工具只靠 description + parameters schema。写不好会出三类问题：
1. 该调没调：描述模糊，模型没意识到这个工具能解决。
2. 调错工具：两个工具描述相似，模型抓阄。
3. 参数错：字段名/必填/枚举值/单位没说清。
实战经验：
- 描述写"能做什么" + "不能做什么" + "典型用法"。
- 参数字段加取值范围、单位、格式、示例。
- 必填字段在 description 里再强调一遍 "Required"。
- 工具超过 15 个就分组加载，不要全部塞 System。

94. Function Calling 和 JSON Mode 有什么区别？

考察点：对两种结构化输出方式的区分。

答案：

维度	JSON Mode	Function Calling
目的	让输出是合法 JSON	让输出符合特定函数 Schema
用法	一个布尔开关	定义 Tools 列表
严格度	只保证合法 JSON	保证字段/类型/必填
适合场景	自由 Schema 输出	精确控制结构
是否触发调用流程	不会	会进入 Tool Calls 循环

选型：需要结构化输出但不需要后续调函数，用 Structured Output/JSON Schema 即可，不用走完整 Tool Calling 循环。

95. 多个工具同时调用怎么管？

考察点：对工具并行调用的理解。
答案：现代模型（GPT-4o/Claude/DeepSeek-V3）一次可返回多个 tool_calls。
工程上：
1. 检查是否可并行：纯读/无依赖的工具直接用 Promise.all 并发。
2. 有依赖的串行：比如"先查订单再退款"，必须等订单查完。
3. 合并结果：所有结果都加进 Messages 后再调下一轮 LLM。
4. 失败处理：单个工具失败不影响其他，把失败信息也塞回去让模型决定。

96. 工具调用失败怎么处理？

考察点：对工具容错机制的理解。

答案：不要直接 throw 给 Agent 框架。统一格式塞回去：

try:
    result = tools[call.name](**call.arguments)
    content = json.dumps({"success": True, "data": result})
except ValidationError as e:
    content = json.dumps({"success": False, "error": "invalid_params", "msg": str(e)})
except TimeoutError:
    content = json.dumps({"success": False, "error": "timeout"})
except Exception as e:
    content = json.dumps({"success": False, "error": "internal", "msg": str(e)})

让模型看到错误后自己决定：重试（改参数）、换工具、或跟用户解释。

97. 工具结果太大怎么办？

考察点：对上下文爆炸问题的处理。
答案：工具返回 50k Token 直接塞回 LLM 就炸了。常见做法：
1. 裁剪：只取前 N 行/关键字段。
2. 摘要：用小模型把结果摘成 1k Token 以内。
3. 分页：让模型自己决定要不要看后面几页。
4. 存档+引用：完整结果存对象存储，工具返回引用 ID，需要详情时再取。
5. 结构化裁剪：根据请求里的字段筛选返回内容。

98. 工具调用的"幂等性"为什么重要？

考察点：对 Agent 安全性的理解。
答案：Agent 有时会重试/重复调同一个工具。如果不是幂等的：
- 重复扣款。
- 重复发短信。
- 重复创建订单。
要做的事：
- 写操作必须支持 idempotency_key（前端生成 UUID 传给工具）。
- 服务端用这个 key 做去重。
- 危险操作（删除/转账）走 HIL，让用户确认。

99. MCP 是什么？为什么需要它？

考察点：对 MCP 协议核心价值的理解。
答案：MCP = Model Context Protocol（模型上下文协议），由 Anthropic 提出，OpenAI/Google 等陆续支持。
要解决的问题：Function Calling 没有跨厂商/跨进程/跨语言的标准协议。每个厂商自己定义格式，Python 写的工具和 Node 写的得分别适配。
MCP 的解法：把这件事协议化：
- 工具方实现 MCP Server（什么语言都行，按协议跑）。
- 客户端（Claude Code/Cursor/自研 Agent）通过 MCP 协议连接 Server。
- 协议规定了 list_tools、call_tool、list_resources、list_prompts 等标准接口（底层基于 JSON-RPC）。
效果：写一次工具，所有支持 MCP 的客户端都能用。

100. MCP 的三层核心结构（Server / Client / Bridge）

考察点：对 MCP 架构的掌握。
答案：按三角色记：
- Server（工具服务端）：提供一组可用的 Tools/Resources/Prompts（如文件读写、数据库、HTTP 请求）。
- Client（模型/IDE/Agent）：通过协议访问 Server，把工具能力暴露给 LLM。
- Bridge（中间层）：负责协议转发、权限校验、上下文同步、日志审计。Claude Code/Cursor 自身就充当 Bridge。

调用链路：

LLM → Function Calling → MCP Client → (Bridge) → MCP Server → 真实外部资源

工程上：Server 由工具方独立维护，Client 由 Agent 框架实现，Bridge 决定了"哪些工具能被哪个用户/哪个会话调用"，是企业级权限和审计的关键点。

101. MCP 和 Function Calling 是替代关系吗？

考察点：对两者关系的判断。
答案：不是替代关系。
- Function Calling 是模型理解工具的方式（Schema → JSON 调用）。
- MCP 是工具进程间通信的协议（stdio/HTTP/SSE）。
关系：模型还是用 Function Calling 调工具，只是工具的实现可以放在另一个 MCP Server 里，跨语言、跨进程、跨机器。
类比：HTTP 和 RESTful——HTTP 是协议，RESTful 是风格。MCP 让"工具的封装"也变得跨生态可复用。

102. Function Calling vs MCP 全维度对比

考察点：对两者差异的系统性理解。

答案：

维度	Function Calling	MCP
定义者	OpenAI（2023）	Anthropic（2024，事实标准）
核心目标	模型调用外部函数	模型与外部环境标准化交互
注册方式	静态注册（请求时塞 Tools 列表）	动态发现/热加载
协议层	SDK 私有格式	JSON-RPC（任意语言）
工具描述	每次请求都拼进 System，Token 暴涨	Client 启动时拉一次，可复用
安全机制	完全靠开发者自管	协议内建权限 + Bridge 兜底
跨语言/跨进程	受 SDK 限制	任意语言 + 跨进程
工具结果中转	必须人工塞回 Messages	协议直接返回
适合场景	单 Agent 单语言、简单工具	多 Agent 协作/IDE 集成/系统级控制

一句话：Function Calling 是模型协议，MCP 是生态协议。前者解决"模型怎么调函数"，后者解决"函数怎么跨边界提供给模型"。

103. MCP Server 一般怎么实现？

考察点：对 MCP 实现的理解。

答案：最小 MCP Server（TypeScript）：

import { Server } from '@modelcontextprotocol/sdk/server/index.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'

const server = new Server({ name: 'demo', version: '0.0.1' }, { capabilities: { tools: {} } })

server.setRequestHandler({ method: 'tools/list' }, async () => ({
  tools: [{
    name: 'echo',
    description: '把输入原样返回',
    inputSchema: {
      type: 'object',
      properties: { text: { type: 'string' } },
      required: ['text']
    }
  }]
}))

server.setRequestHandler({ method: 'tools/call' }, async ({ params }) => {
  if (params.name === 'echo') {
    return { content: [{ type: 'text', text: params.arguments.text }] }
  }
  throw new Error('unknown tool')
})

const transport = new StdioServerTransport()
await server.connect(transport)

跑起来后在 Claude Code/Cursor 的配置里注册 → 模型就能调你的工具。

104. MCP 三种传输方式（stdio / HTTP / SSE）怎么选？

考察点：对 MCP 传输协议的理解。
答案：
- stdio：通过子进程的标准输入输出通信。简单可靠，本地/Claude Code/Cursor 默认。
- HTTP：远程服务的常规调用，无状态。
- SSE：HTTP + 服务端推送，支持长连接/流式工具。
工程上 90% 选 stdio。需要远程共享/跨机器才上 HTTP/SSE。

105. MCP 和 LangChain Tool 怎么共存？

考察点：对技术栈整合的理解。
答案：实战做法：
- 团队内部工具用 MCP Server 写，跨多个 Agent 客户端复用。
- LangChain 项目里装 @langchain/mcp 或类似适配器，把 MCP Server 自动转换成 LangChain Tool。
- 反向也成立：LangChain Tool 也可以包成 MCP Server 暴露给外部客户端。
趋势：MCP 正在成为事实协议，LangChain 不会消失但会从"封装一切"变成"和 MCP 互通"。

106. 工具调用的 Token 怎么算？

考察点：对工具调用成本的了解。
答案：容易被忽略的几个计费点：
- 工具描述本身计费：所有工具的 description + parameters 都拼进 System，每次调用都计费。
- tool_call 输出：模型吐的 JSON 算 Output Token。
- tool_result 输入：你回填的结果算 Input Token。
- 多轮调用：每轮所有历史都重新计费（除非命中 Prompt Caching）。
优化：工具描述精炼、结果裁剪、用 Prompt Caching、按需加载工具。

107. 工具权限/越权怎么控制？

考察点：对 Agent 安全的理解。
答案：模型本身没有权限概念，全靠你的代码兜底。至少做这几层：
1. 工具白名单：当前会话/当前用户能看到哪些工具。
2. 参数校验：执行前用 Zod/JSON Schema 校验，类型不对直接拒。
3. 数据范围隔离：工具内部根据 user_id 限定能查/写的数据范围。
4. 危险操作 HIL：删除、转账、对外发消息都走人工确认。
5. 审计日志：每次工具调用记录 who/when/what。
铁律：不要相信"模型不会调危险工具"，要假设它一定会调。

108. 工具集合怎么管理（工具一多模型选错）？

考察点：对大规模工具管理的理解。
答案：工具超过 10-15 个时模型选错率明显上升。常见策略：
1. 分组：按业务域分组（订单组、商品组、用户组），用户问题先路由到组。
2. 动态加载：根据用户问题用轻量分类器选出 Top 3-5 个工具，再传给主 Agent。
3. 多 Agent 分工：每个子 Agent 只看自己负责的工具。
4. MCP Resources/Prompts：把工具按粒度分层。

109. Skills 和 Function Calling 是什么关系？

考察点：对 Anthropic Skills 概念的理解。
答案：Anthropic 提出的 Skills（技能）是更高一层的封装：
- 一个 Skill 包含：一组工具 + 配套 Prompt + 示例 + 触发条件。
- 模型按用户意图自动加载对应的 Skill。
- 让 Agent 能力可以像插件一样发布、共享、复用。
一句话：Function Calling 是单工具，Skill 是工具 + Prompt 的组合包。

110. 工具调用的"自描述"为什么重要？

考察点：对工具 Schema 设计的理解。
答案：工具的 Schema 是模型理解工具的唯一信息源。模型看不到你的代码，只看 description + parameters。
- 自描述好 = 描述清楚 + 字段有约束 + 示例齐全。
- 不自描述（如 description: "do thing"）= 模型只能瞎调。

111. 一个常被问的场景：让 Agent 自动写代码并跑测试，应该怎么设计工具集？

考察点：对 Agent 工具设计的综合能力。

答案：最小工具集：

- list_directory(path): 看目录结构
- read_file(path): 读文件
- write_file(path, content): 写文件
- edit_file(path, old, new): 局部修改
- run_command(cmd): 执行命令
- search_code(pattern): 搜代码

关键设计：
- edit_file 比 write_file 更安全，全量重写容易丢东西。
- run_command 必须做白名单，禁止 rm -rf、sudo 等。
- 写文件必须先 read 再 write，避免误覆盖。
- 每次工具调用都打日志，便于回放。
这就是 Cursor/Claude Code 内部的最小工具集形态。

112. 同一个 LLM 既给前端又给 Agent 用，工具怎么设计？

考察点：对系统分层设计的理解。
答案：抽两层：
- 底层业务接口：纯后端，保持原样不要污染。
- AI 工具层：在业务接口外面套一层封装，做参数转换、权限收敛、错误格式化、结果裁剪。
不要直接把后端接口暴露给 Agent，否则：
- 权限漏。
- 错误信息泄露内部细节。
- 返回数据太大。
- 参数命名前后端不一致让模型困惑。

113. Anthropic Skills 是什么？和 MCP 什么关系？

考察点：对 Skills 与 MCP 关系的理解。
答案：Skills 是 Anthropic 提的 Agent 能力封装单元，比 MCP Tool 高一层。
- 一个 Skill 包含：能力描述、一组工具、Prompt 模板/示例、触发条件。
- 类比：MCP Tool 是函数，Skill 是「函数 + 调用手册 + 触发器」打包。
Claude Code 的 .claude/skills/ 目录就是 Skills 的物理形态，每个 Skill 一个 Markdown + 配套脚本。

114. MCP 的 Resources、Tools、Prompts 三种能力区别？

考察点：对 MCP 三种能力类型的理解。
答案：MCP Server 能暴露三类东西：
类型是什么例子
Tools 模型主动调的函数 read_file、run_sql
Resources 模型可以读的"资料" README、Schema、配置
Prompts 预设的 Prompt 模板 "用 X 风格生成 Y"
工程区别：
- Tools 由模型决定何时调，Resources 由 Client 决定何时读。
- Resources 不消耗工具调用预算，但占 Context。
- Prompts 让用户能"选择 Prompt 模板"而不是手敲。
实战：90% 用 Tools，Resources/Prompts 用得少但很有用。

类型	是什么	例子
Tools	模型主动调的函数	read_file、run_sql
Resources	模型可以读的"资料"	README、Schema、配置
Prompts	预设的 Prompt 模板	"用 X 风格生成 Y"

115. MCP 有哪些常见的安全风险？

考察点：对 MCP 安全的理解。
答案：工具被模型自动调，安全模型必须有：
1. 凭据泄露：MCP Server 持有 API Key/DB 密码，被 Prompt Injection 套出来。
2. 越权：Server 给所有 Client 看同样工具，租户隔离没做好。
3. 数据泄露：Resources 暴露了不该看的文件。
4. 危险操作：模型自动 rm -rf、删数据库。
5. 供应链攻击：第三方 MCP Server 里有恶意代码。
防御：
- Bridge 层做权限：哪些用户能调哪些工具。
- 白名单 + 危险操作 HIL。
- 审计日志：每次调用记录 who/when/what。
- 第三方 Server 必须 Review，不要随便装。

116. 常用的 MCP Server 有哪些？

考察点：对 MCP 生态的了解。

答案：2026 年生态已经丰富：

类别	代表 Server
文件/Shell	filesystem、shell、git
数据库	postgres、mysql、sqlite、mongodb
浏览器	puppeteer、playwright、chrome-devtools
搜索	brave、google、tavily
GitHub/GitLab	github、gitlab
协作	slack、notion、linear、jira
设计	figma
监控	sentry、datadog
云服务	aws、gcp、azure

实战流程：能用现成的就用现成的，自研只针对内部业务工具。

117. Computer Use 和 MCP 是什么关系？

考察点：对两种能力的区分。
答案：不是替代，是互补：
- MCP：通过协议调函数，精确、快、成本低。
- Computer Use：模型直接操作屏幕，通用但慢且贵。
工程策略：
1. 优先用 MCP（接 API/SDK 的场景）。
2. 没有 API 的老软件、跨多软件的复杂流程 → Computer Use 兜底。
3. 混用：让 MCP 做主流程，Computer Use 处理零星 GUI 操作。

118. 怎么用 Python 写一个 MCP Server？

考察点：对 MCP 实现的具体掌握。

答案：最小可运行（基于 mcp SDK）：

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("demo")

@mcp.tool()
def add(a: int, b: int) -> int:
    """两数相加。"""
    return a + b

@mcp.tool()
def search_user(name: str) -> dict:
    """按用户名查询用户信息。"""
    return {"name": name, "email": f"{name}@example.com"}

if __name__ == "__main__":
    mcp.run()

Claude Code 配置：

{
  "mcpServers": {
    "demo": {
      "command": "python",
      "args": ["server.py"]
    }
  }
}

启动 Claude Code → 工具自动出现 → 模型能直接调用。

119. Function Calling 在 Agent 框架里的位置？

考察点：对技术栈层次的理解。

答案：容易混淆的三层：

Agent  ← 整个跑循环的框架（决定顺序、错误处理、终止）
 └─ Tool（业务函数封装）
     └─ Function Calling（模型调用 Tool 的协议）
         └─ Model（LLM 本体）

实战：你写代码时直接写 Tools（业务函数），Agent 框架（LangChain/Agent SDK）负责处理 Function Calling 协议和循环。Function Calling 你基本不直接接触。

六、Memory 与上下文管理

面试官想确认：你是否理解 LLM 本质无状态，并能在工程上实现"记忆"——这是 Agent 能否跑长任务的关键。

120. 大模型本身是无状态的，为什么 ChatGPT 能记住上文？

考察点：对"记忆"本质的理解。
答案：因为客户端/服务端帮它把历史 Messages 拼回去了。每次请求都把整段对话历史塞进 Prompt。
本质：模型本身永远在做"看这次输入 → 产生这次输出"。你看到的"记忆"全是外部状态管理。
推论：对话长了会慢、会贵，因为每轮都重新带全量历史。

121. Memory 管理的核心矛盾是什么？

考察点：对 Memory 核心挑战的理解。
答案：上下文窗口是有限的，但对话可能无限长。
解法：做有损压缩：
- 保留近期上下文（精确）。
- 把远期上下文压缩成摘要（粗糙）。
- 把"事实性内容"抽取出来存进结构化记忆/向量库（可检索）。

122. 短期记忆有哪几种实现？各自适合什么？

考察点：对短期记忆策略的掌握。
答案：
1. 全量 Messages：最简单，对话一两轮够用。
2. 滑动窗口：只保留最近 N 轮，超过的丢掉。简单粗暴。
3. 滑动窗口 + 摘要：丢掉前先摘要，最常用。
4. Token 上限驱动：按 Token 数（不是轮数）滚动。
5. 关键消息标注：用户标记的"重要消息"始终保留，其他可丢。

123. 长期记忆怎么做？

考察点：对跨会话记忆的理解。
答案：短期记忆只活在当前会话，长期记忆要跨会话。
常见实现：
1. 结构化记忆：抽取"用户偏好/历史事件/关键事实"存数据库（user_id → JSON）。
2. 向量记忆：把每段重要对话 Embedding 入向量库，下次检索相关历史拼回 Prompt。
3. 图谱记忆：实体+关系存图数据库（Neo4j），适合"人物关系/项目关系"。
4. 文件/文档：让 Agent 把"学到的东西"写成 Markdown 文件，下次会话先 Read。
Claude Code 的 Memory 系统就是文件型 + 索引型混合。

124. 滑动窗口的 N 怎么定？

考察点：对窗口大小的经验判断。
答案：经验值：
- 简短闲聊：保留最近 8-12 轮。
- 任务对话：保留最近 5-8 轮。
- 长任务/编程：按 Token，保留最近 10k-20k Token。
更重要的是：
- 超过 N 时先摘要再丢，别直接扔。
- 关键消息（用户确认过的、Agent 写过文件的）独立保留。

125. 摘要压缩什么时机做？

考察点：对压缩时机的理解。
答案：别等"对话长了再说"，否则用户会卡顿。两种时机：
1. 定时：每 5 轮/每 N 个 Token 就摘要一次（异步）。
2. 触发式：上下文剩余 Token 不足 X 时强制摘要。
3. 结束时：会话结束写一份"长期记忆"入库。
异步摘要的好处：不阻塞主线程，用户感知不到。

126. 摘要丢关键信息怎么办？

考察点：对摘要质量的把控。
答案：工程上几条经验：
1. 抽取式摘要 + 关键事实清单双轨：摘要负责"语义连贯"，事实清单负责"不丢细节"。
2. 强约束 Prompt：明确告诉摘要 LLM "用户确认过的事情、订单号、金额、时间等必须保留"。
3. 多级摘要：粗摘要 + 细摘要，按需取。
4. 关键消息独立保留：不进摘要，永远在 Messages 末尾。

127. 多用户怎么隔离记忆？

考察点：对多租户隔离的理解。
答案：最起码三层：
1. 会话级：session_id 隔离，每个会话独立 Messages。
2. 用户级：user_id 隔离，跨会话的长期记忆只能本人访问。
3. 租户级（ToB）：tenant_id 隔离，企业之间数据完全不可见。
实现要点：
- 向量库查询必须带 Metadata 过滤 user_id == 当前用户。
- 缓存层别误共享：模型缓存/工具缓存如果按 Prompt Key 命中，可能跨用户串数据。
- 审计：所有记忆写入都记录 who + when + what。

128. 用户改主意了，记忆怎么处理？

考察点：对记忆一致性的理解。
答案：例子：用户先说"我要订北京的酒店"，几分钟后改成"算了改去上海"。
工程上：
1. 覆盖式更新：用户最近一次表述优先，旧的标记为 outdated。
2. 冲突检测：定期让 LLM 扫描记忆，发现冲突时提醒用户确认。
3. 版本化：所有记忆带版本号 + 时间戳，回溯也方便。
4. 不要悄悄"合并"：合并意图容易出错，明确"以新为准"。

129. Agent 的"工作记忆"（Working Memory）是什么？

考察点：对工作记忆概念的理解。
答案：工作记忆 = 当前任务正在用的临时变量，区别于：
- 短期记忆（对话历史）。
- 长期记忆（用户偏好/历史事件）。
例子：Agent 正在处理退款流程，工作记忆里临时存"订单号=A100、退款金额=200、客户已同意=true"。任务结束就丢。
实现：用 Dict/Redis 存当前 task_id → state，把工作记忆显式注入 Prompt，让模型每步都能看到。

130. Memory 系统设计有哪几条铁律？

考察点：对 Memory 系统设计的综合理解。
答案：工程上踩过坑总结：
1. 不要把所有 Messages 都送给大模型：超贵且效果反而差。
2. 可读性 > 完整性：摘要是为了让模型理解，不是给人看的。
3. 写入读取分离：写入异步、读取同步。
4. 可观测：能查每段记忆是怎么产生的、用过几次。
5. 可撤销：用户能"清除我的记忆"，符合 GDPR/个保法。

131. 怎么让 Agent 记住"用户偏好"？

考察点：对个性化记忆的理解。
答案：最常见两种：
1. 显式存储：用户说"我以后回答都用中文"，Agent 把这条写入 user_preferences 表，每次 System Prompt 拼回去。
2. 隐式学习：定期扫描历史对话，让 LLM 抽取偏好（"用户喜欢简短回答"、"用户喜欢代码带注释"），更新偏好库。
关键：不要靠"模型自己记住"，模型不持久化任何东西。

132. 记忆系统的隐私和合规怎么做？

考察点：对合规要求的理解。
答案：涉及 PII（个人身份信息）的：
1. 采集前告知 + 同意。
2. 敏感字段加密存储（身份证、手机号、邮箱）。
3. 支持"删除我的所有数据"接口。
4. 支持"导出我的数据"接口。
5. 审计日志：谁访问了我的记忆。
6. 跨境传输合规：用海外模型时要考虑数据出境问题。

133. Memory 演进路线（从 Demo 到生产）？

考察点：对 Memory 系统演进的认知。
答案：四步走：
1. 全量 Messages：能跑就行。
2. 滑动窗口 + 异步摘要：能跑长任务。
3. 向量长期记忆：能跨会话。
4. 图谱/结构化记忆 + 多层级：企业级 Agent。
原则：不要一上来上第 4 步，对中小项目就是过度设计。

134. Claude Code 的 Memory 系统怎么实现的？

考察点：对主流工具 Memory 机制的理解。
答案：Claude Code 的 Memory 是「文件型 + 索引型混合」：
- 每个会话/项目有 memory/ 目录。
- 子目录按类型分：user.md（用户偏好）、feedback.md（修改习惯）、project.md（项目状态）、reference.md（外部资源）。
- 一份 MEMORY.md 索引每个 Entry 的 Title + 1-2 句话。
- 模型按需 Read 索引或具体文件。
设计精髓：
- 可读性强（人能看/改/删）。
- 可版本化（Git 跟踪）。
- 可选读（不像全量 Messages 那样必须带）。
- 支持显式编辑（用户能精准纠错）。
这种"显式可控的 Memory"是 LLM 时代 Memory 系统的主流思路。

135. Episodic Memory vs Semantic Memory 区别？

考察点：对记忆分类的理解。
答案：借自认知科学：
- Episodic（情景）记忆：记得"具体发生过什么事"。例子：用户上次说想退款。
- Semantic（语义）记忆：抽象出来的知识/偏好。例子：用户喜欢简短回答。
Agent 系统里两种都要：
- Episodic 适合当前任务推理（"我和你之前说过 X"）。
- Semantic 适合个性化定制（用户偏好、风格、规则）。
实现：Episodic 用对话历史 + 向量库，Semantic 用结构化 Key-Value。

136. 多 Agent 共享 Memory 怎么设计？

考察点：对多 Agent 协作的理解。
答案：多个子 Agent 协作时，信息传递方式：
1. 共享 State（LangGraph 做法）：所有 Agent 都能读写一个 State 字典。
2. Message Passing：子 Agent 之间发消息，主 Agent 协调。
3. 共享存储 + 锁：Redis/DB 加分布式锁。
4. 事件流（Event Log）：所有 Agent 看同一份事件流，各取所需。
最佳实践：
- 别让所有 Agent 都看全量 Memory，按角色过滤。
- 写入要有"是谁写的"标签，方便追责。
- 多 Agent 并发写要序列化或加锁。

137. Memory 的访问控制（哪些 Agent 能读/能写）？

考察点：对 Memory 安全的理解。
答案：不同 Agent 信任级别不一样。常见做法：
- 角色 = 权限：QA Agent 只读，Edit Agent 可写，Auditor Agent 全只读。
- 白名单：每个工具/Memory 字段都列出允许的 Agent。
- 审计：所有写入记录 actor + reason。
- 回滚：保留写入历史，能 Undo。
ToB 场景这是合规硬要求。

138. 用户偏好 Memory 怎么实战？

考察点：对偏好记忆落地的理解。

答案：最常用方案：

   interface UserPrefs {
      user_id: string
      language: 'zh' | 'en' | 'auto'
      response_style: 'concise' | 'detailed'
      preferred_models: string[]
      custom_instructions: string  // 用户自己写的"对我说话要..."
      topics_of_interest: string[]
}

注入方式：
* 每次 System Prompt 拼一段 ## 用户偏好\n{prefs}。
* 模型回答前能感知。
* 用户能在 UI 上显式编辑这份偏好。
关键：不要让模型"自己猜偏好"，给用户编辑入口才合理。

139. 怎么判断一段记忆该不该写？

考察点：对记忆筛选策略的理解。
答案：不是所有对话都值得长期记忆。判定规则：
- 用户明确说"记住这个"：必写。
- 用户偏好性表达（"我以后都用中文回答"）：必写。
- 关键事实（订单号、地址、ID）：必写。
- 闲聊/重复确认：不写。
- 会过期的状态（"我现在很忙"）：不写或加 TTL。
策略：简单粗暴的"全写"会把记忆库污染。让一个轻量 LLM 做记忆筛选是常见做法。

七、LangChain / LangGraph 框架

面试官想确认：你是否理解 LangChain 解决了什么问题，以及何时该用 LangGraph。能讲清"为什么"比背 API 重要得多。

140. LangChain 是什么？它真正帮你做了什么？

考察点：对 LangChain 核心价值的理解。
答案：LangChain 把"LLM 应用开发的常见动作"封装成可组合的组件：
- Models：统一调多家 LLM 的接口。
- Prompts：模板、变量、Few-shot 管理。
- Output Parsers：把模型输出解析成结构化数据。
- Tools/Toolkits：工具定义 + Function Calling 流程。
- Memory：对话历史/长期记忆封装。
- Retrievers：向量库/RAG 检索抽象。
- Chains/LCEL：把上面这些链式拼起来。
- Agents：常见 Agent 模式（ReAct、Plan-and-Execute 等）。
一句话：它让你不用从零写 Prompt 拼接、工具调度、错误重试这些脏活。

141. LCEL（LangChain Expression Language）是什么？

考察点：对 LangChain 核心语法的理解。

答案：LangChain 的管道语法，用 | 把组件串起来：

const chain = promptTemplate
  .pipe(model)
  .pipe(outputParser)

const result = await chain.invoke({ topic: 'AI' })

好处：
- 写起来像 Unix Pipeline，直观。
- 自动支持 Batch/Stream/Async。
- 容易换组件（换模型只改 .pipe(model)）。
适用边界：LCEL 适合线性流程，分叉/循环/条件就该上 LangGraph。

142. LangGraph 是什么？为什么有了 LangChain 还要它？

考察点：对 LangGraph 定位的理解。
答案：LangChain 的 Chain 是线性管道，无法表达：
- 条件分支（这步成功才走下一步）。
- 循环（不达标就回头）。
- 多 Agent 并行/协作。
- 显式状态管理。
LangGraph 是图编排引擎：节点 = 一个动作（LLM 调用/工具调用/自定义函数），边 = 转移规则。
适合场景：
- 多 Agent 协作。
- Agentic RAG（要不要再查一次）。
- 复杂工作流（审批、订单、客服路径）。
- 显式可视化整个 Agent 流程。

143. 用 LangGraph 写一个最小图怎么写？

考察点：对 LangGraph 基本用法的掌握。

答案：

import { StateGraph, END } from '@langchain/langgraph'

const graph = new StateGraph<{ input: string; output?: string }>({
  channels: { input: null, output: null }
})

graph.addNode('plan', async (state) => ({ output: `planned: ${state.input}` }))
graph.addNode('execute', async (state) => ({ output: `done: ${state.output}` }))

graph.addEdge('plan', 'execute')
graph.addEdge('execute', END)

graph.setEntryPoint('plan')

const app = graph.compile()
const result = await app.invoke({ input: 'hello' })

关键概念：
- State：所有节点共享的状态（合并而非覆盖）。
- Node：一个动作。
- Edge：节点间转移。
- Conditional Edge：根据 State 决定走哪条边。
- Checkpoint：每步状态可存到 DB，支持中断+恢复（HIL 神器）。

144. Runnable 是什么？为什么所有组件都是 Runnable？

考察点：对 LangChain 统一接口的理解。

答案：LangChain 给所有组件定义了一个统一接口 Runnable：

interface Runnable<I, O> {
  invoke(input: I): Promise<O>
  stream(input: I): AsyncIterable<O>
  batch(inputs: I[]): Promise<O[]>
}

任何组件（Prompt、Model、Parser、Tool、Chain）都实现这个接口，所以才能用 | 串起来。
类比：React 的 Component——只要符合接口，就能复用/组合。

145. Output Parser 和 Tool Calling 怎么选？

考察点：对两种解析方式的判断。
答案：
- Output Parser：模型输出文本，你写正则/JSON 解析。适合输出格式相对自由 + 不需要严格 Schema 的场景。
- Tool Calling/Structured Output：模型按 Schema 输出。适合严格 JSON/字段必填/类型检查。
经验：
- 简单解析（提取一段总结、抽几个关键词）→ Output Parser。
- 复杂结构化（多字段、嵌套、必填）→ Tool Calling。
- 流式场景：Output Parser 支持流式增量解析，Tool Calling 通常等完整 JSON。

146. Prompt Template 和写字符串拼接的区别？

考察点：对工程化 Prompt 管理的理解。
答案：字符串拼接看起来够用，但写多了会有：
- 变量散在各处难追踪。
- 多语言/模板复用难。
- 没法自动绑定 Few-shot。
- 没法集成版本管理/灰度。
PromptTemplate 把 Prompt 当一等公民：变量声明清晰、可继承、可序列化、可版本化。

147. LangChain 全部 Splitter，挑哪个用？

考察点：对文本切分器的选型能力。
答案：90% 场景用一个就够：RecursiveCharacterTextSplitter。
- 它会按 \n\n → \n → " " → "" 递归切分，尽量保持段落完整。
其他特殊场景：
- 代码：Language.PYTHON/JS/... 专用 Splitter。
- Markdown：MarkdownHeaderTextSplitter，按标题层级切。
- HTML：HTMLHeaderTextSplitter。
- 语义：SemanticChunker（Embedding 模型驱动，慢但效果好）。

148. 怎么把 LangChain 的链接到 Nest/Next API？

考察点：对后端集成的理解。

答案：Nest 后端最小骨架：

@Controller('chat')
class ChatController {
  @Post('stream')
  async stream(@Body() body: { input: string }, @Res() res: Response) {
    res.setHeader('Content-Type', 'text/event-stream')
    res.setHeader('Cache-Control', 'no-cache')

    const chain = prompt.pipe(model).pipe(parser)
    const stream = await chain.stream({ input: body.input })

    for await (const chunk of stream) {
      res.write(`data: ${JSON.stringify(chunk)}\n\n`)
    }
    res.end()
  }
}

前端用标准的 SSE 模板读就行。

149. LangSmith 是什么？为什么所有 LangChain 项目都建议接？

考察点：对可观测性平台的理解。
答案：LangSmith = LangChain 的可观测平台。

接入：只要加三个环境变量：

LANGCHAIN_TRACING_V2=true
LANGCHAIN_API_KEY=...
LANGCHAIN_PROJECT=my-project

能看什么：
- 每一步的 Prompt、输入、输出。
- 每步 Token、耗时、Cost。
- Agent 的完整调用树。
- 失败 Trace 一键回放。
- 历史调用打 Dataset，跑评估。
铁律：工程上没有可观测 = 没法调优 = 没法上线。强烈建议从第一天就接。

150. LangGraph 的 Checkpoint 怎么用？

考察点：对 LangGraph 核心能力的理解。
答案：Checkpoint 是 LangGraph 的杀手锏：每步状态都能保存到 DB，所以可以：
- 中断后恢复（用户离开几小时后接着跑）。
- HIL（跑到关键节点暂停，等用户确认）。
- 时间旅行（回到之前某一步重新执行）。
- 多用户并行运行不同 Thread。

最简单 Sqlite Checkpoint：

import { SqliteSaver } from '@langchain/langgraph-checkpoint-sqlite'

const checkpointer = SqliteSaver.fromConnString('./checkpoints.db')
const app = graph.compile({ checkpointer })

const config = { configurable: { thread_id: 'user-123' } }
await app.invoke({ input: 'hello' }, config)
// 后面任何时候用同一个 thread_id 都能从上次断点继续

151. LangChain vs LlamaIndex 怎么选？

考察点：对两个框架的选型判断。

答案：

维度	LangChain	LlamaIndex
定位	通用 LLM 应用框架	RAG 专精
强项	Agent、工具调用、链编排	文档加载、索引、检索
学习曲线	偏陡	相对简单
文档生态	庞大	聚焦
适合	复杂 Agent/多步骤工作流	纯 RAG 场景

实战常见组合：LlamaIndex 做索引 + LangChain 做 Agent。两者也都能独立做完所有事。

152. LangChain 内置的 Agent 类型有哪些？怎么选？

考察点：对 Agent 类型的了解。

答案：

Agent 类型	工作方式	适合
ReAct Agent	边想边调工具	通用
OpenAI Functions Agent	用 Function Calling 标准	OpenAI/Claude 系列
Plan-and-Execute	先规划再执行	长程任务
Self-Ask	自问自答分解问题	推理/多跳问答
Structured Chat	多工具结构化输出	工具数量多

2026 年趋势：直接用 Tool Calling Agent（基于模型自带 Function Calling），不用旧的 ReAct Prompt-based Agent。

153. LangGraph 怎么做 Human-in-the-loop？

考察点：对 LangGraph HIL 实现的理解。

答案：LangGraph 用 interrupt + Checkpoint 实现 HIL：

graph.addNode('confirm_payment', async (state) => {
  // 等待用户确认
  return await interrupt({ amount: state.amount, action: 'approve_or_reject' })
})

graph.addConditionalEdges('confirm_payment', (state) => {
  return state.approval === 'yes' ? 'execute' : 'cancel'
})

效果：跑到 confirm_payment 节点时保存当前状态+暂停，前端拿到状态展示给用户确认 → 用户决定 → 用 app.invoke({...}, { resume: 'yes' }) 继续。
适合所有"需要二次确认"的场景（付款、删除、对外发消息）。

154. LangGraph 的多 Agent 模式有哪些？

考察点：对多 Agent 架构模式的了解。

答案：

模式	拓扑	适合
Supervisor	主 Agent 派活，子 Agent 干完汇报	任务可拆解
Network	多 Agent 互相调用	复杂协作
Hierarchical	多层 Supervisor	超大规模
Swarm	Agent 之间 Handoff	客服路由

Supervisor 最常用。Swarm（基于 OpenAI Swarm）适合"客户被不同专家接力服务"的场景。

155. LangChain 的 Memory 类型对比？

考察点：对内置 Memory 的掌握。

答案：

Memory	怎么用	适合
ConversationBufferMemory	全部带	Demo
BufferWindowMemory	最近 N 轮	简单对话
SummaryMemory	用 LLM 摘要	长对话
SummaryBufferMemory	摘要 + 窗口混合	实战首选
VectorStoreMemory	向量检索历史	长期记忆
EntityMemory	抽取实体+关系	用户画像

生产建议：用 SummaryBufferMemory，或者干脆自己写（LangChain Memory 抽象偶尔不够灵活）。

156. Vercel AI SDK 和 LangChain 是什么关系？

考察点：对两个库定位的区分。
答案：
- Vercel AI SDK：前端/Edge/Node 全栈 SDK，主打流式 UI（useChat、useCompletion）、模型抽象（generateText/streamText）、Tool Calling 简化。前端友好，复杂 Agent 弱。
- LangChain：后端 Agent 框架，长链/多 Agent/复杂工作流强。
实战常见组合：
- 前端（Next.js）用 Vercel AI SDK 处理 UI/流式/简单工具。
- 复杂业务后端跑 LangChain/LangGraph Agent，通过 SSE 给前端推结果。
两个其实是不同层，不冲突。

157. LCEL Streaming 怎么实现？

考察点：对流式输出的掌握。

答案：LangChain 所有 Runnable 都自带 .stream()：

const chain = prompt.pipe(model).pipe(new StringOutputParser())

for await (const chunk of await chain.stream({ input: 'hi' })) {
  process.stdout.write(chunk)
}

后端给前端流式（Next.js Route Handler）：

export async function POST(req: Request) {
  const { input } = await req.json()
  const stream = await chain.stream({ input })
  return new Response(stream.pipeThrough(new TextEncoderStream()), {
    headers: { 'Content-Type': 'text/plain' }
  })
}

或者用 Vercel AI SDK 的 LangChainAdapter.toDataStreamResponse(stream) 适配。

158. LangChain 怎么写一个完整 RAG Chain？

考察点：对 RAG 实现的综合掌握。

答案：最小骨架：

import { createRetrievalChain } from 'langchain/chains/retrieval'
import { createStuffDocumentsChain } from 'langchain/chains/combine_documents'

const ragPrompt = ChatPromptTemplate.fromTemplate(`
基于以下检索资料回答问题：
{context}

问题：{input}
`)

const docChain = await createStuffDocumentsChain({ llm: model, prompt: ragPrompt })
const ragChain = await createRetrievalChain({ retriever, combineDocsChain: docChain })

const result = await ragChain.invoke({ input: '什么是 RAG？' })
console.log(result.answer)

复杂场景（重排、Hybrid、HyDE）用 LCEL 拼，或者直接上 LangGraph 写图。

八、模型微调 / 私有化部署 / ToB 落地

面试官想确认：你对模型落地的全链路有认知，知道什么时候该微调、什么时候不该。

159. 大模型在 ToB 业务里落地有哪些核心难点？

考察点：对 ToB 落地挑战的理解。
答案：直接拿通用模型给企业用会撞上这些坑：
- 不懂业务：训练语料是公网通用知识，对企业内部规章、产品文档一无所知。
- 幻觉风险：不知道时不会闭嘴，会"看着像那么回事"地编。
- 数据合规：员工/客户敏感信息不能直接送外部 API。
- 响应慢、单价高：交互密集业务直接调外部模型不友好。
- 可控性差：用户问答风格不符合公司话术。
主流解法：
1. RAG：把企业知识向量化，给模型外挂记忆。
2. 私有化部署：选开源模型（Qwen/DeepSeek/LLaMA）在自己机器上跑。
3. 微调：把客服话术、产品规则训进模型。
4. 工作流编排：Dify/Coze/FastGPT 把 Prompt + RAG + 工具串起来。

160. 模型幻觉的深层原因（再追问版）？

考察点：对幻觉根源的深入理解。
答案：不只是"瞎说"，拆开看：
1. 概率模型的天然倾向：在"算最可能的下一个 Token"，不是"查事实"。
2. 训练语料噪声：互联网真假混杂。
3. 没有事实校验：出结果时不会回头验证。
4. 上下文断裂：检索片段不全时会自动"补缝"。
5. 任务边界模糊：开放性问题模型倾向于"展开发挥"。
减少幻觉是组合拳：RAG + 引用 + 二次校验 + 低温 + 拒答指令。

161. 微调（Fine-tuning）核心是什么？什么时候才该用？

考察点：对微调适用场景的判断。
答案：在已预训练好的模型上用领域数据继续训练，把权重调整到对该领域更敏感。理解成"再上岗培训"，不是"重新培养"。
适合：
- 输出格式/风格特别固定（客服话术、报告模板）。
- 行业术语/知识体系密集（医疗、法律、金融）。
- Prompt 膨胀到不可控，希望把规则"内化"省 Token。
- 闭源场景下本地化部署。
不适合：
- 业务规则会频繁变（每次都重训性价比低）。
- 数据少（< 200 条）。
- 短期内 RAG/Prompt 还能优化。

162. 全参微调 vs PEFT（LoRA / QLoRA）区别？

考察点：对微调技术的掌握。

答案：

维度	Full Fine-tuning	PEFT
训练对象	全部权重	一小部分（增量矩阵）
显存	极高（70B 几百 G）	单卡 24G 也能玩
训练速度	慢	快几倍到十几倍
效果上限	最好	略弱，95% 场景够用
过拟合/灾难性遗忘	容易	影响小
适合	大厂底座	中小团队业务定制

99% 应用层用 PEFT 就够，LoRA/QLoRA 是甜点。

163. LoRA 为什么能省显存？

考察点：对 LoRA 原理的理解。
答案：核心思想：别动原矩阵，旁边加两个小矩阵。
数学上：原权重 W 冻结，新增低秩矩阵 A、B（Rank 通常 8-64），让 W' = W + A·B。训练只更新 A、B（参数量小一两个数量级），推理时把 A·B 合并回去。
收益：
- 显存占用大幅下降。
- 训练速度快几倍。
- 训完只存 A、B（几十 MB），换底座或叠加多个 LoRA 都方便。
- QLoRA 进一步把基座量化到 4bit，单卡能玩 70B。

164. 微调要准备什么数据？格式怎么定？

考察点：对微调数据准备的掌握。

答案：

数据类型：

类型	形态	适合
指令数据	{instruction, input, output}	让模型听特定指令
对话数据	messages: [{role, content}]	Chat 类模型
知识 QA	上下文 + 问答对	强化领域问答
偏好数据	{prompt, chosen, rejected}	DPO/RLHF 对齐

质量比数量重要：
- 1000 条干净 > 10 万条杂乱。
- 去重、去矛盾、去低质。
- 风格/长度/格式统一（模型很会学风格）。
- 留 5-10% 做验证集。
- Token 长度尽量贴近实际推理分布。

165. 私有化部署有哪些选项？

考察点：对部署方案的了解。

答案：按规模：

规模	推荐
单机/玩具	Ollama、LM Studio、llama.cpp（CPU/Metal）
单卡生产	vLLM + 14B-32B 量化模型
多卡/高并发	vLLM/SGLang + 70B 模型
集群	TGI/Triton + K8s
企业一体机	阿里/腾讯/火山/智谱的私有化解决方案

vLLM 是事实标准，PagedAttention 让吞吐高出传统几倍。

166. Dify / Coze / FastGPT 这类平台怎么选？

考察点：对低代码平台选型的判断。

答案：

维度	Dify	Coze	FastGPT	LangFlow
开源	是	否（字节托管）	是	是
私有部署	是	否	是	是
国内合规	看部署	友好	友好	看部署
工作流可视化	是	是	是	是
Agent/多 Agent	中	强	中	灵活但要写
模型支持	全	主要豆包/GPT	全	全

选型小结：
- 完全自控+私有化：Dify / FastGPT。
- 抖音/飞书/公众号：Coze。
- 重 RAG 知识库：FastGPT 起步快。
- 已用 LangChain + 想可视化：LangFlow。

167. 自己搭 LLM 应用平台 vs 用 Dify？

考察点：对自研与采购的判断。
答案：
维度自己搭用 Dify
上手慢快
定制自由受抽象限制
维护全自己跟社区版本
性能可极致优化中规中矩
适合超大流量/强定制中小项目/内部工具/MVP
务实结论：MVP/内部工具用 Dify 先跑通，核心业务自研，混合最常见。

维度	自己搭	用 Dify
上手	慢	快
定制	自由	受抽象限制
维护	全自己	跟社区版本
性能	可极致优化	中规中矩
适合	超大流量/强定制	中小项目/内部工具/MVP

168. Function Calling 的优缺点？为什么很多团队转 MCP？

考察点：对技术演进的理解。
答案：
- 优点：上手快、几乎所有 SDK 都支持、模型生态成熟。
- 缺点：
  - 没有跨厂商标准。
  - 工具描述全靠塞 Prompt，工具多了 Token 暴涨。
  - 没内建权限模型。
  - 跨语言/跨进程不友好。
  - 工具发现/热加载难。
这些短板正是 MCP 想解的，所以 2026 年明显朝 MCP 倾斜。

169. Agent Loop 在工程里有哪些坑？

考察点：对 Agent 工程风险的认知。
答案：跑过 Agent 的人都被这些坑过：
- 死循环/振荡。
- Token 烧得飞快。
- 错误被放大。
- 越权风险。
- 不会停。
兜底必做：
1. 设硬上限（步数/Token/时间）。
2. 重复检测。
3. 工具白名单 + 危险操作二次确认。
4. 全链路日志。
5. 上下文压缩。

170. ElasticSearch / 倒排索引在 AI 场景的作用？

考察点：对混合检索的理解。
答案：向量检索擅长语义，倒排索引擅长精确匹配/关键词/字段过滤。
在 RAG 场景下，最佳实践是 ElasticSearch + 向量库混合检索：
- ES 做 BM25 召回 + 字段过滤（按部门、时间、标签）。
- 向量库做语义召回。
- RRF 合并结果。
如果团队已有 ES 集群，可以直接用 ES 的 dense_vector + KNN，少引入一个组件。

171. Neo4j / 知识图谱在 AI 场景的作用？

考察点：对图数据库在 AI 中应用的理解。
答案：把"实体+关系"显式建模成图：
- 节点：人、公司、产品、订单。
- 边：归属、关联、引用、合作。
适合场景：
- 多跳推理（"客户 A 的关联公司在哪些行业有业务？"）。
- 反洗钱/合规审查（关系穿透）。
- 个性化推荐（基于关系）。
GraphRAG 就是基于知识图谱的 RAG，适合关系复杂、单文档语义不够的场景。

172. Docker Compose 在 AI 开发提效里能做什么？

考察点：对开发环境标准化的理解。

答案：本地一键起依赖（向量库 + Redis + Postgres + 监控）：

services:
  milvus:
    image: milvusdb/milvus
    ports: ['19530:19530']
  redis:
    image: redis:7-alpine
  postgres:
    image: pgvector/pgvector:pg16
  langfuse:
    image: langfuse/langfuse

docker compose up -d 一秒起完，免去手动安装。
生产场景一般上 K8s，但 Dev/测试/小型企业一直用 Compose 也合理。

173. LangSmith / Helicone / Langfuse 选哪个？

考察点：对可观测工具选型的判断。
答案：
维度 LangSmith Helicone Langfuse
开源否否是
自部署 否部分是
LangChain 集成 原生通用原生
数据集/评估 强弱中
价格中低自部署免费
选型：中小项目/合规要求高 → Langfuse 自部署；已用 LangChain + 不在意合规 → LangSmith。

维度	LangSmith	Helicone	Langfuse
开源	否	否	是
自部署	否	部分	是
LangChain 集成	原生	通用	原生
数据集/评估	强	弱	中
价格	中	低	自部署免费

174. vLLM 为什么吞吐高？

考察点：对推理引擎原理的理解。
答案：vLLM 的两个核心创新：
1. PagedAttention：把 KV Cache 按页存（类似操作系统虚拟内存），消除显存碎片，能塞更多并发。
2. Continuous Batching：新请求随时插入批次，不等慢的请求。传统 Batching 一个慢拖一片。
效果：单卡吞吐比 transformers + naive batching 高 5-10 倍。
竞品：SGLang（更激进优化）、TGI（HuggingFace 出品）、TensorRT-LLM（NVIDIA 官方，最快但配置复杂）。

175. 模型量化（INT8 / INT4 / AWQ / GPTQ）是什么？

考察点：对模型压缩技术的理解。
答案：模型权重从 FP16/BF16 压缩到更低精度，显存和延迟下降，精度有少量损失。
类型精度显存压缩典型损失
FP16/BF16 原始 1× —
INT8 8 位整数 2× < 1%
INT4 4 位整数 4× 2-5%
AWQ 4 位，关键权重保护 4× < 2%
GPTQ 4 位，基于梯度优化 4× < 2%
实战：
- 推理优先 AWQ（性能稳定、社区生态好）。
- 端侧/极端资源紧用 INT4/GGUF。
- 训练阶段一般不量化（影响梯度）。

类型	精度	显存压缩	典型损失
FP16/BF16	原始	1×	—
INT8	8 位整数	2×	< 1%
INT4	4 位整数	4×	2-5%
AWQ	4 位，关键权重保护	4×	< 2%
GPTQ	4 位，基于梯度优化	4×	< 2%

176. 模型蒸馏（Distillation）是什么？

考察点：对模型压缩技术的理解。
答案：用大模型（Teacher）"教"小模型（Student）：
1. 让 Teacher 生成大量高质量样本（含 Logits/Token 概率）。
2. 训练 Student 模仿 Teacher 的输出分布。
效果：
- Student 参数量 1/10，但效果接近 Teacher。
- 推理速度快好几倍。
- 经典案例：DistilBERT、DeepSeek-V3 蒸馏出来的小模型。
适合：业务场景固定、追求极致延迟/成本的生产环境。

177. 私有化部署 GPU 选什么？

考察点：对硬件选型的了解。

答案：

卡	显存	适合
RTX 4090	24G	个人/试验，14B 模型量化版
A10/A30	24G	中小生产，32B 量化版
L40S	48G	70B 模型量化版
A100 80G	80G	70B 全精度、训练
H100	80G	主流大模型推理/训练
H200/B200	141G+	旗舰生产，175B+

国内合规：A100/H100 受出口管制，替代方案为 A800/H800（被砍 NVLink 带宽）或华为 910B。

178. 模型评测常见 Benchmark？

考察点：对评测体系的了解。

答案：

Benchmark	测试内容
MMLU	57 学科多选题，知识广度
GSM8K	小学数学题，多步推理
MATH	高难度数学
HumanEval/MBPP	Python 代码生成
SWE-bench	真实软件工程
MT-Bench/AlpacaEval	多轮对话质量
C-Eval/CMMLU	中文综合能力
GAIA/AgentBench	Agent 能力

注意：Benchmark 分数和实际业务效果不一定一致，最终还是要拿业务数据测。

179. 私有化模型怎么更新？

考察点：对模型运维的理解。
答案：不像调 API 那样无感升级。常见策略：
1. 灰度切换：新模型挂上来，按流量比例分流，对比指标。
2. 双跑评估：旧/新模型同时跑，离线对比答案差异。
3. 回归测试集：维护一组业务测试 Case，新版必须通过。
4. 可快速回滚：模型版本管理 + 一键切回旧版本。
5. 保留旧版本一段时间：用户反馈"上次回答更好"时能回查。
铁律：不要"周末偷偷换新模型"。

180. ToB 项目灰度发布有什么特殊？

考察点：对 ToB 发布策略的理解。
答案：ToC 灰度按用户 ID Hash，ToB 不行：
- 一个客户的几百用户必须同时升级（避免同公司内体验割裂）。
- 必须支持按客户灰度（先小客户/试点客户/大客户）。
- 部分客户合同里写明"不要给我用新版"，要尊重。
- 告知机制：升级前邮件+站内信通知，让客户管理员有准备。
- 回滚要在合同 SLA 内。

181. ToB 项目的成本怎么算给客户看？

考察点：对商业化成本的理解。
答案：客户最关心的不是技术，是钱。展示口径：
- 按 Token 计费透明：每次调用 Input/Output Token 给出。
- 月度账单：按租户/按用户/按使用场景。
- 预算告警：超过 X% 自动通知。
- 模型分级：便宜模型默认、贵模型按需开。
- 缓存命中率告诉客户"省了多少钱"。
成本可见性是 ToB 续费的关键。

九、前端 AI 集成与工程化

面试官想确认：作为前端工程师，你是否能把 AI 能力落地为丝滑的用户体验。

182. 前端调 LLM API 怎么做流式输出？

考察点：对前端流式处理的核心掌握。

答案：不要用 axios，用 fetch + ReadableStream。

async function streamChat(input: string, onDelta: (text: string) => void) {
  const controller = new AbortController()
  const res = await fetch('/api/chat', {
    method: 'POST',
    body: JSON.stringify({ input }),
    headers: { 'Content-Type': 'application/json' },
    signal: controller.signal
  })

  if (!res.body) throw new Error('no body')
  const reader = res.body.getReader()
  const decoder = new TextDecoder()
  let buffer = ''

  while (true) {
    const { done, value } = await reader.read()
    if (done) break
    buffer += decoder.decode(value, { stream: true })

    let idx
    while ((idx = buffer.indexOf('\n\n')) !== -1) {
      const block = buffer.slice(0, idx)
      buffer = buffer.slice(idx + 2)
      if (block.startsWith('data: ')) {
        const data = block.slice(6)
        if (data === '[DONE]') return
        const { delta } = JSON.parse(data)
        onDelta(delta)
      }
    }
  }

  return controller
}

记得：
- 返回 Controller 给上层做中断。
- 错误要单独处理（一段 Chunk 解析失败别拉垮整个流）。
- TextDecoder 必须用 { stream: true }，否则中文截断会乱码。

183. 为什么不能在前端直接调 OpenAI / Claude？

考察点：对安全与架构的理解。
答案：理论上能，实际上不能：
1. API Key 暴露：放前端等于公开发钱。
2. 没法做权限/速率限制：被人薅羊毛。
3. 没法统计/计费：哪个用户花了多少钱。
4. 没法注入 System Prompt：用户能改请求。
5. CORS/跨域：很多家不支持浏览器直连。
6. 没法做合规过滤。
必须走自己的后端 BFF/API 网关代理。

184. 流式输出在 React 里怎么处理？

考察点：对 React 流式渲染的掌握。

答案：最简单：

function Chat() {
  const [text, setText] = useState('')
  const controllerRef = useRef<AbortController>()

  const send = async (input: string) => {
    setText('')
    controllerRef.current = new AbortController()
    await streamChat(input, (delta) => {
      setText((prev) => prev + delta)
    }, controllerRef.current.signal)
  }

  const stop = () => controllerRef.current?.abort()

  return (...)
}

注意：
- 每个 Token 都 setState 会卡，用 useReducer 或 Ref 缓冲再批量 Flush 在 60fps 内更新。
- 长文章场景上 react-window 虚拟列表。
- 别每个字都触发 Layout/Scroll 计算。

185. 大段文字流式渲染卡顿怎么办？

考察点：对性能优化的理解。
答案：罪魁祸首通常是 Markdown 增量解析。优化：
1. 节流渲染：每 30-50ms Flush 一次缓冲区，不要每 Token 重渲染。
2. Markdown 流式解析：用 react-markdown + memo，或专门的 streaming-markdown 库。
3. 代码高亮异步化：shiki/Prism 跑在 Web Worker。
4. 避免大组件树重渲染：消息列表只追加，最新一条单独组件。
5. 滚动跟随节流：scrollToBottom 防抖。

186. SSE 和 WebSocket 哪个适合 LLM 流式？

考察点：对传输协议选型的判断。

答案：

维度	SSE	WebSocket
方向	单向（服务端→客户端）	双向
协议	HTTP，简单	升级握手，复杂
自动重连	原生支持	自己写
代理/CDN 友好	友好	一般
适合	流式输出（LLM 99% 场景）	多人协作/双向打断

LLM 默认上 SSE，有"实时打断/多端协同/服务端主动推送" 才上 WS。

187. 怎么取消正在流式的请求？

考察点：对请求取消机制的掌握。
答案：前端用 AbortController，后端要识别到客户端断开立即停止 LLM 调用：
- OpenAI/Anthropic SDK 都支持传 AbortSignal。
- Node HTTP 监听 req.on('close') 触发 Cleanup。
- 已经调过的工具结果要做事务处理或标记中断。
不要让用户点了"停止"还在烧钱。

188. Token 预算怎么在前端做提示？

考察点：对用户体验细节的理解。
答案：实战经验：
- 输入框旁边显示估算 Token 数（前端用 tiktoken-js/cl100k_base 估）。
- 长度临近上限时变红 + 提示"内容过长，可能截断"。
- 上传文件/长 Prompt 时显示预估成本（按用户套餐计算）。
库选：gpt-tokenizer、tiktoken-js、@anthropic-ai/tokenizer。

189. 错误怎么向用户展示？

考察点：对错误处理 UX 的理解。

答案：LLM 错误分几类，UI 表达要区分：

错误	用户感知	建议表达
速率限制 (429)	服务忙	"请求过于频繁，请稍后重试"
配额耗尽	额度问题	"今日额度已用完，明日恢复/升级套餐"
上下文超长	内容过长	"对话过长，建议开新会话"
服务异常	后端问题	"服务暂时不可用" + 自动重试
模型拒答	触发安全	"无法回答此类问题"
网络中断	本地问题	"网络异常" + 自动重连

每种都要有重试按钮 + 错误码便于排查。

190. ChatGPT 那种"消息列表"怎么实现？

考察点：对核心 UI 数据结构的理解。

答案：数据结构：

type Message = {
  id: string
  role: 'user' | 'assistant' | 'system' | 'tool'
  content: string
  reasoning?: string  // 思考过程（CoT 显示）
  toolCalls?: ToolCall[]
  attachments?: File[]
  createdAt: number
  status: 'pending' | 'streaming' | 'done' | 'error'
}

UI 关键：
- 流式追加：最后一条 Message 是 streaming 状态时不断更新 content。
- 虚拟列表：消息多了用 react-window。
- 滚动控制：用户手动滚动后停止自动滚到底。
- 重新生成/编辑：编辑某条 User 消息后，从这条开始的所有后续 Message 清空 再重新跑。

191. 怎么管理多个会话状态？

考察点：对会话管理的理解。
答案：类似 ChatGPT 的左侧会话列表：
- 会话表 conversations(id, title, created_at, user_id)
- 消息表 messages(id, conversation_id, role, content,...)
- 前端状态：当前 conversation_id + 当前 messages 数组
- 路由 /c/[conversationId] 反映在 URL 上，方便分享/刷新
进阶：
- 会话标题用 LLM 自动从第一条对话生成。
- 软删除（标记 deleted_at）+ 30 天后真删。
- 大对话支持分页加载。
- 多端同步用 WebSocket/长轮询。

192. AI 对话用 Edge Runtime 还是 Node？

考察点：对运行环境选型的判断。
答案：
场景 Edge Node
纯流式代理 推荐也行
复杂业务/数据库重 不行推荐
全球低延迟 Edge 完胜受机房限制
大依赖/二进制包 Node 才能跑灵活
Vercel/Cloudflare 上的 LLM 代理大多 Edge，复杂 Agent 后端用 Node（要操作数据库、调多工具、跑长任务）。

场景	Edge	Node
纯流式代理	推荐	也行
复杂业务/数据库重	不行	推荐
全球低延迟	Edge 完胜	受机房限制
大依赖/二进制包	Node 才能跑	灵活

193. 怎么实现"图片 + 文字"混合输入？

考察点：对多模态输入的理解。

答案：数据格式（OpenAI/Anthropic/Qwen-VL 类似）：

{
  "role": "user",
  "content": [
    { "type": "text", "text": "这张设计稿对应哪些组件？" },
    { "type": "image_url", "image_url": { "url": "data:image/png;base64,..." } }
  ]
}

前端：
- 支持粘贴/拖拽/文件选择多种方式。
- 图片前端压缩到 1MB 以内再传（Base64 太大很贵）。
- 上传到对象存储拿 URL 比 Base64 便宜（前提是模型能访问到）。
- 显示缩略图 + 移除按钮让用户可以删。
- 多图按顺序排列。

194. Markdown 增量渲染怎么处理？

考察点：对流式 Markdown 渲染的理解。
答案：直接每次都 re-parse 整段会卡。三个套路：
1. Streaming Markdown：用支持流式的 Parser（marked/micromark + 增量插件），只 parse 新增片段。
2. 代码块缓存：代码高亮的输出按内容 Hash 缓存，重复不重 parse。
3. DOM diff 友好：用 React Key 让 DOM 复用而不重建。
注意：未闭合的代码块要做容错（用户还没输入 ``` 结尾），不要让一半的代码把后面渲染全搞乱。

195. AI 应用的埋点要监控什么？

考察点：对 AI 特有指标的理解。
答案：不只是 PV/UV，还要 AI 特有的：
- TTFT（First Token Time）：用户感知响应速度的关键。
- 完成耗时：整个回答从发出到结束。
- Token 消耗：每用户/每会话/每模型。
- 成本：折算成钱。
- 中断率：用户主动停的比例。
- 重试率/重新生成率：暗示回答质量。
- 拒答率：触发了安全过滤。
- 错误码分布。
- 多轮深度：用户问到第几轮。
- 点赞/点踩：用户反馈最直接信号。

196. AI 应用的"灰度发布"怎么做？

考察点：对发布策略的理解。
答案：新 Prompt/新模型/新 RAG 配置上线要灰度：
1. 配置中心驱动：Prompt、模型、RAG 参数从配置中心动态加载，不发版。
2. 用户分组：按 user_id hash 取模，5% → 20% → 50% → 100%。
3. AB 对照：旧版 vs 新版同时跑，对比关键指标（满意度、Token 成本、TTFT）。
4. 影子流量：新版本只跑不返回，只是为了拿数据。
5. 快速回滚：发现问题 5 分钟内切回旧版本。

197. AI 应用的成本怎么算和优化？

考察点：对成本模型的掌握。
答案：公式：成本 = Σ(每次调用的 input_tokens × in_price + output_tokens × out_price)
优化思路：
- 更便宜的模型分流（简单任务用小模型）。
- Prompt Caching（命中率打 1-5 折）。
- 缩短 Prompt + 工具描述。
- 结果裁剪/摘要。
- 多轮压缩（旧轮次摘要）。
- 业务侧缓存（同问题先查 KV）。
- 限流 + 套餐（防止个别用户跑爆）。

198. AI 应用的"国际化"（i18n）有什么特别？

考察点：对国际化细节的理解。
答案：不只是把文案翻译：
- System Prompt 多语言：每种语言一份。
- 输出语言：用户的浏览器语言/用户偏好。
- 不要混用语言：在 Prompt 里告诉模型"全程用同一种语言"。
- 错误信息 i18n：拒答信息、错误码都要翻。
- 数字/日期/货币格式按 Locale。
- RTL 语言（阿拉伯语）UI 也要 RTL。

199. AI 应用的"乐观更新"怎么做？

考察点：对 UI 体验优化的理解。

答案：用户发送消息后立刻显示在列表里，不等服务端确认：

const send = (input: string) => {
  const tempMsg = { id: nanoid(), role: 'user', content: input, status: 'pending' }
  appendMessage(tempMsg)
  // 异步调用 API
  api.chat(input).then((real) => replaceMessage(tempMsg.id, real))
    .catch(() => markFailed(tempMsg.id))
}

注意：
- 失败时用红色 + 重试按钮。
- 不要让"乐观"骗用户：服务端真失败要明确告知。
- 多端同步时小心冲突。

200. AI 自动补全代码（类似 Copilot）怎么实现？

考察点：对代码补全场景的理解。
答案：前端流程：
1. 编辑器 Cursor 位置 + 上下文（前后 200 行/Token）通过 Debounce（300-500ms）发给后端。
2. 后端 FIM（Fill-in-the-Middle）Prompt 调模型。
3. 流式返回，前端 Ghost Text 渲染。
4. Tab 接受 / Esc 拒绝 / 编辑中放弃。
要点：
- 用 FIM 友好的模型（DeepSeek-Coder、Qwen-Coder、StarCoder 等）。
- AbortController 让新一次输入立刻取消上一次。
- 接受率/拒绝率打点优化模型。
- 长函数不要一次全补，让用户分阶段确认。

201. AI 应用要不要 PWA / 离线支持？

考察点：对离线场景的判断。
答案：实战经验：
- 离线 LLM 一般不支持（模型太大，浏览器跑不动）。
- 历史会话可以做离线只读：IndexedDB 存历史，无网时也能看。
- 草稿离线写，回到在线再发送。
- 不要让 ServiceWorker 缓存 LLM API 接口，必须 NetworkOnly。
- 静态资源走标准 PWA 缓存就好。

202. Vercel AI SDK 的 useChat 怎么用？

考察点：对 Vercel AI SDK 的掌握。

答案：最简化的 Next.js 集成：

'use client'
import { useChat } from 'ai/react'

export default function Chat() {
  const { messages, input, handleInputChange, handleSubmit, isLoading, stop } = useChat({
    api: '/api/chat'
  })

  return (
    <>
      {messages.map(m => (
        <div key={m.id}>
          <strong>{m.role}:</strong> {m.content}
        </div>
      ))}
      <form onSubmit={handleSubmit}>
        <input value={input} onChange={handleInputChange} disabled={isLoading} />
        <button type="submit">发送</button>
        {isLoading && <button type="button" onClick={stop}>停止</button>}
      </form>
    </>
  )
}

后端：

import { openai } from '@ai-sdk/openai'
import { streamText } from 'ai'

export async function POST(req: Request) {
  const { messages } = await req.json()
  const result = await streamText({ model: openai('gpt-4o'), messages })
  return result.toDataStreamResponse()
}

省去了流式协议处理、状态管理、停止逻辑的大量样板。

203. 消息编辑 / 重新生成怎么实现？

考察点：对对话管理交互的理解。
答案：设计要点：
- 编辑 User 消息：编辑后，从这条开始的所有后续消息全清空，从这条重新跑。
- 重新生成 Assistant 消息：保留 User 消息，重新调用模型生成新回答，前一次答案要么覆盖、要么作为历史版本保留。
- 历史版本切换：UI 上 < 1/3 > 形式让用户在版本间切换。
- 状态机：消息有 editing | streaming | done | error 几种状态。

数据库 Schema：

message {
  id, conversation_id, role, content,
  parent_id,   -- 编辑后的新分支
  version,     -- 同一节点的多版本
  is_active    -- 当前显示的版本
}

204. 对话分支 / Fork 怎么做？

考察点：对对话树结构的理解。
答案：ChatGPT/Claude 都支持"从某条消息分叉重问"。
实现：
- 数据结构从"线性 List"改成"树"：每条 Message 有 parent_id。
- UI 在分叉点展示版本切换。
- 默认只显示一条线性路径（最新分支）。
- URL 带 ?branch=xxx 让分享和回访能恢复对应分支。
收益：用户能探索不同问法，避免反复开新会话浪费上下文。

205. 语音输入 / TTS 怎么集成？

考察点：对语音能力的理解。
答案：
- 输入侧（STT，语音转文字）：
  - 浏览器原生 webkitSpeechRecognition（兼容性一般）。
  - 接 Whisper API/阿里云 NLS/讯飞，自己录音+上传。
  - 实时流式 STT 用 WebSocket 推送音频流。
- 输出侧（TTS，文字转语音）：
  - 浏览器原生 speechSynthesis（音色差）。
  - 接 OpenAI TTS/Azure Speech/火山/阿里 TTS。
  - 流式 TTS：边生成边播。
工程要点：
- 录音前先申请权限，UI 提示。
- 静音检测自动结束录音。
- 实时 STT 用 SSE/WebSocket 流式更新 UI。
- TTS 队列管理：一句一句播，能跳过/暂停。

206. 文件上传 + 处理流怎么做？

考察点：对文件处理流程的理解。
答案：复杂场景常见：
1. 前端：File API 读文件 → 压缩/切片 → 上传到对象存储。
2. 后端：拿到文件 URL → 用 Loader 解析（PDF/Word/Excel）→ 切片 + Embedding → 入向量库。
3. 会话注入：把文件 ID 写入当前 Conversation 的 Metadata。
4. 检索：用户提问时，先检索该 Conversation 关联的文件。
5. UI：上传时显示进度，处理中显示 Loading，处理完显示文件卡片。
注意：
- 大文件分片上传（避免超时）。
- 异步处理（不阻塞对话）。
- 处理失败时给清晰错误（PDF 加密/编码异常等）。
- 单用户的存储配额必须控制。

207. Markdown 渲染中的 XSS 安全？

考察点：对安全问题的理解。
答案：LLM 输出会被渲染成 Markdown/HTML，潜在 XSS 风险：
- 用户问"输出 <script> 标签" → 模型照写 → 直接渲染就执行了。
- 第三方 RAG 文档里夹带恶意脚本。
防御：
- 用 DOMPurify 等库过滤 HTML。
- Markdown 渲染器关闭 raw HTML（marked 设 sanitize、react-markdown 默认安全）。
- 代码块单独渲染（用 <pre><code> 包裹，不解析）。
- iframe 嵌入要警惕。
- 用户输入也要消毒，不能让用户在自己问题里塞攻击。

208. 移动端 AI 应用有什么特殊问题？

考察点：对移动端适配的理解。
答案：不是把 Web 缩小那么简单：
- 键盘弹起：消息列表要重新计算 Viewport 高度。
- 流式更新滚动：要避免每个 Token 都触发滚动。
- 后台切换：iOS/Android 切到后台后流式可能断，要做重连。
- 网络抖动：弱网下 SSE 易断，要支持断点续传/重试。
- 输入法预测：避免误触发发送。
- 语音输入：移动端用户期望更高。
- 流量提示：长文/图片传输前提示用户。
- 省电：长时间流式 + 不间断渲染会发热掉电。

209. 怎么实现"AI 自动补全代码"（Copilot 同款）？

考察点：对代码补全场景的深入理解。
答案：前端流程：
1. 监听 Cursor 位置 + 上下文（前后 200 行）。
2. Debounce 300-500ms 后请求后端。
3. 后端用 FIM（Fill-in-the-Middle）Prompt 调模型。
4. 流式返回，前端 Ghost Text 渲染。
5. Tab 接受 / Esc 拒绝 / 编辑中放弃。
关键点：
- FIM-friendly 的模型才合用（DeepSeek-Coder、Qwen-Coder、StarCoder）。
- AbortController 让新一次输入立刻取消上一次。
- 接受率/拒绝率打点持续优化。
- 长函数分阶段补，让用户分阶段确认。

210. 怎么把 AI 集成到富文本编辑器（TipTap / Lexical / Slate）？

考察点：对编辑器集成的理解。
答案：主流交互模式：
1. 斜杠菜单（/）：输入 /ai 弹出操作面板（总结/改写/翻译/续写）。
2. 选中改写：选一段文字 → 右键/浮动按钮 → "用 AI 改写"。
3. 行内补全：Cursor 后显示 Ghost Text，Tab 接受。
4. 侧边栏 AI 助手：独立面板，可与文档双向同步。
工程要点：
- AI 改写要走事务：原文 → 模型流式输出 → 替换；用户能撤销。
- 多人协作时要走 CRDT，AI 写入算特殊作者。
- 长文档别全量喂模型，只喂选中片段 + 必要上下文。

十、AI 提效篇（怎么用 AI 反过来帮你干活）

面试官想确认：你是否真的在日常工作中用 AI 提效，能否讲出真实的工作流和踩坑经验。

211. 你日常用哪些 AI 工具？典型的工作流是什么？

考察点：对 AI 工具链的熟悉程度。
答案：参考答案要素：
- 写代码主战场：Cursor / Claude Code / Codex / Copilot 选 1-2 个。
- 写文档/写脚本/调研：ChatGPT / Claude / 通义。
- 画图/生图：Figma AI / Midjourney / 国内即梦。
- 会议/笔记：飞书妙记 / Notion AI / 通义听悟。
工作流示例（可参考改写）：

我用 Claude Code 做主力编码：早上接到需求 → 让 Claude Code 先读相关文件给出初步实现思路 → 我确认方案 → 让它写出来 + 跑测试 → 我 review + 局部修 → commit。零散的研究/文档用 ChatGPT。每周复盘让模型帮我总结这周的 commit。
讲得越具体越能加分。

212. Cursor / Claude Code / Copilot 这些 AI 编程工具的本质区别？

考察点：对 AI 编程工具的理解。

答案：

维度	Copilot	Cursor	Claude Code
主战场	编辑器补全	IDE 整合	命令行/Agent
单次粒度	单行/单函数	多文件编辑	跨任务 Agent
主力模型	OpenAI Codex/GPT-4	多家可选	Claude 系列
上下文	当前文件	Workspace 全局	工作目录+工具调用
强项	行内补全	改造代码	完成完整任务
适合	加速打字	改造重构	端到端开发

工程上常组合：Copilot 行内补全 + Cursor/Claude Code 端到端任务。

213. AI 写代码最容易翻车的几种情况？

考察点：对 AI 代码生成风险的认知。
答案：实战踩坑：
1. 依赖虚构 API：模型编不存在的库函数/方法名。
2. 版本不匹配：写的是旧版 API，你用的是新版（或反过来）。
3. 静默改了无关代码：让它改 A，它顺手"优化"了 B、C、D。
4. 删测试/删错误处理凑通过：测试跑不过它就改测试。
5. 不读现有约定：项目里用 antd 它写 element-ui。
6. 改完不验证：声称"已修复"但其实没跑。
面试讲出来这些细节就能加分。

214. 怎么写一个高质量的 AI 编程指令？

考察点：对 Prompt 工程在编程场景的应用。

答案：不要扔一句"帮我写个登录页"。结构化指令：

背景：项目用 React 18 + Vite + antd 6 + zustand。
任务：实现一个用户列表页，要求支持搜索、分页、删除。
接口：GET /api/users?q=&page=&size= ，返回 { list, total }。
约束：
- 只改 src/pages/UserList/，别动其他文件。
- 用 antd ProTable，不要重新造轮子。
- 删除要二次确认。
- 我已经有 useAuth、useApi hook，直接复用。
完成标准：
- 列表能渲染。
- 搜索和分页能联动。
- 删除有 message 反馈。
- 写一个最小的 vitest 测试。

要点：背景 + 任务 + 边界 + 约束 + 完成标准，模型不会跑偏。

215. AI 写完代码你怎么 Review？

考察点：对代码审查流程的理解。
答案：一定要 review，不要直接 commit。最少这几步：
1. 读 diff：每一行都过一遍，看有没有"惊喜改动"。
2. 跑测试/跑应用：能在本地跑通 + 关键路径过一遍。
3. typecheck + lint。
4. 看依赖：有没有新增包，是不是必要。
5. 看 commit message 是否准确：别让 AI 写 "fix everything"。
AI 写的代码 ≠ 你不用读。它写得快，但你署名。

216. AI 帮调 Bug 应该怎么用？

考察点：对 AI 辅助调试的理解。
答案：无效用法：把报错堆栈丢过去问"怎么修"。
更有效的用法：
1. 先描述上下文：项目结构、当前任务、最近改了什么。
2. 完整堆栈 + 最小复现：错误信息 + 触发步骤。
3. 告诉它你试过什么、排除了什么。
4. 让它先给出几个假设，而不是直接给修复方案。
5. 挨个验证假设，找到根因再修。
不要让 AI 替你思考根因，让它辅助你思考。

217. AI 写单元测试该怎么用？

考察点：对 AI 辅助测试的理解。
答案：容易踩的坑：
- AI 写的测试只覆盖 happy path，没覆盖边界。
- 测试和实现耦合太紧，重构就挂。
- Mock 写错，测试根本没在测。
- 看起来通过，实际没 assert 关键逻辑。
更好的用法：
1. 先告诉 AI 输入输出契约，让它写"测试用例描述"。
2. 你 review 测试用例够不够，再让它生成代码。
3. 故意改坏实现，跑测试看能不能测出来（mutation testing 思路）。
4. 测试要简单到一眼看懂，复杂测试反而藏 bug。

218. AI 帮 Code Review 怎么用？

考察点：对 AI 辅助 Review 的边界认知。
答案：让 AI 做"第一道筛"是合理的：
- 自动跑 lint/type check 看不到的问题。
- 命名/复杂度/副作用之类的"软指标"。
- 安全/性能的一般性建议。
但不能替代人 review：
- AI 看不到业务上下文。
- AI 容易给出"安全的废话"建议（什么都建议加 try/catch）。
- 关键决策（API 设计、架构）还是要人拍。

219. AI 帮写文档 / Commit Message / PR 描述？

考察点：对 AI 辅助写作的理解。
答案：完全可以，但有讲究：
- Commit Message：让 AI 看 diff 写一句话总结，你最后审一眼。命中率 80% 但还是要改。
- PR 描述：让 AI 看所有 commit 写 changelog 草稿，然后你补"为什么这么做"。
- API 文档/TSDoc：让 AI 看代码生成初稿，你必须 review 准确性。
- README：自己写比让 AI 写更靠谱，README 是给人看的，要有"人味"。

220. AI 帮设计 API / 数据结构靠谱吗？

考察点：对 AI 设计能力的判断。
答案：不靠谱当主笔，靠谱当评审。
- 让 AI 给 3 个方案比让它给 1 个方案有用。
- 让 AI 找出某个方案的潜在问题。
- 让 AI 模拟"如果未来要加 X 字段，这个设计能不能扛"。
API 设计最关键的是业务理解，AI 不知道你的业务，所以决策权永远在你。

221. AI 改造遗留代码（Legacy Code）的正确姿势？

考察点：对遗留系统改造的理解。
答案：遗留代码最危险，常见错误：让 AI 一次性"重构这个文件"。
更安全的方式：
1. 先让 AI 解释这段代码做了什么（让它先理解）。
2. 写测试覆盖现有行为（用 AI 写测试）。
3. 小步重构：一次只改一个函数/一个职责。
4. 每次重构后跑测试。
5. 保留原 commit，新建分支/PR 做对比。
不要把"重构一万行代码"当成一个 prompt。

222. AI 帮选技术栈 / 框架对比靠谱吗？

考察点：对 AI 信息准确性的判断。
答案：部分靠谱：
- 客观对比（性能、生态、上手成本）AI 给的信息 80% 准确。
- 结合业务的推荐不可信，因为它不了解你的业务。
- 最新信息（半年内的新框架、新版本）容易过时，必须查官网。
最佳用法：让 AI 列对比维度，然后你按维度自己拉数据。

223. 怎么避免对 AI 过度依赖？

考察点：对 AI 工具使用的理性认知。
答案：实战感受：
- 重要决策不让 AI 拍（架构、API 设计、技术栈选型）。
- 手感不能丢：定期写一段不用 AI 的代码，保持思维。
- Review 不外包：AI 写的也是你的代码，你要懂。
- 不要"我让 AI 写过了所以肯定对"：AI 错误率高于直觉。
- 写 Prompt 比写代码更难：能说清需求才能让 AI 帮你，逻辑思考还是要练。

224. AI 帮做需求分析 / PRD 解析？

考察点：对 AI 辅助需求工程的理解。
答案：实战用法：
1. 把 PRD 丢给 AI，让它抽取需求点（功能、约束、验收标准）。
2. 让它指出含糊的地方（这里没说限制条件、这里和前面冲突）。
3. 让它列出实现要点（要建几张表、要改几个接口、要考虑哪些边界）。
4. 你拿着这份草稿去和产品对齐。
把 AI 当一个"会做笔记的实习生"，它善于结构化整理。

225. 怎么让 AI 帮你"读代码 / 接手老项目"？

考察点：对 AI 辅助代码理解的应用。
答案：接手陌生项目时最高效用法：
1. 让 AI 读项目根目录 + package.json + README → 总结技术栈。
2. 让 AI 看 src 目录结构 → 推断架构分层。
3. 让 AI 挑一条核心链路（比如"用户登录"）走读 → 解释主流程。
4. 你拿着这份"地图"去看代码，事半功倍。
Claude Code/Cursor/Codex 类工具特别擅长这件事。

226. AI 写脚本（一次性 Ops 脚本）的正确姿势？

考察点：对 AI 辅助运维的理解。
答案：很多时候不值得自己写：迁移数据、清洗 log、跑 cron 任务。
实战经验：
- 明确输入输出：数据格式、文件路径、预期效果。
- 跑前先 dry-run：让 AI 加 --dry-run 模式打印不执行。
- 加日志 + 进度条：长时间脚本要能看进度。
- 可中断 + 可重入：跑一半挂了能从中间继续。
- 小数据集先跑一遍：再跑全量。

227. 让 AI 帮"写英文 / 改邮件 / 翻译"的注意点？

考察点：对 AI 辅助写作的理解。
答案：
- 写英文邮件：明确风格（正式/友好/简短），明确收件人。
- 翻译：来回翻译看是否丢信息。
- 技术翻译：术语先 review，AI 容易把专业术语翻成日常词。
- 多语言文档：让 AI 翻一遍 + 找一个母语同事过一眼。

228. AI 帮"画架构图 / 时序图"怎么用？

考察点：对 AI 辅助绘图的掌握。
答案：实战流程：
1. 让 AI 输出 Mermaid 代码：graph LR / sequenceDiagram / classDiagram。
2. 在 VSCode/Typora/Mermaid Live 里渲染看效果。
3. 不满意继续让 AI 改 Mermaid。
4. 满意后导出 SVG/PNG 用到 PR/文档里。
不要让 AI 直接画图（多模态生成图片可控性差），让它写代码。

229. AI 帮"查文档 / 学新框架"怎么用？

考察点：对 AI 辅助学习的理解。
答案：
- 官方文档先用 AI 摘要：但要 verify 关键代码，AI 容易把版本搞混。
- 新框架快速 onboarding：让 AI 给"5 个最常用的 API 示例"。
- 不要全信：新版 API 是 AI 训练后才出的，比如 React 19/Next 16 的新特性 AI 容易写错。
- 代码示例必须自己跑：别信"我刚刚帮你写好"。

230. AI 帮"看性能 Profile / 看 Source Map"靠谱吗？

考察点：对 AI 辅助性能分析的理解。
答案：部分靠谱：
- 看 Profile：让 AI 看 Chrome Performance/Lighthouse 报告总结瓶颈，靠谱。
- 看 minified 代码：AI 能读 Source Map 反映射后的代码，定位 bug。
- 优化建议：AI 给的是"通用建议"，你的项目特定优化它不懂。
更好的用法：你自己定位到瓶颈点 → 把那段代码喂给 AI 让它给优化方案。

231. AI 工具的 Cost 怎么控制？

考察点：对成本管理的理解。
答案：公司给的 AI 工具有预算，超了要被关怀。控制思路：
- 选小模型：日常 80% 任务用 Haiku/GPT-4o-mini/DeepSeek 这种便宜模型。
- 大模型只在难任务上用：架构设计、复杂 debug。
- 避免重复对话：复杂任务一次问清楚，不要来回试探。
- 缓存常用 Prompt：开发模板存起来。
- 关掉自动续传/Background Agent：跑着不知道，就是烧钱。

232. AI 工具的"安全 / 数据合规"风险？

考察点：对数据安全的意识。
答案：工作中要警惕：
- 不能把公司源代码/客户数据传给个人 ChatGPT 账户。
- 走公司统一网关/企业版（数据不进训练集）。
- 敏感字段（密钥、客户信息）脱敏后再问。
- 生成的代码也是代码，要走 Code Review，不要直接合。
面试里被问"你怎么保证用 AI 不泄密"，答出这几点就稳了。

233. AI 工具帮做技术调研 / 写技术分享的工作流？

考察点：对 AI 辅助知识输出的理解。
答案：
- 第一步：明确要分享的主题 + 受众（前端组/全公司）。
- 第二步：让 AI 列大纲（10-15 个点）。
- 第三步：每个点让 AI 写 200 字初稿。
- 第四步：你补自己的例子/项目截图/失败经验——这部分 AI 写不出来。
- 第五步：让 AI 生成 PPT 用 Mermaid/Marp 大纲。
- 第六步：本地 review 修改，配图。
AI 帮你处理体力活，判断力和真实经验你自己出。

234. 怎么用 AI 帮你"晋升 / 写自评"？

考察点：对 AI 辅助职场写作的理解。
答案：不开玩笑，很多人这么用。但要小心：
- AI 不知道你做了什么：你得先列出来。
- AI 容易写得"假大空"：让它优化"具体到指标/影响范围/协作角色"。
- 避免明显 AI 味：成段排比、抽象动词（赋能、闭环、抓手）多半要改。
- 最后自己读一遍：能不能复述出来。如果不能，说明写虚了。

235. 长期看，AI 对前端工程师意味着什么？

考察点：对行业趋势的思考。
答案：实诚答法（面试这种题不要装高调）：
- 门槛上升：以前写组件、调样式就能干活，现在这部分 AI 半秒做完。
- 架构/业务/系统设计的权重上升：决策能力比写代码更值钱。
- 学习曲线变陡：跟不上 AI 工具的人会落后。
- 不是替代，是升级：会用 AI 的前端 > 不会用 AI 的前端。
- 健康的心态：把 AI 当协作伙伴，不当奴隶也不当神。

236. 怎么用 AI 复盘一周 / 一月的 Commit？

考察点：对 AI 辅助复盘的理解。
答案：实用工作流：
1. git log --since="1 week ago" --pretty=format:"%h %s%n%b" --no-merges 拿到所有 commit。
2. 把列表喂给 AI，让它按主题分类（feature/bugfix/refactor/chore）。
3. 让它写两份：对内技术周报（细节）+ 对外业务周报（成果）。
4. 你补"为什么这么做" + "踩过什么坑"。

提示词模板：

帮我整理这一周的工作，按"完成的功能/解决的 bug/重构/文档"四个分类。
每项写 1 句话，强调对业务的影响和量化指标。
风格简洁、可读、面向非技术 leader。

237. AI 帮处理 Excel / CSV / JSON 数据怎么用？

考察点：对 AI 辅助数据处理的掌握。
答案：实战路径：
- 结构化整理：把"乱格式"的数据用 AI 转成规范 schema。
- 批量改写：让 AI 写 Python/Node 脚本，跑 dry-run 看输出再批量。
- 数据清洗：让 AI 列出"可能的脏数据模式"，再写规则过滤。
- Excel 公式：让 AI 写复杂公式（VLOOKUP 嵌套、数组公式），可读性差但能跑。
- 直接 ChatGPT Data Analysis：上传文件让它跑代码（适合一次性分析，不要长期依赖）。

提示词模板：

我有一份 CSV，字段是 [...]，目标是 [...]。
请写一个 Node.js 脚本，要求：
1. 支持 --dry-run 模式
2. 异常数据写到 error.log
3. 输出每一步进度

238. AI 帮做产品 / 设计 Brainstorm？

考察点：对 AI 辅助创意的理解。
答案：不是让 AI 拍板，是让 AI 当反弹墙：
- 让它列当前方案的潜在问题（10 个）。
- 让它扮演典型用户/ 竞品给你提反馈。
- 让它给3 个不同的解决方向让你选。
- 让它模拟 5 年后这个产品会被怎么颠覆。
不要问"你觉得 XX 怎么样"（它一定说"很好"），要问"找 5 个理由说为什么不该做 XX"。

239. AI 帮写周报 / 月报 / 述职报告？

考察点：对 AI 辅助汇报的理解。
答案：提示词技巧：
- 先输入事实：列出"做了什么、改了什么文件、解了什么 bug"。
- 指定风格：简洁/详细/数据驱动/故事化。
- 限制字数。
- 指定结构：成果/难点/协作/改进。
- 要求量化：每点尽量带数字（前后对比、用户量、性能提升）。
最后一定自己读一遍：能不能口头复述出来？不能的话就是写虚了。

240. AI 提效的"反模式"有哪些？

考察点：对 AI 工具使用的理性认知。
答案：工作中容易踩的坑：
1. 凡事先问 AI：简单事情靠 AI 反而慢。
2. AI 给的答案不验证：当成事实直接用。
3. 代码 Review 外包给 AI：自己不读就 commit。
4. AI 写的注释/文档不改：充满"如上所述、综上所述"。
5. 越聊越长不止：来回十几轮还没解决，直接看文档/看源码更快。
6. 过度依赖单一工具：AI 不可用时啥都不会做。
7. 不积累自己的方法论：每次都重新问 AI，没有沉淀。
健康的工作流：先想 → 上 AI 加速 → Review → 沉淀到 own playbook。

241. AI 帮你"学新框架 / 新工具"的最快路径？

考察点：对 AI 辅助学习的掌握。
答案：参考流程：
1. 让 AI 给你一份 30 分钟入门路径（核心概念 + 最小 demo）。
2. 让它对比你已会的框架（"React 开发者怎么理解 Svelte"）。
3. 跟着写一个最小可运行项目。
4. 让 AI 帮你列 5 个最常见踩坑 + 解决方案。
5. 实际项目尝试 → 出问题再回头问。
6. 一周后写一份自己的小结（强迫输出加深记忆）。
关键：别只看，要写。AI 让"看懂"变得容易，但只有"写出来"才真懂。

242. AI 帮你做技术博客 / 知识沉淀？

考察点：对 AI 辅助知识输出的理解。
答案：实战做法：
1. 大纲：让 AI 从你的笔记/commits/问答记录里抽取"值得写的话题"。
2. 初稿：你列要点，AI 扩展段落。
3. 改写：AI 给的初稿"AI 味"重，用"删形容词、加例子、加自己的话"三招过一遍。
4. 配图：让 AI 生成 Mermaid 流程图/表格。
5. 校对：让 AI 当 reviewer，从读者角度提"哪里不清楚"。
写完后：自己讲一遍能不能讲明白，是检验质量的硬指标。

243. AI 帮你做 OKR / 目标拆解？

考察点：对 AI 辅助目标管理的理解。
答案：公司层级 OKR 落到个人时，让 AI 帮你：
- 把模糊目标翻译成可衡量动作。
- 让它列出潜在阻塞/依赖。
- 让它模拟季度末复盘，提前看到"哪些指标会卡住"。
- 给一份周维度的拆分计划。
记住：AI 给的是模板，真正的目标取舍只能你自己拍板。

244. 怎么用 AI 提升英文 / 跨国协作？

考察点：对 AI 辅助跨语言协作的理解。
答案：
- 写英文邮件/文档：先中文起草，让 AI 翻译 + 优化语气。
- 接收英文长邮件/PR Review：让 AI 总结要点 + 列出"必须回应的问题"。
- 会议：飞书妙记 + Notion AI 自动转录 + 摘要。
- 跨时区沟通：让 AI 帮你写"非阻塞式回复"模板（明确说清楚下一步、避免无谓 ping）。
提示：英文表达从"语法对"到"地道"中间还有一大段，让 AI 多给几个候选自己挑。

245. 用 AI 学竞品 / 做技术调研的工作流？

考察点：对 AI 辅助调研的理解。
答案：参考流程：
1. 收集竞品的公开资料（官网、文档、博客、PR）。
2. 让 AI 抽取"它解决了什么问题、用了什么技术、有什么独特性"。
3. 让 AI 对比"我们家做法 vs 竞品做法"。
4. 让 AI 帮你列问竞品的好问题（如果以后能聊到他们工程师）。
5. 自己亲测竞品，形成第一手感受——这个 AI 替代不了。

246. Claude Code 的架构是什么样的？

考察点：对主流 Agent 工具架构的理解。
答案：理解 Claude Code 别只把它当成"命令行版 Cursor"。它本质是 Agent Loop + 多层治理：
- 核心 Loop：标准 Agent Loop（思考→工具调用→观察→再思考），循环里能调几十种内置工具。
- 工具层（Tools）：Read/Write/Edit/Bash/Grep/WebFetch/Agent/TodoWrite 等几十个，每个都有完整 schema。
- MCP 层：通过 MCP 协议把外部能力（数据库/Figma/浏览器/自研工具）接进来。
- Skills 层：可复用的"能力包"，包含 Prompt + 工具组合 + 触发条件。
- Memory 层：CLAUDE.md（项目级）+ ~/.claude/CLAUDE.md（全局）+ memory/ 目录（结构化记忆）。
- Hooks 层：用户可配置的脚本，能在工具调用前后插入校验/自动化动作。
- Permissions 层：哪些工具自动允许、哪些每次问、哪些禁止。
一句话：Claude Code 真正强的不是模型，是治理（Governance）——这套分层让 AI 编程从"放飞"变成"可控"。

247. Claude Code 的"治理"具体怎么做？

考察点：对治理机制的理解。
答案：四件套从粗到细：
1. CLAUDE.md：项目级指令文件，约定技术栈、命令、不要做的事、不要碰的文件。每次会话自动加载。
2. Skills：把"对这个项目怎么干活"封装成可调用的能力。
3. Hooks：在 pre-commit、tool-call-before/after 等事件点跑用户脚本，做格式化、敏感词过滤、危险命令拦截。
4. Permissions：settings.json 里精确控制哪些工具/哪些参数模式可以自动跑，哪些必须用户点确认。
实战收益：
- 团队新人接手项目，AI 自动遵守约定。
- 危险操作（rm -rf、force-push）必须人工二次确认。
- 跨项目复用 Skills，省掉重复教模型。

248. 什么是 Spec-Driven Development（SDD）？为什么 AI 时代需要它？

考察点：对 AI 时代开发方法论的理解。
答案：SDD = 先写规范再写代码，本身不是新概念，但 AI 编程让它复活。
为什么 AI 时代必须：
1. AI 理解需求不靠谱：你说"加个登录"，它可能给你 Session 也可能 JWT，结果跑偏。
2. AI 写的代码缺决策上下文：关掉聊天窗口决策就没了，后来人看不懂为啥这么做。
3. AI 生成速度太快，review 跟不上：缺一层"先达成共识再让 AI 写"的过滤。
SDD 的核心动作：在让 AI 写代码前，先用文档把**「为什么/做什么/怎么做」**写清楚，模型按文档执行，结果可追溯、可对齐、可审计。

249. OpenSpec 是什么？解决了什么问题？

考察点：对 OpenSpec 工具的理解。

答案：OpenSpec 是把 SDD 工程化的工具，主要解决 AI 编程的三个痛点：

痛点	OpenSpec 解法
需求偏差（AI 不懂你真要什么）	用 `proposal.md` 把"为什么/不做会怎样"写下来
设计漂移（AI 一会儿用方案 A 一会儿用方案 B）	用 `design.md` 锁定架构决策、接口、数据流
实施失控（AI 顺手改一堆无关代码）	用 `tasks.md` 列出可验证的具体任务
决策遗失（下次会话又重头讨论）	用 `changes/` 目录归档每次变更的完整提案

工程上 OpenSpec 把"和 AI 聊天"变成"和 AI 共同维护一份蓝图"。

250. OpenSpec 的核心三件套：proposal / design / tasks 各写什么？

考察点：对 OpenSpec 三个核心文件的掌握。
答案：
- proposal.md：为什么要做。背景、业务痛点、不做的代价、成功标准。一两屏长度，不写技术。
- design.md：技术怎么实现。架构决策、接口定义、数据流、依赖、风险点、备选方案对比。这是 AI 写代码时的事实来源。
- tasks.md：具体要做哪些动作。可执行清单，每项粒度小到能被一次执行跑完。
附加：
- specs/<capability>/spec.md：当前系统的稳定能力规范（事实记录，不是变更）。
- changes/<change-id>/：每次变更的完整目录。
- changes/archive/<date>-<id>/：完成后归档。

251. OpenSpec 的双文件夹模型（specs vs changes）是什么意思？

考察点：对 OpenSpec 核心设计理念的理解。
答案：OpenSpec 区分两类内容：
- specs/：当前系统已稳定的事实规范。"系统现在长这样"。
- changes/：每次变更的完整提案。"这次要把系统改成怎样"。

工作流：

1. /opsx:propose → 在 changes/<id>/ 下生成 proposal + design + tasks
2. 人工 review design.md
3. 执行 tasks.md（交给 Superpowers/Claude Code）
4. 完工后 /opsx:archive → 改动反向更新 specs/，change 归档到 changes/archive/

精髓：变更和事实分离。下一次会话来，看 specs/ 知道系统现状，看 changes/archive/ 知道历史决策。AI 不会重头讨论已经决定过的事。

252. Superpowers 是什么？提供了哪些核心能力？

考察点：对 Superpowers 工具的理解。

答案：Superpowers 是把"工程纪律"封装成 Skills 包。核心能力：

Skill	干什么
brainstorming	创造性工作前先发散，避免 AI 跑偏
writing-plans	把目标拆成可执行的实施计划
executing-plans	严格按计划执行，跑完一步勾一步
test-driven-development	强制先写测试再写实现
systematic-debugging	调 bug 的系统方法：复现→隔离→根因→修复→验证
code-reviewer	独立 review pass，不和实现混在一起
verification-before-completion	完成前必须跑过验证
worktrees	git worktree 隔离开发

简单说：OpenSpec 管"要做什么"，Superpowers 管"怎么做得专业"。

253. Claude Code + OpenSpec + Superpowers 三件套是过度工程吗？

考察点：对工具选型尺度的判断。

答案：被面试官追问最容易翻车的题，记住一个观点：按项目规模分档，不是非黑即白。

项目规模/类型	推荐配置
30 分钟脚本/一次性任务	只用 Claude Code，跑完丢
< 2h 探索性原型	Claude Code + 必要时 brainstorming
2-8h 个人项目/小功能	Claude Code + Superpowers（保质量）
4-16h 团队项目/跨人协作	全套（OpenSpec 留决策痕迹 + Superpowers 守纪律）
长期维护/ToB 交付	全套 + 严格 archive 流程

不分场景上全套 = 过度工程；不分场景拒绝全套 = 野路子。务实地按场景挑。
面试答法：

我会按"任务可逆性 + 跨人协作度 + 长期维护可能性"三个维度判断。一次性脚本直接 Claude Code，团队级功能必上 OpenSpec 留决策痕迹。

254. OpenSpec 的常见踩坑有哪些？

考察点：对 OpenSpec 实际使用的理解。
答案：实际用过的人会踩到这些：
1. 完成后忘了 archive：下一次会话以为是新需求，重复实现已有功能。
2. 把 spec 写成伪代码：太具体反而限制 AI 实现空间，应该停留在"接口/数据流/决策"层。
3. 跳过 brainstorming 直接 propose：技术选型偏差，AI 写到一半才发现方向不对。
4. proposal 和 design 混写：proposal 只讲"为什么"，design 才讲"怎么做"。
5. tasks 颗粒度太大：一项 tasks 跑两小时，AI 中途跑飞。
6. OpenSpec 和 Superpowers 没有串联：用了 propose 但执行时没走 TDD/review，等于半套。
避免方式：在 CLAUDE.md 明确写"propose 之后 tasks 必须走 Superpowers 的 TDD + verification + code-review 链路"。

255. "你日常怎么用 AI 提效"被问到，怎么答得让人记住？

考察点：对 AI 提效经验的综合表达能力。
答案：把流程讲具体、有例子、有反思。参考模板：
我们团队最近上 AI First 工作流，分三层：
1. 决策层：用 OpenSpec 先写 proposal + design 锁定方向。解决的痛是：以前一句话需求让 AI 干，常常跑偏 + 决策没留痕。
2. 执行层：Claude Code 跑 Agent + Superpowers 守纪律。关键约束：跑功能必须先写测试（TDD skill 强制），完成前必须 verify。实战收益：上线后回归率明显下降，且改完代码自带 review pass。
3. 沉淀层：每个变更跑完 archive 到 changes/archive/，下次有人接手能直接读历史决策，省掉一遍口头同步。
踩过的坑：
- 早期 OpenSpec 写得太详细，反而限制实现 → 后来 design 只写决策不写代码。
- Superpowers 全开太重 → 现在按任务规模分档，一次性脚本不用全套。
我自己最大的体感：AI 写代码的速度上限不是模型决定的，是"治理"决定的。有治理 = AI 是高级实习生；没治理 = AI 是熊孩子。
要点：有架构、有指标、有反思，是讲故事不是背概念。

十一、综合追问 & 场景题

面试官想确认：你是否能把前面所有知识融会贯通，解决真实的业务问题。

256. 场景题：公司想做一个"内部知识库问答机器人"，让你设计技术方案。

考察点：对 RAG 系统全链路的设计能力。
答案（30 秒能讲完的版本）：
1. 数据层：把 Confluence/内部 Wiki/飞书/Git 文档汇总，做 ETL 进入统一存储。
2. 切片 + Embedding：递归切分（500/50 overlap），用 bge-m3 入 Milvus/pgvector。
3. 检索：Hybrid Search（ES BM25 + 向量），用 bge-reranker 重排 top 5。
4. 生成：Claude/Qwen，prompt 强制带引用 + 拒答。
5. 接入层：Next.js BFF + SSE 流式，Slack/飞书机器人 + 网页 UI 双入口。
6. 可观测：Langfuse 自部署，监控 TTFT/召回/满意度。
7. 合规：私有化部署/数据不出网/审计日志。
8. 运营闭环：用户点踩的样本进入"待整理"队列，由文档负责人补充/更新。
面试官追问：
- "为什么不直接用 ChatGPT？" → 数据合规 + 内部知识。
- "为什么 Hybrid 不只向量？" → 产品编号/错误码/专有名词。
- "怎么评估效果？" → 准备 100 条 ground truth + RAGAS 跑回归。

257. 场景题：让你做一个"代码评审 Agent"，怎么设计？

考察点：对 Agent 应用设计的理解。
答案：最小可行：
1. 触发：GitHub Actions/GitLab Webhook，PR 创建时拉 diff。
2. 预处理：识别变更文件类型、过滤 vendor/lock/generated。
3. Tool 集合：read_file、search_code、run_linter、run_tests。
4. Agent 流程：
  - 读 diff → 理解改了什么。
  - 看 related files 拿上下文。
  - 跑 lint/type check 看明显问题。
  - 用 LLM 评审 → 输出结构化建议。
5. 输出：行级 comment + 总体评分 + 必须修/建议修两档。
6. HIL：高严重度自动 request changes，其他只提建议。
7. 反馈闭环：开发者标记"无效建议"，反过来调 Agent。
要点：让 Agent 跑工具拿事实，不要让它凭"读 diff"瞎评。

258. 场景题：公司 ToB 客户要私有化 LLM，从硬件到部署你怎么选？

考察点：对私有化部署全链路的掌握。
答案：阶段化：
- POC：单卡 A10/A100，跑 Qwen-14B AWQ 量化版，Ollama/vLLM 起来快。
- 试运行：2-4 卡 H800/4090 部署，跑 32B/70B AWQ，vLLM + nginx 反代。
- 生产：8 卡 H100 集群 + K8s + vLLM serverless 模式 + Prometheus + Grafana。
- 监控：tokens/s、并发、显存、温度、错误率。
- 备份模型：主模型挂时自动切到备模型。
要点：别一上来上 70B，先证明小模型 + RAG 业务跑得通，再扩。

259. 场景题：让你优化一个"AI 回答平均要 30 秒"的产品，怎么排查？

考察点：对性能问题的系统排查能力。

答案：按"用户感知"维度拆：

维度	排查	优化
TTFT	streaming 是否开/网关是否缓冲	上 SSE/关闭 buffer
首跳网络	是否走 CDN/边缘	Edge Runtime/CDN
Prompt 长度	system + 历史是否过长	压缩 + Prompt Caching
工具调用	串行 vs 并行	改并行
RAG 检索	单次召回耗时	加索引/Reranker 异步
模型	是否用了 o1/DeepSeek-R1 这种慢模型	切到 Haiku/GPT-4o-mini
后端处理	是否在 LLM 调用前同步等了一堆数据	提前并行加载

不要只看一个数字，画成瀑布图才知道时间花在哪。

260. 场景题：让你做一个"AI 客服"，怎么保证不乱说话？

考察点：对 AI 安全与合规的理解。
答案：防护多层：
1. 意图分类：先用小模型分类用户意图，只有白名单内意图才走 AI 回答。
2. 强 System Prompt：明确回答范围 + 拒答规则。
3. RAG 限定知识源：只用公司知识库，不让模型用通用知识。
4. 关键事实校验：金额、订单状态、政策类回答用代码二次确认。
5. 敏感词过滤：输出前过一层。
6. HIL 兜底：遇到投诉/复杂诉求 → 转人工。
7. 审计 + 回溯：所有对话保存，方便事后排查。
8. 持续学习：用户点踩样本 → 改 Prompt/加 FAQ。
宁可"我不知道"也不能"瞎说"。

261. 场景题：把 ChatGPT 类的对话产品迁移到你们的国产替代方案，应该注意什么？

考察点：对模型迁移的理解。
答案：不只是改 SDK：
- Tokenizer 不同：上下文 Token 估算要重新校准。
- system/user/assistant 行为差异：有些国产模型对 system 不那么"听话"，要在 user 里补强。
- 工具调用格式：每家略有差异，封一层适配器。
- 流式协议：不一定都标准 SSE，写 fallback。
- 速率限制/重试：不同家限流策略不一样。
- 多模态接口：图片 base64/URL 支持度不同。
- 价格/Token 模式：算成本要重新做。
测试一定要跑端到端真实场景而不是单元测试。

262. 场景题：用户对 AI 输出不满意怎么办？

考察点：对产品反馈闭环的理解。
答案：产品/工程都要联动：
- 用户视角：点踩/重试/编辑/切模型。
- 数据视角：点踩样本进入标注队列，每周一次回顾改进 Prompt/知识库。
- 指标视角：监控点赞率/点踩率/重试率/满意度。
- 闭环视角：改进上线后 A/B 看指标是否上升。
不要只在用户体验上做"满意度评分"，要落到可改进的样本。

263. 场景题：模型出现"复读机"现象怎么处理？

考察点：对模型异常行为的处理。
答案：复读 = 同一句话不断重复，原因可能：
- temperature 太低 + presence_penalty 太低。
- 模型陷入局部最优。
- 部分量化模型常出。
处理：
- 适度提高 temperature（0.5-0.7）。
- 设置 presence_penalty / frequency_penalty。
- 用更大的模型。
- Streaming 时前端检测连续 N 个 Token 重复 → 中断。
- 后端检测连续 N 句重复 → 中止并重试。

264. 场景题：怎么做"AI 应用的灾备 / 降级"？

考察点：对系统可靠性的理解。
答案：模型挂了你的产品不能挂：
- 多模型互备：主模型超时 → 自动切到备模型。
- 降级回答：模型完全不可用时返回 FAQ/文档链接。
- 缓存兜底：常见问题预生成答案，挂了也能答。
- 熔断：错误率高于阈值时自动熔断，不要持续重试拖垮系统。
- 状态保留：用户的会话别因为模型挂了就丢，能继续接着用。

265. 自我介绍：怎么把"我做过 AI 项目"讲得让面试官眼前一亮？

考察点：对项目经验的表达能力。
答案：模板：

我在 [项目名] 里做了一个 [一句话功能]，
解决的核心问题是 [业务痛点]。
技术上用了 [前端栈] + [LLM + 工具] + [RAG/Agent/工作流]，
关键决策点是 [选型 + 为什么]。
上线后 [一两个指标] 提升了 [X%]，
我自己负责 [模块/端到端]，
踩过的最深的坑是 [真实事故]，最后用 [方案] 解决。
要点：有数字 + 有决策 + 有踩坑，三件套缺一不可。

266. 场景题：让你设计一个 Cursor 同款 AI 编辑器，怎么做？

考察点：对 AI 编辑器产品的理解。
答案：参考方案：
1. 编辑器内核：Monaco/CodeMirror 起步，复用社区基础。
2. AI 集成方式：
  - 行内补全（ghost text + FIM）。
  - 选中改写（command palette/浮动菜单）。
  - 侧边栏对话（项目级问答）。
  - 端到端任务（Agent 跑工具改文件）。
3. 上下文管理：当前文件 + workspace 索引（用向量库）。
4. 工具集：read_file/write_file/edit_file/run_command/search_code。
5. Agent 模式：plan + execute + diff 三阶段。
6. diff 预览：AI 改动以 diff 形式预览，用户 Accept/Reject。
7. 历史回滚：每次 AI 改动一个 commit。
8. 多模型支持：用户可切 Claude/GPT/本地模型。
9. 隐私模式：可选不把代码上传给云模型。
追问要点：
- 为什么 Cursor 比 Copilot 好？→ workspace 级上下文 + 多文件编辑。
- diff 预览为什么必须？→ 用户对 AI 改动可控。
- 本地模型有什么用？→ 合规/离线/省钱。

267. 场景题：AI 监控告警归并系统怎么做？

考察点：对 AI 在运维场景应用的理解。
答案：业务背景：监控系统一天发几千条告警，人工看不过来。
方案：
1. 采集：从 Prometheus/Grafana/Sentry/日志系统 webhook 接告警。
2. 归一化：把不同来源的告警转成统一 schema（service/severity/message/time）。
3. 聚类：用 Embedding 做向量聚类，相似告警归一组。
4. AI 总结：每组让 LLM 生成"根因猜测 + 影响范围 + 建议动作"。
5. 优先级：用 LLM 评分 P0-P3，根据评分推不同通道（电话/IM/邮件）。
6. 关联历史：检索过去类似告警的解决记录，附在新告警旁边。
7. HIL：高严重度自动推 + 人工确认才能 ack。
8. 闭环：值班人员标"误报/已解决"反向训练系统。
收益：值班人从看 1000 条到看 20 组，注意力聚焦。

268. 场景题：智能客服路由（什么时候转人工）？

考察点：对 AI 与人工协作的理解。

答案：不能让 AI 永远兜底。分流策略：

场景	处理
简单查询/FAQ	AI 直接答
涉及金额/退款/投诉	直接转人工
用户连续点踩 N 次	转人工
AI 检索后置信度低	转人工
用户明确说"转人工"	立即转
涉及合规/法务	转人工
情绪检测：用户情绪激动	转人工
关键词触发（"投诉 12315"）	转人工 + 飞书报警

转人工时带上对话摘要，人工不用从头看。

269. 场景题：让 AI 把设计稿自动转代码？

考察点：对 AI 辅助设计转代码的务实理解。
答案：务实方案（注意：完全自动不可行，辅助才靠谱）：
1. 输入：Figma URL 或截图。
2. 解析：调 Figma API 拿出结构化设计描述（不是裸图）。
3. 组件匹配：和项目已有组件库（antd/shadcn）做 mapping。
4. 代码生成：让 AI 输出用项目组件实现的代码，不是从零写。
5. 样式提取：颜色、字号、间距从 design token 取。
6. 响应式：要求 AI 输出多个 breakpoint。
7. 人工 review：开发者 review + 微调，不能 100% 替代。
避免误区：让 AI"看图写代码"会得到一堆 inline 样式的烂代码，结合设计系统的代码生成才有产品价值。

270. 场景题：AI 应用的 SLA 怎么保证？

考察点：对系统可靠性的理解。
答案：外部模型不可控，SLA 必须做兜底：
- 多模型互备：主模型挂自动切。
- 本地小模型兜底：基本能答简单问题。
- 熔断 + 降级：错误率高于阈值就熔断，UI 降级为"暂不可用"。
- 缓存预热：常见问题预生成答案。
- 告警：错误率/延迟/Token 用量异常立刻报警。
- SLA 透明化：状态页 + 月度报告。
- 限流 + 公平队列：避免少数用户拖垮所有人。
ToB 客户要看 SLA 数字，说不准就别承诺。

271. 场景题：多端 AI 助手（Web + iOS + Android + 桌面）怎么统一？

考察点：对多端架构的理解。
答案：架构：
- 核心 API 后端：唯一事实来源，所有端都调它。
- 会话存储：服务端为主，端侧只缓存。
- 流式协议：SSE 或 WebSocket，端侧统一适配。
- 同步：端侧 push 新消息到服务端 + 拉取其他端的更新（WebSocket 推送）。
- 离线：端侧支持只读历史 + 草稿。
- 能力差异：端侧能力不一致（如桌面端能跑本地模型、移动端只能调云），后端按 capability 协商。
- 共享 Prompt/配置：通过 globalConfig 接口下发。
不要每端各写一套核心逻辑，重 BFF 或 SDK。

272. 场景题：AI 应用全链路可观测性怎么做？

考察点：对可观测性体系的理解。

答案：至少四层：

层	工具	看什么
前端	Sentry/Web Vitals	客户端错误、TTFB、流式卡顿
接入层	Nginx/API Gateway	请求量、错误码、限流
LLM 调用层	LangSmith/Langfuse	每次调用的 prompt、token、cost、耗时
Agent/RAG	自定义 trace	每步 plan/tool/retrieval/output

聚合：
- 全链路 trace_id 串起来。
- 每个请求能从前端点击 → 后端 → LLM → 工具调用 → 回包，一条线追完。
- 关键指标进 Grafana 看实时。
- 错误归类 + alerting。
没有可观测 = 没法调优 = 没法上线。

273. 场景题：AI 应用合规风险有哪些？怎么处理？

考察点：对合规要求的理解。
答案：不只是技术问题，是法务问题：
- 数据出境：海外模型涉及，国内业务要走合规审批。
- PII 保护：身份证/手机号/地址不能明文进 prompt。
- 未成年人保护：可能触发实名 + 内容过滤。
- 大模型生成内容备案（国内）：明确告知用户"内容由 AI 生成"。
- 版权：生成内容的归属、训练数据的合法性。
- 审计：所有对话保留 N 天，监管要求随时调取。
- 拒答场景：政治、暴力、医疗/法律建议要做明显约束。
合规上线前一定有法务过一遍。

274. 场景题：把团队"AI First"推进开发流程，怎么做？

考察点：对团队级 AI 落地的理解。
答案：不是发几个 ChatGPT 账号就行：
1. 统一工具链：选一两个核心工具（Claude Code/Cursor/Copilot），统一付费/培训。
2. 统一 Prompt 库：把团队验证过的高质量 Prompt 共享出来。
3. 统一 MCP/Skills：把内部工具封装成可复用能力。
4. 代码规范同步给 AI：CLAUDE.md/.cursorrules 写好。
5. 培训 + 分享：每周一次 AI 用法分享，沉淀 best practices。
6. 指标驱动：跟踪 AI 工具使用率/commit 中 AI 参与比例/节省工时。
7. 底线规则：什么不能让 AI 做（提交不读、改生产、写测试不审）。
8. 合规护栏：源代码/客户数据不进个人账号。
记住：工具好不好用，看团队；不是发完账号就万事大吉。

275. 终极开放题：如果让你三年内深耕一个 AI 方向，你会选哪个？

考察点：对职业规划的思考。
答案：参考思路（不要背，要按自己情况答）：
- AI Agent 工程：架构+工具+落地，需求量最大。
- Context Engineering / Prompt Engineering：基础设施型岗位。
- RAG / 知识工程：ToB 长青。
- AI 基础设施：网关/推理/评估，技术门槛高。
- 多模态/端侧：手机/车机/机器人，硬件结合。
- AI 安全/对齐：研究偏多，国内还没大规模商业化。
- AI 产品：把模型能力翻译成用户价值，需求量上升。
要点：
- 选自己有兴趣 + 公司有资源的方向。
- 不要追最热（红海早进的人吃肉，晚进的人吃灰）。
- 每个方向都需要工程能力 + 业务理解，纯算法岗在缩。

附录：常用速查表（背版）

AI 名词速查（面试官最爱当快问快答）

名词	一句话
Prompt	给大模型的输入指令，控制行为/风格/思路
LLM	Large Language Model，大语言模型
Token	模型实际处理的最小单元，影响计费和上下文
Context Window	一次能看到的最大 Token 数
Embedding	把文本压成高维向量，反映语义相似度
RAG	检索增强生成，给模型外挂知识库
Fine-tuning	用领域数据在预训练模型上继续训练
PEFT/LoRA/QLoRA	轻量微调，省显存的代表方案
Agent	LLM + 工具 + 记忆 + 规划，能自主完成任务
Tool	Agent 能调用的外部功能（接口、文件、命令）
Function Calling	模型按 Schema 输出 JSON 决定调哪个函数
MCP	Model Context Protocol，跨语言跨进程工具协议
CoT	Chain of Thought，让模型先想再答
ReAct	Reason + Act，Agent 的基础范式
Memory	模型的"记忆"，分短期/长期/工作记忆
Hallucination	模型幻觉，听起来合理但事实错误
Prompt Injection	用户输入夹带恶意指令攻击 System Prompt
Jailbreak	突破模型自身安全限制
Streaming	一边生成一边推到客户端
TTFT	First Token Time，首 Token 出现时间
Prompt Caching	复用 KV Cache 给重复 Prompt 打折计费

主流模型（2026 年）

厂商	主力	特点	适合
Anthropic	Claude Opus/Sonnet/Haiku	Agent、长文本、代码	复杂 Agent/编程
OpenAI	GPT-4.1/GPT-5/GPT-4o/o1	通用、工具生态	通用业务、多模态
Google	Gemini 2 Pro/Flash	多模态、超长上下文	长文档、视频
Meta	LLaMA 系列	开源标杆	学术研究/私有定制
DeepSeek	V3/R1	开源、推理/代码/数学强	私有化、降本
阿里	Qwen Max/Plus/VL	中文、私有化生态	ToB/多模态
Moonshot	Kimi K1	长文本、中文阅读	长文档问答
智谱	GLM-4	国内私有化好	国企/政企
字节	豆包/Doubao	抖音生态打通	字节渠道
Mistral/Phi/Gemma	1B-14B 轻量模型	边缘部署、端侧推理	IoT/浏览器/端侧

主流框架 / SDK

类别	推荐
前端 SDK	Vercel AI SDK
后端 Agent	LangChain / LangGraph
多 Agent	CrewAI / AutoGen / LangGraph
RAG	LlamaIndex / LangChain
向量库	pgvector / Milvus / Qdrant / Chroma
评估	RAGAS / DeepEval / TruLens
可观测	LangSmith / Langfuse / Helicone
私有化推理	vLLM / Ollama / SGLang

Prompt 万能骨架

# 角色
[具体角色]

# 任务
[一句话讲清楚]

# 输入
{{user_input}}

# 步骤（可选，复杂任务必加）
1. ...
2. ...

# 输出格式
[JSON Schema / Markdown 模板]

# 约束
- 必须...
- 不能...
- 当 [边界情况] 时，[怎么做]

# 示例（可选，复杂任务必加）
输入：...
输出：...

Agent 公式

Agent = LLM + 工具 + 记忆 + 规划

用户输入
  ↓
规划（拆任务）
  ↓
循环：思考 → 工具调用 → 观察 → 再思考
  ↓
输出 + 写记忆

RAG 公式

切片 → embedding → 入库
查询 → 改写 → 向量召回 + BM25 召回 → 重排 → top-k
材料 + 问题 → LLM → 回答（带引用）

MCP 公式

LLM ↔ Function Calling ↔ Client ↔ MCP Protocol ↔ Server ↔ Real Tools

Memory 公式

全量 messages → 滑动窗口 → 滑动窗口 + 摘要 → 向量长期记忆 → 图谱/结构化记忆

第一版整理到这里。每年都会补 30-50 道新题，建议只看问题不看答案先自己讲一遍，能讲清的跳过、卡壳的再看答案。

真正能拉差距的不是题目多寡，而是有没有真的写过 Agent、调过 RAG、踩过 Memory 的坑。面试前找一个你正在用的产品想想能怎么加 AI，自己做一个最小 demo 上线让真实用户用一周，胜过刷十遍题。

分享

AI 大模型与 Agent 面试题汇总