企业官网建设流程全解析

这个系列写到第9篇，今天想聊一个被问得最多、也最容易被搞混的话题：RAG和Agent到底什么关系？做Agent架构这几年，我最大的感触是，市面上至少有一半号称“Agent”的系统，本质上是披着Agent外衣的RAG；反过来，也有不少团队在只需要检索增强的场景里硬造一个Agent，结果成本和延迟都炸了。检索增强与行动决策，这两条技术路线到底怎么融合、边界划在哪，就是这篇文章要解决的问题。如果你是刚接触Agent开发的工程师，或者正在纠结团队的项目到底该上RAG还是Agent，这篇文章应该能帮你把判断框架搭起来。

1. 先搞清楚RAG的本质：它是知识供应链，不是问答工具箱

1.1 RAG要解决的真问题：事实锚定与知识外挂

RAG（Retrieval-Augmented Generation，检索增强生成）这几年被讲烂了，但绝大多数团队对它的理解停留在“哎呀，就是先从知识库里搜点相关内容，然后拼进prompt里让模型回答”。这个理解不算错，但忽略了一个根本问题——RAG的本质是给LLM搭一条知识供应链，而不是简单地“搜一搜、拼一拼”。

为什么这么说？因为LLM有两个天生的毛病：一是知识截止，训练完之后世界还在变，它不知道今天发生了什么；二是幻觉，凡是它没有把握的内容，它倾向于一本正经地编。RAG的思路就是用外部知识库把模型的能力“锚定”在真实事实上，让模型的每一个回答都有据可查。

所以RAG的核心价值不只是“检索”这个动作本身，更是“用检索结果约束生成过程”。中间任何一环出了问题——切分不合理、向量化失真、召回跑偏、排序漏检、拼装超限——最后生成的答案都会偏离事实。这也是为什么很多团队吐槽“我明明搭了RAG，怎么还是胡说八道”，大概率不是模型的问题，而是供应链的某个环节断了。

1.2 经典RAG链路每一步的取舍

标准的RAG可以拆成两条链路：索引链路，即离线把文档加载、清洗、切分、向量化、存入向量库；问答链路，即在线把用户问题改写、召回、重排、拼装prompt、生成答案。

里面最大的坑在切分（chunking）。切分粒度直接决定召回质量：切大了，一个chunk里塞了太多无关信息，向量检索很容易跑偏；切小了，上下文语义被切断，召回回来也是一堆碎片。我一般会按语义边界切分，用标题、段落、空行做标记，chunk控制在300到500个token之间，同时保留20到50个token的overlap。这个参数没有绝对最优，但它是一个起步经验值，先用起来再按效果调。

向量化同样别小看。用通用embedding模型（比如bge-m3或者OpenAI的text-embedding-3）跑一遍，召回效果勉强能看，但行业术语多的场景，通用模型的表现会明显下降。我自己踩过的坑是，在技术文档场景里，通用embedding对“API、SDK、中间件”这类词的相似度判断经常出错，后来在领域语料上做了微调，hit rate（检索命中率）从58%涨到了79%，这个提升立竿见影。

问答链路还有一个容易被忽略的环节：重排（rerank）。很多团队把“召回”当成终点，其实召回出来的top 5到top 10里往往混着大量不相关片段，直接全部塞给模型，会稀释注意力。我的做法是召回之后加一道cross-encoder重排，把候选集重新打分，只保留真正和问题相关的3到5条进上下文。这一步对最终答案质量的提升，往往比换一个更强的embedding模型还要明显。

1.3 RAG的三个软肋：检索不到、检索到但没用上、检索到也用错了

聊完了链路，我再泼点冷水。RAG有三类典型的失败模式，几乎每个生产环境里的RAG系统都中过招。

第一类：检索不到。知识库里根本没有相关内容，或者有但embedding距离太远召不回来。前者是知识覆盖率问题，后者是检索质量问题的解法是补数据、优化切分、做查询改写。有一个技巧叫“多查询生成”（multi-query），让模型把原始问题改写成几个不同表述的子问题，分头检索再合并结果，能明显提升recall。

