企业官网建设流程全解析

1. 为什么RAG和Agent组合才是大模型智能体落地的完全体

过去两年，我见过太多项目把大模型接上API就开始喊“智能体”，结果一上线就露馅：问点业务细节，模型一本正经地编答案；让Agent连续执行几步操作，中间一卡就彻底跑偏。直到把RAG+Agent的架构组合放进系统里，这些“看着聪明、用着失控”的问题才真正被解决。所以这篇文章不聊概念，只聊大模型知识问答、业务分析、自动执行这些场景下，RAG和Agent到底怎么搭在一起，才能成为稳定落地的大模型智能体。

先给一个我自己的观察结论：RAG负责让大模型“知道该说什么”，Agent负责让大模型“知道该干什么”。前者解决幻觉和知识陈旧，后者解决复杂任务拆解和工具执行。两者不是竞争关系，而是同一个智能体的左右手。很多团队把RAG做成了一个“检索后直接回答”的管道，又把Agent做成了一堆工具函数的调度器，结果两边的能力都没发挥出来。

1.1 单独RAG的边界在哪里：答案仍然“一次性生成”

RAG的全称是检索增强生成，标准流程大家都熟：把文档切块、向量化存入知识库，用户提问后做向量检索，再把命中的片段拼进Prompt交给大模型生成答案。

这个模式应付“给出一段资料，回答一个问题”足够用，但它的结构性问题很明显：检索次数固定为一轮。用户的问题表述模糊时，向量检索很难一次命中；问题需要跨多个文档对照时，单次检索根本拼不出完整答案；如果知识库里没有答案，RAG不会主动去查实时接口，只会硬着头皮说“根据资料……”。这就像一个资料员只被允许翻一次书就回答，翻不到就算编也得把答案说出来。

更隐蔽的问题是，RAG没有任何“自我检查”机制。模型生成完答案，不会回头验证“我引用的这段和用户问的到底匹不匹配”。一旦检索阶段捞回一个语义相似但不相关的片段，RAG的整个回答就会被带偏。所以我一直对想直接拿一个裸RAG管道做智能体的朋友说：不是RAG没用，是它天然缺了“决策”这一层。

1.2 Agent补齐了决策能力，RAG补齐了事实来源

Agent的核心是把一个大目标拆成小步骤，循环地决定“下一步调什么工具、观察什么结果”。有了Agent这层，检索就不再是被动的一次性动作，而成为智能体工具箱里的一个可调用能力：查到不够就再查一次，结果不对就改写查询词，文档不够还可以调外部数据库或API。

但Agent单独跑，问题同样尖锐：它擅长“调动工具”，却不擅长“拥有知识”。如果工具返回的是一堆原始数据，或者Agent要基于内部规章制度做判断，它仍然依赖模型参数里那点训练时记忆。大模型智能体落地最难的一环，就是如何让模型在真实业务数据上做推理，而不是在训练数据里做“回忆”。

把RAG和Agent放在一起，等于给智能体装了两套系统：一套是事实核查系统，一套是任务执行系统。一套主内，一套主外。后续所有架构设计，本质上都是在回答一个问题：这两个系统之间怎么做接口、怎么传状态、怎么避免冲突。

2. RAG这一半：从知识库到上下文，难点不在“存”而在“取”

如果把RAG+Agent架构比作一个工厂，RAG就是原料供应链。供应链出问题，后面全线停摆。我做过的几个RAG项目里，真正拖后腿的从来不是大模型参数不够大，而是检索召回的质量不够高。而检索质量的第一道关卡，就是知识切片。

2.1 切片不是字数问题，是语义完整性问题

很多人做知识库切片，习惯按固定字数切：512字一块、512字一块，简单省事。但这样切出来的片段经常把一句话切掉一半，把一个表格拆成两截，或者把一个业务规则从“前提”和“结论”之间硬生生断开。向量检索到的片段看似相关，实际语义支离破碎。

我现在的经验是：宁可让规则复杂一点，也要先保语义完整性。常见做法包括：

