面经复盘：AI 应用 / Agent 后端岗面试，RAG、工具调用、评测、成本与落地的追问链

先把话说在前面：本文根据公开面经整理与改编，不是我本人亲历的某一场面试。我是做了 8 年 Java 后端、后来在业务里落地过 LLM 应用的人，最近看 AI 应用 / Agent 岗位的面经，最大的感受是一句话：这类岗位的面试，正在从“你会不会调 API”变成“你能不能把一个不确定的东西做成可上线的系统”。所以本文的点评部分，我是按“中高级后端转 AI 应用”的口径来写的：初级会答“是什么”，中高级要答“怎么选、怎么测、怎么兜底、怎么算账”。

下文出现的“某一线互联网公司”“某 SaaS 厂商”都是泛指。题目和追问来自我实际打开阅读的几份公开资料：卡码笔记的大模型 / Agent 面经汇总、小林 coding 的 AI 大模型面试题集、GitHub 上的 AI 面试指南和 AgentGuide 的 RAG 题库，以及牛客 Java 面经合集里几家涉及 RAG 与 Agent 的面经；技术事实部分我对照了 Anthropic 的《Building effective agents》和 MCP 官方规范。参考资料在文末逐条说明。

一、这类岗位面试是什么形态

从公开面经看，岗位名字五花八门：AI 应用开发、Agent 开发、大模型应用后端、RAG 工程师、FDE（前置部署工程师）。共同点是：模型不是你训练的，你负责围绕模型搭系统——知识检索、工具调用、状态与记忆、评测、成本、安全、上线。卡码笔记那份汇总的说法是：应用开发岗位重点在 RAG 和 Agent 工程，算法岗位才偏 Transformer 原理与微调；小林 coding 的题集则按 Agent（16 题）、RAG（20 题）、工具调用（16 题）、大模型工程（22 题）四个专题组织，并强调“考的是工程思维，而非背诵”。GitHub 上那份 AI 面试指南的思路也类似：不只问“是什么”，更问“为什么选它、怎么验证、备选方案在质量、延迟、成本、复杂度上的差异”。

牛客合集里我看到的几条短面经也印证了这一点：有一场后端面试只有 20 分钟，问的是RAG 知识库的业务场景、Milvus 向量库怎么选型、Agent 里用户意图怎么识别，再回到 CAS、线程池、B+ 树、慢 SQL 这些传统后端追问；另一场实习面试则问到 Agent Skill 怎么构建、大模型幻觉的原理。也就是说，AI 题只是新增的一块，传统后端功底没有被免除。下面这张图是我整理的典型流程。

二、第一轮：后端基础 + “你项目里的 AI 到底是怎么做的”

考察目标：确认你是合格的后端，同时判断 AI 项目是不是“套壳 demo”。JavaGuide 的项目指南里也特别提到，简历上写了 AI Agent 项目，面试官会要求你解释 Agent 的工作流程与失败恢复。所以第一轮的很多追问，是从项目切入的。

面试官问：介绍一下你做的 AI 项目，你负责哪一块？

参考回答要点：用 30 秒讲“业务问题 → 方案 → 你的职责 → 结果”，然后主动给出可追问的钩子：“我们用 RAG 做知识问答，切分策略我们试了三种，用一个 200 条的标注集做离线评测，召回率从 X 提升到 Y；上线后做了缓存和模型路由，单次调用成本降了大约 Z%”。注意数字要真实，宁可说“我们的标注集只有 200 条，统计上不算强”，也别编。

追问链：为什么做这个而不是直接用现成产品？→ 你们的数据是怎么进入知识库的，谁负责清洗？→ 用户觉得答案不对怎么处理？→ 上线后你怎么知道它在变好还是变差？——最后这一问，就是引到“评测”的钩子，后面会展开。

踩坑：只讲“接了大模型 API + LangChain”，说不出任何一个自己做的取舍。面试官会很快判断这是“调包侠”。

面试官问：后端基础照旧——线程池、CAS、B+ 树、慢 SQL

