企业官网建设流程全解析

不少团队都能在几周内搭出一个"能回答文档问题"的AI客服：把FAQ和说明书切块、做向量化、接个大模型，演示效果挺唬人。可一旦放到生产环境，面对真实用户五花八门的问法，满意度曲线就会直线往下掉。问题不在模型，也不在向量库，而在思路——你做的只是"文档检索问答"，不是"客服"。客服的核心是解决问题，不是找资料。这就是我从传统RAG转向Agentic RAG的原因，也是这篇实战指南想讲清楚的事：如何把一个"会背书的检索器"，进化成"会分诊、会查系统、会开售后单、会自己判断还需不需要追问"的工业级AI客服。这篇文章适合正在做客服知识库问答、准备把RAG项目推向生产的工程师和架构师，内容会围绕场景拆解、架构设计、工具编排、稳定性治理和评测迭代展开，都是可以直接落地的经验。

1. 传统RAG在客服场景的"及格线"困境

先正视一个问题：传统RAG在产品演示里够用，但在客服场景里，它只是踩着及格线。

1.1 客服问答不是"查文档"，而是"解决事情"

传统RAG的工作流非常简单：用户提问、检索召回、模型基于上下文生成回答。它的前提假设是"用户想知道某件事"，但客服场景里，这个假设经常不成立。

举个例子。某电商平台的用户问："我昨天买的手机为什么还没发货？"这句话表面上是在询问发货规则，实际诉求是"帮我查我的订单状态，如果延迟了，给我一个说法或补偿方案"。传统RAG能检索到"平台通常会在48小时内发货"这样的规则文本，但回答完这句之后呢？用户真正的问题——"我的订单现在到哪一步了"——根本没有解决。

我见过很多客服系统的对话日志，用户带着"查一下""帮我改""为什么扣款"这类动词进来，期望的是动作，而非一段知识。这意味着系统必须有"调用工具、获取实时数据、执行操作"的能力，而这正是传统RAG架构天然缺失的。它的检索链路再优化，也只能回答"知识型问题"，覆盖不了"任务型问题"。客服场景里，任务型问题通常占到40%以上，忽略这部分，所谓智能化就是空中楼阁。

1.2 传统RAG翻车的四类"现场"

我把实际生产里最常见的失败模式归纳成四类，每一类都对应着不同的技术缺失：

多知识组合失败。用户问"会员价商品可以叠加优惠券吗？"，答案散落在两篇文章里：《会员权益说明》讲折扣规则，《优惠券使用规则》讲叠加限制。传统RAG一次检索通常只召回最相关的少部分段落，模型只能看到其中一半信息，于是给出一个自信但错误的回答。这类问题不是"检索不到"，而是"检索不完整"，是组合推理缺失。

多轮信息丢失。用户先说"我买了个扫地机"，再问"它充满电能用多久？"，然后补充"我家120平米"。环境信息在第三轮才出现，前两轮的对话内容又没有进入检索上下文，最后模型只能返回产品参数表里的通用续航时间。对用户来说，这是一个"不智能"的系统。

实时数据空白。询问"积分什么时候到账""退款到哪一步"这类问题，知识库里根本没有答案，数据在业务系统里。传统RAG连尝试查询的入口都没有，只能让用户"去App里自行查看"。

规则与知识不同步。运费规则7月1日调整后，知识库更新不及时，AI还在按照旧规则回答。传统RAG没有"知识时效性感知"能力，不知道哪个段落已经过期，也不知道该去哪个业务系统确认最新策略。

这四类问题，靠调embedding模型或换向量库解决不了，它们是架构层面的缺口。

1.3 检索质量的隐性天花板

就算只做知识问答，传统RAG也有一些容易被忽视的"隐性天花板"。最典型的是分块粒度。某团队在做产品说明书问答时，最初把每段按512个token切块，召回准确率看着不错，但生成答案时经常"混着讲"——一段里同时包含了安装步骤和安全警告，模型把警告内容当成操作步骤输出。后来改成按标题段落语义切块，问题明显减少。

另一个隐性问题是相关性阈值。很多团队把向量检索的score阈值定得很低，导致一堆无关片段进上下文，模型被噪声带偏。工业级做法是同时维护"向量召回"和"关键词召回"两条链路，用RRF（倒数排名融合）合并结果，再对最终进入上下文的片段做一次相关性打分过滤。这一步不是模型能替代的，它决定了模型看到的"原料"质量。

传统RAG不是没有价值，它是Agentic RAG的"体感层"——负责最终的快速答案生成。但作为一个完整的客服系统，它只是起点。

