企业官网建设流程全解析

智能客服助手这个题目，看起来像是教科书里的一个章节案例，但真把它当成一个能上线跑的系统来做，坑远比想象中多。我前后参与过三个不同规模的客服机器人项目，从最早的关键词匹配，到后来的意图分类，再到现在的 Agent + RAG 架构，每一代方案都有它适用的边界。这一章要聊的，就是把大模型、检索增强生成、工具调用和路由调度这几块拼成一个真正能接客的智能客服助手，而不是一个只会说"抱歉我没听懂"的玩具。

这篇文章适合谁看？如果你已经了解大模型的基本调用方式，知道什么是向量检索，但不知道这些东西怎么组装成一个完整系统，那这篇就是写给你的。如果你是完全零基础，也没关系，我会在关键概念处用生活化的例子解释清楚。核心关键词包括智能客服、Agent、RAG、工具调用、路由，这几个词基本构成了整套系统的骨架。

1. 为什么智能客服不能只靠一个大模型硬撑

1.1 纯大模型方案的三个致命短板

很多人第一反应是：客服嘛，接个大模型 API，把用户问题丢进去，让它回答不就行了？我最早也是这么想的，结果上线第一天就被打脸。

第一个短板是知识时效性和准确性问题。大模型的训练数据有截止日期，你公司的产品价格、退换货政策、活动规则这些每天都在变，模型根本不知道。你问它"你们家会员多少钱一年"，它要么瞎编一个数字，要么说"建议您咨询官方客服"——那我要你干嘛？

第二个短板是幻觉问题。大模型在不确定的时候不会说"我不知道"，它会非常自信地编造。客服场景里这是灾难性的，用户问"支持七天无理由退货吗"，模型编一个"支持三十天"，后面就是投诉和纠纷。

第三个短板是无法执行实际操作。用户说"帮我查一下订单 12345 的物流"，纯大模型只能干瞪眼，它没有查数据库的能力。客服的核心价值不只是回答问题，还要能办事——查订单、改地址、发起退款、转人工，这些都是"动作"，不是"文本"。

提示：判断一个客服场景要不要上大模型，先问自己一个问题——用户的问题里，有多少比例是需要查实时数据或执行操作的？如果超过三成，纯大模型方案直接放弃。

1.2 RAG 解决"知道什么"，Agent 解决"能做什么"

这两个概念经常被混在一起讲，其实分工很清晰。

RAG（检索增强生成）解决的是知识问题。它的思路是：把公司的文档、FAQ、产品手册切碎，存进向量数据库，用户提问时先检索出最相关的几段内容，再把这几段内容作为"参考资料"塞进大模型的提示词里，让模型基于这些资料回答。打个比方，大模型是个聪明的客服新人，RAG 就是在他面前摊开一本随时更新的业务手册，他照着手册回答，就不会瞎编。

Agent（智能体）解决的是行动问题。它给大模型装上了"手脚"，让模型可以调用外部工具。用户说"帮我查订单"，Agent 会判断这需要调用"订单查询工具"，把订单号作为参数传进去，拿到结果后再组织语言回复用户。Agent 的核心是"决策"——它要决定当前这轮对话该不该调工具、调哪个工具、参数怎么填。

一个完整的智能客服助手，是 RAG 和 Agent 的结合体：RAG 负责"答得准"，Agent 负责"办得成"。而路由则是这两者之上的调度层，决定用户这句话到底该走知识问答、工具调用，还是直接转人工。

1.3 路由层：被大多数人低估的关键模块

我见过太多项目把路由当成一个 if-else 随便写写，结果系统一复杂就乱套。路由的本质是意图分流，它要在用户消息进入系统的最前端，快速判断这条消息的归属。

举个实际例子，用户发来"我昨天买的东西怎么还没到"，这句话可能对应三种处理路径：如果用户已登录且能识别订单，走订单查询工具；如果用户没登录，走知识问答解释物流时效；如果用户情绪激动带脏话，直接转人工。路由判断错了，后面全错。

路由的实现方式有好几种，从简单到复杂依次是：关键词规则匹配、小模型意图分类、大模型意图判断。我的经验是，用大模型做路由判断性价比最高，因为客服场景的意图边界模糊，规则写不全，小模型又要标注数据，而大模型给几个示例就能判断得八九不离十。代价是每次路由多一次模型调用，延迟和成本要算进去。

2. RAG 知识库的搭建：切分、向量化与检索调优

2.1 文档切分不是随便切，粒度决定召回质量

RAG 效果好不好，七成看检索，检索好不好，一半看切分。我踩过最大的坑就是文档切得太粗，一个 2000 字的段落塞进向量库，检索出来一大坨，模型抓不住重点。