公开面经里，AI 相关问题旁边紧跟的仍是传统追问：CAS 与 ABA、线程池参数、ThreadLocal 原理、B+ 树索引、慢 SQL 排查。这里补一个和 AI 场景相关的结合点：LLM 调用是典型的高延迟 IO（一次调用几秒到几十秒、流式返回），如果你用固定大小的平台线程池去承接，线程很快就被占满。这里可以自然引出 JDK 21 虚拟线程：适合大量并发的 IO 密集型任务，官方 JEP 444 明确说明当并发任务数很高（超过几千）且负载不是 CPU 密集型时吞吐会显著提升；但要注意 JDK 21 中 synchronized 块内阻塞会“钉住”载体线程，这在 JDK 24 通过 JEP 491 大幅改善。能把这个版本差异说清楚，是很好的加分项。

再补一个 SSE / WebSocket 的选型题（小林 coding 的工具调用专题里出现过）：SSE 是单向、基于 HTTP、自带重连，适合模型逐 token 流式输出；WebSocket 是全双工，适合需要频繁双向交互（如语音、协同）的场景。企业内网网关、代理是否支持长连接和缓冲，也是落地时要考虑的。

三、第二轮：RAG 全链路（必考项）

卡码笔记把 RAG 称作大模型面试的“必考项”，覆盖向量检索、混合检索、重排和幻觉治理；AgentGuide 的 RAG 题库把题分成切分、Embedding、检索优化、评测、噪声与幻觉、成本并发几大类。我把这些拼成一条“一次提问的旅程”，面试官通常也是顺着这条线追问。

Q1：RAG 是什么？为什么不直接微调？

参考回答要点：RAG 是“检索增强生成”：先根据问题从外部知识库检索相关片段，再把它们放进 Prompt 让模型基于上下文回答。相比微调：知识可以随时更新（不用重新训练）、答案可追溯（能给引用）、成本低；微调更适合改变模型的风格、格式或注入稳定的领域能力，不适合承载频繁变化的事实。卡码笔记在“微调 vs RAG vs Prompt 优化”这个取舍上也是同样的思路。

追问：什么时候两者结合？→ 用微调让模型更好地遵循“基于上下文回答、不知道就说不知道”的格式，再用 RAG 提供事实。

Q2：文本怎么切？块大小和重叠怎么选？

要点：AgentGuide 的题库把这个问题定位为“上下文完整性与检索精准度的权衡”：块太小语义不全，块太大检索噪声多、占 Token；适度重叠保持上下文连贯。工程上不要只用固定长度切分，优先按文档结构切（标题层级、段落、表格、代码块），再对超长段做二次切分，并给每个块带上元数据（文档名、章节路径、更新时间），这些元数据后面可以用来过滤和引用。

追问链：怎么证明你选的块大小是好的？→ 用评测集，不要靠感觉：准备一批“问题 + 应命中的文档片段”，对不同切分参数跑召回率，选综合最优的。这一步答出来，就从“背概念”跳到“有方法”。

Q3：Embedding 模型怎么选？向量库怎么选型？

要点：Embedding 看语言支持（中文场景要专门看）、维度（影响存储与检索速度）、最大输入长度、在你自己领域数据上的召回表现，以及部署方式与成本（API 还是自部署）。向量库选型（面经里出现过 Milvus 选型这类问法）：数据规模、是否需要标量过滤与混合检索、更新与删除的频率、运维成本、是否已有基础设施（比如已经在用带向量能力的数据库或搜索引擎，可以不新增组件）。

加分：说明“换 Embedding 模型意味着全量重建向量索引”，所以要给索引做版本化，支持灰度切换和回滚。这是后端思维在 AI 场景里的天然优势。

Q4：为什么需要混合检索和重排？

要点：向量检索擅长语义相似，但对专有名词、型号、错误码、精确数字不敏感；BM25 这类稀疏检索基于词频与文档长度归一化，对关键词命中很强。两者结果融合（比如 RRF 倒数排名融合，或加权）能提升召回；然后用 Reranker（交叉编码器）对候选做精排，只取 Top-N 送给模型。题库里“Lost in the Middle”指的是长上下文中间位置的信息容易被模型忽视，缓解办法是重排后把最相关的放在开头或结尾、减少无关内容、控制上下文长度。