第二类：检索到了，但模型没用上。这是最隐蔽的坑。很多case是上下文里明明有正确答案，但模型还是凭自己的“记忆”回答。原因可能是给的上下文太多，关键信息被淹没；也可能是prompt里没强调“答案必须基于给定上下文”。我的做法是在prompt里加一条硬性约束：“不允许使用外部知识，只能依据提供的参考片段回答；如果参考片段不足以回答问题，直接说不知道。”

第三类：检索到了，模型也用了，但用错了。参考片段自相矛盾，或者片段本身信息过时，模型无法判断。这种问题要靠引用溯源来解决：强制模型在输出中标注答案对应的来源段落，再由下游校验环节检查答案和引用是否一致。这恰恰是GraphRAG、Ontology RAG这类方案想要在知识组织层面缓解的问题——光靠向量距离，确实解决不了语义组织和时效判断。

2. Agent的底牌：行动决策的本质是闭环

2.1 感知-决策-行动-观察：Agent的最小循环

Agent这个词被炒得很热，但从架构师角度看，Agent的本质只有一个：闭环。一个真正的Agent系统，必须包含感知（Perception）、决策（Decision）、行动（Action）、观察（Observation）四个环节，并且这个循环是可重复的。

拿一个最简单的例子说明：让模型帮用户查“我现在适合穿什么”。RAG的做法是：检索天气数据，生成穿搭建议，结束。Agent的做法是：调用天气API拿到温度湿度，判断是否需要补充紫外线指数，再调用一个紫外线API，综合分析，给出建议。如果用户追问“那我晚上跑步要不要戴帽子”，Agent要能感知到这个新意图，再次行动。差别在哪？差别在于Agent的每一步行动都在改变状态，而状态的改变又会影响下一步决策。这是闭环和单次检索的本质区别。

这也是吴恩达那套著名的Agent教程里反复强调的点：workflow是编排好的固定流程，Agent是模型自主决定流程。RAG本质上是一种workflow，先检索、再生成，路径是确定的。Agent则允许模型自己去选择“要不要检索、检索什么、检索完了干什么、要不要再检索一次”。

2.2 ReAct与Plan-and-Execute：两种主流的行动决策模式

Agent的行动决策循环，目前主流实现有两种。第一种是ReAct（Reasoning + Acting），它把推理和行动交织在一起：模型先思考，再决定调用什么工具，拿到工具结果后继续思考，如此循环，直到问题解决。这是最接近“人怎么干活”的模式，适合开放性强、步骤不确定的任务。

第二种是Plan-and-Execute，模型先把整个任务拆成子任务清单，然后按清单逐一执行，执行过程中可以做局部调整。这种方式的好处是规划清晰、可观测性好、每一步的输入输出都能审计，适合流程相对固定的场景，比如“先查库存、再算价格、最后生成报价单”。

我的经验是：能上Plan-and-Execute就别急着上ReAct。ReAct虽然灵活，但自由度越高，跑偏的概率越大，而且每多一轮循环就多一次大模型调用，成本和时间都是指数级上升。中小型团队做Agent落地，先固定流程、再逐步放开自主决策，是性价比最高的路径。

2.3 RAG和Agent的本质差异：回答“是什么”与解决“怎么办”

把RAG和Agent放在一张表里对比，差异一下子就清楚了。

还有一个更本质的差异：RAG是被动的、一次性的信息请求；Agent是主动的、多轮的行动主体。前者是“问路”，你告诉我怎么走；后者是“走路”，你自己走到终点，路上还要绕过堵车和死胡同。

这里顺带说明一下“Agentic RAG”这个词。它指的就是把检索能力嵌入到Agent的行动循环里，让模型自己决定什么时候去查知识库、查完能不能信、要不要换个词再查。检索不再是“给定的第一步”，而是Agent的工具箱里的一件工具。这就是后面要讲的融合形态。

3. 从RAG到Agent的三条进化路线

3.1 路线一：工具增强的RAG——给检索结果加“后手”

第一条路线最保守，也最容易落地：在标准RAG后面挂上工具调用能力。典型形态是“先检索、生成，如果生成的内容需要实时数据，再调用API补充，重新生成”。