• 按Markdown标题层级切分，比如#、##、### 作为边界；
• 按表格、代码块、引用块等富文本结构切分；
• 先按段落切，再结合embedding模型的最大输入长度做二次合并；
• 设置小幅重叠（overlap），让相邻片段保留上下文过渡。

这里有一个经常被忽略的点：切片长度直接决定检索精度的天花板。段落越小，召回时命中的语义越聚焦，但上下文丢失的风险也越大；段落越大，语义完整了，但一个片段里往往塞了多个主题，向量表示被“平均化”，检索精度反而下降。所以我在实际项目里通常维护两套索引：一套用小分段做精准召回，一套用大分段做上下文理解，检索时混合使用。

2.2 检索质量的三道关卡：召回、重排、上下文压缩

从索引到最终放进Prompt，我一般至少经过三道关卡，而不是“向量检索一把梭”。

第一关是召回。纯向量召回的问题在于它只捕捉语义相似，不擅长精确匹配。业务系统里经常出现“订单编号SN20230712”“设备型号M88Pro”这种字符串，向量检索大概率分不清相近编号之间的细微差别。所以生产环境里我强烈推荐混合检索：向量召回加上BM25关键词召回，再把两者结果合并去重。这样既能理解“帮我看看最近哪批设备故障率高”这样的自然语言，也能精确匹配“请把PRD-1024这个工单的状态查出来”这样的硬性条件。

第二关是重排。混合召回拿回来的候选集可能有20~50条，但真正能被Prompt容纳的只有3~5条。直接用向量相似度排序并不理想，因为向量相似度和“问答相关性”不是一回事。更可靠的是用一个专门的cross-encoder重排模型，把用户问题和每个候选片段拼在一起，算一个更精细的相关性分数，再按这个分数截断列表。Rerank模型延迟会比普通向量检索高一些，但为了最终回答质量，这几十毫秒完全值得。

第三关是上下文压缩。重排之后拿到的片段仍然可能有冗余，直接塞进Prompt既浪费Token又干扰生成。压缩可以做两层：第一层做规则过滤，比如长度过滤、重复内容过滤、与问题关键词匹配度过低的过滤；第二层可以用小模型对片段做摘要，或者只截取和问题相关的句子。我一般只在片段质量明显偏低的时候才启用LLM压缩，否则它会引入额外延迟。

这三道关卡对应的质量指标也很简单：召回看Recall，重排看Precision，最终看Answer Faithfulness。下面这张表是我在项目里常用的检查表：

3. Agent这一半：不只是调工具，而是用“计划+记忆+工具”解问题

Agent和“调接口”之间有一条明显的分界线：调接口是固定流程，Agent是由大模型动态决定流程。但动态不等于任意。如果把Agent写成“循环调用大模型直到用户满意”，它会在真实系统里制造大量不可控开销。所以做一个能用的Agent，至少要设计好三样东西：循环方式、工具清单、状态管理。

3.1 ReAct循环：让模型“边想边查边做”

ReAct模式是目前最经典、也最容易实现的Agent决策方式，全称是Reason + Act。它的核心是让大模型交替输出两样东西：

• 推理过程：解释为什么接下来要这么做；
• 工具调用：选择哪个工具、传入什么参数。

比如用户问：“帮我看看华东区域最近的销售情况，并分析环比下降的原因。”Agent在一次循环里会先思考“需要找到华东区域销售数据”，然后调用销售数据查询工具；拿到数据后继续思考“环比下降需要对比上月数据”，再调用对比分析工具；最后才会生成结论。整个过程的关键是：每一步都建立在前一步的观察结果上。

工程上实现ReAct并不难，一个简化版的伪代码大概长这样：

for step in range(max_steps): response = llm.act( sys_prompt + memory + tool_context ) if response.is_final_answer: return response.final_answer tool_result = run_tool(response.tool_name, response.tool_args) memory.append(tool_result)

看起来简单，但这里藏着两个工程重点。第一，tool_context必须给得足够结构化，让模型清楚知道“有哪些工具、每个工具是干嘛的、参数怎么填”。我见过大量Agent乱调工具，原因不是模型笨，而是工具描述写得含糊。第二，max_steps必须设置上限，否则遇到坏分支就是无限死循环。生产环境一般控制在5~8步，再多基本说明规划质量出了问题。