2. Agentic RAG的本质：把"检索"变成"规划后的行动"

Agentic RAG与传统RAG最大的区别，不是多了一个"智能体"的名头，而是把原来"检索-拼接-生成"的单向流水线，改成了"规划-行动-观察"的循环。

2.1 先有规划，后有检索

理解Agentic RAG，可以先看一个典型的复杂客服请求："订单显示已签收，但用户说没收到，要求退款。"

这个请求单靠一段文档无法解决。正确的处理路径至少包含四步：先调用订单系统接口确认签收状态和物流轨迹；再根据轨迹判断包裹是否可能被代收或误投；如果确实异常，检索售后流程文档确认能否发起退款；最后生成答复，并附带下一步操作引导。每一步都会产生新的信息，信息又决定下一步动作。

这就是"规划先行"的含义：系统在生成答案前，先输出一个行动序列，而不是直接检索。行动序列中的每一项都绑定一个工具，工具的执行结果再喂回给模型继续推理。相比传统RAG的"一次检索搞定"，这个过程更像一个初级客服员工的处理思路。

我自己在设计规划器时，比较保守的做法是：让它先输出结构化JSON，而不是直接在对话流里乱跑。比如行动计划包含三个字段：action表示工具名，parameters表示工具参数，reason表示为什么要做这一步。这个结构便于追踪、便于限制、也便于评测。

2.2 工具调用与动态路由的配合

Agentic RAG里的工具，不只有"检索知识库"这一种。常见的有：订单查询工具、物流查询工具、售后退款工具、优惠计算工具、工单创建工具，以及最基础的"知识库检索工具"。每个工具在Agent看来都有一个函数描述，大模型根据用户意图选择该调用哪个。

一个典型的知识库检索工具定义大致是这样的：

{ "name": "search_knowledge_base", "description": "在客服知识库中检索业务规则、操作流程、常见问题解答。适用于运费、退换货、会员等级、发票等知识类问题。", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "检索关键词，建议提取用户问题的核心诉求" }, "category": { "type": "string", "enum": ["order", "product", "account", "promotion", "invoice"], "description": "知识库分类，缩小检索范围" } }, "required": ["query"] } }

很多团队忽视了description字段的重要性。模型不是靠工具名字理解工具的，它靠的是description里的语义信息。如果你的description写的是"知识库检索工具"，模型就只知道这是一个检索功能，不知道什么时候该用；如果你写清楚"适用于运费、退换货、会员等级、发票等知识类问题"，模型才能做好路由。

再配合function calling机制，大模型输出一个结构化的工具调用请求，程序收到后执行真实API并返回结果，模型再基于结果继续生成回答。这一步是Agentic RAG的核心交互模式。

2.3 为什么不能只有一个大模型通吃所有环节

Agentic RAG涉及三个步骤：意图路由、行动规划、最终话术生成。三个步骤对模型能力的要求完全不同。如果全程都用同一个最强模型，成本会非常难看，延迟也压不下来。工业级方案要做模型分级。

我的经验是：意图路由和工具选择用7B~14B的中小模型即可，准确率高、速度快；行动规划和多步推理用更强的商用模型，保证复杂路径不迷路；最终话术生成可以复用行动规划模型，也可以单独用一个小模型做话术润色，取决于客服场景需要的人格化程度。

模型分级的核心原则是：把"决策"和"表达"拆分。复杂的决策步骤集中消耗强大模型，重复表达步骤交给轻量模型，这样做延迟和成本的收益非常直接。

3. 落地实战：一套可复用的Agentic RAG客服架构

概念讲完，说架构。下面这套架构我在模拟项目和某客服系统的POC里都验证过，整体上可以拆成"入口分层-规划器-工具层-记忆层"四个部分。

3.1 场景边界划分：别让Agent处理所有问题

第一件事，是定义一个"分流器"。不是所有用户消息都需要启动Agent，很多简单问题用传统RAG直答更快、更省钱。分流器负责在入口处把请求分成三类：

• 闲聊/情绪表达：直接走安抚话术，不检索不规划。
• 单轮知识问答：走传统RAG链路，一步检索直接回答。
• 复杂任务/多步处理：才进入Agentic RAG规划流程。

分流器可以用一个小型意图分类模型，也可以让入口大模型通过prompt判断。我更推荐前者，因为意图分类是确定性较强的任务，中小模型就能做得很准，且可以脱离主模型独立部署，方便压延迟。

场景边界的价值在于：它明确"哪些问题不该Agent化"。Agent能力很强，但多一次规划就多一次延迟和失败机会。把简单问题挡在外面，系统整体成功率会明显提升。

