今天 09:47 已编辑北京邮电大学 Java 发布于浙江

关注

简历上写了AI项目，怎么才能拉开差距？

大家好，我是马丁。

看到大家都在找实习包装简历，但简历上写了一个RAG/Agent项目，面试官一追问就露馅：这个项目具体解决了什么业务问题？你怎么知道效果好不好？碰到用户单次问答多问题混合处理场景（下面会有示例），你怎么处理？三个问题下来，大部分人就开始打磕巴了。

问题出在哪？不是技术不行，是没有把技术和业务场景绑在一起。面试官见过太多只调了 LangChain4j/SpringAI 的 API、跑通一个 demo 的简历，他想听的是：你为什么这么做，你怎么知道做对了，遇到问题你怎么解决的。

这篇文档每一条都值得你花时间想清楚。想清楚了，面试的时候你讲的就不是背的，而是你自己的东西。

点个关注，持续更新：AI 面试真题拆解 + 企业级 AI 实战场景——面试会问的，工作要用的，一次讲透。

确定业务场景：你的项目到底在给谁用？

很多同学简历上写基于 RAG/Agent 实现智能体系统，面试官第一个问题一定是：什么场景？谁在用？解决什么问题？

如果你回答只是一个通用问答，这条项目基本就废了。

1. 为什么业务场景这么重要？

RAG/Agent 不是一个通用解法，它的每个环节——分块策略、检索方式、Prompt 设计、意图识别、循环问答、上下文记忆——都跟业务场景强相关。同样是智能客服，电商客服和企业 IT 客服的知识库结构、用户问法、回答要求完全不一样。

面试官通过业务场景来判断你是否真正理解了 RAG 的落地细节，而不是只会调 API。

2. 场景怎么定？不要凭空编，去抄真实的

做项目评测的时候，我没有凭空编一个场景，而是花了时间去研究真实的业务体系。以电商客服为例：

调研真实商城：去小米商城、无印良品、网易严选、京东京造等电商平台，把它们的客服系统摸一遍——客服会回答哪些类型的问题？商品文档长什么样？售后政策怎么组织的？FAQ 怎么分类的？
梳理意图体系：基于调研结果，设计一套分层意图分类体系——3 个一级意图（产品咨询、用户反馈、闲聊兜底）、22 个二级意图（选购推荐、参数咨询、对比选购、配件兼容、操作指引、故障排查、退换货、物流配送等）。每个意图都有真实的用户问题示例和难度分级
构建文档体系：参考小米商城真实的文档结构，设计 115 篇知识库文档——商品详情页 50 篇、选购指南 15 篇、使用手册 25 篇、售后政策 15 篇、故障排查 10 篇。文档里刻意埋参数表、对比表、故障树等结构化内容，模拟真实场景的检索难点
设计评估集：基于意图体系，为每个意图设计 5-10 条评估 Query，总共 150 条。每条都标注了难度（简单 / 中等 / 困难）、预期命中文档、标准答案、预埋的难点类型（歧义陷阱、多跳推理、参数计算等）

这里的关键是：你得自己走一遍这个过程。 面试官问你为什么选这个场景，你说跟着教程做的，这就没有说服力了。自己去调研一个真实的业务场景，梳理出属于自己的意图体系和文档体系，面试通过率会高很多。

几个值得参考的方向：

电商客服	商品详情、售后政策、操作手册、故障排查	多商品对比、跨品类组合推荐、故障诊断、退换货政策	结构化表格检索、跨文档多跳推理、动态数据混合
企业 IT 帮助台	内部系统操作手册、故障处理 SOP、权限申请流程	VPN 怎么连、OA 审批流程、系统报错排查	多系统意图路由、版本敏感、权限隔离
法律咨询	法规条文、司法解释、案例摘要	合同纠纷怎么处理、这种情况违法吗、诉讼时效多久	条款精确匹配、时效性判断、多法规交叉引用
金融理财	产品说明书、风险提示、监管文件	这个基金风险等级多少、手续费怎么算、能不能赎回	数值精度、合规约束、实时数据依赖

关键是你能回答这三个问题：

用户是谁？ 不是所有人，而是具体的角色——电商买家、企业员工、法务人员
他们会问什么？ 不是各种问题，而是你能列出 10-20 个典型问题，并且知道每个问题对应什么类型的知识
回答错了会怎样？ 电商场景回答错参数，用户买错商品要退货；法律场景引用错条款，后果更严重。这个决定了你对幻觉抑制的要求有多高

Agentic RAG：从查资料到帮用户解决问题

这是面试中最能拉开差距的部分。

很多人讲 RAG 只讲检索 + 生成——用户问一个问题，去向量数据库里查几个 chunk，喂给大模型生成答案。这是最基础的 Naive RAG，面试官听得太多了，没有区分度。