追问：重排会增加延迟，怎么权衡？→ 先召回较多（如 50 条），重排后取 5–8 条；对延迟敏感的场景，用更轻的重排模型或只对高不确定性的问题启用；同时缓存热门问题的检索结果。

Q5：RAG 还是会答错，怎么治幻觉与噪声？

要点（分层）：

• 检索侧：质量过滤（去重、过期文档降权）、相关性阈值（分数太低就不给模型，直接走“无法回答”）；
• Prompt 侧：明确“仅根据给定资料回答，资料不足就说不知道”，并要求输出引用编号；
• 后处理：对答案做引用校验（每个关键断言能否在引用片段中找到），不通过就重试或降级；
• 产品侧：展示引用来源、允许用户反馈“答案有误”，反馈回流到评测集。

踩坑：不要说“把 temperature 调成 0 就没有幻觉了”。温度只影响采样随机性，不能保证事实正确；幻觉的原因是模型本质上在做概率续写。

Q6：知识库更新怎么做？数据有时效性怎么办？

AgentGuide 题库里有“时间衰减与增量更新”这两类问题。要点：增量更新靠“文档指纹（内容 hash）+ 变更事件”，只重算变化的块；删除要同步清理向量与元数据（软删除 + 定期物理清理）；时效性数据（价格、政策）在检索时按更新时间加权或过滤，并在答案里带上“数据截至某日期”。这也是很典型的后端治理题，中高级面试官爱问。

四、第二轮（续）：Agent 与工具调用

卡码笔记那份 Agent 面经汇总，把高频题整理成“题目 + 追问链 + 回答思路”，我按自己的理解挑最反复出现的几组来复盘。

Q7：Agent 和普通调用 LLM 有什么区别？什么时候用 Workflow？

参考回答要点：LLM 本身是无状态的“文本函数”；Agent 在外面加了规划、工具调用、记忆、循环执行，让模型能根据观察结果决定下一步。Anthropic 那篇《Building effective agents》给了一个我很喜欢的分类：Workflow 是“由预定义代码路径编排 LLM 与工具”，Agent 是“LLM 动态决定自己的流程和工具使用”。并列出常见 Workflow 模式：提示链（Prompt Chaining）、路由（Routing）、并行化（Parallelization：分段或投票）、编排者-工人（Orchestrator-Workers）、评估者-优化者（Evaluator-Optimizer）。

追问：“为什么不全用 Agent？”→ Agent 灵活但不确定、成本高、延迟长、难调试；能用固定流程解决的就用 Workflow；开放式、步骤不可预测、且结果可验证、你信得过模型判断的任务（如客服、编码）再用 Agent。Anthropic 的建议很朴素：先用优化过的简单 Prompt，只有在确有收益时才增加复杂度。生产里最常见的是混合架构：简单问题走固定流程，复杂问题才启动 Agent，高风险或失败多次就转人工。

Q8：Function Calling 的底层原理？LLM 自己执行函数吗？

要点：Function Calling 本质是一种结构化输出协议，不是执行机制。流程四步：① 应用把工具的名称、描述、参数 JSON Schema 传给模型；② 模型判断是否需要调用，输出工具名与参数（JSON）；③ 应用侧代码校验并执行；④ 把结果作为工具消息回传，模型据此继续或给出最终答案。所以“执行权在应用侧”，这既是灵活性也是安全边界：参数一定要校验、权限一定要在服务端检查。加分项：不同厂商字段不同（比如 OpenAI 是 tool_calls，Claude 是 tool_use 内容块），你封装适配层时要抽象出统一的中间结构。