3.2 任务规划器的设计

规划器是Agent的大脑，负责输出行动序列。我用的Prompt骨架大致如下：

你是一个在线客服系统的任务规划器。你需要根据用户的诉求，生成一份可执行的动作序列。 要求： 1. 输出JSON格式，字段包括：actions、fallback_reply。 2. actions数组按执行顺序排列，每个action包含：action（工具名）、parameters（工具参数）、reason（执行理由）。 3. 如果用户的诉求无法通过任何工具解决，将fallback_reply设为需要转接人工的说明，actions置为空数组。 4. 最多输出3个action，不要生成无依据的步骤。 5. 每一步只调用一个工具，等待工具结果后再进入下一步。

注意第4条：限制最大行动数。这一步很关键，不加限制的Agent容易在复杂场景里无限规划，最后把延迟和成本拉爆。我在生产环境里最常用的上限就是3步，因为客服场景90%以上的复杂问题，三步以内都能闭环。

规划器还需要一个"停止条件"：当行动序列执行完，或者某个工具返回了"用户问题已直接解决"的标记，Agent就该停止规划，进入话术生成。

3.3 工具层的抽象

工具层是Agentic RAG最需要做工程投入的地方。不是把API接进来就完了，每个工具都要有元信息：描述、参数schema、超时阈值、重试策略、幂等性说明。

我见过一个典型的翻车现场：某团队把"创建售后工单"工具接入Agent后，测试时发现模型在用户表达不满时会重复调用工单创建接口，导致半个小时内创建了几十张重复工单。原因是工具没有幂等设计，也没有在描述里注明"仅当用户明确要求申请售后时"才可调用。

工具层设计要注意三件事：

• 每个工具必须有清晰触发条件，写在description里，必要时候加"绝对不要……除非……"这类限制。
• 所有写操作必须幂等，接口设计上支持传入业务幂等键（例如订单号+用户ID+售后类型），重复调用不会产生副作用。
• 工具失败要有降级提示，返回给Agent的结果里应该包含错误码和"建议转人工"的信号，让模型在拿不到数据时知道怎么收场。

3.4 记忆管理与上下文压缩

Agent每多执行一步，就会多一轮工具返回结果，这些内容全塞进上下文，很快就会爆掉。工业级做法是区分长期记忆和短期记忆：

• 长期记忆存储用户画像、历史工单、历史诉求摘要，用向量库或KV存储维护。
• 短期记忆只保留最近几轮原始对话和最近一次工具调用结果。

我常用的压缩策略是：每轮对话结束时，把"上一轮的用户意图+系统动作+答复摘要"压缩成一行字符串存起来，作为下一轮的记忆前缀；同时保留最近两轮完整对话原文。这个"摘要+原文"的混合策略，在信息保全和token消耗之间比较平衡。如果你直接保留全部原文，5轮以上就会让模型开始"忘记"重点指令，这比token成本上升更致命。

上下文压缩的触发时机也有讲究：不是每轮都压缩，而是当记忆前缀超过一定阈值（例如2000 token）才执行。压缩动作本身也消耗模型调用，频率太高等于把钱花在整理房间上，不值。

4. 稳定性与成本：工业级绕不开的两座大山

Agentic RAG不是只要"对话聪明"就够，生产环境对稳定性和成本的要求非常严苛。

4.1 延迟预算与异步编排

传统RAG一次请求的延迟通常在1到3秒，Agentic RAG因为存在多步调用，延迟会翻倍甚至更多。用户可不会为"AI在思考"买单，满意度曲线对5秒以上延迟极其敏感。所以在设计阶段就要有延迟预算意识。

我给客服Agent定的预算表格大致是这样：

异步编排是另一个关键手段。多个独立的工具调用可以并行执行，例如用户身份查询和历史订单查询互不依赖，应该同时发出，而不是串行等待。这要求规划器输出的action里显式标记dependency字段，调度框架根据依赖关系决定执行顺序。串行和并行，在工具环节能省下的时间通常是1到2秒。

4.2 成本控制与模型分级

Agentic RAG的成本公式可以粗略概括为：单会话成本约等于所有模型调用token之和乘以单价，再乘以工具调用次数。一个复杂会话可能产生10次以上的模型调用，如果不做控制，单次客服交互成本可能比人工客服还贵，那就本末倒置了。

我的成本控制三板斧：

