AI 智能体与大模型应用开发面试题库
AI 智能体与大模型应用开发面试题库
定位：面向 AI 智能体 / 大模型应用开发工程师、AI 应用开发工程师、Agent 开发工程师。
风格：偏 应用落地、架构设计、工程治理、项目实战，不偏纯算法研究或预训练细节。
文档特点：
- 每道题都标注了重要度和难度，方便区分必刷内容、常考内容和进阶内容。
- 题目下方尽量补充了对应章节，方便回看知识点、边学边练。
- 相当一部分题目来自大厂真实面经和实际高频追问场景，更贴近真实面试。
- 整体表达坚持语言专业但易读，尽量避免空话、套话和纯概念堆砌。
- 各个二级标题按主题分类，结构清晰，便于按模块系统复习。
重要度标记说明：
必刷：大概率会被问到，答不好会直接暴露短板。高频：面试中很常见，通常是主问题或高频追问。中频：更偏工程设计、项目深挖和落地细节。低频：加分题、延伸题、岗位深挖题。
难度标记说明：
基础：偏概念主干和标准答法，适合第一轮打底。中等：需要结合工程理解、分层表达或一定项目经验。较难：更偏系统设计、复杂治理、协议细节或高级架构取舍。
📅 秋招面试复习计划（4 周版）
基于「重要度 × 难度」分级排期，建议每天 2-3h，周末加量。共 89 题，按周递进。
节奏原则：第 1 周打底 → 第 2 周深入 → 第 3 周进阶 → 第 4 周冲刺。
总览统计
| 维度 | 数量 |
|---|---|
| 总题数 | 89 |
| 必刷 | 13 |
| 高频 | ~35 |
| 中频 | ~35 |
| 低频 | 2 |
| 基础难度 | ~15 |
| 中等难度 | ~50 |
| 较难难度 | ~24 |
第 1 周：基础打底（必刷 + 基础/中等）
目标： 过完 Ch1-Ch4，吃透必刷题，建立知识骨架。
| Day | 章节 | 题目 | 用时 |
|---|---|---|---|
| 1 | Ch1 基础认知 | Q1-1 → Q1-5 | 2.5h |
| 2 | Ch2 Prompt | Q2-1 → Q2-6 | 2.5h |
| 3 | Ch3 RAG（上） | Q3-1 → Q3-5 | 3h |
| 4 | Ch3 RAG（下） | Q3-6 → Q3-10 | 3h |
| 5 | Ch4 检索基础设施 | Q4-1 → Q4-6 | 2.5h |
| 6 | 复习 + 整理笔记 | 重点回顾必刷题 | 2h |
| 7 | 口述模拟 | 对着每题说出核心答法 | 2h |
本周必刷： Q1-1、Q1-3、Q2-1、Q3-1、Q3-3
第 2 周：核心深入（高频 + 中等/较难）
目标： 过完 Ch5-Ch8，掌握 Agent、框架、MCP、平台选型。
| Day | 章节 | 题目 | 用时 |
|---|---|---|---|
| 8 | Ch5 Tools & Agent | Q5-1 → Q5-9 | 3h |
| 9 | Ch6 框架与编排 | Q6-1 → Q6-7 | 2.5h |
| 10 | Ch7 记忆 & MCP（上） | Q7-1 → Q7-6 | 3h |
| 11 | Ch7 记忆 & MCP（下） | Q7-7 → Q7-12 | 3h |
| 12 | Ch8 平台实践 | Q8-1 → Q8-5 | 2.5h |
| 13 | 复习 + 整理笔记 | 重点回顾高频题 | 2h |
| 14 | 口述模拟 | Ch5-Ch8 脱稿复述 | 2h |
本周必刷： Q5-2、Q5-3、Q5-4、Q6-1、Q7-1
第 3 周：进阶实战（较难 + 项目表达）
目标： 过完 Ch9-Ch12，吃透安全评测、业务设计、项目表达。
| Day | 章节 | 题目 | 用时 |
|---|---|---|---|
| 15 | Ch9 安全 & 评测（上） | Q9-1 → Q9-6 | 3h |
| 16 | Ch9 安全 & 评测（下） | Q9-7 → Q9-12 | 3h |
| 17 | Ch10 业务场景设计 | Q10-1 → Q10-11 | 3h |
| 18 | Ch11 + Ch12 | Q11-1 → Q12-3 | 2h |
| 19 | 较难题专项 | 重刷所有「较难」题 | 3h |
| 20 | 项目表达专项 | 练习 STAR 结构讲项目 | 2h |
| 21 | 口述模拟 | Ch9-Ch12 脱稿复述 | 2h |
本周必刷： Q9-1、Q10-1、Q11-1
第 4 周：冲刺模拟（查漏补缺 + 模拟面试）
目标： 全量过一遍，查漏补缺，模拟面试。
| Day | 任务 | 用时 |
|---|---|---|
| 22 | 必刷题全过一遍（13 题） | 2h |
| 23 | 高频题查漏（重点看不熟的） | 3h |
| 24 | 模拟面试 Round 1（自问自答） | 2h |
| 25 | 模拟面试 Round 2（找同学互问） | 2h |
| 26 | 薄弱章节定向补 | 2-3h |
| 27 | 常见追问全过一遍 | 2h |
| 28 | 最终回顾 + 心态调整 | 1.5h |
复习小贴士
- 先读速答再读正文： 每题先看下方速查表的一句话速答，再回到正文看完整答案，效率更高。
- 必刷题优先： 13 道必刷题一定要能脱稿讲，答不好会直接暴露短板。
- 常见追问别跳过： 面试官的追问往往比主问题更考察深度，建议每题至少把追问过一遍。
- 口述 > 默写： 面试是说的不是写的，Day 7/14/21 的口述模拟一定要出声练。
- 项目题提前准备： Q11-1 的 STAR 结构要提前用自己的项目套一遍，不要临场现编。
⚡ 一句话速答速查表
每题浓缩成一句话核心答法，快速过脑用。详细版见各题正文。
用法：复习时先遮住正文，只看速答，看能不能展开讲 2-3 分钟。
Ch1 基础认知与技术选型（5 题）
| 题号 | 一句话速答 |
|---|---|
| Q1-1 | RAG 解决"知识从哪来"（不改参数），微调解决"模型怎么表现"（改参数），可组合使用。 |
| Q1-2 | Agent = 模型 + 工具集 + 运行循环 + 当前状态，核心是动态决策而非单轮回答。 |
| Q1-3 | Prompt 缺表达、RAG 缺知识、微调缺行为稳定、Workflow 缺流程、Agent 缺动态决策——按问题类型选。 |
| Q1-4 | Token 是模型处理文本的基本计量单位，上下文窗口是单次推理 token 上限，直接影响成本、延迟和长文本能力。 |
| Q1-5 | 从效果、性能、成本、稳定性、治理性五维度看，RAG/Agent 额外关注召回质量和工具成功率。 |
Ch2 Prompt、结构化输出与护栏（6 题）
| 题号 | 一句话速答 |
|---|---|
| Q2-1 | System 放稳定约束（角色/规则/格式），User 放动态任务，分层便于版本管理和灰度。 |
| Q2-2 | 从纯 Prompt → Output Parser → Structured Output → Function Calling 递进，优先用原生结构化输出 + Pydantic。 |
| Q2-3 | Prompt Injection 是不可信输入改写系统指令，RAG 文档也可能带恶意指令，需五层防护（指令分层/内容隔离/工具权限/动作校验/观测兜底）。 |
| Q2-4 | Prompt 优化是工程闭环：任务拆解 + 样例驱动 + 评测回归 + 边界收敛，不是反复手改。 |
| Q2-5 | Prompt 解决任务表达，但不解决知识缺失、复杂状态管理和强执行需求，需配合 RAG/Tools/Graph。 |
| Q2-6 | Prompt 要当配置资产管理：模板 + 运行参数 + 评测集 + 发布信息一起版本化，换模型后必须回归。 |
Ch3 RAG 全链路（10 题）
| 题号 | 一句话速答 |
|---|---|
| Q3-1 | 完整 RAG = 索引阶段（加载/清洗/切块/向量化/写库）+ 检索阶段（改写/召回/重排/组装/生成/引用）。 |
| Q3-2 | 切块目标是保留语义单元，结合固定长度 + 段落边界 + 标题层级 + 重叠窗口，避免过碎或过大。 |
| Q3-3 | 按"检索前（query）→ 检索中（切块/Embedding/参数）→ 检索后（上下文组装）"三层排查。 |
| Q3-4 | 查询改写解决表达问题，混合检索解决漏关键词，重排解决顺序不准，三者解决不同层次问题。 |
| Q3-5 | RAG 接入 Agent 推荐"按需检索为主"——把检索封成工具，Agent 在需要时主动调用。 |
| Q3-6 | 企业 RAG 必须做权限隔离（租户/角色/文档级）、版本追踪和引用溯源，不只是"能查到"。 |
| Q3-7 | Lost in the Middle 指模型容易忽略中间信息，需 rerank + 过滤 + 重要证据前置，不是塞越多越好。 |
| Q3-8 | 长上下文扩大了可处理范围但没消灭检索价值，RAG 更适合海量知识、权限过滤和引用追溯。 |
| Q3-9 | 复杂文档 RAG 要先做版面分析/OCR/表格提取/标题恢复，按结构块切，不能当纯文本处理。 |
| Q3-10 | Agentic RAG 把检索当动态决策——可补检/改写/交叉验证，适合复杂多跳问题，但成本和失控风险更高。 |
Ch4 检索基础设施与检索优化（6 题）
| 题号 | 一句话速答 |
|---|---|
| Q4-1 | 向量数据库面向语义相似度检索，传统数据库面向精确查询，两者是分工关系不是替代。 |
| Q4-2 | Embedding 把内容变成向量，让"语义接近"变成"距离接近"，是语义检索的基础设施。 |
| Q4-3 | 选型先看语言/领域适配和建库查询一致性，再看检索层/业务层/工程层三维度表现。 |
| Q4-4 | 精确检索可控但成本高，近似检索牺牲精度换吞吐，线上系统通常用近似 + rerank 补偿。 |
| Q4-5 | 当核心是实体关系、路径推理、多跳关联时，知识图谱比纯向量检索更有价值。 |
| Q4-6 | GraphRAG 适合实体关系密/多跳推理场景，先用向量 RAG 打底，badcase 集中在多跳关系时再引入图谱。 |
Ch5 Tools、Function Calling 与 Agent（9 题）
| 题号 | 一句话速答 |
|---|---|
| Q5-1 | ReAct = Thought → Action → Observation 循环，把推理和行动串起来，适合不确定路径的多步任务。 |
| Q5-2 | Tool 是能力单元，Function Calling 是调用机制，Agent 是组织模型/工具/状态/决策的运行模式。 |
| Q5-3 | Agent = 模型 + 工具集 + 运行循环 + 当前状态，重点是目标单一、工具收敛、状态显式、停止条件和治理。 |
| Q5-4 | Function Calling = 模型负责决策（生成 tool_calls），程序负责执行，安全校验在宿主层。 |
| Q5-5 | Tool 设计四原则：单一职责、明确 schema、可观测、可失败，接业务系统还要加权限和审计。 |
| Q5-6 | 查天气/新闻类需求 = 意图识别 + 工具调用 + 结果整合，Prompt + Function Calling 往往就够。 |
| Q5-7 | 工具幻觉 = 调不存在工具/传错参数/误触发写操作，靠白名单 + schema 校验 + 工具收敛 + 高风险确认兜底。 |
| Q5-8 | JSON 解析是 Prompt 层要求，Function Calling 是协议级契约，后者可靠性更高、职责边界更清晰。 |
| Q5-9 | 工具多时做分层暴露 + 动态选择（Tool Retrieval）+ 工具聚合 + 描述治理，别让模型在工具海里盲选。 |
Ch6 Agent 框架与编排：LangChain、LCEL、LangGraph（7 题）
| 题号 | 一句话速答 |
|---|---|
| Q6-1 | LangGraph 把状态/节点/边/循环显式表达，让复杂流程可设计、可追踪、可恢复，不是"换种写法"。 |
| Q6-2 | State 是共享上下文，Node 是处理逻辑，Edge 是流转规则，图设计好不好取决于这三者是否清晰。 |
| Q6-3 | LangChain 价值在于统一接口（Prompt/Model/Parser/Retriever/Tools/Memory），解决应用层编排和生态整合。 |
| Q6-4 | Agent = 定义 Tools + 选 LLM + 设计 Prompt + 形成决策-执行-回传闭环，1.x 用 create_agent。 |
| Q6-5 | LCEL 把所有组件抽象成 Runnable，统一组合/调试/替换接口，不只是语法糖。 |
| Q6-6 | LangGraph 进阶四能力：流式（可观察）、持久化（可恢复）、时间回溯（可复盘）、子图（可维护）。 |
| Q6-7 | Checkpoint 负责可恢复，HITL 负责可控制，Time-Travel 负责可复盘——三者解决"停看批继续"。 |
Ch7 记忆、MCP 与多智能体（12 题）
| 题号 | 一句话速答 |
|---|---|
| Q7-1 | 上下文窗口是单次推理上限，短期记忆是会话级状态，长期记忆是跨会话信息，三者不能混用。 |
| Q7-2 | 短期记忆用消息历史/checkpointer，长期记忆用数据库/向量库按需召回，要区分原样保留/摘要/结构化/检索。 |
| Q7-3 | MCP 是模型上下文协议，统一外部工具/资源/提示模板的接入方式，不等于 Tool 也不等于 Agent。 |
| Q7-4 | Function Calling 靠近模型决策（怎么调），MCP 靠近生态接入（怎么统一暴露），是上下层关系。 |
| Q7-5 | MCP 跨平台来自"统一协议而非统一实现"，遵循同一消息结构就能互通。 |
| Q7-6 | MCP 四层：角色（Host/Client/Server）、能力（Tools/Resources/Prompts）、通信机制、传输方式。 |
| Q7-7 | MCP Server 开发 = 定能力边界 → 定义 schema → 选传输 → 实现 + 鉴权/日志/超时 → 客户端联调。 |
| Q7-8 | Agent 接 MCP = 发现能力 → 转成工具描述 → 模型决策调用 → 宿主发 MCP 请求 → 结果回传，关键在可控。 |
| Q7-9 | 流式 HTTP 让结果边产生边返回，降低首包延迟、支持长任务进度回传、利于取消和超时处理。 |
| Q7-10 | MCP 并发要三层看：协议层（唯一标识）+ 服务端（并行处理）+ 工具层（超时/限流/优先级）。 |
| Q7-11 | MCP 关注模型接外部能力，A2A 关注 Agent 间协作，多智能体不是越早越好，职责边界清晰时才拆。 |
| Q7-12 | 热门 MCP 工具集中在浏览器自动化、数据后端、文件代码、搜索知识四类，覆盖 Agent 常见外部需求。 |
Ch8 平台实践与框架选型：Coze、Dify、RAGFlow（5 题）
| 题号 | 一句话速答 |
|---|---|
| Q8-1 | Coze/Dify 是应用搭建层（低代码/可视化），LangChain/LangGraph 是底层编排层（代码级），不替代。 |
| Q8-2 | 框架选型看任务复杂度/团队能力/交付要求，能说替代方案和迁移路径比夸某个框架更有说服力。 |
| Q8-3 | 步骤固定/格式明确/强可控/易审计时用 Workflow；路径不固定/需动态决策时用 Agent。 |
| Q8-4 | 调 Dify/Coze 工作流重点：鉴权绑定、参数对齐、优先流式、超时控制、日志串联、幂等重试。 |
| Q8-5 | RAGFlow 重在文档导入/解析/检索，Dify/Coze 重在 Agent/工作流/插件，深度定制走自研。 |
Ch9 安全、评测、部署与可观测性（12 题）
| 题号 | 一句话速答 |
|---|---|
| Q9-1 | 评估拆离线（检索层 + 生成层）和在线（满意度/转人工率），Agent 还要看轨迹级（工具选择）和结果级。 |
| Q9-2 | 幻觉是链路系统问题，从知识层（RAG/引用/拒答）、执行层（Tool）、约束层（schema）、治理层（badcase 回灌）四层缓解。 |
| Q9-3 | 多用户 Agent 安全隔离分三层：环境层（Docker）、系统层（seccomp/非 root）、应用层（白名单/审计）。 |
| Q9-4 | Agent 运维看五类：效果（完成率）、性能（延迟/P95）、稳定性（成功率/超时）、成本（token）、治理（人工接管率）。 |
| Q9-5 | RAG 部署挑战在数据侧（解析/切块）、检索侧（召回/重排）、生成侧（忠实度）、治理侧（权限/版本）、评测侧、工程侧六类。 |
| Q9-6 | 模型对齐解决"基础行为别太离谱"，应用治理（权限/流程/审批/审计）解决"在业务系统里别出事"。 |
| Q9-7 | Agent 耗长要拆层：模型层、检索层、工具层、编排层、结果层，打 trace 看 wall time 花在哪。 |
| Q9-8 | 意图路由做多级：业务意图（FAQ/RAG/Tool/Agent）→ 子域路由 → 模型路由，低置信度不强判。 |
| Q9-9 | 可观测性 = 有日志 + 有指标 + 有 Trace，打通 trace_id 把请求/Prompt/模型/检索/工具/异常串起来。 |
| Q9-10 | 成本优化从模型层（高低配）、上下文层（压缩 Prompt）、检索层（优化召回）、流程层（减少 LLM 调用）四层下手。 |
| Q9-11 | 模型路由 = 意图路由 + 复杂度路由 + 成本路由，本质是效果/成本/稳定性的平衡器。 |
| Q9-12 | 内网 Agent/RAG 要做到数据不出域、模型可控、依赖可替换、链路可观测，应用层 + 推理层 + 数据层解耦。 |
Ch10 典型业务场景设计题（11 题）
| 题号 | 一句话速答 |
|---|---|
| Q10-1 | 企业知识库 = 数据接入 + 检索链路 + 生成链路 + 治理能力四层，企业场景还要预留转人工和索引回滚。 |
| Q10-2 | NL2SQL 控制四风险：schema 注入（做裁剪）、SQL 安全（只读/禁危险语句）、执行验证、歧义澄清。 |
| Q10-3 | 客服 Agent 优先：意图识别 + 知识检索 + 流程执行 + 人机协同 + 复盘闭环。 |
| Q10-4 | Agent 终止条件拆四层：任务层（达成目标）、工具层（关键调用成功）、状态层（进入终态）、保护层（步数/超时）。 |
| Q10-5 | Code Agent = 任务理解 + 代码库理解 + 计划执行 + 工具层 + 反馈闭环 + 安全治理，难点在上下文治理和验证闭环。 |
| Q10-6 | Deep Research = 查询规划 + 多轮检索 + 交叉验证 + 报告生成，不是把 RAG 上下文塞更长。 |
| Q10-7 | Deep Research 设计 = 查询规划器 + 检索执行器 + 信息融合层 + 迭代控制器 + 报告生成器。 |
| Q10-8 | Python 代码解释器 = 代码生成 + 沙箱执行 + 结果回传 + 状态管理 + 安全治理，难点在"有执行能力又不暴露宿主"。 |
| Q10-9 | 类 Manus = Agent 最小骨架扩展到长任务链，需任务规划 + 工具调度 + 状态记忆 + 执行反思 + 安全治理。 |
| Q10-10 | 浏览器 Agent = 页面感知 + 决策 + 执行 + 校验 + 治理，难点在网页不稳定和误操作成本高。 |
| Q10-11 | 软件 Agent 在数字系统操作（结构化/可回放），真实环境 Agent 多了感知噪声/物理副作用/实时反馈。 |
Ch11 项目表达与面试实战（3 题）
| 题号 | 一句话速答 |
|---|---|
| Q11-1 | 项目表达用 STAR：情境 → 任务 → 行动 → 结果，先讲业务目标再讲技术栈，给出可量化指标。 |
| Q11-2 | 回答"为什么不用 X"重点说当前选择和业务约束匹配，且知道替代方案、留了迁移路径。 |
| Q11-3 | 线上波动排障：先确认输入分布变化 → 模型/Prompt 变更 → 检索召回 → 工具调用 → 上下文组装 → 日志链路。 |
Ch12 工具生态与岗位认知（3 题）
| 题号 | 一句话速答 |
|---|---|
| Q12-1 | AI 开发工具按场景分：通用对话（ChatGPT/Claude）、AI 编码（Cursor/Claude Code/Copilot）、低代码平台（Dify/Coze）、RAG 平台（RAGFlow）。 |
| Q12-2 | Cursor 偏 IDE 内协作，Claude Code 偏终端代码库级 Agent，Copilot 偏轻量补全，看任务类型选。 |
| Q12-3 | AI 应用工程师关注"把模型能力稳定交付到业务系统"，算法研究岗关注"改进模型本身能力边界"。 |
1、基础认知与技术选型
Q1-1. RAG 和微调（SFT）的核心区别是什么？能不能一起用？
RAG 解决的是“知识从哪里来”，微调解决的是“模型应该怎么表现”。
RAG 不改模型参数，而是在运行时把相关资料检索出来，再交给模型生成答案，所以更适合处理时效性强、更新频繁、需要可溯源的知识。微调会改模型参数，更适合提升输出风格一致性、结构化能力、分类能力或领域行为稳定性。
它们当然可以一起用，而且很多企业项目就是这么落地的：用 RAG 提供知识，用微调或强约束输出提升行为稳定性。比如客服项目里，产品政策靠 RAG 保持最新，回复格式和字段输出靠微调或结构化输出保证稳定。
常见追问：
- 为什么多数企业项目不会优先做续训？
- 什么场景适合
RAG + 微调组合？ - 如果预算有限，先做哪一个？
重要度：必刷（出现次数：3次） | 难度：中等
**考察点：**知识增强和行为优化的区分能力。
对应章节：1-3 RAG、微调、续训与智能体选型 §1、RAG；1-3 RAG、微调、续训与智能体选型 §2、微调（Fine-tuning）
Q1-2. 什么是 AI Agent？它和传统 AI 应用的区别是什么？
可以概括为：Agent = 模型 + 工具集 + 运行循环 + 当前状态。
- 模型负责理解目标和决定下一步。
- 工具集负责提供外部能力。
- 运行循环负责让系统不是只回答一次，而是能“想一步、做一步、看结果、再决定下一步”。
- 当前状态负责保存消息、工具结果和中间结论。
传统 AI 应用更接近“输入一个请求，返回一个结果”的单轮系统；Agent 更接近“围绕目标持续做决策”的运行方式。它的关键不只是用了大模型，而是具备了工具调用、状态推进和动态决策能力。
所以不是所有 AI 应用都该叫 Agent。固定表单生成、固定知识问答、固定流程审批，这类系统往往用普通链路或 Workflow 就够了。只有在路径不固定、需要根据中间结果继续选择工具或调整路线时，Agent 才真正合适。
另外也要注意，很多人会把“长期记忆、复杂规划、多智能体协作”都当成 Agent 的必备条件，不是。对很多入门场景来说，能做到“理解目标、决定是否调工具、拿到结果再继续判断”，就已经是 Agent 了。
重要度：高频（出现次数：2次） | 难度：基础
**考察点：**是否理解 Agent 的本质，不会把任何聊天机器人都叫 Agent。
对应章节：21 Agent智能体 §1、Agent 简介；1-3 RAG、微调、续训与智能体选型 §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、微调、续训与智能体选型 §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、认识大模型；11 Model I/O 与模型接入 §2、LangChain 模型分类、参数与返回
**来源：**腾讯AI后台工程师一面（实际大厂面试题）
Q1-5. 大模型应用上线前你最关心哪些工程指标？
通常会从效果、性能、成本、稳定性、治理性五个维度看。
- 效果：准确率、忠实度、任务完成率、引用正确率。
- 性能：首 token 延迟、端到端延迟、P95/P99。
- 成本：token 消耗、检索成本、工具调用成本。
- 稳定性：超时率、错误率、重试率、降级命中率。
- 治理性：日志、Trace、Prompt 版本、索引版本、权限审计。
如果是 RAG / Agent 项目，我还会额外看检索召回质量、工具调用成功率、人工兜底比例和 badcase 回灌效率，因为这些才是真正影响线上体验的关键指标。
常见追问：
- 你怎么设计降级策略？
- 如果成本超预算，先优化哪一层？
- 怎样做 Prompt / 模型 / 索引回滚？
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**是否具备生产环境意识。
对应章节：1-1 大模型认知与工程概览 §4、大模型的工程实现（概览）；7 企业级大模型部署 §1、企业级大模型部署概述
2、Prompt、结构化输出与护栏
Q2-1. System Message 和 User Message 应该怎么分工？
System Message 负责放稳定约束，User Message 负责放动态任务。
System 里一般放角色、目标、边界、安全规则、输出格式要求、工具使用规范，这些内容应该尽量稳定、少改。User Message 放用户当次任务、输入数据、补充上下文和个性化要求。
这样拆分的好处是结构更清晰，便于版本管理，也更适合后续做模板化、灰度和评测。如果把所有内容都混在一段 prompt 里，后面排查效果波动会非常困难。
重要度：必刷（出现次数：1次） | 难度：基础
**考察点：**Prompt 分层设计能力。
对应章节：13 提示词与消息模板 §3、入参的消息类型；13 提示词与消息模板 §7、对话提示词模板（ChatPromptTemplate）
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”当成真正的生产方案，更稳的顺序通常是：
- 能用原生结构化输出就优先用。
- 需要强校验时优先用 Pydantic 一类 schema。
- 即使模型已经结构化输出，也要补业务校验、缺省值处理和失败重试。
归根结底，Prompt 只能“尽量要求它长成这样”，Parser 和 Structured Output 才是在帮你把模型输出真正接进程序系统。
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**从“能输出 JSON”到“能稳定接系统”的工程意识。
对应章节：14 输出解析器 §1、输出解析器简介；14 输出解析器 §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 简介；17 Tools工具调用 §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、提示词怎么写；14 输出解析器 §8、实际开发选择
Q2-5. Prompt 工程的边界是什么？为什么不能把一切问题都交给 Prompt？
Prompt 更接近一种“任务表达和约束手段”，但它解决不了知识缺失、复杂状态管理和强执行需求。
比如资料太多时，仅靠 Prompt 塞上下文会出现成本高、噪声多、丢关键信息的问题，这时候应转向 RAG。多步骤复杂流程如果全靠 Prompt 硬编排，会变成不可维护的长指令，应该转 Workflow 或 LangGraph。需要稳定调用外部系统时，应该走 Tools / Function Calling，而不是让模型在文本里“假装调用了接口”。
所以工程上更合理的思路是：Prompt 负责表达规则，RAG 负责补知识，Tools 负责执行能力，Graph / Workflow 负责流程控制。
重要度：中频（出现次数：1次） | 难度：基础
**考察点：**是否理解 Prompt 不是万能药。
对应章节：1-2 提示词工程基础 §4、提示词工程的边界；13 提示词与消息模板 §1、Prompt 简介
Q2-6. 如何做 Prompt 版本管理与回归？
如果 Prompt 已经进入生产环境，就不能再把它当成一段“临时改改的字符串”，而要把它当成配置资产或代码资产来管理。
通常会同时管理四样东西：
- Prompt 模板本身：System、User 模板、few-shot 示例、输出格式要求。
- 运行参数：模型名、模型版本、temperature、top_p、max_tokens。
- 评测集：固定 golden questions、典型 badcase、失败样例。
- 发布信息：模板版本号、发布时间、负责人、灰度范围、回滚版本。
更稳的做法通常是：
- Prompt 和代码一起版本化，或者放进配置中心统一管理。
- 每次改 Prompt 都跑固定回归集，不只看主观感觉。
- 记录模板 hash、模型版本和关键参数，避免“明明没改 Prompt，效果却变了”时查不清原因。
- 上线前做灰度和抽样人工复核，高风险链路保留快速回滚能力。
还有一个很容易被忽略的点：换底层模型后，旧 Prompt 不一定还能保持原效果。 所以很多时候回归的对象不是“这段 Prompt 对不对”，而是“Prompt 和当前模型组合起来还稳不稳”。
常见追问：
- golden set 应该怎么构建？
- 如果线上效果波动，你怎么判断是 Prompt 问题还是模型版本问题？
- Prompt、模型、索引三者一起变更时，如何设计回滚策略？
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**Prompt 工程化治理能力，而不是只会手改提示词。
对应章节：13 提示词与消息模板 §8、从文件加载提示词；1-2 提示词工程基础 §5、提示词工程的几个注意点
3、RAG 全链路
Q3-1. 请描述一个完整的 RAG 流水线。
完整 RAG 一般分索引阶段和检索阶段。
索引阶段是：文档加载、清洗、切块、向量化、写入向量库，并补充元数据。检索阶段是：接收问题、必要时做 query 改写、检索召回、重排过滤、上下文组装、交给模型生成答案，最后再做引用、脱敏和格式化输出。
工程上真正难的通常不在“把模型接起来”，而在三件事：文档是否被正确解析，切块是否保留语义，检索结果是否真的对当前问题有帮助。线上效果差，大多数时候也是卡在这三层，而不是卡在最后那一轮生成。
常见追问：
- chunk 应该怎么切？
- metadata 应该存哪些字段？
- 为什么要加 rerank？
重要度：必刷（出现次数：3次） | 难度：中等
**考察点：**是否真正理解 RAG，而不是只会说“检索增强生成”。
对应章节：19 RAG检索增强生成 §1、RAG 简介；19 RAG检索增强生成 §2、RAG 文本处理核心知识
Q3-2. 文本切块应该怎么设计？有哪些常见坑？
切块的目标不是“切得均匀”，而是“尽量保留对检索有意义的语义单元”。
通常会结合固定长度、段落边界、标题层级和重叠窗口来设计。太大，会导致噪声多、命中不准；太小，会丢上下文，检索回来也无法回答。对于手册、FAQ、制度文档、图文混排 PDF，这些文档往往不能只按字符数切，还要结合版面结构、标题、表格和语义边界。
常见坑包括：切块过碎、忽略标题层级、重叠不足、纯 OCR 文本脏乱不清洗、表格内容被打散，以及把多个主题塞进一个 chunk 导致向量语义污染。
重要度：高频（出现次数：3次） | 难度：中等
**考察点：**RAG 基础功是否扎实。
对应章节：19 RAG检索增强生成 §2、RAG 文本处理核心知识；2-RAG 搭建企业私有&个人知识库 §2、知识库的概述
Q3-3. RAG 效果不好时，你会怎么排查？
排查时可按“检索前、检索中、检索后”三层展开。
- 检索前：看 query 是否表达清楚，是否需要改写、拆问、补充上下文。
- 检索中：看切块、Embedding、向量库索引参数、top_k、过滤条件、重排是否合理。
- 检索后：看拼给模型的上下文是否过长、是否有噪声、是否出现关键信息被淹没、生成提示是否要求“无依据就拒答”。
如果是企业知识库，还要额外查文档质量、版本是否最新、权限过滤是否误伤。很多所谓“模型不聪明”的问题，最后都能定位到文档解析脏、chunk 太碎、召回噪声大或者上下文组装差。
常见追问：
- top_k 是不是越大越好？
- 如何识别是召回问题还是生成问题？
- 什么是 Lost in the Middle？
重要度：必刷（出现次数：1次） | 难度：中等
**考察点：**排障能力、定位思路是否分层。
对应章节：19 RAG检索增强生成 §2、RAG 文本处理核心知识；19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手
Q3-4. 混合检索、重排序和查询改写分别解决什么问题？
这三者解决的是三个不同层次的问题。
- 查询改写解决“用户问题表达得不够像检索语句”的问题。
- 混合检索解决“只靠稠密向量可能漏掉关键词命中”的问题。
- 重排序解决“召回了一批候选，但顺序还不够准”的问题。
真实项目里，尤其是制度、产品参数、订单字段、错误码这类知识，关键词常常非常重要，所以仅靠 dense retrieval 往往不够。比较稳的方案通常是“query 改写 + 稠密检索 + 稀疏检索 + rerank”，再结合 metadata 过滤做收口。
常见追问：
- 稠密检索和稀疏检索的区别是什么？
- Rerank 放在哪一层最合适？
- 混合检索会不会更贵？
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**是否理解检索优化的职责分工。
对应章节：18 向量数据库与Embedding实战 §6、向量库的写入与检索；19 RAG检索增强生成 §2、RAG 文本处理核心知识
Q3-5. RAG 应该如何接入 Agent 执行链路？
RAG 接到 Agent 里，不能只理解成“先查一遍资料再回答”，更稳的做法通常是把检索能力做成 Agent 可按需调用的一环。
常见有三种接法：
- 前置检索：用户问题一进来先统一检索，再把证据交给 Agent 继续规划。
- 按需检索：把 Retriever / Search 封成工具，Agent 在需要事实依据时主动调用。
- 后置校验：先生成结果，再用检索做证据核对或引用补全。
真实项目里，通常更推荐“按需检索为主，前置检索为辅”。因为不是每一步都需要查知识库，有些步骤是规划、路由、参数确认或工具执行。把 RAG 做成可调用能力，能减少无效检索，也更适合多步任务。后置校验可以作为增强，但通常不适合作为主链路，否则会增加延迟，而且一旦前面已经跑偏，后面再校验修正成本会更高。
常见追问：
- 你了解生成过程中多次检索、自适应检索或 Agentic RAG 吗？它和“先检索一次再生成”有什么区别？
- 什么情况下应该从“一次检索”升级成“多轮检索 + 中途补检”？
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**是否理解 Agentic RAG 的接入方式，而不是只会把 RAG 当成固定前置流水线。
对应章节：19 RAG检索增强生成 §1、RAG 简介；21 Agent智能体 §6、小结：Agent、Tool、Function Calling、RAG、MCP 的区别与联系
Q3-6. 为什么企业项目里的 RAG 必须重视权限、版本和引用？
因为企业知识不是“能查到就行”，而是“要查对、查对权限范围、还能追溯来源”。
权限上，向量检索必须做租户隔离、角色过滤、文档级或段落级权限控制，不能把安全寄希望于模型“自觉不回答”。版本上，索引和源文档要可追踪，文档更新后要知道哪些向量需要增量重建。引用上，如果答案不能回溯到原文片段，业务方很难建立信任，也不利于审计和复盘。
所以在企业里，RAG 不只是检索效果问题，更是数据治理问题。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**企业落地意识，不只停留在 Demo。
对应章节：2-RAG 搭建企业私有&个人知识库 §2、知识库的概述；19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手
Q3-7. 什么是 Lost in the Middle？它对 RAG 设计有什么启示？
Lost in the Middle 指的是：上下文一长，模型往往更容易利用开头和结尾的信息，而把中间那部分关键证据“看见了但没用好”。
它对 RAG 的启示非常直接：不是把更多 chunk 塞进上下文就一定更好。如果中间噪声太多，真正关键的证据反而更容易被淹没。
因此，工程上通常采用以下处理方式：
- 先做 rerank 和过滤，再决定谁能进上下文。
- 尽量减少低价值片段，别把“可能相关”都塞进去。
- 重要证据优先放前面，必要时做摘要或结论前置。
- 对复杂问题采用分阶段检索，而不是一次性把大段材料全塞进去。
总结来说：长上下文不等于高质量上下文，RAG 的核心仍然是“把最有用的证据放到最容易被模型用到的位置”。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**长上下文理解能力，以及检索、重排、上下文组装之间的联动意识。
对应章节：19 RAG检索增强生成 §2、RAG 文本处理核心知识；19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手
Q3-8. 有了超长上下文模型，还需要 RAG 吗？
多数场景下仍然需要，因为“能塞进去”和“应该塞进去”完全不是一回事。
超长上下文模型确实让长文理解、少量文档内推理变得更方便，但企业场景里更常见的问题不是“模型窗口不够大”，而是：
- 知识总量太大，没法每次都全塞。
- 长上下文成本和延迟都更高。
- 权限过滤、租户隔离、版本控制不能只靠窗口硬塞解决。
- 审计和引用追溯更适合通过检索链路来做。
所以更合理的理解通常是：长上下文扩大了可处理范围，但没有消灭检索的价值。 它更适合少量长文档分析、上下文整合和复杂推理；RAG 更适合海量知识缩圈、权限过滤、证据引用和持续更新。
如果压缩成一句话，可以概括为：长上下文不是 RAG 的替代品，更接近 RAG 的补充能力。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**是否理解“长窗口能力”和“检索系统价值”不是同一层问题。
对应章节：19 RAG检索增强生成 §1、RAG 简介；1-1 大模型认知与工程概览 §1、认识大模型
Q3-9. 复杂文档 RAG 或多模态 RAG 应该怎么做？
这类场景最大的坑，是把 PDF、扫描件、表格、图片、网页全都当成“普通纯文本”来处理。
更稳的做法通常是先把解析层单独看待：
- 先做版面分析、OCR、表格提取、标题层级恢复，而不是一开始就按字符切块。
- chunk 尽量按结构块切，比如标题、段落、表格、图注，而不是把一张表切成几段残缺文本。
- metadata 要保留页码、章节标题、文档版本、来源文件、坐标或结构位置信息，方便引用和追溯。
- 查询时必要时走多路召回，例如文本召回、表格召回、图片说明召回，再统一重排和组装。
如果是企业知识库，复杂文档 RAG 往往比“模型选型”更影响上限。因为解析错了、表格碎了、图文对应关系丢了，后面再强的模型也很难补回来。
常见追问：
- 为什么很多设备手册、制度 PDF 特别难做 RAG？
- OCR 准确率和最终问答效果是什么关系？
- 多模态 RAG 什么时候值得上，什么时候纯文本就够？
重要度：中频（出现次数：1次） | 难度：较难
**考察点：**是否意识到 RAG 不只是检索问题，还包括文档解析、结构恢复和引用追踪。
对应章节：19 RAG检索增强生成 §2、RAG 文本处理核心知识；2-RAG 搭建企业私有&个人知识库 §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 简介；21 Agent智能体 §1、Agent 简介
4、检索基础设施与检索优化
Q4-1. 什么是向量数据库？它和传统数据库有什么区别？为什么不能只用 MySQL？
先下一个定义：向量数据库是一种专门面向“相似度检索”的存储系统，用来保存向量、原始内容和元数据，并支持近邻搜索、过滤和召回。
传统数据库擅长精确过滤、事务和结构化查询，而向量数据库擅长按“语义相似度”做近邻检索。两者不是替代关系，而是分工关系。
如果只用 MySQL，你当然也能存 Embedding，但一旦数据量上来，近似向量检索、ANN 索引、混合检索和大规模召回都会变得低效，而且工程复杂度会明显上升。企业里更常见的做法是：结构化条件走传统数据库，语义召回走向量库，再通过 metadata 把两边结合起来。
重要度：高频（出现次数：2次） | 难度：基础
**考察点：**底层检索设施理解。
对应章节：18 向量数据库与Embedding实战 §2、向量数据库；18 向量数据库与Embedding实战 §6、向量库的写入与检索
Q4-2. Embedding 是什么？它在应用开发里最核心的价值是什么？
Embedding 的本质，是把文本、图片这类原始内容变成一串固定长度的向量，让“语义关系”尽量映射成“空间关系”。换一种工程化表述，就是把“意思接近”变成“距离接近”，这样程序才能做相似度计算。
它在应用开发里最核心的价值，不只是“把文本编码成数字”，而是让系统第一次具备了按语义检索的能力。所以它常被拿来做语义搜索、相似匹配、去重、聚类、推荐和 RAG 召回。
放到 RAG 里，Embedding 决定的是“问题和知识能不能在向量空间里正确相遇”。如果 Embedding 选错了，后面的向量库、重排、Prompt 再怎么补，也只能在一个偏掉的召回基础上做优化。
另外有两个工程细节需要特别强调：
- 建库和查询最好用同一套 Embedding 模型，不然要么维度对不上，要么即使维度一样，相似度也可能没有意义。
- Embedding 只是把文本变成“稠密向量”这一层，真正检索时往往还会和标量字段过滤、甚至稀疏检索一起配合，不能把它理解成检索系统的全部。
重要度：高频（出现次数：1次） | 难度：基础
**考察点：**是否理解 Embedding 不是“附属模型”，而是检索基础设施。
对应章节：18 向量数据库与Embedding实战 §1、向量与向量化；18 向量数据库与Embedding实战 §4、Embedding 文本向量化
Q4-3. 如何选择一个合适的 Embedding 模型？评估它好坏看什么？
通常不会先看榜单，而是先看自己的知识类型和检索目标，再反推模型选型。更合理的思路是先看三件事：
- 语言和领域适配：中文、英文、多语言、代码、法律、金融，适合的模型可能完全不同。
- 建库和查询一致性：建库和查询尽量使用同一套 Embedding 模型，这是底线。
- 成本和延迟是否可接受：不是维度越高越好，也不是模型越大越好，要看知识库规模和查询量能不能撑住。
真正评估时，更应关注“它有没有把整条检索链路整体抬起来”，而不是只看一个榜单分数。比较实用的判断通常有三层：
- 检索层：相关片段有没有更容易被召回，坏例子有没有减少，重排前后的差距大不大。
- 业务层：最终答案的忠实度、引用准确性、任务完成率有没有变好。
- 工程层：延迟、成本、接入复杂度能不能接受。
工程上需要特别强调两点：
- Embedding 选型不是孤立问题，它会和切块策略、索引参数、混合检索、rerank 一起决定上限。
- 公开榜单只能做初筛，真正能决定要不要上线的，还是你自己的知识样本和 badcase。
所以更稳的做法通常是：先选两到三套候选模型跑通，再在自己的知识库样本上做小规模对比，观察召回质量、最终回答质量和成本延迟，最后再决定。
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**Embedding 选型、评测意识，以及“模型一致性 + 检索链路联动”的理解。
对应章节：18 向量数据库与Embedding实战 §4、Embedding 文本向量化；18 向量数据库与Embedding实战 §6、向量库的写入与检索
Q4-4. 近似检索和精确检索怎么权衡？
精确检索效果更可控，但在大规模数据下成本高、延迟高。近似检索牺牲一部分精确性，换来更好的吞吐和响应速度，所以大部分线上系统都会优先用近似检索。
工程上不是简单二选一，而是看业务要求。如果是高风险检索、数据量不大、对结果一致性要求极高，可以用精确或更保守的索引策略。如果是通用知识问答、商品搜索、海量文档召回，近似检索通常更现实，再配合 rerank 做补偿。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**性能和效果取舍能力。
对应章节：18 向量数据库与Embedding实战 §2、向量数据库；18 向量数据库与Embedding实战 §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）；17 Tools工具调用 §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 简介；21 Agent智能体 §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智能体 §6、小结：Agent、Tool、Function Calling、RAG、MCP 的区别与联系
Q5-4. Function Calling 的基本原理是什么？
Function Calling 的核心分工，可以概括成一句话：模型负责决策，程序负责执行。
更完整地说，这条链路通常是：
- 宿主程序把工具的
name、description、参数 schema 一起发给模型。 - 模型判断要不要调用工具，如果要，会先返回结构化的
tool_calls，而不是直接给最终自然语言。 - 宿主程序读取
AIMessage.tool_calls，真正去执行 Python 函数、HTTP API、数据库查询或业务服务。 - 程序把执行结果封成
ToolMessage或等价消息，再交回模型。 - 模型基于工具结果生成最终答复。
所以 Function Calling 不是模型自己去调 API，它只是生成“调用哪个工具、传什么参数”的结构化意图。真正的鉴权、参数校验、超时、幂等、重试和安全控制，仍然都在宿主程序这一层。
如果要答得更工程化，还需要补一句：Function Calling 解决的是“模型如何表达调用意图”，不解决“工具是否安全、是否允许调用、调用失败怎么兜底”这些问题。
常见追问：
- Function Calling 和文本解析调用有什么区别？
- 为什么生产环境更推荐原生 Tool Calling？
- 工具执行失败怎么处理？
重要度：必刷（出现次数：1次） | 难度：中等
**考察点：**是否理解模型和宿主程序的职责边界。
对应章节：17 Tools工具调用 §1、Tools 简介；17 Tools工具调用 §2、工具调用的工作方式
**来源：**腾讯AI后台工程师一面（实际大厂面试题）
Q5-5. 设计 Tool 时最值得重视的工程原则是什么？
最值得重视的四点是：单一职责、明确 schema、可观测、可失败。
单一职责意味着一个 Tool 只做一件清晰的事，避免“大而全万能工具”。明确 schema 是为了让模型更稳定地理解参数含义。可观测意味着每次调用都要能追踪请求、参数、耗时、结果和错误。可失败意味着工具必须有超时、异常码、重试策略和降级逻辑，而不是假设一定成功。
如果 Tool 要连业务系统，还要加权限校验、幂等控制和审计日志。因为工具一旦从“查天气”变成“发消息、下工单、写数据库”，风险等级就完全不同了。
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**是否有把工具接到生产系统的经验意识。
对应章节：17 Tools工具调用 §3、自定义 Tool；17 Tools工具调用 §4、参数 schema：为什么要配合 Pydantic
Q5-6. 如果让你实现一个“查天气、查新闻”的 AI 助手，你会怎么设计？
这类题在面试里更推荐先做场景判断，再谈方案。像查天气、查新闻这种需求，核心不是复杂规划，而是“意图识别 + 工具调用 + 结果整合”。
一个比较稳的实现通常包括四层：
- 输入与路由层：先判断用户是查天气、查新闻，还是两者都要。必要时抽取城市、时间、新闻主题等参数。
- 工具层：把天气查询和新闻检索分别封成清晰的 Tool，定义好 schema、参数说明、异常返回和超时策略。
- 调度层：先用 Function Calling 或轻量 Agent，让模型决定调用哪个工具、怎么传参、要不要串联多个工具。
- 输出层：把工具结果做统一整理，比如天气给关键字段，新闻给摘要和来源，最后再由模型生成自然语言回复。
如果需求只是单轮查天气、查新闻， Prompt + Function Calling 往往就够了，不一定要上完整 ReAct Agent。只有在需求升级成“先查天气，再根据天气推荐本地新闻，再继续追问某条新闻细节”这种多步动态链路时，Agent 的价值才会更明显。
工程上需要特别关注三点：工具描述要清楚，避免模型乱调；外部 API 要有降级和超时；结果输出最好带来源或关键字段，避免模型把工具结果又二次编造一遍。
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**能否把一个简单助手拆成“意图、工具、调度、输出”四层，而不是一股脑说上 Agent。
对应章节：17 Tools工具调用 §5、天气助手实战；21 Agent智能体 §5、实操与案例
**来源：**腾讯AI后台工程师一面（实际大厂面试题）
Q5-7. 什么是“工具幻觉”？工程上怎么缓解？
工具幻觉指的是：模型调用了不存在的工具、传了不合理的参数，或者在只该读数据时却试图触发写操作。
这类问题在工具数量多、描述模糊、schema 不清晰时特别常见。模型有时不是“不会用工具”，而是“对工具边界理解错了”。
工程上通常会这样兜底：
- 工具注册表白名单：不存在的工具名直接拒绝。
- schema 强校验：参数类型、必填项、枚举值都要在运行时校验，不信任模型返回。
- 工具集收敛：按场景暴露最小工具集，别让模型在几十个相近工具里乱猜。
- 描述清晰：工具名、description、参数含义要能明显区分读写边界和适用场景。
- 高风险确认：涉及发消息、写数据库、发工单、下单等副作用动作，必须审批或二次确认。
- 失败反馈：把错误原因回传给模型，让它有机会修正，但要限制重试次数，避免死循环。
可以概括为：Tool Calling 不是“接上就行”，而是要让模型“调得准、调得住、调错了也出不了大事”。
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**对 Tool Use 稳定性和风险控制的理解。
对应章节：17 Tools工具调用 §6、从课程案例走向真实项目；17 Tools工具调用 §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、结构化输出；17 Tools工具调用 §2、工具调用的工作方式
Q5-9. 当工具很多时，如何控制上下文长度和调用稳定性？
工具一多，问题通常不再是“会不会调工具”，而是“会不会在一堆相似工具里选错、调错、调得越来越乱”。
比较稳的做法通常有四类：
- 分层暴露：先按业务域拆成搜索类、数据类、执行类、写操作类，不要一次把所有工具都暴露给同一个 Agent。
- 动态选择：先做 Tool Retrieval 或路由，只把 Top-N 个最相关工具描述放进当前上下文，而不是全量列出来。
- 工具聚合：把过细的底层 API 封装成更高层的业务动作，减少模型在几十个相近函数里猜名字。
- 描述治理：工具名、description、参数说明里要明确“什么时候用、什么时候不用、有没有副作用”。
如果再往前走一步，生产里还可以把“工具选择”本身做成一个独立阶段，比如先做意图分类或子域路由，再进入具体工具调用。这样既能控上下文长度，也能降低工具幻觉和误调用概率。
可以概括为：工具多不是问题，关键是别让模型在一个没有层次的工具海里盲选。
常见追问：
- 工具太多时，应该优先做路由还是优先改工具粒度？
- Tool Retrieval 和普通知识检索有什么区别？
- 为什么业务动作级工具通常比原子 API 更适合模型调用？
重要度：中频（出现次数：1次） | 难度：较难
**考察点：**多工具场景下的上下文治理和工具编排能力。
对应章节：17 Tools工具调用 §6、从课程案例走向真实项目；21 Agent智能体 §5、实操与案例
6、Agent 框架与编排：LangChain、LCEL、LangGraph
Q6-1. LangGraph 相比普通 Workflow 或链式调用，最大的价值是什么？
LangGraph 最大的价值是把复杂流程中的状态、节点、边和循环显式表达出来，让大模型驱动的动态流程真正可设计、可追踪、可恢复。
普通链式调用适合简单串行流程，Workflow 适合固定路径，而 LangGraph 更适合有分支、循环、人工中断、状态持久化和多 Agent 协作的任务。它不是“换一种写法”，而是把复杂控制流从隐式逻辑变成显式图结构。
所以当你发现系统开始出现“要不要继续查、什么时候结束、失败后从哪恢复、状态怎么跨轮保留”这些问题时，LangGraph 的优势就出来了。
常见追问：
- LangGraph 和 Agent 的关系是什么？
- 什么场景下普通 Workflow 就够了？
- 图编排的维护成本会不会更高？
重要度：必刷（出现次数：1次） | 难度：中等
**考察点：**是否理解图编排的必要性。
对应章节：22 LangGraph概述与快速入门 §1、LangGraph 简介；23 LangGraphAPI：图与状态 §1、Graph API 之 Graph
Q6-2. 在 LangGraph 里，State、Node、Edge 分别代表什么？
State 是共享状态，Node 是处理逻辑，Edge 是流转规则。
State 决定图里“大家共同操作的上下文”是什么；Node 决定每一步具体做什么，比如调用模型、查库、执行工具；Edge 决定执行完当前节点后下一步去哪里，可以是固定跳转，也可以是条件路由。
真实项目里，LangGraph 设计得好不好，往往取决于 State 是否清晰、Node 粒度是否合理、Edge 条件是否可解释。很多图写得难维护，不是因为图本身复杂，而是把太多隐式逻辑塞进了一个节点。
重要度：高频（出现次数：1次） | 难度：基础
**考察点：**LangGraph 基础心智模型。
对应章节：23 LangGraphAPI：图与状态 §2、Graph API 之 State；24 LangGraphAPI：节点、边与进阶 §2、Graph API 之 Edge
Q6-3. LangChain 在今天的价值是什么？为什么不是直接手写 SDK 就够了？
LangChain 的价值不在于“能不能调模型”，而在于它把模型输入输出、Prompt、Parser、Retriever、Tools、Memory、Callbacks 等常见能力统一成了一套可组合接口。
如果只是做一个最小 Demo，直接手写 SDK 当然可以。但一旦进入多模型接入、链式编排、结构化输出、可观测和长期维护阶段，统一抽象会明显降低代码分散度。它真正解决的是“应用层编排和生态整合”问题，而不是“替你发一个 HTTP 请求”。
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**框架选型判断，而不是盲目崇拜框架。
对应章节：9 LangChain概述与架构 §2、LangChain 定位；9 LangChain概述与架构 §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、实操与案例；17 Tools工具调用 §5、天气助手实战
Q6-5. LCEL 的价值是什么？为什么说它不只是语法糖？
LCEL 的核心价值是把 Prompt、Model、Parser、Retriever、函数逻辑都抽象成 Runnable，然后通过统一方式组合和调用。
它不只是写法更短，而是让顺序链、分支链、并行链、函数链能够用同一种接口去拼装、调试和替换。这对真实项目很有价值，因为你后面做日志、流式、批处理、回调和局部替换时，统一接口会让系统更可维护。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**是否理解链式编排的统一接口思想。
对应章节：15 LCEL与链式调用 §1、Runnable 与统一调用方式；15 LCEL与链式调用 §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高级特性 §2、状态持久化（Persistence）；25 LangGraph高级特性 §3、时间回溯（Time-Travel）；25 LangGraph高级特性 §4、子图（Subgraphs）
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高级特性 §3、时间回溯（Time-Travel）
7、记忆、MCP 与多智能体
Q7-1. 上下文窗口、短期记忆、长期记忆分别是什么关系？
上下文窗口是模型单次推理能看到的内容上限，短期记忆是会话级状态，长期记忆是跨会话保留的用户或任务信息。
工程上不能把这三者混为一谈。窗口是昂贵资源，不能无限塞历史。短期记忆一般保留当前任务相关历史、摘要、线程状态。长期记忆则更适合存偏好、画像、历史结论和可复用事实，需要按需检索，不应该每次全量放进 prompt。
所以一个成熟的系统通常是：窗口里只放高信号上下文，短期记忆保证当前线程不断档，长期记忆通过数据库或向量库按需召回。
常见追问：
- 记忆和 RAG 的区别是什么？
- 为什么说记忆不是训练模型？
- Redis 在记忆里适合做什么？
- 如果上下文太长被截断了，你会选滑动窗口、摘要压缩还是检索式补充？怎么判断？
重要度：必刷（出现次数：3次） | 难度：中等
**考察点：**对话系统和 Agent 的状态设计能力。
对应章节：16 记忆与对话历史 §1、记忆简介；25 LangGraph高级特性 §2、状态持久化（Persistence）
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；25 LangGraph高级特性 §2、状态持久化（Persistence）
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模型上下文协议 §3、MCP 能做什么
**来源：**腾讯AI后台工程师一面（实际大厂面试题）
Q7-4. MCP 和 Function Calling 的关系是什么？
Function Calling 更接近模型侧的“结构化调用机制”，MCP 更接近应用侧的“统一能力接入协议”。
前者解决的是模型如何表达“要调用哪个函数、传什么参数”；后者解决的是不同外部工具、资源、提示模板如何用统一标准暴露给客户端。两者不是替代关系，而是上下层关系。
可以简单理解为：Function Calling 更靠近模型决策，MCP 更靠近生态接入和协议标准化。真正落地时，Agent 完全可以在 MCP 暴露的能力之上继续用 Function Calling 做调用决策。
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**协议层和调用机制的边界理解。
对应章节：20 MCP模型上下文协议 §2、MCP 简介；17 Tools工具调用 §2、工具调用的工作方式
Q7-5. MCP 是如何做到跨平台兼容的？
MCP 的跨平台兼容，本质上来自“统一协议，而不是统一实现”。
也就是说，不同平台、不同语言、不同宿主程序，只要都遵循同一套消息结构、能力暴露方式和调用约定，就能在协议层互通。这样客户端不需要为每一个外部系统写一套私有接入方式，服务端也能按标准暴露能力。
所以 MCP 的价值不在于它绑定了某个技术栈，而在于它把接入差异收敛成了统一的协议面。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**协议标准化的理解。
对应章节：20 MCP模型上下文协议 §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模型上下文协议 §3、MCP 能做什么
Q7-7. MCP 服务器开发流程是什么？
一个 MCP Server 的典型开发流程通常是：
- 明确要暴露的能力边界，是工具、资源还是提示模板。
- 定义输入输出 schema 和错误处理方式。
- 选择传输方式，比如 STDIO 或 HTTP。
- 实现服务端逻辑，并补齐鉴权、日志、超时和异常处理。
- 在客户端完成注册、发现、调用和联调测试。
工程上最容易被忽略的是能力边界和错误处理。MCP Server 不是简单把现有 API 套一层壳，而是要把能力设计成真正适合模型消费的接口。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**是否理解 MCP 不只是“会用”，还包括服务端建设。
对应章节：20 MCP模型上下文协议 §4、怎么用 MCP；20 MCP模型上下文协议 §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模型上下文协议 §6、案例实战：本地 MCP 天气服务与客户端
Q7-9. MCP 的流式 HTTP 传输核心优势是什么？
流式 HTTP 的核心价值，是让结果可以边产生边返回，而不是必须等整次调用结束后一次性返回。
这样做有三个直接好处：
- 降低首包延迟，用户更快看到反馈。
- 支持长任务的中途进度回传，减少“卡死感”。
- 更利于宿主做取消、超时和部分结果处理。
对于 Agent 或研究型任务，这种能力尤其重要，因为很多调用本来就不是“瞬时完成”的。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**流式协议在体验和并发上的价值理解。
对应章节：20 MCP模型上下文协议 §5、MCP 架构知识
Q7-10. MCP 调用如何保证并发？
MCP 并发能力不只是协议本身决定的，更取决于宿主和服务端如何设计请求处理模型。
要保证并发，通常要关注：
- 请求是否有唯一标识，避免响应错配。
- 服务端是否支持并行处理，而不是串行阻塞。
- 工具执行是否有超时、限流和优先级控制。
- 客户端是否能正确管理多请求上下文。
如果底层工具本身很慢，协议再好也救不了，所以并发治理要看“协议层 + 服务层 + 工具层”三层一起设计。
重要度：中频（出现次数：1次） | 难度：较难
**考察点：**高并发调用下的协议和宿主设计能力。
对应章节：20 MCP模型上下文协议 §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 §2、Supervisor 与 Handoff；26 LangGraph多智能体与A2A §3、Skills 与多智能体的边界；27 Agent Skills智能体技能与AI编程工具实践
**来源：**腾讯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)概述；9 LangChain概述与架构 §2、LangChain 定位
Q8-2. 各类 Agent 开发框架应该如何选取？
框架选型不要看热度，要看任务复杂度、团队能力和交付要求。
- 如果目标是快速原型、生态丰富、常见组件齐全，LangChain 很合适。
- 如果任务有显式状态、循环、条件路由、人机协同或多智能体，LangGraph 更合适。
- 如果是低代码、快速验证业务流程，Coze / Dify 更适合。
- 如果系统边界简单、需求非常明确，直接手写 SDK 也可能是成本最低的方案。
更成熟的回答方式，不是简单比较“哪个最好”，而是说明“什么场景下用什么更划算”。能说出替代方案和迁移路径，通常比单纯夸某个框架更有说服力。
常见追问：
- 你最终会用哪些指标判断这次框架选型是不是成功的？
- 如果前期先用平台，后期迁到自研框架，迁移边界应该怎么划？
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**框架选型和工程判断。
对应章节：9 LangChain概述与架构 §2、LangChain 定位；22 LangGraph概述与快速入门 §1、LangGraph 简介
Q8-3. 什么时候工作流比 Agent 更合适？
当业务步骤固定、输出格式明确、希望强可控和易审计时，工作流通常比 Agent 更合适。
比如分类、摘要、内容审核、报告生成、表单填充、固定审批链，这类场景流程路径通常是稳定的。用工作流能更清楚地定义节点职责、失败重试、人工介入点和 SLA。Agent 更适合开放任务和动态决策，而工作流更适合企业里大量“有规则、可追责、可回放”的流程型任务。
常见追问：
- Workflow 中哪些节点适合交给 LLM？
- 人工审核点应该加在哪里？
- 工作流如何逐步升级成 Agentic Workflow？
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**流程治理意识。
对应章节：3 基于Coze&Dify平台的智能体开发 §6、工作流的搭建；21 Agent智能体 §1、Agent 简介
Q8-4. 用 Python 调用 Dify / Coze 工作流时，最值得关注哪些工程细节？
重点需要关注五类问题：鉴权、参数对齐、流式模式、超时限制、日志追踪。
先说 Dify。它的工作流 API 重点字段通常是：
Authorization: Bearer {api_key}- 请求体里的
inputs response_modeuser
这里有两个非常容易踩坑的点：一是 API Key 和工作流是绑定关系，不是拿一个全局 key 到处用；二是长流程尽量用 streaming，因为 blocking 很容易被网关超时打断。真正做流式时，要能识别 SSE 流里的 workflow_finished，并正确拿到最终 outputs。
再说 Coze。它更需要盯紧：
workflow_idapp_idparameters
其中 parameters 必须和工作流里定义的输入变量严格对齐，变量名一旦对不上，代码看起来能跑，请求也可能成功，但业务结果就是不对。流式处理时，则要能区分 PING、MESSAGE、DONE，或者 SDK 里的 MESSAGE / ERROR / INTERRUPT 事件。
如果从工程角度总结，重点需要看这几件事：
- 密钥、工作流、应用的绑定关系是否搞清楚。
- 请求参数名是否和平台工作流输入严格一致。
- 是不是默认用流式，而不是把长任务都压成阻塞式。
- 平台日志、
workflow_run_id、业务request_id是否串起来了。 - 如果流程里有外部副作用，是否做好幂等、重试和失败补偿。
这道题真正考察的，不是“会不会发 POST 请求”，而是是否真正理解过平台 API 的真实调用链。
常见追问：
- 流式和阻塞式返回怎么选？
- 平台日志能解决哪些排障问题？
- 平台工作流和自建后端服务怎么协作？
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**是否看过平台 API 的真实调用链，而不是只会点界面。
对应章节：4 Python调用Dify平台工作流 §4、请求格式；5 Python调用Coze平台工作流 §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 综合案例：智能运维助手；21 Agent智能体 §5、实操与案例
Q9-2. 什么是“幻觉”？应用层应该怎么缓解？
幻觉不只是“完全胡说八道”，更常见的是“看起来很像真的，但细节、引用、时间点、权限范围或者工具结果已经偏了”。
因此，不应把幻觉当成单纯的模型问题，而应把它视为一条链路上的系统问题。比较稳妥的缓解思路通常有四层：
- 知识层：用 RAG、外部检索、引用和无依据拒答，尽量让模型基于证据回答。
- 执行层：把计算、查库、发消息、查订单这类事情交给 Tool，不让模型纯文本瞎编结果。
- 约束层：用结构化输出、schema 校验、关键字段规则校验和低温度策略，减少“格式对了但内容错了”的情况。
- 治理层：做 badcase 回灌、人工抽检、线上监控和降级，别把“模型大概率没问题”当作上线条件。
总结来说：幻觉很难被彻底消灭，工程目标不是“保证永不出错”，而是让它 可发现、可限制、可回滚、可复盘。
常见追问：
- RAG 为什么不能彻底消灭幻觉？
- 什么叫“有引用但依然不忠实”？
- 幻觉和 Prompt Injection 是一回事吗？
重要度：高频（出现次数：2次） | 难度：中等
**考察点：**是否理解“模型能力问题”和“应用链路治理问题”的边界。
对应章节：19 RAG检索增强生成 §1、RAG 简介；14 输出解析器 §4、结构化输出
Q9-3. 多用户场景下，如何为 Agent 做安全沙箱隔离？
如果 Agent 只是单机 Demo，很多风险不会暴露出来；但一旦进入多用户场景，安全隔离就必须从“工具权限”上升到“执行环境隔离”。
一个更稳的方案通常会分三层：
- 环境层：用 Docker 或其他容器把每个任务或租户隔离开，限制 CPU、内存、网络和文件系统访问范围。
- 系统层：配合 seccomp、AppArmor、只读根目录、临时工作目录、非 root 用户运行，避免直接碰宿主机。
- 应用层：对工具、文件访问、系统命令、外部连接做白名单和审计，不让模型拿到裸权限。
如果要执行代码、命令或读文件，通常不会只靠 Prompt 或业务代码做限制，而是会把工作目录挂成最小权限空间，敏感目录不挂载，数据库密钥和主机凭据也不进容器。MCP 或 Tool 负责“能不能调”，沙箱负责“即使调了也跑不出边界”，两者职责不同，最好一起上。
重要度：高频（出现次数：2次） | 难度：较难
**考察点：**多用户 Agent 的安全隔离设计，以及协议层控制和环境层隔离的分工。
对应章节：7 企业级大模型部署 §1、企业级大模型部署概述；17 Tools工具调用 §6、从课程案例走向真实项目
Q9-4. Agent 部署和运维有哪些指标？
Agent 运维至少要看五类指标：
- 效果指标：任务完成率、用户满意度、引用正确率。
- 性能指标：首 token、端到端延迟、P95/P99。
- 稳定性指标：调用成功率、超时率、重试率、失败率。
- 成本指标：token 消耗、工具调用成本、单任务平均成本。
- 治理指标：人工接管率、审计日志完整性、异常任务复盘效率。
如果是多工具、多步骤 Agent，还要看每一步的成功率和卡点分布，否则你只能知道“最终失败了”，却不知道失败发生在哪一层。
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**从 Demo 到生产的运维视角。
对应章节：7 企业级大模型部署 §1、企业级大模型部署概述；21 Agent智能体 §5、实操与案例
Q9-5. RAG 系统在实际部署中可能面临哪些挑战？
RAG 真正上线后，难点通常不在“能不能检索”，而在“这条从索引到回答的完整链路能不能长期稳定运行”。
这里首先要强调的是：RAG 不是单点能力，而是“索引阶段 + 检索与生成阶段”的工程链路。很多线上问题，本质上都是这两阶段里某一层出了问题。
先把挑战拆成六类：
- 数据侧：文档解析质量、切块策略、表格和 PDF 处理、知识更新时效。如果源数据脏、切块不合理，后面检索和生成都会被拖垮。
- 检索侧：Embedding 选型、召回质量、混合检索、重排效果、metadata 过滤。很多系统离线看起来能答，线上一放大就会暴露“召回不准、噪声太多、漏关键片段”的问题。
- 生成侧：上下文组装、引用溯源、忠实度控制、拒答策略。RAG 不是“检索了就不会幻觉”，如果上下文拼接差、Prompt 弱、引用不清，模型照样会编。
- 治理侧：权限隔离、版本管理、引用可追溯、知识回滚。企业里最怕的不是答错，而是答了权限外内容，或者答出来了却说不清依据来自哪里。
- 评测侧：badcase 建设、离线评测和在线指标闭环。没有评测，你很难知道问题到底出在切块、召回、重排还是生成。
- 工程侧：延迟、成本、缓存、可观测性、索引重建和线上运维。比如知识库一更新，是全量重建还是增量更新？查询慢是卡在检索、重排还是模型？这些都得拆开看。
所以面试里更稳的答法不是只说“部署会有很多工程问题”，而是明确讲出：RAG 是一条从数据接入、索引构建、检索召回到生成回答的完整链路，任何一层出问题，最终答案都会出问题。
常见追问：
- 如果 RAG 线上效果不好，你会优先从哪一层开始排查？
- 知识库频繁更新时，你怎么处理索引重建和版本回滚？
重要度：高频（出现次数：1次） | 难度：较难
**考察点：**是否有生产系统思维。
对应章节：19 RAG检索增强生成 §2、RAG 文本处理核心知识；7 企业级大模型部署 §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、从课程案例走向真实项目；19 RAG检索增强生成 §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、大模型的工程实现（概览）；7 企业级大模型部署 §1、企业级大模型部署概述
Q9-11. 模型路由应该怎么做？
模型路由的核心不是“让所有请求自动找最强模型”，而是让不同复杂度、不同风险等级的请求走到最合适的链路。
比较常见的做法有三层：
- 意图路由：先判断这是 FAQ、RAG、工具调用、复杂 Agent，还是应该直接转人工。
- 复杂度路由：简单分类、格式化抽取、轻量总结走小模型；多步规划、开放生成、复杂决策走大模型。
- 成本路由：热点问题先查缓存，能规则化解决的就别进大模型，高价值用户或高风险任务再给更强模型预算。
真正落地时，通常不会把“路由”做成纯主观规则，而会配合评测和线上数据来调：
- 看不同路由分支的完成率、延迟、每任务成本。
- 看是不是某类问题被错误地下沉到了小模型。
- 看路由规则是否需要引入回退机制，比如小模型失败后升级到大模型。
所以模型路由本质上是效果、成本和稳定性之间的平衡器。做得好的系统，不是每次都用最贵的模型，而是能把“该省的地方省掉，该花的地方花对”。
常见追问：
- 什么场景下适合先用规则路由，而不是一开始就做模型路由？
- 小模型路由失败后，怎样设计升级和回退策略？
- 如何避免为了省成本把系统整体效果打穿？
重要度：中频（出现次数：1次） | 难度：较难
**考察点：**成本治理、模型分层和路由策略设计能力。
对应章节：11 Model I/O 与模型接入 §2、LangChain 模型分类、参数与返回；7 企业级大模型部署 §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 企业级大模型部署 §3、模型部署；12 Ollama本地部署与调用 §5、LangChain 整合 Ollama
10、典型业务场景设计题
Q10-1. 如果让你设计一个企业知识库问答系统，你会怎么做？
通常按“数据接入、检索链路、生成链路、治理能力”四层设计。
先把文档接入、解析、切块、向量化和索引更新机制搭好，再设计查询链路，包括 query 改写、混合检索、rerank、权限过滤和上下文组装。生成层要强调“基于证据回答、无依据时拒答、尽量带引用”。治理层则要补上权限、版本、监控、评测和 badcase 回灌。
如果是企业场景，通常还会预留转人工、知识修订、索引回滚和多租户隔离能力，因为这些往往比“第一次答对”更影响长期可用性。
常见追问：
- 如何支持知识更新？
- 如何避免用户问到权限外文档？
- 如果系统答非所问，优先排查哪里？
重要度：必刷（出现次数：1次） | 难度：较难
**考察点：**从需求到架构的完整表达能力。
对应章节：2-RAG 搭建企业私有&个人知识库 §5、使用 Dify 搭建知识库；19 RAG检索增强生成 §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、项目：商户运营管家；21 Agent智能体 §5、实操与案例
Q10-4. 如何设计 Agent 的完成判断与终止条件，避免过早结束？
Agent 的“结束”不能只靠感觉，也不能只靠看日志或一个宽泛的完成率分数。更稳的做法是给它设计显式的完成条件。
终止逻辑通常拆成四层：
- 任务层：是否达成用户目标，是否拿到了必须的产物或字段。
- 工具层：关键工具调用是否成功，返回结果是否满足预期约束。
- 状态层：当前 state 是否进入 done / failed / need_human 这样的终态。
- 保护层：最大步数、超时、重复无进展次数、异常退出条件。
如果链路里有 Supervisor 或监督节点，更适合把它当“辅助审查”和“异常兜底”，而不是唯一的结束依据。真正稳的方案是：只有当关键任务结果、工具返回和状态机条件都满足时，才允许进入最终答复节点。否则宁可继续执行、澄清或转人工，也不要过早把未完成结果返回给用户。
常见追问：
- 只靠监督节点统计完成率和查日志，为什么会慢、还容易误判？
- 有没有更通用的判断方式，比如直接看关键工具调用结果和状态字段？
- 如何避免 Agent 任务还没做完，就提前返回给用户？
重要度：高频（出现次数：1次） | 难度：较难
**考察点：**Agent 终止条件设计、状态机思维，以及 Supervisor / 工具结果 / 状态字段的组合使用能力。
对应章节：24 LangGraphAPI：节点、边与进阶 §2、Graph API 之 Edge；21 Agent智能体 §4、Agent 工作原理（V1.0）
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、从课程案例走向真实项目；21 Agent智能体 §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 综合案例：智能运维助手；21 Agent智能体 §5、实操与案例
Q11-2. 如果面试官问“你们为什么不用某个更热门的框架或模型”，怎么回答更稳？
回答重点不是证明“当前选择永远最对”，而是说明“当前选择和业务约束是匹配的”。
比较完整的回答可以按四层展开：
- 业务复杂度：当前问题到底需要单 Agent、Workflow，还是已经复杂到必须上 LangGraph / 多智能体。
- 工程约束：团队熟悉度、交付周期、可观测性、可维护性、迁移成本。
- 部署条件：是直接用在线模型，还是要接 OpenAI 兼容 API、本地模型、Ollama、Xinference 这类自建推理层。
- 成本与性能：延迟、吞吐、token 成本、模型版本稳定性、是否存在第三方版本漂移风险。
比如没选更重的多智能体框架，可能是因为当前任务用单 Agent 或 Workflow 已经够了；没选更大的模型，可能是因为延迟和成本不划算；没选某个托管平台，可能是因为我们更看重统一 OpenAI-compatible API、模型可控和私有化部署能力。
再往前走一步，还应该顺手体现两点：
- 你知道替代方案，不是没调研过。
- 你给当前方案留了迁移路径，不会把系统锁死。
常见追问：
- 如果未来需求变复杂，迁移路径是什么？
- 你们是如何做技术验证的？
- 如何避免技术选型锁死？
- 如果你的 MCP 是基于 Java 自研的，和成熟 Agent 框架相比，扩展性优势到底体现在哪？
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**技术判断和表达成熟度。
对应章节：9 LangChain概述与架构 §2、LangChain 定位；7 企业级大模型部署 §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次） | 难度：基础
**考察点：**岗位认知是否准确。
更多推荐
8
0- 0
已为社区贡献16条内容
所有评论(0)