打开一份“大模型应用开发”方向的岗位 JD翻到任职要求那栏高频出现的词通常是这几个RAG、LangChain、Agent。这三个词不是并列的三个工具而是一条能串起完整业务闭环的工程链路知识库问答解决“模型怎么回答私有信息”智能客服解决“多轮对话怎么接入业务”多Agent协作解决“复杂任务怎么拆给多个模型角色去干”。这次要聊的项目方向就很明确用 RAG LangChain Agent 做一个可用在简历里的“企业知识库智能客服与多Agent协作平台”。它不是单个Demo而是三个递进模块能覆盖文档解析、向量检索、提示词工程、对话记忆、工具调用、流程编排、API 服务化、批量评测和面试考核提问。这篇内容会把整体设计、环境准备、核心实现、简历写法和面试应答一次讲完。先给一个直接判断这个项目适合已经有 Python 基础、正在冲刺大模型应用开发岗位的读者。你不需要从零精通大模型原理但需要能说清楚“检索链路怎么搭”“多轮会话怎么管”“Agent之间的流程怎么编排”。本文不提供伪造测试数据所有效果数字都需要你搭完项目后在自己的数据集上重跑但代码骨架、模块划分、评测口径和简历表达可以直接复用。1. 核心能力速览模块解决什么问题涉及的核心技术简历展示能力RAG 知识库问答让大模型回答企业内部文档、PDF、网页中的私有知识文档解析、文本切分、向量检索、Embedding、重排、生成检索方案设计能力、知识库调优能力智能客服把问答从“单轮检索”升级成“业务对话”多轮记忆、意图识别、会话管理、工具调用、引用溯源业务场景建模、RAG与对话系统结合能力多 Agent 协作复杂任务拆解、多角色协同、人工兜底LangChain Agent、LangGraph 状态流、角色规划流程编排能力、复杂系统设计能力合适的部署形态有两种在线模型服务和本地模型服务。在线方案适合快速跑通业务闭环本地部署方案适合数据敏感场景也方便讲清楚模型加载、推理服务和显存观察。无论哪种方案项目代码结构是同一套。从项目阶段看这套东西可以分成三个阶段先做检索问答再做带记忆和工具的客服最后再上多Agent编排。面试官问起来时你的回答不是“我调了一个接口”而是“我设计了一条从文档解析到用户可见答案的完整链路并且知道每一层怎么调优”。2. RAGLangChainAgent 为什么是简历必选项2.1 JD 高频要求与项目落点对应关系很多读者纠结一个问题我到底该把时间花在微调大模型还是做 RAG/Agent从大模型应用岗位的常见要求看微调往往是加分项但 RAG、LangChain、Agent 更接近日常开发工作。JD 常见描述需要你具备的能力在项目里的落点熟悉 RAG 流程、有知识库经验文档切分、向量检索、召回质量调优文档加载器、索引构建、检索引擎、RAG测评熟悉 LangChain 等开发框架用框架编排模型调用、链式逻辑LCEL 链路、检索链、工具链、会话链有 Agent 开发经验让模型根据任务调用工具并循环验证Tool calling、AgentExecutor、LangGraph状态机具备接口开发能力把模型能力封装成服务FastAPI 接口、批量任务脚本、结果日志把这个对应关系想清楚你就知道简历上真正要写的不是“熟悉大模型”而是“使用 LangChain 完成过 RAG 知识库问答与多Agent智能客服平台”。2.2 全栈项目总体架构从系统分层看这个项目可以拆成四层用户交互层Web 页面、接口调用、批量导入问题 应用编排层LangChain 链、Agent 循环、会话记忆、工具路由 模型能力层Chat 模型、Embedding 模型、ReRank 模型 数据存储层原始文档、切分片段、向量索引、对话历史、评测结果这个架构不需要做成前后端分离的大型系统重点是“链路完整”。面试官关心的是一条用户问题进来之后经过哪些模块又是如何返回答案的。2.3 技术选型LangChain、LangGraph、向量库与模型LangChain 的价值在于把“模型调用、提示词模板、文档加载、向量存储、工具注册”统一成可组合的组件。对做简历项目而言它帮你省掉大量胶水代码也能让你接触到 LCEL、RunnableWithMessageHistory 这些面试常问的实现方式。LangGraph 则适合描述更复杂的流程。LangChain 更适合“顺序链”LangGraph 支持带分支、循环和人工审批的状态图。当你的客服系统出现多个角色、需要条件分支或人工审核时LangGraph 的优势就很明显。面试被问“LangChain 和 LangGraph 的区别”时答案不是谁取代谁而是“顺序编排用 LangChain状态机/多Agent协作用 LangGraph”。向量库可以选 Chroma 这类本地进程内方案起步简单不需要启动额外服务。真实项目中也常使用 Milvus/PGVector 等方案但简历项目只要说清“向量的写入、检索、topK 调参”即可。Embedding 模型不是非用某个厂商不可。一种做法是调用云厂商 Embedding 接口另一种是从模型仓库下载开源 Embedding 模型在本地运行。文档数据如果涉及企业隐私优先选择本地部署。模型下载与调用需要遵守对应来源的许可证。大模型本身可以分两套配置开发环境用兼容 OpenAI 协议的接口快速验证对隐私要求高时切换为本地大模型服务。这样你的代码不会绑定某一家的 SDK面试介绍时也更灵活。3. 环境准备与基础依赖3.1 环境清单建议按如下条件准备开发环境项目建议操作系统Windows / Linux / macOS 均可涉及本地模型时优先 LinuxPython3.10 及以上依赖管理venv 或 conda 虚拟环境模型接口一个可用于测试的大模型 API或本地模型推理服务文档解析项目中准备若干 PDF、Markdown、TXT 样例向量库先使用本地文件型向量库避免额外维护成本API 服务FastAPI Uvicorn性能观察nvidia-smi或任务管理器/活动监视器这里属于通用建议不同版本框架对 Python 版本要求不同安装时以官方文档为准。尽量不要直接在一个已有 TensorFlow/PyTorch 环境中安装容易造成版本冲突。3.2 创建项目目录mkdir rag-langchain-agent cd rag-langchain-agent # 创建虚拟环境 python -m venv .venv # Windows .venv\Scripts\activate # Linux/macOS source .venv/bin/activate项目目录建议这样组织rag-langchain-agent/ ├── data/ # 原始文档 ├── docs/ # 项目说明文档 ├── app/ # 主代码 │ ├── rag/ # RAG 检索相关 │ ├── chatbot/ # 客服对话相关 │ ├── agent/ # Agent 多角色相关 │ └── api/ # FastAPI 服务 ├── tests/ # 评测脚本与测试集 └── .env # 环境变量配置3.3 安装基础依赖以下是常见依赖示例。LangChain 生态版本更新较快类名和方法应以你安装的版本 API 文档为准。pip install langchain langchain-core langchain-openai langchain-community chromadb fastapi uvicorn python-dotenv pydantic # 文档解析相关按需安装 pip install pypdf pymupdf markdown # 本地部署模型时需要做额外配置具体看模型服务说明3.4 配置模型服务如果你的在线模型服务提供兼容 OpenAI 协议的接口可以用环境变量统一配置# .env LLM_API_KEYyour_api_key LLM_BASE_URLhttps://your-model-service.example.com/v1 LLM_MODEL_NAMEyour-model-name EMBEDDING_API_KEYyour_api_key EMBEDDING_BASE_URLhttps://your-model-service.example.com/v1 EMBEDDING_MODEL_NAMEyour-embedding-model-name本地模型方案通常是先用本地推理框架加载模型并暴露一个本地 HTTP 服务之后把LLM_BASE_URL指向本机地址。代码层面只面向 BaseURL 和 APIKey不写死具体厂商。4. RAG 知识库问答从文档解析到精准检索4.1 RAG 基础链路RAG 一般分索引和查询两个阶段。索引阶段要做文档加载、文本切分、Embedding 向量化、向量写入查询阶段要做用户问题向量化、相似度检索、拼接上下文、交给大模型生成。先写一个最小版 RAG 链路代码里的类名需要根据实际 LangChain 版本做调整。from langchain_community.document_loaders import PyPDFLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain_openai import ChatOpenAI # 1. 加载文档。实际项目中需要按文件类型选择 loader图片型PDF还需要OCR loader PyPDFLoader(data/employee_handbook.pdf) documents loader.load() # 2. 切分文本。chunk_size 和 chunk_overlap 直接影响召回质量 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap100, separators[\n\n, \n, 。, , , , ] ) chunks text_splitter.split_documents(documents) # 3. 向量化并写入向量库 embedding OpenAIEmbeddings(modelyour-embedding-model) vectorstore Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db ) # 4. 构建检索器。k 值先设 4再按准确率调优 retriever vectorstore.as_retriever(search_kwargs{k: 4})检索器准备好后需要拼一个问答链from langchain_core.prompts import ChatPromptTemplate prompt ChatPromptTemplate.from_messages([ (system, 你是一个知识库助手。只能根据提供的上下文回答不要编造。 如果上下文不足以回答问题请明确说不知道。), (human, 上下文\n{context}\n\n问题{question}) ]) def format_docs(docs): return \n\n.join([d.page_content for d in docs])再把检索、提示词和模型串起来。方式不同但核心是“检索出的文档片段必须作为上下文传给模型”。为了让答案可追溯建议在返回结果里保留引用来源from operator import itemgetter from langchain.schema.output_parser import StrOutputParser from langchain.schema.runnable import RunnablePassthrough chat_model ChatOpenAI(modelyour-chat-model, temperature0.2) rag_chain ( { context: itemgetter(question) | retriever | format_docs, question: itemgetter(question), } | prompt | chat_model | StrOutputParser() )4.2 RAG 知识库指标怎么理解很多读者不知道自己做出来的 RAG 系统到底好不好。这里要区分两类指标。第一类看检索质量。常见的是召回率、精确率。比如一个知识库有 100 个标准问答对你预期每个问题能召回包含正确答案的文档片段。如果 100 个问题中只有 70 个召回了正确片段命中率就是 70%。如果召回的 400 个片段里只有 120 个真正相关那么精确率偏低说明需要调小 topK 或换更强的 embedding/重排模型。第二类看端到端答案质量。常见指标包括忠实性、答案相关性和上下文相关性。忠实性衡量模型有没有在提供的上下文之外编造内容答案相关性衡量返回文本是否切题上下文相关性衡量检索出的片段是否足够回答用户问题。你可以构建一个小规模测试集每条包含“问题、标准答案、期望召回来源”然后跑批观察这些维度。做简历项目时不要只写“效果好”。建议这样记录构造 80 到 120 条评测题把文件解析、切分参数、Embedding、topK、是否加重排模型等改动都记录成对比表。4.3 从关键词检索到 dense vector search搜索热词里频繁出现 dense vector search这其实就是把文本转成稠密向量后用余弦相似度或内积做检索。它的优势是能处理近义表达。例如用户问“员工年假多少天”如果文档写的是“带薪年休假天数”关键词检索可能匹配不到但向量检索能通过语义关联找到。一般建议关键词检索和稠密向量检索结合。先同时拿到两路结果再做合并或重排。项目里可以把“为什么选择语义向量检索”“关键词检索失效的场景”作为自我介绍的重要素材。4.4 提高 RAG 答案质量的几个操作文本切分方面不要只复制默认参数。先看常见格式再决定 chunk_size。如果问题是针对具体条款chunk 太大容易混入无关内容如果问题需要对整篇文档做总结chunk 太小又会丢失上下文。检索召回方面topK 不是越大越好越大越容易把噪声塞进上下文。可以先固定 prompt在测试集上跑 topK3、4、5 的差异。上下文组织方面把检索片段按相关性排序后拼给模型。对于客服场景建议给每个片段附上来源文件名或文档编号让模型在答案末尾输出引用编号。后处理方面如果预算允许在向量检索后增加一个 ReRank 环节。向量检索先取前 20 条候选ReRank 再精确打分取前 5 条。这在你的简历里能体现你对“检索精度”不是停留在概念层面。5. 智能客服会话管理、意图路由与工具调用5.1 客服和单轮问答的差别知识库问答通常是一问一答智能客服则要处理连续对话。核心区别在于“历史上下文”用户第二句“那怎么申请”必须结合第一句“年假怎么计算”才能理解。此外客服场景还要求系统在必要时调用业务工具比如查订单、查物流、提交退换货申请。因此智能客服模块需要设计三件事多轮会话记忆保存每轮问题和答案限量截断。意图识别与路由不是所有问题都走知识库检索。工具调用把“查订单”“查退款状态”这类操作委托给真实函数。5.2 多轮会话管理实现LangChain 生态中常见做法是用RunnableWithMessageHistory包装会话链也会用ChatMessageHistory这样的对象存放历史消息。以下写法只是示意不同版本 API 差别较大需要根据官方示例调整。from langchain_core.chat_history import InMemoryChatMessageHistory from langchain_core.runnables.history import RunnableWithMessageHistory store {} def get_session_history(session_id: str): if session_id not in store: store[session_id] InMemoryChatMessageHistory() return store[session_id]设计要点是对话历史不能无限增长。一般保留最近 N 轮摘要或最近 6 轮原始消息超出后截断。否则时间一长大模型的 prompt 会被历史消息塞满。5.3 意图路由与业务工具客服问题不能全部走向量检索。用户说“帮我看看退款到哪了”这需要查询订单系统或测试数据库。如果把这类问题也放进知识库检索系统回答的可信度很低。一个可落地的做法是先做粗粒度意图分类用户问题类型处理方式知识库内容相关走 RAG 链路带引用返回售后订单相关调用订单查询工具返回业务数据闲聊/寒暄走 Chat 模型普通回复攻击性或超范围问题拒绝回答并转人工无法确定的复杂诉求转人工并保留会话摘要意图分类不一定需要单独训练模型。可以让大模型在每轮对话先输出一个 JSON 结构指定意图类型和业务参数再按意图路由到不同处理器。工具调用一般通过 Tool 注册实现。先定义一个能查询订单状态的函数def query_order_status(order_no: str) - str: 根据订单号查询订单状态返回可读文本。 # 这里应替换为真实订单服务接口 if not order_no: return 缺少订单号 return f订单 {order_no} 当前状态已发货预计明天送达。然后在 Agent 或工具调用链路中声明这个函数模型会根据用户问题生成一次query_order_status(order_noxxx)的调用。不要给模型直接操作数据库的权限更稳妥的做法是只暴露只读接口和预定义动作。5.4 客服回答规范客服场景比普通知识库更强调稳妥。提示词里需要写清楚不确定业务信息时不要猜测。只回答与知识库或已授权工具相关的内容。涉及个人敏感信息时不能输出完整身份证号、手机号。安抚话术只能做辅助重要售后结论要经过系统校验。当用户连续多轮没有得到解决时主动建议转人工。另外客服答案建议附上参考片段 ID。实际工作里客服能不能给出来源决定了质检团队是否允许系统上线。6. 多 Agent 协作从单轮到系统化调度6.1 为什么客服系统需要 Agent一条固定链可以解决“文档问答”和“意图路由”但遇到多步骤复杂任务会不够用。比如用户提了三个问题“这个商品符合退货条件吗”“那我的运费谁承担”“帮我登记一下申请”。用一个固定链处理会产生上下文错乱因为每个子任务对应不同工具、不同分析逻辑。Agent 的思路是让模型拥有“工具箱”并自主规划。模型先看用户目标决定需要调用哪些工具调用完把结果放到思考上下文里再决定是继续调用还是给出最终回答。这就是 ReAct 模式。单 Agent 实现示例from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_openai import ChatOpenAI tools [query_order_status, create_refund_request, ask_knowledge_base] model_with_tools ChatOpenAI(modelyour-chat-model).bind_tools(tools) agent create_tool_calling_agent( llmmodel_with_tools, toolstools, promptagent_prompt ) agent_executor AgentExecutor( agentagent, toolstools, verboseTrue, return_intermediate_stepsTrue, max_iterations5 )单 Agent 已经能完成一次“检索产品退货政策 → 查用户订单 → 判断是否可退”的操作。但它的问题在于所有逻辑混在一条提示词和一套状态里问题稍微复杂模型就可能在分支上绕圈或超过最大迭代次数。6.2 多 Agent 协作的项目设计多 Agent 协作不是为了炫技而是要形成“上级Agent拆任务多个子Agent各干各的再由上级Agent汇总”的结构。一个很常见的项目切分方式角色职责主管 Agent理解用户完整意图拆解子任务决定调用哪个子 Agent检索 Agent只负责知识库检索返回带引用的答案售后 Agent查订单、退货、退款流程推荐 Agent根据用户问题做商品或内容推荐质检 Agent在最终回答发送前检查合规性比如有没有泄露隐私、有没有不安全承诺主管 Agent 不需要一次性把任务全推给所有子 Agent。它可以先问“用户的问题涉及知识库还是订单”再决定只调一个子 Agent 还是多个。这种方式能显著降低上下文噪声。想把这个流程做成真正可控的状态机LangGraph 是一个合适的选择。LangChain 适合定义“步骤顺序固定”的链LangGraph 能定义“存在分支和循环”的工作流。例如质检 Agent 检查不通过时可以回到售后 Agent 重写回答用户对工具结果不满意时可以循环让模型重新调用工具。这种回环用 LangChain 默认顺序链实现比较别扭但用 LangGraph 的状态转移描述更自然。面试时提到这一点不要只背概念可以这样说我的项目里先用 LangChain Agent 快速验证了单 Agent 工具调用然后在客服质检环节引入 LangGraph因为质检不通过触发的重写、多 Agent 分支协作需要状态机管理。LangChain 管“链”LangGraph 管“图”。6.3 避免过度 Agent 化如果链路只是“判断意图 → 检索 → 回答”没必要引入多 Agent。Agent 会增加调用次数模型自主循环后可能产生额外 token 消耗也会出现中间状态不可控的问题。多 Agent 协作适用于这些场景任务类型差异很大比如既有文档问答又有订单操作。每个子任务需要独立的指令和工具范围。一个结果需要多个角色交叉校验例如质检。有明确人工审批节点。简历项目的完整链路建议控制在“主管 Agent 3 个子 Agent 1 个人工兜底”以内。子 Agent 太多调试成本会大幅上升反而无法讲清楚每个模块的评估结果。7. 批量测试、RAG 测评与 API 服务化7.1 用批量任务积累项目数据简历项目要能拿出量化结果就必须有批量测试和回归集。测试集可以是简单的 CSV 文件session_id,category,question,expected_answer_keywords test_001,return_policy,商品支持7天无理由退货吗,7天 test_002,order_status,订单DX20240001到哪里了,已发货然后写脚本遍历测试集调用对话接口把返回结果写入输出文件import csv from app.api import answer results [] with open(tests/cases.csv, encodingutf-8) as fh: for row in csv.DictReader(fh): response answer(row[question], session_idrow[session_id]) results.append({ question: row[question], answer: response[answer], sources: response.get(sources, []), }) with open(tests/result.csv, w, encodingutf-8, newline) as fh: writer csv.DictWriter(fh, fieldnames[question, answer, sources]) writer.writeheader() writer.writerows(results)批量任务的重点不是“能跑”而是“能发现回归问题”。每当你调整了 chunk_size、换了 embedding 或改了提示词都应该重新跑一遍测试集记录变化。这样面试被问到“你怎么验证系统效果”你就有完整过程可讲。7.2 用 FastAPI 封装对话服务项目最终需要一个统一接口服务方便接入前端或供测试脚本调用。from fastapi import FastAPI from pydantic import BaseModel app FastAPI(title智能客服API) class ChatRequest(BaseModel): session_id: str question: str class ChatResponse(BaseModel): session_id: str answer: str sources: list[str] | None None app.post(/chat, response_modelChatResponse) def chat(req: ChatRequest): # 这里是核心链路路由 - RAG检索/工具调用 - 组装答案 answer_text route_and_answer( session_idreq.session_id, questionreq.question ) return ChatResponse(session_idreq.session_id, answeranswer_text)启动服务uvicorn app.main:app --host 127.0.0.1 --port 8000用 curl 验证curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {session_id: test_001, question: 怎么申请年假}返回结果示例{ session_id: test_001, answer: 可以在自助系统提交年假申请具体流程见员工手册第三章。, sources: [data/employee_handbook.pdf] }7.3 接口服务化的注意事项本地调试阶段建议只监听127.0.0.1不要直接暴露到公网。如果之后要在局域网内测试也需要加认证或访问控制。真实项目里还需要考虑超时设置。大模型推理耗时通常比普通 HTTP 接口长要在调用侧设置合理的超时时间比如 30 到 120 秒。批量任务里如果某个请求卡住要加超时中断和失败重试。7.4 性能观察方法如果模型是本地部署的重点观察显存和响应延迟。启动模型服务后在另一个终端运行nvidia-smi可以查看显存使用率与 GPU 利用率。显存占用具体数值取决于模型文件尺寸、上下文长度和并发数不能一概而论。如果模型服务在 CPU 上运行延迟会明显升高批量任务耗时也会更长。观察响应性能时建议记录三段耗时框架路由耗时、模型推理耗时、工具调用耗时。批量测试可能出现这样的情况总响应时间很长但实际大头在本地 Embedding 推理而不是 Chat 模型。知道瓶颈在哪才能在简历项目总结里写出“优化点”。8. 从项目到简历量化表达与面试回答8.1 项目描述示例项目名可以写成企业知识库智能客服与多Agent协作平台简历里的项目描述可以借鉴下面的结构但数字必须自己跑完测试之后填写。项目简介针对企业内部知识库分散、客服人工答复压力大的问题设计并实现基于 RAG、LangChain 与 LangGraph 的智能客服平台。平台支持文档批量导入、知识库问答、多轮会话管理、订单工具调用、质检 Agent 与人工兜底流程。核心工作基于 LangChain 搭建文档加载、文本切分、向量化与检索链路结合关键词检索与向量检索解决公司文档格式多、专有名词多导致的召回不准确问题。构造 100 条以上业务评测集对比不同 chunk_size、topK 与 ReRank 策略对检索命中率的影响最终离线阶段命中率提升至 xx%。针对客服多轮场景引入 ChatMessageHistory 与 RunnableWithMessageHistory设计基于 JSON 的意图路由与订单查询工具实现带引用的可解释回答。利用 LangGraph 编排主管 Agent、检索 Agent、售后 Agent、质检 Agent 的工作流实现多 Agent 协作和质检不通过后的重写逻辑工单处理口径更可控。项目成果知识库问答可用性达到 xx%订单查询工具调用成功率达到 xx%客服首轮解决率由 xx% 提升至 xx%。8.2 简历写作的三个忠告第一不要照抄别人的数字。简历是给面试官看的事实依据来源你写了“准确率提升到 95%”面试官一定会追问评测集构成、基线怎么定义、badcase 怎么归类。没有真实实验支撑的数字一旦被追问就会露馅。第二项目背景远比你用了多少个模型重要。面试官想看到你能识别实际业务问题而不是把当前最热模型堆起来。哪怕是“企业内部 Wi-Fi 使用说明”这种素材也能支撑完整的 RAG 项目。第三项目边界要清晰。承认“该项目未覆盖合同级文档知识库也不替代人工客服决定”并不会减分反而显示你理解系统能力边界。真实的工程系统一定有人工兜底和稳定性设计。8.3 高频面试问题与回答切入点问题一LangChain 和 LangGraph 的区别切入点LangChain 提供链式组合和组件抽象适合流程固定、顺序执行的场景LangGraph 基于图状态机支持分支、循环、人工在环适合多 Agent 协作流程。项目里先用 LangChain Agent 做工具调用验证后来引入 LangGraph 做质检重写和多 Agent 调度。问题二RAG 中 dense vector search 是什么意思关键词检索有没有必要保留切入点Dense vector search 是将文本编码成稠密向量后做语义相似度检索能匹配到同义改写但关键词不一致的内容。关键词检索在商品型号、工号等短编码场景仍然有效。推荐两路召回再合并最后让 ReRank 排序。问题三RAG 知识库指标有哪些怎么理解切入点检索侧关注 hit rate、precision、recall端到端侧关注忠实性、答案相关性、上下文相关性。模型答错有三种可能检索没召回、上下文够了但模型没按上下文答、评测问题本身存在歧义。调优前要先区分是哪一类。问题四客服系统什么时候不需要 Agent切入点如果只是固定规则问答直接检索加提示词最简单稳定。引入 Agent 的前提是任务存在规划与工具调用依赖并且能用评测集证明 Agent 确实提高了任务完成率否则会增加延迟和不确定性。问题五模型回答出现了幻觉怎么办切入点先看上下文是否和答案一致。如果是知识库问答正确答案应该能在上下文里找到出处如果上下文没有答案应强制模型回答“无法确认”。系统层面还可以增加质检 Agent 检查输出是否引用不存在来源并保留人工审批节点。9. 常见问题与排查方法问题现象可能原因排查方式解决方案安装依赖报错Python版本或依赖包版本冲突查看报错中的包名与Python版本新建干净虚拟环境按官方README安装本地Embedding模型加载失败模型文件未下载完整或路径错误检查首次下载日志下载完整模型文件后重新加载或切换到在线Embedding接口接口调用超时大模型推理太慢或网络连接不稳定查看模型服务和调用侧超时配置调大timeout小批量测试或换更快的模型服务检索不到相关内容切分粒度太大/太小、embedding不匹配、topK太小打印命中文档内容调整chunk_size、chunk_overlap和topK测试不同Embedding模型答案看着像编的提示词未限制“只能根据上下文回答”去掉知识库上下文再问同一问题增加prompt约束返回内容带引用编号加拒答逻辑多轮对话回答上下文错乱历史消息未按session隔离检查session_id是否一致确保每次请求都携带同一session_id并对历史做截断Agent反复调用工具不结束模型规划不收敛或工具边界不清打开verbose日志看中间步骤限制max_iterations精简工具描述把高风险操作改成固定流程批量任务跑到一半卡住单条请求超时无重试机制看批量任务日志定位卡住的问题对单条请求设置超时失败任务输出错误记录允许断点续跑端口被占用启动失败上次服务进程未退出或端口冲突netstat -anofindstr 8000或lsof -i:8000项目在演进过程中最容易踩的坑不是“RAG原理不理解”而是“改了一处参数后效果变差但不知道是哪一步导致”。因此每一次修改建议保留独立记录。推荐建一个experiments目录按exp_001_chunk_500_topk_4.md的命名保存配置、测试集结果和 badcase。10. 最佳实践与安全边界最后这部分更多是工程素养问题。CSDN 读者做简历项目往往只关心“跑得通”但大模型应用岗位面试中能不能体现边界意识往往决定了面试官对项目的评级。第一数据授权与隐私保护。知识库语料如果来自公司内部文档或用户隐私信息必须确认使用范围。不要在公网模型服务中上传未经授权的个人敏感信息不要在测试集里放真实客户手机号、身份证号、银行卡号。实验环境应先用脱敏数据或公开测试文本。第二接口访问控制。对话服务启动后要确认是否可被外网访问。如果不需要外网访问把host设为127.0.0.1如果需要部署到服务器提前加 API Token 或网关鉴权。把大模型接口暴露在无鉴权的公网上可能被恶意调用造成费用损失和数据泄露。第三Agent 权限最小化。尽量让 Agent 只调用只读查询和预授权操作。涉及退款、改密、支付等高影响动作不能在无人审批情况下直接执行。可以在 LangGraph 流程中设置“人工审批节点”这样既演示多 Agent 协作能力也体现工程安全设计。第四不要做违规的越狱或攻击测试。热词里偶尔会看到“大模型投毒测试”这类说法。这类安全测试必须放在经过授权的企业内部安全测试环境中由具备资质的人员设计和执行。普通开发者在简历项目阶段不应该采集或篡改他人提示词数据更不应针对未授权服务做注入攻击。面试官真正想看到的是“你知道哪些内容不应该让模型回答”而不是“你能绕过多少安全限制”。第五客服要设置人工兜底。即使多 Agent 协作链路再完善也不能让 AI 直接对用户做出最终承诺。比较成熟的做法是 AI 先生成回复草稿和高风险判断质检 Agent 校验后被允许的内容自动回复其余内容进入人工工作台。把“AI 辅助 人工审核”的机制写进简历会比单纯强调模型效果更有吸引力。从一个想法到一个简历级项目最容易出现的问题是停留在收藏代码和看教程。真正有效的路径是先把最小闭环跑通再做一轮针对性调整。第一步准备 5 到 10 份文档先把 RAG 问答跑通第二步整理一份 30 条左右的测试集记录初始效果第三步把智能客服的多轮会话和订单工具接进去完成 APIs 化第四步再根据效果决定是否引入多 Agent。每一步都有验证输出也就意味着每一步都能写进简历。建议把这份项目骨架收藏备用实际动手时从最小检索链开始而不是同时铺开所有模块。