3.2 工具编排与状态管理：LangGraph里真正要设计的东西

市面上的Agent框架很多，LangChain、LangGraph、LlamaIndex、自研调度器，各有各的偏好。但如果你准备做一个有真实业务约束的智能体，我建议核心流程不要交给那种“自动迭代到天荒地老”的老式Agent框架，而是用好图结构的状态机。这也是LangGraph这类工具的价值所在：它把Agent流程显式定义成一张图，节点是动作，边是条件跳转。

举个例子，一个“查资料回答问题”的智能体，可以设置这样的节点：

1. 意图识别节点：判断问题是简单问答、多跳分析还是需要实时信息；
2. RAG检索节点：调用知识库检索工具；
3. 外部工具节点：调用数据库、API、业务系统；
4. 答案生成节点：汇总所有上下文生成最终答案；
5. 验证节点：检查生成内容是否基于检索结果。

这种图式编排最大的好处是可观测：每一步都记录在案，出了问题可以直接回放。实时状态里要存什么？至少要存：用户原始问题、当前目标列表、历史工具调用记录、每步检索回来的上下文、中间推理过程。这些东西合在一起，就是Agent的“工作记忆”。没有工作记忆的Agent，等于让一个人每次说话都忘掉上一句说过什么。

4. Agentic RAG：从“检索一次就问”到“检索决策一体化”

“Agentic RAG”是最近高频出现的一个词，直译是“智能体式RAG”。很多人的第一反应是：我是不是已经在前面的架构里完成它了？其实没有。Agentic RAG的核心不是“RAG作为Agent的工具”，而是检索过程本身也由Agent来驱动和验证。

传统RAG里，用户问题长什么样，检索就用原话去查。但真实世界里，用户问题往往是含糊的、口语化的、包含大量指代。Agentic RAG会做更聪明的事：改写查询、拆解子问题、判断检索结果是否够用、检索后自我打分。这也正是目前大模型智能体落地最重要的分水岭：它是用检索结果辅助生成，还是用检索结果参与决策。

4.1 智能体如何决定“要不要查、查什么、查几次”

第一步是判断“要不要查”。我见过不少系统一上来就检索，用户说“你好”也去库里捞一遍，纯属浪费。更好的方式是先用一个小分类器或强模型判断：这个问题是否需要外部知识？如果需要，是否有足够上下文直接回答？

第二步是“查什么”。这个过程通常包含查询改写。用户说“它最近怎么样”，“它”指代谁，要从对话历史里捞出来；“最近”指哪个时间段，要转换成可检索的关键词。这部分如果直接用原句检索，召回精度惨不忍睹。一个实用的做法是让Agent生成多个检索查询词：技术术语用专业名、业务说法用口语名、缩写配全称，然后做多查询并行召回。

第三步是“查几次”。并不是查一次就能收工。Agentic RAG允许迭代：第一次检索结果质量分低，就改写再查；结果里引用了某个报告编号，就再查一次该编号对应的详情；多个子问题都检索完成后，再汇总成最终答案。这里的核心是设置一个结果质量判断器。早期项目我直接让大模型判断“这些检索结果是否足以回答用户问题”，但这样不稳定；后来我加了一个规则打分：结果与问题的关键词覆盖率、结果数量、重排分数阈值，三者结合，比单一模型判断可靠得多。

4.2 多路召回与问题分解：让复杂问题被拆着解决

多数企业的知识不止一份文档，而是散落在规范手册、工单系统、数据库、产品源码里。Agentic RAG在接这些资料时，会把检索入口做成分支工具：

• 向量知识库：适合非结构化文档、规章制度、产品说明；
• 关系型数据库：适合订单、库存、用户信息这类结构化事实；
• 搜索引擎/内部Wiki：适合比较新的、频繁更新的内容；
• 融合检索入口：同时查多个来源再合并结果。

多路召回解决的是“资料在哪”的问题；问题分解解决的是“复杂问题怎么查”的问题。拿一个典型场景举例：“对比去年和今年新品发布后首月的用户投诉，找出事故率上升的主要原因。”这个问题没法一次检索完成，Agent会把目标分解成三个子问题：