真实业务场景里，用户的问题远不是一次检索就能解决的。

1. 什么是 Agentic RAG？

一句话概括：让 RAG 系统具备规划、决策和行动能力，不只是查资料，而是像一个有经验的客服一样帮用户解决问题。

传统 RAG 的链路是线性的：Query → 检索 → 生成。Agentic RAG 的链路是动态的：系统会根据用户问题自主判断应该检索知识库、调用业务系统、还是两者结合，甚至在一次问答中执行多个步骤。

用电商客服场景来看这个差别：

扫地机 T20 的吸力多大？	检索商品详情页，返回参数 ✅	同左（简单问题不需要 Agent）
扫地机 T20 和 T20 Pro 选哪个？	检索两个商品的 chunk，可能拼不全 ⚠️	识别为对比意图，并行检索两个商品参数，结构化对比后生成推荐 ✅
我家 120 平有猫有小孩，预算 5000，配一套扫拖方案	检索到一堆不相关的 chunk ❌	拆解约束（面积→吸力需求、宠物→防缠绕、小孩→安全锁、预算→价格筛选），多轮检索 + 调用价格接口，组合推荐 ✅
我上周买的那个净化器滤芯该换了，同款多少钱？有券能用吗？	不知道用户买了什么 ❌	查会话记忆确认商品 → 检索配件兼容文档 → 调用价格接口查实时价 → 调用优惠券接口查可用券 ✅
扫地机充不进电了怎么办？	检索到故障排查文档，一次性甩一大段 ⚠️	走故障诊断树：先问指示灯状态 → 根据回答定位原因 → 给出针对性解决方案 → 解决不了转人工 ✅

2. Agentic RAG 的核心能力

Agentic RAG 和 Naive RAG 的本质区别不是多了几个模块，而是系统的控制权从硬编码的流水线交给了 LLM 自身。LLM 不再只是链路末端的生成器，而是整个流程的决策者——它来判断该做什么、怎么做、做得对不对。

2.1 推理与行动交替（ReAct）

ReAct 是 Agentic RAG 最核心的模式。LLM 不是一次性跑完整条链路，而是在一个思考 → 行动 → 观察的循环中逐步推进：

以电商场景为例，用户问我上周买的净化器滤芯该换了，同款滤芯现在多少钱，有券能用不：

[思考] 用户提到"上周买的"，需要先确认是哪款净化器。查会话记忆。
[行动] 调用 memory_lookup → 返回：用户上周咨询并购买了净化器 P5
[观察] 确认商品为净化器 P5

[思考] 需要查 P5 的兼容滤芯型号。这是静态知识，走知识库检索。
[行动] 检索知识库，query="净化器 P5 兼容滤芯" → 返回：兼容滤芯型号 FH-05、FH-05 Pro
[观察] 得到两个兼容型号

[思考] 用户问"多少钱"和"有没有券"，这是实时数据，需要调业务接口。
[行动] 并行调用 price_query(FH-05, FH-05 Pro) + coupon_query(用户ID)
[观察] FH-05 价格 129 元，FH-05 Pro 价格 199 元；用户有一张满 150 减 20 的券

[思考] 信息收集完毕，可以生成回答了。FH-05 Pro 用券后 179 元，性价比更高。
[行动] 生成最终回答

关键点在于：每一步做什么不是预先写死的，而是 LLM 根据上一步的结果动态决定的。如果会话记忆里没有购买记录，Agent 会改为反问用户确认型号，而不是继续往下走然后报错。

2.2 任务规划与分解（Plan-and-Execute）

ReAct 解决的是一步步往前推的问题。但有些问题更复杂——Agent 需要先退一步想清楚整体方案，再分步执行。每一步执行完还可能修正后续计划。

用户问我家 120 平，有两只猫，客厅铺了地毯，预算 5000，帮我配一套清洁方案：

Agent 的规划过程：

分析约束条件：120 平（大户型）、养猫（毛发多）、地毯（需要强吸力）、预算 5000
确定需要的信息：①适合大户型养宠的扫地机型号 ②地毯清洁能力对比 ③配件兼容性 ④当前价格和优惠
规划执行步骤：先查知识库筛选候选机型 → 再针对候选机型查详细参数 → 调价格接口确认预算可行性 → 综合推荐

这跟 Naive RAG 一把梭检索的区别在于：Agent 知道一次检索解决不了这个问题，需要分多步、有策略地收集信息。

2.3 工具编排与 MCP 协议

光会推理和规划还不够，Agent 还得能干活。干活靠的是工具——而且不只是会调一个工具，是能根据任务需要动态选择和组合多个工具。工具之间可能有依赖关系（先查订单号才能查物流），也可能可以并行（价格查询和库存查询互不依赖）。

在电商场景中，常见的工具包括：

