# AI 智能体与大模型应用开发面试题库

> 定位：面向 **AI 智能体 / 大模型应用开发工程师**、**AI 应用开发工程师**、**Agent 开发工程师**。  
> 风格：偏 **应用落地、架构设计、工程治理、项目实战**，不偏纯算法研究或预训练细节。

文档特点：

- 每道题都标注了**重要度**和**难度**，方便区分必刷内容、常考内容和进阶内容。
- 题目下方尽量补充了**对应章节**，方便回看知识点、边学边练。
- 相当一部分题目来自**大厂真实面经**和实际高频追问场景，更贴近真实面试。
- 整体表达坚持**语言专业但易读**，尽量避免空话、套话和纯概念堆砌。
- 各个二级标题按主题分类，结构清晰，便于按模块系统复习。

重要度标记说明：

- `必刷`：大概率会被问到，答不好会直接暴露短板。
- `高频`：面试中很常见，通常是主问题或高频追问。
- `中频`：更偏工程设计、项目深挖和落地细节。
- `低频`：加分题、延伸题、岗位深挖题。

难度标记说明：

- `基础`：偏概念主干和标准答法，适合第一轮打底。
- `中等`：需要结合工程理解、分层表达或一定项目经验。
- `较难`：更偏系统设计、复杂治理、协议细节或高级架构取舍。

## 1、基础认知与技术选型

### Q1-1. RAG 和微调（SFT）的核心区别是什么？能不能一起用？

RAG 解决的是“知识从哪里来”，微调解决的是“模型应该怎么表现”。

RAG 不改模型参数，而是在运行时把相关资料检索出来，再交给模型生成答案，所以更适合处理时效性强、更新频繁、需要可溯源的知识。微调会改模型参数，更适合提升输出风格一致性、结构化能力、分类能力或领域行为稳定性。

它们当然可以一起用，而且很多企业项目就是这么落地的：用 RAG 提供知识，用微调或强约束输出提升行为稳定性。比如客服项目里，产品政策靠 RAG 保持最新，回复格式和字段输出靠微调或结构化输出保证稳定。

**常见追问：**

- 为什么多数企业项目不会优先做续训？
- 什么场景适合 `RAG + 微调` 组合？
- 如果预算有限，先做哪一个？

**重要度：**`必刷`（出现次数：3次） | **难度：**`中等`

**考察点：**知识增强和行为优化的区分能力。

