最近在帮团队做技术面试发现一个很有意思的现象很多候选人简历上写着“熟悉RAG”、“有Agent项目经验”、“用过LangChain”但一追问细节要么是调了几个API要么是跟着教程跑通了Demo真正能把技术选型、架构设计、落地难点和长期维护说清楚的人少之又少。这背后反映的其实是当前AI应用开发的一个普遍困境工具和框架的更新速度太快大家忙着追新概念、跑新Demo却很少停下来思考这些技术组合在一起到底解决了什么本质问题从“跑通”到“能用”再到“好用且稳定”中间到底隔着多少道坎就拿“RAG Agent LangChain LangGraph DeepSeek”这个组合来说它几乎成了今年AI应用开发的“标配”技术栈。但如果你只是把它们当作一个个孤立的工具来学习背下几个API调用和概念定义那面试时大概率会露怯。真正的价值在于理解它们如何协同工作如何将一个模糊的“智能问答”需求拆解成可设计、可开发、可调试、可运维的工程系统。这篇文章我们不打算罗列300道面试题和答案——那只是信息的堆砌。我想和你聊聊当面试官听到你提到这些技术时他真正想考察的是什么。我会用一个完整的“从需求到上线”的视角帮你把RAG、Agent、LangChain、LangGraph、DeepSeek这些点串联成线再编织成一张应对复杂场景的网。看完之后你不仅能回答“是什么”更能清晰地阐述“为什么这么选”以及“落地时要注意什么”。1. 先拆解需求你的场景真的需要“RAGAgent”全家桶吗很多项目失败的第一步不是技术不行而是技术选型与真实需求错配。一上来就想着用最全的架构往往会让简单问题复杂化。1.1 回归本质RAG 和 Agent 各自解决什么问题RAG的核心是“知识增强”。它要解决的问题是大模型不知道你的私有数据。通过“检索-增强-生成”的流程将外部知识库文档、数据库、网页中的相关信息作为上下文喂给模型从而生成更准确、更相关的回答。它的价值在于打破模型的知识边界。关键判断点如果你的需求是“基于固定文档的精准问答”、“客服知识库查询”、“代码库解读”那么一个设计良好的RAG系统通常是首选。新手误区认为RAG就是“向量数据库文本切分”。实际上检索质量召回率、准确率、文本切分策略chunk大小、重叠、embedding模型的选择、以及重排序re-ranking环节才是决定RAG效果上限的关键。Agent的核心是“任务拆解与工具调用”。它要解决的问题是大模型不擅长执行具体动作比如查询数据库、调用API、写文件。Agent通过规划、思考、调用工具、观察结果、再规划的方式将一个复杂目标分解为一系列可执行的步骤。它的价值在于扩展模型的能力边界。关键判断点如果你的需求是“自动完成多步骤工作流”如分析数据并生成报告、预订会议并发送邮件、监控系统状态并执行修复、或者需要与外部系统搜索引擎、数据库、业务API动态交互那么你需要考虑Agent。新手误区认为Agent就是“让模型自己写代码去执行一切”。实际上可靠Agent系统的核心在于工具的设计是否完备、安全、易用和执行流的控制如何避免无限循环、如何处理工具调用失败。1.2 组合使用什么时候需要“RAG Agent”当你的需求同时涉及“需要外部知识”和“需要执行复杂动作”时这个组合的威力就显现了。一个经典场景技术客服机器人用户提问“我们部署在K8s上的服务A日志里出现了‘Connection timeout’错误如何排查”RAG工作Agent首先调用“知识检索工具”该工具背后是一个RAG系统从内部知识库故障处理手册、技术文档中检索关于“Connection timeout”和“服务A”的相关解决方案。Agent规划Agent分析检索到的知识并规划下一步动作。知识可能建议“检查网络策略”和“查看服务依赖状态”。工具执行Agent调用“检查K8s网络策略工具”和“查询服务状态工具”这些是连接真实K8s API的工具获取实时信息。生成回答Agent综合静态知识RAG提供和动态状态工具提供生成具体的、可操作的排查步骤。面试官在这里想听到的不是你背出了定义而是你能清晰地描述一个符合该模式的实际业务场景并说明RAG和Agent在其中扮演的不同角色以及它们是如何协作的。1.3 选型清单LangChain 还是 LangGraphDeepSeek 怎么放进去这是具体技术栈的选择取决于你对灵活性和可控性的权衡。维度LangChainLangGraph核心范式链Chain和代理Agent。将组件像积木一样连接成线性的或多分支的工作流。图Graph和状态机StateGraph。显式地定义节点Node和边Edge构建带状态循环的复杂、有向工作流。适用场景快速构建相对线性的流程如简单的RAG链、顺序执行的任务。其Agent框架如ReAct已经能处理很多问题。构建有复杂循环、状态依赖、多路分支的Agent系统。例如一个需要反复检查条件、循环执行直到满足要求的自治Agent。关键区别抽象程度高开发快但复杂流程的控制流可能隐藏在链的逻辑中不够直观。控制流显式化通过图结构一目了然调试性更强特别适合实现长期记忆通过状态持久化和循环逻辑。类比像编写一个脚本定义了主要的函数调用顺序。像绘制一张流程图或设计一个有限状态机明确所有可能的状态跳转。关于DeepSeek它是一个强大的开源大模型。在技术栈中它通常扮演“大脑”角色。在RAG中它是最终的“生成器Generator”。在Agent中它是“规划器Planner”和“决策器”决定下一步调用哪个工具。关键考量你需要决定是使用DeepSeek的API服务还是本地部署模型。这涉及到成本、延迟、数据隐私和网络依赖的权衡。面试常考点如果选择本地部署你需要考虑硬件资源GPU内存、推理速度优化如vLLM, llama.cpp以及模型版本管理。一个简单的决策路径需求是静态知识问答 - 优先实现一个稳健的RAGLangChain的链足以构建。需求是动态任务自动化 - 评估使用LangChain的Agent框架。需求极度复杂有显著的状态循环和分支 - 考虑使用LangGraph进行更工程化的控制流设计。对流程可视化和调试有很高要求 -LangGraph Studio是一个加分项。追求高性价比和开源可控 -DeepSeek是一个优秀的模型选择需规划好部署方式。2. 构建基石设计一个“可用”的RAG系统远不止向量检索很多教程止步于把文本切成块存入向量数据库然后查询。但一个生产可用的RAG需要一套完整的工程化考量。2.1 文本处理流水线Chunking 的学问文本切分是RAG的“第一公里”切不好后面再强的模型也无力回天。固定大小切分最简单但可能把完整语义如一个问题的答案切断。基于分隔符切分如段落、标题更符合文档结构但块大小可能不均。语义切分使用模型或算法在语义边界处切分。这是高级做法成本也更高。重叠Overlap在块之间保留一部分重叠文本有助于模型获取跨越切分边界的上下文。重叠量需要调试太少没用太多增加冗余和成本。实操建议不要盲目选择。用小批量文档测试不同切分策略如256/512字符固定块按段落切分用一些典型问题查询直观感受哪种策略召回的关键信息更完整。2.2 检索环节向量搜索不是唯一答案Embedding模型选择至关重要。通用模型如text-embedding-3-small不错但在垂直领域如法律、医疗领域微调过的Embedding模型效果可能显著提升。必须评估。混合检索Hybrid Search结合稠密检索向量搜索和稀疏检索如BM25关键词搜索。向量搜索擅长语义相似BM25擅长精确词匹配。两者结合可以互相弥补短板提高召回率。这是生产级RAG的常见配置。重排序Re-ranking从检索到的Top K个结果如20个中用一个更精细的通常是交叉编码器模型重新排序选出最相关的Top N个如3个送入大模型生成。这能显著提升最终答案的准确性但会增加延迟和成本。面试展示点你可以说“在我们的项目中为了平衡效果和效率采用了‘BM25 向量搜索’的混合检索召回Top 10片段再用一个轻量级重排序模型选出Top 3最终喂给DeepSeek生成答案。这个方案比单纯用向量搜索在业务指标上提升了约15%。”2.3 生成与提示工程告诉模型“如何利用上下文”检索到相关片段后如何组织提示词Prompt同样关键。# 一个基础的RAG提示词模板示例 RAG_PROMPT_TEMPLATE 你是一个专业的助手请根据以下提供的上下文信息来回答问题。 如果上下文信息不足以回答问题请直接说“根据现有信息无法回答”不要编造信息。 上下文信息 {context} 问题{question} 请根据上下文提供准确的答案 进阶技巧元数据过滤在存储时为每个文本块添加元数据如来源文件、章节、日期。检索时可以先根据用户问题中的条件如“请参考最新版手册”过滤元数据再进行向量搜索能极大提升精度。引用溯源要求模型在答案中注明引用的来源如【文档1第3页】这对知识库应用至关重要。这需要在提示词中明确要求并在输出解析时处理。2.4 评估与迭代没有评估就没有优化这是区分“玩具”和“产品”的关键。如何知道你的RAG系统好不好人工评估黄金标准但成本高。可以制定评分卡相关性、准确性、完整性、流畅性。自动评估检索评估计算召回率RecallK、命中率Hit Rate。生成评估使用LLM本身作为裁判LLM-as-a-judge给定问题、上下文和答案让另一个LLM从多个维度评分。也可以使用基于嵌入的评估如答案与参考答案的语义相似度。核心闭环建立评估数据集 - 运行RAG系统 - 评估效果 - 分析bad cases是检索没找到还是生成没利用好- 针对性优化调整切分、改进检索、优化提示- 再次评估。3. 赋予行动力设计一个“可靠”的Agent系统Agent的魅力在于自主性但危险也在于自主性。一个不受控的Agent可能会陷入死循环、执行错误操作或产生高昂成本。3.1 工具Tools设计能力、安全与边界工具是Agent的手和脚。设计良好的工具集是Agent成功的基石。原子性每个工具应只完成一件明确、原子性的任务。例如“查询用户订单”是一个工具“取消订单”是另一个工具。避免设计“处理客户请求”这种巨无霸工具。描述清晰工具的名称和描述必须极其精准因为Agent完全依赖这些文本来决定是否以及如何调用它。描述应包含工具的目的、输入参数格式和输出示例。安全性权限控制工具背后可能是数据库或API。必须实施严格的权限校验Agent的调用上下文应带有用户身份工具内部需验证该用户是否有权执行此操作。输入验证与清理对所有输入参数进行严格的类型、范围和恶意代码检查。副作用与确认对于具有“写”操作或不可逆副作用的工具如发送邮件、删除数据可以考虑设计“两阶段提交”或要求Agent在调用前必须明确获得用户确认通过对话。错误处理工具必须能优雅地处理失败网络超时、API限流、数据不存在并返回结构化的错误信息以便Agent能理解并采取下一步行动如重试、换一种方式、向用户报告失败。3.2 控制流与规划从 ReAct 到 LangGraphReAct模式这是最经典的Agent推理框架。“思考Reason”下一步做什么“行动Act”调用工具“观察Observe”结果然后循环。LangChain的标准Agent多基于此模式。它适合步骤不多、逻辑相对直接的任务。当ReAct不够时如果任务需要长期记忆记住之前多轮交互的上下文、复杂循环例如“持续监控某个指标直到它低于阈值”、或者明确的状态分支根据工具返回结果的不同走向完全不同的处理分支ReAct的线性“思考-行动”循环就显得力不从心。引入LangGraphLangGraph允许你将Agent的工作流定义为一个有状态图。节点Nodes可以是调用LLM进行规划、执行一个工具、进行条件判断等。边Edges定义节点之间的流转条件。可以是“总是执行”也可以是基于状态的“条件边”if-else。状态State一个贯穿整个图执行过程的共享字典可以存储用户输入、历史对话、中间结果、工具执行记录等。这实现了长期记忆。循环Cycles通过将边指向之前的节点可以轻松实现循环逻辑直到满足某个退出条件。示例一个带审核的自动化流程LangGraph思路plan_node: LLM分析需求生成任务计划存入状态。execute_node: 根据计划顺序调用一系列工具执行结果存入状态。review_node: LLM检查执行结果是否完备、正确。条件边如果review通过流向end_node如果不通过流回plan_node或execute_node进行修正。这种显式的图结构让复杂的、带状态的工作流变得可设计、可可视化、可调试。3.3 记忆Memory管理记住过去才能面向未来Agent的记忆分为短期和长期。短期记忆/对话记忆通常指当前会话的对话历史。LangChain/LangGraph提供了多种内存后端如缓冲区、摘要式。长期记忆指跨会话、需要持久化存储的信息。这通常需要结合外部存储数据库。实现方式可以将重要的交互摘要、用户偏好、任务执行结果等通过工具调用写入数据库。下次会话时再通过检索工具可以是一个小型RAG读入上下文。LangGraph的优势其持久化状态Persisted State机制可以很方便地将整个Agent的运行状态图的状态保存到数据库实现“暂停”和“恢复”这对于运行时间极长的任务非常有用。4. 从开发到部署工程化与运维的实战考量让一个Demo在本地跑起来和让一个系统在线上稳定服务是两回事。4.1 开发流程与调试快速原型利用LangChain/LangGraph的组件化和大量集成快速搭建概念验证POC。此时重点是验证核心逻辑是否跑通。调试与可观测性日志在关键节点工具调用前后、LLM调用前后、状态变更时打上结构化日志。记录输入、输出、耗时、Token使用量。追踪Tracing使用LangSmith等工具可视化整个链或图的执行过程查看每一步的输入输出这是调试复杂Agent的利器。成本监控记录每次LLM调用的模型、Token数估算成本避免意外开销。4.2 性能、成本与稳定性延迟优化RAG端优化检索速度向量索引选择、缓存、考虑异步处理。LLM端对于DeepSeek如果是API网络延迟是主要因素如果是本地部署推理优化量化、GPU推理引擎是关键。Agent端避免不必要的LLM调用。有时可以用更简单的规则或小模型代替大模型做决策。成本控制缓存对常见的、结果不变的查询如某些知识库问答进行结果缓存。限流与降级为API设置速率限制。在高峰时段可以为非关键任务切换到更小、更快的模型。预算告警设置每日/每周的Token消耗预算和告警。稳定性错误重试对于暂时的网络错误或API限流实现带退避策略的重试机制。超时控制为LLM调用和工具调用设置严格的超时时间避免线程阻塞。看门狗Watchdog对于长时间运行的Agent任务需要有机制监控其状态防止死循环。4.3 部署与监控部署模式可以将整个系统RAG检索服务、Agent推理服务打包为容器Docker使用K8s或云服务进行部署和扩缩容。API设计对外提供清晰的API接口。对于Agent可能是异步任务接口立即返回一个任务ID客户端再轮询结果。监控指标业务指标问答准确率、用户满意度、任务完成率。系统指标请求量、响应延迟、错误率、Token消耗。Agent特定指标工具调用成功率、平均任务步骤数、循环次数分布。反馈闭环建立用户反馈渠道如“回答是否有用”按钮。收集bad cases用于持续优化RAG和Agent。5. 面试不是背题是展现你的系统思维回到开头的问题。面试官问你RAG、Agent、LangChain他期待的答案层次应该是概念理解层能清晰说出它们是什么解决什么问题。这是基础必须过关技术细节层能深入一两个关键点比如RAG的混合检索与重排序Agent的工具设计与安全考量。这能证明你不仅用过还思考过架构设计层能结合一个具体场景比如内部知识库客服自动化巡检阐述如何将这些技术组合成一个系统并说明组件间的数据流和职责划分。这展示你的设计能力工程实践层能讨论在落地过程中遇到的真实挑战如chunking策略调优、Agent的稳定性保障、成本控制以及你是如何解决或思考的。这证明你有实战经验演进思考层能谈谈对这些技术未来发展的看法或者当前方案的局限性以及可能的改进方向。这体现你的学习能力和前瞻性所以与其焦虑地背诵300个孤立的知识点不如深入理解一两个核心项目用上面的层次去拆解它、阐述它。当你能够把一个技术的“为什么用”、“怎么用得好”、“哪里容易出问题”讲得明明白白时通过率自然就上去了。真正的准备是建立属于自己的、有深度的认知框架而不是拥有一本看似全面的答案之书。