`price_query`	商品 ID	实时价格、促销信息	用户问价格、问划不划算
`inventory_check`	商品 ID + SKU	库存状态、预计到货	用户问有没有货、什么时候发
`order_lookup`	用户 ID / 订单号	订单详情、物流状态	用户问订单到哪了、什么时候到
`coupon_query`	用户 ID	可用优惠券列表	用户问有没有优惠
`compare_products`	商品 ID 列表	结构化参数对比表	用户做对比选购
`warranty_claim`	商品 ID + 故障描述	保修状态、维修方案	用户报修

工具的注册和调用走 MCP 协议（Model Context Protocol），每个工具声明自己的名称、描述、参数 Schema。Agent 根据工具描述判断该调哪个，从用户问题中提取参数，发起调用。新增一个工具只需要实现执行器接口并注册，不用改主链路代码。

2.4 技能封装（Skill）

工具是原子操作——查一个价格、查一个库存。但真实场景里，用户的一个问题往往需要好几个工具和检索配合才能搞定。每次都让 Agent 从零开始编排，效率低，还容易出错。

Skill 就是把常见的多步操作打包成一个可复用的能力单元。对 Agent 来说，调一个 Skill 和调一个 Tool 没区别，但 Skill 内部封装了完整的编排逻辑。

还是用电商场景来看：

商品对比	并行检索两个商品的知识库详情 + 调价格接口 + 按对比模板结构化输出	T20 和 X20 Pro 选哪个
选购推荐	分析用户约束 → 知识库筛选候选 → 查价格确认预算 → 组合推荐	预算 5000 配一套清洁方案
故障诊断	检索故障树 → 引导式多轮追问 → 定位原因 → 给方案或转人工	扫地机充不进电
配件查询	查会话记忆确认主机型号 → 检索兼容配件 → 查配件价格和库存	滤芯该换了，同款多少钱

打个比方：Tool 是螺丝刀、扳手这些单个工具，Skill 是换轮胎这个完整操作——换轮胎的人知道先松螺丝、再上千斤顶、再拆旧装新，不用每次都从头想步骤。

工程上，Skill 可以用配置化的方式管理——每个 Skill 定义自己需要哪些 Tool、走什么检索策略、用什么 Prompt 模板。新增业务场景时，写一个新 Skill 就行，Agent 的核心推理逻辑不用动。

2.5 自我反思与纠偏（Self-Reflection）

还有一个能力容易被忽略——但面试的时候提到这个，绝对加分。Agent 不是执行完就直接输出，而是会检查自己的中间结果：

检索质量检查：检索回来的 chunk 和用户问题相关度低于阈值？Agent 会换个 query 重新检索，而不是硬着头皮生成一个低质量答案
答案完整性检查：用户问了三个子问题，生成的答案只覆盖了两个？Agent 会补充检索遗漏的部分
工具结果校验：价格接口返回异常值（比如 0 元）？Agent 不会傻乎乎地写进答案，而是降级为建议用户到商品页查看最新价格
幻觉自查：生成的答案中包含检索上下文里没有的参数数据？触发兜底机制，明确告知用户该信息暂未在知识库中找到

这种自我纠偏能力，是 Agentic RAG 和固定流水线的根本区别。固定流水线里，检索差了只能认栽；Agent 会想办法自救。

3. 用一个完整的电商场景串一遍

用户输入：我家 120 平，有两只猫，客厅铺了地毯，想买个扫地机器人。T20 和 X20 Pro 哪个合适？现在哪个更划算？

Agent 的 ReAct 执行过程：

[思考] 这是一个复杂的选购决策问题，包含三个维度：
  1. 场景适配：120 平 + 养猫 + 地毯 → 需要查适用场景和清洁能力
  2. 产品对比：T20 vs X20 Pro 的核心参数差异
  3. 价格对比：当前售价和优惠活动 → 需要调价格接口
  先查知识库解决 1 和 2，同时查价格接口解决 3。

[行动] 并行执行：
  - 检索知识库 query₁="养宠家庭大户型扫地机选购"
  - 检索知识库 query₂="T20 和 X20 Pro 参数对比"
  - 调用 price_query(T20) + price_query(X20 Pro) + coupon_query(用户ID)

[观察] 知识库返回：
  - T20：5000Pa 吸力，胶刷+毛刷双主刷，支持地毯增压模式，续航 180 分钟
  - X20 Pro：8000Pa 吸力，零缠绕胶刷，智能地毯识别自动增压，续航 260 分钟，自动集尘
  - 选购指南：养宠家庭建议 6000Pa 以上 + 防缠绕主刷 + 自动集尘
  价格接口返回：T20 当前价 2499 元，X20 Pro 当前价 3999 元 + 618 满减 300 元

