企业官网建设流程全解析

最近有个感受特别明显：朋友圈里聊AI的人越来越多，但真正能把 LLM、RAG、AI Agent 这三件事说清楚的人，十个里面挑不出两三个。大部分人要么被“大模型无所不能”的营销话术带偏，要么在网上扒了一堆概念，看完还是不知道怎么把一个 Chatbot 进化成一个能真的干活的东西。

我先说个结论：这三个词根本不是并列关系，也谈不上谁替代谁，它们是三个不同层面的问题。LLM 是“大脑”，RAG 是“外挂记忆”，AI Agent 是“会动手的躯干”——把这三样东西的边界和能力划清楚，你才算真的入了大模型的门。这篇文章不聊花活，我按自己实际落地项目时的理解顺序，把这三大概念一层层拆开讲。

1. 从“会聊天”到“会干活”：解码LLM背后的三层逻辑

1.1 先搞清楚LLM的底细：一个“概率学大师”

很多人第一次接触大模型，上来就问“它懂不懂我”。这个问题本身就是错的。LLM 本质上是一个超大规模的统计语言模型，它做的事情用一句话就能讲明白：根据你前面输入的一串文字，预测下一个最可能出现的词。

听起来很简单？但这里面的门道在于“怎么预测”和“预测得有多准”。我打个比方，上学时候做英语完形填空，你要在一个空里填一个最合适的词，你需要看前后文、需要知道语法、需要理解语境。LLM 做的事情和这个一模一样——它就是那个把“完形填空”做到了极致的选手。它之所以能这么强，靠的是两样东西：海量的训练文本和上千亿的参数规模。

但请注意，它预测的是“概率最高”的词，不是“语义最正确”的词。这就是很多人在实践中碰到的第一个坑：模型一本正经地胡说八道，也就是大家常说的“幻觉”。它不是在骗你，它只是选了一个词频概率很高、但事实上是错的词。

我在某次做知识库问答时遇到过这样的情况：模型把公司内部一份旧文档里的联系方式当成最新的版本输出给用户，因为它训练时见过太多类似的电话号码格式，潜意识里觉得“这个位置出现一个十一位数字”的概率很高。这就是概率模型的本性。

1.2 上下文窗口是你的最小工作记忆

搞懂 LLM 的工作原理之后，第二个绕不开的概念是上下文窗口。你可以把它理解为模型的工作记忆大小，也就是它“一次抬头能看多远”。GPT 时代早期模型的上下文窗口只有 2048 个 Token，打个不恰当的比喻，就是一次只能看两页纸，翻到第三页就忘了第一页写了什么。

Token 这个概念也要顺手解释一下。它不是一个字，也不是一个词，而是模型处理文本的最小单位。中文场景下，一个汉字大约对应 0.6 到 2 个 Token，具体取决于分词器的设计。所以当你看到模型支持 128K 上下文的时候，不要兴奋得太早——128K Token 换算成中文也就十来万字，看起来很多，但如果你把一个 50 页的产品手册塞进去，再加上用户的问题，很快就会触到天花板。

而且这里还有个更隐蔽的问题：模型对上下文的注意力并不是均匀分布的。我实测过，模型往往特别关注开头和结尾的内容，中间部分容易被“遗忘”。这个现象在学术上叫“迷失在中间”，在实际项目里带来的后果就是：你明明把正确答案放在了检索内容的中间位置，模型却忽略了它。

所以现在你再回头看，为什么业界一直在探索 RAG，而不是简单地把所有资料都塞进上下文？因为上下文窗口再大，也是有物理边界的，而且大窗口不意味着模型真的“理解”了里面所有内容。

1.3 LLM真正不擅长什么

聊完 LLM 能做什么，现在说它不擅长的三件事。

第一，它无法“知道”训练截止日期之后的信息。你问它最近的热点新闻，它只能通过推理来“猜”，猜的准确率完全看运气。第二，它无法获取你的私域数据——你公司内部几万份合同、几十个项目的复盘文档，它一个都没见过。第三，它不会“调用外部工具”。你问它“帮我查一下天气”，它只能编一个“今天多云转晴”给你，因为它没有接天气 API 的能力。

这三件事恰恰是 RAG 和 Agent 要解决的。我在很多项目评审会上反复强调一句话：先明确 LLM 的能力边界，再谈架构设计。很多人一上来就想做一个“什么都会”的智能体，结果做出来的东西既不智能，也不可靠，就是因为没搞懂这层边界。

2. RAG到底解决了什么痛点：给大模型装上一个“外挂数据库”

2.1 幻觉和知识时效的根源

RAG 的全称是 Retrieval-Augmented Generation，翻译过来是“检索增强生成”。这个名字起得很妙，它把本质说透了：先检索，再增强，最后生成。

