企业官网建设流程全解析

说实话，最近这段时间，我被问得最多的问题，不是怎么写代码，而是“LLM、RAG、AI Agent这三个词到底是什么”。身边不少朋友刷到相关文章，第一反应几乎一模一样：每个字都认识，连起来不知道在说什么。更夸张的是，有些科普内容把技术原理写得比高数课本还长，看完直接想放弃。所以我决定换个路子，全程只用大白话和生活里常见的例子，把这三个概念拆开揉碎讲清楚。哪怕你没有任何编程基础，也能在15分钟里弄明白它们分别是什么、能干什么、怎么配合着干活。为了照顾从来没接触过的读者，我会尽量做到小学生也能听懂，不堆术语，不炫技，只讲人话。

1. 先别慌：LLM、RAG、AI Agent到底是什么

1.1 LLM：一个超级强大、但记性有限还会瞎编的“接龙大师”

LLM的全称是Large Language Model，中文叫大语言模型。名字听着吓人，但它的核心原理特别朴素——本质上就是一个“接龙游戏选手”。你给它一句话的前半段，它负责预测后半段最可能出现的文字。

这样说可能太抽象，我举个例子。你输入“床前明月”，一个训练合格的LLM大概率会接出“光”字。你输入“举头望”，它大概率会接出“明月”。你输入“张三今天迟到了，老板很”，它可能会接“生气”或者“不满”。你看，它做的就是一件事：根据前面已经出现的内容，推断下一个词最该是什么。

那为什么它看起来什么都懂？因为它训练时读过的文本量极其庞大，可能读完了互联网上公开的、人类写过的大部分文字。读得多了，它就把语言的规律、知识的片段、逻辑的走向，全都“压缩”进了自己的参数里。这就像一个在图书馆里泡了十年的人，你问它任何话题，它都能顺着记忆里的文本接上几句话，听起来还挺像那么回事。

但是这里有个巨大的坑，很多人没意识到：LLM的记忆是有截止日期的。它训练时用的数据是过去某个时间点的，今天刚发生的事情，它多半不知道。你问它最新的赛事结果，它会一本正经地给你编一个。因为它不联网，也没法实时获取信息，它在不知道答案的时候，会选择“顺着最可能的字眼往下接”，而不是像搜索引擎那样说“我没有”。这种现象在行内叫“幻觉”。

我们可以把LLM想象成一个记忆力超强、但完全活在自己世界里的老朋友。它聊天很厉害、写文章很厉害、翻译很厉害，但只要你问到它知识边界之外信息的细节，它就可能给你编一个看起来合理但实际上错误百出的答案。更麻烦的是，它每次编出来的答案都语气笃定、结构严谨，像是真的查过资料一样，你很难单凭文本内容分辨真假。

所以在实际用LLM的时候，你要时刻记住两件事：第一，它能帮你处理的是“语言表达”这件事本身，比如润色文字、总结段落、起草邮件；第二，它不能直接当作“事实数据库”来用，尤其是那些会变化的、时效性强的信息。这也是后面RAG要登场的原因。

1.2 RAG：给大模型配一个“开卷考试”的资料架

RAG的全称是Retrieval-Augmented Generation，中文叫检索增强生成。这个名字很拗口，但拆开就说白了：检索、增强、生成。它解决的核心问题，正好是LLM最大的短板——不知道、记不住、还爱编。

想象一下，LLM原本是个闭卷考试的学生，脑子里装着训练时学过的旧知识。你把它丢进考场，问它一个它没见过的题目，它只能硬着头皮瞎写。RAG要做的事情很简单：在考试前帮它把该看的资料准备好，让它变成开卷考试。它不再凭记忆硬编，而是先去你的资料库里翻找相关的内容，找到之后把那些内容塞进它眼前，让它在参考这些材料的基础上来回答你。

具体流程拆开来看，可以分成四个步骤。第一步，把你要用到的文档，比如产品手册、客服对话记录、内部规章制度，按照合理的大小切成一个个“片段”。第二步，把这些片段通过一种叫嵌入（Embedding）的技术转成向量——你可以理解成给每段文字生成一个代表语义特征的“指纹”。第三步，把这些指纹连同原文一起存进一个专门的向量数据库里。第四步，用户提问时，系统把问题也转成指纹，然后去数据库里搜索最相似的几个片段，连同原始问题一起提交给LLM，让它基于这些片段作答。