[思考] 信息够了，但需要做一个判断：
  - T20 的 5000Pa 低于选购指南建议的 6000Pa，且胶刷+毛刷对猫毛容易缠绕
  - X20 Pro 在三个关键指标（吸力、防缠绕、自动集尘）上都更匹配养宠场景
  - 价格差：3699（优惠后）- 2499 = 1200 元
  需要如实呈现对比，给出倾向性建议但不替用户做决定。

[行动] 生成最终回答

最终输出给用户的是一份结构化推荐：先对比两款在养宠场景下的核心差异（吸力、防缠绕、自动集尘），再结合 120 平 + 地毯的需求给出倾向性建议，最后标注实时价格和优惠信息。

注意这个过程和固定流水线的区别：

固定流水线会把所有子问题拆好、分配好路径、执行完拼在一起——像流水线工人
Agent 会推理（养猫需要防缠绕和大吸力）、判断（T20 的 5000Pa 低于建议值）、决策（给出倾向性建议）——像一个有经验的销售顾问

再看一个体现自我反思的场景。用户问扫地机充不进电了怎么办：

[思考] 这是故障排查类问题，需要走诊断流程而不是一次性甩一大段排查手册。
[行动] 检索知识库 query="扫地机充电故障排查"
[观察] 返回故障诊断树：先检查充电座指示灯 → 白色常亮/不亮/红色闪烁分别对应不同原因
[思考] 不能直接把整棵诊断树甩给用户，需要引导式问答。先问指示灯状态。
[行动] 生成引导回复："请先看一下充电座的指示灯是什么状态？白色常亮、不亮、还是红色闪烁？"

（用户回复：红色闪烁）

[思考] 红色闪烁对应"充电座与机器人触点接触不良"。查知识库确认解决方案。
[行动] 检索知识库 query="扫地机充电座红色闪烁 触点清洁"
[观察] 返回：① 清洁充电触点 ② 检查充电座放置是否平稳 ③ 重启机器人
[思考] 给出具体步骤，如果都不行需要引导转售后。
[行动] 生成分步解决方案 + 兜底提示"如以上步骤无法解决，建议联系售后"

这里 Agent 做了两件 Naive RAG 做不到的事：引导式多轮问答（不是一次性甩答案，而是逐步缩小范围）和兜底决策（判断自己解决不了时主动建议转人工）。

4. 面试怎么讲 Agentic RAG？

面试官问 Agentic RAG，本质上是在考察你对 AI Agent 范式的理解深度。不要只描述项目的执行链路，要能从概念层讲清楚。

4.1 先把核心区别说透

Naive RAG 是一条固定流水线：Query 进来，检索，生成，结束。不管问题简单还是复杂，都走同一条路。Agentic RAG 的核心区别是把 LLM 放到了决策位——它自己判断该检索还是调工具、该一步到位还是分步推进、中间结果够不够好要不要重试。用学术一点的说法，这叫 ReAct 模式——Reasoning and Acting 交替进行。

基础区别一定要能讲清楚，最好能够配上示例问题，以及系统背后的处理机制，结合真实场景回答，面试官就知道你不是在背概念。

4.2 然后用设计模式撑起深度

ReAct	思考→行动→观察，循环推进	故障诊断：先问症状、再定位原因、逐步排查
Plan-and-Execute	先规划步骤，再逐步执行	全屋清洁方案：先分析约束、筛选候选、查价格、组合推荐
Tool Use	动态选择和调用外部工具	查实时价格、查库存、查订单物流、查优惠券
Self-Reflection	检查中间结果，质量不够就重试	检索结果不相关时换 query 重新检索，而不是硬生成
Multi-Step	一个问题需要多次检索/调用才能回答	配件兼容：先确认用户的主机型号 → 再查兼容配件列表 → 再查配件价格

面试的时候不用每个都讲，挑两三个你最熟的展开，配上具体场景说清楚就够了。

4.3 最后落到工程实现上

概念讲完，面试官大概率会追一句：那你代码里具体怎么做的？这时候你得能接住：

意图识别怎么做的？ → 混合方案：规则层快速过滤（关键词 + 正则）+ LLM 分类兜底。LLM 输出 JSON 带置信度分数，低置信度走歧义引导让用户澄清
ReAct 循环怎么控制不死循环？ → 设置最大推理步数（比如 5 步），超过就强制生成当前最优答案 + 兜底提示
工具调用用什么协议？ → MCP 协议，标准化工具注册和调用。每个工具声明参数 Schema，Agent 根据描述判断该调哪个，LLM 从用户问题中提取参数
KB 和 Tool 结果怎么合并？ → Prompt 里分区标注来源（相关文档 vs 相关数据），让模型能区分静态知识和实时数据。System Prompt 里写明：知识库内容不可编造，工具返回的数据可以做计算推理
工具调用失败怎么办？ → 降级策略：工具超时或返回异常时，Agent 不阻断主流程，降级为纯 KB 回答 + 提示用户实时数据暂时获取失败