为什么需要这个流程？根源还是在 LLM 自身的问题上。前面说了，LLM 的知识是静态的、截止到训练之前的、并且是从公开语料里学来的。一旦你问它私域的、实时的、或者是极度垂直专业的问题，它就开始“编”了。

我见过一个很典型的场景：某公司想做一个内部 HR 问答机器人，用来回答员工关于请假流程、报销标准的问题。如果把这些问题直接丢给原始 LLM，它能回答出七八分——但关键的那种“今年最新的调休政策”、“特殊情况下的快速审批通道”它根本不知道。这七八分的准确率看着还行，实际上在人力资源这个领域，答错一个关键细节，就可能引发实际的麻烦。

RAG 的核心解法是：不让模型凭记忆回答，而是先去一个外部知识库里检索相关的资料片段，把这些片段拼进提示词里，再让模型基于这些资料来回答。模型不需要“记得”你的政策文档，它只需要“读懂”你喂给它的那几段文字。

2.2 RAG三段式到底怎么运转

RAG 的标准流程可以拆成三个步骤：索引、检索、生成。听起来简单，但每一环都有坑。

索引阶段，你要做的事情是把那些零散的文档（PDF、Word、网页）切分成小段，把每一段转化成向量，存进向量数据库。这里第一个问题就来了：切分粒度怎么定？切太细，一段只有几十个字，语义不完整；切太粗，一段几千字，检索的时候精确度又会下降。我在实际项目中常用的策略是：按标题层级切分，每个二级标题下的内容作为一个段落，同时保留前后各加一小段重叠的上下文，确保语义连贯。

检索阶段，是把用户的问题也转化成向量，然后在向量数据库里找最相似的若干段落。这里常被忽略的是“相似度”和“相关性”的区别。向量相似度高，不代表语义上一定相关，尤其是在中文这种语序灵活的语言里，同一个意思的表达方式千差万别。所以在检索阶段除了向量相似度，我通常还会加上关键词匹配的 BM25 算法做混合召回，把两种方式的结果做一遍融合排序。

生成阶段，是把检索到的内容和用户问题一起组装成提示词，交给 LLM 生成答案。这个阶段有个小细节，必须在提示词中明确说明“请基于以下资料回答问题，如果资料中没有相关信息，请直接说不知道”。不要觉得这个提示多余——我对比测试过，加了这句话之后，模型的幻觉率能明显下降。因为它在概率上更倾向于不编造，而不是试图“填满”你的问题。

2.3 一个知识库问答场景的完整拆解

理论说多了容易飘，我拿一个落地过的模拟项目来拆一遍。项目很简单：做一个面向新员工的入职问答机器人，知识库里有员工手册、制度文件、培训材料，大概一百多页。

首先是文档处理。我把所有 PDF 转成文本，按章节切分。员工手册里的“请假制度”这一章，切成了二十多个片段。每个片段包含条目标题、正文和条款编号。这里有一个经验之谈：片段里一定要保留结构信息和编号，否则模型看到一段孤零零的文字时，很难判断它属于哪一章哪一条。

然后是数据库选型。我试过向量数据库的多种开源替代品，最终选了个轻量的方案，直接用 Embedding 接口把文本转成向量存进去。对于一百多页的文档来说，完全够用，不需要上重型的分布式系统。

接着是问答过程。用户问：“新增的产假政策是什么？”系统把这个问题的向量拿去检索，召回了几条相关片段，其中有一条是“2024年新增产假天数调整说明”，一条是“产假待遇标准”，一条是旧版的“产假规定”。重排之后，前两条排在前面，旧版那条被放到最后。LLM 读到前两条内容，生成一个基于新政策的准确回复。

这个项目上线之后效果还不错，但我也踩了不少坑。其中一个印象深刻的坑是：旧版和新的政策内容会被同时检索到，新旧内容互相矛盾，模型有时候会倾向于选择新政策，有时候却会选旧政策。后来我在每个片段里加了“生效时间”的元数据，并在生成阶段用规则强制过滤掉已经过期的政策片段，这个问题才彻底解决。

RAG 这套方案的核心价值在于：它让模型的回答变得有据可查。每次回答都能溯源到具体文档，这在很多对内容准确性有硬性要求的场景里，是至关重要的。

3. AI Agent真正颠覆的是什么：从“被动回答”到“独立做事”

3.1 Agent不是“更聪明的聊天机器人”

如果说 RAG 解决的是“让模型知道该说什么”，那 Agent 解决的就是“让模型能够做什么”。

很多人把 Agent 理解为“更聪明的聊天机器人”——这是一个很大的误解。聊天机器人是被动的，你问一句它答一句，对话停它就停。Agent 的区别在于，它面对一个目标，能够自己拆解任务、选择工具、执行操作、检查结果，并在失败的时候自动调整策略。