1. 去年发布的新品有哪些，上市首月投诉量是多少；
2. 今年发布的新品有哪些，上市首月投诉量是多少；
3. 投诉量上升对应的品类和故障模式是什么。

每个子问题各自走一次检索或工具调用，然后把结果拼起来做归因。这个过程像极了一个资深分析师的实际工作：不急着给结论，先拆问题、找数据、交叉验证。而Agentic RAG的架构目标，就是把这种行为模式固化到系统里。

5. 架构选型与组件搭配：一份可以直接抄的落地清单

聊完原理，到落地阶段大家最头疼的还是选型。我在技术方案评审会上被问得最多的一句话是：“我这场景到底要不要上Agent？”我的答案经常让人意外：能不上就先别上，除非传统RAG确实兜不住。

5.1 明确要用传统RAG还是Agentic RAG

延迟、成本、稳定性，这三项是架构决策的底座。Agent每多一轮决策，就多一次大模型调用，延迟和成本同步上涨。所以在设计初始，先给业务需求分层。

这个表是我在多次项目里总结出的判断框架。核心标准只有一条：问题能否在“一次检索+一次生成”内解决。不能，再引入Agent。很多团队把Agent做成全场标配，最后发现80%的请求根本没用到推理决策，只让延迟白白涨了几倍。

5.2 技术栈选型：向量库、框架、模型的匹配逻辑

如果确定要做Agentic RAG，技术栈怎么搭？我按层来拆：

• 向量存储：知识规模小就选轻量方案，比如pgvector；规模上千万条、对查询性能敏感，再考虑Milvus或Qdrant；如果团队已经重度使用Elasticsearch，直接走ES的kNN+BM25混合检索也足够，没必要额外维护一套向量库。
• RAG流程框架：LangChain生态最成熟，但历史包袱重，只用它做数据处理和工具调用没问题；如果流程复杂度高，我推荐LangGraph这类按图编排的方案，因为它把可观测性做进了状态管理里。
• 工具接入标准：现在越来越多人谈MCP，它本质上是一个让智能体调用外部工具的统一协议。如果你有多个业务系统需要接入Agent，MCP能省掉大量“一个系统写一套适配器”的重复工作。它是RAG之外的另一根管道，解决的是工具生态互通问题。
• 模型组合：问答生成用大参数模型，查询改写、意图分类可以用较小但速度快的模型；重排单独用cross-encoder。不用所有环节都堆最强的模型，成本经不起这么烧。

我对自研框架的态度是：除非你们团队的场景非常特殊、现有框架无法表达，否则不要从零写调度器。LangGraph这类框架已经把状态持久化、条件跳转、人工干预这些能力封装好了，直接在上面约束业务规则，比自研一套稳定得多。

6. 落地过程中的性能、成本与可靠性治理

架构设计得再漂亮，进了生产环境都会原形毕露。RAG+Agent系统的最大矛盾是：Agent能力的上限越高，中间过程的不可控性就越高。所以治理层必须从第一天就设计进去，而不是等出现了上百万Token消耗才发现。

6.1 延迟优化：不是所有查询都要走完整智能体循环

Agentic RAG的完整流程确实贵，一步意图识别、两步查询改写、几次检索、若干次工具调用、一轮生成验证，总耗时奔着10秒去很正常。但真实用户没有那么大的耐心。我常用的降延迟手段是快速通道：

• 先做一次轻量意图分类，把明显是简单问答的请求引导到传统RAG管道，不走Agent；
• 在路由上加规则：问题长度小于一定阈值、没有“对比”“分析”“为什么”这类词，默认走快速通道；
• 对热点问题加缓存：命中缓存的直接返回历史答案，连检索都省了。

快速通道之外，还要控制Agent内部循环的步数。我建议把max_iterations设成硬上限，并在Prompt里写清楚“如果第N轮还没有解决问题，就基于已有上下文给出一个带明确前提的回答。”这样做不是降低质量，而是避免让用户面对一个无限转圈又什么都答不出来的智能体。

6.2 成本控制与评测：ROI和数据指标缺一不可