评测体系：你怎么知道系统效果好不好？

效果还不错，这是面试中最没用的一句话。

面试官想听的是：你用什么指标衡量？测了多少条数据？基线是多少？优化之后提升了多少？

1. 分层评测的思路

Agentic RAG 系统的评测比 Naive RAG 复杂得多。Naive RAG 只需要测检索和生成两层，但 Agent 系统多了意图决策、工具调用、多步推理这些环节，每一层都可能出错，错误还会级联放大。所以评测必须分层做，定位问题才有方向。

1.1 意图识别与路由决策

指标：Top-1 准确率
为什么重要：意图是整条链路的闸门。意图错了，后面全错——该走工具调用的走了知识库检索，该查售后政策的查成了选购推荐
特别注意：Agentic 系统里意图识别还要测路径决策的正确性——该调工具的有没有调（漏调），不该调工具的有没有乱调（误调）。比如用户问扫地机吸力多大不需要调价格接口，但用户问这款现在多少钱必须调
参考目标：>= 90%

1.2 检索质量

自建指标：Hit@5（Top-5 结果中是否命中了相关文档）、Recall@K（找回了多少相关文档）、MRR（第一个相关文档排多靠前）
RAGAS 指标：context_precision（召回结果里有多少是有用的）、context_recall（标准答案需要的信息是否都被召回了）
为什么要两套：自建指标是纯集合运算，秒出结果，适合每次提交都跑；RAGAS 指标是 LLM-as-Judge，更贴近语义但有成本和方差
参考目标：Hit@5 >= 90%，context_recall >= 0.80

1.3 工具调用质量

这一块是 Agentic RAG 特有的，Naive RAG 完全不涉及：

工具决策准确率	该调工具时调了，不该调时没调	问参数不应该调价格接口，问价格必须调
工具选择准确率	调了正确的工具	查价格调 `price_query` ，不能调成 `inventory_check`
参数提取准确率	从用户问题中提取出正确的工具参数	T20 多少钱 → 提取商品 ID 为 T20，不能提成 T20 Pro
工具结果利用率	工具返回的数据有没有被正确用到答案里	价格接口返回 2499 元，答案里写的也是 2499 元，不能写成别的数

评估集里需要专门标注每条 Query 是否应该触发工具调用、该调哪个工具、参数是什么。运行时记录实际的工具调用轨迹（工具名 + 参数 + 返回值），和真值做比对。

1.4 生成质量

核心指标：faithfulness（回答是否忠实于召回内容，即幻觉检测）、answer_relevancy（回答是否切题）、answer_correctness（回答与标准答案的一致性）
参考目标：faithfulness >= 0.90，answer_correctness >= 0.80
Agent 场景的额外关注：混合回答中，知识库来源的内容不能和工具返回的实时数据矛盾。比如知识库里写的标价是 3999 元（可能过时了），价格接口返回的当前价是 3699 元（有活动），答案应该用实时数据

1.5 Agent 行为质量

前面几层测的都是单个环节，这一层看的是 Agent 作为一个整体，行为合不合理：

多步任务完成率：用户的复合问题（比如 T20 和 X20 Pro 对比一下，哪个更划算，同时包含参数对比和价格查询）是否所有子任务都完成了，有没有漏掉某个维度
自我纠偏成功率：检索结果质量差时，Agent 有没有换 query 重试？重试后效果有没有改善？
引导澄清合理性：问题模糊时（比如推荐个手机，没有任何约束条件），Agent 有没有反问澄清而不是瞎猜？反问的质量如何？
兜底 / 转人工决策：确实解决不了的问题，Agent 有没有及时识别并建议转人工，而不是硬编一个答案？

1.6 业务红线与性能

误拒率：应该回答的问题，系统拒答了
错答率：应该拒答的问题（比如竞品问题、越界问题），系统乱答了
安全红线：有没有泄露系统 Prompt、内部工具名、其他用户数据
P95 延迟：Agent 的多步推理比 Naive RAG 慢，延迟预算怎么分配？单步检索 / 工具调用的超时阈值设多少？
Token 消耗：ReAct 循环的每一步都消耗 Token，复杂问题的总消耗是多少？有没有超出成本预算？

2. 评估集怎么建？

评估集不是随便写几个问题就行。一份能覆盖 Agentic RAG 的评估集需要：