我举个例子。你用普通 LLM 接口查航班，它只能告诉你“你可以前往某航空公司官网查询”。你用 Agent 来做，它会自己去调用航班查询接口、比较价格、挑选符合你时间段要求的航班，把结果整理好给你。

这里面的核心变化是：LLM 从“回答问题”变成了“制定计划并调用工具执行计划”。

3.2 ReAct核心循环：思考-行动-观察

Agent 的运行机制目前最主流的框架是 ReAct，全称是 Reason and Act，推理与行动。它就是一个循环：

1. 思考（Thought）：分析当前目标，决定下一步该做什么。
2. 行动（Action）：选择一个工具，比如调用搜索引擎、执行一段代码、查询数据库。
3. 观察（Observation）：获得工具返回的结果。
4. 回到第一步，继续思考，直到达成最终目标。

我找一个类比来帮助理解：这就好比你去买一台不熟悉的电子产品。你不会直接拍板下单，你会先打开一些评测网站（行动），看看大家的评价（观察），发现评价不错，再决定要不要下单（思考）。如果发现某个型号的口碑很差，你会调转方向去看另一个型号，而不是头铁买下一台。

ReAct 循环最妙的地方在于，它让模型可以基于“真实世界的反馈”来修正自己的判断，而不是闭门造车。这在很多实际场景里尤其重要：模型预测的行动结果和实际返回不一致时，它能及时纠偏。

3.3 一个自动化工单处理场景的Agent怎么搭

我实际搭过一个 Agent 来处理客服工单自动分类和初步回复。这个场景很有意思，它同时用到了 LLM、RAG 和 Agent 三层能力。

目标：用户提交一个工单，Agent 需要判断这个工单属于哪个部门、紧急程度如何，并生成一个初步回复建议，帮助客服人员节省时间。

我的 Agent 设计如下：

• 一个 LLM 作为“大脑”，负责理解工单内容、做判断。
• 一个分类工具，能根据已有的工单类别标签，对工单进行自动分类。
• 一个检索工具，接了一个 RAG 管道，能从历史工单库中检索相似工单及其处理方式。
• 一个记忆模块，保存这个 Agent 最近处理的工单记录，避免重复处理同一问题。

实际运行的流程是：Agent 先读取新工单内容，用 LLM 判断工单的意图分类。同时，它把工单文本发送给检索工具做相似度匹配，找到历史同类工单的处理记录。然后，Agent 综合这两个维度的信息，生成初步回复建议。

如果你只用 RAG 来做这个场景，效果会差很多。RAG 只能告诉你“历史上类似工单是怎么处理的”，但它不能主动去调用分类工具、也不懂得结合当前工单的特殊情况做调整。Agent 在这里做的事情，更像工作人员——它会检索、会调用工具、会自己判断下一步怎么做，而 RAG 只是其中一环。

但要特别说明一点：Agent 绝不是万能的。它最怕的是任务目标不清晰。你让它“帮用户解决一切问题”，它大概率会陷入无限循环，因为“一切问题”这个目标太模糊了。我自己的经验是，Agent 每做一件事，都要有一个明确的任务边界和终止条件。没有边界的目标，Agent 表现出来就是失控。

4. 三个概念怎么选、怎么协同：我的架构判断方法

4.1 先给三者画个能力边界

很多刚入门的同学总是在问，这三个概念我应该学哪个？我的回答是：它们不是一个层级的，根本没得选。

用一张简单的表格来画清楚这件事：他们分别解决什么问题，最适用的场景是什么，以及典型的局限性。

从这张表你可以看出，它们之间是一种递进关系。LLM 是地基，RAG 是增强层，Agent 是执行层。没有地基，后面全无从谈起；没有 RAG，Agent 做决策时缺少可靠的知识来源；没有 Agent，RAG 只能被动回答问题，无法主动完成多步骤任务。

4.2 一个通用的三层架构参考

在我自己落地的多数项目里，一个相对通用的架构可以抽象成三层：

最底层是基础设施，包括模型底座和各类数据存储。模型底座可以是一个开源模型，也可以是一个商用模型接口，这取决于你的数据隐私要求。数据存储里除了传统的数据库，还需要有向量数据库，用来支撑 RAG 检索。

中间层是增强能力层，包括 RAG 管道（文档切分、向量化、检索、重排）、提示词管理、工具封装。这一层解决的是“模型的知识从哪里来、模型能不能用外部工具”。

最上层是执行层，也就是 Agent 的调度逻辑。它负责拆解用户请求、编排调用哪些中间层能力、哪些外部工具，并对过程进行监控和兜底。

这个架构看起来简单，但它能应对的项目场景非常广。有一次我给某高校的实验室做一个科研助理 Demo，它能在文献库里检索资料、能调用计算工具做数据处理、能生成报告摘要。底层是开源模型，中间层是 RAG 管道和计算工具封装，上层是一个带有任务循环的 Agent shell。整个项目大概几周时间就搭出了可用的版本。