追问链：和“Prompt + 正则解析 JSON”比有什么好处？→ 模型对该协议有专门训练，格式更稳定，参数 Schema 有约束；仍然可能出错，所以要做校验和重试。→ 并行调用怎么处理？→ 模型可能一次返回多个互不依赖的调用，服务端可并发执行，最后按 id 一一对应回填结果。→ 工具很多（上百个）怎么办？→ 不要全塞进上下文：先做工具检索或路由，只加载与当前任务相关的少量工具（这也是省 Token 的第一招）。

Anthropic 在文中强调，要像设计人机界面一样投入精力设计“Agent-计算机接口（ACI）”：工具描述要清晰、给出示例与边界情况、参数格式要贴近模型自然的输出形式、避免让模型做计数或转义这类容易出错的事，并在沙箱里大量测试。这条我建议背下来，因为“怎么写好一个工具”是很实在的工程题。

Q9：MCP 是什么？和 Function Calling 什么关系？

要点：我对照了 MCP 官方规范：MCP 是开放协议，用 JSON-RPC 2.0 在Host（发起连接的 LLM 应用）、Client（宿主里的连接器）、Server（提供上下文与能力的服务）之间通信，连接有状态并做能力协商。Server 可提供三类东西：Resources（数据）、Prompts（模板）、Tools（模型可调用的函数）；Client 可提供 Sampling、Roots、Elicitation 等能力。它的设计灵感来自 LSP，目的是解决“每个应用都要对接每个工具”的 N×M 问题。

所以关系可以这样答：Function Calling 解决“模型怎么表达要调什么”，MCP 解决“工具怎么被发现、怎么被标准化地接入”；两者不是替代关系，而是不同层。卡码笔记还有一个通俗类比：Function Call 是基础通话能力，MCP 是统一通讯录，Skills 是岗位培训手册。

安全追问（一定会有）：规范里明确写了：工具代表任意代码执行，必须谨慎对待；工具行为的描述（比如 annotations）应视为不可信，除非来自可信的 Server；Host 在调用任何工具前必须获得用户明确同意。落地含义：对第三方 MCP Server 要做白名单、权限分级、调用审计，对有副作用的工具（写、删、支付）加入人工确认；这也是防 Prompt Injection 的一环。

Q10：ReAct 是什么？为什么会死循环？怎么防？

要点：ReAct 是 Thought → Action → Observation 的循环，模型边推理边调用工具，直到给出最终答案。优点是透明、可审计、适应性强；缺点是每一步都带完整历史，Token 消耗大、延迟长，且当工具持续失败或结果不满足模型预期时，可能反复重试。卡码笔记给出的三招我认为很实用：最大步数限制、重复动作检测（连续相同工具 + 相同参数就退出）、超时控制。我自己再补两条：失败要给模型可行动的错误信息（而不是一句“error”），以及预算（Token / 金额）上限。

下面是一个我会在面试里手写的“带护栏的 Agent 循环”骨架（伪接口，突出逻辑）：

import java.util.*;

public class AgentLoop {
    private static final int MAX_STEPS = 12;
    private static final int MAX_REPEAT = 3;
    private static final long BUDGET_TOKENS = 50_000;

    interface Llm { Reply chat(List<Message> history, List<ToolSpec> tools); }
    interface ToolExecutor { String execute(String name, String argsJson) throws Exception; }
    record Message(String role, String content) {}
    record ToolSpec(String name, String description, String schema) {}
    record ToolCall(String id, String name, String argsJson) {}
    record Reply(String text, ToolCall call, int usedTokens) {}

    public String run(String question, Llm llm, ToolExecutor tools, List<ToolSpec> specs) {
        List<Message> history = new ArrayList<>();
        history.add(new Message("user", question));
        Map<String, Integer> seen = new HashMap<>();
        long used = 0;

        for (int step = 1; step <= MAX_STEPS; step++) {
            Reply r = llm.chat(history, specs);
            used += r.usedTokens();
            if (used > BUDGET_TOKENS) return fallback("超出 Token 预算");
            if (r.call() == null) return r.text();          // 模型给出最终答案

            ToolCall c = r.call();
            String key = c.name() + "|" + c.argsJson();
            if (seen.merge(key, 1, Integer::sum) >= MAX_REPEAT) {
                return fallback("检测到重复调用同一工具");   // 防死循环
            }
            String obs;
            try {
                obs = tools.execute(c.name(), c.argsJson());  // 应用侧执行，先校验参数与权限
            } catch (Exception e) {
                obs = "工具执行失败: " + e.getMessage() + "。请检查参数或换一种方式。";
            }
            history.add(new Message("assistant", "call " + c.name()));
            history.add(new Message("tool", truncate(obs, 4000))); // 输出截断，防上下文爆炸
        }
        return fallback("超过最大步数");
    }