这种形态下，检索仍然是被动触发的，但生成过程多了一个“补数据”的动作。比如用户问“我们公司上个月的销售数据怎么样”，RAG只能检索到销售制度文档，无法拿到真实报表。这时候可以设计一个工具调用步骤：模型识别出“需要查数据”的意图，调用SQL查询工具拿真实数据，再结合检索到的制度文档生成分析。

我见过不少团队把这种形态直接叫“Agent”，但从架构上看，它只是RAG的增强版。核心判断标准是：模型的决策空间里有没有“要不要调用工具、调用哪个工具、调完怎么办”的自由度。如果流程是预先写死的，那它就是workflow，不是Agent。workflow不可怕，但叫错名字会让你对系统的预期和投入完全跑偏。

3.2 路线二：Agentic RAG——检索变成行动循环里的一个动作

第二条路线是真正的质变：Agentic RAG。在这种架构里，检索模块不再是管线里固定的一环，而是被封装成一个可以被LLM动态调用的工具。模型根据用户问题自行决定：是先检索还是先问用户澄清，是检索一次还是检索多次，是直接回答还是检索完再调用别的工具。

这里有几个典型的落地范式值得记住。一个是Self-RAG，模型在生成过程中自我反思：当前知识够不够？需不需要再检索？检索结果和已有上下文冲突吗？另一个是Adaptive RAG，先用一个分类器判断问题类型：简单问题直接生成，难问题走检索，复杂多步问题走完整的Agent循环。还有一个是Corrective RAG（CRAG），它对检索结果做质量评估，如果评测不过关，就触发“重写查询再检索”或“用其他来源兜底”的逻辑。

这些范式的共同点，是“检索意图”的决策权从架构师手里移交给了模型。架构师不再写死“每次必查知识库”，而是让模型根据实际情况决定。这个转变看着不大，但对系统设计的影响是全方位的——检索频次、上下文管理、失败恢复机制都要重新设计。

3.3 路线三：GraphRAG与结构化检索——知识组织层面的升级

第三条路线不是从“流程”上进化，而是从“知识组织”上进化的。GraphRAG把文档里的实体和关系抽取出来构成知识图谱，检索时先定位实体，再沿着关系扩散，最后把图谱子图喂给模型。Ontology RAG更进一步，用本体定义领域概念和逻辑关系，让检索结果天然具有结构性和一致性。

我为什么在讲RAG到Agent进化时专门提GraphRAG？因为当Agent的行动需要处理复杂多跳知识时，纯向量检索根本不够用。举个例子，Agent要回答“A部门的离职率上升对B项目的交付风险有什么影响”，这个问题的答案散布在多份文档里，涉及人事、项目、财务三类数据。向量检索召回的可能只是零散句子，但GraphRAG可以把“部门-员工-项目-风险”这条关系链整段捞出来，Agent拿到手就是一张可以直接推理的关系图。

所以在真正的Agent系统里，检索层往往不是单一的向量检索，而是“向量检索 + 关键词检索 + 图谱检索 + 规则引擎”的混合体，由决策层统一调度。这也是我建议做Agent架构师的同行，别只会用向量库，得对ES、Neo4j这类传统组件也有实操经验。知识层的功底，决定了Agent行动的天花板。

4. 融合的边界：什么场景用RAG，什么场景必须上Agent

4.1 判断标准一：任务是否可以用单个回答终结

这是最直觉也最好用的判断标准——用户的问题是否可以通过“给定一段上下文，生成一个答案”来终结。如果能，那就是RAG的活。比如“报销流程是什么”“某某接口的返回字段有哪些”，这类事实型问题，一次检索一次生成就能解决，上Agent纯属浪费。

反过来，如果用户的问题天然需要“多步操作”，比如“帮我整理一份竞品分析报告并发送到邮箱”，单靠RAG永远答不完整——因为它只能生成报告，生成不了“发送邮箱”这个动作。这种任务的目标不是“生成一段答案”，而是“达成一个状态改变”，Agent是唯一的选择。

我自己的经验法则是：把任务描述写下来，逐字检查动词。如果动词是“查询、解释、描述、列举”，用RAG；如果动词是“对比、计划、执行、修改、通知、监控”，大概率需要Agent。

