做智能客服这个方向，说实话最开始我是持怀疑态度的。早几年的机器人客服，无非是关键词加正则的命中怪，或者点菜单式的多轮引导，用户问一句"我上周买的充电宝坏了怎么办"，它能让你绕三个菜单再转人工。直到大模型和Agent概念真正落地之后，这件事才出现了本质变化。
这篇内容记录的是一个基于ModelEngine框架搭建智能客服系统的完整实践过程，核心解决两个问题：第一，把散落在产品文档、历史工单、聊天记录里的业务知识，变成真正可检索、可回答的知识库；第二，抛弃"一个Agent包打天下"的思路，升级为多智能体协作的服务架构，让意图识别、售前咨询、订单处理、售后安抚各司其职，覆盖完整的用户服务链路。我会把知识库构建的细节、Agent角色的划分逻辑、ModelEngine里的编排方式、评估体系和上线后踩过的坑都写清楚，适合正在做智能客服、RAG应用或者Agent编排的开发者参考。
1. 为什么选ModelEngine：客服场景的架构选型思考
1.1 传统客服在真实业务里的三个死穴
先说说这个项目立项时的背景。我这边服务的业务是一个中等规模的电商平台，SKU几千个，用户问题集中在物流、退换货、发票、优惠券使用、售后时效这几类。老系统是标准的"FAQ关键词分类+菜单式工单录入"，表面上能跑，但实际运营数据很难看。
第一个死穴是维护成本爆炸。运营同学每周都在改关键词规则，新增一个活动、调整一次物流政策，就得同步改规则库和话术库，规则的排列组合指数级增长，越来越难维护。第二个死穴是长尾问题完全兜不住，用户一句"我朋友的地址填错了但订单已经发货了"这种复合型问题，关键词命中的概率基本为零。第三个死穴更致命——答非所问比不答伤害更大。规则匹配到一个带相关字词的FAQ就硬答，用户觉得你在羞辱他，满意度直线下降。
立项的时候我们做过一个统计：老系统的问题解决率大概只有40%，剩下的60%最终全部转人工，人工客服团队几十号人还是忙不过来，高峰期的平均排队时长一度超过十分钟。这就是推动我们用大模型重新做客服系统的原始动力。
1.2 ModelEngine到底做了什么
市面上可选的方案不少，有直接调用各家大模型API做Prompt的，有基于开源框架自己搭Agent的，也有类似ModelEngine这样专门做模型编排和智能体工作流的中间层。我们最终选择ModelEngine，主要是看中它在三个层面的能力，这三件事恰好都是客服场景的刚需。
第一层是多模型路由。客服场景的请求量有明确的高峰低谷，双十一大促和凌晨三点的QPS差两个数量级。如果所有请求都走最强的大模型，成本根本扛不住。ModelEngine支持设置路由策略，意图识别、情感判断这类简单任务走小模型，复杂生成和推理任务走大模型，还可以在指定模型超时或返回异常时自动切换备用模型。这一点对生产环境来说太关键了。
第二层是Agent的注册、编排与工具调用。客服系统里Agent要调用的内部接口相当多：订单查询、物流追踪、退款申请、优惠券核销、工单流转……ModelEngine以函数调用的方式统一管理这些工具的入参出参和权限，Agent只需要声明"我要用什么工具"，框架层去处理参数校验、超时重试和异常捕获。编排方面，它支持把多个Agent和外部API串成有状态的工作流，这对后面的多智能体协作设计帮助很大。
第三层是可观测性。老项目排查线上问题全靠日志，而LLM应用是典型的"同样的输入可能出不同的输出"，不确定性很强。ModelEngine提供完整的链路追踪，每一轮对话从意图识别到检索再到最终生成的每一步，都能看到用的什么模型、prompt是什么、工具返回了啥。这在测试和线上排查阶段省了太多力气。
1.3 整体架构与核心组件
整个系统的架构可以分成四层来看：
接入层负责渠道统一，微信公众号、网页H5、小程序、App的咨询入口都接到同一个网关，输出统一的会话协议。智能体层是业务逻辑的核心，包含意图识别、知识库问答、订单处理、售后安抚、数据运营五个Agent，它们之间按工作流协作。引擎层就是ModelEngine，负责模型路由、Prompt管理、工具注册、工作流编排和链路追踪。数据层包含业务数据库、向量数据库、Redis缓存和知识库文件存储。
数据流向是这样的：用户的消息先经过网关进入意图识别Agent，判断用户意图并抽取关键实体；意图明确后，工作流根据路由规则把任务分发给对应的业务Agent；业务Agent如果需要查订单、查物流，就通过工具调用去业务系统取数；涉及知识类问题则去向量库走检索增强。所有Agent的回答统一返回给网关，由网关做最终回复的格式化和敏感信息过滤。
这个架构看起来不复杂，但落地过程中每一个环节都有不少细节坑，下面逐块说。
2. 知识库构建：回答质量的"第一道工序"
知识库是客服回答质量的地基。很多项目做RAG，把文档一切、一存、一检索就完事了，上线之后发现回答质量不行，最后都栽在源数据处理和切块策略上。这一节我把我们跑通并且验证有效的完整流程拆开讲。
2.1 源文档的清洗与结构化
第一步是盘点知识源。我们项目的知识主要来自四类：产品说明书和帮助文档（Word/PDF）、售后政策文档、运营发布的公告（含活动规则）、历史工单和客服聊天记录。前三类是"官方知识"，优先级最高，最后一类用来补充长尾问法的表达方式。
官方文档的清洗有几个实操要点。PDF要先通过OCR转成可编辑文本，但OCR的错误率在表格和复杂排版上特别高，比如"申请退款"识别成"申请退软"，这种错误后面全链路都会放大，所以OCR结果必须有人工抽检环节，抽检比例至少在20%以上。Word和Markdown文档相对好处理，但要注意提取目录结构和标题层级，这些结构信息在后面切块时非常有用。
表格是个大坑。客服知识里有大量运费规则、退换货时效表，直接转成纯文本后结构全丢，检索和回答都用不上。我们的做法是先把表格单独抽取出来，转成Markdown表格格式，并且保留表头和上下文说明。向量化之后，表格型知识还是会有一定的结构损失，这个后面专门说补救方案。
历史工单和聊天记录的处理更麻烦，脏数据太多。客服聊天里有一堆"亲亲""您好"之类的寒暄词、表情符号、错别字，还有用户隐私信息。我们的清洗流程包括：去重（同一个工单反复流转产生的重复片段）、去除个人信息（手机号、地址、订单号打码）、拼写纠错、口语化表达归一化（"咋整""咋办"统一成"怎么办"）。清洗完的数据不能直接进知识库，还要人工标注一批高质量的"标准问答对"，每个问答对包含用户常见问法、标准答案、答案来源链接。这批标注数据后来在评测阶段帮了大忙。
2.2 切块策略：chunk size、overlap与语义边界
切块是RAG里最容易被低估的环节。我们的实验过程很有意思，最开始用固定512 token一刀切，实测下来检索命中率还行，但回答里频繁出现"牛头不对马嘴"——因为一个完整语义被切断了，比如"七天无理由退货的条件是……"和"以下情况除外……"被分到了两个块里，检索到一半答案，Agent就照着不完整信息胡说了。
后来我们改成了**"结构优先+动态切块"**的策略。具体规则是：
- 先按文档的标题层级拆成章节，再在章节内部处理。
- 文本段落优先保持完整，一个段落超过设定阈值才继续切；设定阈值我们最后定的是512 token，这个值在不同业务里差别很大，必须自己实验，我们对比了128、256、512、1024四档，512在召回率和上下文相关性上综合最优。
- 相邻块之间设置10%-15%的重叠token，防止关键信息正好落在边界上被截断。
- 列表、表格这种结构化内容不要跟段落混在一个块里，单独成块并附带说明性前缀。
除了切块本身，我们给每个块都补充了元数据：来源文档名、文档版本号、所属产品线、更新时间、原始链接。这些元数据在检索阶段可以做过滤，比如用户问的是"空调安装费用"，向量检索时可以先用类目过滤掉彩电和冰箱的知识块；元数据里的更新时间还能用来做知识时效性校验，政策类问题会优先召回最新版本的知识。
2.3 Embedding模型与向量库的选型
切块完成后进入向量化环节。我们对比了多个Embedding模型，包括通用中文向量模型和一些开源的文本向量模型，评测指标用的是检索召回率（Recall@10）和检索结果的人工相关性打分。测试集用了500条真实客服问题，每条都有对应的标准知识块。
实测结果给两个结论：一是开源模型和商业API模型的差距没有想象中大，在垂直领域数据上，用业务语料微调过的开源模型甚至能在召回率上反超；二是Embedding的这种细微差距，远不如切块策略和重排序环节带来的提升明显。也就是说，把精力投入到数据清洗和检索链路优化上，性价比远高于纠结Embedding模型选哪个。
向量库方面我们最后用的是开源向量数据库，部署在K8s里，索引类型HNSW，M值设为16、efConstruction设为200，实测在千万级向量规模下召回率稳定在95%以上，单查询P95延迟在30毫秒左右。如果向量规模不大，用关系型数据库的向量插件也完全够用，没必要为了"上向量库"而多维护一个组件。
2.4 检索增强：混合检索、重排序与上下文组装
只靠向量检索的效果其实不够稳。向量检索擅长语义相似，但对"关键词精确匹配"很钝感，比如用户问的"SN序列号在哪儿看"，知识库里写的是"产品机身标贴上的序列号"，语义很接近但关键词重叠少；反过来，用户问"退货运费谁出"，如果知识库里同时有"买家承担运费"和"卖家承担运费"两个条款，向量检索会分不清该给哪个。
我们的解决方案是混合检索：BM25关键词检索和向量检索并行，各自取Top 20，合并去重后再进重排序模型。重排序用的是交叉编码器，把"用户问题+候选知识块"拼在一起打分。加了重排序之后，评测集上的答案相关命中率从78%提升到了91%，效果非常明显。代价是重排序阶段增加了100毫秒左右的延迟，后面讲性能优化时会提到怎么把这段延迟消化掉。
上下文组装也有讲究。不能简单地把检索到的Top 5块一股脑塞进Prompt，要按重排序分数排序，并且在每块知识前面标注来源和格式。同时要给Agent一条明确的指令：只能基于给定知识回答，知识不足时直接说"这个问题我需要转人工处理"，不允许编造。我们把这条指令用特殊标记框起来，放在系统Prompt的尾部靠近用户输入的位置——实测大模型对靠近输入末尾的指令遵从性更高，这个细节很多人容易忽略。
3. 从单智体到多智能体：客服场景为什么需要协作
3.1 单Agent的瓶颈：一个"万能客服"并不存在
MVP版本我们只做了一个全能客服Agent，把所有Prompt、知识库工具和业务接口都塞给一个Agent管理。跑了两周就发现这条路走不通，问题非常典型。
先说Prompt冲突。客服应答需要口语化、耐心、简洁，但处理订单查询时需要严格的参数提取和逻辑判断，这两种风格放在同一个Prompt里互相打架。模型在"该温柔还是该严谨"之间反复摇摆，回答质量不稳定。
再说责任边界模糊。一个售后问题进来，Agent既要做情绪安抚，又要查订单状态，还要判断是否符合退款政策，最后还要给用户输出解决方案。四个任务在同一个上下文里串行执行，一旦中间某一步的工具调用出错，整个回复就崩了，而且很难定位是哪个环节出了问题。
还有一个痛点是权限安全。订单查询和退款操作涉及用户敏感数据，如果所有任务都在同一个Agent里，根本无法做细粒度的权限控制。后来我们做多智能体，顺手解决了这个合规问题——只有订单Agent能访问订单接口，知识库Agent和数据分析Agent根本接触不到用户订单信息。
3.2 Agent角色划分与职责清单
我们的多智能体方案总共拆了五个角色，每个角色的定位都紧扣真实的客服团队分工：
- 意图识别Agent（Router）：判断用户意图、抽取核心实体，是所有请求的入口。
- 知识库问答Agent（QA）：负责任何与产品、政策、活动相关的知识性问答，只访问向量知识库，不触达业务系统。
- 订单处理Agent（Order）：负责订单查询、物流追踪、退款申请、地址修改等操作类任务，需要调用业务API。
- 售后安抚Agent（Service）：在用户情绪负面或投诉场景下介入，负责情绪识别、安抚话术和升级路径建议。
- 数据运营Agent（Analyst）：面向内部运营人员，分析高频问题、满意度数据、Agent拒答率，输出报表建议。
这个分工对应到真实客服团队，"不同岗位各管一摊"，用户感知上是一个整体，内部却是清晰的责任边界。每个Agent有自己的专属Prompt、允许调用的工具白名单、可以访问的数据范围。Prompt的总长度大幅缩短，模型的表现稳定性明显提升。
3.3 ModelEngine里的工作流编排与协作机制
角色定了之后，关键问题是怎么让它们协作。我们在ModelEngine里设计了两种协作模式。
第一种是顺序路由模式，适合请求意图单一的情况。用户消息进来，Router判断意图为"知识咨询"，就直接把请求交给QA Agent，QA回复后整个流程结束，链路最短、延迟最低。约70%的请求走这条路。
第二种是动态分工模式，适合复杂请求。比如用户说"我买的电饭煲煮饭有焦味，我申请过退货了但还没人来取件，能帮我催一下吗"。Router判断同时涉及售后知识、订单状态和人工催办，工作流会把请求同时分发给QA Agent获取退换货政策，Order Agent查询退货进度，如果用户情绪词触发阈值，再通知Service Agent介入生成安抚式回复。最终由主控Agent汇总各子Agent的结果，生成统一的用户回复。
这种协作机制在技术上就是一套消息协议+状态机。每个Agent收到的输入是一个标准信封结构，包含消息ID、来源Agent、目标Agent、消息类型、会话上下文ID和业务数据JSON。主控Agent维护一张状态表，记录每个会话当前处于哪个阶段、哪些子任务已完成、哪些还在等待。子Agent返回的结果会写回共享上下文，并触发状态机跳转到下一步。
ModelEngine对这个过程的支持主要体现在两个方面：工具调用的信令统一——子Agent调用业务API不需要自己拼HTTP请求，框架层统一管理鉴权和重试；会话上下文隔离又共享——每个子Agent看到的是被权限过滤过的信息子集，不会泄露业务系统内部数据。
3.4 会话级记忆与上下文管理
多智能体协作最头疼的是记忆管理。一个用户的咨询会话可能持续多轮，中间还穿插Agent的转交，如果每个Agent各记各的，就会出现用户上一轮刚说完"我地址是北京朝阳区"，下一轮换了个Agent又得重新问一遍，这个体验非常崩溃。
我们的方案是做一个独立的会话记忆服务，用Redis做存储，记录三个层级的记忆：
- 短期记忆：最近十轮对话原文，按时间序排列。任何Agent在生成回复前都会读取这份短期记忆，确保对话上下文连续。
- 业务记忆：从对话中抽取出来的关键实体和状态，比如订单号、用户诉求、当前处理进度，用结构化的JSON保存。这样即使Agent轮换，新接手的Agent从业务记忆里就能拿到"这个用户已经发起过退款申请，等待取件中"。
- 长期记忆：用户在历史会话中的偏好和行为模式摘要，比如"该用户倾向于优先选择最快时效的物流"，这部分做了脱敏处理，只存抽象结论不存原始数据。
记忆的不一致问题靠版本号机制解决。每次业务记忆更新都会递增版本号，子Agent写入时携带版本号，主控Agent发现版本冲突（两个Agent基于不同版本同时写）时，以业务流程状态机的当前状态为准做冲突合并。上线之前我们认为这个机制可有可无，直到在一次压测中同时触发退款查询和地址修改两个子任务，才发现没有版本控制的话数据会互相覆盖，这个坑真实地让人肉疼。
4. 一次完整对话请求的链路细节
这一节我们把一次典型的用户对话从头到尾拆一遍，看看每个环节具体是怎么实现的，参数怎么设，异常怎么处理。
4.1 意图识别与实体抽取：小模型也能干大活
意图识别Agent是整个系统的入口，性能要求最高。我们最开始想着用最强的大模型来做意图识别，实测单次调用延迟300毫秒以上，高峰期根本扛不住。后来改成小模型加提示工程，延迟降到80毫秒以内，准确率只掉了不到两个百分点。
意图识别的核心是一份分类Schema，定义了系统支持的意图类型、每种类型的描述、需要的实体字段和示例问法。这里有个经验：意图类型不要设计得太细，比如"查询物流"和"修改收货地址"就应该分开（处理逻辑完全不同），但"催发货"和"催物流更新"其实是一个意图，合并即可。我们最终保留了25个意图类型，覆盖了95%以上的真实用户请求。
实体抽取也是必做的环节，因为后面业务Agent需要结构化的参数。订单号、手机号、商品名称、诉求类型，这些实体在用户消息里是自然语言表达的，得转成JSON。我们的做法是在Schema里用few-shot示例标注实体位置，再让模型按JSON格式输出。抽取结果的校验靠规则兜底：手机号有正则校验，订单号按业务规则校验格式，校验不通过就主动追问用户，不硬着头皮往下走。
意图识别模块还承担了一个重要职责——兜底判定。当模型的置信度低于阈值（我们设的是0.75）时，系统不会强行进入业务处理，而是用"您的问题我还没有完全理解，请问是想咨询退换货、物流还是发票方面的问题？"来引导用户。别小看这个简单的机制，它直接决定了系统是"偶尔聪明"还是"始终靠谱"。
4.2 工具调用与结构化输出：让Agent真正能"做事"
多智能体的核心能力在于工具调用。我们通过ModelEngine向Agent暴露了十二个业务API，包括查询订单详情、查询物流轨迹、提交退款申请、修改地址、查询优惠券、创建工单等等。每个工具都按统一的JSON Schema描述入参、出参和校验规则，Agent通过"我要调用某工具，参数是……"的方式触发调用，框架层负责真正的HTTP请求。
这里要重点说三个生产经验。
第一个是参数必须双重校验。LLM生成的参数是不可靠的，比如"修改地址"可能把楼号字段填错、或者把手机号"13800138000"改成了"1380013800"。我们在框架层加了Schema校验和业务规则校验两层防护，校验失败就向Agent返回错误码和明确的修正提示，让Agent自己调整参数重新调用。实测这套机制能让工具调用的失败率从12%降到2%以内。
第二个是写操作必须二次确认。退款、改地址这类操作影响用户权益，Agent生成准备执行的指令后，信息要拼成一句自然语言回显给用户确认。我们踩过一个坑：某次测试中，用户说"我地址不想要了"，Agent理解成"删除收货地址"，直接调用了删除接口，要不是测试环境数据可恢复，这就是个生产事故。后来规则明确，凡是删除、退款、转账这类高危操作，一律先确认再执行。
第三个是工具超时与幂等。业务API的P95延迟在400毫秒左右，但偶尔会飙到几秒。ModelEngine为每个工具调用设置了两秒的超时和一次重试，同时要求所有写操作接口支持幂等键，同一个请求重复发送不会产生重复退款或重复工单。这属于微服务的老经验，但放到LLM应用里又格外重要，因为模型重试的频率比人类操作高得多。
4.3 多智能体的消息协议与状态机
多智能体协作不是简单地把几个Agent的消息拼接起来，我们实际维护了一套轻量级的流程引擎。消息信封格式如下：
{ "messageId": "msg_20240115_001", "from": "order_agent", "to": "router", "sessionId": "sess_881023", "type": "task_result", "payload": { "taskId": "task_4491", "status": "completed", "data": { "orderStatus": "shipped", "logistics": "SF1234567890", "eta": "2024-01-18" } } }每个子任务都有状态：pending、running、completed、failed、needs_confirmation。主控Agent的流程引擎根据状态机决定下一步动作。比如Order Agent查询订单发现状态是"退款中"，引擎就会触发QA Agent去检索"退款中订单能否修改地址"的知识，再把两个结果合并处理。
这套机制上线之后最直观的收益是问题定位快了。以前单Agent模型胡言乱语，不知道是Prompt问题还是工具问题；现在链路拆开了，哪个Agent返回了什么、工具调用是否成功、状态卡在哪一步，全部有据可查。客服团队的运营同学甚至能直接在管理后台看到"知识库Agent拒答率偏高是因为近期版本把运费规则文档更新了"这种结论。
4.4 降级策略：LLM不可用时的体验保障
没有哪个大模型API敢承诺99.99%的可用性，降级策略必须提前想好。我们设计了三级降级：
第一级是模型降级。主模型超时或连续报错时，ModelEngine自动切换到备用模型，用户在无感知的情况下继续对话。切换的同时会记录链路日志，方便事后排查。
第二级是能力降级。如果模型完全不可用，意图识别和复杂对话功能暂停，系统进入"知识库快速匹配+话术模板"模式。知识库的检索链路不走LLM的生成，直接从已有问答对里匹配最优答案返回。体验上退回早期的FAQ水平，但至少不会整个客服系统白屏。
第三级是人工接管。检测到模型连续多次拒答、或者用户情绪达到投诉级别阈值、或者用户三次以上明确要求转人工，系统自动生成转人工工单，把会话上下文摘要（用户说了什么、系统做过哪些尝试）随工单一起推给人工客服，让人工不用从头读聊天记录。
这三层降级在压测中验证过，模拟主模型全挂的情况下，会话成功率还能维持在85%以上，只是回答质量明显下降。对一个直接服务用户的系统来说，这个兜底能力是必须有的。
5. 评测、调优与成本控制
5.1 评测集与回归测试：LLM应用的质量防线
LLM应用评测是公认的难题，我们一开始也没头绪。反复试验后，形成了一套可执行的方案。
评测集包含400条真实脱敏对话，覆盖所有意图类型、正常句子和"骂人""口语混乱""火星文"的异常输入，每一条都标注了期望的知识来源或期望的工具调用序列。评测分两个维度：结果评测和过程评测。结果评测看最终回复是否正确、是否基于知识库（有引用来源）、语气是否合规；过程评测看意图识别是否准确、是否按预期调用了工具、有没有多余的推理步骤。
执行评测的方式是"规则+LLM裁判"双轨。硬性规则包括：回复是否包含必要信息、知识来源引用格式是否正确、敏感信息是否泄露；LLM裁判负责主观质量打分，用一个大模型对被测模型的回复按"准确、完整、简洁、礼貌"四个维度打分。使用点评测模型和被评模型不能是同一个，否则会有系统性偏好。每次代码或知识库变更都跑一轮完整回归，得分下降超过两个百分点就阻止上线。
这里我想多说一句，评测集是活的。每周从线上对话里捞一批新问题，人工标注后追加进评测集。上线三个月，评测集从最初的300条长到了1000多条。很多感觉"最近回答变差了"的玄学问题，跑一遍评测就定位到了是知识库版本回退还是Prompt被覆盖，这套评估体系是项目能持续迭代的根本保障。
5.2 延迟优化：从5秒到2秒的调优记录
初始版本的完整回复链路延迟将近5秒，用户体验可以用"糟糕"形容。我们把整条链路拆开做了逐段计时，关键优化有四处。
第一是意图识别模型轻量化，从大模型换成小模型，一步砍掉200毫秒。第二是检索链路并行化和结果缓存，向量检索和BM25并行执行，同义问题的检索结果缓存到Redis，缓存命中时检索阶段直接省掉300毫秒。第三是重排序降频，不是所有请求都需要重排序，我们加了规则：知识类问题才走重排序，订单操作类问题直接按向量分数取Top 3，重排序的100毫秒延迟只在必要时发生。第四是核心回复流式输出，首字延迟从2000毫秒降到400毫秒左右，用户感知到的等待时间大幅缩短。
调优之后，知识类问题的P95延迟稳定在1.8秒以内，操作类问题在1.2秒以内。这里有个取舍：流式输出对"最终回复质量评估"和"敏感信息过滤"提出了额外要求，我们是在流式输出之前先做一次完整的安全预检，再允许呈现，压测验证没有明显劣化。
5.3 成本控制：模型分级、会话级缓存与请求瘦身
客服系统是真实的业务系统，成本必须算明白。上线第一个月账单出来的时候，数字把我们吓一跳——每万次对话的成本比预期高了40%。逐项排查之后做了三个调整。
第一个调整是模型分级。意图识别、实体抽取、情绪判断这些"判别式"任务全部走小模型，只有最终生成用户回复才走大模型。这个调整直接让账单数字降了约40%。第二个调整是Prompt缓存。系统Prompt（角色设定、知识库使用规则）是固定的，走带缓存的大模型接口，命中缓存的Prompt部分不再计入计费tokens。第三个调整是回复缓存。FAQ性质的问题每天有大量重复，我们把"标准问+标准答"直接缓存，命中时连模型都不用调用。调整后每万次对话的成本降到原来的四成左右，而且回答质量评测分数几乎没有变化。
还有一条容易忽视的成本项是知识库的Embedding更新。每次文档更新都要重算全部或部分向量的Embedding，这块也要计入成本。我们的做法是增量更新：只重算受影响的知识块，更新的批次控制在512以内，避免一口气全量重算产生大额账单。
6. 上线之后的坑与经验沉淀
6.1 知识库更新与线上一致性：被忽略的"脏数据"问题
上线初期最频繁的线上问题不是模型不聪明，而是知识过期。某次平台调整运费政策，运营同学在知识库里把"满99包邮"改成了"满69包邮"，但我检索链路里用的知识库版本还是旧的，导致用户问的时候给的是错误信息——用户在下单页看到满69包邮，客服却说满99，场面一度非常尴尬。
我们后来建立了知识库版本管理和发布流程：文档更新进入待发布队列，自动完成清洗和切块，预览环境跑一遍针对这个更新的迷你回归评测，通过后才把新版本的知识库切换为线上生效版本，并记录生效时间。所有对话的检索日志都保留版本号快照，事后能定位"这个用户当时看的是哪个版本的知识"。对政策变动频繁的客服场景，这一套流程比任何模型调优都重要。
6.2 拒答与转人工：不要追求100%自动化
做一个客服系统，会天然地想"自动化率越高越好"，但这个目标是个陷阱。用户的诉求千奇百怪，有些就是需要人工处理，比如复杂投诉、法律纠纷、售后扯皮。强制让AI处理这些问题的结果，是用户满意度崩塌。
我们的做法分两步：第一，在QA Agent的Prompt里明确写了"宁可拒答，不可编造"。评测集里专门有一类"拒答样题"，凡是知识库里没有明确依据的问题，正确的回答应该是"抱歉，您的情况比较特殊，我帮您转接人工客服"，而不是东拼西凑给一个看似合理的答复。第二，主动识别"必须转人工"的场景。投诉升级、涉及价格纠纷、用户情绪强烈等场景，不是一路安抚到底，而是经历一两轮缓和后启动人工接管流程。
上线三个月后的数据是：完全自动解决率51%、AI辅助人工解决率35%、剩余14%转人工。这个数字不是最高，但满意度从老系统的70%提升到了86%。要记住，用户最终要的是"解决问题"，不是"被AI接待"。
6.3 一些贯穿全程的实操体会
最后分享几点做这个项目攒下的经验，比较零碎但都很实在。
第一，Prompt工程在系统里不是一次性的。上线后我们维护了一份Prompt变更记录，每次修改都标注原因、影响范围、是否影响评测分数。很多问题表面是"模型不聪明"，实际是"Prompt被某次改崩了"。正式环境对Prompt修改走和代码修改一样的评审流程，这个原则请务必坚持。
第二，知识库质量要主动监控。我们搭建了一个简单的知识老化看板，统计每个知识块的被查询频率、被引用频率和拒答关联度，三个月以上从未被检索到的知识块，会被标记为"疑似过期"，推给运营确认。数据分析Agent干的活之一就是每周生成"知识库健康度"报告。
第三，多智能体的价值需要在真实流量里验证。单Agent在Demo里表现看起来很棒，因为演示数据都是准备好的；真实流量的长尾问题会迅速暴露单Agent的脆断点。如果预算和人手有限，建议先把意图识别和知识库问答两个角色的多Agent做扎实，再逐步扩展到运营分析等旁路能力，不要一开始就铺全所有角色。
我一直觉得，智能客服项目最刺激的部分不在模型本身，而在把"模型能力"翻译成"稳定的业务服务"这个过程。ModelEngine给了我们一个相对完整的编排底座，但知识库的质量、Agent的边界设计、评测体系的建设、线上兜底机制，这些才是一个客服系统能不能真正立住的胜负手。项目上线大半年，从最初的人工为主、AI打杂，走到现在的AI为主、人工兜底，每一步都是靠测试集里多跑出来的一条数据、线上对话里多捞到的一个问题堆出来的。希望这篇文章里的细节能帮你少踩几个坑。