    private String truncate(String s, int max) { return s.length() <= max ? s : s.substring(0, max) + "…(已截断)"; }
    private String fallback(String reason) { return "抱歉，这个问题我暂时处理不了（" + reason + "），已转人工。"; }
}

追问：Plan-and-Execute 和 ReAct 怎么选？→ 步骤可预先规划的任务用 Plan-and-Execute，模型只规划一次、执行阶段可用更小的模型，省 Token；开放探索、需要根据中间结果不断调整的任务用 ReAct。上面代码里“先校验参数与权限”这句是关键：模型可能幻觉出不存在的工具名或越权的参数，工具名要白名单校验。

Q11：Agent 的记忆怎么设计？上下文满了怎么办？

要点：分层：上下文窗口是短期记忆；长期记忆放外部存储——向量库存语义偏好类信息，关系库存订单账号这种需要精确查询的事实，KV 存任务状态。上下文压缩三种手段：滑动窗口、摘要压缩、重要性过滤。追问“什么时候写记忆”：不要每轮都写，可以在会话结束或重要事实出现时由一个轻量模型抽取，并做去重与冲突处理（新事实覆盖旧事实）。

Q12：Agent 的安全与可靠性

要点：最小权限（读权限不给写删权限）、高风险操作人工审批、数据与指令分离（外部网页、文档内容放在明确标记的区域，不被当成指令）、输入过滤；可靠性上做幂等、回滚、超时。Prompt Injection 是必问：间接注入（网页/邮件/文档里藏指令）比直接注入更难防，只靠“提示词里叮嘱”是不够的，必须依赖权限与确认机制做硬隔离。幂等具体怎么落地？给有副作用的工具调用加 idempotency key（如会话 ID + 步骤号），服务端去重，重试才不会重复下单或重复发邮件。

五、第三轮：评测、成本与工程落地（中高级的分水岭）

前两轮很多同学都能背出来，真正拉开差距的是这一轮。GitHub 那份 AI 面试指南强调“怎么验证”，卡码笔记强调“可观测性和成本优化”，我把它们合成三个问题。

Q13：你怎么评测一个 RAG / Agent 系统？

参考回答结构：先说“分段评测”，再说“离线 + 在线”，最后说“评测集怎么来”。

• 检索段：召回率（应命中的片段有没有被召回）、精确率、MRR / NDCG 这类排序指标；
• 生成段：答案与参考是否一致、是否忠实于上下文（有没有编造）、相关性、流畅度；AgentGuide 题库的说法是要分别评估“召回—过滤—生成”三段式，而不是只看最终答案；
• Agent 段：任务成功率、平均步数、工具调用正确率、失败类型分布（参数错、选错工具、死循环、越权）、单任务 Token 与耗时；
• 离线：维护一个“黄金评测集”（真实问题 + 标准答案 / 应命中文档），每次改切分、改 Prompt、换模型都跑一遍回归；用 LLM-as-Judge 做规模化打分，但要抽样人工复核，防止 Judge 自身偏差；
• 在线：点赞点踩、人工转接率、重问率、引用点击率；灰度对比 A/B；
• 评测集来源：线上日志脱敏后抽样、专家标注、难例挖掘（点踩的问题回流进评测集）。

加分：把评测接入 CI：Prompt 或检索配置变更走“评测集回归 → 指标不得低于基线 → 灰度”流程，这就是AI 应用的“单元测试 + 发布门禁”。