切分的核心原则是语义完整 + 长度适中。太短了语义不完整，比如把"退货政策"和"退货流程"切成两段，用户问退货，可能只召回一半；太长了噪声多，检索精度下降。我的经验值是每段 200 到 500 字，具体看文档类型。

对于客服场景，我推荐按结构切分而不是按固定字数切分。FAQ 文档就按问答对切，每个 Q&A 一段；产品手册按小节切；政策文档按条款切。如果文档本身没有清晰结构，再用递归切分，优先按段落切，段落太长再按句子切。

# 按结构切分的简化示例 def split_by_structure(doc): chunks = [] # FAQ 类型：按问答对切 if doc.type == "faq": for qa in doc.qa_pairs: chunks.append({ "text": f"问：{qa.question}\n答：{qa.answer}", "metadata": {"source": doc.title, "type": "faq"} }) # 手册类型：按小节切 elif doc.type == "manual": for section in doc.sections: if len(section.content) > 500: # 超长小节再按段落二次切分 chunks.extend(split_by_paragraph(section.content)) else: chunks.append({ "text": section.content, "metadata": {"source": doc.title, "section": section.title} }) return chunks

注意 metadata 一定要带上来源信息，后面检索出来要能追溯到原文，方便排查问题，也方便在回答里标注出处。

2.2 向量化模型的选择：别盲目追大

向量化模型决定了文本被映射成什么样的向量，直接影响检索相似度。市面上模型很多，从几百兆到几个 G 的都有。我的建议是先用中等规模的模型跑通，再根据效果决定要不要换大的。

选型时看三个指标：检索准确率、推理速度、部署成本。客服场景对延迟敏感，用户等三秒就烦躁了，所以推理速度很重要。一个 300M 左右的模型，在普通 GPU 上单条推理能压到几十毫秒，基本够用。如果追求极致准确率上大模型，延迟可能翻几倍，要权衡。

还有一个容易被忽略的点：向量化模型和检索时的查询必须用同一个模型。我见过有人建库用 A 模型，查询用 B 模型，结果相似度算出来全是乱的。这个错误很低级但真的有人犯。

2.3 检索策略：单一向量检索不够用

纯向量检索有个问题：它对精确匹配不敏感。用户问"iPhone 15 Pro Max 多少钱"，向量检索可能召回一堆讲 iPhone 的段落，但就是没召回那个精确的价格表。因为向量检索看的是语义相似，不是关键词匹配。

我的做法是混合检索：向量检索 + 关键词检索（BM25），两路结果合并后重排序。向量检索负责语义召回，关键词检索负责精确召回，两者互补。

def hybrid_retrieve(query, top_k=5): # 向量检索 vector_results = vector_store.search(embed(query), top_k=top_k*2) # 关键词检索 keyword_results = bm25_index.search(query, top_k=top_k*2) # 合并去重 merged = merge_and_dedup(vector_results, keyword_results) # 重排序（可以用交叉编码器，也可以用简单的加权分数） reranked = rerank(query, merged) return reranked[:top_k]

重排序这一步很关键。初步召回的结果排序往往不准，用一个专门的重排序模型（交叉编码器）对候选结果重新打分，能把最相关的顶上来。这一步会增加延迟，但准确率提升明显，值得。

注意：检索的 top_k 不是越大越好。召回太多，噪声也多，模型容易被带偏。我一般初召回取 10 到 20 条，重排序后取 3 到 5 条塞进提示词。

2.4 检索效果的评估：别凭感觉

RAG 最怕的就是"感觉还行"。上线前一定要有一套评估方法。我常用的指标是Hit Rate（命中率）和MRR（平均倒数排名）。

Hit Rate 衡量的是：在测试问题集中，正确答案被召回的比例。比如 100 个测试问题，有 85 个的正确答案出现在召回结果里，Hit Rate 就是 85%。MRR 则进一步衡量正确答案排在第几位，排得越靠前分数越高。

准备测试集的方法：从真实客服对话里抽 100 到 200 个问题，人工标注每个问题的正确答案在哪个文档块里。这个工作费时但值得，没有测试集你根本不知道优化有没有效果。

3. Agent 工具调用的设计：让模型真正能办事

3.1 工具的定义：描述比实现更重要

Agent 调用工具的能力，很大程度上取决于工具的描述写得好不好。模型是根据工具的名称和描述来判断该不该调、怎么调的。描述写得含糊，模型就调错或者不调。

一个好的工具定义包含四要素：名称、功能描述、参数说明、使用场景。我拿订单查询工具举例：

{ "name": "query_order", "description": "根据订单号查询订单的详细状态，包括物流信息、支付状态、商品明细。当用户询问订单进度、物流位置、是否发货时使用此工具。", "parameters": { "order_id": { "type": "string", "description": "订单号，通常是 12 到 18 位数字，用户可能直接提供或从上下文推断", "required": true } } }

