1. 从零起步我为什么选择大模型应用开发这条路2023年初我第一次用API调用大模型完成了一个自动摘要脚本当时的感觉就像第一次用上智能手机——知道这东西会改变很多事但具体怎么改变、自己能从中抓住什么完全没想清楚。两年多下来我从一个只会写CRUD的后端开发逐步摸到了大模型应用开发的门道做过RAG知识库、搭过Agent工作流、踩过上下文管理的坑也经历过“Demo很惊艳、上线就翻车”的尴尬。这篇文章不是教程而是把我这两年多的学习路径、技术选型思路、实操中真正卡住我的地方原原本本拆开讲一遍。如果你也是后端或全栈出身想切入大模型应用开发但不知道从哪下手或者你已经会调API但一提到Agent、RAG、LangChain就感觉知识点散落一地——那这篇内容应该能帮你省下不少瞎折腾的时间。我会围绕大模型应用开发这条主线把Agent开发、LangChain框架、RAG知识库、上下文工程这几个核心模块串起来讲清楚每个阶段该学什么、为什么这么学、实际做项目时会遇到什么问题。先说一个我自己的判断大模型应用开发不是“学一个框架”就能搞定的事。它更像是后端开发数据工程提示词设计系统架构的混合体。你不需要成为算法专家但必须理解模型的边界在哪里否则你设计出来的系统一定会在某个环节崩掉。下面我按自己实际走过的路径从基础能力建设到完整项目落地逐层拆解。2. 学习路径的整体设计与阶段拆解2.1 为什么不能一上来就学LangChain我见过太多人包括我自己一开始就扎进LangChain的文档里结果被Chain、Agent、Tool、Memory、Retriever这些概念绕晕写了几个Demo之后发现除了“能跑”之外什么也没学到。问题出在顺序错了。LangChain本质上是一个编排框架它解决的是“如何把大模型调用、工具调用、数据检索、状态管理串起来”的问题。但如果你不理解大模型本身的调用方式、不理解Token和上下文窗口的限制、不理解Embedding和向量检索的原理那你用LangChain只是在抄代码出了问题完全不知道怎么排查。我的建议是分四个阶段阶段一裸调API理解模型的基本行为。用Python直接调大模型接口感受Temperature、Top-P、Max Tokens这些参数对输出的影响理解System Prompt和User Prompt的区别搞清楚什么是流式输出、什么是Function Calling。阶段二手写一个最小RAG。不用任何框架用Embedding模型向量数据库Prompt拼接自己实现一个“基于文档问答”的流程。这一步会让你真正理解RAG的每个环节在做什么。阶段三引入LangChain/LangGraph做编排。当你手写过一遍之后再看LangChain的抽象就会很清晰——它只是把你手写的步骤封装成了可复用的组件。阶段四做Agent和上下文工程。这是进阶阶段涉及多轮工具调用、状态管理、上下文压缩、评估与迭代。这个顺序的核心逻辑是先理解原理再使用工具先跑通最小闭环再追求工程化。2.2 每个阶段的核心产出物光说阶段太虚我列一下我当时每个阶段要求自己必须交付的东西阶段核心产出验证标准裸调API一个命令行问答脚本能流式输出能切换模型能控制参数手写RAG一个本地文档问答工具能对PDF/Markdown切片、检索、生成回答LangChain编排一个带记忆的对话机器人能记住上下文能调用外部工具Agent上下文工程一个多步骤任务Agent能拆解任务、调用多个工具、处理失败重试每个产出物都不追求功能多但要求自己能讲清楚每一行代码为什么这么写。这个习惯后来帮了我大忙——线上出问题时我能快速定位是检索环节、Prompt环节还是模型本身的问题。2.3 关于“动手学大模型”这类课程的使用方式网上有很多公开的学习资料比如上海交大的“动手学大模型”课程质量确实不错。但我的经验是课程用来建立知识框架真正的能力来自自己动手做项目。看课的时候觉得什么都懂了一上手就发现连环境都配不明白。所以我的做法是每看完一个章节立刻用自己的一台机器复现一遍哪怕只是把示例代码改几个参数跑通也比光看强。3. 核心模块深度解析RAG、Agent与上下文工程3.1 RAG知识库从“能问答”到“答得准”的关键细节RAG是我做的第一个真正有实用价值的大模型应用。当时的需求很简单公司内部有几百份技术文档想让新同事能用一个问答界面快速找到答案。我一开始觉得这事不难——文档切片、向量化、检索、拼Prompt、调模型五步搞定。结果第一版上线后回答准确率大概只有60%经常答非所问。问题出在几个地方我逐个拆解。切片策略比你想的重要得多。我最初用的是固定长度切片每500个字符切一段。结果很多段落被从中间切断语义不完整。后来改成按标题层级切分再配合重叠窗口overlap检索质量明显提升。具体做法是先用Markdown的标题结构做一级切分如果某个章节太长再按段落做二级切分每个切片保留前一段的最后50个字符作为上下文衔接。Embedding模型的选择直接影响检索效果。我试过几种方案OpenAI的text-embedding-ada-002效果稳定但需要网络调用本地部署可以用BGE-M3或者M3E中文场景下BGE-M3的表现相当不错。如果你对数据隐私有要求本地Embedding模型是更好的选择。实测下来BGE-M3在中文技术文档上的检索命中率比ada-002高出大约8个百分点。向量数据库选型要看场景。我用过Milvus、PGVector和Chroma。Milvus适合大规模数据百万级以上性能好但运维复杂PGVector的优势是如果你已经在用PostgreSQL直接加个扩展就行不用额外维护一套数据库Chroma适合快速原型但生产环境不太推荐。我最终选了PGVector因为我们的业务数据本来就在PG里省了一套运维。检索策略上混合检索比纯向量检索更稳。纯向量检索在语义相似度上表现好但对精确关键词比如错误码、函数名的匹配能力弱。我的做法是向量检索全文检索BM25各取Top-K然后用RRFReciprocal Rank Fusion做融合排序。这个改动让检索准确率又提升了大概10个百分点。实操心得RAG的调优不是一次性的需要建立评估集。我当时的做法是人工标注了100个问题和对应的正确文档片段每次调整切片策略或检索参数后跑一遍评估集看命中率变化。没有评估集的调优就是瞎调。3.2 Agent开发从“单次问答”到“多步执行”的跨越Agent是我觉得最有意思也最容易翻车的部分。简单说Agent就是让大模型不仅能回答问题还能决定调用什么工具、按什么顺序调用、根据结果决定下一步做什么。我做的第一个Agent是一个“技术文档助手”能根据用户问题自动决定是检索知识库、查询API文档还是执行代码示例。用的框架是LangGraph因为它对状态管理和条件分支的支持比LangChain的AgentExecutor更灵活。Agent的核心难点不在“调用工具”而在上下文管理。每次工具调用都会产生新的上下文如果不加控制几轮之后上下文窗口就爆了。我的解决方案是工具返回结果做摘要压缩只保留关键信息维护一个“任务状态”对象记录当前进展和已完成步骤超过一定轮次后强制触发上下文压缩把历史对话总结成简短摘要这里要提一下上下文工程这个概念。很多人把它和提示词工程混为一谈其实不一样。提示词工程关注的是“怎么问”上下文工程关注的是“在什么信息环境下问”。对于Agent来说上下文工程决定了它能记住什么、忘记什么、什么时候该检索新信息。这个能力比会写几句漂亮的Prompt重要得多。3.3 LangChain与LangGraph什么时候用哪个这个问题我被问过很多次。我的理解是LangChain适合线性的、步骤固定的流程。比如“检索→拼接→生成”这种RAG流程用LangChain的Chain就能很清晰地表达。LangGraph适合有状态、有分支、有循环的流程。比如Agent需要根据工具返回结果决定下一步走哪个分支或者需要多轮迭代直到满足条件这时候LangGraph的图结构更合适。我自己的项目里RAG部分用LangChainAgent部分用LangGraph两者可以共存。不需要二选一。3.4 模型部署本地还是云端这取决于你的场景。如果只是学习和原型开发直接用云端API最省事。但如果涉及敏感数据或者需要控制成本本地部署是更好的选择。本地部署我推荐用vLLM或者Ollama。vLLM的吞吐量更好适合生产环境Ollama安装简单适合个人开发。模型选择上7B到14B参数的模型在消费级显卡上就能跑比如Qwen2.5-7B-Instruct在中文任务上表现不错。如果显卡显存够24G以上可以尝试32B级别的模型效果会更好。注意本地部署模型时一定要关注量化方式。GPTQ和AWQ是两种常见的量化方案前者兼容性好后者推理速度更快。我实测下来AWQ量化后的模型在相同显存下能支持更长的上下文。4. 实操过程从零搭建一个Agentic RAG系统4.1 整体架构设计这一章我把自己做过的一个完整项目拆开讲。需求是做一个内部技术知识库助手能回答技术问题、能查询API文档、能执行简单的代码片段验证。技术栈选型后端框架FastAPI轻量、异步支持好编排框架LangChain LangGraph向量数据库PGVectorEmbedding模型BGE-M3本地部署大模型Qwen2.5-14B-Instruct本地vLLM部署前端简单的Streamlit界面整体流程是用户提问 → LangGraph入口节点判断意图 → 如果是知识问答走RAG分支 → 如果是API查询走工具调用分支 → 如果是代码验证走代码执行分支 → 汇总结果返回。4.2 知识库构建的完整步骤第一步是文档预处理。我把所有技术文档统一转成Markdown格式然后用LangChain的MarkdownHeaderTextSplitter按标题层级切分。切分后的每个片段加上元数据来源文件、章节标题、更新时间。第二步是向量化。用BGE-M3对每个片段生成向量存入PGVector。这里有个细节BGE-M3支持多语言而且对长文本的处理比很多模型好适合技术文档这种中英文混杂的场景。第三步是建立索引。PGVector支持IVFFlat和HNSW两种索引。IVFFlat构建快但查询精度略低HNSW查询快但构建慢。我选了HNSW因为查询性能对用户体验影响更大。# 向量化与存储的核心代码示意 from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import PGVector embedding HuggingFaceBgeEmbeddings( model_nameBAAI/bge-m3, model_kwargs{device: cuda}, encode_kwargs{normalize_embeddings: True} ) vectorstore PGVector.from_documents( documentschunks, embeddingembedding, collection_nametech_docs, connection_stringpostgresql://user:passlocalhost:5432/vectordb, use_jsonbTrue )4.3 Agent工作流的实现细节LangGraph的核心是定义状态和节点。我定义了一个AgentState包含用户问题、当前步骤、已收集的信息、工具调用历史。节点设计上我分了四个意图识别节点判断用户问题属于哪一类RAG检索节点从知识库检索相关文档工具调用节点执行API查询或代码验证结果汇总节点整合所有信息生成最终回答条件边的逻辑是如果意图识别结果是“知识问答”走RAG分支如果是“API查询”走工具调用分支如果两者都涉及先走RAG再走工具调用。这里有个关键设计每个节点执行完后都会更新状态但状态中只保留摘要信息不保留完整的工具返回结果。这样做是为了控制上下文长度。完整的工具返回结果存在外部状态里只存引用ID。4.4 上下文压缩的具体实现上下文压缩我用了两种策略滑动窗口摘要保留最近N轮对话的完整内容更早的对话用大模型生成摘要工具结果压缩工具返回的长文本先用小模型做摘要只把摘要放入上下文实测下来这两种策略结合使用能把上下文长度控制在模型窗口的60%以内同时保留关键信息。实操心得上下文压缩不要等到快满了才做要在每轮对话结束后就判断是否需要压缩。我一开始是等到报错才处理结果经常在关键时刻掉链子。5. 常见问题与排查技巧实录5.1 RAG检索不准的排查思路这是最高频的问题。我的排查顺序是先看切片质量把检索到的片段打印出来看是否语义完整。如果片段被切断调整切片策略。再看Embedding效果用几个已知答案的问题测试看正确文档是否在Top-K里。如果不在考虑换Embedding模型或加入混合检索。最后看Prompt拼接检索到了正确文档但模型没用好说明Prompt需要调整。我通常会在Prompt里明确要求“只根据提供的文档回答不要编造”。5.2 Agent陷入循环怎么办Agent有时候会反复调用同一个工具陷入死循环。我的解决方案是设置最大迭代次数通常5-8次在状态里记录已调用过的工具和参数如果重复调用相同组合强制跳出在Prompt里明确告知“如果已经获取了足够信息请直接生成回答”5.3 本地模型部署的显存问题14B模型用FP16加载大概需要28G显存如果显卡不够可以用4-bit量化显存降到8G左右。但量化会损失一些精度需要评估是否可接受。我的经验是对于RAG场景量化后的模型在生成质量上差异不大但在复杂推理任务上会有明显下降。5.4 常见问题速查表问题现象可能原因解决方向回答与问题无关检索结果不相关检查切片策略和Embedding模型回答内容编造Prompt约束不够加强“只根据文档回答”的指令Agent反复调用工具缺少终止条件设置最大迭代次数和重复检测上下文超限未做压缩引入滑动窗口和摘要机制本地模型推理慢未用量化或硬件不足尝试AWQ量化或换更小模型6. 我踩过的坑与后来才明白的事第一个坑是过早追求框架化。我一开始就用LangChain把所有东西包起来结果出了问题完全不知道是框架的锅还是自己的锅。后来我把关键环节手写了一遍再回头看LangChain的源码才发现很多“魔法”其实很简单。第二个坑是忽视评估。没有评估集的调优就是盲人摸象。我后来花了整整一周时间标注了200个测试用例虽然枯燥但之后每次改动都能快速验证效果效率反而高了。第三个坑是低估上下文管理的重要性。我最初觉得上下文就是“把历史对话拼进去”后来才发现什么时候该检索、什么时候该压缩、什么时候该丢弃这些决策直接决定了Agent的智能程度。上下文工程不是提示词工程的子集它是独立且更底层的能力。如果让我重新走一遍这条路我会把更多时间花在理解模型行为和设计评估体系上而不是追新框架。框架会变但对问题的理解和解决问题的能力不会变。
1. 从零起步我为什么选择大模型应用开发这条路2023年初我第一次用API调用大模型完成了一个自动摘要脚本当时的感觉就像第一次用上智能手机——知道这东西会改变很多事但具体怎么改变、自己能从中抓住什么完全没想清楚。两年多下来我从一个只会写CRUD的后端开发逐步摸到了大模型应用开发的门道做过RAG知识库、搭过Agent工作流、踩过上下文管理的坑也经历过“Demo很惊艳、上线就翻车”的尴尬。这篇文章不是教程而是把我这两年多的学习路径、技术选型思路、实操中真正卡住我的地方原原本本拆开讲一遍。如果你也是后端或全栈出身想切入大模型应用开发但不知道从哪下手或者你已经会调API但一提到Agent、RAG、LangChain就感觉知识点散落一地——那这篇内容应该能帮你省下不少瞎折腾的时间。我会围绕大模型应用开发这条主线把Agent开发、LangChain框架、RAG知识库、上下文工程这几个核心模块串起来讲清楚每个阶段该学什么、为什么这么学、实际做项目时会遇到什么问题。先说一个我自己的判断大模型应用开发不是“学一个框架”就能搞定的事。它更像是后端开发数据工程提示词设计系统架构的混合体。你不需要成为算法专家但必须理解模型的边界在哪里否则你设计出来的系统一定会在某个环节崩掉。下面我按自己实际走过的路径从基础能力建设到完整项目落地逐层拆解。2. 学习路径的整体设计与阶段拆解2.1 为什么不能一上来就学LangChain我见过太多人包括我自己一开始就扎进LangChain的文档里结果被Chain、Agent、Tool、Memory、Retriever这些概念绕晕写了几个Demo之后发现除了“能跑”之外什么也没学到。问题出在顺序错了。LangChain本质上是一个编排框架它解决的是“如何把大模型调用、工具调用、数据检索、状态管理串起来”的问题。但如果你不理解大模型本身的调用方式、不理解Token和上下文窗口的限制、不理解Embedding和向量检索的原理那你用LangChain只是在抄代码出了问题完全不知道怎么排查。我的建议是分四个阶段阶段一裸调API理解模型的基本行为。用Python直接调大模型接口感受Temperature、Top-P、Max Tokens这些参数对输出的影响理解System Prompt和User Prompt的区别搞清楚什么是流式输出、什么是Function Calling。阶段二手写一个最小RAG。不用任何框架用Embedding模型向量数据库Prompt拼接自己实现一个“基于文档问答”的流程。这一步会让你真正理解RAG的每个环节在做什么。阶段三引入LangChain/LangGraph做编排。当你手写过一遍之后再看LangChain的抽象就会很清晰——它只是把你手写的步骤封装成了可复用的组件。阶段四做Agent和上下文工程。这是进阶阶段涉及多轮工具调用、状态管理、上下文压缩、评估与迭代。这个顺序的核心逻辑是先理解原理再使用工具先跑通最小闭环再追求工程化。2.2 每个阶段的核心产出物光说阶段太虚我列一下我当时每个阶段要求自己必须交付的东西阶段核心产出验证标准裸调API一个命令行问答脚本能流式输出能切换模型能控制参数手写RAG一个本地文档问答工具能对PDF/Markdown切片、检索、生成回答LangChain编排一个带记忆的对话机器人能记住上下文能调用外部工具Agent上下文工程一个多步骤任务Agent能拆解任务、调用多个工具、处理失败重试每个产出物都不追求功能多但要求自己能讲清楚每一行代码为什么这么写。这个习惯后来帮了我大忙——线上出问题时我能快速定位是检索环节、Prompt环节还是模型本身的问题。2.3 关于“动手学大模型”这类课程的使用方式网上有很多公开的学习资料比如上海交大的“动手学大模型”课程质量确实不错。但我的经验是课程用来建立知识框架真正的能力来自自己动手做项目。看课的时候觉得什么都懂了一上手就发现连环境都配不明白。所以我的做法是每看完一个章节立刻用自己的一台机器复现一遍哪怕只是把示例代码改几个参数跑通也比光看强。3. 核心模块深度解析RAG、Agent与上下文工程3.1 RAG知识库从“能问答”到“答得准”的关键细节RAG是我做的第一个真正有实用价值的大模型应用。当时的需求很简单公司内部有几百份技术文档想让新同事能用一个问答界面快速找到答案。我一开始觉得这事不难——文档切片、向量化、检索、拼Prompt、调模型五步搞定。结果第一版上线后回答准确率大概只有60%经常答非所问。问题出在几个地方我逐个拆解。切片策略比你想的重要得多。我最初用的是固定长度切片每500个字符切一段。结果很多段落被从中间切断语义不完整。后来改成按标题层级切分再配合重叠窗口overlap检索质量明显提升。具体做法是先用Markdown的标题结构做一级切分如果某个章节太长再按段落做二级切分每个切片保留前一段的最后50个字符作为上下文衔接。Embedding模型的选择直接影响检索效果。我试过几种方案OpenAI的text-embedding-ada-002效果稳定但需要网络调用本地部署可以用BGE-M3或者M3E中文场景下BGE-M3的表现相当不错。如果你对数据隐私有要求本地Embedding模型是更好的选择。实测下来BGE-M3在中文技术文档上的检索命中率比ada-002高出大约8个百分点。向量数据库选型要看场景。我用过Milvus、PGVector和Chroma。Milvus适合大规模数据百万级以上性能好但运维复杂PGVector的优势是如果你已经在用PostgreSQL直接加个扩展就行不用额外维护一套数据库Chroma适合快速原型但生产环境不太推荐。我最终选了PGVector因为我们的业务数据本来就在PG里省了一套运维。检索策略上混合检索比纯向量检索更稳。纯向量检索在语义相似度上表现好但对精确关键词比如错误码、函数名的匹配能力弱。我的做法是向量检索全文检索BM25各取Top-K然后用RRFReciprocal Rank Fusion做融合排序。这个改动让检索准确率又提升了大概10个百分点。实操心得RAG的调优不是一次性的需要建立评估集。我当时的做法是人工标注了100个问题和对应的正确文档片段每次调整切片策略或检索参数后跑一遍评估集看命中率变化。没有评估集的调优就是瞎调。3.2 Agent开发从“单次问答”到“多步执行”的跨越Agent是我觉得最有意思也最容易翻车的部分。简单说Agent就是让大模型不仅能回答问题还能决定调用什么工具、按什么顺序调用、根据结果决定下一步做什么。我做的第一个Agent是一个“技术文档助手”能根据用户问题自动决定是检索知识库、查询API文档还是执行代码示例。用的框架是LangGraph因为它对状态管理和条件分支的支持比LangChain的AgentExecutor更灵活。Agent的核心难点不在“调用工具”而在上下文管理。每次工具调用都会产生新的上下文如果不加控制几轮之后上下文窗口就爆了。我的解决方案是工具返回结果做摘要压缩只保留关键信息维护一个“任务状态”对象记录当前进展和已完成步骤超过一定轮次后强制触发上下文压缩把历史对话总结成简短摘要这里要提一下上下文工程这个概念。很多人把它和提示词工程混为一谈其实不一样。提示词工程关注的是“怎么问”上下文工程关注的是“在什么信息环境下问”。对于Agent来说上下文工程决定了它能记住什么、忘记什么、什么时候该检索新信息。这个能力比会写几句漂亮的Prompt重要得多。3.3 LangChain与LangGraph什么时候用哪个这个问题我被问过很多次。我的理解是LangChain适合线性的、步骤固定的流程。比如“检索→拼接→生成”这种RAG流程用LangChain的Chain就能很清晰地表达。LangGraph适合有状态、有分支、有循环的流程。比如Agent需要根据工具返回结果决定下一步走哪个分支或者需要多轮迭代直到满足条件这时候LangGraph的图结构更合适。我自己的项目里RAG部分用LangChainAgent部分用LangGraph两者可以共存。不需要二选一。3.4 模型部署本地还是云端这取决于你的场景。如果只是学习和原型开发直接用云端API最省事。但如果涉及敏感数据或者需要控制成本本地部署是更好的选择。本地部署我推荐用vLLM或者Ollama。vLLM的吞吐量更好适合生产环境Ollama安装简单适合个人开发。模型选择上7B到14B参数的模型在消费级显卡上就能跑比如Qwen2.5-7B-Instruct在中文任务上表现不错。如果显卡显存够24G以上可以尝试32B级别的模型效果会更好。注意本地部署模型时一定要关注量化方式。GPTQ和AWQ是两种常见的量化方案前者兼容性好后者推理速度更快。我实测下来AWQ量化后的模型在相同显存下能支持更长的上下文。4. 实操过程从零搭建一个Agentic RAG系统4.1 整体架构设计这一章我把自己做过的一个完整项目拆开讲。需求是做一个内部技术知识库助手能回答技术问题、能查询API文档、能执行简单的代码片段验证。技术栈选型后端框架FastAPI轻量、异步支持好编排框架LangChain LangGraph向量数据库PGVectorEmbedding模型BGE-M3本地部署大模型Qwen2.5-14B-Instruct本地vLLM部署前端简单的Streamlit界面整体流程是用户提问 → LangGraph入口节点判断意图 → 如果是知识问答走RAG分支 → 如果是API查询走工具调用分支 → 如果是代码验证走代码执行分支 → 汇总结果返回。4.2 知识库构建的完整步骤第一步是文档预处理。我把所有技术文档统一转成Markdown格式然后用LangChain的MarkdownHeaderTextSplitter按标题层级切分。切分后的每个片段加上元数据来源文件、章节标题、更新时间。第二步是向量化。用BGE-M3对每个片段生成向量存入PGVector。这里有个细节BGE-M3支持多语言而且对长文本的处理比很多模型好适合技术文档这种中英文混杂的场景。第三步是建立索引。PGVector支持IVFFlat和HNSW两种索引。IVFFlat构建快但查询精度略低HNSW查询快但构建慢。我选了HNSW因为查询性能对用户体验影响更大。# 向量化与存储的核心代码示意 from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import PGVector embedding HuggingFaceBgeEmbeddings( model_nameBAAI/bge-m3, model_kwargs{device: cuda}, encode_kwargs{normalize_embeddings: True} ) vectorstore PGVector.from_documents( documentschunks, embeddingembedding, collection_nametech_docs, connection_stringpostgresql://user:passlocalhost:5432/vectordb, use_jsonbTrue )4.3 Agent工作流的实现细节LangGraph的核心是定义状态和节点。我定义了一个AgentState包含用户问题、当前步骤、已收集的信息、工具调用历史。节点设计上我分了四个意图识别节点判断用户问题属于哪一类RAG检索节点从知识库检索相关文档工具调用节点执行API查询或代码验证结果汇总节点整合所有信息生成最终回答条件边的逻辑是如果意图识别结果是“知识问答”走RAG分支如果是“API查询”走工具调用分支如果两者都涉及先走RAG再走工具调用。这里有个关键设计每个节点执行完后都会更新状态但状态中只保留摘要信息不保留完整的工具返回结果。这样做是为了控制上下文长度。完整的工具返回结果存在外部状态里只存引用ID。4.4 上下文压缩的具体实现上下文压缩我用了两种策略滑动窗口摘要保留最近N轮对话的完整内容更早的对话用大模型生成摘要工具结果压缩工具返回的长文本先用小模型做摘要只把摘要放入上下文实测下来这两种策略结合使用能把上下文长度控制在模型窗口的60%以内同时保留关键信息。实操心得上下文压缩不要等到快满了才做要在每轮对话结束后就判断是否需要压缩。我一开始是等到报错才处理结果经常在关键时刻掉链子。5. 常见问题与排查技巧实录5.1 RAG检索不准的排查思路这是最高频的问题。我的排查顺序是先看切片质量把检索到的片段打印出来看是否语义完整。如果片段被切断调整切片策略。再看Embedding效果用几个已知答案的问题测试看正确文档是否在Top-K里。如果不在考虑换Embedding模型或加入混合检索。最后看Prompt拼接检索到了正确文档但模型没用好说明Prompt需要调整。我通常会在Prompt里明确要求“只根据提供的文档回答不要编造”。5.2 Agent陷入循环怎么办Agent有时候会反复调用同一个工具陷入死循环。我的解决方案是设置最大迭代次数通常5-8次在状态里记录已调用过的工具和参数如果重复调用相同组合强制跳出在Prompt里明确告知“如果已经获取了足够信息请直接生成回答”5.3 本地模型部署的显存问题14B模型用FP16加载大概需要28G显存如果显卡不够可以用4-bit量化显存降到8G左右。但量化会损失一些精度需要评估是否可接受。我的经验是对于RAG场景量化后的模型在生成质量上差异不大但在复杂推理任务上会有明显下降。5.4 常见问题速查表问题现象可能原因解决方向回答与问题无关检索结果不相关检查切片策略和Embedding模型回答内容编造Prompt约束不够加强“只根据文档回答”的指令Agent反复调用工具缺少终止条件设置最大迭代次数和重复检测上下文超限未做压缩引入滑动窗口和摘要机制本地模型推理慢未用量化或硬件不足尝试AWQ量化或换更小模型6. 我踩过的坑与后来才明白的事第一个坑是过早追求框架化。我一开始就用LangChain把所有东西包起来结果出了问题完全不知道是框架的锅还是自己的锅。后来我把关键环节手写了一遍再回头看LangChain的源码才发现很多“魔法”其实很简单。第二个坑是忽视评估。没有评估集的调优就是盲人摸象。我后来花了整整一周时间标注了200个测试用例虽然枯燥但之后每次改动都能快速验证效果效率反而高了。第三个坑是低估上下文管理的重要性。我最初觉得上下文就是“把历史对话拼进去”后来才发现什么时候该检索、什么时候该压缩、什么时候该丢弃这些决策直接决定了Agent的智能程度。上下文工程不是提示词工程的子集它是独立且更底层的能力。如果让我重新走一遍这条路我会把更多时间花在理解模型行为和设计评估体系上而不是追新框架。框架会变但对问题的理解和解决问题的能力不会变。