**对应章节：**[1-3 RAG、微调、续训与智能体选型 §1、RAG](1-3-RAG、微调、续训与智能体选型.md#_1、rag)；[1-3 RAG、微调、续训与智能体选型 §2、微调（Fine-tuning）](1-3-RAG、微调、续训与智能体选型.md#_2、微调%EF%BC%88fine-tuning%EF%BC%89)

### Q1-2. 什么是 AI Agent？它和传统 AI 应用的区别是什么？

可以概括为：**Agent = 模型 + 工具集 + 运行循环 + 当前状态**。

- 模型负责理解目标和决定下一步。
- 工具集负责提供外部能力。
- 运行循环负责让系统不是只回答一次，而是能“想一步、做一步、看结果、再决定下一步”。
- 当前状态负责保存消息、工具结果和中间结论。

传统 AI 应用更接近“输入一个请求，返回一个结果”的单轮系统；Agent 更接近“围绕目标持续做决策”的运行方式。它的关键不只是用了大模型，而是具备了工具调用、状态推进和动态决策能力。

所以不是所有 AI 应用都该叫 Agent。固定表单生成、固定知识问答、固定流程审批，这类系统往往用普通链路或 Workflow 就够了。只有在路径不固定、需要根据中间结果继续选择工具或调整路线时，Agent 才真正合适。

另外也要注意，很多人会把“长期记忆、复杂规划、多智能体协作”都当成 Agent 的必备条件，不是。对很多入门场景来说，能做到“理解目标、决定是否调工具、拿到结果再继续判断”，就已经是 Agent 了。

**重要度：**`高频`（出现次数：2次） | **难度：**`基础`

**考察点：**是否理解 Agent 的本质，不会把任何聊天机器人都叫 Agent。

**对应章节：**[21 Agent智能体 §1、Agent 简介](21-Agent智能体.md#_1、agent-简介)；[1-3 RAG、微调、续训与智能体选型 §4、智能体开发](1-3-RAG、微调、续训与智能体选型.md#_4、智能体开发)

### Q1-3. 什么时候该用 Prompt、RAG、微调、Workflow、Agent？

最稳的判断方式，是先判断问题到底是**缺知识、缺行为，还是缺流程能力**。

- 如果模型本来就会，只是任务没描述清楚，先用 Prompt。
- 如果缺的是私有知识、最新知识、外部知识，优先上 RAG。
- 如果缺的是稳定行为，比如固定格式、固定语气、固定分类习惯，再考虑微调。
- 如果流程固定、节点明确、强调稳定和可审计，优先 Workflow。
- 如果路径不固定，需要边做边决定下一步、动态调用工具，再考虑 Agent。

这条选型主线可以压缩成一句话：

- **Prompt** 解决任务表达问题。
- **RAG** 解决知识来源问题。
- **微调** 解决行为稳定问题。
- **Workflow** 解决固定流程问题。
- **Agent** 解决动态决策问题。

真实项目里通常不会一开始就说“必须做 Agent”。大部分需求先用 `Prompt + RAG + Workflow` 就能覆盖，只有在任务开放度高、工具选择依赖中间结果、流程没法提前写死时，Agent 的价值才会真正体现出来。

**常见追问：**

- 为什么很多项目不一开始就做微调？
- 为什么不是所有复杂任务都适合 Agent？
- Workflow 和 Agent 的分界线是什么？

**重要度：**`必刷`（出现次数：1次） | **难度：**`中等`

**考察点：**技术选型能力、边界意识、是否有工程判断。

**对应章节：**[1-3 RAG、微调、续训与智能体选型 §1、RAG](1-3-RAG、微调、续训与智能体选型.md#_1、rag)；[1-3 RAG、微调、续训与智能体选型 §4、智能体开发](1-3-RAG、微调、续训与智能体选型.md#_4、智能体开发)

### Q1-4. Token 和上下文窗口是什么？它们在工程上意味着什么？

Token 可以看作模型处理文本的基本计量单位，不等于“字数”或“单词数”。模型在训练和推理时看到的不是原始文本，而是 tokenizer 切出来的一串 token。

上下文窗口则是模型单次推理时最多能看到多少 token 的上限。工程上常说的 `8K`、`32K`、`128K`，本质上说的都是“这次请求里系统提示、历史对话、检索结果、用户问题加起来最多能塞多少 token”。

它的工程意义非常直接：

- 上下文窗口决定了你能不能做长文问答、多轮对话和大段 RAG 上下文拼接。
- token 越多，成本通常越高，延迟也更容易上升。
- 超出窗口的内容会被截断、压缩或根本进不了模型，所以不是“塞得越多越好”。

如果只做一个大致口径，`128K token` 可以看作很长的一段内容。按常见经验口径，1 个中文字符大约是 `0.6` 个 token，1 个英文字符大约是 `0.3` 个 token，所以 `128K token` 粗略可以近似成二十万级别的中文字符量级。但这只是估算，真实数字会因为 tokenizer、语言类型、代码、标点和格式不同而波动。

**常见追问：**

- 1 个汉字、1 个英文单词大概是多少 token，为什么不能死记一个固定值？
- 如果上下文被截断了，你会优先怎么处理？

**重要度：**`高频`（出现次数：1次） | **难度：**`基础`

**考察点：**是否真正理解 token、上下文窗口和成本 / 截断 / 长文本场景之间的关系。

**对应章节：**[1-1 大模型认知与工程概览 §1、认识大模型](1-1-大模型认知与工程概览.md#_1、认识大模型)；[11 Model I/O 与模型接入 §2、LangChain 模型分类、参数与返回](11-Model-I-O与模型接入.md#_2、langchain-模型分类、参数与返回)

**来源：**腾讯AI后台工程师一面（实际大厂面试题）

### Q1-5. 大模型应用上线前你最关心哪些工程指标？

通常会从效果、性能、成本、稳定性、治理性五个维度看。

- 效果：准确率、忠实度、任务完成率、引用正确率。
- 性能：首 token 延迟、端到端延迟、P95/P99。
- 成本：token 消耗、检索成本、工具调用成本。
- 稳定性：超时率、错误率、重试率、降级命中率。
- 治理性：日志、Trace、Prompt 版本、索引版本、权限审计。

如果是 RAG / Agent 项目，我还会额外看检索召回质量、工具调用成功率、人工兜底比例和 badcase 回灌效率，因为这些才是真正影响线上体验的关键指标。

**常见追问：**

- 你怎么设计降级策略？
- 如果成本超预算，先优化哪一层？
- 怎样做 Prompt / 模型 / 索引回滚？

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**是否具备生产环境意识。

**对应章节：**[1-1 大模型认知与工程概览 §4、大模型的工程实现（概览）](1-1-大模型认知与工程概览.md#_4、大模型的工程实现%EF%BC%88概览%EF%BC%89)；[7 企业级大模型部署 §1、企业级大模型部署概述](7-企业级大模型部署.md#_1、企业级大模型部署概述)

---

## 2、Prompt、结构化输出与护栏

### Q2-1. System Message 和 User Message 应该怎么分工？

System Message 负责放稳定约束，User Message 负责放动态任务。

System 里一般放角色、目标、边界、安全规则、输出格式要求、工具使用规范，这些内容应该尽量稳定、少改。User Message 放用户当次任务、输入数据、补充上下文和个性化要求。

这样拆分的好处是结构更清晰，便于版本管理，也更适合后续做模板化、灰度和评测。如果把所有内容都混在一段 prompt 里，后面排查效果波动会非常困难。

**重要度：**`必刷`（出现次数：1次） | **难度：**`基础`

**考察点：**Prompt 分层设计能力。

**对应章节：**[13 提示词与消息模板 §3、入参的消息类型](13-提示词与消息模板.md#_3、入参的消息类型)；[13 提示词与消息模板 §7、对话提示词模板（ChatPromptTemplate）](13-提示词与消息模板.md#_7、对话提示词模板%EF%BC%88chatprompttemplate%EF%BC%89)

### Q2-2. 结构化输出有哪些常见做法？各自的优缺点是什么？

从 Model I/O 这条主线看，结构化输出大致可以分成“后处理解析”和“前约束结构化输出”两类。

- 纯 Prompt 约束：直接要求模型按 JSON 返回。优点是最简单、起步快；缺点是模型多说一句话、少个逗号，程序就容易崩，稳定性最差。
- Output Parser：比如 `StrOutputParser`、`JsonOutputParser`、`PydanticOutputParser`。它更接近“模型已经输出了，我再把结果转成程序可用的数据”，适合 `prompt | model | parser` 这条经典链路。
- Structured Output：比如 `with_structured_output(TypedDict / Pydantic / JSON Schema)`。它更接近“在模型输出前就先把 schema 定好”，让模型按结构生成并自动解析，约束力更强。
- Function Calling / Tool Calling：本质上也是结构化输出的一种，只不过目标更偏“生成调用意图和参数”，特别适合工具调用、外部接口编排和 Agent。

如果模型平台支持更严格的结构化输出能力，通常会优先采用只保证“返回合法 JSON”的模式，因为前者更接近“按 schema 生成”，后者很多时候只是“长得像 JSON”。

如果再往下细分：

- `TypedDict` 适合字段固定、但不追求很强运行时校验的场景。
- `Pydantic` 适合字段类型、范围、必填项比较严格的业务场景。
- `JSON Schema` 更适合跨语言、跨系统共享结构协议。

工程上通常不会把“让模型输出 JSON”当成真正的生产方案，更稳的顺序通常是：

1. 能用原生结构化输出就优先用。
2. 需要强校验时优先用 Pydantic 一类 schema。
3. 即使模型已经结构化输出，也要补业务校验、缺省值处理和失败重试。

归根结底，Prompt 只能“尽量要求它长成这样”，Parser 和 Structured Output 才是在帮你把模型输出真正接进程序系统。

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**从“能输出 JSON”到“能稳定接系统”的工程意识。

**对应章节：**[14 输出解析器 §1、输出解析器简介](14-输出解析器.md#_1、输出解析器简介)；[14 输出解析器 §4、结构化输出](14-输出解析器.md#_4、结构化输出)

### Q2-3. Prompt Injection 是什么？为什么 RAG / Agent 场景更要小心？

Prompt Injection 本质上是：**不可信输入试图改写系统指令、诱导模型越权，或者让 Agent 执行原本不该执行的动作。**

它不只来自用户直接输入，也可能藏在网页、PDF、知识库文档、邮件甚至图片里。只要这些内容会被模型读到，就可能形成“间接注入”。所以在 RAG、浏览器 Agent、代码解释器这类会读外部内容的系统里，风险会明显更高。

通常会从五层做防护：

- 指令分层：System 放稳定规则，User 和外部文档都视作不可信输入，不能和系统约束同权。
- 内容隔离：检索片段、网页内容、用户上传文档只当“待分析材料”，不要默认它们能发新指令。
- 工具权限：所有写操作、危险操作都走白名单、schema 校验和最小权限，不让模型拿裸能力。
- 动作校验：关键输出做规则校验，关键动作做确认、审批或 HITL，不让一句恶意文本直接触发副作用。
- 观测与兜底：记录注入样例、失败轨迹和异常调用，及时加入评测集和拦截规则。

这里有一句特别关键：**RAG 不是安全层，知识库文档本身也可能带恶意指令。** 只要把“检索到的内容”直接当成“可信提示词”，系统就很危险。

**常见追问：**

- 如果文档里写着“忽略之前所有指令”，你会怎么处理？
- 浏览器 Agent 怎么防网页里的隐藏提示词？
- 为什么微调和对齐不能从根上解决 Prompt Injection？

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**应用层安全意识，以及对直接注入、间接注入和工具越权风险的理解。

**对应章节：**[13 提示词与消息模板 §1、Prompt 简介](13-提示词与消息模板.md#_1、prompt-简介)；[17 Tools工具调用 §6、从课程案例走向真实项目](17-Tools工具调用.md#_6、从课程案例走向真实项目)

### Q2-4. Prompt Engineering 中，如何系统优化提示词并把准确率做上去？

通常不会把 Prompt 优化理解成“反复手改几句提示词”，而是把它当成一个小型工程闭环。真正想把准确率稳定做上去，核心不是玄学技巧，而是 **任务拆解、样例驱动、评测回归和边界收敛**。

比较稳的做法通常是：

- 先定义任务边界：先说清楚什么叫答对，什么叫答错，哪些情况必须拒答或澄清。
- 做输入分层：把稳定规则放 `System`，动态任务放 `User`，别把所有约束揉成一段长 prompt。
- 先修大问题再修措辞：如果问题本质是缺知识、缺工具、缺流程，不要强行靠 Prompt 硬抬效果。
- 用样例和反例：few-shot 示例、反例约束、输出格式示例，通常比抽象要求更稳定。
- 做结构化约束：能用 schema、parser、structured output 的地方，不要只写“请返回 JSON”。
- 建 badcase 集：把线上错例沉淀成固定评测集，每次改 Prompt 都跑回归，而不是靠体感判断“好像更准了”。
- 做版本和灰度：Prompt、模型版本、温度、输出格式要求一起管理，避免改了一个点却查不清影响。

如果从更务实的面试表达出发，还需要补一句：所谓“准确率 > 95%”一定要绑定具体任务，比如分类、抽取、格式生成、客服问答，它不是一个通用承诺值。真正的工程目标应该是让某个具体任务在固定评测集上稳定达标，而不是追一个脱离场景的数字。

**常见追问：**

- 如果 Prompt 怎么改都上不去，你怎么判断应该切到 RAG、Tool、Workflow 还是微调？
- badcase 集应该怎么建，才能真的指导迭代？
- 如果线上效果突然下降，你怎么判断是 Prompt 问题、模型版本问题，还是外部知识 / 工具链路问题？

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**Prompt 优化方法论、评测闭环意识，以及是否知道 Prompt 不是万能修复工具。

**对应章节：**[1-2 提示词工程基础 §2、提示词怎么写](1-2-提示词工程基础.md#_2、提示词怎么写)；[14 输出解析器 §8、实际开发选择](14-输出解析器.md#_8、实际开发选择)

### Q2-5. Prompt 工程的边界是什么？为什么不能把一切问题都交给 Prompt？

Prompt 更接近一种“任务表达和约束手段”，但它解决不了知识缺失、复杂状态管理和强执行需求。

比如资料太多时，仅靠 Prompt 塞上下文会出现成本高、噪声多、丢关键信息的问题，这时候应转向 RAG。多步骤复杂流程如果全靠 Prompt 硬编排，会变成不可维护的长指令，应该转 Workflow 或 LangGraph。需要稳定调用外部系统时，应该走 Tools / Function Calling，而不是让模型在文本里“假装调用了接口”。

所以工程上更合理的思路是：Prompt 负责表达规则，RAG 负责补知识，Tools 负责执行能力，Graph / Workflow 负责流程控制。

**重要度：**`中频`（出现次数：1次） | **难度：**`基础`

**考察点：**是否理解 Prompt 不是万能药。

**对应章节：**[1-2 提示词工程基础 §4、提示词工程的边界](1-2-提示词工程基础.md#_4、提示词工程的边界)；[13 提示词与消息模板 §1、Prompt 简介](13-提示词与消息模板.md#_1、prompt-简介)

### Q2-6. 如何做 Prompt 版本管理与回归？

如果 Prompt 已经进入生产环境，就不能再把它当成一段“临时改改的字符串”，而要把它当成配置资产或代码资产来管理。

通常会同时管理四样东西：

- Prompt 模板本身：System、User 模板、few-shot 示例、输出格式要求。
- 运行参数：模型名、模型版本、temperature、top_p、max_tokens。
- 评测集：固定 golden questions、典型 badcase、失败样例。
- 发布信息：模板版本号、发布时间、负责人、灰度范围、回滚版本。

更稳的做法通常是：

1. Prompt 和代码一起版本化，或者放进配置中心统一管理。
2. 每次改 Prompt 都跑固定回归集，不只看主观感觉。
3. 记录模板 hash、模型版本和关键参数，避免“明明没改 Prompt，效果却变了”时查不清原因。
4. 上线前做灰度和抽样人工复核，高风险链路保留快速回滚能力。

还有一个很容易被忽略的点：**换底层模型后，旧 Prompt 不一定还能保持原效果。** 所以很多时候回归的对象不是“这段 Prompt 对不对”，而是“Prompt 和当前模型组合起来还稳不稳”。

**常见追问：**

- golden set 应该怎么构建？
- 如果线上效果波动，你怎么判断是 Prompt 问题还是模型版本问题？
- Prompt、模型、索引三者一起变更时，如何设计回滚策略？

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**Prompt 工程化治理能力，而不是只会手改提示词。

**对应章节：**[13 提示词与消息模板 §8、从文件加载提示词](13-提示词与消息模板.md#_8、从文件加载提示词)；[1-2 提示词工程基础 §5、提示词工程的几个注意点](1-2-提示词工程基础.md#_5、提示词工程的几个注意点)

---

## 3、RAG 全链路

### Q3-1. 请描述一个完整的 RAG 流水线。

完整 RAG 一般分**索引阶段**和**检索阶段**。

索引阶段是：文档加载、清洗、切块、向量化、写入向量库，并补充元数据。检索阶段是：接收问题、必要时做 query 改写、检索召回、重排过滤、上下文组装、交给模型生成答案，最后再做引用、脱敏和格式化输出。

工程上真正难的通常不在“把模型接起来”，而在三件事：文档是否被正确解析，切块是否保留语义，检索结果是否真的对当前问题有帮助。线上效果差，大多数时候也是卡在这三层，而不是卡在最后那一轮生成。

**常见追问：**

- chunk 应该怎么切？
- metadata 应该存哪些字段？
- 为什么要加 rerank？

**重要度：**`必刷`（出现次数：3次） | **难度：**`中等`

**考察点：**是否真正理解 RAG，而不是只会说“检索增强生成”。

**对应章节：**[19 RAG检索增强生成 §1、RAG 简介](19-RAG检索增强生成.md#_1、rag-简介)；[19 RAG检索增强生成 §2、RAG 文本处理核心知识](19-RAG检索增强生成.md#_2、rag-文本处理核心知识)

### Q3-2. 文本切块应该怎么设计？有哪些常见坑？

切块的目标不是“切得均匀”，而是“尽量保留对检索有意义的语义单元”。

通常会结合固定长度、段落边界、标题层级和重叠窗口来设计。太大，会导致噪声多、命中不准；太小，会丢上下文，检索回来也无法回答。对于手册、FAQ、制度文档、图文混排 PDF，这些文档往往不能只按字符数切，还要结合版面结构、标题、表格和语义边界。

常见坑包括：切块过碎、忽略标题层级、重叠不足、纯 OCR 文本脏乱不清洗、表格内容被打散，以及把多个主题塞进一个 chunk 导致向量语义污染。

**重要度：**`高频`（出现次数：3次） | **难度：**`中等`

**考察点：**RAG 基础功是否扎实。

**对应章节：**[19 RAG检索增强生成 §2、RAG 文本处理核心知识](19-RAG检索增强生成.md#_2、rag-文本处理核心知识)；[2-RAG 搭建企业私有&个人知识库 §2、知识库的概述](2-RAG-搭建企业私有&个人知识库.md#_2、知识库的概述)

### Q3-3. RAG 效果不好时，你会怎么排查？

排查时可按“检索前、检索中、检索后”三层展开。

- 检索前：看 query 是否表达清楚，是否需要改写、拆问、补充上下文。
- 检索中：看切块、Embedding、向量库索引参数、top_k、过滤条件、重排是否合理。
- 检索后：看拼给模型的上下文是否过长、是否有噪声、是否出现关键信息被淹没、生成提示是否要求“无依据就拒答”。

如果是企业知识库，还要额外查文档质量、版本是否最新、权限过滤是否误伤。很多所谓“模型不聪明”的问题，最后都能定位到文档解析脏、chunk 太碎、召回噪声大或者上下文组装差。

**常见追问：**

- top_k 是不是越大越好？
- 如何识别是召回问题还是生成问题？
- 什么是 Lost in the Middle？

**重要度：**`必刷`（出现次数：1次） | **难度：**`中等`

**考察点：**排障能力、定位思路是否分层。

**对应章节：**[19 RAG检索增强生成 §2、RAG 文本处理核心知识](19-RAG检索增强生成.md#_2、rag-文本处理核心知识)；[19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手](19-RAG检索增强生成.md#_3、rag-综合案例：智能运维助手)

### Q3-4. 混合检索、重排序和查询改写分别解决什么问题？

这三者解决的是三个不同层次的问题。

- 查询改写解决“用户问题表达得不够像检索语句”的问题。
- 混合检索解决“只靠稠密向量可能漏掉关键词命中”的问题。
- 重排序解决“召回了一批候选，但顺序还不够准”的问题。

真实项目里，尤其是制度、产品参数、订单字段、错误码这类知识，关键词常常非常重要，所以仅靠 dense retrieval 往往不够。比较稳的方案通常是“query 改写 + 稠密检索 + 稀疏检索 + rerank”，再结合 metadata 过滤做收口。

**常见追问：**

- 稠密检索和稀疏检索的区别是什么？
- Rerank 放在哪一层最合适？
- 混合检索会不会更贵？

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**是否理解检索优化的职责分工。

**对应章节：**[18 向量数据库与Embedding实战 §6、向量库的写入与检索](18-向量数据库与Embedding实战.md#_6、向量库的写入与检索%EF%BC%88rag-的底层能力%EF%BC%89)；[19 RAG检索增强生成 §2、RAG 文本处理核心知识](19-RAG检索增强生成.md#_2、rag-文本处理核心知识)

### Q3-5. RAG 应该如何接入 Agent 执行链路？

RAG 接到 Agent 里，不能只理解成“先查一遍资料再回答”，更稳的做法通常是把检索能力做成 Agent 可按需调用的一环。

常见有三种接法：

- 前置检索：用户问题一进来先统一检索，再把证据交给 Agent 继续规划。
- 按需检索：把 Retriever / Search 封成工具，Agent 在需要事实依据时主动调用。
- 后置校验：先生成结果，再用检索做证据核对或引用补全。

真实项目里，通常更推荐“按需检索为主，前置检索为辅”。因为不是每一步都需要查知识库，有些步骤是规划、路由、参数确认或工具执行。把 RAG 做成可调用能力，能减少无效检索，也更适合多步任务。后置校验可以作为增强，但通常不适合作为主链路，否则会增加延迟，而且一旦前面已经跑偏，后面再校验修正成本会更高。

**常见追问：**

- 你了解生成过程中多次检索、自适应检索或 Agentic RAG 吗？它和“先检索一次再生成”有什么区别？
- 什么情况下应该从“一次检索”升级成“多轮检索 + 中途补检”？

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**是否理解 Agentic RAG 的接入方式，而不是只会把 RAG 当成固定前置流水线。

**对应章节：**[19 RAG检索增强生成 §1、RAG 简介](19-RAG检索增强生成.md#_1、rag-简介)；[21 Agent智能体 §6、小结：Agent、Tool、Function Calling、RAG、MCP 的区别与联系](21-Agent智能体.md#_6、小结：agent、tool、function-calling、rag、mcp-的区别与联系)

### Q3-6. 为什么企业项目里的 RAG 必须重视权限、版本和引用？

因为企业知识不是“能查到就行”，而是“要查对、查对权限范围、还能追溯来源”。

权限上，向量检索必须做租户隔离、角色过滤、文档级或段落级权限控制，不能把安全寄希望于模型“自觉不回答”。版本上，索引和源文档要可追踪，文档更新后要知道哪些向量需要增量重建。引用上，如果答案不能回溯到原文片段，业务方很难建立信任，也不利于审计和复盘。

所以在企业里，RAG 不只是检索效果问题，更是数据治理问题。

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**企业落地意识，不只停留在 Demo。

**对应章节：**[2-RAG 搭建企业私有&个人知识库 §2、知识库的概述](2-RAG-搭建企业私有&个人知识库.md#_2、知识库的概述)；[19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手](19-RAG检索增强生成.md#_3、rag-综合案例：智能运维助手)

### Q3-7. 什么是 Lost in the Middle？它对 RAG 设计有什么启示？

Lost in the Middle 指的是：上下文一长，模型往往更容易利用开头和结尾的信息，而把中间那部分关键证据“看见了但没用好”。

它对 RAG 的启示非常直接：不是把更多 chunk 塞进上下文就一定更好。如果中间噪声太多，真正关键的证据反而更容易被淹没。

因此，工程上通常采用以下处理方式：

- 先做 rerank 和过滤，再决定谁能进上下文。
- 尽量减少低价值片段，别把“可能相关”都塞进去。
- 重要证据优先放前面，必要时做摘要或结论前置。
- 对复杂问题采用分阶段检索，而不是一次性把大段材料全塞进去。

总结来说：**长上下文不等于高质量上下文，RAG 的核心仍然是“把最有用的证据放到最容易被模型用到的位置”。**

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**长上下文理解能力，以及检索、重排、上下文组装之间的联动意识。

**对应章节：**[19 RAG检索增强生成 §2、RAG 文本处理核心知识](19-RAG检索增强生成.md#_2、rag-文本处理核心知识)；[19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手](19-RAG检索增强生成.md#_3、rag-综合案例：智能运维助手)

### Q3-8. 有了超长上下文模型，还需要 RAG 吗？

多数场景下仍然需要，因为“能塞进去”和“应该塞进去”完全不是一回事。

超长上下文模型确实让长文理解、少量文档内推理变得更方便，但企业场景里更常见的问题不是“模型窗口不够大”，而是：

- 知识总量太大，没法每次都全塞。
- 长上下文成本和延迟都更高。
- 权限过滤、租户隔离、版本控制不能只靠窗口硬塞解决。
- 审计和引用追溯更适合通过检索链路来做。

所以更合理的理解通常是：**长上下文扩大了可处理范围，但没有消灭检索的价值。** 它更适合少量长文档分析、上下文整合和复杂推理；RAG 更适合海量知识缩圈、权限过滤、证据引用和持续更新。

如果压缩成一句话，可以概括为：**长上下文不是 RAG 的替代品，更接近 RAG 的补充能力。**

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**是否理解“长窗口能力”和“检索系统价值”不是同一层问题。

**对应章节：**[19 RAG检索增强生成 §1、RAG 简介](19-RAG检索增强生成.md#_1、rag-简介)；[1-1 大模型认知与工程概览 §1、认识大模型](1-1-大模型认知与工程概览.md#_1、认识大模型)

### Q3-9. 复杂文档 RAG 或多模态 RAG 应该怎么做？

这类场景最大的坑，是把 PDF、扫描件、表格、图片、网页全都当成“普通纯文本”来处理。

更稳的做法通常是先把解析层单独看待：

- 先做版面分析、OCR、表格提取、标题层级恢复，而不是一开始就按字符切块。
- chunk 尽量按结构块切，比如标题、段落、表格、图注，而不是把一张表切成几段残缺文本。
- metadata 要保留页码、章节标题、文档版本、来源文件、坐标或结构位置信息，方便引用和追溯。
- 查询时必要时走多路召回，例如文本召回、表格召回、图片说明召回，再统一重排和组装。

如果是企业知识库，复杂文档 RAG 往往比“模型选型”更影响上限。因为解析错了、表格碎了、图文对应关系丢了，后面再强的模型也很难补回来。

**常见追问：**

- 为什么很多设备手册、制度 PDF 特别难做 RAG？
- OCR 准确率和最终问答效果是什么关系？
- 多模态 RAG 什么时候值得上，什么时候纯文本就够？

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**是否意识到 RAG 不只是检索问题，还包括文档解析、结构恢复和引用追踪。

**对应章节：**[19 RAG检索增强生成 §2、RAG 文本处理核心知识](19-RAG检索增强生成.md#_2、rag-文本处理核心知识)；[2-RAG 搭建企业私有&个人知识库 §2、知识库的概述](2-RAG-搭建企业私有&个人知识库.md#_2、知识库的概述)

### Q3-10. 什么是 Agentic RAG？它和“一次检索后直接生成”有什么区别？

传统 RAG 更接近固定流水线：先检索一次，再把结果交给模型生成答案；Agentic RAG 则更接近一个闭环过程，模型或 Agent 会根据当前进展决定要不要检索、检索什么、是否改写 query、是否继续补检，甚至在发现证据不足时主动回头重查。

两者最大的区别，不在于“有没有检索”，而在于**检索是不是被当成一个动态决策过程来管理**。

- 传统 RAG：流程稳定、成本更可控、实现简单，适合单轮问答和大多数标准知识库场景。
- Agentic RAG：更适合复杂问题、多跳证据、需要自检补检的场景，但代价是链路更长、成本更高、失控风险也更高。

所以工程上通常不会一开始就上 Agentic RAG，而是先看 badcase 是否真的集中在这些问题上：

- 一次检索经常拿不到足够证据。
- 问题本身需要拆问、多轮求证或多源交叉验证。
- 生成前需要先判断“到底该查知识库、查网页，还是查业务系统”。

如果真的要落地 Agentic RAG，我一定会同时补上步数上限、预算限制、失败退出条件和可观测性，否则它很容易从“更聪明的检索”变成“更贵的随机游走”。

**常见追问：**

- 什么情况下应该坚持固定 RAG，而不是升级成 Agentic RAG？
- Agentic RAG 的收益通常体现在哪些 badcase 上？
- 如何防止多轮补检把延迟和成本拉得太高？

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**是否真正理解 RAG 从固定流水线向智能检索闭环演进的边界和代价。

**对应章节：**[19 RAG检索增强生成 §1、RAG 简介](19-RAG检索增强生成.md#_1、rag-简介)；[21 Agent智能体 §1、Agent 简介](21-Agent智能体.md#_1、agent-简介)

---

## 4、检索基础设施与检索优化

### Q4-1. 什么是向量数据库？它和传统数据库有什么区别？为什么不能只用 MySQL？

先下一个定义：向量数据库是一种专门面向“相似度检索”的存储系统，用来保存向量、原始内容和元数据，并支持近邻搜索、过滤和召回。

传统数据库擅长精确过滤、事务和结构化查询，而向量数据库擅长按“语义相似度”做近邻检索。两者不是替代关系，而是分工关系。

如果只用 MySQL，你当然也能存 Embedding，但一旦数据量上来，近似向量检索、ANN 索引、混合检索和大规模召回都会变得低效，而且工程复杂度会明显上升。企业里更常见的做法是：结构化条件走传统数据库，语义召回走向量库，再通过 metadata 把两边结合起来。

**重要度：**`高频`（出现次数：2次） | **难度：**`基础`

**考察点：**底层检索设施理解。

**对应章节：**[18 向量数据库与Embedding实战 §2、向量数据库](18-向量数据库与Embedding实战.md#_2、向量数据库)；[18 向量数据库与Embedding实战 §6、向量库的写入与检索](18-向量数据库与Embedding实战.md#_6、向量库的写入与检索%EF%BC%88rag-的底层能力%EF%BC%89)

### Q4-2. Embedding 是什么？它在应用开发里最核心的价值是什么？

Embedding 的本质，是把文本、图片这类原始内容变成一串固定长度的向量，让“语义关系”尽量映射成“空间关系”。换一种工程化表述，就是把“意思接近”变成“距离接近”，这样程序才能做相似度计算。

它在应用开发里最核心的价值，不只是“把文本编码成数字”，而是让系统第一次具备了按语义检索的能力。所以它常被拿来做语义搜索、相似匹配、去重、聚类、推荐和 RAG 召回。

放到 RAG 里，Embedding 决定的是“问题和知识能不能在向量空间里正确相遇”。如果 Embedding 选错了，后面的向量库、重排、Prompt 再怎么补，也只能在一个偏掉的召回基础上做优化。

另外有两个工程细节需要特别强调：

- 建库和查询最好用同一套 Embedding 模型，不然要么维度对不上，要么即使维度一样，相似度也可能没有意义。
- Embedding 只是把文本变成“稠密向量”这一层，真正检索时往往还会和标量字段过滤、甚至稀疏检索一起配合，不能把它理解成检索系统的全部。

**重要度：**`高频`（出现次数：1次） | **难度：**`基础`

**考察点：**是否理解 Embedding 不是“附属模型”，而是检索基础设施。

**对应章节：**[18 向量数据库与Embedding实战 §1、向量与向量化](18-向量数据库与Embedding实战.md#_1、向量与向量化)；[18 向量数据库与Embedding实战 §4、Embedding 文本向量化](18-向量数据库与Embedding实战.md#_4、embedding-文本向量化)

### Q4-3. 如何选择一个合适的 Embedding 模型？评估它好坏看什么？

通常不会先看榜单，而是先看自己的知识类型和检索目标，再反推模型选型。更合理的思路是先看三件事：

- 语言和领域适配：中文、英文、多语言、代码、法律、金融，适合的模型可能完全不同。
- 建库和查询一致性：建库和查询尽量使用同一套 Embedding 模型，这是底线。
- 成本和延迟是否可接受：不是维度越高越好，也不是模型越大越好，要看知识库规模和查询量能不能撑住。

真正评估时，更应关注“它有没有把整条检索链路整体抬起来”，而不是只看一个榜单分数。比较实用的判断通常有三层：

- 检索层：相关片段有没有更容易被召回，坏例子有没有减少，重排前后的差距大不大。
- 业务层：最终答案的忠实度、引用准确性、任务完成率有没有变好。
- 工程层：延迟、成本、接入复杂度能不能接受。

工程上需要特别强调两点：

- Embedding 选型不是孤立问题，它会和切块策略、索引参数、混合检索、rerank 一起决定上限。
- 公开榜单只能做初筛，真正能决定要不要上线的，还是你自己的知识样本和 badcase。

所以更稳的做法通常是：先选两到三套候选模型跑通，再在自己的知识库样本上做小规模对比，观察召回质量、最终回答质量和成本延迟，最后再决定。

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**Embedding 选型、评测意识，以及“模型一致性 + 检索链路联动”的理解。

**对应章节：**[18 向量数据库与Embedding实战 §4、Embedding 文本向量化](18-向量数据库与Embedding实战.md#_4、embedding-文本向量化)；[18 向量数据库与Embedding实战 §6、向量库的写入与检索](18-向量数据库与Embedding实战.md#_6、向量库的写入与检索%EF%BC%88rag-的底层能力%EF%BC%89)

### Q4-4. 近似检索和精确检索怎么权衡？

精确检索效果更可控，但在大规模数据下成本高、延迟高。近似检索牺牲一部分精确性，换来更好的吞吐和响应速度，所以大部分线上系统都会优先用近似检索。

工程上不是简单二选一，而是看业务要求。如果是高风险检索、数据量不大、对结果一致性要求极高，可以用精确或更保守的索引策略。如果是通用知识问答、商品搜索、海量文档召回，近似检索通常更现实，再配合 rerank 做补偿。

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**性能和效果取舍能力。

**对应章节：**[18 向量数据库与Embedding实战 §2、向量数据库](18-向量数据库与Embedding实战.md#_2、向量数据库)；[18 向量数据库与Embedding实战 §5、通过向量计算语义相似度](18-向量数据库与Embedding实战.md#_5、通过向量计算语义相似度)

### Q4-5. 在什么场景下，知识图谱或图数据库比纯向量检索更有价值？

当问题的核心不只是“语义相似”，而是“实体关系、路径推理、多跳关联、结构化约束”时，知识图谱或图数据库会更有价值。

比如设备故障排查、商品属性关联、组织关系、法规条文引用、依赖链分析，这些场景往往更依赖“谁和谁有什么关系”，而不只是“哪段文本看起来最像”。这时候如果只靠向量检索，容易召回到语义接近但关系错误的内容。

工程上更适合把它理解成增强，而不是简单替代。比较稳的做法通常是：向量检索负责语义召回，知识图谱负责结构化约束、实体消歧和关系推理。只有在问题本身高度结构化、关系链特别关键时，图数据库才可能成为主通路。

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**对“语义召回”和“关系推理”边界的理解，以及检索架构选型能力。

### Q4-6. GraphRAG 适合什么场景？和传统向量 RAG 怎么选？

GraphRAG 更适合实体关系密、需要多跳推理、社区摘要或结构化约束很强的场景。

比如组织关系分析、供应链依赖、设备故障链路、法规条款关联、人物事件网络，这些问题往往不是“哪段文字最像”，而是“谁和谁怎么关联、要经过几跳才能到答案”。这时候图谱或图数据库的优势会更明显。

但工程上通常不会默认一开始就做 GraphRAG。更常见的稳妥路径是：

- 先用传统向量 RAG 打底，解决大多数语义召回问题。
- 当 badcase 明显集中在多跳关系、实体消歧、结构约束时，再引入图谱增强。
- 真正落地时，也常常不是二选一，而是“向量召回 + 图谱召回 + 融合重排”一起做。

更准确的结论是：**只有当问题核心在关系结构上时，图谱路线的收益才会大于复杂度。**

**常见追问：**

- GraphRAG 和知识图谱数据库是什么关系？
- 什么情况下多路召回比纯图谱主路更现实？
- 图谱更新和维护成本会不会太高？

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**GraphRAG 选型能力，以及对复杂度和收益的权衡意识。

---

## 5、Tools、Function Calling 与 Agent

### Q5-1. ReAct 模式是什么？它解决了什么问题？

ReAct 的价值在于把“推理”和“行动”串起来，让模型不只是想，还能基于外部观察不断调整下一步。

它通常表现为 `Thought -> Action -> Observation` 的循环。模型先做当前判断，再决定调用什么工具，然后根据工具返回的结果更新判断，直到任务完成。相比只靠一次性生成，ReAct 更适合不确定路径、多步决策和外部信息依赖强的任务。

这里还需要补充一个重要点：现代 Tool Calling Agent 不一定会把 `Thought` 明文展示出来。实际代码中更常见的是 `AIMessage.tool_calls`、工具执行结果和下一轮消息。因此，更准确的理解方式是：**ReAct 更接近一种工作机制，而不只是某个固定 Prompt 模板。**

工程上要注意，ReAct 的优势是灵活，但代价是链路更长、成本更高、调试更复杂，所以并不是所有场景都值得上完整循环。

**常见追问：**

- Chain of Thought（CoT）是什么？它为什么能提升复杂推理题的效果？
- CoT 和 ReAct 的区别是什么？什么时候只用 CoT 就够了，什么时候要升级到 ReAct？

**重要度：**`高频`（出现次数：3次） | **难度：**`基础`

**考察点：**Agent 运行范式理解。

**对应章节：**[21 Agent智能体 §3、Agent 工作原理（V0.3）](21-Agent智能体.md#_3、agent-工作原理%EF%BC%88v0.3%EF%BC%89)；[17 Tools工具调用 §2、工具调用的工作方式](17-Tools工具调用.md#_2、工具调用的工作方式)

### Q5-2. Tool、Function Calling、Agent 三者是什么关系？

Tool 是能力单元，Function Calling 是调用机制，Agent 是把模型、工具、状态和决策流程组织起来的运行模式。

Tool 解决“能做什么”，Function Calling 解决“怎么发起结构化调用”，Agent 解决“如何围绕目标多轮地决定要不要调用、调用谁、调用几次”。所以 Tool 不等于 Agent，单次 Tool Calling 也不一定等于 Agent。

在真实项目里，很多需求只需要 Tool Calling，不一定要上完整 Agent。只有当任务需要多步规划、反复决策和状态推进时，Agent 才值得引入。

**常见追问：**

- 单工具助手算不算 Agent？
- ReAct 和 Function Calling 什么关系？
- Tool 设计的最小粒度应该是什么？

**重要度：**`必刷`（出现次数：2次） | **难度：**`基础`

**考察点：**概念拆分是否清楚。

**对应章节：**[17 Tools工具调用 §1、Tools 简介](17-Tools工具调用.md#_1、tools-简介)；[21 Agent智能体 §6、小结：Agent、Tool、Function Calling、RAG、MCP 的区别与联系](21-Agent智能体.md#_6、小结：agent、tool、function-calling、rag、mcp-的区别与联系)

### Q5-3. 一个 Agent 应该如何设计？它通常由哪些核心组件构成？

如果按最小理解版概括，可以写成：**Agent = 模型 + 工具集 + 运行循环 + 当前状态**。

- 模型：负责理解目标、分析当前局面、决定下一步。
- 工具集：负责提供外部能力，比如搜索、数据库、文件系统、业务 API。
- 运行循环：负责让系统不是只回答一次，而是能“想一步、做一步、看结果、再决定下一步”。
- 当前状态：负责保存消息、工具返回、中间结果和线程上下文。

在这个最小骨架之上，记忆、规划、反思、多智能体协作都可以继续往上叠，但它们更适合作为“扩展能力”来理解，而不是每个 Agent 一上来都必须全部具备。

如果从工程设计看，一个可落地的 Agent，重点应控制五件事：

- 目标和职责：一个 Agent 解决什么问题，要尽量单一，不要什么都做。
- 工具边界：只暴露完成任务真正需要的能力，避免给模型一把通吃的权限。
- 状态设计：当前任务进展、中间结论、消息历史放在哪里，要显式设计。
- 停止条件：什么时候继续、什么时候澄清、什么时候转人工、什么时候结束，不能模糊。
- 治理能力：日志、Trace、重试、超时、审计、人工接管都要补齐。

概括来说：Agent 设计的重点不是“堆更多能力”，而是围绕 **模型、工具、循环、状态** 四条主线，把系统做得更可控、更可追踪、更能稳定交付结果。

**常见追问：**

- 在构建一个复杂 Agent 时，你认为最主要的挑战是什么？
- 为什么很多 Agent 不是能力不够，而是状态、边界和治理没设计好？

**重要度：**`必刷`（出现次数：2次） | **难度：**`中等`

**考察点：**Agent 架构能力，而不是停留在概念层。

**对应章节：**[21 Agent智能体 §1、Agent 简介](21-Agent智能体.md#_1、agent-简介)；[21 Agent智能体 §6、小结：Agent、Tool、Function Calling、RAG、MCP 的区别与联系](21-Agent智能体.md#_6、小结：agent、tool、function-calling、rag、mcp-的区别与联系)

### Q5-4. Function Calling 的基本原理是什么？

Function Calling 的核心分工，可以概括成一句话：模型负责决策，程序负责执行。

更完整地说，这条链路通常是：

1. 宿主程序把工具的 `name`、`description`、参数 schema 一起发给模型。
2. 模型判断要不要调用工具，如果要，会先返回结构化的 `tool_calls`，而不是直接给最终自然语言。
3. 宿主程序读取 `AIMessage.tool_calls`，真正去执行 Python 函数、HTTP API、数据库查询或业务服务。
4. 程序把执行结果封成 `ToolMessage` 或等价消息，再交回模型。
5. 模型基于工具结果生成最终答复。

所以 Function Calling 不是模型自己去调 API，它只是生成“调用哪个工具、传什么参数”的结构化意图。真正的鉴权、参数校验、超时、幂等、重试和安全控制，仍然都在宿主程序这一层。

如果要答得更工程化，还需要补一句：Function Calling 解决的是“模型如何表达调用意图”，不解决“工具是否安全、是否允许调用、调用失败怎么兜底”这些问题。

**常见追问：**

- Function Calling 和文本解析调用有什么区别？
- 为什么生产环境更推荐原生 Tool Calling？
- 工具执行失败怎么处理？

**重要度：**`必刷`（出现次数：1次） | **难度：**`中等`

**考察点：**是否理解模型和宿主程序的职责边界。

**对应章节：**[17 Tools工具调用 §1、Tools 简介](17-Tools工具调用.md#_1、tools-简介)；[17 Tools工具调用 §2、工具调用的工作方式](17-Tools工具调用.md#_2、工具调用的工作方式)

**来源：**腾讯AI后台工程师一面（实际大厂面试题）

### Q5-5. 设计 Tool 时最值得重视的工程原则是什么？

最值得重视的四点是：单一职责、明确 schema、可观测、可失败。

单一职责意味着一个 Tool 只做一件清晰的事，避免“大而全万能工具”。明确 schema 是为了让模型更稳定地理解参数含义。可观测意味着每次调用都要能追踪请求、参数、耗时、结果和错误。可失败意味着工具必须有超时、异常码、重试策略和降级逻辑，而不是假设一定成功。

如果 Tool 要连业务系统，还要加权限校验、幂等控制和审计日志。因为工具一旦从“查天气”变成“发消息、下工单、写数据库”，风险等级就完全不同了。

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**是否有把工具接到生产系统的经验意识。

**对应章节：**[17 Tools工具调用 §3、自定义 Tool](17-Tools工具调用.md#_3、自定义-tool：从最简单的工具开始)；[17 Tools工具调用 §4、参数 schema：为什么要配合 Pydantic](17-Tools工具调用.md#_4、参数-schema：为什么要配合-pydantic)

### Q5-6. 如果让你实现一个“查天气、查新闻”的 AI 助手，你会怎么设计？

这类题在面试里更推荐先做场景判断，再谈方案。像查天气、查新闻这种需求，核心不是复杂规划，而是“意图识别 + 工具调用 + 结果整合”。

一个比较稳的实现通常包括四层：

- 输入与路由层：先判断用户是查天气、查新闻，还是两者都要。必要时抽取城市、时间、新闻主题等参数。
- 工具层：把天气查询和新闻检索分别封成清晰的 Tool，定义好 schema、参数说明、异常返回和超时策略。
- 调度层：先用 Function Calling 或轻量 Agent，让模型决定调用哪个工具、怎么传参、要不要串联多个工具。
- 输出层：把工具结果做统一整理，比如天气给关键字段，新闻给摘要和来源，最后再由模型生成自然语言回复。

如果需求只是单轮查天气、查新闻， `Prompt + Function Calling` 往往就够了，不一定要上完整 ReAct Agent。只有在需求升级成“先查天气，再根据天气推荐本地新闻，再继续追问某条新闻细节”这种多步动态链路时，Agent 的价值才会更明显。

工程上需要特别关注三点：工具描述要清楚，避免模型乱调；外部 API 要有降级和超时；结果输出最好带来源或关键字段，避免模型把工具结果又二次编造一遍。

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**能否把一个简单助手拆成“意图、工具、调度、输出”四层，而不是一股脑说上 Agent。

**对应章节：**[17 Tools工具调用 §5、天气助手实战](17-Tools工具调用.md#_5、天气助手实战：把-tool-跑成业务闭环)；[21 Agent智能体 §5、实操与案例](21-Agent智能体.md#_5、实操与案例)

**来源：**腾讯AI后台工程师一面（实际大厂面试题）

### Q5-7. 什么是“工具幻觉”？工程上怎么缓解？

工具幻觉指的是：模型调用了不存在的工具、传了不合理的参数，或者在只该读数据时却试图触发写操作。

这类问题在工具数量多、描述模糊、schema 不清晰时特别常见。模型有时不是“不会用工具”，而是“对工具边界理解错了”。

工程上通常会这样兜底：

- 工具注册表白名单：不存在的工具名直接拒绝。
- schema 强校验：参数类型、必填项、枚举值都要在运行时校验，不信任模型返回。
- 工具集收敛：按场景暴露最小工具集，别让模型在几十个相近工具里乱猜。
- 描述清晰：工具名、description、参数含义要能明显区分读写边界和适用场景。
- 高风险确认：涉及发消息、写数据库、发工单、下单等副作用动作，必须审批或二次确认。
- 失败反馈：把错误原因回传给模型，让它有机会修正，但要限制重试次数，避免死循环。

可以概括为：**Tool Calling 不是“接上就行”，而是要让模型“调得准、调得住、调错了也出不了大事”。**

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**对 Tool Use 稳定性和风险控制的理解。

**对应章节：**[17 Tools工具调用 §6、从课程案例走向真实项目](17-Tools工具调用.md#_6、从课程案例走向真实项目)；[17 Tools工具调用 §4、参数 schema：为什么要配合 Pydantic](17-Tools工具调用.md#_4、参数-schema：为什么要配合-pydantic)

### Q5-8. Function Calling 和“让模型输出 JSON 再自己解析”有什么区别？

两者表面上都像“模型输出结构化结果”，但稳定性和工程边界差别很大。

- 让模型输出 JSON，更接近在 Prompt 层提出要求。它简单、通用、起步快，但模型一旦多说一句自然语言、少一个字段、类型写错，程序端就要自己兜底。
- Function Calling 更接近协议级结构化输出。模型不是随便返回一段文本，而是明确返回工具名和参数，宿主按约定解析和执行，可靠性通常更高。

因此，在生产环境中通常这样判断：

- 如果只是抽取字段、做轻量结构化返回，而且平台原生能力有限，先用 JSON + parser。
- 如果要进入真实工具调用、外部系统编排、副作用执行，优先用原生 Function Calling 或等价 Tool Use 协议。

更关键的区别还在于职责边界。JSON 解析更接近“你让模型尽量长成这个格式”；Function Calling 更接近“模型和宿主之间有一层明确契约”。这层契约越清楚，后面的校验、审计、重试和观测就越好做。

**常见追问：**

- 什么时候 JSON + parser 已经够用？
- 为什么 Function Calling 更适合接生产系统？
- 如果平台没有原生 Function Calling，怎么尽量把 JSON 方案做稳？

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**结构化输出和工具调用之间的协议级差异理解。

**对应章节：**[14 输出解析器 §4、结构化输出](14-输出解析器.md#_4、结构化输出)；[17 Tools工具调用 §2、工具调用的工作方式](17-Tools工具调用.md#_2、工具调用的工作方式)

### Q5-9. 当工具很多时，如何控制上下文长度和调用稳定性？

工具一多，问题通常不再是“会不会调工具”，而是“会不会在一堆相似工具里选错、调错、调得越来越乱”。

比较稳的做法通常有四类：

- 分层暴露：先按业务域拆成搜索类、数据类、执行类、写操作类，不要一次把所有工具都暴露给同一个 Agent。
- 动态选择：先做 Tool Retrieval 或路由，只把 Top-N 个最相关工具描述放进当前上下文，而不是全量列出来。
- 工具聚合：把过细的底层 API 封装成更高层的业务动作，减少模型在几十个相近函数里猜名字。
- 描述治理：工具名、description、参数说明里要明确“什么时候用、什么时候不用、有没有副作用”。

如果再往前走一步，生产里还可以把“工具选择”本身做成一个独立阶段，比如先做意图分类或子域路由，再进入具体工具调用。这样既能控上下文长度，也能降低工具幻觉和误调用概率。

可以概括为：**工具多不是问题，关键是别让模型在一个没有层次的工具海里盲选。**

**常见追问：**

- 工具太多时，应该优先做路由还是优先改工具粒度？
- Tool Retrieval 和普通知识检索有什么区别？
- 为什么业务动作级工具通常比原子 API 更适合模型调用？

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**多工具场景下的上下文治理和工具编排能力。

**对应章节：**[17 Tools工具调用 §6、从课程案例走向真实项目](17-Tools工具调用.md#_6、从课程案例走向真实项目)；[21 Agent智能体 §5、实操与案例](21-Agent智能体.md#_5、实操与案例)

---

## 6、Agent 框架与编排：LangChain、LCEL、LangGraph

### Q6-1. LangGraph 相比普通 Workflow 或链式调用，最大的价值是什么？

LangGraph 最大的价值是把复杂流程中的状态、节点、边和循环显式表达出来，让大模型驱动的动态流程真正可设计、可追踪、可恢复。

普通链式调用适合简单串行流程，Workflow 适合固定路径，而 LangGraph 更适合有分支、循环、人工中断、状态持久化和多 Agent 协作的任务。它不是“换一种写法”，而是把复杂控制流从隐式逻辑变成显式图结构。

所以当你发现系统开始出现“要不要继续查、什么时候结束、失败后从哪恢复、状态怎么跨轮保留”这些问题时，LangGraph 的优势就出来了。

**常见追问：**

- LangGraph 和 Agent 的关系是什么？
- 什么场景下普通 Workflow 就够了？
- 图编排的维护成本会不会更高？

**重要度：**`必刷`（出现次数：1次） | **难度：**`中等`

**考察点：**是否理解图编排的必要性。

**对应章节：**[22 LangGraph概述与快速入门 §1、LangGraph 简介](22-LangGraph概述与快速入门.md#_1、langgraph-简介)；[23 LangGraphAPI：图与状态 §1、Graph API 之 Graph](23-LangGraphAPI：图与状态.md#_1、graph-api-之-graph%EF%BC%88图%EF%BC%89)

### Q6-2. 在 LangGraph 里，State、Node、Edge 分别代表什么？

State 是共享状态，Node 是处理逻辑，Edge 是流转规则。

State 决定图里“大家共同操作的上下文”是什么；Node 决定每一步具体做什么，比如调用模型、查库、执行工具；Edge 决定执行完当前节点后下一步去哪里，可以是固定跳转，也可以是条件路由。

真实项目里，LangGraph 设计得好不好，往往取决于 State 是否清晰、Node 粒度是否合理、Edge 条件是否可解释。很多图写得难维护，不是因为图本身复杂，而是把太多隐式逻辑塞进了一个节点。

**重要度：**`高频`（出现次数：1次） | **难度：**`基础`

**考察点：**LangGraph 基础心智模型。

**对应章节：**[23 LangGraphAPI：图与状态 §2、Graph API 之 State](23-LangGraphAPI：图与状态.md#_2、graph-api-之-state%EF%BC%88状态%EF%BC%89)；[24 LangGraphAPI：节点、边与进阶 §2、Graph API 之 Edge](24-LangGraphAPI：节点、边与进阶.md#_2、graph-api-之-edge%EF%BC%88边%EF%BC%89)

### Q6-3. LangChain 在今天的价值是什么？为什么不是直接手写 SDK 就够了？

LangChain 的价值不在于“能不能调模型”，而在于它把模型输入输出、Prompt、Parser、Retriever、Tools、Memory、Callbacks 等常见能力统一成了一套可组合接口。

如果只是做一个最小 Demo，直接手写 SDK 当然可以。但一旦进入多模型接入、链式编排、结构化输出、可观测和长期维护阶段，统一抽象会明显降低代码分散度。它真正解决的是“应用层编排和生态整合”问题，而不是“替你发一个 HTTP 请求”。

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**框架选型判断，而不是盲目崇拜框架。

**对应章节：**[9 LangChain概述与架构 §2、LangChain 定位](9-LangChain概述与架构.md#_2、langchain-定位)；[9 LangChain概述与架构 §4、LangChain 核心模块](9-LangChain概述与架构.md#_4、langchain-核心模块)

### Q6-4. 如何使用 LangChain 开发一个 Agent？

一个最小可用的 LangChain Agent，通常按两条路线去讲。

- classic 路线：模型、工具、Prompt、`create_tool_calling_agent(...)`、`AgentExecutor(...)` 一层层组起来，更适合理解内部结构。
- 1.x 路线：直接用 `create_agent(...)`，背后由基于 LangGraph 的运行时去驱动循环、状态和工具调用，更接近当前官方主线。

不管走哪条路线，底层都还是同一条主线：

- 先定义 Tools，把外部能力封成清晰的能力单元。
- 再选择 LLM，并让模型知道可调用的工具 schema。
- 然后设计 Prompt，明确角色、工具使用规则、停止条件和输出边界。
- 最后让系统形成“模型决策 -> 工具执行 -> 结果回传 -> 继续或结束”的闭环。

如果是简单场景，可以直接走高层封装；如果是复杂场景，仍然要能讲清楚底层运行主线。面试里真正加分的不是背 API 名，而是能说清 Agent 为什么会调用工具、什么时候停、失败了怎么兜底。

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**是否理解 Agent 不是“调一个 create_agent 就结束”，而是清楚底层组成。

**对应章节：**[21 Agent智能体 §5、实操与案例](21-Agent智能体.md#_5、实操与案例)；[17 Tools工具调用 §5、天气助手实战](17-Tools工具调用.md#_5、天气助手实战：把-tool-跑成业务闭环)

### Q6-5. LCEL 的价值是什么？为什么说它不只是语法糖？

LCEL 的核心价值是把 Prompt、Model、Parser、Retriever、函数逻辑都抽象成 Runnable，然后通过统一方式组合和调用。

它不只是写法更短，而是让顺序链、分支链、并行链、函数链能够用同一种接口去拼装、调试和替换。这对真实项目很有价值，因为你后面做日志、流式、批处理、回调和局部替换时，统一接口会让系统更可维护。

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**是否理解链式编排的统一接口思想。

**对应章节：**[15 LCEL与链式调用 §1、Runnable 与统一调用方式](15-LCEL与链式调用.md#_1、runnable-与统一调用方式)；[15 LCEL与链式调用 §2、LCEL 简介](15-LCEL与链式调用.md#_2、lcel-简介)

### Q6-6. LangGraph 的进阶特性里，你觉得最有工程价值的是哪些？

优先关注四类能力：流式处理、持久化、时间回溯、子图。这四类也刚好是 LangGraph 高级特性的主线。

先看流式。LangGraph 的流式不只是“模型 token 一点点吐出来”，更重要的是它能把整张图执行过程流出来。实际项目里常用的 `stream_mode` 有这些：

- `values`：看每一步结束后的完整状态快照。
- `updates`：看当前这一步到底改了哪些字段。
- `messages`：看模型消息片段或 token 流。
- `custom`：在节点里主动推送业务进度，比如“正在检索知识库”。

再看持久化。LangGraph 里的 `checkpointer` 更接近线程内、会话内的短期记忆，适合按 `thread_id` 保存图状态，用于断点恢复、人机协同和多轮任务承接；如果要跨线程、跨会话保存更长期的信息，则更接近 Store 这条线。

时间回溯的工程价值主要在排障、复盘和重放。很多复杂 Agent 不是最后结果错了，而是中间某一步状态被污染了，Time Travel 能帮你从具体节点回看甚至重跑。

子图的价值则是把复杂系统拆成可复用模块。比如“检索子图”“审批子图”“报告生成子图”可以独立封装，主图只负责更高层编排。

这四类能力可以概括为一句话：流式解决可观察，持久化解决可恢复，时间回溯解决可复盘，子图解决可维护。四个一起上，LangGraph 才真正像生产基础设施，而不只是一个能跑通的 Demo 图。

**常见追问：**

- Checkpointer 和长期记忆有什么区别？
- Time-Travel 适合什么场景？
- 什么时候应该拆子图？

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**是否关注真实生产能力，而不是只会 HelloWorld。

**对应章节：**[25 LangGraph高级特性 §1、流式处理（Streaming）](25-LangGraph高级特性.md#_1、流式处理%EF%BC%88streaming%EF%BC%89)；[25 LangGraph高级特性 §2、状态持久化（Persistence）](25-LangGraph高级特性.md#_2、状态持久化%EF%BC%88persistence%EF%BC%89)；[25 LangGraph高级特性 §3、时间回溯（Time-Travel）](25-LangGraph高级特性.md#_3、时间回溯%EF%BC%88time-travel%EF%BC%89)；[25 LangGraph高级特性 §4、子图（Subgraphs）](25-LangGraph高级特性.md#_4、子图%EF%BC%88subgraphs%EF%BC%89)

### Q6-7. Checkpoint、HITL、Time-Travel 在面试里怎么讲得更工程化？

这三个概念适合放在一起理解，因为它们共同解决的是：**复杂 Agent 不是“能跑起来”就够了，还要能停、能看、能批、能继续。**

- Checkpoint：解决“做到一半能不能恢复”，适合长任务、断点续跑、失败重放。
- HITL：解决“高风险动作要不要人工拍板”，适合支付、删改数据、对外发送这类动作前的人工确认。
- Time-Travel：解决“出问题后怎么回看和复盘”，适合排障、调试和重跑特定阶段。

如果用一句很工程化的话来概括，就是：

> Checkpoint 负责可恢复，HITL 负责可控制，Time-Travel 负责可复盘。

这三个能力放在一起，面试官通常会感觉你理解的不是“图会不会画”，而是“系统上线以后怎么治理”。

**常见追问：**

- 哪些节点你一定会加人工审批？
- Checkpointer 和长期记忆 / Store 的边界怎么讲？
- 什么时候时间回溯只是调试利器，什么时候它已经是生产必需？

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**LangGraph 生产能力理解，以及对恢复、审批、复盘三类能力的归纳能力。

**对应章节：**[25 LangGraph高级特性 §2、状态持久化（Persistence）](25-LangGraph高级特性.md#_2、状态持久化%EF%BC%88persistence%EF%BC%89)；[25 LangGraph高级特性 §3、时间回溯（Time-Travel）](25-LangGraph高级特性.md#_3、时间回溯%EF%BC%88time-travel%EF%BC%89)

---

## 7、记忆、MCP 与多智能体

### Q7-1. 上下文窗口、短期记忆、长期记忆分别是什么关系？

上下文窗口是模型单次推理能看到的内容上限，短期记忆是会话级状态，长期记忆是跨会话保留的用户或任务信息。

工程上不能把这三者混为一谈。窗口是昂贵资源，不能无限塞历史。短期记忆一般保留当前任务相关历史、摘要、线程状态。长期记忆则更适合存偏好、画像、历史结论和可复用事实，需要按需检索，不应该每次全量放进 prompt。

所以一个成熟的系统通常是：窗口里只放高信号上下文，短期记忆保证当前线程不断档，长期记忆通过数据库或向量库按需召回。

**常见追问：**

- 记忆和 RAG 的区别是什么？
- 为什么说记忆不是训练模型？
- Redis 在记忆里适合做什么？
- 如果上下文太长被截断了，你会选滑动窗口、摘要压缩还是检索式补充？怎么判断？

**重要度：**`必刷`（出现次数：3次） | **难度：**`中等`

**考察点：**对话系统和 Agent 的状态设计能力。

**对应章节：**[16 记忆与对话历史 §1、记忆简介](16-记忆与对话历史（含Redis基础）.md#_1、记忆简介)；[25 LangGraph高级特性 §2、状态持久化（Persistence）](25-LangGraph高级特性.md#_2、状态持久化%EF%BC%88persistence%EF%BC%89)

### Q7-2. 如何为 Agent 设计短期记忆和长期记忆系统？技术上通常怎么落地？

先把“记忆”拆成两层，不然很容易把所有信息都塞进上下文，最后变成又贵又乱。

- 短期记忆：解决当前会话或当前线程不断档的问题，核心是“读历史 -> 拼进提示 -> 调模型 -> 写回历史”。
- 长期记忆：解决跨会话保留用户偏好、画像、历史结论和可复用事实的问题，核心是“存结构化信息，按需召回”，而不是每轮全量塞进 prompt。

技术上，短期记忆常见做法是把消息历史或线程状态持久化到内存、Redis 或 checkpointer 里，再通过 `MessagesPlaceholder` 或图状态在下一轮重新注入；长期记忆更适合放在数据库、向量库，或者在关系很重要的场景里放进知识图谱。一个比较稳的工程思路是：短期记忆服务当前任务连续性，长期记忆服务跨任务复用，二者分开设计。

在 LangChain / LangGraph 体系下，`RunnableWithMessageHistory + BaseChatMessageHistory` 更适合理解为“对话历史注入”，而 LangGraph persistence / checkpointer 更适合理解为线程级状态持久化。前者更适合先把“历史消息怎么读写”讲明白，后者更适合 Agent、图编排和线程级状态管理。

因此，真正落地时通常这样划分：

- 聊天助手或轻量多轮问答：优先消息历史方案。
- 复杂 Agent 或 LangGraph：优先 `thread_id + checkpointer` 方案。
- 跨会话偏好、事实、用户画像：走长期存储，按需检索，不直接硬塞上下文。

如果继续追问“超长多轮对话如何兼顾不断档和节省 token”，通常还会补充四种常见手段：

- 滑动窗口：只保留最近 N 轮原文，简单直接，但容易丢早期约束。
- 周期性摘要：每隔几轮把历史压成结构化总结，保留目标、已确认事实、待办和偏好。
- 检索式补充：把旧对话写入向量库或长期存储，按当前问题召回相关片段，而不是把所有旧消息都塞回窗口。
- 结构化记忆槽：像城市、会员等级、偏好、关键状态这类固定信息直接落键值或数据库，不让模型每次“回忆”。

所以记忆系统不是“历史保存得越多越好”，而是要区分什么该原样保留，什么该摘要，什么该结构化，什么该按需检索。

**常见追问：**

- `RunnableWithMessageHistory` 和 LangGraph persistence / checkpointer 怎么理解各自的定位？
- Redis 更适合拿来做短期记忆持久化，还是长期记忆？

**重要度：**`高频`（出现次数：2次） | **难度：**`较难`

**考察点：**记忆分层设计能力，以及对短期状态、长期知识、外部存储边界的理解。

**对应章节：**[16 记忆与对话历史 §4、RunnableWithMessageHistory 与 BaseChatMessageHistory](16-记忆与对话历史（含Redis基础）.md#_4、实现类介绍：runnablewithmessagehistory-与-basechatmessagehistory)；[25 LangGraph高级特性 §2、状态持久化（Persistence）](25-LangGraph高级特性.md#_2、状态持久化%EF%BC%88persistence%EF%BC%89)

### Q7-3. 什么是 MCP？它解决的核心问题是什么？它和 Tool、RAG、Agent 有什么区别？

如果先给一句定义，MCP 是 Model Context Protocol，也就是模型上下文协议。它是一套开放标准，用来规范 AI 应用如何以统一方式连接外部工具、资源和提示模板。

MCP 本质上是在做“模型能力接入的统一协议层”，解决的不是“模型能不能调工具”，而是“不同 AI 应用怎样用统一方式接外部工具、资源和上下文”。

更直观的理解是，MCP 最适合被看成 AI 世界的统一插口。它统一的不是模型本身，而是 Host、Client、Server 之间发现、暴露和调用能力的方式。MCP Server 不只会暴露 Tools，还可以暴露 Resources 和 Prompts。

- Tool / Function Calling：解决模型如何表达“我要调用哪个工具、传什么参数”。
- RAG：解决模型如何拿到外部知识。
- Agent：解决谁来规划、决策、调用这些能力。
- MCP：解决这些外部能力如何被标准化暴露和接入。

所以 MCP 不等于 Agent，也不等于 Tool。它更偏协议和生态层，价值在于一次暴露、多处复用、统一 schema、降低接入成本。

**常见追问：**

- MCP Server 通常暴露哪些能力？
- STDIO 和 HTTP 传输怎么选？
- 为什么企业会关心 MCP？

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**协议层理解能力。

**对应章节：**[20 MCP模型上下文协议 §2、MCP 简介](20-MCP模型上下文协议.md#_2、mcp-简介)；[20 MCP模型上下文协议 §3、MCP 能做什么](20-MCP模型上下文协议.md#_3、mcp-能做什么)

**来源：**腾讯AI后台工程师一面（实际大厂面试题）

### Q7-4. MCP 和 Function Calling 的关系是什么？

Function Calling 更接近模型侧的“结构化调用机制”，MCP 更接近应用侧的“统一能力接入协议”。

前者解决的是模型如何表达“要调用哪个函数、传什么参数”；后者解决的是不同外部工具、资源、提示模板如何用统一标准暴露给客户端。两者不是替代关系，而是上下层关系。

可以简单理解为：Function Calling 更靠近模型决策，MCP 更靠近生态接入和协议标准化。真正落地时，Agent 完全可以在 MCP 暴露的能力之上继续用 Function Calling 做调用决策。

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**协议层和调用机制的边界理解。

**对应章节：**[20 MCP模型上下文协议 §2、MCP 简介](20-MCP模型上下文协议.md#_2、mcp-简介)；[17 Tools工具调用 §2、工具调用的工作方式](17-Tools工具调用.md#_2、工具调用的工作方式)

### Q7-5. MCP 是如何做到跨平台兼容的？

MCP 的跨平台兼容，本质上来自“统一协议，而不是统一实现”。

也就是说，不同平台、不同语言、不同宿主程序，只要都遵循同一套消息结构、能力暴露方式和调用约定，就能在协议层互通。这样客户端不需要为每一个外部系统写一套私有接入方式，服务端也能按标准暴露能力。

所以 MCP 的价值不在于它绑定了某个技术栈，而在于它把接入差异收敛成了统一的协议面。

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**协议标准化的理解。

**对应章节：**[20 MCP模型上下文协议 §5、MCP 架构知识](20-MCP模型上下文协议.md#_5、mcp-架构知识)

### Q7-6. MCP 技术协议的主体内容是什么？

如果从协议层展开，MCP 的主体内容按四层来讲最清楚：

- 参与角色：Host、Client、Server。
- 能力类型：Tools、Resources、Prompts。
- 通信机制：能力发现、请求、响应、错误、通知。
- 传输方式：stdio、Streamable HTTP 等承载协议的通道。

这里还需要补充一句细节：

- Tools 更偏 model-controlled，适合让模型自动决定要不要调用。
- Resources 更偏 application-driven，通常由宿主决定如何纳入上下文。
- Prompts 更偏 user-controlled，适合复用提示模板或工作流模板。

这样答出来，面试官通常能看出你理解的是协议本身，而不是只把 MCP 当成某个“现成插件市场”。

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**是否理解 MCP 协议层的基本构成。

**对应章节：**[20 MCP模型上下文协议 §5、MCP 架构知识](20-MCP模型上下文协议.md#_5、mcp-架构知识)；[20 MCP模型上下文协议 §3、MCP 能做什么](20-MCP模型上下文协议.md#_3、mcp-能做什么)

### Q7-7. MCP 服务器开发流程是什么？

一个 MCP Server 的典型开发流程通常是：

1. 明确要暴露的能力边界，是工具、资源还是提示模板。
2. 定义输入输出 schema 和错误处理方式。
3. 选择传输方式，比如 STDIO 或 HTTP。
4. 实现服务端逻辑，并补齐鉴权、日志、超时和异常处理。
5. 在客户端完成注册、发现、调用和联调测试。

工程上最容易被忽略的是能力边界和错误处理。MCP Server 不是简单把现有 API 套一层壳，而是要把能力设计成真正适合模型消费的接口。

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**是否理解 MCP 不只是“会用”，还包括服务端建设。

**对应章节：**[20 MCP模型上下文协议 §4、怎么用 MCP](20-MCP模型上下文协议.md#_4、怎么用-mcp)；[20 MCP模型上下文协议 §6、案例实战：本地 MCP 天气服务与客户端](20-MCP模型上下文协议.md#_6、案例实战：本地-mcp-天气服务与客户端)

### Q7-8. Agent 应该如何接入 MCP 工具？

Agent 接入 MCP 工具，核心是把 MCP 暴露出来的能力纳入自己的工具注册和调度体系。

通常的思路是：

- 先发现 MCP Server 暴露的工具或资源。
- 再把这些能力转换成 Agent 能消费的工具描述和 schema。
- 在执行时让模型决定何时调用，宿主负责真正发起 MCP 请求。
- 把结果回传给 Agent，进入下一轮决策。

真正的关键不在“接通”，而在“如何保证接通之后仍然可控”，包括权限、超时、失败重试、观测和审计。

**常见追问：**

- MCP 在你的架构里是只做权限检查，还是会和环境级安全沙箱一起工作？
- 如果已经有 MCP，为什么还需要容器、只读挂载或系统级隔离？

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**Agent 架构与 MCP 的结合方式。

**对应章节：**[20 MCP模型上下文协议 §4、怎么用 MCP](20-MCP模型上下文协议.md#_4、怎么用-mcp)；[20 MCP模型上下文协议 §6、案例实战：本地 MCP 天气服务与客户端](20-MCP模型上下文协议.md#_6、案例实战：本地-mcp-天气服务与客户端)

### Q7-9. MCP 的流式 HTTP 传输核心优势是什么？

流式 HTTP 的核心价值，是让结果可以边产生边返回，而不是必须等整次调用结束后一次性返回。

这样做有三个直接好处：

- 降低首包延迟，用户更快看到反馈。
- 支持长任务的中途进度回传，减少“卡死感”。
- 更利于宿主做取消、超时和部分结果处理。

对于 Agent 或研究型任务，这种能力尤其重要，因为很多调用本来就不是“瞬时完成”的。

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**流式协议在体验和并发上的价值理解。

**对应章节：**[20 MCP模型上下文协议 §5、MCP 架构知识](20-MCP模型上下文协议.md#_5、mcp-架构知识)

### Q7-10. MCP 调用如何保证并发？

MCP 并发能力不只是协议本身决定的，更取决于宿主和服务端如何设计请求处理模型。

要保证并发，通常要关注：

- 请求是否有唯一标识，避免响应错配。
- 服务端是否支持并行处理，而不是串行阻塞。
- 工具执行是否有超时、限流和优先级控制。
- 客户端是否能正确管理多请求上下文。

如果底层工具本身很慢，协议再好也救不了，所以并发治理要看“协议层 + 服务层 + 工具层”三层一起设计。

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**高并发调用下的协议和宿主设计能力。

**对应章节：**[20 MCP模型上下文协议 §5、MCP 架构知识](20-MCP模型上下文协议.md#_5、mcp-架构知识)

### Q7-11. A2A 和 MCP 的区别是什么？什么时候需要多智能体？

MCP 更关注“模型和外部能力怎么接”，A2A 更关注“Agent 和 Agent 之间怎么协作”。

前者偏工具与资源接入标准，后者偏多智能体通信和分工协作。如果系统只是需要接搜索、数据库、文件系统，MCP 的价值更明显；如果系统已经演化出多个角色明确、职责分离的 Agent，比如规划、检索、执行、审阅各自独立，那么 A2A 或多智能体编排才有意义。

多智能体不是越早越好。任务如果单 Agent 就能清晰处理，多智能体只会增加通信、调试和治理成本。只有在职责边界清晰、单 Agent prompt 已经过载、流程确实需要角色分治时，拆分才划算。

**常见追问：**

- Supervisor 和 Handoff 怎么选？
- 多智能体最常见的失败点是什么？
- 什么情况下 Skill 比独立 Agent 更合适？
- A2A 和 LangGraph 这类应用内编排框架、普通 Agent 框架的边界到底是什么？
- Agent Skills 和 Tool、独立 Agent 的边界怎么理解？什么时候更适合做成 Skill 而不是再拆一个 Agent？

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**协议边界和系统拆分能力。

**对应章节：**[26 LangGraph多智能体与A2A §1、A2A 协议与多智能体架构](26-LangGraph多智能体与A2A.md#_1、a2a-协议与多智能体架构)；[26 LangGraph多智能体与A2A §2、Supervisor 与 Handoff](26-LangGraph多智能体与A2A.md#_2、supervisor-与-handoff)；[26 LangGraph多智能体与A2A §3、Skills 与多智能体的边界](26-LangGraph多智能体与A2A.md#_3、skills-与多智能体的边界)；[27 Agent Skills智能体技能与AI编程工具实践](27-Agent%20Skills智能体技能与AI编程工具实践.md)

**来源：**腾讯AI后台工程师一面（实际大厂面试题）

### Q7-12. 有哪些热门的 MCP 工具？

常见受关注的 MCP 工具通常集中在几类：

- 浏览器自动化类，比如 Playwright。
- 数据与后端类，比如数据库、Supabase 一类服务。
- 文件与代码类，比如本地文件系统、代码库。
- 搜索与知识类，比如网页搜索、知识库检索。

面试里更重要的不是背全名字，而是知道为什么这些工具受欢迎：因为它们覆盖了 Agent 最常见的外部能力需求。

**重要度：**`低频`（出现次数：1次） | **难度：**`基础`

**考察点：**对 MCP 生态有基本了解，但不要求死记硬背。

---

## 8、平台实践与框架选型：Coze、Dify、RAGFlow

### Q8-1. Coze / Dify 这类平台和 LangChain / LangGraph 的关系怎么理解？

Coze / Dify 更偏应用层、低代码和可视化交付，LangChain / LangGraph 更偏代码级开发框架。它们不是谁替代谁，而是同一条 AI 应用链路上的不同层级。

如果从这一层关系来理解：

- Dify / Coze 更适合快速把 Agent、RAG、Workflow 搭起来，方便业务侧验证、协作和交付。
- LangChain 更适合把 Prompt、Model I/O、Parser、Retriever、Tools 这些组件按代码方式组合起来。
- LangGraph 更适合状态显式、循环、条件路由、人机协同、多智能体这类复杂编排。

所以平台更接近“应用搭建层”，代码框架更接近“底层编排层”。真实项目里很常见的路径是：先用平台验证业务价值，再把核心链路迁到代码框架；或者平台负责上层业务编排，底层复杂能力由自建服务承接。

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**平台能力和代码能力的选型判断。

**对应章节：**[3 基于Coze&Dify平台的智能体开发 §1、智能体(AI Agent)概述](3-基于Coze&Dify平台的智能体开发.md#_1、智能体ai-agent概述)；[9 LangChain概述与架构 §2、LangChain 定位](9-LangChain概述与架构.md#_2、langchain-定位)

### Q8-2. 各类 Agent 开发框架应该如何选取？

框架选型不要看热度，要看任务复杂度、团队能力和交付要求。

- 如果目标是快速原型、生态丰富、常见组件齐全，LangChain 很合适。
- 如果任务有显式状态、循环、条件路由、人机协同或多智能体，LangGraph 更合适。
- 如果是低代码、快速验证业务流程，Coze / Dify 更适合。
- 如果系统边界简单、需求非常明确，直接手写 SDK 也可能是成本最低的方案。

更成熟的回答方式，不是简单比较“哪个最好”，而是说明“什么场景下用什么更划算”。能说出替代方案和迁移路径，通常比单纯夸某个框架更有说服力。

**常见追问：**

- 你最终会用哪些指标判断这次框架选型是不是成功的？
- 如果前期先用平台，后期迁到自研框架，迁移边界应该怎么划？

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**框架选型和工程判断。

**对应章节：**[9 LangChain概述与架构 §2、LangChain 定位](9-LangChain概述与架构.md#_2、langchain-定位)；[22 LangGraph概述与快速入门 §1、LangGraph 简介](22-LangGraph概述与快速入门.md#_1、langgraph-简介)

### Q8-3. 什么时候工作流比 Agent 更合适？

当业务步骤固定、输出格式明确、希望强可控和易审计时，工作流通常比 Agent 更合适。

比如分类、摘要、内容审核、报告生成、表单填充、固定审批链，这类场景流程路径通常是稳定的。用工作流能更清楚地定义节点职责、失败重试、人工介入点和 SLA。Agent 更适合开放任务和动态决策，而工作流更适合企业里大量“有规则、可追责、可回放”的流程型任务。

**常见追问：**

- Workflow 中哪些节点适合交给 LLM？
- 人工审核点应该加在哪里？
- 工作流如何逐步升级成 Agentic Workflow？

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**流程治理意识。

**对应章节：**[3 基于Coze&Dify平台的智能体开发 §6、工作流的搭建](3-基于Coze&Dify平台的智能体开发.md#_6、工作流的搭建)；[21 Agent智能体 §1、Agent 简介](21-Agent智能体.md#_1、agent-简介)

### Q8-4. 用 Python 调用 Dify / Coze 工作流时，最值得关注哪些工程细节？

重点需要关注五类问题：鉴权、参数对齐、流式模式、超时限制、日志追踪。

先说 Dify。它的工作流 API 重点字段通常是：

- `Authorization: Bearer {api_key}`
- 请求体里的 `inputs`
- `response_mode`
- `user`

这里有两个非常容易踩坑的点：一是 API Key 和工作流是绑定关系，不是拿一个全局 key 到处用；二是长流程尽量用 `streaming`，因为 `blocking` 很容易被网关超时打断。真正做流式时，要能识别 SSE 流里的 `workflow_finished`，并正确拿到最终 `outputs`。

再说 Coze。它更需要盯紧：

- `workflow_id`
- `app_id`
- `parameters`

其中 `parameters` 必须和工作流里定义的输入变量严格对齐，变量名一旦对不上，代码看起来能跑，请求也可能成功，但业务结果就是不对。流式处理时，则要能区分 `PING`、`MESSAGE`、`DONE`，或者 SDK 里的 `MESSAGE / ERROR / INTERRUPT` 事件。

如果从工程角度总结，重点需要看这几件事：

- 密钥、工作流、应用的绑定关系是否搞清楚。
- 请求参数名是否和平台工作流输入严格一致。
- 是不是默认用流式，而不是把长任务都压成阻塞式。
- 平台日志、`workflow_run_id`、业务 `request_id` 是否串起来了。
- 如果流程里有外部副作用，是否做好幂等、重试和失败补偿。

这道题真正考察的，不是“会不会发 POST 请求”，而是是否真正理解过平台 API 的真实调用链。

**常见追问：**

- 流式和阻塞式返回怎么选？
- 平台日志能解决哪些排障问题？
- 平台工作流和自建后端服务怎么协作？

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**是否看过平台 API 的真实调用链，而不是只会点界面。

**对应章节：**[4 Python调用Dify平台工作流 §4、请求格式](4-Python调用Dify平台工作流.md#_4、请求格式)；[5 Python调用Coze平台工作流 §3、通过 Python 代码调用工作流](5-Python调用Coze平台工作流.md#_3-通过-python-代码调用工作流)

### Q8-5. 开源 RAG 平台比如 RAGFlow，应该如何选型？和 Dify 或自研链路怎么比较？

这道题不要答成“谁更强”，而要答成“当前知识库场景更需要什么”。

如果重点是文档导入、解析、切块、检索和 RAG 编排体验，那么像 RAGFlow 这类平台会比较有吸引力；如果重点是多类 Agent、工作流、插件生态和业务 API 编排，Dify / Coze 这类平台的边界会更宽；如果核心链路涉及深度定制、复杂状态治理、合规审计和内部系统耦合，自研代码链路通常更稳。

真正做选型时，优先看四类因素：文档导入与解析质量、权限和多租户能力、是否方便对接业务系统、二次开发空间。很多项目不是卡在“能不能做 RAG”，而是卡在“解析质量稳不稳、权限做不做得住、后续能不能接进企业系统”。

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**RAG 平台选型判断，以及平台能力与自研能力的边界意识。

---

## 9、安全、评测、部署与可观测性

### Q9-1. 你会如何评估一个 RAG 或 Agent 系统的效果？

评估先拆成**离线评测**和**在线评测**，再把问题拆到具体层级，而不是只盯一个总分。

如果是 RAG，通常按两层看：

- 检索层：相关内容有没有被召回，引用片段对不对，badcase 是卡在切块、召回、重排，还是过滤。
- 生成层：答案是不是忠实于证据，引用是否正确，无依据时能不能拒答，最终回答对业务有没有帮助。

如果是 Agent，评测应分成两类：

- 轨迹级评测：有没有选对工具、参数对不对、有没有无效循环、是不是过早结束。
- 结果级评测：最终任务有没有完成，输出质量和用户体验是否达标。

在线评测则看用户满意度、转人工率、任务中断率、耗时、badcase 类型分布。对于 Agent，还要看工具调用成功率、重试率、循环次数和人工兜底比例。

自动评测上，通常不会只押某一种方案，而是把规则评测、`LLM-as-a-judge` 和人工抽检结合起来。规则和 LLM 评测适合放大规模、做回归，人工抽检负责兜住高风险误判和评价漂移。

更重要的是评测不能只告诉你“分数变低了”，而要能定位到底是哪一层出问题。比如召回差、上下文组装差、生成幻觉、工具失败、终止条件不合理，这些问题的修法完全不同。

更推荐的评测闭环是：**先分层建指标，再沉淀 badcase，最后让 badcase 反过来驱动 Prompt、检索、工具和流程迭代。**

**常见追问：**

- RAGAS 这类框架适合做什么？
- 如何建设 badcase 数据集？
- 自动评测和人工评测怎么配合？

**重要度：**`必刷`（出现次数：2次） | **难度：**`较难`

**考察点：**是否有评测闭环意识。

**对应章节：**[19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手](19-RAG检索增强生成.md#_3、rag-综合案例：智能运维助手)；[21 Agent智能体 §5、实操与案例](21-Agent智能体.md#_5、实操与案例)

### Q9-2. 什么是“幻觉”？应用层应该怎么缓解？

幻觉不只是“完全胡说八道”，更常见的是“看起来很像真的，但细节、引用、时间点、权限范围或者工具结果已经偏了”。

因此，不应把幻觉当成单纯的模型问题，而应把它视为一条链路上的系统问题。比较稳妥的缓解思路通常有四层：

- 知识层：用 RAG、外部检索、引用和无依据拒答，尽量让模型基于证据回答。
- 执行层：把计算、查库、发消息、查订单这类事情交给 Tool，不让模型纯文本瞎编结果。
- 约束层：用结构化输出、schema 校验、关键字段规则校验和低温度策略，减少“格式对了但内容错了”的情况。
- 治理层：做 badcase 回灌、人工抽检、线上监控和降级，别把“模型大概率没问题”当作上线条件。

总结来说：幻觉很难被彻底消灭，工程目标不是“保证永不出错”，而是让它 **可发现、可限制、可回滚、可复盘**。

**常见追问：**

- RAG 为什么不能彻底消灭幻觉？
- 什么叫“有引用但依然不忠实”？
- 幻觉和 Prompt Injection 是一回事吗？

**重要度：**`高频`（出现次数：2次） | **难度：**`中等`

**考察点：**是否理解“模型能力问题”和“应用链路治理问题”的边界。

**对应章节：**[19 RAG检索增强生成 §1、RAG 简介](19-RAG检索增强生成.md#_1、rag-简介)；[14 输出解析器 §4、结构化输出](14-输出解析器.md#_4、结构化输出)

### Q9-3. 多用户场景下，如何为 Agent 做安全沙箱隔离？

如果 Agent 只是单机 Demo，很多风险不会暴露出来；但一旦进入多用户场景，安全隔离就必须从“工具权限”上升到“执行环境隔离”。

一个更稳的方案通常会分三层：

- 环境层：用 Docker 或其他容器把每个任务或租户隔离开，限制 CPU、内存、网络和文件系统访问范围。
- 系统层：配合 seccomp、AppArmor、只读根目录、临时工作目录、非 root 用户运行，避免直接碰宿主机。
- 应用层：对工具、文件访问、系统命令、外部连接做白名单和审计，不让模型拿到裸权限。

如果要执行代码、命令或读文件，通常不会只靠 Prompt 或业务代码做限制，而是会把工作目录挂成最小权限空间，敏感目录不挂载，数据库密钥和主机凭据也不进容器。MCP 或 Tool 负责“能不能调”，沙箱负责“即使调了也跑不出边界”，两者职责不同，最好一起上。

**重要度：**`高频`（出现次数：2次） | **难度：**`较难`

**考察点：**多用户 Agent 的安全隔离设计，以及协议层控制和环境层隔离的分工。

**对应章节：**[7 企业级大模型部署 §1、企业级大模型部署概述](7-企业级大模型部署.md#_1、企业级大模型部署概述)；[17 Tools工具调用 §6、从课程案例走向真实项目](17-Tools工具调用.md#_6、从课程案例走向真实项目)

### Q9-4. Agent 部署和运维有哪些指标？

Agent 运维至少要看五类指标：

- 效果指标：任务完成率、用户满意度、引用正确率。
- 性能指标：首 token、端到端延迟、P95/P99。
- 稳定性指标：调用成功率、超时率、重试率、失败率。
- 成本指标：token 消耗、工具调用成本、单任务平均成本。
- 治理指标：人工接管率、审计日志完整性、异常任务复盘效率。

如果是多工具、多步骤 Agent，还要看每一步的成功率和卡点分布，否则你只能知道“最终失败了”，却不知道失败发生在哪一层。

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**从 Demo 到生产的运维视角。

**对应章节：**[7 企业级大模型部署 §1、企业级大模型部署概述](7-企业级大模型部署.md#_1、企业级大模型部署概述)；[21 Agent智能体 §5、实操与案例](21-Agent智能体.md#_5、实操与案例)

### Q9-5. RAG 系统在实际部署中可能面临哪些挑战？

RAG 真正上线后，难点通常不在“能不能检索”，而在“这条从索引到回答的完整链路能不能长期稳定运行”。

这里首先要强调的是：RAG 不是单点能力，而是“索引阶段 + 检索与生成阶段”的工程链路。很多线上问题，本质上都是这两阶段里某一层出了问题。

先把挑战拆成六类：

- 数据侧：文档解析质量、切块策略、表格和 PDF 处理、知识更新时效。如果源数据脏、切块不合理，后面检索和生成都会被拖垮。
- 检索侧：Embedding 选型、召回质量、混合检索、重排效果、metadata 过滤。很多系统离线看起来能答，线上一放大就会暴露“召回不准、噪声太多、漏关键片段”的问题。
- 生成侧：上下文组装、引用溯源、忠实度控制、拒答策略。RAG 不是“检索了就不会幻觉”，如果上下文拼接差、Prompt 弱、引用不清，模型照样会编。
- 治理侧：权限隔离、版本管理、引用可追溯、知识回滚。企业里最怕的不是答错，而是答了权限外内容，或者答出来了却说不清依据来自哪里。
- 评测侧：badcase 建设、离线评测和在线指标闭环。没有评测，你很难知道问题到底出在切块、召回、重排还是生成。
- 工程侧：延迟、成本、缓存、可观测性、索引重建和线上运维。比如知识库一更新，是全量重建还是增量更新？查询慢是卡在检索、重排还是模型？这些都得拆开看。

所以面试里更稳的答法不是只说“部署会有很多工程问题”，而是明确讲出：RAG 是一条从数据接入、索引构建、检索召回到生成回答的完整链路，任何一层出问题，最终答案都会出问题。

**常见追问：**

- 如果 RAG 线上效果不好，你会优先从哪一层开始排查？
- 知识库频繁更新时，你怎么处理索引重建和版本回滚？

**重要度：**`高频`（出现次数：1次） | **难度：**`较难`

**考察点：**是否有生产系统思维。

**对应章节：**[19 RAG检索增强生成 §2、RAG 文本处理核心知识](19-RAG检索增强生成.md#_2、rag-文本处理核心知识)；[7 企业级大模型部署 §1、企业级大模型部署概述](7-企业级大模型部署.md#_1、企业级大模型部署概述)

### Q9-6. 如何确保 Agent 的行为安全、可控且符合人类意图？

这件事不能只寄希望于模型本身“够聪明”或“已经对齐过”。模型层的 SFT、RLHF / RLAIF 只能提供基础安全边界，真正落地到应用时，还必须补应用层治理。

通常会从四层做：

- 模型与提示层：用 System Message 明确角色、边界、安全规则和拒答策略。
- 工具与权限层：不给模型裸权限，所有 Tool 都要做 schema 约束、鉴权、参数校验和最小权限暴露。
- 执行与流程层：设置最大步数、超时、人工审批、转人工、失败兜底，避免无限循环和危险动作直接落地。
- 观测与审计层：保留调用日志、trace、输入输出、关键决策点和人工复盘链路。

如果再补一层生产视角，我还会把预算和熔断讲进去：

- 预算控制：最大工具调用次数、时间预算、token 预算、费用预算。
- 熔断机制：连续失败停止、异常率告警、重复无进展退出。

这些机制的价值不只是省钱，更重要的是把“模型可能一直试下去”的风险收住。

如果再往上一层总结，就是：模型对齐解决“基础行为别太离谱”，应用治理解决“在你的业务系统里别出事”。真正稳的 Agent，一定是“模型能力 + 权限边界 + 流程控制 + 人机协同”一起做，而不是只靠某一层。

**常见追问：**

- 模型已经做过对齐了，为什么应用层还要再做这么多安全治理？
- 哪些动作你会要求人工审批，而不是让 Agent 直接执行？

**重要度：**`高频`（出现次数：1次） | **难度：**`较难`

**考察点：**是否理解“模型对齐”和“应用层安全治理”是两套互补机制。

### Q9-7. Agent 链路耗时很长时，如何定位性能瓶颈？

Agent 一条链路跑到几分钟，不能只说“模型太慢”，要先把耗时拆开。

通常会按这几层做分解：

- 模型层：单次推理时长、首 token 延迟、输出 token 长度。
- 检索层：召回、重排、外部搜索、知识库请求耗时。
- 工具层：API 延迟、浏览器动作、代码执行、等待外部系统返回。
- 编排层：路由判断、Supervisor 判断、重复重试、串行等待。
- 结果层：后处理、校验、存储、日志落盘。

比较稳的做法是给每一步打 trace 和 span，先看 wall time 花在哪，再决定是换模型、改链路、减少步骤，还是把串行改成并行。如果用了 LangGraph，我还会看节点级耗时、是不是反复进入同一节点、有没有因为缺少明确完成信号而来回判断。

很多五分钟任务最后不是卡在单次模型调用，而是卡在多步链路过长、工具等待、监督节点重复判断，或者中间没有明确成功信号导致反复检查。也就是说，性能问题很多时候不是“模型太慢”，而是**状态流转和执行闭环没有设计好**。

**重要度：**`高频`（出现次数：1次） | **难度：**`较难`

**考察点：**Agent 性能排障能力，以及把长链路延迟拆解到模型、工具、检索和编排层的能力。

### Q9-8. 意图识别 / 任务路由应该怎么做？

需要先强调，这题和“模型路由”不是一回事。模型路由更接近“这次该用大模型还是小模型”，而意图识别 / 任务路由更接近“这次请求到底该走 FAQ、RAG、Tool、Agent、Workflow，还是直接转人工”。

比较稳的设计通常分三层：

- 第一层是目标分类：先定义清楚系统有哪些路由终点，比如闲聊、FAQ、知识问答、查状态、执行动作、复杂任务、人工兜底。
- 第二层是路由机制：高确定性场景先用规则和关键词兜底，模糊场景再用分类模型或 LLM 做语义判断。
- 第三层是置信度治理：低置信度不强判，允许澄清、降级或转人工，别让系统带着误判继续往下跑。

工程上通常不会做“单层万能路由器”，而是更偏好多级路由：

- 先做业务意图路由：判断这是 FAQ、RAG、Tool 还是 Agent。
- 再做子域路由：比如客服里再分订单、退款、工单、投诉。
- 最后再做模型路由：在具体链路里决定用强模型还是轻模型。

这样做的好处是更容易治理，也更容易评测。评估时重点看：路由准确率、低置信度占比、误路由成本、澄清命中率，以及每条路由分支的最终任务完成率。

**常见追问：**

- 什么时候先用规则路由就够了，什么时候必须上语义分类？
- 如果一个问题同时像 FAQ 又像 Tool 调用，你怎么处理？
- 如何避免错误路由把后续链路全部带偏？

**重要度：**`高频`（出现次数：1次） | **难度：**`较难`

**考察点：**分层路由能力、意图识别落地能力，以及把 FAQ / RAG / Tool / Agent 串成统一入口的系统设计意识。

**对应章节：**[17 Tools工具调用 §6、从课程案例走向真实项目](17-Tools工具调用.md#_6、从课程案例走向真实项目)；[19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手](19-RAG检索增强生成.md#_3、rag-综合案例：智能运维助手)

### Q9-9. 你会怎么做大模型应用的可观测性？

至少要做到三件事：**有日志、有指标、有 Trace**。也就是能看见请求怎么流过系统、每一步花了多久、失败在哪里、用了多少 token、最后输出了什么。

具体上，应打通 trace_id / request_id，把入口请求、Prompt 版本、模型版本、索引版本、检索结果、工具调用、异常信息、耗时和 token 用量串起来。如果用了 LangChain / LangGraph，还需要重点关注节点流转、状态更新、人工中断点、重试次数和最终退出原因。

对 Agent 系统来说，可观测性尤其重要，因为很多问题都发生在中间步骤，而不是最终输出那一刻。真正有用的可观测性，不只是“最后报错了”，而是能告诉你：**它在哪个节点卡住、为什么重试、为什么结束、当时看到了什么状态。**

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**Trace、日志、指标意识。

### Q9-10. 控制大模型应用成本，你会优先从哪些层面下手？

通常从模型、上下文、检索、流程四层入手。

- 模型层：高低配模型分层，大任务用强模型，小任务用轻模型。
- 上下文层：压缩 Prompt，减少无效历史，控制返回长度。
- 检索层：优化召回和重排，减少无意义进窗内容。
- 流程层：减少不必要的 LLM 调用次数，能规则化就不要全靠模型。

很多系统成本高，不是因为模型太贵，而是链路设计太浪费，比如无差别全量检索、过长历史拼接、多次重复调用大模型、工具失败后盲目重试。

**常见追问：**

- 什么时候应该引入模型路由？
- 如何平衡成本和效果？
- token 成本和工具成本哪个更值得先优化？

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**成本优化思维。

**对应章节：**[1-1 大模型认知与工程概览 §4、大模型的工程实现（概览）](1-1-大模型认知与工程概览.md#_4、大模型的工程实现%EF%BC%88概览%EF%BC%89)；[7 企业级大模型部署 §1、企业级大模型部署概述](7-企业级大模型部署.md#_1、企业级大模型部署概述)

### Q9-11. 模型路由应该怎么做？

模型路由的核心不是“让所有请求自动找最强模型”，而是让不同复杂度、不同风险等级的请求走到最合适的链路。

比较常见的做法有三层：

- 意图路由：先判断这是 FAQ、RAG、工具调用、复杂 Agent，还是应该直接转人工。
- 复杂度路由：简单分类、格式化抽取、轻量总结走小模型；多步规划、开放生成、复杂决策走大模型。
- 成本路由：热点问题先查缓存，能规则化解决的就别进大模型，高价值用户或高风险任务再给更强模型预算。

真正落地时，通常不会把“路由”做成纯主观规则，而会配合评测和线上数据来调：

- 看不同路由分支的完成率、延迟、每任务成本。
- 看是不是某类问题被错误地下沉到了小模型。
- 看路由规则是否需要引入回退机制，比如小模型失败后升级到大模型。

所以模型路由本质上是效果、成本和稳定性之间的平衡器。做得好的系统，不是每次都用最贵的模型，而是能把“该省的地方省掉，该花的地方花对”。

**常见追问：**

- 什么场景下适合先用规则路由，而不是一开始就做模型路由？
- 小模型路由失败后，怎样设计升级和回退策略？
- 如何避免为了省成本把系统整体效果打穿？

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**成本治理、模型分层和路由策略设计能力。

**对应章节：**[11 Model I/O 与模型接入 §2、LangChain 模型分类、参数与返回](11-Model-I-O与模型接入.md#_2、langchain-模型分类、参数与返回)；[7 企业级大模型部署 §1、企业级大模型部署概述](7-企业级大模型部署.md#_1、企业级大模型部署概述)

### Q9-12. 内网环境下怎么设计 Agent / RAG 系统？

内网环境下做 Agent / RAG，核心不是“把公网方案照搬一遍”，而是先把 **数据不出域、模型可控、依赖可替换、链路可观测** 这几件事立住。

如果按企业级部署思路设计，通常拆成三层：

- 应用层：Dify、Coze 类平台的私有化版本，或者自研后端服务，负责工作流、Agent 编排、权限和业务接口。
- 推理层：用 Xinference 这类托管平台统一管理 LLM、Embedding、Rerank，对外暴露 OpenAI-compatible API。
- 数据层：内网向量库、关系库、对象存储、知识库索引、日志和审计系统都放在可控域内。

这类架构的关键点一般有：

- 模型接入统一：上层尽量都走兼容 API，方便替换在线模型、本地模型和不同推理引擎。
- 网络和权限隔离：Agent 能访问哪些内网系统，必须按最小权限开放，不让模型拿到一把通吃的内网钥匙。
- 知识治理：文档解析、索引重建、版本回滚、租户隔离、引用追踪都要内建，不然内网知识库很快会失控。
- 可观测与审计：请求链路、工具调用、检索结果、模型版本、token 用量、异常告警都要能在内网闭环查看。
- 降级能力：内网模型抖动时，是否有缓存、规则链路、人工兜底或备用模型，不然系统会很脆。

总结来说：内网方案不是“离线版 Demo”，而是一套更强调安全边界、运维治理和模型可替换性的生产架构。

**常见追问：**

- 为什么很多企业会选择“应用层 + 推理层”解耦，而不是把所有东西混在一台机器上？
- 内网环境下，LLM、Embedding、Rerank 为什么最好分开部署和管理？
- 如果不能直接访问公网搜索，动态信息怎么补？

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**企业私有化部署理解、应用层与推理层解耦意识，以及内网 Agent / RAG 的安全与运维设计能力。

**对应章节：**[7 企业级大模型部署 §1、企业级大模型部署概述](7-企业级大模型部署.md#_1、企业级大模型部署概述)；[7 企业级大模型部署 §3、模型部署](7-企业级大模型部署.md#_3、模型部署)；[12 Ollama本地部署与调用 §5、LangChain 整合 Ollama](12-Ollama本地部署与调用.md#_5、langchain-整合-ollama)

---

## 10、典型业务场景设计题

### Q10-1. 如果让你设计一个企业知识库问答系统，你会怎么做？

通常按“数据接入、检索链路、生成链路、治理能力”四层设计。

先把文档接入、解析、切块、向量化和索引更新机制搭好，再设计查询链路，包括 query 改写、混合检索、rerank、权限过滤和上下文组装。生成层要强调“基于证据回答、无依据时拒答、尽量带引用”。治理层则要补上权限、版本、监控、评测和 badcase 回灌。

如果是企业场景，通常还会预留转人工、知识修订、索引回滚和多租户隔离能力，因为这些往往比“第一次答对”更影响长期可用性。

**常见追问：**

- 如何支持知识更新？
- 如何避免用户问到权限外文档？
- 如果系统答非所问，优先排查哪里？

**重要度：**`必刷`（出现次数：1次） | **难度：**`较难`

**考察点：**从需求到架构的完整表达能力。

**对应章节：**[2-RAG 搭建企业私有&个人知识库 §5、使用 Dify 搭建知识库](2-RAG-搭建企业私有&个人知识库.md#_5、使用-dify-搭建知识库)；[19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手](19-RAG检索增强生成.md#_3、rag-综合案例：智能运维助手)

### Q10-2. 如果让你设计一个 NL2SQL Agent，你会重点控制哪些风险？

重点应控制 schema 注入、SQL 安全、执行验证和歧义澄清四类风险。

首先不能把整个数据库 schema 全量塞进上下文，而是要按问题做裁剪和 schema linking。其次要限制只读查询、禁止危险语句、加执行沙箱和超时控制。再次要做语法检查和执行前校验，避免生成看似合理但跑不通的 SQL。最后，对时间范围、口径定义、字段歧义这类问题，要支持澄清，不要让模型自行脑补。

**常见追问：**

- 生成 SQL 前要不要先展示预览？
- 如何做 self-correction？
- 什么时候该放弃生成 SQL，转人工或转报表模板？

**重要度：**`高频`（出现次数：1次） | **难度：**`较难`

**考察点：**结构化查询和安全意识。

### Q10-3. 如果让你设计一个客服智能体，你会优先考虑哪些能力？

优先考虑意图识别、知识检索、流程执行、人机协同和复盘闭环。

客服场景不是简单问答，它往往同时涉及 FAQ、订单查询、退款流程、工单流转和情绪安抚。所以系统既要能回答，也要能查状态、调接口、补资料，还要在不确定时及时转人工，并把上下文完整交接过去。

上线后还要持续复盘高频未解决问题、误判意图、知识缺口和转人工原因，这样系统才会越做越稳，而不是只在演示时好看。

**常见追问：**

- 转人工条件怎么设计？
- 客服场景为什么更需要长期记忆或用户画像？
- 如何做满意度和闭环评估？

**重要度：**`高频`（出现次数：1次） | **难度：**`较难`

**考察点：**业务型 Agent 设计能力。

**对应章节：**[3 基于Coze&Dify平台的智能体开发 §7、项目：商户运营管家](3-基于Coze&Dify平台的智能体开发.md#_7、项目：商户运营管家)；[21 Agent智能体 §5、实操与案例](21-Agent智能体.md#_5、实操与案例)

### Q10-4. 如何设计 Agent 的完成判断与终止条件，避免过早结束？

Agent 的“结束”不能只靠感觉，也不能只靠看日志或一个宽泛的完成率分数。更稳的做法是给它设计显式的完成条件。

终止逻辑通常拆成四层：

- 任务层：是否达成用户目标，是否拿到了必须的产物或字段。
- 工具层：关键工具调用是否成功，返回结果是否满足预期约束。
- 状态层：当前 state 是否进入 done / failed / need_human 这样的终态。
- 保护层：最大步数、超时、重复无进展次数、异常退出条件。

如果链路里有 Supervisor 或监督节点，更适合把它当“辅助审查”和“异常兜底”，而不是唯一的结束依据。真正稳的方案是：只有当关键任务结果、工具返回和状态机条件都满足时，才允许进入最终答复节点。否则宁可继续执行、澄清或转人工，也不要过早把未完成结果返回给用户。

**常见追问：**

- 只靠监督节点统计完成率和查日志，为什么会慢、还容易误判？
- 有没有更通用的判断方式，比如直接看关键工具调用结果和状态字段？
- 如何避免 Agent 任务还没做完，就提前返回给用户？

**重要度：**`高频`（出现次数：1次） | **难度：**`较难`

**考察点：**Agent 终止条件设计、状态机思维，以及 Supervisor / 工具结果 / 状态字段的组合使用能力。

**对应章节：**[24 LangGraphAPI：节点、边与进阶 §2、Graph API 之 Edge](24-LangGraphAPI：节点、边与进阶.md#_2、graph-api-之-edge%EF%BC%88边%EF%BC%89)；[21 Agent智能体 §4、Agent 工作原理（V1.0）](21-Agent智能体.md#_4、agent-工作原理%EF%BC%88v1.0%EF%BC%89)

### Q10-5. Code Agent 怎么设计？

Code Agent 的核心不是“会写几行代码”，而是能围绕一个代码任务完成 **读代码库、定计划、改文件、跑验证、根据结果继续修正** 的闭环。从系统结构看，它本质上仍然是一个 **模型 + 工具集 + 运行循环 + 当前状态** 的执行系统，只不过工具和状态都更偏代码场景。

如果按模块拆分，通常设计为以下几层：

- 任务理解层：先把需求转成明确目标，判断是读代码、改 bug、补测试、重构，还是回答架构问题。
- 代码库理解层：通过代码搜索、文件树、符号索引、依赖关系、提交历史建立最小必要上下文，而不是把整个代码库一股脑塞进模型。
- 计划与执行层：先列出修改计划，再决定读哪些文件、改哪些文件、跑哪些命令、需要哪些验证。
- 工具层：至少要有搜索、读文件、编辑文件、运行测试、执行命令、查看日志这些能力。
- 反馈闭环层：根据 lint、测试、运行报错、diff 结果继续修正，而不是生成一次补丁就结束。
- 安全治理层：限制执行权限、隔离危险命令、保留变更和执行日志，避免 Agent 在代码库里无约束乱改。

真正的难点通常不在“会不会生成代码”，而在三个地方：

- 上下文治理：代码库很大时，怎么只拿到和当前任务最相关的上下文。
- 验证闭环：怎么判断修复真的生效，而不是只让模型说“我已经改好了”。
- 失败处理：当 Agent 连续修不好 bug 时，怎么停下来、怎么暴露中间诊断、怎么交还给人。

所以一个成熟的 Code Agent，更接近“面向代码任务的执行系统”，而不是“代码自动补全工具放大版”。它的关键不只是会写代码，而是能把 **代码库理解、工具调用、验证反馈、停止条件** 做成稳定闭环。

**常见追问：**

- 千万行代码库里，Code Agent 最容易先卡在哪里？
- Agent 修不好 bug 时，你怎么设计停止条件和人工接管？
- 静态知识和动态数据在代码场景里怎么区分，哪些该靠索引，哪些该靠运行反馈？

**重要度：**`高频`（出现次数：1次） | **难度：**`较难`

**考察点：**代码场景下的 Agent 设计能力、代码库上下文治理能力，以及“修改 - 验证 - 继续修复”的闭环意识。

### Q10-6. 如果让你设计一个 Deep Research 系统，它和普通 RAG 有什么不同？

普通 RAG 更接近“先检索，再回答”，而 Deep Research 更接近“围绕一个复杂主题，先拆研究任务，再多轮检索、交叉验证、综合整理，最后输出结构化报告”。

因此，Deep Research 通常需要查询规划、子任务拆分、多源检索、冲突检测、引用管理、可信度判断和迭代补检这些能力。它更接近研究助手，而不是问答助手。输出形式也更偏报告、摘要和引用列表，而不是一句直接答案。

如果按工程实现去理解，它本质上更接近“**工作流 / 图编排 + 多轮检索 + 报告生成**”的组合能力，而不是把普通 RAG 的上下文塞得更长。重点不只是召回，而是有没有把研究过程拆开、证据有没有被反复求证、最后能不能形成带引用的结构化结论。

**常见追问：**

- 如何保证结果可靠？
- 什么叫多源交叉验证？
- 这类系统为什么更需要人工审核点？

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**复杂检索与报告生成理解。

### Q10-7. 如何设计一个 Deep Research 系统？

Deep Research 的核心不是“查一次资料再总结”，而是“围绕复杂问题持续研究并形成结构化结论”。

一个比较完整的设计通常包括：

- 查询规划器：把复杂问题拆成子问题。
- 检索执行器：面向搜索、数据库、知识库做多源检索。
- 信息融合层：做去重、冲突检测、证据对齐和可信度加权。
- 迭代控制器：发现证据不足时继续补检，而不是一次性结束。
- 报告生成器：输出摘要、正文、引用和时间戳。

如果采用更工程化的表达方式，可以将其理解为一个研究型工作流：

- 前面是任务拆解和检索编排。
- 中间是多轮证据收集、去重、冲突处理。
- 后面是结构化报告生成和引用整理。

它和普通 RAG 最大的差异，是从“单轮问答”升级成“多轮研究流程”。所以设计重点不只是召回率，还包括规划质量、引用质量、可信度和过程可回放性。真正落地时，通常也更倾向于用 Workflow 或 LangGraph 这类显式编排方式来做，而不是把它完全交给一个黑盒对话 Agent。

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**复杂研究型系统的模块拆分能力。

### Q10-8. 如何设计 Python 代码解释器？

Python 代码解释器本质上是“模型生成代码 + 安全执行 + 回传结果”的闭环系统。

核心设计通常包括：

- 代码生成层：模型把用户需求转成 Python 代码。
- 沙箱执行层：隔离环境、白名单模块、超时限制、资源限制。
- 结果回传层：收集 stdout、stderr、文件产物、图表和返回值。
- 状态管理层：支持多轮执行时保留变量或工作目录。
- 安全治理层：禁止危险系统调用、网络访问和越权读写。

这类系统真正的难点不在“会不会运行 Python”，而在“如何既让它有执行能力，又不把宿主环境暴露出去”。

**常见追问：**

- 如果 Agent 需要执行系统命令或访问文件，你怎么防止它越权删除数据库、读取主机敏感文件？
- 除了白名单，你在宿主环境隔离上还会做哪些限制？

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**执行型智能体和安全沙箱设计。

**对应章节：**[17 Tools工具调用 §6、从课程案例走向真实项目](17-Tools工具调用.md#_6、从课程案例走向真实项目)；[21 Agent智能体 §5、实操与案例](21-Agent智能体.md#_5、实操与案例)

### Q10-9. 如何设计类 Manus 通用智能体？

这类系统不宜先强调“通用”，而应先回到 Agent 的最小骨架：**模型 + 工具集 + 运行循环 + 当前状态**。所谓类 Manus，本质上是把这四层能力扩展到更长任务链和更复杂任务空间中。

设计上通常要有：

- 任务理解与规划模块：把目标拆成可执行步骤。
- 工具调度模块：统一接搜索、浏览器、代码执行、文件系统等工具。
- 状态与记忆模块：维护任务上下文、待办和阶段成果。
- 执行与反思模块：根据中间结果继续执行、修正或重试。
- 安全与治理模块：权限控制、日志、失败恢复和人工接管。

这类系统和普通 Agent 的区别，不在于“工具更多”，而在于它需要长期推进任务、处理中间产物、管理复杂状态，并在较长链路里维持稳定性。因此，它更接近一个通用任务执行框架，而不是单轮问答机器人的放大版。

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**通用任务型 Agent 的系统拆分能力。

### Q10-10. 如何开发浏览器自动化 Agent？

浏览器自动化 Agent 的核心是把“看页面、理解页面、操作页面、校验结果”做成一个稳定闭环。

一个比较合理的设计通常包括：

- 页面感知层：拿到 DOM、截图、可交互元素信息。
- 决策层：根据目标决定点击、输入、滚动、等待还是回退。
- 执行层：调用浏览器自动化工具完成动作。
- 校验层：确认动作是否生效，页面是否进入预期状态。
- 治理层：超时、重试、幂等、防误操作和日志回放。

这类 Agent 最大的难点不在“会不会点按钮”，而在网页不稳定、异步加载、状态漂移和误操作成本高，所以一定要把验证和回滚意识做进去。

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**浏览器工具、任务规划和可靠性设计。

### Q10-11. 当 Agent 需要在真实或模拟环境中执行任务时，它和纯软件工具型 Agent 有什么本质区别？

最大的区别在于：软件型 Agent 主要在数字系统里操作，输入输出更结构化，可回放性也更强；而真实或模拟环境里的 Agent，面对的是感知噪声、状态不完备、实时反馈和物理世界副作用。

也就是说，纯软件工具型 Agent 更接近“调接口、读写数据、操作页面”，重点是权限、状态机和工具编排；真实环境 Agent 则多了感知、定位、动作执行和安全约束，很多时候不是“调用成功”就算完成，而是还要判断动作有没有真正生效、环境有没有变化、风险是否可控。

所以这类系统会更强调闭环感知、实时性、仿真验证、失败保护和人工接管。它本质上不是把工具再多接几个，而是把 Agent 从“信息处理系统”推进到了“感知-决策-行动闭环系统”。

**重要度：**`中频`（出现次数：1次） | **难度：**`较难`

**考察点：**对“软件型 Agent”和“行动型 / 具身环境 Agent”边界的理解。

---

## 11、项目表达与面试实战

### Q11-1. 面试官让你介绍一个做过的 RAG / Agent 项目，你应该怎么讲？

更稳的表达顺序是 `业务目标 -> 方案设计 -> 你负责的部分 -> 难点 -> 指标结果`。

不要一开始就报技术栈，而要先讲这个项目解决了什么业务问题，例如“降低客服查文档成本”或“让运营能自然语言查数”。然后再讲架构，比如用了 RAG、Tools、LangGraph 还是平台工作流。接着重点说你自己具体做了什么，比如索引策略、权限设计、工具接入、评测体系、成本优化。最后给出可量化结果，比如命中率、耗时、转人工率、人工节省时长。

如果希望表达更稳，可以采用适合应用岗的轻量 STAR 结构：

- 情境：业务问题和约束是什么。
- 任务：你负责哪一段，目标指标是什么。
- 行动：你具体做了哪些设计、排障、优化。
- 结果：最终指标、上线效果、复盘收获。

面试官在项目题里最常往下追的，通常不是“你用没用过某个框架”，而是这些方向：

- 你具体负责哪一层，别把团队成果全讲成自己做的。
- 遇到过哪些 badcase，最后怎么修。
- 为什么这么选型，而不是别的方案。
- 项目上线后效果怎么评估，问题怎么排查。

**常见追问：**

- 这个项目最难的点是什么？
- 你做过哪些 trade-off？
- 如果重做一次，你会怎么改？

**重要度：**`必刷`（出现次数：1次） | **难度：**`中等`

**考察点：**项目表达能力。

**对应章节：**[19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手](19-RAG检索增强生成.md#_3、rag-综合案例：智能运维助手)；[21 Agent智能体 §5、实操与案例](21-Agent智能体.md#_5、实操与案例)

### Q11-2. 如果面试官问“你们为什么不用某个更热门的框架或模型”，怎么回答更稳？

回答重点不是证明“当前选择永远最对”，而是说明“当前选择和业务约束是匹配的”。

比较完整的回答可以按四层展开：

- 业务复杂度：当前问题到底需要单 Agent、Workflow，还是已经复杂到必须上 LangGraph / 多智能体。
- 工程约束：团队熟悉度、交付周期、可观测性、可维护性、迁移成本。
- 部署条件：是直接用在线模型，还是要接 OpenAI 兼容 API、本地模型、Ollama、Xinference 这类自建推理层。
- 成本与性能：延迟、吞吐、token 成本、模型版本稳定性、是否存在第三方版本漂移风险。

比如没选更重的多智能体框架，可能是因为当前任务用单 Agent 或 Workflow 已经够了；没选更大的模型，可能是因为延迟和成本不划算；没选某个托管平台，可能是因为我们更看重统一 OpenAI-compatible API、模型可控和私有化部署能力。

再往前走一步，还应该顺手体现两点：

- 你知道替代方案，不是没调研过。
- 你给当前方案留了迁移路径，不会把系统锁死。

**常见追问：**

- 如果未来需求变复杂，迁移路径是什么？
- 你们是如何做技术验证的？
- 如何避免技术选型锁死？
- 如果你的 MCP 是基于 Java 自研的，和成熟 Agent 框架相比，扩展性优势到底体现在哪？

**重要度：**`高频`（出现次数：1次） | **难度：**`中等`

**考察点：**技术判断和表达成熟度。

**对应章节：**[9 LangChain概述与架构 §2、LangChain 定位](9-LangChain概述与架构.md#_2、langchain-定位)；[7 企业级大模型部署 §1、企业级大模型部署概述](7-企业级大模型部署.md#_1、企业级大模型部署概述)

### Q11-3. 如果线上效果波动很大，你怎么向面试官展示你的排障能力？

最重要的是分层排查，并且给出清晰的证据链。

更规范的答法是：先确认是否存在输入分布变化，再看模型版本或 Prompt 是否变更，然后检查检索召回、工具调用、上下文组装、接口超时和日志链路。如果是 RAG，应抽样查看 query、召回片段和最终答案是否一致；如果是 Agent，则需要检查每一步工具调用和状态推进是否异常。最后再看是不是评测集失真或缓存污染。

这种回答比泛泛地说“调参数、优化 Prompt”更有说服力，因为它体现的是分层排障能力。

**常见追问：**

- 有没有遇到过偶发性错误？
- 如何做问题复现？
- 如何做一次有效复盘？
- 你会怎么判断问题主要来自模型幻觉，还是 RAG、Prompt、工具链路本身？

**重要度：**`中频`（出现次数：1次） | **难度：**`中等`

**考察点：**故障定位与复盘能力。

---

## 12、工具生态与岗位认知

### Q12-1. 你常用哪些 AI 开发工具？各自适合什么场景？

比较稳的答法，不是罗列名字，而是按场景分层。

通常可以分成几类：

- 通用对话与研究类：例如 `ChatGPT`、`Claude`、`Perplexity`，适合快速验证想法、梳理方案、写初稿、做资料总结。
- AI 编码协作类：例如 `Cursor`、`Claude Code`、`GitHub Copilot`，适合读代码、改代码、补测试、解释代码库结构，重点看它是更偏 IDE 内协作，还是更偏终端里的代码库级 Agent。
- 低代码 / 工作流平台类：例如 `Coze`、`Dify`，更适合业务快速验证、工作流编排、知识库接入和多人协作。
- RAG / 知识库平台类：例如 `RAGFlow`，更适合文档导入、解析、切块、检索和引用链路验证。

如果放到真实项目里，通常不会只选一种工具，而是按阶段组合使用。比如前期用通用对话工具梳理方案，用低代码平台做 POC，用 AI 编码工具接手核心链路实现，后面再把评测、部署和可观测性补齐。

如果需要一句更像面试现场的话，可以直接这样概括：方案梳理和资料总结常用 `ChatGPT`、`Claude` 这类通用工具；代码实现和仓库级修改更偏向 `Cursor`、`Claude Code`、`Copilot`；业务验证和工作流编排更常用 `Dify`、`Coze`；知识库链路验证则更适合 `RAGFlow` 这类平台。

这类问题真正考察的，不是“用过多少工具”，而是是否形成了自己的工具分层心智，知道不同工具各自解决什么问题。

**重要度：**`中频`（出现次数：1次） | **难度：**`基础`

**考察点：**工具生态认知，以及是否能按场景而不是按热度选工具。

**来源：**腾讯AI后台工程师一面（实际大厂面试题）

### Q12-2. Cursor、Claude Code、Copilot 这类 AI 编码工具的差异该怎么理解？

可以将它们理解为“都在帮助开发，但协作位置和交互方式不同”。

- Cursor 这类工具更偏 IDE 内协作，适合一边看代码、一边补全、局部改写、基于当前文件或工作区做编辑。
- Claude Code 这类工具更偏终端里的代码库级 Agent，适合跨文件理解、执行命令、改一组文件、做更完整的任务闭环。
- Copilot 这类工具更偏轻量级代码补全和编辑辅助，优势通常在低打断、嵌入现有编辑器工作流。

因此，不宜简单判断谁更强，而应回到任务类型本身。如果是“边写边补全、快速改一段代码”，IDE 内工具体验更顺；如果是“要理解整个代码库、跑命令、跨文件修改、完成一个更完整任务”，终端型 Agent 更有优势；如果团队已经有稳定 IDE 习惯，轻量补全类工具的接入成本也更低。

还可以补一句：工具能力会持续变化，所以真正稳定的判断标准不是名字，而是它对代码库上下文的理解深度、执行边界、可控性，以及是否契合团队工作流。

**重要度：**`中频`（出现次数：1次） | **难度：**`基础`

**考察点：**AI 编码工具的比较能力，以及是否有稳定的选型标准。

**来源：**腾讯AI后台工程师一面（实际大厂面试题）

### Q12-3. 如果让你总结“AI 应用工程师”和“算法研究岗”的差异，你会怎么说？

可以概括为，AI 应用工程师更关注“把模型能力稳定、安全、低成本地交付到业务系统中”，而算法研究岗更关注“如何改进模型本身的能力边界”。

前者的核心工作通常是技术选型、RAG / Agent 架构、工具和数据接入、工作流编排、评测、部署、监控和业务闭环；后者则更偏模型训练、微调策略、数据构造、算法实验和指标突破。两者会有交集，但能力重点不一样。

**重要度：**`低频`（出现次数：1次） | **难度：**`基础`

**考察点：**岗位认知是否准确。