最近后台收到不少同行的私信翻来覆去都是同一个问题RAG和Agent都火成这样了但网上教程要么只讲概念不给代码要么给一堆资源链接让人收藏吃灰到底怎么才能真正上手这问题我太有共鸣了。过去一年里我从只知道“RAG是检索增强生成”这个名词到自己动手搭出能跑的知识库问答Agent中间踩坑无数也总结出一套完整的学习路径。这篇文章就把这套路径、核心原理、工程细节和免费资源的筛选方法一次讲清楚适合零基础想转AI应用开发的初学者也适合已经会调API但没正经做过RAG和Agent项目的开发者参考。1. 先弄明白RAG和Agent解决的是两件不同的事很多新手一上来就纠结“先学RAG还是先学Agent”其实这个顺序问题本身就说明没搞清楚两个概念的关系。它们在真实系统里经常组合出现但解决的问题完全不同分开理解会更清晰。1.1 RAG的本质给大模型配一本“可检索的参考书”大模型的训练数据有截止日期也不包含任何私有业务数据。你让它回答公司内部制度、产品手册里的问题它要么一本正经瞎编要么直接说不知道。这就是所谓“幻觉”和“知识滞后”问题。早期有人用微调来解决但维护成本高、每次数据更新都要重新训练对多数团队根本划不来。RAG的思路完全绕开了微调这个大坑不改变模型权重而是在回答前先检索外部知识把相关内容“喂”给大模型让它基于这些参考资料作答。打个比方考试分两种闭卷和开卷。微调是让大模型死记硬背新知识RAG是允许它带着资料上考场、翻书找答案。开卷的好处显而易见资料更新只需替换知识库模型不用重新训练回答还能给出引用来源方便核对对错。RAG的一条完整链路通常包括四个环节文档加载与解析、文本分块、向量化入库、查询时召回。核心是把非结构化的文档变成结构化的向量索引再用语义相似度做检索。我见过很多初学者把RAG理解成“文档转文本直接拼进Prompt”那其实不是RAG只是粗暴的上下文拼接文档一大就超限效果也很差。1.2 Agent的本质让大模型从“回答问题”升级到“完成任务”Agent智能体则完全是另一个维度的问题。它不再满足于“你问我答”而是让模型作为决策中枢主动拆解任务、调用工具、执行动作、检查结果直到达成目标。早期Agent多半基于提示词模板事先写好“你是某某助手”的系统提示词让模型按固定流程走。但一旦任务超出预设模板就失灵。后面大家发现与其把流程写死不如让模型具备“思考—行动—观察”的循环能力也就是ReAct模式。模型先推理下一步该做什么然后调用某个工具去执行看到工具的返回结果后继续推理如此反复。整个过程很像一个真人员工做事先分析任务再动手看结果再调整下一步。Agent带来的关键变化是大模型从“内容生成器”真正变成了“流程调度器”。它手里开始握着工具搜索引擎、数据库查询接口、内部系统API、代码执行环境。能不能用好这些工具直接决定了Agent的上限。1.3 RAG和Agent为什么总被放在一起学原因很简单在实战中知识库问答Agent是最常见、最容易跑通的业务形态。单独做RAG它只是一个“增强版问答系统”单独做Agent它常常因为缺少领域知识而在关键环节上犯迷糊。两者一组合Agent负责理解意图、拆解问题、决定调哪些工具RAG负责在需要查询知识时提供准确、可溯源的答案各自补短板。我这样说你可能更直观把Agent想象成一位项目经理RAG是它手下的资料研究员。项目经理想知道“我们产品上个季度的退货率是多少”研究员就翻资料、查数据把答案连同出处递给项目经理项目经理再组织语言回复。这正好串起了我后面要讲的所有实操环节。2. 从零搭一个RAG系统完整链路和实测参数上一节把概念讲透了这一节直接进入工程实现。我的经验是先不要管花哨的高级技巧能跑通一个最小RAG系统你对全链路才算有真正的体感。这个项目我前后做了三版第一版花了两周才理清所有环节第二版半天就能复现原因就是第一版踩的坑足够多。2.1 最小RAG系统的四个组件一套能用的RAG系统最少需要四个东西嵌入模型、向量数据库、大模型和编排代码。嵌入模型负责把文本变成向量。它做的事可以理解成一个“语义编码器”把一句话映射成高维空间里的一个点语义相近的文本在空间里距离也近。主流做法是用专门的嵌入API或开源嵌入模型每个文本块生成一个向量。向量数据库负责存这些向量并做相似度检索。你可以理解为一张巨型索引表用户查询时同样转成向量然后在库里找“距离最近”的一批片段返回。技术选型上小规模用轻量级方案就够大规模再上专门的向量服务。大模型负责最终的文字生成。给它的Prompt由三部分组成系统指令、检索到的参考片段、用户原始问题。模型的任务不是回答问题本身而是“根据参考片段回答问题”这是很多初学者容易写错的Prompt结构。编排代码则是把上面三者粘起来的胶水。它要完成处理文档、分块、调嵌入模型入库、接收用户问题、转向量检索、拼Prompt、调大模型、返回结果。2.2 一步步跑通从文档到带来源的回答下面是我用过的一套最小实现逻辑用伪代码表示你换成自己顺手的语言就行# 阶段一索引构建 def build_index(documents): chunks [] for doc in documents: # 清洗去掉重复标题、页眉页脚、无意义空白 cleaned clean_doc(doc) segments split_into_chunks(cleaned, chunk_size500, overlap50) chunks.extend(segments) vectors [] for seg in chunks: emb embedding_model.encode(seg) # 文本 - 向量 vectors.append({text: seg, vector: emb}) vector_store.add(vectors) # 批量入库 return len(chunks) # 阶段二查询与生成 def query(question): q_vec embedding_model.encode(question) results vector_store.search(q_vec, top_k5) # 检索召回 context \n\n.join([r[text] for r in results]) prompt f 你是知识库助手。请严格根据下列参考内容回答用户问题。 若参考内容不足以回答请明确说明“资料库中未找到相关信息”。 【参考内容】 {context} 【用户问题】 {question} answer llm.generate(prompt) return answer, results # results 用于展示来源这里有两个参数我特意标了出来也是我踩过坑的地方分块大小chunk_size和重叠overlap。块太大单段涵盖内容多但检索精度下降容易把不相干信息也拽进来块太小语义碎片化模型拿到的是残缺信息。我实测下来中文字档500字符左右分块、50字符重叠是个稳妥起点。overlap的作用是避免一句话正好被拦腰截断导致边界信息丢失。TopK召回个数同理。太少容易漏太多会把噪声塞进上下文。5到8个是常见区间具体要看知识库的文档复杂程度。2.3 三个影响RAG效果的隐藏因素第一是文档清洗。很多人忽略这一步结果检索效果差得离谱。PDF里常见的页眉页脚、表格错位、图表扫描件乱码如果不清理就直接分块入库检索出来就是一坨噪声。我曾经拿一份扫描版的产品说明书测试不做OCR清洗时用户问“保修期多久”检索回来的是“第3页”这样的页眉文字回答自然是胡说八道。第二是嵌入模型与检索的不匹配。换了好的嵌入模型不等于检索变好还要看你的查询是长句子还是短关键词。实际使用时用户往往只输入“退款政策”四个字而我入库的文档句子都是完整长句两者向量分布差异很大直接检索效果很差。一个常见补救是查询时做HyDE让模型先对用户问题生成一段假想回复用假想回复去检索。这个技巧在短查询场景提升明显但会增加一次模型调用性能和成本都要权衡。第三是Prompt的输出约束。RAG链路里模型输出不只要“答得好”还要避免“编得真”。我的做法是在系统提示词里明确写“若参考内容不足明说不知道”同时在后处理里把回答与参考片段做简单比对防止模型脱稿发挥。代码上就是在返回answer的同时带上results来源列表前端展示“引文来源”这是生产级RAG一定要有的功能。3. Agent开发的核心四件套规划、工具、记忆与边界如果说RAG的核心是“找得准”Agent的核心就是“做得稳”。从最简单的一个Agent到生产可用的Agent区别就在于这四件事的完备程度规划、工具、记忆和边界控制。3.1 一个不吃框架的Agent内核ReAct循环你不需要任何重量级框架也能写一个能跑的Agent底层就是一个循环def run_agent(user_task): messages [system_prompt user_task] for step in range(max_steps): response llm.call(messages) action parse_action(response) if action.type finish: return action.output elif action.type tool_call: tool_result execute_tool(action.tool_name, action.params) messages.append(response) messages.append({role: tool, content: tool_result}) else: continue return 已达最大步数安全退出这个循环的精髓在于每轮都把模型输出和工具结果追加回对话历史让模型在下一次生成时“看到”自己刚才的行动结果。这就是ReAct里的Observation。它不复杂但没有这个循环结构Agent就无法持续收敛到最终答案。我见过很多教程直接把Agent等同于“调某个现成框架的Agent类”这其实是本末倒置。框架可以帮你封装细节但你先得搞懂这个循环否则遇到问题根本不知道从哪里排查。3.2 让Agent学会使用工具从“会说话”到“能办事”工具是什么对Agent来说工具就是一组注册表把函数名、参数描述、功能说明告诉模型模型选择一个调用。这里的关键不是“写函数”而是“把函数描述清楚”。模型是通过函数描述来决定是否调用、传什么参数的描述写得像密码一样含糊模型就会乱调。我总结了一套工具描述模板名称用动词开头并说清对象参数说明里注明确认必填还是选填在描述中写明适用场景和边界避免误用。更核心的是工具返回值处理。工具返回的往往是结构化的JSON或原始数据我们不能原封不动塞给模型而是要做一步“提炼”把关键信息转成模型更容易理解的自然语言文本。比如数据库查询返回了一堆字段我会先在后端格式化一轮输出“当前库存A商品12件B商品0件”再让它继续决策。这步处理好Agent的回答准确率会直接上一个台阶。3.3 记忆机制的取舍没有记忆的Agent走不远记忆分三层上下文记忆、短期工作记忆和长期记忆。上下文记忆就是对话历史拼接简单直接但Token消耗按轮数增长必须做裁剪或摘要。短期工作记忆指Agent在单次任务执行中记住自己已经做过哪些工具调用避免重复操作或绕圈子。长期记忆则复杂得多通常用向量库存储历史经验、用户偏好等本质上又回到了RAG的领域。对大多数新手项目我建议先上上下文记忆加一轮任务内的执行轨迹记录就够别盲目设计复杂的记忆系统。记忆设计得越复杂调试越痛苦。一个常见事故就是记忆里存了大量无关历史模型被带偏回答反而变差。记忆不等于越长越好关键是“在需要时检索到对的记忆”。3.4 Agent开发中踩过的三个大坑第一大坑是无限循环没有兜底。第一个正式Demo做到一半模型反复调用一个查询工具就是不结束活活烧掉大量Token才被我发现。后来我在循环里加max_steps限制同时监控工具调用次数异常就强制中断并给出部分结果。第二大坑是工具结果不可信。模型有了工具调用能力但很少校验工具返回是否合理。真实世界里接口超时、权限不足、返回空结果都是常态。如果不加校验模型就会拿着“空结果”继续推理甚至编造一个结果出来。我现在的做法是所有工具调用后都先做一步状态检查异常就直接返回“工具执行失败”让模型换条路走。第三大坑是缺少人工确认环节。Agent一旦能执行写操作发邮件、改数据就必须在关键动作前设置暂停确认。这是工程上最容易被忽略、上线后最容易出事故的点。我在项目里对所有非查询类工具都加了一道确认钩子拦在前面。4. 从零到实战的100天学习路径我建议这样安排不少新手找我要学习路径我给过很多版本最后收敛下来的一套“100天路径”今天完整放出来。它表上面看着节奏不紧实际上每天都在推动产出物不是看完类教程就完事。4.1 三个阶段的目标、交付物与自测方法第一阶段基础与Prompt工程目标是用代码稳定调用大模型API写出结构清晰的Prompt。交付物是五类不同功能的Prompt模板问答、总结、分类、提取、改写加一个小脚本。自测方法是给你身边人出题看看Prompt在不换模型的情况下能不能稳定输出理想结果。第二阶段RAG完整链路目标是从零搭出带界面的知识库问答Demo。交付物是一个支持上传文档、提问、展示引用来源的本地项目。自测方法是用30个真实问题和参考答案建一个评估集算一算召回率和回答准确率而不是“看起来挺准”。第三阶段Agent实战目标是在RAG基础上加入工具调用和循环规划完成能解决实际问题的Agent。交付物类似“文档问答资料检索定时汇总”相结合的半自动助理。自测方法是预设任务脚本让它按照预定路径完成验证每一步的工具调用和最终结果。4.2 技术栈选型先固定一条路再扩展新手最容易犯的选择困难症是今天看这个框架好明天看那个库强结果一周下来什么都没跑通。我的建议是先固定一套“最小组合”跑通之后再横向扩展。一套经典的新手组合是一门语言当然是Python、一个开源嵌入模型、一个向量库、一个主流编排框架。先在本地把这一套跑起来理解各环节的数据流再去看别的方案。千万不要一上来就同时研究多个编排框架的差异那是老手该做的事。工具选型的另一个原则是“看生态配套和文档更新频率”。选一个文档里有完整示例、示例代码能直接跑的比选一个性能好但社区冷的要重要得多。冷门工具遇到报错搜遍全网都找不到解决方案心态很容易崩。4.3 免费资源的正确打开方式市面上的免费资源确实很多但“免费领全套资料”和“真正学会”之间隔着一条鸿沟。资源的价值不在数量在于能不能让你动手。筛选资源我有三条自己的标准。一是看教程是否包含可运行的样例工程。一个只有概念讲解、没有代码仓库的教程不管讲得多精彩对你的动手能力帮助都很有限。我建议每学一个概念都找到对应的最小代码示例在自己的机器上真实跑一遍比看十篇图文都管用。二是看文档和示例代码的更新时间。AI技术迭代速度极快半年前的教程里用的接口可能已经过时了。选资源优先看更新时间太老的就不要浪费时间了。我实际踩过这个坑两年前的一份教程费了好大的劲最后发现接口全部废弃等于白学。三是跳脱“收藏等于学会”的错觉。不用下载很全的合集一个标题写着“从零到实战”的课程只要它确实带动手环节比十个“知识清单”更有价值。下载资料前先想清楚一个问题这份资源能让我马上动手写出什么代码能回答出来的下载回答不出来的先不下载。5. 实战记录我用免费资源完成“文档问答Agent”的全过程讲了一堆理论和方法最后用一个我做过的完整项目来收尾。这个项目的所有组件全是通过公开渠道能拿到的免费资源搭起来的正好呼应标题里的“全套资源免费领”。5.1 项目设定一个小但完整的技能闭环项目需求很明确给我手头的一批产品操作手册做一个问答Agent能回答“怎么设置定时任务”“故障码E03是什么意思”这类问题。要求回答必须基于手册内容不能瞎编同时要在回答里标出信息来自哪一节。技术选型上文档是纯文本和PDF混合检索链路用了嵌入模型加轻量级向量库Agent编排使用通用框架的Agent接口同时自定义了三个工具文档检索工具、页面定位工具、常见问题查询工具。整体结构刚好是一个“RAGAgent”的组合。这个项目体量不大但包含了一个真实应用的所有关键环节数据准备、索引构建、检索策略、工具调用、生成约束、来源展示由它可以延伸到多个更复杂的业务。5.2 实现细节检索增强 工具调用 结果溯源整个Agent的执行逻辑是这样用户提问进来Agent先判断这是一个“事实型问题”还是“操作型问题”。事实型问题直接走RAG检索返回答案和来源操作型问题则先查常见问题库再查手册对应章节必要时自动生成步骤总结。文档处理阶段的细节值得说说。产品手册最大的特点是章节边界清晰、步骤有编号因此不能只是机械地按固定长度分块。我先按章节标题拆出大段再把大段按内容粒度细分为小节小节再按固定窗口做二次切分。这样检索时既能按大章节召回又能在小节级别给出精确引用。结果溯源我做了两步第一步召回时记录命中的文档块及其所属章节第二步模型回答后在后端校验回答中提到的关键步骤是否在命中块中出现过防止模型自行发挥。校验通过才把来源附在回答后面展示给用户。5.3 测评与上线别等部署完才考虑效果项目跑通后我没有急于部署而是先建了一个包含60个问题的评测集。评测集里的问题分三类直接可在手册中定位原文的、需要综合多个章节信息的、手册中根本没有答案的。前两类检验回答正确度第三类专门测试“拒答”能力。这个评测给我最大的教训是一个RAG系统最怕的不是“答错”而是“明明找不到答案还硬编”。我第一版在第三类问题上的表现几乎全军覆没模型都在一本正经地编造操作步骤。修复方法是在Agent的规划阶段增加一道“资料充分性检查”如果检索结果与问题的语义相关性极低就直接进入“资料库未覆盖该问题”的分支不再调用生成模型硬答。上线前的最后一个工作是我一直强调的安全边界的确认。我限制了Agent只能操作已开放的三个工具不允许模型凭空调用其它接口所有面向外部数据的操作都必须先经过权限校验。别嫌这一步烦生产系统在启动初期的稳定性往往就取决于这些兜底设计。项目上线后日常使用中我印象最深的一件事是用户不太关心你的Agent用了什么高级算法他们只关心“能不能快速找到答案找到的答案靠不靠谱”。这一点想通了项目的技术选型和实现重点就都不会跑偏。这套从零到实战的方法看起来慢但每一步都是为后面的工程化打基础值得你在自己的项目里复刻一遍。