大模型岗位面试有一个几乎绕不开的问题你做过 RAG 相关项目吗?如果你投递的是算法工程、应用开发或大模型平台方向十份面试题里有八份会围绕知识库问答、智能客服、Agent 工具调用展开。很多人不是不会写 Prompt也不是没跑过模型而是缺少一个能讲清楚“检索链路怎么搭、LangChain 怎么编排、Agent 怎么设计、多 Agent 怎么协作”的完整项目。这次要聊的就是一个可以直接写进简历的项目RAG LangChain Agent 全栈实战。项目目标是让面试官能清晰看到你有三个能力——把私有知识库变成可回答问题的问答系统把单轮问答扩展成带工具调用的智能客服以及在复杂任务里让多个 Agent 分工协作。文章会从项目定位开始把整体架构拆成几个模块再串起数据清洗、向量化、检索增强、LangChain 编排、Agent 工具调用、多 Agent 协作、智能客服落地的完整链路最后给出可写进简历的“项目亮点”和一套接口化打包方案。代码统一使用通用部署模板你复制到自己的项目里改路径和密钥即可。1. 核心能力速览能力项说明项目类型大模型应用型项目覆盖 RAG 知识库问答、智能客服、多 Agent 协作主要技术栈LangChain、向量数据库、Embedding 模型、大模型 API、LangGraph / 多 Agent 框架核心功能私有知识库问答、文档语义检索、意图识别、工具调用、多轮会话、多 Agent 协作模型接入方式支持云端大模型 API也可通过 Ollama 等工具接入本地开源模型面向岗位大模型应用开发、RAG 算法工程、Agent 应用开发、Prompt 工程交付形态Python 工程 FastAPI 接口 任务日志可扩展 WebUI是否需要 GPU云端 API 不需要本地部署 Embedding 和小型 LLM 时可使用 CPU效果以实测为准启动方式Python 脚本 uvicorn 服务启动是否支持 API支持可按/chat方式封装问答服务是否支持批量任务支持可对离线问答列表做批处理建议加重试与日志适合读者正在准备大模型相关简历项目的人、RAG 入门到进阶学习者需要说明的是本文不是“零代码一键包”而是一个偏工程化的简历项目方案。它更看重链路完整度与可解释性。2. 项目业务设定与整体架构2.1 业务设定简历项目不建议写“通用 ChatBot”因为没有业务限定就没有深度。我们建议采用下面这种人设非常清晰的设计项目名称企业内部智能客服知识平台用户角色企业员工或终端客户使用场景 1员工输入“年假申请流程是什么”系统检索公司制度文档并给出带引用的回答使用场景 2用户输入“请帮我查一下 4 月报修工单”Agent 调用工单查询工具后端提供答案使用场景 3用户输入“我想投诉网络问题并希望生成一份处理摘要”协作型 Agent 把工单查询、内容摘要、回复起草三个动作拆开执行这套设定让项目同时覆盖了 RAG 和 AgentRAG 负责“制度/文档类问题”Agent 负责“需要工具调用和组合动作的问题”。面试官问到任何一条链路你都能找到对应的业务落点。2.2 系统分层整个项目可以分成五层数据层原始文档包括 PDF、Word、Markdown、网页、问答对等。索引层文档解析、清洗、分块、Embedding 向量化、向量库存储。检索增强层查询改写、多路召回、Top-K、重排 Reranker把最相关片段送到大模型。编排层LangChain 负责构建检索链和工具调用链实现 Prompt 模板、模型调用、结构化输出。智能体与接口层Agent 负责决策调用哪些工具多 Agent 负责分工协作最后由 FastAPI 暴露接口支持业务系统接入。3. 环境准备与技术选型3.1 运行环境清单依赖项建议说明操作系统Windows / macOS / Linux 均可Python 版本3.10 及以上大模型 API任意 OpenAI 兼容接口也可以使用国内各云厂商大模型 API 平台或本地 Ollama 服务Embedding需要中英文同时支持的向量模型可选云端 Embedding也可选本地开源向量模型向量数据库Chroma、FAISS、Milvus、Qdrant 等根据自己的数据规模选择核心库langchain、langchain-community、langchain-openai、fastapi、uvicorn、pydantic依赖安装代码# 建议单独创建虚拟环境 python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate pip install \ langchain \ langchain-community \ langchain-openai \ langchain-text-splitters \ chromadb \ fastapi \ uvicorn \ pydantic # 如果本地要通过 Ollama 使用开源模型 # 先安装 Ollama再拉取模型 # ollama pull qwen2.5:7b提示LangChain 不同版本的 API 略有区别尤其是load_qa_chain、ConversationBufferMemory等组件在新版本中可能有兼容性调整。项目里建议固定版本号例如安装时使用pip freeze requirements.txt锁定现场。3.2 大模型怎么接项目前期建议直接接大模型 API因为业务链路的调试重点是 RAG 和 Agent不需要把时间浪费在显存和本地模型调试上。代码实现如下# llm_client.py from langchain_openai import ChatOpenAI # 说明如果使用云端 API替换 base_url 和 api_key 为你自己的合法服务地址。 # 如果本地部署可以配置为 Ollama 提供的 http://localhost:11434/v1 llm ChatOpenAI( model你的模型名称, base_url你的 API 服务地址, api_key你的服务密钥, temperature0.2, )项目做到中后期后可以用 Ollama 在本地跑一个 7B 量级的开源模型通过 OpenAI 兼容端点把链路整体替换一遍。这样可以在面试里说清楚“我既接过大模型 API也做过本地模型部署”。3.3 LangChain、LangGraph、Agent 的技术选型这里先解决一个很容易被问的问题LangChain 和 LangGraph 有什么区别对比项LangChainLangGraph设计理念面向 Chain把 Prompt、模型、Retriever、Output Parser 串联成流程面向 Graph把 Agent 状态流转建模为状态机适合场景固定链路如“检索 - 拼接 - 生成”动态分支、条件跳转、多 Agent 协作、复杂对话流控制力中高学习成本低较高团队协作Chain 结构清晰适合快速实现状态定义清楚后适合大规模机器人流程选择建议如果你的项目中只有“判断是否为闲聊 - 走知识库 - 生成回答”这种固定流程LangChain 足够如果要让 Agent 自己决定调用多个工具并且多个 Agent 之间互相传递结果建议使用 LangGraph或者使用 LangChain AgentExecutor 先做单 Agent 工具调用再升级到多 Agent 编排。简历上最好写出两者对比也能体现技术深度。4. 模块一RAG 知识库问答链路RAG 是整个项目的底座。它的目标很简单把文档切成小块向量化后存进向量库用户提问时先检索最相关的文档片段再让大模型基于片段回答。4.1 数据准备与清洗推荐准备 300 条以上的真实业务问答覆盖售后服务、员工制度、产品说明三类知识。原始数据可以从 PDF 或 Markdown 文档中抽取。# data_loader.py from langchain_community.document_loaders import DirectoryLoader, TextLoader # 加载 docs 目录下的全部 md 文件 loader DirectoryLoader(./docs, glob**/*.md, loader_clsTextLoader) docs loader.load() # 粗略清洗删除多余空行标准化空白字符 for doc in docs: doc.page_content \n.join( [line.strip() for line in doc.page_content.splitlines() if line.strip()] )PDF 文件可以根据实际效果选择 PyPDFLoader、PyMuPDFLoader 等。文档清洗的核心是保留段落语义同时去掉无意义的页眉页脚和导航文字。4.2 文档切分很多新手项目直接把整篇文档塞给模型或者切得特别碎。切分需要根据文档结构动态调整# splitter.py from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ], ) split_docs text_splitter.split_documents(docs) print(f原始文档数量: {len(docs)}, 切分后片段数量: {len(split_docs)})参数建议chunk_size 300 到 800chunk_overlap 控制在 chunk_size 的 10% 到 20%。过大的块会引入噪声过小的块会让上下文缺失。研发时可以先拿一批真实问题来回测再决定最终切分参数。4.3 Embedding 与向量库向量化阶段可以选用本地小模型也可以选用云端 Embedding API。第一次跑通时建议用本地小模型避免每轮测试都产生 API 费用# embedding_store.py from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 可根据自己的数据情况替换为 bge-small-zh、text2vec 等开源向量模型 embeddings HuggingFaceEmbeddings( model_name你的本地向量模型路径或模型名 ) vector_store Chroma.from_documents( documentssplit_docs, embeddingembeddings, persist_directory./vector_store/chroma_db, ) print(f写入向量库完成向量数量: {vector_store._collection.count()})数据量不大时Chroma 足够好用而且零运维数据量到百万级以上需要迁移到 Milvus 或 Qdrant。4.4 检索增强从相似度搜索到多层召回简历项目不能只写“调用 similarity_search”必须体现检索优化。下面几条属于高频考点查询改写用户问“他什么时候入职的”时用大模型或规则把用户问题先补全为完整问句再接向量检索。多路召回同时使用关键词检索和语义向量检索再把结果合并。Top-K 控制初期设 K4K 太大容易引入干扰片段K 太小可能丢掉关键答案。重排 Reranker第一轮向量检索召回 20 条再交给 Reranker 精排到 4 条。建议把重排结果与引用来源一起送入大模型。一个简洁的实现思路# retriever.py retriever vector_store.as_retriever( search_typemmr, # 最大边界相关减少重复片段 search_kwargs{k: 6} # 实际配置要按测试结果调整 )如果只写一条检索链路项目说服力不够。把“重排”“查询改写”“多路召回”中至少一个点落地项目深度就会明显提升。4.5 RAG 会话链路下面是 RAG 问答的核心代码用 LCEL 描述整个链路# rag_chain.py from langchain.prompts import ChatPromptTemplate from langchain.schema.output_parser import StrOutputParser from langchain.schema.runnable import RunnablePassthrough prompt ChatPromptTemplate.from_messages([ (system, 你是一个企业知识助手只能基于给定的资料回答。 如果资料中没有答案请直接说明“资料中未找到相关内容”不要编造。 回答最后请标注引用来源编号。), (human, 资料\n{context}\n\n问题{question}), ]) def format_docs(docs): return \n\n.join( f[来源 {i1}] {doc.page_content} for i, doc in enumerate(docs) ) rag_chain ( { context: retriever | format_docs, question: RunnablePassthrough(), } | prompt | llm | StrOutputParser() ) answer rag_chain.invoke(公司年假申请流程是什么) print(answer)这里用 RunnablePassthrough 把用户问题同时传给 retriever 和 prompt流程直观也很好解释给面试官。5. 模块二LangChain 编排智能客服流程知识库问答是单轮能力。真实的智能客服必须支持多轮对话、意图识别、安全规则和降级策略。这一节把模块一升级成客服流程。5.1 会话记忆与上下文压缩多轮对话不能把全部历史都堆给模型否则会越聊越慢。常用方案是保留最近 N 轮并用小节缩略“对话摘要”。LangChain 中处理数据部分# conversation_memory.py from langchain.memory import ConversationBufferWindowMemory # 只保留最近 3 轮用户消息与助手回复减少 token 消耗 memory ConversationBufferWindowMemory( k3, return_messagesTrue, )注意这个类在不同 LangChain 版本中存在导入路径调整。比如某些版本需要从langchain.memory导入升级到新版本后可能移入langchain_community.memory。实际使用时先打印一下导入路径不要照抄旧教程后直接开始跑。5.2 意图识别与路由客服场景里可以先做一层意图路由。根据业务常问的方向分类INTENTS { document_qa: 员工制度/产品文档问答, tool_query: 查询工单、订单、账单等系统数据, chat: 闲聊寒暄, complaint: 投诉与负面情绪处理, }工程上落地“轻量路由”有两种办法第一种让大模型按照 JSON 格式输出意图适合业务逻辑复杂、依赖模糊语义的情况。第二种先用关键词规则快速匹配匹配不到再调用大模型判断。这种方案省 token响应速度快。实现示例from langchain.prompts import ChatPromptTemplate from langchain_core.output_parsers import JsonOutputParser route_prompt ChatPromptTemplate.from_messages([ (system, 请判断用户问题属于下面哪个分类只输出 JSON {intent: document_qa} / {intent: tool_query} / {intent: chat} / {intent: complaint}), (human, {user_input}), ]) intent_parser JsonOutputParser() intent_chain route_prompt | llm | intent_parser result intent_chain.invoke({user_input: 我网络断了能帮我查一下我家工单记录吗}) print(result)路由完之后再把不同的 intent 接到不同的子链路上document_qa - RAG QA 链路tool_query - Agent 工具调用链路complaint - 更谨慎的安全回复策略进入投诉模板chat - 闲聊 Prompt不携带业务文档5.3 客服链路稳定性设计真正的客服系统不是模型能不输出就成功而是“答不上来、工程异常、用户情绪失控”都要有兜底。场景策略知识库没有相关内容返回“抱歉资料库暂未收录”并推荐转人工模型输出为空重试一次重试仍为空则返回默认提示用户情绪负面、想投诉不辩论、不解释进入安抚与工单升级模板单次请求超时客户端设置超时阈值服务端开启异步任务引用来源缺失回答中如果出现具体制度细节必须有引用来源编号6. 模块三Agent 工具调用设计与实现6.1 Agent 为什么需要工具RAG 只能回答知识库里有答案的问题。当用户问“请帮我统计这个月报修 3 次以上的设备”时知识库无法回答因为用户的数据在业务系统里。这时必须让 Agent 自己决定调用后端接口。面试时最容易听人讲“我用了 Agent”但问一句“Agent 是怎样调用工具的”答不出来的候选人很多。项目里建议至少实现两个工具查询工单工具根据用户 ID 查询当前待处理工单列表。信息规范化工具把工具返回的数据整理成可读文本。用 LangChain 的tool装饰器注册自定义工具是最常见做法# tools/ticket_tool.py from langchain.tools import tool tool def query_ticket(user_id: str) - str: 查询指定用户的工单记录返回 JSON 字符串。 参数 user_id 是用户唯一编号。 # 这里在企业项目中替换为真实后端接口调用 mock_data [ {ticket_id: T2024001, status: 处理中, content: 办公区网络无法连接}, {ticket_id: T2024002, status: 已完成, content: 邮箱无法登录}, ] return str(mock_data)上面用了模拟数据跑通流程后可以直接替换成请求。6.2 单 Agent 与 ReAct 模式LangChain 的 Agent 默认使用 ReAct 风格先思考Thought再决定行动Action观测结果Observation最后给答案Final Answer。实现示例# agent_assistant.py from langchain.agents import initialize_agent, AgentType tools [query_ticket] agent initialize_agent( toolstools, llmllm, agentAgentType.STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION, verboseTrue, ) resp agent.invoke({input: 帮我查一下用户 10001 的工单记录并总结状态。}) print(resp[output])初次测试时先开verboseTrue可以完整看到 Agent 的思考链路。项目调试完成后应把 verbose 关掉避免接口返回大量中间日志。6.3 Agentic RAGAgent 何时调用知识库、何时调用工具只是把 RAG 和 Agent 分别讲清楚还不够。真正能写进简历的是比“RAG 串接 Agent”更进一步的 Agentic RAG 设计用户提问后先进入一个“决策 Agent”。若问题能由知识库文档覆盖Agent 选择retrieve_knowledge工具触发 RAG 链路。若问题涉及业务系统数据Agent 选择query_ticket、query_order等工具。若两段信息都需要Agent 可以按顺序调用多个工具最后汇总。Agent 工具列表可以理解为“一组能力注册表”。每个工具要写清楚参数、返回值结构和适合场景。工具描述写得越清晰模型选错工具的概率越低。这和“大模型提示词工程”一样都属于 RAG/Agent 落地必须优化的细节。7. 模块四多 Agent 协作的三种落地方式多 Agent 不一定是多个“模型进程”。在工程项目里我们把不同职责的 Agent 视为不同的“角色函数”它们共享同一个大模型但有不同的 Prompt、工具权限和记忆。7.1 主管 / 协作型结构这种结构适合智能客服场景使用“主管 Agent 子 Agent”的方式Supervisor Agent 负责判断任务类型然后把请求分发给下面某个子 Agent 子 Agent 1知识库问答 Agent只挂载检索工具回答制度文档类问题 子 Agent 2业务查询 Agent只挂载订单/工单查询工具负责系统数据类问题 子 Agent 3投诉与安抚 Agent只负责情绪判断与安抚话术不允许自行承诺赔偿每个子 Agent 的工具权限是收敛的。这样能避免一个 Agent 拥有过多权限导致误调用也可以在出问题时更准确定位是哪一轮的分发逻辑出了错。7.2 流水线协作型结构这种结构适合批处理任务例如“生成客户服务摘要”流程编排 Agent - 调用信息检索工具 - 生成摘要 - 审阅 Agent 校验是否有幻觉和缺失 - 输出结构化结果审阅这一步非常关键。多 Agent 协作的价值不仅是“并行”还在于让一个 Agent 生成内容另一个 Agent 负责检查。面试中可以描述成“我在摘要生成后增加了一个 Reviewer Agent它会检查摘要中的设备信息、处理结果是否与工具返回的原始数据一致不一致时自动退回重写。”这一个设计点就能比“两个 Agent 随便聊”有说服力得多。7.3 LangGraph 方案如果继续往深度做可以把流程升级到 LangGraph。你可以用 LangGraph 定义节点router、qa_node、tool_node、memory_node和supervisor再定义状态对象控制流转与条件跳转。面试时可以说明LangChain 倾向于把固定链路串起来适合“顺序执行”LangGraph 倾向于状态机房调度适合“需要条件判断、循环调用和跨 Agent 状态共享”的复杂流程。LangGraph 对团队协作的收益也更明显状态和节点图是显式的后续别人接手时能快速看懂业务流走到哪一步。8. 模块五从脚本到服务——接口 API 与批量任务拆解简历项目只停留在 Notebook 中不行。应至少封装成一个 API 服务体现工程能力。8.1 FastAPI 接口封装这里需要把上面模块串起来。服务路由可以拆成两部分/agent/chat处理在线问答/batch/process处理离线批量任务。from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field app FastAPI(title企业智能客服 API) class ChatRequest(BaseModel): user_id: str question: str session_id: str class ChatResponse(BaseModel): answer: str intent: str sources: list[str] Field(default_factorylist) app.post(/agent/chat, response_modelChatResponse) async def agent_chat(req: ChatRequest): try: # 实际代码中调用第 5 节的意图路由和第 6 节的 Agent 编排 result run_customer_agent( user_idreq.user_id, questionreq.question, session_idreq.session_id, ) return result except Exception as e: # 统一异常兜底避免接口直接抛 500 raise HTTPException(status_code500, detailstr(e)) app.get(/healthz) async def health(): return {status: ok}根据 API 服务启动uvicorn api_server:app --host 0.0.0.0 --port 8000接口文档会自动生成在/docs浏览器访问后可以看到 OpenAPI 调试页面。这个能力可以直接截图放进简历作品集。8.2 接口调用测试服务启动后再打开一个终端调用curl --request POST \ --url http://127.0.0.1:8000/agent/chat \ --header Content-Type: application/json \ --data { user_id: 10001, question: 年假申请需要提前几天, session_id: session_001 }Python 调用示例import requests resp requests.post( http://127.0.0.1:8000/agent/chat, json{ user_id: 10001, question: 帮我查一下我的报修记录, session_id: session_002, }, timeout60, ) print(resp.json())观察返回结果回答内容是否正确、是否带上sources来源列表、是否成功识别了意图。如果 Response 里intent识别错了优先检查路由 Prompt 是否定义清楚而不是直接改模型。8.3 批量任务设计企业场景中有大量“给历史记录补一份摘要”的离线需求。批量任务不要直接在 web 请求里做否则会让接口长时间阻塞。建议把批处理拆成一个独立脚本再输入一个待处理列表# batch_runner.py import json import time from typing import Iterator def load_batch_inputs(path: str): with open(path, r, encodingutf-8) as f: for line in f: yield json.loads(line) def run_batch(input_file: str, output_file: str, concurrency: int 4): results [] session requests.Session() for item in load_batch_inputs(input_file): # 真实项目可用 ThreadPoolExecutor 或 asyncio 提升并发 resp session.post( http://127.0.0.1:8000/agent/chat, jsonitem, timeout60, ) if resp.status_code 200: results.append(resp.json()) else: results.append({item: item, error: resp.text}) time.sleep(0.1) # 防止把本地服务打满 with open(output_file, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: run_batch(batch_input.jsonl, batch_output.json)批量任务必须配套以下三点每个输入都有唯一session_id或task_id日志能回溯到具体问题。请求失败后不要直接丢弃而是记录错误并将任务放入重试队列。建议给 API 服务加max_requests或并发数限制避免批量任务把服务拖挂。9. 资源占用与性能观察方法简历项目部署时会涉及 CPU、内存、磁盘占用。虽然不用像本地大模型工具那样严格关注显存但“服务优化”思路仍然需要去观察。9.1 观察哪些指标指标观察方式异常信号单次回答耗时接口响应时间、调用日志耗时超过 10 秒说明链路太长Token 消耗打印每次调用前的 Prompt 和模型返回 usage历史消息与文档片段过大导致成本飙升向量库内存观察 Python 进程内存占用向量库加载数据越多内存占用越高并发请求使用ab或locust压测接口并发高时错误率上升9.2 如何缩短响应时间结合链路组件进行优化缩短“文档片段长度”比如 500 字符调整为 300 字符减少生成时间历史消息只保留最近 2 到 3 轮避免长对话后 token 变多Embedding 模型本地化后把向量一次性预加载到内存中减少查询时磁盘加载向量检索优先做“粗召回”再做精排避免重排阶段处理太多片段少量请求缓存相同或相近问题的回答结果业务数据缓存失效时间要单独设计。9.3 如果要本地部署大模型这一阶段可选。如果你想验证本地模型部署能力可以使用 Ollama 拉取 7B 量级的开源模型然后把 ChatOpenAI 的base_url指向本机 Ollama 地址。注意本地模型的推理速度和显存占用以你实际机器为准。如果机器显存不足可以先使用量化版本或改用云端 API 训练链路。简历里建议先写清楚“支持 API 切换”在此基础上再补一句“已用本地模型完成过兼容性验证”。10. 简历项目量化与面试复盘10.1 简历里如何写项目亮点不要只写“实现了一个问答机器人”。多写量化结论构建了 300 条业务问答数据覆盖 3 类知识主题回答准确率经过 20 轮样例回归测试。使用 LangChain LCEL 构建 RAG 链路通过检索重排和查询改写将 Top-1 命中率从提升前水平优化到稳定可用的状态。具体数字需要以你的记录为准。使用 FastAPI 封装 API支持在线问答与批量任务批量任务在 200 条记录场景下支持错误重试与日志回溯。实现主管 Agent 子 Agent 协作架构将意图路由准确率和工具调用成功率作为两个核心质量指标。在 RAG 链路中增加引用来源回答可解释性明显提升。这里要注意简历中的“提升 X%”必须来自你实际记录的测试结果。把脚本写好后花半天跑 20 到 50 个用例把通过率记录成表格再同步进简历。10.2 高频面试问题整理RAG 方向高频问题RAG 和微调的区别是什么什么时候用 RAGEmbedding 模型如何选为什么切分参数会显著影响效果向量检索只能返回 Top-KK 太大或 K 太小分别有什么问题“精准 RAG”应该从哪几个环节入手数据中日期、人名、订单号这类实体如何检索如何评测 RAG 效果有哪些指标Agent 方向高频问题Agent 的工具描述为什么重要ReAct 模式的工作过程是怎样的多个 Agent 协作时如何避免陷入重复对话工具调用参数错误时如何纠正智能客服怎么避免幻觉答案LangChain 和 LangGraph 的区别是什么什么场景下一方更合适10.3 最终交付物建议简历项目最好配套下面 5 类交付物代码仓库按data/、src/、tests/、scripts/分层。演示视频录制一条“上传文档 - 建库 - 问答 - 调用工具 - 多 Agent 协作”的完整流程控制在 5 分钟内。效果截图至少包含一个带引用来源的 RAG 回答和一个带结构化输出的 Agent 调用结果。测试用例集面试时可以说“我准备了 30 个回归测试用例用于验证系统没有跑偏”。README 文档写清运行环境、安装命令、目录结构和常见问题。11. 常见问题与排查方法问题现象可能原因排查方式解决方案导入 langchain 报错库版本冲突或导入路径差异查看错误堆栈检查导入包路径固定版本或改用langchain_community/langchain_openai导入RAG 回答与知识库无关切分块太大、Retriever 召回噪声打印retriever.invoke()的原始结果调小 chunk_size、增加重排、调整 Top-KAPI 报认证失败Key 地址配置错误检查环境变量是否生效确认 API 服务地址、模型名和密钥是否一致Agent 没有调用工具工具描述不清晰开启 verboseTrue 观察思考过程重写工具描述列出参数示例和调用条件向量库重新写入后结果未更新持久化目录仍使用旧数据检查向量库 collection 数量清空持久化目录后重新建库批量任务大量失败未设限流或接口超时查看日志中的错误码增加重试队列并限制并发数接口响应速度慢历史消息过长或检索片段过多记录每次 LLM 调用 token 数压缩历史消息、减少上下文片段回答出现幻觉检索片段中无答案且未约束模型检查引用来源是否为空提示词明确要求知识库无答案时直接说明如果调试时发现某一个问题反复出现建议先做一个最小化复现实验。例如只保留 10 条文档、1 个会话、固定 Prompt观察每条调用链路中的输入输出是否正常再逐步恢复参数。12. 总结与下一步这个项目最值得尝试的点在于它没有把“RAG”和“Agent”当两个孤立功能做而是把它们放在同一个智能客服业务里。知识库问答负责静态知识工具调用负责动态数据多 Agent 协作负责把“查数据、生成摘要、核对来源”串成一个完整流程。你只要把链路完整跑通一遍面试中面对大模型岗位的核心问题会更有底气。最先应该验证的功能是 RAG 基础链路准备 20 条问答数据上传到本地 Docs 目录确认“检索到的片段”和“最终回答”都令人满意。调试好后再往链路里加入 Agent 工具调用最后才扩展多 Agent 协作。最容易踩的坑有两个一个是检索结果不相关却急着调大模型一个是 Agent 经常选错工具却找不到原因。遇到这两种情况先打开日志查看进入 Prompt 的内容序列再去调提示词和工具描述。后续可以继续扩展的方向有三个一是从 LangChain Chain 升级到 LangGraph把多 Agent 协作写成显式的状态机二是增加带模型的 RAG 评测脚本输出召回率和忠实度报告三是把向量库替换成 Milvus测试百万级文档场景下的性能表现。项目做到这里就不再是“练手 Demo”了。建议把代码仓库、接口测试记录、效果截图和面试问题清单一起整理好作为简历项目备用。