• 模型分级：分流和意图识别走低价模型，只有真正进入多步规划的会话才调用高能力模型。这一步能把高成本调用占比压到总流量的20%以下。
• 结果缓存：相同意图+相同参数的工具调用结果可以做短时缓存，例如"运费规则查询"五分钟内缓存，模型输出全部命中缓存的话，不需要再次调用高成本模型。
• 主动终止：规划器在"信息不足但已有直接答复"时，允许直接生成最终回答，不需要追求把所有工具都调用一遍。

4.3 可观测性：链路口径与追踪

Agentic RAG最大的工程隐患是"黑盒"。传统RAG一次检索，出错了查日志就行；Agent有3个步骤、3个工具调用、两次模型推理，出错时如果只看到最终回答，根本定位不了问题。

所以从第一版开始就要做链路追踪。每个会话分配一个request_id，每个动作记录一个step_id，日志里至少要包含这些字段：

有了这些，才能回答"为什么这个用户被Agent错误引导"这类问题。没有可观测性的Agent项目，上线后大概率会在问题排查上消耗两倍于开发的工时。这是我从多个项目里得到的教训。

除了追踪，还要设计"兜底降级链"：Agent执行失败时，自动回退到传统RAG问答；传统RAG如果也没有把握，则降级到"抱歉，我为您转接人工客服"。用户永远不应该面对一个"死循环"的AI。

5. 评测与迭代：从POC到上线后持续进化

最后说评测。Agentic RAG的评测体系比传统RAG复杂得多，因为正确答案不再只是一段文本。

5.1 评测集不是"对答案"，而是"看动作"

传统RAG评测只需要比对生成答案和标准答案的语义相似度，但Agent类系统要评测的是"动作链"是否正确。两个系统可能最终答复文本很像，但一个正确查了订单API再回答，另一个只是从知识库猜了个答案，后者的风险要高得多。

我建议测评集里每个用例都标注期望的工具调用序列。例如：

{ "user_query": "我订单显示签收但没收到，能退款吗？", "expected_actions": [ {"action": "query_order_status", "parameters": {"order_id": 123}}, {"action": "query_logistics_track", "parameters": {"order_id": 123}}, {"action": "retrieve_after_sale_policy", "parameters": {"scene": "not_received"}} ], "expected_final_answer": "需要先为您核实物流状态，若确认异常，可申请售后。" }

评测时，断言的内容有两层：模型输出的action序列是否匹配期望序列；模型的最终答复是否覆盖关键要素。只对最终文本打分，会把"规划错误但话术正确"的Agent判为合格，这是评测体系最严重的失真。

5.2 灰度发布与人工接管位

Agentic RAG上线也要讲究节奏。我的建议是分三批灰度：

• 5%流量：只处理分流器判定的"复杂任务"，同时把top失败case全部导入人工复盘，这个阶段的目标不是满意度，而是找规划漏洞。
• 20%流量：把Agent边界扩大到有一定确定性的任务，设置一个置信度阈值，低置信度直接转人工，不硬答。
• 50%以上流量：确认失败率稳定后放开，但保留人工接管通道。

灰度阶段最容易被忽视的是"人工接管位"的设计：Agent回复下方要有明确的一键转人工入口。这不是UI问题，是系统兜底问题。用户连续两次表示"没解决"时，Agent必须主动转人工，不允许继续和用户打太极。这个规则要写在规划器Prompt里，也要写在调度代码里，双重保障。

5.3 失败样本回流与进化循环

Agentic RAG系统上线只是开始，真正的工作量在迭代。

我习惯每周拉一次失败样本清单，筛选标准是：转人工率高、用户重复提问、用户情绪负向（需要做简单的情绪分类标注）。每个失败样本都回到评测集里，先人工标注"期望动作链"，再跑回归测试，看新版本有没有修复该case、有没有引入新的回归问题。

一个很实际的规律：前两周的样本集中在检索工具触发错误，例如该走订单查询时走了知识库；三到四周后会集中在多轮记忆问题，例如用户补充的信息没有影响后续动作；五到六周后集中在业务规则变化导致的过期回答。每个阶段都需要不同的优化手段，没有一劳永逸的方案。

我还有个个人习惯：每周选一个失败案例，完整回放它的链路追踪数据，从分流器到工具调用，逐条看当时日志，你会发现大量"看起来不致命但实际误导了模型"的小细节。比如某个工具描述里有一个模糊词，导致模型在20%的case里路由错误。这些细节只有在全链路复盘里才能暴露出来。

工业级AI客服从来不是"上一个模型就完事"的项目，它更像一个持续训练和治理的系统工程。Agentic RAG给了它一个更接近真实客服工作方式的骨架，剩下的，就是靠每一次失败样本打磨出来的功力。