用个生活化的类比：你有一个装满便签纸的抽屉，每张便签纸上写着一条知识。现在有人问你一个问题，你不是凭空回答，而是先去翻抽屉，抽出最相关的三五张便签纸，然后照着便签纸上的内容组织语言回答。抽屉就是知识库，翻抽屉的过程就是检索，照着便签纸回答的部分就是生成。

RAG最大的价值，是让LLM的回答开始“有据可查”。因为它在回答时参考了你传入的资料，而不是猜测。这样一来，知识库可以随时更新，今天改的资料明天就能生效；回答也不再那么容易瞎编，因为模型手里有参考答案。更重要的是，你可以追踪答案来自哪份资料，这对企业内部场景来说太关键了。

不过也要说清楚，RAG不是万能的。它相当于给模型提供了参考资料，但模型本身的推理能力并没有变强。如果你问的是一个需要多份资料联合推理的复杂问题，它可能把上下文搞混、把资料拼错。它解决的是“信息来源”问题，解决不了“深度思考”问题。

1.3 AI Agent：给大模型装上手脚的“自主小员工”

AI Agent，中文叫智能体，是我认为目前被讲得最玄乎的概念。有人把它吹成堪比科幻小说里的机器人，也有人把它说成只是一个聊天窗口。实际它没那么神，但确实比单纯聊天的LLM更进一步。如果LLM是一个只会说话的“嘴强王者”，那Agent就是一个“还能动手办事”的实习生。

这个实习生的特点是什么？你给它一个目标，它不会只回复你一段建议，它会自己把目标拆解成步骤，自己决定先做什么后做什么，自己调用工具去执行，然后观察执行结果，如果发现不对，就调整策略再来一次，直到任务完成。

我举例子你就明白了。如果你让一个纯LLM“帮我订一间周五下午三点的会议室”，它大概率会给你回一篇小作文——《关于如何预订会议室的步骤指南》。你说荒谬不荒谬？你明明只想让它订个会议室，它却给你写了一份说明书。但如果你让一个Agent来做同样的事，它会自己去打开日历系统，查看周五下午三点有哪些房间空着，然后帮你发出预订邀请，确认收到回执之后，再告诉你结果。

这种差距的关键，在于Agent拥有“调用工具”的能力。它可以通过代码接口操作日历、发送邮件、查询地图、读写文件、访问网站。LLM只负责生成文字，Agent则把文字背后的意图变成了实际的系统操作。它就这样从“能说”升级到了“能做事”。

Agent的内部工作机制，可以简单理解成一个循环：思考、行动、观察、再思考。第一步思考，规划接下来应该采取什么动作；第二步行动，调用某个工具完成任务；第三步观察，看看工具返回的结果是否达到预期；然后回到第一步，根据观察结果决定下一步。整个过程不断循环，直到最终目标完成。

所以你看，Agent并不是一个比LLM更聪明的模型，而是一个围绕LLM搭建的“框架”。它负责把大模型装进一个能做事的外壳里，给它手、脚和眼睛。目前市面上主流Agent产品，基本都是这个思路。理解这个定位很重要，因为很多人误以为Agent是灵丹妙药，其实它只是LLM的执行层。

2. 一句话讲清三者的协作关系：大脑、外挂记忆、操作手脚

2.1 用一次“周末亲子游攻略”任务串起它们

很多人看了三个概念之后更晕了，因为他们发现市面上很多工具既像LLM又像RAG还像Agent，完全分不清谁是谁。别急，我带你跑一个真实的场景，你一下就通了。

假设你周末要带娃出去玩，想让AI帮你安排一个半日游计划，要求适合小学生、有室内备选、还能顺便解决午饭。这时候Agent先把任务接手了。它会把你的大目标拆成小任务：查周末天气、找三个适合亲子的场馆、看各场馆的门票和开放时间、规划午餐地点。

拆解完之后，Agent开始调用工具：天气接口获取周末天气预报，同时触发了RAG流程。RAG去资料库里检索“室内亲子场馆”相关的文档，把搜出来的场馆信息、用户评价、开放时间作为参考资料交给LLM。LLM拿到这些资料后，负责把这些碎片信息组织成一份通顺、对人友好的行程建议草案。