覆盖所有意图类型和路径组合：纯 KB 查询、纯 Tool 调用、KB + Tool 混合、应拒答、应引导澄清——每种路径都要有样本
难度分级：简单（单参数查询）、中等（多条件约束、单次工具调用）、困难（多跳推理、多工具编排、歧义消解）
标注完整：每条数据需要标注——期望命中文档 ID、标准答案、意图标签、是否需要工具调用、调哪个工具和参数、是否应拒答
口语化：模拟真实用户输入，含错别字、省略、口语表达。比如那个扫地的充不进去电了咋办，比扫地机器人无法充电的解决方案更接近真实场景
规模合理：起步 50-100 条覆盖核心场景；完善到 150-200 条，支持分层统计。其中建议 30% 以上涉及工具调用或混合场景，不能全是纯检索的简单题

3. 面试怎么讲评测？

不要只说做了评测，要讲清楚三件事：

你评了什么：150 条评估集，覆盖 22 个意图，按难度三档分布，其中纯 KB 查询占 50%、纯 Tool 调用占 20%、KB + Tool 混合占 20%、拒答 / 引导占 10%
结果怎么样：给出具体数字，比如意图准确率 95%，Hit@5 达到 92%，工具决策准确率 91%，faithfulness 达到 0.93
基于评测结果做了什么优化：比如发现工具参数提取准确率只有 82%，排查后发现是参数提取 Prompt 对商品别名覆盖不够（用户说 T20，但工具需要完整商品 ID），增加了术语归一化映射后提升到 94%；再比如发现混合场景的 faithfulness 低于纯 KB 场景，是因为模型混淆了知识库旧价格和接口实时价格，在 Prompt 里加了来源标注后解决

部分效果如下所示：

生产级工程能力：demo 和真实系统的差距在哪？

面试官区分候选人水平的核心问题：你做的是 demo 还是生产系统？

demo 能跑通 happy path 就行，生产系统要扛住异常、撑住并发、追踪得了问题、管理得了 Prompt。

1. AI 基础设施层：模型调不通，一切白搭

1.1 模型路由与多级 Fallback

生产环境不能只依赖一个模型供应商。按优先级配置多个候选（比如阿里百炼 → SiliconFlow → 本地 Ollama），主模型超时或报错时自动切到下一个。

1.2 三态熔断器

不是每次失败都要重试。CLOSED（正常）→ 连续失败超阈值 → OPEN（直接跳过，不再浪费请求）→ 冷却期到 → HALF_OPEN（放一个探测请求）→ 成功则回 CLOSED，失败则重回 OPEN。这比 Hystrix / Sentinel 更适合大模型场景，因为大模型 API 的恢复时间通常是分钟级而不是秒级。

1.3 流式首包探测

流式调用不能等完整响应才判断成功失败——连接建立了但迟迟没内容，也算失败。拦截首包（第一个 token），首包到了才算成功；超时就取消连接切下一个模型。首包前的内容缓冲在 buffer 里，确认成功后批量回放给下游。这是流式场景特有的容错设计，面试很爱问。

1.4 Embedding / Rerank 同理

Embedding 模型和 Rerank 模型也需要路由和 Fallback，不只是 Chat 模型。很多人只对生成模型做了容错，检索链路上的模型挂了整个系统照样不可用。

2. 数据管道层：知识库不是上传就完了

2.1 文档入库流水线

从文档上传到可检索，要经过一条完整的 Pipeline：抓取（支持本地文件 / S3 / HTTP / 飞书文档等多种来源）→ 解析（PDF / DOCX / PPT / HTML，Apache Tika）→ 分块（递归分块 / 语义分块，不同文档类型不同策略）→ 向量化（调 Embedding 模型）→ 入库（写入向量数据库）。

每个节点可以单独配置、单独失败、单独重试。某个文档解析失败不应该阻断整批任务。节点执行结果（耗时、输入输出、成功 / 失败）都要记录日志，方便排查。

2.2 分块策略的选型

面试官经常问你怎么分块的。答固定 512 token 是最差的回答。好的回答是：根据文档类型选择不同策略——商品详情页按段落结构分块（保留参数表完整性），售后政策按条款分块（每条政策独立），FAQ 按问答对分块。分块粒度直接影响检索效果，需要结合评测结果反复调。

2.3 定时同步与增量更新

知识库不是导入一次就完了。商品上下架、政策修改、文档更新——都需要定时同步或事件触发更新。更新时要做到：旧 chunk 删除 + 新 chunk 入库是原子操作，中间状态不能被用户查到。

3. Agent 运行时层：让 Agent 跑得稳

3.1 多路检索引擎

多个检索通道并行执行（意图定向检索精度高 + 向量全局检索召回广），结果经后处理器链（去重 → Rerank 精排），处理器解耦，某个失败不中断整条链。topK 不是全局固定值，意图节点上可以按场景配置不同的 topK。

3.2 会话记忆管理

多轮对话的记忆不是简单地把历史消息全塞进去。Token 会膨胀，成本会爆炸，还会把有用的检索上下文挤出窗口。