下面是一个我会在白板上写的检索评测小例子，说明“召回率”到底怎么算：

import java.util.*;

public class RetrievalEval {
    /** 单个问题的 recall@k：应命中的文档里，有多少出现在前 k 个结果中 */
    static double recallAtK(List<String> retrieved, Set<String> relevant, int k) {
        int hit = 0;
        for (int i = 0; i < Math.min(k, retrieved.size()); i++) {
            if (relevant.contains(retrieved.get(i))) hit++;
        }
        return relevant.isEmpty() ? 0 : (double) hit / relevant.size();
    }

    /** 单个问题的倒数排名：第一个相关结果排第几，取倒数 */
    static double reciprocalRank(List<String> retrieved, Set<String> relevant) {
        for (int i = 0; i < retrieved.size(); i++) {
            if (relevant.contains(retrieved.get(i))) return 1.0 / (i + 1);
        }
        return 0;
    }
}

对所有问题取平均，就是 Recall@k 和 MRR。注意评测集太小时，指标波动很大，别对 1–2 个百分点的差异过度解读。

Q14：Token 成本怎么优化？

卡码笔记给出了一个“由易到难”的阶梯，我觉得很适合当答题骨架：

我再补三条业务侧手段：语义缓存（相似问题直接命中历史答案，需要设阈值和过期）、限制输出长度与结构化输出、预算与限流（按用户 / 租户设 Token 配额，超额降级）。面试官追问“怎么量化”：要有成本看板——按功能、按租户、按模型统计单次请求平均输入 / 输出 Token 和费用，才能知道优化哪一层最划算。卡码笔记中的一个生产对比是：简单任务从 ReAct 换成 Plan-and-Execute 可以节省相当比例的 Token，但具体数字取决于任务，别把它当普适结论。

Q15：这个系统上线后你怎么治理？（可观测、灰度、回滚）

要点：可观测性三样：完整 Trace（一次请求里每次模型调用、每个工具调用、检索命中、耗时、Token 都串起来）、指标（成功率、P95 延迟、Token 用量、限流与失败类型）、日志与采样回放（脱敏后保留可复现的输入）。发布上，Prompt、模型版本、检索配置、工具定义都要版本化，走灰度和一键回滚——很多线上事故不是代码改了，而是“换了个模型版本 / 改了一句提示词”。另外别忘了降级方案：模型超时或限流时，回退到关键词搜索、缓存答案或转人工。

追问：“模型供应商临时抖动或限流怎么办？”→ 超时 + 重试（指数退避加抖动）、熔断、备用模型 / 备用供应商、请求排队与优先级（付费用户优先）、异步任务化（长任务提交后轮询或回调）。这些和传统微服务治理一脉相承，你的后端经验在这里全部可以迁移。

六、系统设计题：设计一个企业级 Agent 平台

公开面经里，系统设计常见的形式就是“设计一个企业级 Agent 系统”。卡码笔记给的五个维度可以直接当提纲，我加上自己的补充：

1. 工具管理层：通过 MCP 或内部工具注册中心统一接入；工具有元数据（名称、描述、Schema、权限级别、副作用等级、超时、幂等性）；调用全量审计。
2. 记忆与状态：会话状态、长期记忆分层存储；任务状态机持久化，支持断点续跑（长任务不要放在一次 HTTP 请求里）。
3. 可靠性：最大步数、重复检测、超时、人工审批点、幂等与回滚。
4. 可观测性：Trace、Token 与成本监控、错误分类、评测回归。
5. 安全：Prompt Injection 防护、最小权限、租户隔离、数据脱敏、敏感操作确认。

答题顺序建议：先澄清需求（用户是谁、任务类型、QPS、可接受延迟、错误容忍度）→ 画出主链路（网关 → 会话服务 → 编排层 → 模型网关 / 工具网关 / 检索服务 → 存储）→ 逐个说“它出问题怎么办”→ 最后说演进（先 Workflow 后 Agent、先单 Agent 后多 Agent）。模型网关值得单独展开：统一鉴权、限流、多模型路由、重试熔断、成本统计、Prompt 与响应的脱敏审计。

