企业官网建设流程全解析

最近带项目的时候，被问得最多的两个词，一个是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_key="your-key", model="your-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 技术选型建议：入门组合与进阶方向

很多人纠结“该用哪个框架、哪个模型”，我的建议是刚开始不要追求新，追求稳定可复现。下面我按入门和进阶两档给出一套参考选型。

选型的原则就一条：能用简单的就别上复杂的。有的同学一上来就搭了一整套分布式架构，最后发现数据量只有几千条，纯属给自己找麻烦。技术选型是服务于场景的，不是用来炫技的。

3. 手把手实战：做一个带知识库的售后问答Agent

3.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, size=512, overlap=64) vectors = embed_documents([c.text for c in chunks]) vector_store.add(vectors, metadata=[{"source": c.source, "page": c.page} for c in chunks])

参数的选择说下我的思路。size=512意味着每个文本块大概容纳512个字符，这个长度能装下一个完整的知识点段落，又不会太长导致检索时混入太多无关信息。overlap=64表示相邻块之间重叠64个字符，保证跨块的信息不丢失。比如售后政策里有一句话横跨两个块，没有重叠，检索时只能找到半句话，答案自然不完整。

保存metadata是我强烈建议做的一件事。每个块存了来源文件名和页码，这样最后回答时可以附上出处，用户能对照原文验证，可信度完全不同。

3.3 检索与重排序

检索接口不能只做简单的向量相似度查询，我推荐用“混合检索+重排”的组合拳。先通过关键词和向量两个通道各取候选集，合并去重后多取一些，比如20条，再用精排模型把最相关的3到5条筛出来。

def knowledge_search(query, top_k=3): # 混合检索初筛，取较宽的候选 candidates = hybrid_search(query, top_k=20) # 精排模型重新排序 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场景下最大的耗时不在模型，而在文档加载和向量检索。文档加载要做缓存，向量数据库索引要建好，不要把每次用户提问都触发一次全量文档加载。这些优化项目上线后特别关键，前期练习时至少要有这个意识。

为了让你排查起来更快，我把常见问题整理成一个速查表。

6. 我的几个实操体会与建议

6.1 数据清洗比想象中更重要

做过的RAG项目越多，越会承认一个道理：项目的天花板由数据质量决定，而不是由模型决定。清洗数据花的时间，经常比写代码还多。页眉页脚、OCR乱码、表格错位，这些看似小问题，最终都会变成检索里的噪声。如果你准备做自己的第一个RAG项目，我建议把三分之一的时间预算留给数据准备，这不是浪费。

6.2 稳定输出靠约束，不靠运气

很多人觉得Agent效果不稳定是模型不够聪明，其实大部分情况下是约束写得不够细。我调试过上百次模型输出，发现只要把行为边界写清楚，把工具触发条件写具体，把输出格式约束明确，稳定率会明显提升。你要像给一个新人写岗位说明书一样写提示词，哪里该做、哪里不该做、做到什么程度算完成，全写出来。模型比大部分新人执行力强，前提是你把边界画清楚。

最后再说一个实用小技巧。调试RAG和Agent项目时，一定要保留“中间过程日志”。把每次检索命中了什么、模型调用了哪个工具、返回了什么结果统统记录下来。出问题时不用靠猜，翻日志就能定位。这也应该是所有人做这类项目的习惯，记录过程永远比事后复盘省时间。