推荐混合策略：最近几轮完整保留，超过阈值触发 LLM 摘要压缩，把早期对话压缩成一条摘要消息。检索用改写后的问题（语义更精准），记忆里存的是用户原始输入（保留真实上下文）。摘要压缩异步执行，提交到专用线程池不阻塞主流程。

3.3 Prompt 模板管理

生产系统的 Prompt 不能写死在代码里。用模板引擎（StringTemplate / Mustache / 自研）管理，支持：

多场景模板：知识库问答、工具调用、混合回答、引导澄清各一套
占位符动态填充：检索上下文、工具结果、用户问题、历史摘要，分区域注入
版本管理：每次 Prompt 调整都有记录，效果回退时能快速定位是哪次改动引入的

3.4 Agent 循环控制

ReAct 循环必须有兜底机制：

最大步数上限（比如 5 步），超过强制基于已有信息生成最优答案
单步超时控制，检索 / 工具调用超时触发降级
Token 预算控制，多步推理的累计消耗不能超过上限
重复行为检测，如果 Agent 连续两步执行了相同的检索 query，强制跳出循环

4. 并发与限流层：扛住流量

4.1 分布式排队限流

大模型 API 的并发能力有限，不做限流系统会被打崩。基于 Redis 实现跨实例排队：Semaphore 控制全局并发上限，ZSET 维护 FIFO 等待队列，Lua 脚本保证出队的原子性，Pub/Sub 通知等待者。排队超时的请求要优雅拒绝，不能让用户一直转圈。

4.2 Token 成本控制

Agent 系统的 Token 消耗比 Naive RAG 高得多——每一步 ReAct 推理、每次 LLM 意图分类、每次参数提取都在烧 Token。需要：

区分场景用不同级别的模型（意图分类用小模型，最终生成用大模型）
简单问题快速短路（一步检索就能解决的不走 Agent 循环）
监控每个请求的 Token 消耗，设报警阈值

5. 可观测性层：出了问题能定位

5.1 全链路追踪

一个请求跨越多个线程池（工具调用、检索通道并行、意图分类、记忆摘要等），上下文靠 TTL（TransmittableThreadLocal）跨线程透传。关键方法上打 AOP 注解，自动记录调用栈和每个环节的耗时。管理后台能看到完整链路，一眼定位哪个环节慢了。

5.2 Agent 决策日志

ReAct 的每一步推理——思考了什么、选了什么行动、观察到什么结果——都要落日志。这不只是调试用的，更是评测和优化的数据源。出了 bad case，从日志里能回溯 Agent 在哪一步走偏了。

5.3 关键指标监控

生产系统至少要看这些指标：

请求量 / 成功率 / P95 延迟（基础）
意图分布（哪类问题最多，是不是和预期一致）
工具调用成功率（哪个工具经常超时或报错）
平均 ReAct 步数（是否有大量请求跑满最大步数——可能是 Prompt 设计有问题）
Token 消耗分布（成本是否可控）
用户重新提问率（侧面反映答案质量）

给自己叠个甲，上面内容只是部分企业级的特点，其实还有不少，不过更多的是个性化需求场景，就不再一一赘述了。

面试怎么讲这个项目？

1. 一分钟项目介绍模板

我做了一个企业级 Agentic RAG 智能问答系统，业务场景是 XXX（电商客服 / 企业帮助台 / ...）。和普通 RAG 不同的是，系统采用 ReAct 模式，LLM 自主决定每一步该检索知识库还是调用业务接口，支持多步推理和自我纠偏。核心技术包括意图识别与动态路由、多路检索引擎、MCP 工具编排、模型路由与三态熔断、分布式排队限流。

在评测方面，我基于真实业务场景构建了 150 条评估集，覆盖 22 个意图类型，分层评测意图准确率、检索命中率、工具调用准确率和生成忠实度。用自建指标 + RAGAS 框架，检索 Hit@5 达到 XX%，工具决策准确率 XX%，生成 faithfulness 达到 XX。

技术栈是 Java 17 + Spring Boot 3 + PostgreSQL / Milvus + React 18，后端约 4 万行代码。

2. 高频追问及应对

2.1 RAG 的检索效果不好怎么优化？

先定位问题在哪一层。用评估集跑一遍，看 Hit@5 和 context_recall。如果 Hit@5 就低，说明向量检索本身没找对，可能是分块粒度不对、Embedding 模型不适合当前领域。

如果 Hit@5 还行但 context_recall 低，说明找到了文档但具体 chunk 不对，需要调分块策略或加 Rerank。如果检索指标都还行但 answer_correctness 低，那就是生成阶段的问题，检查 Prompt 约束是否到位。

另外在 Agent 架构里，如果 Agent 有自我纠偏能力，检索差的时候会换 query 重试——但这不意味着可以放松对首次检索质量的要求，因为每多一步 ReAct 循环都在加延迟和烧 Token。

2.2 怎么解决幻觉问题？