如果面试官问“多 Agent 有必要吗”，我的答案是：多数场景先别上。多 Agent 会放大 Token 成本、增加调试难度和一致性问题；只有在子任务确实相互独立、上下文需要隔离、或需要不同权限边界时才拆分。Anthropic 文章里的“编排者-工人”模式适合子任务无法预先确定的情形（比如跨多个文件改代码），但要为它付出成本。

七、这场面试暴露的通用规律

八、复盘清单与准备建议

1. 做一个能讲三层的小项目：带评测集的 RAG 问答 + 1–2 个真实工具的 Agent，自己实现工具调用循环，而不是只调框架。
2. 补评测：哪怕只有 100 条标注，也要有 Recall@k / MRR 和一份失败案例分类表。
3. 准备成本账：估算单次请求的 Token、月成本，并列出你会做的三个优化。
4. 准备安全一页纸：Prompt Injection、权限、审批、审计，各一个例子。
5. 准备一个“翻车故事”：你的系统曾经答错、死循环或超预算，你如何发现与修复。
6. 传统后端别荒废：并发、MySQL、Redis、MQ、限流熔断，每周回顾一遍。
7. 读官方文档：至少读一遍 MCP 规范总览与 Anthropic 的 Agent 构建文章，面试时能说出原文的核心区分。
8. 诚实边界：不会的（比如模型训练细节）就说“这块我偏应用侧，了解到 X，Y 我会怎么去学”。卡码笔记也把“能承认不知道并说出学习计划”列为加分项。

顺带一个提醒：这些资料很多是面试题库和二次整理，“真实大厂题”的说法无法逐条验证——GitHub 上那份指南就明确写了“排除无法验证的大厂面试声明”。我们能学到的是题型与追问逻辑，而不是某家公司的标准答案。

一句话备忘：AI 应用岗面试 = 后端基本盘 + RAG 全链路 + 带护栏的工具调用循环 + 评测集 + 成本账 + 安全与治理；答题永远走“概念 → 原理 → 工程落地”，并用一个真实的坑收尾。

我入行时最怕“新技术名词轰炸”，后来发现名词换了一茬又一茬，追问的逻辑始终没变：它解决什么问题、边界在哪、出错怎么办、花多少钱。抓住这四问，大部分“新题”其实都是老题。

参考资料

• 卡码笔记：Agent / 大模型面试题汇总（ReAct、Function Calling、MCP、RAG）：本文追问链、ReAct 防死循环三招、成本优化阶梯、企业级 Agent 五维度的主要来源。
• 卡码笔记：大模型面经汇总：RAG 被视为必考项、应用岗与算法岗侧重点不同的判断。
• 小林 coding：AI 大模型面试题集：Agent / RAG / 工具调用 / 大模型工程四专题的分类方式，以及“考工程思维而非背诵”的说法。
• GitHub：ai-interview-guide：面试题按工程取舍与“如何验证”组织，并声明排除无法验证的大厂面试说法。
• GitHub：AgentGuide 的 RAG 面试题：切分、Embedding、检索优化、评测、噪声与时间衰减等题目要点。
• Anthropic：Building effective agents：Workflow 与 Agent 的区别、五种工作流模式、工具接口设计建议。
• MCP 官方规范（2025-06-18 版）：Host / Client / Server 架构、三类服务端能力、工具安全与用户同意原则。
• 牛客网「Java 工程师精选面经合集」：涉及 RAG 业务场景、Milvus 选型、Agent 意图识别及传统后端追问的短面经，页面未统一标注年份。
• JavaGuide：项目经历准备指南：AI Agent 项目要能讲清工作流与失败恢复。
• OpenJDK JEP 444：Virtual Threads：虚拟线程在 JDK 21 定稿、适用场景与 synchronized 钉住问题。
• OpenJDK JEP 491：Synchronize Virtual Threads without Pinning：JDK 24 起 synchronized 不再钉住载体线程。