4.2 判断标准二：系统是否存在外部状态和环境

RAG的世界里只有两个东西：问题和答案。Agent的世界里至少有三个：目标、工具和环境。外部环境的存在是Agent架构的硬门槛——如果这个系统不用碰数据库、不用调API、不用操作文件、不用发通知，那它就没有“环境”可以交互，Agent的行动闭环根本转不起来。

拿客服机器人举例。如果它只能回答“物流多久能到”“退换货政策是什么”，那是RAG；如果它能查真实订单物流、能提交退换货工单、能根据用户历史订单推荐补偿方案，那它就是Agent。判断的核心是：你的系统里有没有“用户不可见但系统需要修改”的状态？

4.3 判断标准三：结果是否可以被客观评估

这个标准常常被忽略，但它决定了系统能不能健康地演进。RAG的输出是“答案文本”，可以用引用准确性、忠实度等指标来客观评估；Agent的输出是“任务结果 + 过程轨迹”，评估维度更多：任务成功率、工具调用成功率、步数、成本、耗时。

如果团队还没有建立Agent的评估体系，我劝你不要贸然上Agent。因为Agent系统的最大风险不是“答错”，而是“在你看不见的地方跑偏”——模型自己规划了一条路径，执行了半天，你的评估体系却看不出来哪里出了问题。RAG答错了，看一眼输出就知道；Agent悄悄把所有工具调了一遍然后返回一句“无法完成”，你连失败原因都要翻半天trace。没有评估体系就上Agent，等于在没有仪表盘的飞机上起飞。

4.4 边界灰度区与误用代价

现实里的需求往往落在灰度区。比如“用户问了一个开放性的技术问题，需要结合多份文档推理出一条解决方案”，单轮RAG回答不了，但也未必需要完整Agent。我的建议是：先用轻量策略过渡——查询改写、多轮对话历史上下文增强、检索结果的二次重排，这些都能显著提升RAG的处理能力。只有确认任务真的需要“执行动作”或者“动态决策”时，才升级到Agent。

误用的代价是真金白银。某次项目里，团队把本可以用RAG解决的文档问答硬做成了Agent，每个问题平均要跑4到6轮LLM循环，一次对话的成本是RAG方案的8到10倍，响应时间从2秒飙升到15秒以上。更要命的是，因为Agent每一步都可能出错，链条越长出错概率越大，整体成功率反而比RAG更低。所以我的结论一直很明确：RAG能解决的问题，不要用Agent解决；Agent只解决那些“必须通过行动才能达成目标”的问题。这条边界虽然模糊，但值得每一个架构师认真对待。

5. 实战拆解：一个“检索增强+行动决策”的融合系统

5.1 场景定义与目标

光讲理论没有感觉，我来拆一个自己做过并且验证过的系统设计。场景是：某企业内部的数据运营助手。目标用户是运营、产品、管理层，他们的问题是混合型的——既有事实查询（“报销制度是什么”），也有行动需求（“把上周各渠道的转化率拉出来，对比上个月，分析变化原因，生成一份报告并发送到指定邮箱”）。

这个场景是RAG和Agent融合的典型代表：事实查询用RAG，行动需求用Agent。我要把两者放进同一个系统，并且让它们共用一套检索基础设施。听起来简单，但真正的工程难点在于“接口设计和状态管理”。

5.2 系统分层与数据流

我把系统拆成四层。接入层负责意图识别和路由，用一个轻量分类器，或者让主模型自己判断当前请求走RAG直答还是Agent循环，这是整个系统的分流阀。检索层统一封装成检索服务，内部混用向量检索、BM25关键词检索和图谱检索，任何上层模块想拿知识，都调这个服务的同一个接口。决策行动层就是Agent的ReAct循环，所有工具（SQL执行器、报告生成器、邮件发送器、日历查询器）都注册成标准化工具。校验与兜底层对Agent每步输出做格式校验和内容校验，失败自动重试或降级。