如果Agent发现其中一个场馆周日闭馆，它会看到RAG返回的检索结果里写着“周日休息”，于是重新调整方案，再让LLM生成新的推荐。最终，一份带着天气提醒、备选方案、餐厅指南的攻略就交到你手里了。全程不需要你反复追问和提醒。

在这个例子里，RAG的作用是提供知识：场馆在哪、开放时间是什么、口碑如何。LLM的作用是组织和表达语言：把资料写成可读、自然的建议。Agent的作用是全程规划和调度：决定先查什么、发现行不通就换一条路、确保最后任务被完成。三者各司其职，缺一个都会出问题。

如果只有LLM，它可能把场馆信息编得像模像样，但实际开门时间是错的。如果只有RAG和LLM，你能拿到一篇不错的回答，但没法触发工具去查实时天气，也没法自动调整计划。如果只有Agent没有RAG，它执行时缺少可靠的知识支撑，规划出来的东西还是空中楼阁。

所以记住这三个词各管一摊：知识归RAG，表达归LLM，执行归Agent。理解到这个程度，就够你日常使用了。

2.2 用一张对照表看懂边界：知识、语言与行动

我再给你一个更直观的拆法。LLM解决的是“话说得好不好”，RAG解决的是“知识从哪来”，Agent解决的是“活谁来干”。这三个问题其实完全互相独立，只是在实际产品里被揉在了一起。

有时候你会发现某个产品宣传自己是“Agent”，实际上它只是套了一层很薄的规划壳子，核心还是LLM生成；另一个产品宣传自己是“RAG”，但它也加入了简单的工具调用。这很正常，商业产品不会严格按学术分类来取名。但对你来说，理解边界特别重要，因为在排查问题时你得知道是哪个环节出了岔子。

这里做一张表，建议你存下来对照使用。

看到没有，这三个东西根本不是一个维度上的。LLM是一种模型，RAG是一种技术方案，Agent是一种应用架构。你可以有LLM但没有RAG，也可以有RAG但不叫Agent，当然更可以三者叠加组成完整产品。市面上你看到的那些“AI客服”“AI助理”，几乎都是把这三样组合在一起用的。

理解完这些边界，你再看任何一篇讨论AI应用的文章，都不会再被术语绕晕了。当有人说“我们的产品用了Agent架构”，你可以直接问他：底层知识库走的是RAG吗？工具调用最长循环几轮？错误怎么兜底？他要是答不上来，说明被忽悠的可能是他。

3. 15分钟手把手跑通：从“纯聊天”到“带知识库回答”

3.1 先花5分钟，搭一个最简RAG问答演示

前面讲的都是原理，接下来我带你亲手搭一个能用的最小RAG系统。放心，不需要你写多复杂的代码，重点是把流程跑通、把每个环节的感受建立起来。你甚至不需要完全看懂代码，照着做就行。

我这里用一套非常朴素的伪代码来说明整个流程，实际工程中用到的库名不重要，关键是理解管道结构：

# 第1步：准备知识库文档 # 假设你有一份"公司请假制度.txt"，里面写着各种请假规则 docs = load_documents("公司请假制度.txt") # 第2步：把长文档切成小片段 chunks = split_text(docs, chunk_size=200) # 第3步：把每个片段转成向量(embedding)，并存入向量数据库 for chunk in chunks: vector = embedding_model.encode(chunk) vector_db.add(vector, metadata={"source": chunk}) # 第4步：用户提问时，先检索相关资料，再让LLM回答 def ask_question(user_question): question_vector = embedding_model.encode(user_question) related_chunks = vector_db.search(question_vector, top_k=3) context = "\n".join(related_chunks) prompt = f"请根据以下资料回答问题：\n{context}\n\n问题：{user_question}" return llm.chat(prompt)

你仔细看这四步，会发现RAG的本质其实特别简单：把知识库提前准备好，把用户的问题变成搜索条件，找到相关的片段，塞进提示词里让LLM回答。整个过程中LLM甚至不知道自己“查过资料”，它只是拿到了一段文字，然后根据这段文字组织回答。