注意描述里我特意写了"当用户询问订单进度、物流位置、是否发货时使用"，这就是在告诉模型使用场景。模型看到用户问"我的快递到哪了"，就能对应上这个工具。

3.2 参数填充：从对话里抽取实体

工具调用的难点不在调用本身，而在参数怎么来。用户说"帮我查下订单"，但没说订单号，怎么办？

我的处理策略分三层。第一层，从当前对话抽取，用户如果说了订单号，直接提取。第二层，从上下文推断，如果用户之前提过订单号，从历史对话里找。第三层，主动追问，如果实在没有，让模型生成一句追问"请提供您的订单号"，而不是硬调一个参数为空的工具。

这里有个细节：订单号这类参数最好做格式校验。用户可能把手机号当订单号发过来，工具调用前先校验格式，不符合就追问，避免无效调用。

3.3 多工具编排：一次对话可能调多个工具

复杂场景下，用户一句话可能需要调多个工具。比如"我上周买的那个耳机还没到，帮我看看，顺便问下能不能改地址"，这需要先查订单，再判断能否改地址，可能还要调改地址工具。

这种多步编排，用LangGraph这类框架会比较顺手。它把 Agent 的执行过程建模成一张图，节点是工具调用或模型推理，边是流转条件。相比简单的 ReAct 循环，图结构能更清晰地表达"先查订单，如果已发货则走改地址流程，如果未发货则走取消重下流程"这种分支逻辑。

# LangGraph 风格的节点定义（伪代码） graph.add_node("route", route_intent) graph.add_node("query_order", query_order_tool) graph.add_node("check_shipped", check_shipping_status) graph.add_node("change_address", change_address_tool) graph.add_node("reply", generate_reply) graph.add_edge("route", "query_order") graph.add_conditional_edges( "check_shipped", lambda state: "shipped" if state.shipped else "not_shipped", {"shipped": "change_address", "not_shipped": "reply"} )

3.4 工具调用的失败处理

工具会失败，网络会超时，数据库会挂。Agent 必须有失败处理机制。我的做法是给每个工具调用包一层重试和降级逻辑。

重试策略：网络类错误重试 2 到 3 次，业务类错误（比如订单不存在）不重试直接返回。降级策略：工具彻底不可用时，Agent 要能优雅地告诉用户"系统繁忙，请稍后再试或转人工"，而不是抛一个错误堆栈。

还有一个坑：工具调用的超时时间要设合理。设太短，正常查询也被掐断；设太长，用户干等。我的经验是数据库查询类 3 秒，外部接口类 5 秒，超过就降级。

4. 路由与并发：系统能不能扛住真实流量

4.1 意图路由的三种实现与取舍

回到开头说的路由。具体怎么实现，我详细展开。

关键词规则路由：维护一个关键词到意图的映射表，命中就走对应路径。优点是快、零成本、可控；缺点是覆盖不全，用户换个说法就失效。适合作为兜底和快速通道。

小模型意图分类：训练一个文本分类模型，输入用户消息，输出意图标签。优点是准确率不错、速度快；缺点是需要标注数据，新意图要重新训练。适合意图相对固定的场景。

大模型意图判断：把用户消息和意图列表一起给大模型，让它判断。优点是灵活、无需训练、新意图改提示词就行；缺点是每次多一次调用，有延迟和成本。适合意图多变、冷启动的场景。

我的实际方案是三者结合：高频明确意图走关键词快速通道，中等复杂度走大模型判断，大模型判断置信度低的走小模型兜底或直接转人工。这样兼顾了速度和准确率。

4.2 并发压力下的三个瓶颈

智能客服上线后，并发是绕不开的。我遇到过三个典型瓶颈。

第一个瓶颈是模型推理。大模型推理是 GPU 密集型的，并发一高就排队。解决办法是请求队列 + 限流，超过处理能力的请求排队等待或降级到轻量模型。别指望无限扩容，成本扛不住。

第二个瓶颈是向量检索。向量数据库在数据量大、并发高时检索会变慢。优化手段包括：建索引（HNSW 之类）、缓存高频查询结果、分片。高频问题比如"运费多少"这种，直接缓存答案，不用每次都检索。

第三个瓶颈是工具调用的外部依赖。订单系统、物流接口这些外部服务，并发一高就可能超时。必须做熔断和降级，外部服务挂了不能拖垮整个客服系统。

4.3 会话状态管理：多轮对话的记忆问题

客服是多轮对话，用户不会一句话说清所有事。会话状态管理要解决两个问题：记住上下文和控制上下文长度。

