最近帮团队筛了一批AI岗位的简历，也面了不少候选人，有个感受特别强烈：十个投AI岗的人，八个简历里写着RAG和Agent项目，但一到追问环节，好几个都卡在“代码能跑，原理却说不上来”。这不是个别现象，而是当前AI应用开发太依赖框架和现成样例，把门槛拉低之后的必然结果。你用一个上午跑通了LangChain的RAG demo，再用两个晚上调通了一个Agent工具调用，确实能写进简历，但投递AI岗位时，面试官真正想看到的远不止这些。
写这篇文章，就是想给正在准备AI岗位面试、或正在优化简历项目的朋友提个醒：别把“能跑代码”当成项目完成。RAG和Agent这两个方向，近年几乎成了AI应用岗的标配，可面试官看中的恰恰是那些代码跑通之后才会暴露出来的问题——数据切分、检索质量、幻觉控制、任务规划、失败恢复、成本边界。这些才是区分“跑过demo”和“真正做过项目”的分水岭。下面我会从面试官视角拆一遍，RAG和Agent项目到底该怎么准备，才能在问答环节站得住。
1. 面试官最想问的，其实是你对“系统边界”的理解
先还原一个很典型的面试场景。候选人简历上写着“基于LangChain搭建企业知识库问答系统，实现RAG检索增强生成”，听起来没错。我问第一个问题：“你的chunk size为什么设成500？如果改成200或者1000，对答案质量会有什么影响？”对方愣住，想了半天说“我试过几个值，感觉差不多”。我再问：“用户问了一个知识库里根本没有的问题，你的系统会怎么回答？你做了阻止模型胡说的处理吗？”对方开始支支吾吾。
这不是针对谁。很多RAG项目跑通得太容易了，导入文档，切块，塞进向量库，接上LLM，表面上确实能回答一些问题。但“能回答一些常见问题”和“在边界情况下依然可靠”之间，差着整个生产环境的基础素养。面试官问这些边角问题，不是为了刁难，而是想在短时间内判断：你有没有站在系统层面思考过自己的项目？
所谓系统边界，就是知道这个方案在什么情况下会失效。RAG的边界在哪里？知识库覆盖不全、检索召回率低、上下文塞太满导致幻觉、多跳问题链式推理失败。Agent的边界在哪里？工具调用格式不稳定、多步任务错误累积、记忆丢失导致重复、成本不可控。这些问题，代码不会直接告诉你，只有你自己做过、踩过，或者认真读过相关分析，才答得出来。
面试官也不想招一个只会对着教程调参的人。你写的每行代码、选的每个参数，背后都应该有理由：为什么用混合检索而不是单路向量检索？为什么不把检索到的所有片段都塞进提示词？为什么Agent要设最大迭代次数？理由不一定全对，但你得有。有理由代表你有思考，有思考才可能进下一轮面试。
2. RAG项目：真正拉开差距的是chunk、检索和评估这三个环节
现在具体说RAG。这一节我想按面试时的高频追问顺序来写，也基本对应一个RAG项目的核心链路：文档切分、召回、重排、生成、评估。你如果能在每个环节讲出“为什么”和“如果这样会怎样”，面试官基本不会再拿框架名来考你。
2.1 chunk size怎么定，面试官想听的是“为什么”
这是RAG项目最容易被追问的点。很多教程默认给一个数，比如512或者1024，你照着写了，但面试官问的时候你答不出动机，印象分就掉了。chunk size没有标准答案，它取决于你的文档类型和问题形态。
举几个我实际遇到的例子。处理合同文本时，一个条款往往很长，如果chunk切得太碎，一个完整条款散落在多个片段里，检索到其中一个片段，模型只能看到一半的约定条件，回答就很容易片面。这时候chunk size应该调大一点，或者干脆按照条款结构切，而不是按固定字数切。处理产品说明书时，表格很多，纯文本切片会把表格拆烂，更好的做法是按markdown结构或表格行来切。处理代码文档时，一个函数最好作为一个chunk，否则大括号可能被切到两个片段里。
面试官想听的是，你知道chunk size不是拍脑袋定的，而是基于数据形态和问题复杂度做出来的。你还可以补一句：我留了overlap，避免切分边界切断语义；我还把文档标题、章节路径作为metadata拼进向量里，帮助召回。这句话一出来，对方就会知道你不是只调了CSV导入。
2.2 混合检索和重排，不是锦上添花而是兜底手段
纯向量检索最大的问题是：专业术语、商品型号、精确数字这类关键词，embedding表现不稳定。比如用户查“SN74HC245N”，向量检索很可能把相近字面但完全不同的物料拉上来，反而精确匹配字段的BM25能做对。真实RAG项目里，很多知识库都包含大量产品编号、法规条文，只靠向量召回会漏掉这些关键证据。所以我会建议简历里写“采用向量检索+BM25混合召回，再用rerank模型精排”，面试官问到，你就能讲出这套设计是来解决什么问题的。
讲混合检索的逻辑时，可以类比两个入口：向量检索擅长“相似语义联想”，关键词检索擅长“精确命中”。前者能找出“雨刮器坏了怎么办”对应到“刮水器更换方法”，后者能在用户输入“第12条”时准确锁定法条。两者各管一块，合并后效果才会稳。
重排环节同样重要。如果你一次检索出来50个chunk，全都塞给生成模型，上下文超长必然导致注意力分散，答案反而不准。正确的做法是先用双塔粗排，把候选集缩小到50个，再用cross-encoder重排到top3或top5。这个操作在面试里很加分，因为它体现你对成本和效果做过平衡。你要是能说一句“重排模型虽然慢，但只是在几十条候选上跑，延迟可控”，面试官基本就默认你有上线意识了。
2.3 生成质量：上下文压缩与幻觉控制
RAG不是把一堆检索结果拼起来扔给LLM就完事。上下文越长，模型越容易抓错重点，甚至编造出文档里没有的信息。一个常见优化是：检索回来后先做上下文压缩，删掉和用户问题无关的句子，只保留关键片段，再拼进提示词。这个动作既降低token成本，又减少幻觉。
面试官这边很爱问“幻觉怎么处理”。你可以分三层回答。第一层，在提示词里明确约束：没有原文支撑时，必须回答“知识库中没有相关信息”，不允许自行推断。第二层，在检索端提高证据质量：如果top-k召回结果的相似度都低于某个阈值，直接判定为无答案，不再走生成流程。第三层，在输出端要求模型给出引用片段或来源条款，方便后续核查。这三层思路本身，比任何具体代码都有说服力。
另外可以提一句“no answer”训练或阈值设置。你不需要真的训练过模型，但可以说：我设定了一个检索分数阈值，低于阈值就触发fallback。面试官不是要你上生产级方案，而是要看到你具备“可控性”的意识。
2.4 没有评估体系的RAG项目，面试会露馅
很多候选人聊RAG会聊得很热闹，但一问“你怎么知道你的系统比原来的好”，就卡住了。这比前面几个问题更能拉开差距。没有评估，你所谓的“效果好”只是几个demo问题的观感，不是可验证的结果。
我当时是这么做的：从知识库里挑了一篇长文档，人工构造了30条测试问题，覆盖三类——能从单条片段直接答出的，需要拼两个片段才能答出的，以及知识库里根本没有、预期应该拒绝回答的。每道题都标注好标准答案和出处的chunk位置。然后跑了三组实验：chunk size分别改成300、500、800，各跑一遍离线评估，统计召回率、答案正确率、拒绝回答率。最后发现chunk size=500时整体F1最高，chunk size=300时检索召回更高但生成阶段容易断章取义，chunk size=800时答案完整但偶发幻觉。这个结果一拿出来，面试官眼里你的项目就是一个“带评测指标的工程”，不是一个“跑完就扔的demo”。
评估工具方面，RAGAS这类开源框架可以算faithfulness、answer relevance、context precision，但你最好能解释指标含义。Faithfulness衡量的是生成内容到底有没有忠实引用检索上下文，context precision衡量检索结果是不是越靠前越相关。能用一组指标指出项目瓶颈，比如“召回没问题，但生成时模型有点自说自话”，比罗列一堆技术名词强得多。
2.5 进阶话题：GraphRAG、本体RAG和Agentic RAG
如果你的岗位是偏高级或算法方向，建议再补一个进阶点。RAG的常见瓶颈是处理不了多跳关系：问“某项目延期的原因对供应商付款条件有什么影响”，普通向量检索只能找到跟“项目延期”相关的碎片，很难沿着合同里的引用关系跨片段推理。
现在有很多RAG变体，比如GraphRAG把实体关系抽取成图谱，检索时沿着关系路径找证据。本体RAG用业务本体约束实体和关系的语义，适合垂直领域。Agentic RAG则是在检索、重排、生成之间加入Agent调度，让Agent决定什么时候检索、检索几次、要不要去调另一个工具。你不用真的都做过，但面试时能说清楚“我知道经典RAG只适合单跳问答，关系型问题需要图谱或Agent化”，这层认知本身就值钱。
3. Agent项目：从“能调工具”到“能接管复杂任务”隔着一整条容错链
讲完RAG再说Agent。现在Agent框架很多，LangGraph、AgentScope、AutoGen，每个都能两天跑通一个demo。但投AI岗时，面试官不会问你“会不会用LangGraph”，而会问你在Agent失控时怎么处理。能调工具只是入门，真正拉开差距的是规划、记忆、容错这三件事。
3.1 规划层：ReAct不是万能的，要会按任务复杂度选型
很多入门教程的Agent demo都是ReAct模式：模型循环地“思考-行动-观察”，直到得出答案。这个模式简单直观，但多步任务很容易累积错误。比如让Agent去查三个数据源，再写一份对比报告，如果用ReAct让模型一步步自由发挥，中间某一步错了解析，后续所有步骤都会被带偏。
面试时可以这么说：我在简单单选任务上用的ReAct，但在复杂任务上尝试过Plan-and-Execute模式，先让Agent把任务拆成几个阶段，再逐步执行，每阶段校验结果。不要怕暴露自己选型不够完美，你要展示的是“我根据不同任务选择不同策略”的判断力。再补一个细节：我设置了最大迭代次数，防止Agent在失败分支上无限循环。这句话一出，面试官就知道你踩过Agent卡死的坑。
3.2 工具调用的可靠性与校验
Agent的核心是跟工具打交道，但模型生成的工具调用不一定合法，常见故障包括参数类型写错、必填参数缺失、工具返回格式不标准。面试官最怕听到“我没处理过这个问题，因为我的demo工具都设置好了”。
真实的Agent项目必须有工具调用校验层。我的做法是：在调用工具前，先把模型输出的JSON参数做一个schema校验，用pydantic或jsonschema验一下，不合法就带着错误信息让模型重新生成一次。工具返回后，再做一层解析校验，比如要求返回必须是标准JSON或者包含特定字段，否则标记为失败。这个环节不需要多复杂，但你讲了，面试官会认为你理解Agent是“不可靠的模型+需要可靠编码”的组合体。
还有一点：工具描述本身的质量直接影响调用准确率。你在Agent里注册工具时，如果描述写得太模糊，模型会频繁用错。有效的做法是给每个工具限定输入格式和适用场景，比如“计算总价时使用此工具，参数amount必须是浮点数，单位美元”。这个细节很小，但很能体现你的工程经验。
3.3 记忆与上下文管理：Agent的短期记忆和长期记忆不能混着谈
老实说，很多Agent项目根本没有设计记忆，只是靠对话历史的滑动窗口在硬撑。面试官问“你的Agent在多轮任务里怎么记住中间结果”，需要区分短期记忆和长期记忆。
短期记忆就是当前任务执行过程中的中间变量，比如用户输入了“帮我查A和B的价格”，Agent先查A，再把A的价格存下来继续查B，最后汇总。这个中间状态可以写进上下文，也可以用内存变量存。长期记忆面向跨对话场景，比如用户上次偏好、历史任务结果，需要持久化，通常用向量库存储或者摘要化存储。面试时提一句“我目前只做了短期记忆，长期记忆在架构上预留了存储层”，比硬说自己全做了更可信。
上下文管理还有一个成本问题：把整段历史都留给Agent，一轮对话可能烧掉几万token。你可以说自己做了“历史摘要压缩”，每隔几轮把前面的对话压缩成一句话再继续。这是Agent项目中很实用的优化，面试官一听就知道你是真在跑业务。
3.4 容错与恢复：一次工具失败后，Agent该做什么
这个问题我在面试里几乎必问：“你的Agent在调用某个外部API时超时了，它会怎么办？”常见的错误回答是“重试一下就好”。但真实场景里，重试可能连续失败三次，或者API返回了一个完全荒谬的结果，Agent需要有降级策略。
我建议准备这样一段回答：我的Agent带三层容错。第一层，工具调用失败会重试两次，每次等待时间递增；第二层，如果还是失败，Agent会尝试调用备选工具，比如主搜索失败后改用备用搜索；第三层，如果所有工具都失败，Agent不会编造结果，而是把失败原因和部分结果返回给用户，并询问是否要继续其他方式。这个回答之所以加分，是因为它展示了“Agent需要被约束，而不是被放任自由发挥”。
还可以讲一个具体调试经历：你发现Agent在工具返回中取了一个null字段，导致后面所有的计算结果全是“undefined”。后来你加了一个空值检查，一旦发现关键字段为空就触发修复流程。这种细节比“我调通了三个工具”更有说服力。
3.5 成本与安全边界，很多候选人没概念
Agent项目还有一个面试高频题：成本。一个Agent执行复杂任务时，可能调用模型几十次，每次都要消耗token。如果你没算过账，会给面试官留下“不适合生产”的印象。你可以说，我用一个case估算过，每轮Agent调用平均消耗多少token，一个月跑下来大概多少钱，所以我在工具调用前增加了缓存、把重复查询结果先存起来，避免重复生成。这种成本意识在AI岗面试里非常稀缺。
安全边界也要提两句。不要让Agent拥有所有工具的无限制权限。比如在代码执行Agent里，我只会给Agent一个沙盒目录，不能访问系统文件；在操作数据库的Agent里，只开放只读账号。面试官如果问到“你的Agent会不会乱删数据”，你能回答“权限最小化+人工审批门槛”，比任何算法优化都更能展现工程素养。
4. 用三个高性价比实验，把项目从“demo”变成“案例”
前面讲了很多面试追问点，但最关键的还是你要在面试前真正动手补课。这里我推荐三个低门槛、高回报的实验，任何一个都能让你的项目在描述时多出真实数据，而不是停留在“能跑代码”。
4.1 给RAG项目加一套离线评估集
这是性价比最高的实验，我前面已经提过。哪怕你只有几十条测试问题，做一轮chunk size/检索top-k/重排开关的对比实验，就能得到一张小小的结果表格。面试时你拿出这张表格，完全有资格说“我做了RAG调优，发现检索召回率从67%提升到82%，但生成正确率在某个参数下反而下降了，所以最终选择了一个平衡点”。这比任何“我用了LangChain”都强一百倍。
构造测试集时不要只做简单题，一定要包含需要多片段聚合的问题和拒绝回答类问题。很多候选人只准备知识库里有答案的问题，遇到“没有答案”的情况就傻眼。放几道这样的题，你的评估结论才有可信度。
4.2 给Agent故意制造故障，看它怎么恢复
这个实验听起来有点反直觉，但对面试帮助极大。你可以写一个测试脚本，故意让某个工具返回超时或者错误字段，然后观察Agent的行为。第一次跑的时候你会发现非常有趣：Agent可能会一直重试，或者直接把错误结果当作正确答案继续生成。你根据这些失败案例，再补上错误处理逻辑，比如重试次数限制、备选工具、失败上报。
准备面试时，你不需要说自己“设计了完整容错体系”，你可以反过来讲：“我通过故障注入发现一个问题，然后加了XXXX修复。”真实感和具体度完全不一样。故障注入实验本身就是一种工程测试方法的体现，很多做AI应用的人都没做过，你说出来就是差异化。
4.3 画一张系统链路图，标注每个环节的失败点
不要用visio画那种高大上的架构图，而是手画一条从“用户输入”到“最终回答”的链路，然后把每个环节可能出问题的地方标出来。比如链路是：问题路由→查询改写→检索→重排→生成→输出校验。在“查询改写”旁边写：用户口语化表达，模型改写后歧义风险；在“检索”旁边写：向量召回漏掉精确词，所以需要混合检索。
这张图会在面试中救你很多次。面试官问任何一个环节，你都可以指着图上的失败点展开。而且画图的过程本身就是逼你把知识梳理清楚的过程。等你画到“生成”环节，自然就会想到上下文压缩、幻觉控制、引用标注。这张图比简历上的项目描述值钱得多。
5. 不要在简历上写“精通LangChain”，这一句话就暴露了你的项目深度
最后聊点简历和自我介绍层面的事。我筛简历时，看到太多“精通LangChain”“熟练使用LlamaIndex”“熟悉LangGraph”这种写法。这基本上等于告诉面试官“我跑过几个官方demo”。为什么？因为框架本身只是工具，AI岗评价的是你解决问题的能力，不是你的API调用熟练度。你真的做过RAG项目，简历上应该写“通过混合检索和重排优化，将知识库问答的答案准确率从68%提升到85%”，或者“为Agent增加工具调用校验与失败恢复，多步任务成功率从41%提升到79%”。
数字不一定要精确到每个实验都完整跑过，但最好来自真实评估。如果你暂时没有这些数字，就诚实地写项目做的技术优化，比如“实现了检索失败时的阈值丢弃”“设计了Agent多轮中间状态缓存”。每个词背后都对应具体的实现，面试官一眼能看出这些不是背概念背出来的。
自我介绍时也同理。不要花两分钟讲“我用LangChain搭建了一个RAG知识库”，而要花两分钟讲“我解决了一个什么问题，当时有哪几个备选方案，为什么选这个”。有一个具体的问题背景，面试官的所有提问都会围绕这个背景展开，完全可控。反过来，你只讲技术名词，提问方向就会完全失控，大概率踩到某个你没想到的边界上。
如果面试官问到你确实没做过的部分，也有一个应对套路：先坦诚说“这个方向我目前还没有实际落地”，然后立刻补一句“不过基于我对RAG的理解，如果要做，我会这样设计架构……”。把问题拉回你的逻辑框架里，面试官能看到你的思考过程，哪怕答案不够完整，好感度也比支支吾吾高很多。
最近面试中我越来越感觉，RAG和Agent项目的“技术含量”不在于用了多新的框架，而在于你有没有想清楚每一步决策的原因。跑通代码是一件好事，但那只代表着学习路径的开始。真正让你通过面试的，是你知道你的系统在什么情况下会挂掉，以及你打算怎么让它挂得体面一点。希望这篇内容能帮你把项目准备得更扎实，也祝每一位准备投AI岗的朋友都能在追问环节稳住阵脚。