4.3 选型时绕不开的成本与延迟考量

架构设计是一回事，实际落地还有一个很重要的变量：成本和延迟。

先说 Token 消耗。Agent 是最耗 Token 的环节，因为它的循环机制决定了它要反复调用模型。一次“思考-行动-观察”的循环，每一步都是完整的一次模型调用。如果你的 Agent 经过十轮循环才完成一个任务，那意味着你为一个用户请求调用了十次模型，这消耗会远超一次简单的 LLM 问答。

所以我在实际设计中会非常注意控制循环次数。能两步处理完的任务，绝不设计成五步。给 Agent 设定一个最大循环步数，比如最多八次，超过就直接把当前结果返回给用户，并附上“任务未完全处理”的提示。这看起来很“不智能”，但从可用性角度来说，它比让用户等三十秒还没出结果要好得多。

延迟方面，RAG 是个相对轻量的环节，一次检索加生成的延迟大概比纯 LLM 多出几百毫秒，用户基本感知不到。但 Agent 的延迟是累加的，而且不可预测。在做产品设计的时候，必要时要给用户一个“任务正在处理中”的中间态，否则用户会觉得应用卡死了。

5. 落地时容易踩的坑和我的处理习惯

5.1 检索内容一多就“被淹没”的问题

这是 RAG 落地中最常见的问题：你明明检索到了正确答案，但模型就是答错。原因我前面提过——模型对长上下文的注意力不平均，中间区域很容易被忽略。

我自己的处理习惯是：把所有检索结果按重要程度重新排序，把最可能包含答案的内容放在提示词的最前面和最后面。这个听起来像是在耍小聪明，但实测效果显著。另一个更根本的办法是减少喂给模型的片段数量。检索时宁缺毋滥，只选最相关的 3-5 段，而不是把 top-10 的结果全塞进去。相关性不足的内容塞进去只会稀释模型的注意力。

5.2 Agent循环失控的边界控制

Agent 失控这事，几乎每个做过 Agent 项目的人都会遇到。典型的失控场景：Agent 为了解决一个问题，反复调用某个工具十几遍，或者陷入“思考-行动-失败-再思考-再行动”的死循环。

我一般用三种手段来控制：

一是设置最大步数，前面提过，这是最硬的兜底。二是做“行动结果校验”，当工具返回的结果为空或者报错时，给 Agent 一个明确的信号，让它换一个方向，而不是原地重试。三是在提示词里明确“这个任务的最优解法是两到三步”，给模型一个收敛的引导。

这三条配合起来，Agent 从“偶尔疯跑”变成了“可控地完成任务”。想让 Agent 在真实业务里可用，可控性比聪明程度重要得多。

5.3 向量召回“漂了”的元数据过滤问题

向量检索的结果有时候非常飘。你问一个问题，它召回的片段表面语义上相关，实际内容根本没有有效信息。原因在于，向量检索看重的是“语义相似”，它不区分你问的是“2024年的政策”还是“2019年的政策”。

解决这个问题的方法是给每个文档片段加上结构化元数据，然后在检索时用规则过滤掉不符合条件的片段。比如前面提到的政策问答，给每个片段打上“生效年份”标签，检索时直接过滤掉旧的年份。在垂直领域里，元数据过滤的优先级甚至高于向量相似度——这算是 RAG 落地的一个隐藏知识点。

5.4 先RAG后Agent：从小步快跑开始的落地顺序

最后分享一个我对团队和学员反复强调的落地顺序：先做纯 LLM 应用，再做 RAG，最后做 Agent。

纯 LLM 应用能让你熟悉提示词设计和模型特性，这是地基。RAG 能让你接触真实的业务数据，学会文档处理和检索调优，这是老板们最关心的问题之一。Agent 是在前两者都跑通之后才能驾驭的进阶玩法——它适合解决复杂问题，但它也要求你具备更强的工程化和容错设计能力。

我在一个项目里见过有团队从第一天就嚷嚷要做 Agent，结果做了一个月还卡在“模型胡乱调用工具”这关。最后我把方案拆成两步：先用 RAG 把知识问答做好，在这个基础上再给对话系统加一个“查天气”之类的简单工具调用。那个项目最终在一个月内顺利上线，而“复杂 Agent 计划”反而成了后续的进阶模块。

初学者一定要记住：概念只是工具，不是目的。

我在实际项目中练就的判断标准就一句话：如果一个小团队想在两周内把大模型能力落到一门具体业务上，先从 LLM 做起来，要接私域知识的时候补 RAG，要处理多步骤任务的时候再上 Agent。每往前走一步，都建立在前面已经稳定运行的基础上。这个路线看着不性感，但它是踩坑最少、最不容易翻车的路。这也是我在所有大模型实践中最想分享的一个心得。