记住上下文好理解，用户前面说了订单号，后面说"帮我改地址"，系统要知道改的是哪个订单。控制长度是因为模型有上下文窗口限制，对话太长塞不下。

我的做法是滑动窗口 + 摘要。保留最近 N 轮完整对话，更早的对话压缩成摘要。摘要用模型生成，把关键信息（订单号、用户诉求、已执行的操作）提取出来。这样既保留了关键信息，又控制了长度。

def manage_context(history, max_turns=10): if len(history) <= max_turns: return history # 保留最近 max_turns 轮 recent = history[-max_turns:] # 更早的压缩成摘要 older = history[:-max_turns] summary = summarize(older) return [{"role": "system", "content": f"历史对话摘要：{summary}"}] + recent

4.4 转人工的时机判断

智能客服不是万能的，该转人工就得转。判断时机有几个信号：用户明确要求转人工、连续两轮没解决问题、用户情绪负面（检测到脏话或强烈不满）、涉及敏感操作（大额退款、账号安全）。

转人工不是简单地把对话丢过去，要带上上下文。人工客服接手时应该能看到之前的对话记录、用户信息、已尝试的解决方案，避免让用户重复描述。这个交接体验做得好不好，直接决定用户对客服的整体评价。

5. 上线后的真实踩坑记录

5.1 检索召回了过期文档

上线两周后收到一个投诉：用户问活动规则，机器人回答的是上个月的活动。排查发现，旧活动的文档没从知识库里删掉，检索时新旧文档都在，模型随机选了一个。

这个坑的教训是：知识库要有生命周期管理。文档要带生效时间和失效时间，检索时过滤掉过期文档。同时建立文档更新流程，活动结束就下线对应文档，别指望人工记得清理。

5.2 工具调用陷入死循环

有一次 Agent 卡在一个循环里出不来：查订单失败，它重试，还失败，再重试，无限循环，把接口打挂了。

修复方案是给工具调用设最大重试次数和总步数上限。单个工具最多重试 2 次，整个 Agent 执行最多 10 步，超过就强制结束并转人工。这个上限一定要设，不然模型可能陷入各种奇怪的循环。

5.3 提示词里的知识被模型"发挥"了

RAG 把检索到的文档塞进提示词，本意是让模型照着答。但模型有时候会"发挥"，把文档里的信息和其他知识混在一起，答出文档里没有的内容。

解决办法是在提示词里强约束："只能基于以下资料回答，资料中没有的信息不要编造，如果不确定就说不知道并建议转人工。"同时降低模型的温度参数，减少随机性。实测下来，加了强约束后幻觉率明显下降。

5.4 并发高峰的雪崩

大促当天流量翻十倍，系统直接雪崩。事后复盘，问题是没有限流和降级，所有请求都往模型和数据库打，把下游打挂了，然后整个系统连锁失败。

补救措施是加了三层保护：网关层限流，超过阈值直接返回"当前咨询人数较多"；模型层排队，超过队列长度降级到轻量模型；工具层熔断，外部服务错误率超阈值就快速失败。加了这三层之后，再遇到高峰至少不会全挂。

6. 一些可以复用的工程经验

6.1 提示词要版本化管理

提示词是智能客服的核心资产，但很多人把它硬编码在代码里，改一次要发一次版。我的做法是把提示词抽出来，用配置文件或专门的提示词管理平台，支持版本、灰度、回滚。这样调优提示词不用动代码，效率高很多。

6.2 全链路日志和可观测性

客服系统出问题，排查起来最怕没日志。我的经验是每个环节都打点：路由判断结果、检索召回的文档 ID、工具调用的入参出参、模型的输入输出、最终回复。这些日志串起来，才能还原一次对话的完整链路，定位问题在哪一环。

6.3 灰度发布和 A/B 测试

新版本别一次性全量。先放 5% 流量，观察指标（解决率、转人工率、用户满意度），没问题再逐步放量。同时可以做 A/B 测试，对比不同提示词、不同检索策略的效果，用数据说话而不是拍脑袋。

6.4 成本控制

大模型调用是花钱的，客服量大起来成本很可观。控制成本的手段：高频问题缓存答案、简单意图走小模型、限制单次对话的模型调用次数、设置单用户日调用上限。这些措施加起来，能把成本压下来一大半。

我在实际项目里最深的一个体会是：智能客服的难点从来不是模型本身，而是工程化的细节。模型能力再强，检索召回不准、工具调用不稳、并发扛不住，系统照样不能用。把 RAG 的检索质量、Agent 的工具可靠性、路由的判断准确率这三件事做扎实，比追最新的模型重要得多。另外，别指望一次上线就完美，客服场景的长尾问题特别多，持续收集 bad case、持续迭代，才是正道。