数据流是这样的：用户请求进来，接入层路由。如果是事实查询，直接从检索层拿知识，拼prompt生成答案；如果是行动需求，进入Agent循环，Agent在循环中按需调用检索服务、SQL工具、报告工具等，每完成一步就把结果写入会话状态，最终生成报告并通过邮件工具发送。关键设计在于：检索服务对于RAG路径和Agent路径是同一个服务，但不同出口——RAG出口直接拼context，Agent出口作为工具返回值进入模型的下一次推理。这样既保证了知识的一致性，又让Agent拥有检索的自主权。

5.3 检索层与决策层的接口协议

这个接口协议是我们踩了很多坑之后沉淀下来的。检索服务对外暴露的接口，返回结果不能只是一堆文本片段，而要有结构化字段：

{ "query": "原始查询", "rewritten_queries": ["改写后的子查询1", "子查询2"], "results": [ { "doc_id": "doc_001", "chunk_id": "chunk_003", "content": "片段文本", "source": "文档标题/URL", "score": 0.87, "rerank_score": 0.92, "metadata": {"updated_at": "2025-03-01", "author": "张三"} } ], "retrieval_strategy": "hybrid+rerank", "total_hits": 12 }

为什么要结构化成这样？因为Agent的决策需要看到的不只是“片段内容”，还有评分、来源、时间戳。模型要判断“这个信息是不是过时了”，就得看metadata里的更新时间；要判断“要不要换一种方式再检索”，就得看total_hits和score。RAG直答的时候只需要content，但Agent路径必须把决策所需的全部元信息暴露给模型，否则它就是在盲人摸象。

还有一个细节：接口要支持根据doc_id过滤和按时间范围过滤。Agent在检索后如果发现结果全是旧文档，可以重新发起带时间过滤的检索，这个能力在纯RAG里基本不会用到，但在Agent里是刚需。

5.4 记忆与工具的组织方式

融合系统的记忆设计要比纯RAG复杂得多。纯RAG的记忆就是对话历史，用于多轮上下文；而Agent需要三种记忆：会话记忆（当前对话的短期状态）、长期记忆（用户偏好、历史任务结论）、工作记忆（当前任务循环中已经执行过的步骤和结果）。

我建议把工作记忆显式地做成一张“任务状态表”，每一步Agent的行为——调用了什么工具、输入是什么、输出是什么、结论是什么——都写入状态表。这样做有三个好处：一是模型在下一次推理时不需要把全部历史又输一遍，只读状态表的关键字段即可；二是排查问题非常方便，打开状态表就能看到Agent从头到尾干了什么；三是为“记忆压缩”打基础，当状态表太长时提取摘要替代原始记录进入上下文。

工具组织方面，不要一股脑把所有工具都塞给模型。工具越多，模型选错的概率越大。我通常会按场景分组：数据分析组（SQL执行、指标查询）、内容生成组（报告生成、摘要）、通信组（邮件发送、IM通知），每次对话根据路由结果只加载相关组的工具描述。实测下来，工具选择准确率能提升10到15个百分点。

5.5 失败恢复与兜底策略

融合系统最怕的是“执行到一半崩了”。我见过最典型的情况：Agent在第三步调SQL工具时字段名写错了，工具返回报错信息，Agent尝试修正一次还是错，结果就直接放弃，返回一句“无法完成”。这对用户来说是灾难。

我的兜底策略是三层防线。第一层：工具调用重试，让模型根据错误信息修正参数，最多重试2次，重试要带上下文，告诉它上次错在哪。第二层：任务降级，如果SQL执行始终失败，Agent可以退化为“只做能做的部分”——比如生成一份含查询语句草稿的报告，标注“数据未获取，以下为待执行查询”，而不是直接放弃。第三层：人工接管，如果前两层都失败，把当前状态表完整打包给人工客服或开发同学，带着上下文接手，而不是让用户重新描述一遍。

这套兜底做下来，Agent的有效完成率从67%提到了89%，剩下的11%也都有可追踪的失败上下文，不会变成黑盒。核心思路就一句话：永远给Agent留一条“体面退出”的路，别让它卡死在半路。

6. 给Agent架构师的几条硬建议：从0出发少走弯路

6.1 先画数据流，再画架构图