多层防线。Prompt 层面：限定知识来源，比如只基于以下参考资料回答；加兜底指令，比如信息不足时明确告知；要求引用标注、降低 Temperature 到 0.1。检索层面：设置相似度阈值，低于阈值的 chunk 不喂给模型。Agent 层面：生成后做自查——答案中的关键数据（参数、价格）是否都能在上下文中找到出处，找不到就触发兜底。评测层面：用 RAGAS 的 faithfulness 指标持续监控，低于 0.90 就触发 Prompt 优化。

2.3 你这个和用 LangChain / Dify 搭的有什么区别？

LangChain 是一个通用框架，帮你快速跑通 demo。但在生产环境，你需要的是对每个环节的精确控制——模型熔断怎么做、限流队列怎么设计、检索通道怎么并行、上下文怎么跨线程透传、Agent 循环怎么控制不死循环。这些通用框架要么不提供要么提供的方案不适合你的场景。我们的设计是手写核心链路、在关键扩展点用策略模式，新增一个检索通道、后处理器或 MCP 工具只需要实现接口注册为 Spring Bean，比框架绑定更灵活。

2.4 Agentic RAG 和普通 RAG 的核心区别是什么？

本质区别是控制权在谁手里。普通 RAG 是开发者写死的流水线——不管用户问什么，都走同一条路径。Agentic RAG 是 LLM 自己做决策：该检索还是调工具？检索结果够不够好要不要重试？用户问了三个子问题是否都覆盖到了？这种 ReAct 循环（思考→行动→观察→再思考）让系统能处理开放式的复杂问题，而不只是回答知识库能直接命中的简单查询。

Agentic RAG 并不是银弹，其中一个问题就是执行时间慢，相对于普通 RAG WorkFlow 形式，至少慢3-5倍以上。

2.5 ReAct 循环怎么防止死循环或性能爆炸？

两个机制。第一是最大推理步数上限（比如 5 步），超过就强制基于当前已有信息生成最优答案，附带兜底提示。第二是每一步的行动都有超时控制——检索超时、工具调用超时都会触发降级，不会让整条链路卡死。另外还有重复行为检测，Agent 连续执行相同检索时强制跳出。实际跑下来，80% 以上的问题在 2-3 步内就能解决。

2.6 会话记忆怎么处理的？

混合策略。最近几轮对话完整保留，超过阈值触发 LLM 摘要压缩。检索用改写后的问题，记忆里存用户原始输入。摘要压缩异步执行，不阻塞主流程。Agent 场景要特别注意：ReAct 循环的中间推理过程（思考 / 行动 / 观察）不存进会话记忆，只存最终的用户输入和系统回复，否则记忆会膨胀得非常快。

最容易踩的坑

1. 只讲技术栈，不讲业务决策

我用了 Milvus 做向量检索，用了 HNSW 索引——这是技术细节，不是项目亮点。面试官想听的是：电商场景下用户经常问参数对比，纯向量检索对结构化表格数据效果差，所以我们设计了意图定向检索通道，针对对比类问题直接定位到参数表所在的 chunk。技术选型要和业务场景绑在一起讲。

2. 说不出具体数字

效果还不错、提升了很多——这些都是废话。你需要准备的是：评估集多少条、Hit@5 多少、faithfulness 多少、工具调用准确率多少、优化前后的对比数据。没有数字，面试官会认为你没有真正做过评测。

3. 把框架当成自己的能力

我用了 Spring AI 的 RAG 框架——用框架不是问题，但你得说清楚框架帮你做了什么、你自己做了什么。检索通道的策略设计是你的，Agent 推理循环的控制逻辑是你的，Prompt 模板的迭代优化是你的，评测体系是你搭的。

4. 不了解自己项目的代码

面试官可能会深入追问某个模块的实现细节。比如问你熔断器的状态转换具体怎么做的，你至少要能说出三态转换的条件和线程安全怎么保证的。建议面试前挑 2-3 个你最熟的模块，Debug 一遍关键链路，确保能讲清楚。

5. 讲 Agent 只停留在概念

我们用了 ReAct 架构——然后呢？面试官会追问：你的 Agent 在一次真实请求里具体做了几步推理？每一步是怎么决策的？你要能拿出一个复杂问题，用思考→行动→观察的格式一步步还原 Agent 的推理过程。拿不出来，面试官就会认为你只是在背论文。

6. 忽略成本和延迟

Agent 系统比 Naive RAG 贵得多也慢得多——每步 ReAct 都在烧 Token 和加延迟。面试官问你的系统 P95 延迟多少，单次请求平均消耗多少 Token，如果你答不上来，说明你没有在生产环境下认真跑过。要准备的数据：简单问题平均几步完成、复杂问题平均几步完成、单次请求的 Token 消耗范围、P95 延迟。