我在刚开始接触这个领域时犯过一个错误：总以为RAG是某个复杂的框架，非得装一堆依赖库。后来才明白，RAG的核心思想或许可以用一句话概括：先搜索，后回答。那些眼花缭乱的产品，本质都在做这个事，只是把搜索做得更好、更准、更快。

如果你只是想快速体验，完全可以跳过代码这一步。市面上不少现成的问答工具都支持上传文档后直接问答，上传一份PDF，它会自动解析、切片、存库，你只要输入提问就能体验RAG的效果。但我想让你理解的，是背后这个“先检索再回答”的逻辑，否则工具换了壳你又不认识了。

3.2 三个关键参数，决定了你的RAG好不好用

搭建只是第一步，真正决定体验的是参数调优。我调过不少RAG系统的参数，发现新手最容易困惑的就是这三个：切片大小、Top K值、温度。我一个个说，每个都配上生活化解释。

第一个是切片大小，也就是chunk_size。它决定你切文档片段的时候，每段多长。切太小了，比如50字一个片段，信息碎片化严重，检索到的片段可能只有半句话，缺少上下文；切太大了，比如3000字一个片段，里面挤满了无关内容，既浪费向量存储空间，又容易让检索结果不够精准。我比较常用的是200到500字。这个值没有正确答案，取决于你的文档风格。拿臣子比喻，切片就像切菜，切太碎炒出来一坨糊，切太大又不好入味，你得根据食材本身调整。

第二个是Top K值，也就是检索后要取多少个相关片段送进去。K值太小，比如K=2，容易漏掉关键信息；K值太大，比如K=10，会把一堆噪音塞进提示词里，不但浪费Token，还容易让LLM把回答问题变成“摘抄资料”。一般场景K设为3到5就够。尤其是你的知识库文档质量参差不齐时，宁可小一点，也别让模型被不相关内容带偏。

第三个是温度，也就是temperature。它控制LLM回答的确定性。温度越低，回答越保守稳定，几乎每次输出都差不多，适合事实性问答、信息抽取这类任务；温度越高，输出越有创造性，但出错和跑偏的概率也会变大。做RAG问答时，我倾向于把温度调到0到0.3之间。写文案任务可以调到0.7以上，但做知识库问答时你肯定不希望模型自由发挥。

我把常用参数范围整理成一张表，方便你参考：

如果你在实际调试时发现回答质量差，不要急着换模型，先检查这三个参数。很多时候不是模型不行，而是资料压根没被检索到，或者塞进提示词的片段本身就不对。先调切片和Top K，最后再动温度，因为温度对事实准确性的伤害是最直接的。

3.3 再花10分钟，看看加入Agent之后会有什么不同

RAG系统跑通之后，你再想象一个场景：你不再满足于“问一句、答一句”，而是想让AI帮你完成一个连贯的任务，比如“把上周的客户反馈整理成一份周报，然后发给团队所有人”。这时候纯RAG就不够用了，因为RAG只能查资料和回答，它不会主动去翻聊天记录、不会自动整理表格、更不会点发送按钮。你需要的是Agent。

Agent接到任务后，首先会做一个规划。它把“整理周报”这个大目标拆成几个子任务：获取上周的客户反馈数据、分析常见问题、生成周报正文、查找团队成员的邮箱列表、调用邮件服务发送。每一个子任务都是一次独立的“思考-行动-观察”循环。

比如在“获取反馈数据”这一步，Agent会先调用一个查询接口，从CRM系统拉数据。它看到返回的数据格式是原始的、包含大量重复内容，就开始下一步“整理重点”，把重复项合并，把问题分类。然后再调用LLM生成周报草稿，让RAG从历史周报模板库里检索一篇格式参考，最后由LLM按模板格式输出。

整个过程Agent就是那个“监工”，每一步都在检查结果：如果数据没拉成功，它就换个接口重试；如果周报格式不对，它就让LLM重新生成。所有跟“执行动作”有关的部分，比如调用接口、发邮件、操作文件，都是Agent的能力边界。相比之下，纯RAG只停留在“给你一份参考资料”的层面。

