如果最近在准备大模型岗位的面试你大概会发现一个现象简历里不放 RAG 知识库问答、LangChain 编排、Agent 协作相关的项目第一轮简历筛选都可能过不去。但真正到了面试现场最容易卡住的不是“项目没跑通”而是下面这类问题“用户问了一个知识库里没有的问题你的系统会怎么表现”“文档切分块大小为什么定成这个数字”“你说回答能带引用那怎么防止模型引用和正文对不上”“你这个 Agent 调用工具失败了怎么办”一旦在这些问题上停顿超过几秒项目基本就被打回原形。我的核心判断很直接大模型岗位的简历项目真正值钱的不是你会不会调 LangChain 的 API也不是你有没有把某个开源 demo 跑通而是你能不能对着一套自己设计的系统把功能、边界、失败场景、评估方法和后续迭代都讲明白。RAG、LangChain、Agent 这三件事恰好构成从功能到工程的三个台阶。下面我把一条从知识库问答、到智能客服、再到多 Agent 协作的项目主线拆开讲希望能帮你把它从“照着抄”变成“能扛住追问”。1. 面试官问倒你的通常不是原理而是失败场景1.1 照抄型知识库项目最明显的破绽很多聊到 RAG 项目候选人都会说我用了文本切分用了向量检索然后把检索到的内容扔给大模型让它基于知识库回答。这些话没有错但它只回答了“我做了什么”没有回答“我怎么判断它做得好”。面试官真正想听的是决策过程为什么这块业务需要 RAG而不是直接让大模型硬答切分策略是怎么定的你有没有对比过不同切分粒度检索不到内容时系统是直接编还是返回“我不确定”你用什么指标证明新方案比旧方案好Agent 把任务拆错了、工具调用超时了谁来兜底如果项目是看完几篇教程拼出来的绝大多数细节经不起连续三问。第一个问题还能解释框架第二个问题开始模糊第三个问题基本沉默。这不是知识储备不够而是项目构建方式出了问题你在用“能用”代替“可用”用“输出正常”代替“可控”。1.2 简历项目的验收标准不是跑通而是“我清楚它会在哪里失败”我习惯把这类项目的理解深度分成三层功能层知道这个工具能做什么能照教程跑出结果。机制层知道它内部为什么这样工作能解释参数和模块之间的关系。工程层知道它在真实场景里会遇到什么问题并且已经设计了日志、测评、兜底和异常处理。能进简历的项目至少要达到第三层的一半你不一定把每个工程能力都做完但要能说清楚哪些做了、哪些没做、哪些是下一阶段要做。所以开始写代码之前先给自己定一句主判断这个项目要证明的不是我调通了一个大模型应用而是我能在一个真实场景里把 RAG 和 Agent 做准、做稳、做可评估。后面所有章节都围绕这一句展开。2. 别把 RAG 当黑盒先让知识库问答每一步都解释得通2.1 RAG 不是追热点它解决的是大模型落地的三个硬问题为什么几乎所有大模型应用项目都要从 RAG 开始因为它解决的不是“锦上添花”而是三个非常具体的问题。第一私有知识和实时知识。大模型训练数据有截止时间也不可能包含企业内部的产品手册、售后政策、订单规则。如果不能实时把这些内容交给模型模型就只能靠“泛化能力”回答结果大概率是似是而非。第二幻觉控制。纯靠模型记忆回答问题时它会把没学过的信息用一种非常自信的方式说出来。RAG 给模型提供了一段可核对的上下文要求它“依据材料回答”相当于把回答范围收紧。第三更新成本。如果每次业务政策变化都重新训练或微调模型成本太高、周期太长。RAG 的好处是改一段文档、重新入库系统下一次检索就能用到新内容。但请注意RAG 不是一个“文档进去、答案出来”的魔法盒。它的实际效果由很多细节点决定任何一个环节弱结果都会打折扣。2.2 从文档入库到答案生成每一步都有“如果…就…”的取舍一条典型的 RAG 管线包括文档接入与清洗、切分、向量化、存储、检索、组装 Prompt、模型生成。你不能只把教程里的组装代码跑一遍要理解每个环节为什么存在。先看文档接入与清洗。PDF、Word、HTML 里往往带着页眉、页脚、目录、表格。很多入门项目直接按 PDF 页读文本结果切出来的 chunk 里一半是重复的导航文字另一半是断在半截的表格。这样的索引无论检索多先进都不可能召回有效信息。所以第一步要做的不是切分而是把文档结构还原出来保留必要的层级信息比如章标题、小节标题。再看切分。最常见的错误是问“切多少字合适”。切分粒度不是一个固定数字而是一个平衡块太大会稀释语义检索回来的内容可能有一半和问题无关浪费模型上下文块太小则会丢失上下文模型拿到的一句话可能根本解释不清一个流程。更合理的做法是按照文档结构切尽量把一个完整标题、一个完整表格、一个步骤组保持在一起。如果你最初不知道粒度就应该做几组不同切分放到后面说的测评集里去比较而不是凭感觉拍一个数字。然后是向量化与检索。Embedding 模型决定了文本的“语义理解方式”同一个领域切换不同模型检索效果可能差很多。尤其要注意专业术语、型号、缩写、规则编号这类信息它们不一定适合纯语义检索。一个常见问题是用户问“型号 ABC-100 能退吗”向量检索很可能把“退换货政策”整篇文章拉回来却找不到具体型号那一页。这种情况需要一个补丁思路要么做关键词和向量混合检索要么对文档做别名映射要么在检索前先做一次查询改写。最后是 Prompt 和生成。给模型的指令要明确只能依据提供的片段回答如果没有依据就明确说没找到引用来源要标清楚。你可以在代码里加入一个兜底分支当最高分片段的相似度低于某个阈值或模型判定材料不足时返回“知识库中暂未找到相关说明请转人工客服”而不是继续生成一段似是而非的话。注意不要一上来就追求全自动的完美链路。先把一条最小流程跑通再用真实业务问题验证最后再逐步加“聪明”的模块。2.3 没有测评集调参就是凭感觉RAG 项目最容易被忽略、也最能在面试里拉开差距的是测评。很多人做完一个知识库问答系统感觉效果“还行”但又说不上哪里不行。你说 chunk size 从 300 调到 500 结果更好了依据是什么你说 top_k 从 5 改成 8 召回更全怎么测出来的如果这些问题答不上来项目就还是实验品。建议先准备一个 50 到 100 条问题的小型测评集。问题要来自真实业务而不是教程里那种“用一句话概括什么是退货政策”。每条问题最好标注对应的标准答案来源片段至少要能判断“这个问题是否应该从知识库中找到答案”。有了这个集合你才能调参。常见的 RAG 指标可以分成三组层次指标关心的问题检索质量Recallk、Hit Rate、MRR正确答案有没有被检索到排在第几位生成质量Faithfulness / Groundedness回答是否忠于检索到的材料有没有脑补端到端质量Answer Relevance、人工正确率最终回答是否命中用户意图是否完整实际操作时不用从第一天就追求跑一套完整评测框架。可以先做一件最简单的事跑 50 条问题把每一条的回答结果看一眼记录哪些回答“看起来对但实际上没有依据”哪些回答“明明资料里有但没检索到”。这两类问题指向完全不同的修复方向前者要改 Prompt 和生成策略后者要改切分、Embedding、检索策略。3. LangChain 在项目里的真正价值是让流程变得可替换、可维护3.1 为什么你不用自己重复封装一套编排有人会觉得RAG 逻辑也不复杂直接用 Python 自己调模型、自己写向量检索、自己拼 Prompt 不就行了确实可以。LangChain 这类工具的价值不在于“它是唯一的实现方式”而在于它把反复出现的流程组件整理成可组合的对象。在真实项目里文档加载、切分、Embedding、向量存储、检索、Prompt 模板、模型调用、输出解析这些步骤几乎都要出现。如果全都自己硬编码每次更换一个 Embedding 模型、换一种向量库或改一个 Prompt都要四处修改。用编排框架后流程更像一条可以插拔的管道# 示意结构LangChain 版本迭代很快具体 API 以你本地安装版本为准 loader YourLoader(/path/to/data) documents loader.load() chunks text_splitter.split_documents(documents) vector_store.add_documents(chunks) retriever vector_store.as_retriever(search_kwargs{k: 5})初学者最容易犯的错是只背 API不理解流程。比如代码里写了retriever但说不清它实际作用是什么调了text_splitter却不知道切出来的 chunk 后面是向量入库的唯一单位。框架可以帮你省掉模板代码但不能替你理解数据流向。另外要提醒一点LangChain 的底层组件也在快速变化不同版本之间 API 迁移是常态。项目里要把依赖版本锁定清楚并且引入你自己调用的抽象层。这样即便上游版本升级影响范围也能被控制住。面试时有一句话很加分“我通过这个项目意识到框架本身不是核心资产框架背后的编排模式才是所以我把它包在项目内部避免和版本强耦合。”3.2 LangChain 和 LangGraph 不是二选一是不同复杂度下的编排工具很多人被 LangChain 和 LangGraph 的关系搞混。用一句话区分如果你的流程是固定的“检索—生成”线性管道LangChain 足够如果你的系统里有条件分支、循环、Agent 多次调用工具、不同步骤之间需要共享状态LangGraph 是更合适的选择。可以这样理解演进路径固定流程用户问题进来检索生成结束。带条件的流程先判断这个问题是否需要检索不需要就轻量回答。带循环的流程第一次检索结果不够改写查询再检索最多重试两次。带外部行为的流程调用订单查询工具、调用物流接口根据结果决定下一步。后两种情况已经不适合写成一条死板的链更适合用“图”来表达。LangGraph 的核心概念是状态、节点和边。节点是具体步骤边是状态转移状态节点之间的共享数据。它比让 Agent 在纯文本里反复思考要可控得多因为每一步都有一份明确的状态可以记录、可以回溯。如果你的项目只做了线性问答却硬套上 LangGraph 和 Agent 概念面试官很容易判断你是在堆名词。更好的方式是先让 RAG 这条线用 LangChain 跑得干净再让 Agent 的决策循环落到 LangGraph让两者指向同一个客服场景。3.3 框架迭代快不是减分项关键是你的判断和记录遇到 API 升级、依赖冲突、调用报错不要急着觉得“还是自己写最稳”。工程上的合理态度是既能用框架的抽象也能在框架不够灵活时降到原生代码。这个判断过程本身就是项目经验。我一般会在本地写一份简单的实验笔记记录每个版本验证过什么、跳过了什么坑。到时候无论是简历里的技术描述还是面试时的项目复盘这些东西比“我在项目里使用了 LangChain”有力得多。4. 把“能问答”升级为“能干活”Agent 才是智能客服场景的关键4.1 从 Chain 到 Agent系统的决策权发生了变化知识库问答再强也只解决“提问—检索—回答”的问题。但智能客服场景里大量问题不能靠文档回答。比如用户说“我上周买的订单还没发货帮我查一下。”这里面至少涉及几个动作识别用户身份或订单号、调用订单系统接口、把订单状态和物流信息整理成用户能听懂的话。如果订单确实异常还要走售后或转人工。这一类需求已经是 Agent 的应用边界不只是回答问题而是通过调用外部工具完成一个任务闭环。Agent 的最小工作方式是理解目标、决定调用什么工具、执行工具、观察结果、再决定继续操作还是生成最终回答。这里的关键变化是“决策权”。Chain 的路线是写死的Agent 的每一步都可能不同。用户第一次说“查订单”Agent 会去调订单工具用户接着说“那我要退货”Agent 会再走退货政策检索判断是否符合条件。如果还是固定流程这种多轮任务几乎没法覆盖。4.2 一个最小可用闭环以及它必须绑定的护栏做智能客服项目时不需要真的接入公司订单系统。用一组 mock 接口模拟订单查询、退款申请、物流跟踪是更合适的方式既安全又能把 Agent 的流程完整练一遍。一个带护栏的最小 Agent 闭环通常包括工具层把订单查询、物流查询、售后政策查询封装成独立的函数每个函数有清晰入参和返回值。决策层让模型根据用户对话判断调用哪些工具并限制只能调用白名单内的工具。执行与观察层把工具返回结果重新交给模型让模型判断结果是否满足用户问题。兜底层工具失败或模型连续重试次数超过阈值时不再让模型自由发挥而是直接走人工客服转接。权限层Agent 只能查不能改退款的金额上限是多少哪些操作必须人工确认这些不能交给模型自己判断。很多人做 Agent 项目时只实现了“模型能调用函数”这一步以为这就够了。但真实客服里的大多数风险不是在“能不能调用”而是在“调用以后是否越权”“结果是否可信”“失败时是什么表现”。所以接口的工具函数要尽可能小、专用、可审计而不是给模型暴露一个能执行任意代码的万能工具。关键提醒Agent 不是越自由越好。先给 Agent 划定只有几个合法出口再逐步放开比一开始就让它用一堆工具自主操作安全得多。4.3 Agentic RAGAgent 和知识库不是两个孤立模块前面说的都是“知识库问答”和“工具调用”分开。实际更贴近业务的形态是 Agentic RAG让 Agent 自己判断要不要检索、检索几次、要不要改写查询、要不要把多轮对话中的信息补全后再检索。一个典型场景是用户问“退货政策和上次一样吗”这里面有一个指代“上次”如果直接拿整句话去做向量检索效果会很差。正确做法是先让 Agent 结合对话历史把用户问题补全成独立问题比如“退货政策是什么最近有没有变化”再去做检索。Agentic RAG 并不意味着每一步都智能也不意味着应该把大量判断交给模型。它只是告诉你检索计划、查询改写、重试策略这些决策可以做成 Agent 的“工具使用能力”。在项目里可以先从一个固定问题补全模块开始演进到可控的“先判断是否需要检索”模式。4.4 从知识库问答到智能客服的落地路线结合标题里的三个关键词推荐按这个顺序演进而不是一上来就写多 Agent第一版只做知识库问答文档是产品手册和售后政策回答必须带来源。第二版接入 mock 订单接口让系统能处理“查订单”“查物流”这种无法靠文档回答的问题RAG 负责政策依据Agent 负责工具调用。第三版把多个能力分给不同的子 Agent由一个总控角色来调度。每个版本都要有对应的测评集和日志。比如电商售后场景里至少准备几类测试问题能直接从政策文档回答的需要查询订单状态后再回答的需要先查政策再判断能不能退的知识库里没有、应当转人工的。这样系统能力边界才清晰。5. 多 Agent 协作最容易翻车的地方不是模型智商而是状态和协议5.1 值得优先尝试的协作模式主管—工人多 Agent 协作听起来很酷很多人第一反应是“几个模型互相聊天聊出答案”。这种设计在 demo 里可行但到了复杂业务里很快会失控上下文互相污染、错误不断传播、一个 Agent 开始编造消息另一个 Agent 还会继续基于编造的回复继续推理。真正进入业务前我更建议先做“主管—工人”模式。在这种模式里总控 Agent 负责理解用户意图、拆解任务、然后分发给不同子 Agent。子 Agent 不需要互相直接对话它们只和总控通信各自专注自己的职责。一个电商客服场景的职责拆分可以是这样的角色职责主要输入主要输出总控/主管判断意图、分发任务、汇总最终回答用户整段对话与会话状态最终回复或转人工条件知识库问答 Agent在产品手册、售后政策等文档中检索标准化后的用户问题带来源的答案片段订单查询 Agent调用 mock 订单接口得到订单、物流状态用户身份或订单号结构化订单信息人工交接 Agent识别无法回答或高风险请求生成转人工摘要对话摘要、置信度、风险标记转人工工单这样设计的好处是每个子 Agent 的功能可以被单独测试。你可以先只调知识库问答 Agent再单独调订单查询 Agent最后再通过总控把它们串起来而不是一开始就调试所有 Agent 的协作。5.2 共享上下文不等于让 Agent 随便“聊天”多 Agent 协作的难度不在“模型会不会理解”而在“状态有没有被管理好”。比如用户在多轮对话里先说“我是会员”又说“帮我退这个订单”最后问“钱什么时候到账”。知识库问答 Agent、订单 Agent、退款 Agent 都需要某些共享状态比如用户会员等级、订单编号、之前检索到的政策依据。如果这些信息只存在于某个 Agent 的私聊上下文里总控和其他 Agent 拿不到整个系统就会变得迟钝甚至反复追问。更稳的做法是定义一份清晰的会话状态结构里面至少包含用户唯一标识、会话 ID已确认的订单号、商品 ID当前任务阶段比如“确认身份中”“查询订单中”“生成回复中”已经检索到的政策引用是否需要转人工的标志。子 Agent 之间的交互最好通过结构化的输入输出协议完成而不是纯粹靠自然语言。例如订单查询 Agent 接收的不应该是“帮我看看我的快递到哪了”这种自由文本而应该是总控解析出来的{user_id: 10086, need: logistics}。结构化协议带来的好处是容易写测试、容易做异常处理也更容易在心里想清楚每个 Agent 的边界。5.3 先受控编排再加自由协作最后再谈“智能涌现”在多 Agent 场景里我更推崇的是“受控编排优先”的策略。也就是说先把流程画清楚什么条件下走知识库什么条件下走订单工具什么条件下转人工什么条件下启动某种兜底。Agent 可以在节点内部做选择和规划但不要让它自己决定整条流程的所有出口。这样做的理由很简单真实业务系统需要为每一次行为负责。如果一个 Agent 自由地调用了另一个 Agent又导致了错误结果责任链会非常难追。受控编排至少提供了一个可以回溯的调用链谁发起了什么、用了什么工具、得到什么结果、最终怎么回答。面试时能讲清楚这套链路就已经比大多数人强。“人在环路”也不是一句空话。在意图识别置信度低、涉及退款/敏感操作、多轮重试后仍失败这些情况下系统应该主动生成结构化摘要并转人工。这部分如果做成可触发的开关就能既保留 Agent 的自动化价值又不让它在高风险场景里单打独斗。6. 面试级项目不是“做完”的是“能证明”的6.1 用“场景—边界—证据”三层框架验收项目准备简历项目时可以把它当成一个迷你产品来做。我建议用下面这个三层框架自检。第一层是场景。不要写“做了一个知识库问答系统”而要写清楚针对哪类用户、什么业务场景、解决什么痛点。例如面向电商平台售后客服回答用户关于退换货政策、订单状态和售后流程的问题。第二层是边界。这是多数人最缺的部分。你要主动说出它不做什么。比如无法处理超出售后政策范围的复杂纠纷无法查询未登录用户的历史订单知识库未覆盖的问题要转人工Agent 只允许调用白名单内的 mock 接口。第三层是证据。你用什么证明它有效比如准备了一套业务测评集记录了检索命中率在每次切分调整前后的变化写了一组 case 展示什么输入进入了什么分支最终回答带不带引用把一次 Agent 工具调用失败的处理过程沉淀成了日志。哪怕没有跑出多高的分数这组“证据链”本身就说明你不是在照抄。6.2 工程化补全清单如果想让项目比普通教程项目更扎实建议在代码之外补上这些东西配置分离模型名、api key、embedding 模型、切分参数、top_k、温度都不写在业务代码里而放在配置文件中。这样换数据和换模型不需要改代码。日志记录每次用户请求、检索到的文档片段、模型输出、Agent 工具调用结果、异常类型和耗时。这一步能够让你定位 90% 的问题。错误处理模型调用超时的重试、向量数据库连接失败的降级、Agent 工具调用失败的下一步动作。测评集至少准备几十条真实业务问题把“应该能回答”和“应该转人工”两类分开。成本控制记录 token 消耗尤其是 Agent 多轮调用时成本很容易快速上升。安全边界不要把用户敏感信息拼进 Prompt不要允许 Agent 调用有写权限的真正接口用 mock 接口或沙箱环境。这些内容看起来不性感但它们才是项目和其他练习作品的分水岭。真实团队在评估一个候选人时看的往往就是你有没有意识到这些点。6.3 一步一步从入门走到能写进简历如果你现在还是一个只跑过入门教程的状态建议按下面的步骤往下走不要跳先完整跑通一个最小 RAG 流程用 PDF 或网页文档建一个几十页的小知识库。用自己的方式把流程拆开换切分粒度、换 top_k、换一个 Embedding感受结果变化。做一个小测评集把每次改动前和改动后的结果记下来。给 RAG 接入一个 mock 订单查询接口让系统能回答“查订单”类问题。把工具调用升级成多轮可控的 Agent 流程加入失败重试和转人工兜底。再把总控、知识库问答 Agent、订单 Agent 拆开用结构化协议连接起来。写完日志、配置和 README再根据测评集补一轮效果优化。经过这一套你得到的就不只是“简历项目”而是一段完整解决问题的能力闭环。6.4 面试被追问时试着用“取舍证据”回答面试官追问某个参数时你的最佳回答不是“网上都这么配”而是说清楚“我试过什么、对比过什么、为什么留下这个”。比如他问 chunk size你可以这样回答我先用标题和段落结构切然后对长短不一的测试片段分别入库用 30 个容易出现混淆的问题做召回测试对比 hitk最后选择了一个平衡性和稳定性更好的切法同时我也知道它的问题在于某些特别长的表格会被拆散这需要在文档清洗阶段补结构解析。再比如他问“你有没有想过不用 LangChain自己写”你可以诚实回答想过。LangChain 的价值是省了很多胶水代码但它也在快速变化所以我把核心流程写在独立函数里再用框架把模块串起来这样即使框架升级替换成本也是可控的。这套回答方式的核心不是炫技而是展示你具备一个工程人员最基本的素质做选择时有理由做证明时有依据知道自己的方案在什么场景下会失效。结尾我想说一句话RAG、LangChain、Agent 这些词本身不稀缺稀缺的是你围绕它们建立起来的一整套“发现问题—设计实验—验证效果—修复边界”的工作方式。真正能写进简历的从来不是某个框架名而是你亲手设计、亲手评估、出了问题还能定位原因的那套系统。准备这个大模型项目时别急着把三个热点词全塞进一张架构图先让一条知识库问答主线跑出证据链再逐步加上 Agent 和多 Agent 协作你会更清楚哪些选择值得放进简历也更有底气应对下一次追问。