★ FEATURED ARTICLE 最近带项目的时候被问得最多的两个词一个是RAG另一个是Agent。几乎每天都有人在群里问我零基础能学会吗该先学哪个有没有免费资源可以直接用我的答案一直很一致——先学RAG再学Agent然后把它们接到一起做项目。这个组合学完很多真实场景都能落地不是那种学完就忘了的玩具Demo。这篇内容不是课程广告也不搞引流套路。我会把从零到实战要走的每一步拆开讲清楚包括概念、技术栈、完整实操流程还有我自己找过、用过的免费资源到底去哪找。零基础读者请放心文中会出现一些代码但都是伪代码级别重点让你看懂思路而不是背某个SDK的API。已经有基础的读者可以直接跳到第三章看实操或者直接看第五章的避坑清单。1. 核心概念拆解为什么RAG和Agent必须绑定学1.1 RAG给大模型开卷考试RAG全称是Retrieval-Augmented Generation翻译过来就是检索增强生成。一句话解释先让模型去知识库里查资料再基于查到的资料来回答问题。为什么需要这一步因为大模型本身的知识有天花板。训练数据截止时间之后的新闻、公司内部的产品手册、你自己写的笔记和文档这些内容模型一概不知道。可现实中最值钱的恰恰就是这些私域知识。另一个问题是幻觉模型在不确定的时候会一本正经地编答案错的也说得像真的。RAG就是用来同时解决“不知道”和“瞎编”这两个问题的。我常用一个类比来解释RAG它相当于给大模型开卷考试。闭卷考的时候模型全凭记忆答题记错了就只能编开卷考的时候它手里有资料答不出的题先翻书翻到再写答案。翻书这个过程就是“检索”照着资料写答案就是“增强生成”。RAG的完整链路其实就四步用户提问、知识库检索、资料塞进提示词、模型生成答案。看起来简单真正要做好每一步都有细节。检索质量直接决定回答质量这一步做得不好后面模型再怎么调都没用。所以我在后续实操章节里会重点讲检索这块怎么优化。1.2 Agent给模型配上手脚Agent直译是智能体但在开发语境下它更像是一个“能自己规划并执行任务”的程序。大模型只能输出文字这是它的核心能力但也限制了它的行动能力。你想让它查个数据库、算个报表、发个通知光靠对话是做不到的。Agent要解决的就是“模型只会说、不会做”的问题。理解Agent的关键是四个词规划、工具、记忆、反思。规划是指模型把一个大目标拆成几个小步骤工具是指模型通过调用外部函数来拿数据、做计算记忆是保存对话上下文和重要信息反思是模型在行动之后根据反馈调整下一步。举个小例子。用户说“帮我把这份销售数据整理成周报并发到群里”。一个Agent的实现流程是这样的先调用读文件工具拿到Excel数据再调用统计工具汇总销售额和环比然后用大模型生成周报文本最后调用群机器人工具发送消息。每一步都是模型自己决定该调哪个工具、按什么顺序调。我见过很多人把Agent理解为“调了几个API”这不全面。API调用只是工具层真正的Agent核心在于那个决策循环模型在每一步判断“我下一步该做什么”。这有点像老板安排任务员工领到任务后自己拆解、自己约人开会、自己交付结果而不是全程等老板一步步下指令。1.3 合体思路知识型Agent把RAG和Agent放在一个标题里不是营销话术而是它们天然互补。RAG解决知识来源Agent解决行动能力。一个成熟的应用往往两者都要。举个例子。某硬件公司的售后问答助手用户问“我用了半年的设备坏了能换新吗”。如果只有Agent没有RAG模型不知道这家公司的售后政策只能胡乱回答如果只有RAG没有Agent模型能查到政策但无法帮你发起换货流程。合体之后Agent先调用知识库检索工具查售后规则RAG返回“半年内非人为损坏可以换新”的依据Agent再根据规则判断用户是否符合条件最后调用工单接口帮用户登记。既懂知识又能办事。所以这篇内容的实战项目我也会刻意把两者揉在一起用RAG支撑知识检索用Agent来编排整个问答流程。建议你也按这个思路来设计自己的练习项目而不是分开学完后不知道怎么串。2. 从零到实战的技术栈全景2.1 第一层模型接入与提示词基础不管是RAG还是Agent最底层的东西都是模型调用。你不用研究模型训练但至少得会调接口、会写提示词。模型API的调用格式大差不差无非是传一个消息列表进去里面有系统角色、用户角色然后拿回模型生成的回复。伪代码大概长这样from llm_sdk import Client client Client( api_keyyour-key, modelyour-model ) resp client.chat([ {role: system, content: 你是知识库问答助手回答问题要简洁准确。}, {role: user, content: 产品A的保修期是多久} ]) print(resp.content)这段代码里有两个容易被新手忽略的关键点。第一是system系统提示词它定义了模型的角色和行为边界千万别省。第二是接口里的几个参数比如temperature控制回答的随机性做知识库问答时建议调低一些比如0到0.3之间能让回答更稳定减少胡编的概率。提示词工程在零基础阶段就要扎扎实实过一遍。核心就三条角色设定、任务边界、输出格式约束。你告诉模型“你是售后客服”比不说这句话的回答专业得多你要求它“只依据资料回答资料没有就说不知道”能直接砍掉大半幻觉问题你规定“用列表输出”它就不会给你写一大段散文。这些基础能力后面全都要用上。2.2 第二层RAG核心组件拆解RAG的技术栈可以拆成五个环节文档加载、文本清洗、分块、向量化、检索与重排。每个环节都有对应的工具和注意点。文档加载就是把PDF、Word、Markdown等格式的文件读出来。这里有个常见的坑PDF里的表格经常被读成乱序文本目录和页眉页脚也会混进来。加载完之后要先做清洗把这些噪音去掉否则后面检索到的基本都是页眉页脚这种垃圾内容。分块是整个RAG里最影响效果的一环。一般做法是按固定长度切块同时设置重叠区域。为什么需要重叠因为语义可能横跨两个块没有重叠信息就被切断了。我常用的参数是块大小512字符左右、重叠64字符左右然后根据文档具体情况微调。这有点像切肉不切就下锅太大不入味太小又容易烂。切得太短语义不完整切得太长检索到的噪声就多。向量化是RAG的数学基础。你要把一段文本转成一长串数字组成的向量让语义相近的文本在向量空间里距离更近。我们可以用一个现成的开源向量模型来做这件事不需要自己训练。向量数据库负责存储这些向量并在查询时用相似度计算快速找到“语义最接近”的文本片段。检索环节最推荐的是混合检索把关键词检索和向量检索结合。关键词检索擅长匹配“订单号”“型号HW-2000”这种精确词向量检索擅长匹配“换货需要什么条件”这种语义相近但字面不同的查询。两者结合覆盖更全面。检索完之后还建议加一步重排用一个精排模型把候选结果重新排序把最相关的几条排到前面。后面实战章节我会展开讲。2.3 第三层Agent核心组件拆解做Agent最大的认知转变是你不再写“一步步怎么做”的命令式代码而是在配置一个“模型可以自主决策”的环境。这个环境里最关键的是工具定义。每个工具要告诉模型三件事工具叫什么、是干什么的、需要传什么参数。模型看到工具列表后会自己决定要不要调用、调用哪个、传什么值。所以工具描述写得好不好直接决定Agent靠不靠谱。tool { name: knowledge_search, description: 当用户询问产品参数、退换货规则、使用说明时调用此工具检索知识库。, parameters: { type: object, properties: { query: { type: string, description: 用户问题中的核心关键词尽量精简 } } } }写工具描述有个经验不要写得模棱两可。你写“查询知识库”模型可能什么都往这个工具上靠你写清楚“适用于产品参数、售后政策类问题”模型就知道天气询问不需要走这个工具。Agent主循环也很经典逻辑就是一个循环把消息列表发给模型看模型返回的是文字还是工具调用意图。如果是工具调用意图就去执行对应工具把返回结果追加进消息列表再让模型继续决策如果是文字说明任务已经完成跳出循环。messages [{role: system, content: system_prompt}, {role: user, content: user_question}] for step in range(max_steps): resp model.chat(messages) if resp.has_tool_call(): for tc in resp.tool_calls: result execute_tool(tc.name, tc.arguments) messages.append(tool_result_message(tc, result)) else: final_answer resp.content break这个循环在工程上并不复杂难点在于让模型“该调工具时调工具该结束时结束”。很多新手第一次跑Agent会看到一个现象模型反复调用工具停不下来。这不是代码问题多半是系统提示词里没有写清楚结束条件或者工具描述太宽泛。2.4 技术选型建议入门组合与进阶方向很多人纠结“该用哪个框架、哪个模型”我的建议是刚开始不要追求新追求稳定可复现。下面我按入门和进阶两档给出一套参考选型。选型项入门推荐进阶推荐说明大模型任何主流的商用API模型开源模型本地部署入门先用API成本低、不用调环境进阶考虑数据隐私和成本再上本地部署向量模型某开源轻量语义向量模型领域微调过的向量模型通用领域选轻量模型垂直领域用微调模型效果更准向量数据库本地文件型向量存储独立向量数据库服务入门数据量小用文件型最方便数据量大再切换Agent编排手写主循环使用开源编排框架手写一遍主循环有助于理解原理业务复杂再用框架提效选型的原则就一条能用简单的就别上复杂的。有的同学一上来就搭了一整套分布式架构最后发现数据量只有几千条纯属给自己找麻烦。技术选型是服务于场景的不是用来炫技的。3. 手把手实战做一个带知识库的售后问答Agent3.1 目标确定与技术方案我们这次要做的项目我称之为“某硬件产品售后问答Agent”。知识库资料包含产品手册和退换货规则用户可以通过自然语言问售后政策Agent不仅要回答准确还要标注出处。同时Agent还要处理一类复合任务比如“把客服需要知道的产品规则整理成速查表”这时候它需要先检索多份文档再汇总生成。整体技术方案分两层RAG层负责检索知识库Agent层负责编排回答流程。我们把检索功能封装成一个工具挂到Agent底下。当用户问售后政策时Agent调用这个检索工具获取资料再基于资料回答。当用户要求整理速查表时Agent会连续多次调用检索工具拿到多个板块的资料后统一汇总。3.2 数据准备与索引构建做RAG项目数据准备往往比写代码更耗时。我们假设手头有3份PDF产品说明书、快速上手指南、售后政策声明。第一步先加载并清洗处理掉PDF里的页眉页脚、乱码和表格错位。documents load_documents([manual.pdf, quick_start.pdf, policy.pdf]) cleaned clean_documents(documents) # 去除页眉页脚、修正表格错位 chunks split_chunks(cleaned, size512, overlap64) vectors embed_documents([c.text for c in chunks]) vector_store.add(vectors, metadata[{source: c.source, page: c.page} for c in chunks])参数的选择说下我的思路。size512意味着每个文本块大概容纳512个字符这个长度能装下一个完整的知识点段落又不会太长导致检索时混入太多无关信息。overlap64表示相邻块之间重叠64个字符保证跨块的信息不丢失。比如售后政策里有一句话横跨两个块没有重叠检索时只能找到半句话答案自然不完整。保存metadata是我强烈建议做的一件事。每个块存了来源文件名和页码这样最后回答时可以附上出处用户能对照原文验证可信度完全不同。3.3 检索与重排序检索接口不能只做简单的向量相似度查询我推荐用“混合检索重排”的组合拳。先通过关键词和向量两个通道各取候选集合并去重后多取一些比如20条再用精排模型把最相关的3到5条筛出来。def knowledge_search(query, top_k3): # 混合检索初筛取较宽的候选 candidates hybrid_search(query, top_k20) # 精排模型重新排序 reranked rerank(query, candidates) # 只取最相关的结果返回 return reranked[:top_k]为什么要先宽后窄因为向量检索和关键词检索各有盲区。向量检索可能漏掉“型号HW-2000”这种精确匹配关键词检索可能漏掉“换货流程”这种同义表达。先各取一批合并再用精排模型统一排序能最大化召回率。这个流程跑下来检索准确率通常能提升不少。3.4 定义Agent工具与主循环RAG这层准备好后把它封装成Agent工具。这里要把工具描述写得足够精确模型才能准确判断何时该调用。我实际用的工具描述大概这样tools [ { name: knowledge_search, description: 检索产品手册与售后政策知识库适合产品参数、使用方法、退换货规则、保修政策类问题, parameters: { type: object, properties: { query: {type: string, description: 用户问题中的核心关键词尽量精简例如退货条件} } } } ]主循环沿用第二章里的逻辑。用户问“保修期是多久”Agent会输出一个工具调用意图我们执行这个工具把检索到的文本追加到消息列表模型再基于这些资料生成回答。这里有个细节检索结果追加到消息里时要明确标识出“这是资料不是模型的历史回答”否则模型会混淆哪些是它自己说的、哪些是外部资料。3.5 提示词模板与回答生成最后一步是把检索到的资料组装成提示词。经验是给模型明确的规则只依据资料回答、每个事实标来源、资料里没有就直说不知道。模板如下你是一名售后问答助手。请根据【参考资料】回答用户问题。 【参考资料】 [1] 《产品说明书》第12页该产品保修期为一年因质量问题可免费维修。 [2] 《售后政策声明》第5页非人为损坏且在保修期内支持换新。 【要求】 1. 只能依据参考资料回答如果资料中没有答案直接回复“根据现有资料未找到相关信息”。 2. 每个事实点后面标注来源编号例如[1]。 3. 回答控制在5句话以内简洁清晰。 用户问题设备用了两个月坏了能换新吗模型返回的效果大概是“根据售后政策在保修期内因质量问题可免费维修[1]非人为损坏且在保修期内支持换新[2]。建议您通过客服渠道提交检测申请。”这样回答既准确、有依据又具备可操作性。这一步就是RAG与Agent结合的最终成果Agent调度工具完成检索RAG提供可靠的资料模型完成最终表达。整个流程不算复杂但每个环节都有优化空间接下来我把容易踩的坑单独拎出来讲。4. 免费资源清单与获取指南4.1 免费学习资源的正确获取思路先说结论免费资源真的很多多到泛滥但大多数新手不是缺资源而是缺筛选标准。我见过太多人收藏夹里躺着一百多个链接最后真正打开的没几个项目连目录都没建起来。我的建议是先定一个小项目目标再按目标去找资源。目标可以很朴素“我要用RAG做一个个人文档问答工具”。有了这个目标资源就自动分成了三类官方文档用来查基础语法、教程博客用来理解整体流程、开源项目用来临摹别人怎么组织代码。三类资源各找一两份高质量的就足够起步了不需要囤。找代码示例时优先选“能跑通的完整项目”而不是零散的讲解片段。判断标准很简单仓库里要有完整的代码目录结构、依赖清单和可读文档最好最近还在更新维护。那种只有一堆介绍文字、没有可运行代码的资料先放一边。4.2 开源项目与代码库怎么找开源项目是学RAG和Agent最直接的素材。我不建议一开始就啃大型项目几千行代码会把你淹没。更适合入门的是那种几百行代码、聚焦核心流程的教学型项目。搜索关键词我给你列几个直接去代码托管平台搜就行“RAG tutorial”“document question answering”“agent basic demo”“knowledge base chatbot”。搜出来之后按三个标准筛star少一点的反而更好读懂、有中文注释或文档的更友好、依赖不要太多的更不容易卡环境。拿到项目之后我建议做三件事第一把项目跑起来确认输入输出第二读懂主循环和检索流程这两个核心模块其他可以先不管第三改一个功能比如把知识库从“食品百科”换成“产品手册”看看到底能不能跑通。能完成这三步这个项目就真正变成你的能力了。4.3 数据集去哪里找RAG项目需要一份像样的知识库数据来做练习。如果你手头没有现成的文档可以去开放数据平台找现成的问答语料。搜索关键词推荐“知识库问答”、“百科问答”、“开放领域问答”。选数据集时有一条红线仔细看开源协议。有些数据集只允许研究用途不能商用用在实际项目前必须确认许可。数据质量也要看至少要有几千条数据、问题与答案一一对应那种一堆杂乱文本的数据集清洗成本太高新手容易劝退。如果只想快速验证流程我还有个土办法把自己电脑里的几份PDF丢进去当知识库比如产品说明书、论文、合同模板都行。用自己熟悉的材料做验证的好处是你比模型更懂正确答案调优时容易判断检索到底准不准。4.4 免费资源怎么配合学习路线我给零基础同学建议的学习顺序是这样的第一周只学提示词和模型调用目标是写一个能稳定输出的对话机器人第二到第三周做RAG目标是把文档索引起来并能检索第四周做Agent目标是把工具调用跑通最后一周把RAG和Agent合并做一个小项目收尾。每个阶段只盯一份资源跑通了再换下一个。你会发现后面阶段的资源看起来比前面简单因为你的理解力已经上来了。免费资源最大的问题不是不够而是会让人产生“收藏了就学会了”的错觉。资源拿来用才有价值放在收藏夹里只是缓解焦虑。5. 新手最容易踩的坑与排查方法5.1 检索出来的内容牛头不对马嘴这是RAG项目最经典的翻车现场。用户问“退货流程”检索出来一堆“安装步骤”。先说原因大概率是这三类问题之一分块切碎了关键信息、向量模型不适合这个领域、混合检索的权重没调好。排查方法很简单把检索接口单独拎出来调试打印每一次检索命中的原始片段直接肉眼看。如果片段本身语义就不相关先查向量模型如果片段相关但被切得七零八落回去调分块参数如果单路检索都准但混合之后反而变差就两路分别看结果适当降低噪声大的那一路权重。不要同时改一堆参数一次只调一个变量不然永远不知道是哪个改动起了作用。5.2 回答和检索内容明显矛盾有时候检索出来是对的但模型回答却跑偏了。这通常不是模型笨而是提示词约束不够。我在实战里遇到过模型不看资料、凭自己记忆回答的情况后来在提示词里加了一条“只依据参考资料回答参考资料没有的内容一律禁止输出”问题立刻改善。还有一个容易被忽略的问题检索结果里塞进了大量不相干片段模型在长上下文里不知道该信哪条。解决办法是精简Top-K我们实战里只保留3条最多不超过5条。条数太多模型会被无关信息带偏条数太少可能漏掉关键信息。给模型提供明确“信源优先级”也很有效比如“编号靠前的资料优先级更高”。5.3 Agent陷入循环调用工具我第一次跑带工具的Agent时遇到过模型一直在调用知识搜索工具搜完又问“还需要更多信息吗”然后继续搜。最后我加了两个约束循环立刻停止。第一个约束是“最大调用次数上限”代码层面写死比如最多调用8次工具超出就强制返回当前结果。第二个约束是在系统提示词里写明“只有在资料不足以回答用户问题时才允许检索有足够信息时直接给出最终答案”。工具调用失败的情况也要提前兜底。如果工具报错把错误信息返回给模型让它决定是换个参数重试还是告知用户“暂时无法获取相关信息”。不要直接抛异常打断循环那样用户的体验会很差。5.4 成本与延迟失控Agent比普通问答烧钱这是共识。每次工具调用都是一次模型往返一个复杂任务可能产生5到10次调用账算下来很可观。控制成本有几个思路缓存重复问题热门问题的答案直接复用精简提示词和检索内容减少每次请求的Token数能用一个工具完成的绝不拆成两个工具。延迟也是一样。RAG场景下最大的耗时不在模型而在文档加载和向量检索。文档加载要做缓存向量数据库索引要建好不要把每次用户提问都触发一次全量文档加载。这些优化项目上线后特别关键前期练习时至少要有这个意识。为了让你排查起来更快我把常见问题整理成一个速查表。现象常见原因排查方法解决思路检索不相关分块不当、向量模型不匹配打印检索中间结果肉眼检查命中片段重分块、换向量模型、调混合检索权重回答与资料矛盾提示词缺少约束、检索Top-K过大审查系统提示词检查上下文是否塞入杂质明确“只依据资料回答”精简上下文条数Agent反复调工具工具描述宽泛、缺少结束条件查看模型每步的决策日志细化工具描述设置调用上限写清结束条件成本快速上涨调用次数多、无缓存统计一次完整任务的模型调用数加缓存减少工具拆分精简提示词答案没有出处未保存文档元信息检查向量库是否存了来源与页码索引时保存metadata提示词要求标注来源编号6. 我的几个实操体会与建议6.1 数据清洗比想象中更重要做过的RAG项目越多越会承认一个道理项目的天花板由数据质量决定而不是由模型决定。清洗数据花的时间经常比写代码还多。页眉页脚、OCR乱码、表格错位这些看似小问题最终都会变成检索里的噪声。如果你准备做自己的第一个RAG项目我建议把三分之一的时间预算留给数据准备这不是浪费。6.2 稳定输出靠约束不靠运气很多人觉得Agent效果不稳定是模型不够聪明其实大部分情况下是约束写得不够细。我调试过上百次模型输出发现只要把行为边界写清楚把工具触发条件写具体把输出格式约束明确稳定率会明显提升。你要像给一个新人写岗位说明书一样写提示词哪里该做、哪里不该做、做到什么程度算完成全写出来。模型比大部分新人执行力强前提是你把边界画清楚。最后再说一个实用小技巧。调试RAG和Agent项目时一定要保留“中间过程日志”。把每次检索命中了什么、模型调用了哪个工具、返回了什么结果统统记录下来。出问题时不用靠猜翻日志就能定位。这也应该是所有人做这类项目的习惯记录过程永远比事后复盘省时间。
阅读完成 · 觉得有帮助？