这个系列写到第9篇，我反复说的一句话就是：画架构图之前，先画数据流。很多同行上来就画“用户到网关到Agent到工具到数据库”这种拓扑图，画完自我感觉良好，一上线就发现数据流断了。RAG到Agent的融合系统尤其如此，你要先回答清楚：知识从哪来、检索结果流向哪、Agent每一步的状态写在哪、失败信息往哪传。数据流画清楚了，拓扑图自然就出来了。

我在做前面那个数据运营助手时，第一版架构图画了三版都不满意，后来换了个思路，把每次请求的完整数据流写成一条时间线，从用户输入、意图识别、检索、Agent行动、工具执行到输出，每一步的数据形态都标注出来。这一下子发现了两个本来要上线才会暴露的问题：一是SQL工具的结果没有格式化就传给模型，二是检索服务在Agent循环中会被重复初始化。数据流提前帮我把这些坑填掉了。

6.2 检索质量的三件套评测指标

不管是纯RAG还是融合系统，检索质量都是地基。我建议团队固定盯三个指标：hit rate（检索命中率，指正确答案是否出现在召回结果中）、MRR（平均倒数排名，衡量正确答案的排位）、faithfulness（生成答案对检索片段的忠实度）。前两个衡量“检没检到”，第三个衡量“用没用对”。

我们的实践是每两周跑一次评测集回归，评测集里放200到300条真实用户问题和对应的标准答案。每次改动检索策略——换embedding、调整chunk、加rerank——都拿评测集说话。没有评测集就调参，等于闭眼开车。另外多说一句：hit rate这个指标最近在RAG社区讨论很多，它是比单看top1准确率更稳健的指标，因为它只关心“正确答案有没有在候选集里”，至于能不能被模型选中，那是faithfulness和prompt的范畴。

6.3 可观测性是融合系统的生命线

Agent系统的可观测性，比任何传统后端系统都重要。原因很简单，Agent的每一条路径都可能不一样，你没法靠“固定日志”去复现问题。我的做法是给每一步都打上结构化trace：请求ID、路由决策（RAG还是Agent）、检索服务的查询和结果top5、Agent每一轮的Thought／Action／Observation、工具调用的输入输出、耗时、token消耗。

有了这些trace，线上出问题的时候，我可以直接定位到“第4轮循环里模型选择了错误的工具”，而不是像无头苍蝇一样翻日志。LangSmith和Langfuse这类工具对LLM应用的trace支持已经很成熟了，自己搭一套也不是不行，但成本高得多。我强烈建议：任何上生产的融合系统，第一步就是接trace，而不是接监控告警。

6.4 边界不是常量，它是随能力演进的变量

最后想提醒同行们：RAG和Agent的边界不是一成不变的。随着模型能力的增强，以前需要Agent多步规划才能解决的问题，可能未来的单次推理就能完成；以前检索不到的知识，可能因为embedding模型升级而变得可以召回了。所以不要把自己的架构焊死在“这里是RAG、那里是Agent”的分界线上。

我的做法是每季度做一次“边界复审”，用最新的模型跑一遍评测集，看看哪些原本走Agent的任务可以降级为RAG，哪些原本走RAG的任务暴露出了需要行动能力的问题。架构设计永远是为当前能力服务的，留好扩展点，比追求一步到位重要得多。换句话说，你画的RAG和Agent的分界线，本质上是“当前模型能力曲线”的投影，能力一变，分界线就要跟着动。

最后说点个人的体会。我最早做RAG的时候，觉得检索就是一切；后来做Agent，又差点把一切问题都往Agent上套。折腾了两年，现在的判断标准反倒朴素了：先问用户到底要什么，再问系统到底要动什么。RAG负责让模型知道，Agent负责让系统做到，两者从来不是竞争关系，而是同一件事的两个阶段。如果这篇文章能给同行们一个参考系，让你在评审会上能理直气壮地说出“这个需求其实用RAG就够了”或者“这个目标必须靠Agent闭环”，那就没白写。下一篇文章，我打算聊聊Agent的评估体系怎么从零搭建，那是让整个闭环真正可信的前提。