Token成本和业务价值之间，必须用评测数据来对齐。做RAG+Agent项目，我至少要维护三类数据集：

• 检索评测集：标注每个问题应该召回哪几个文档片段；
• 生成评测集：标注标准答案，评测答案相关性、忠实度；
• Agent流程测试集：记录每一步工具调用是否合理、最终是否成功完成任务。

有了这三类数据集，才可能在一次Agent版本升级时说出“检索召回率提高了5个点，但最终答案忠实度降了2个点，问题出在上下文压缩那一步”。没有评测数据支撑的Agent优化，基本就是调Prompt玄学。

成本治理的核心是给Agent的每一步调用建账。我习惯在日志系统里记录每次请求消耗了多少Token、调了几次模型、几次向量检索、几次外部API。最后用一张简单的成本分布表来定位瓶颈：是意图分类调用太多，还是重排太频繁，还是Agent反复检索失败。大多数情况下，成本都能靠减少无效检索来回收，而不是一味换便宜模型。

7. 实践中的坑：我踩过的几个具体问题与解决思路

前面说的都是框架层面，最后聊几个真实项目里让我印象深刻的坑。这些细节在技术文档里基本不会写，但每一个我都花过不止一个通宵去解决。

7.1 检索到的无关片段比不检索更伤输出

早期做一个企业内部知识问答系统时，我发现一个诡异现象：给模型提供两个不相关但语义沾边的片段，模型往往不会说“资料不足”，而是会自信地把两个片段强行关联起来，生成一个看似完整、实则虚构的答案。对比实验里，不提供上下文时模型反而会坦诚说不知道。

后来我总结出一套处理方案：第一，检索后必须经过重排和阈值过滤，分数低于阈值的片段宁可舍弃也不要塞进Prompt；第二，Prompt里明确加一句“如果提供的资料与问题不相关，请直接说明无法回答”；第三，在生成阶段要求模型输出引用来源编号，并让验证节点检查引用的片段是否真的支持结论。这一步在Agent架构里尤其重要，因为Agent比裸RAG更容易把“背景资料”误当成“答案依据”。

7.2 工具权限过大导致智能体乱飞

有一次做自动化运维助手，给Agent暴露了一个“执行SOP脚本”的工具。测试时原意是让它读脚本、解释脚本，结果模型在一次推理中判断“需要实际运行一遍来验证结果”，然后真的把脚本执行了。幸好是在沙箱环境，没有造成线上影响，但这件事让我彻底意识到：Agent的工具调用能力必须最小化授权。

现在的做法是给工具加两层防护：第一层，工具权限按角色区分，只读工具直接可调，写操作和外部动作必须走人工审批节点；第二层，在工具定义的描述里写清楚使用边界，例如“该工具只能用于查询状态，不能执行任何变更操作”。此外还会在Agent循环里加一个独立的“安全校验节点”，在模型调用敏感工具前自动拦截。

7.3 知识更新不是“重训模型”，而是索引与缓存的联动

做RAG+Agent之后，业务方最爱问的问题是：“我们改了制度文档，模型什么时候能学会？”答案是：模型不用重新训练，但你的索引和缓存必须一起更新。RAG这一步就是这么设计的：删除旧文档对应的向量切片，写入新文档的向量切片，旧答案缓存立即失效，让下一次查询强制走新索引。

我建议在这个环节做版本管理：给每条知识打上生效时间区间，检索时把时效条件作为过滤项。Agent在做RAG检索时，也应该把“当前知识版本”放到上下文里，防止模型引用已经下线的旧规定。曾经有个团队上线新制度后忘了清缓存，用户提问时模型还念着三个月前的老版本，原因就是缓存里的Prompt旧样本没失效。这类问题听起来低级，但真的就藏在上线流程里。

如果让我给RAG+Agent架构定一条最重要的经验，我会说：架构本身不是目的，让智能体在真实业务里稳定地“知道该说什么、该干什么”才是目的。RAG保证它有据可依，Agent保证它有章可循。把这条主线想清楚了，剩下的选型、调优、踩坑，都不过是这条主线上的具体修补而已。