需要提醒的是，Agent虽然能干，但它并不一定可靠。一是容易陷入死循环：可能同一个失败的操作反复重试，不加以限制就白烧预算。二是成本问题：每一步循环都要调用模型，Token消耗会比单纯问答高好几倍。三是不可预测性：模型决策有点随机性，同样任务跑两次可能策略完全不同。

我的建议是，如果你要搭Agent，一定要给它设定最大轮数。比如规定循环最多执行5次，超过就停止并向上报错。同时，把它能调用的工具限制在一个白名单里，别让一个客服机器人能删数据库。这些听上去像废话，但实际踩过坑的人会明白，失控的Agent带来的麻烦远比它解决的问题多。

4. 新手最容易踩的坑：问题排查与选型建议

4.1 这几个常见问题，我基本都踩过

随便问你一句：“如果你的RAG问答系统回答了一个明显错误的信息，你觉得问题出在哪？”大多数新手会回答“模型不行”。但根据我调试的经验，实际原因往往五花八门：文档压根没进知识库、检索词和文档措辞差太远、Top K太小导致正确答案没被召回、切片切乱了上下文、温度太高模型放飞了等等。

这里给出一份排查速查表，遇到问题先对照一遍，比瞎改参数高效得多。

我记得有一次，一个开发者的RAG问答系统死活答不对某个问题。一开始怀疑是Embedding模型不够好，换了好几个，效果还是不行。最后打开日志一看才发现，那份文档导入时因为格式特殊，内容被吞了大半，知识库里的原文残缺不全。那不是模型的问题，是数据源的问题。

所以请你记住这个排查顺序：先查数据源，再查检索结果，最后才查模型和参数。数据没有入库，后面调什么都白搭。很多看上去玄学的故障，最后都出在最基本的数据准备环节。

4.2 什么时候别用RAG，什么时候别用Agent

聊完了“怎么用”，我还想聊一下“什么时候别用”。因为技术选型这个东西，最怕的就是什么热门用什么，不管合不合适。我用得越多越确信：RAG和Agent都不是默认选项，而是特定场景下的解决方案。

RAG不适合的场景，至少有两种。第一种是知识高度结构化的情况，数据都在数据库表里，字段关系明确，直接查数据库拿结果，比RAG走一圈要准得多。第二种是问题需要跨大量文档进行多步推理的场景，比如“找出近三个月所有与某个客户的合同纠纷并分析共性”，这种问题RAG召回片段会非常碎片化，模型断章取义的概率很大。RAG适合的，是“答案藏在某个具体文档段落里、需要被找出来”的任务。

Agent不适合的场景就更多了。凡是要求绝对可靠性和零容错的流程，比如资金支付、医疗剂量计算，我强烈不建议一上来就让Agent全权决策。还有成本敏感的场景，Agent每一步都要调模型，复杂任务多轮循环下来费用惊人，如果任务本身用简单脚本十行代码就能搞定，真的没必要上Agent。Agent适合的是那些需要灵活判断、工具多、且允许出错重试的任务，比如资料整理、行程规划、代码生成后的检查修复。

你自己做选型时，可以按这个思路问自己：如果答案需要从自有资料中找，就用RAG；如果任务需要动手操作外部工具，就用Agent；如果只是文字修饰和内容生成，用LLM就够了。一层一层加，通常不会错。

我在做实际项目时奉行一个原则：能简单解决的绝不堆架构。很多人一上来就搭一个“LLM+RAG+Agent”全家桶，结果出了问题根本不知道排查哪一层。不如从最小可行方案开始，先跑通，再加一层，跑通了再叠下一层。等哪天你真的觉得现有架构不够用了，再扩展也不迟。

最后分享我自己的一点体会。我刚开始接触这套东西的时候，被各种概念绕得晕头转向，天天搜“LLM和Agent什么区别”，搜完更加迷糊。后来是一个做工程的朋友点醒了我：别从概念去理解工具，要从场景反推需要的组件。你要回答一个问题，那就是LLM；你要让回答准一点，那就是加RAG；你要让它把事办了，那就是加Agent。这话我一直记到现在，也分享给你。下次再有人和你聊AI，你记住一句话就够了：LLM负责说，RAG负责理据，Agent负责办事。剩下的细节，动手踩几次坑自然就懂了。