做智能客服这几年我最大的感受是真正难的不是调通一个大模型而是把知识、流程、工具串成一个能稳定产出价值的系统。这次的项目是基于 ModelEngine 从零搭建一套智能客服重点拆解了三个问题知识库怎么构建检索怎么做到答得上多智能体怎么协作不打架。常见的情况是知识库塞进去几千篇文档模型回答出来还是一本正经地胡说。RAG 链路里任何一环没做好都会让答案质量断崖式下跌。而一旦引入多智能体意图路由和上下文管理又会成为新的老大难。这套系统用 ModelEngine 作为统一推理与编排层把这摊事管了起来上线后人工转接率从 40% 左右降到 18%整体回复时长大多在 3~5 秒内。内容适合想把智能客服真正落地的开发者和产品团队也适合对知识库自动化跃跃欲试的学习者。1. 整体架构为什么先搭一个 ModelEngine 底座1.1 智能客服系统里的三个老大难先说直接调大模型接口的做法。做完一版 demo 很容易业务里写上几个接口调用传一段消息进去答案就出来了看起来挺像回事。但真放到生产环境问题一个接一个。第一个是模型迭代太频繁。今天这个效果好明天那个更便宜想切换模型的时候发现业务代码里到处是模型名、入参出参、prompt 模板换一次模型等于把整个系统伤筋动骨一遍。第二个是并发和延迟很难平衡。客服场景工作时段流量集中同一个模型既要做实时问答又要做异步总结互相挤占资源一个慢路径拖垮整条链路。第三个是多轮对话的上下文管理。每个请求都把所有历史消息原样塞给模型token 成本高响应时间长用户等得烦躁。这些痛点单独看都是小问题但叠在一起就是线上事故。ModelEngine 在这一层的定位是充当统一的模型入口和编排底座。上游服务不用关心底层是哪个模型、走什么链路只需要按统一协议提交会话上下文和任务由引擎完成模型路由、缓存、上下文管理、工具调用和结果规整。做过中间件的人应该明白这个抽象带来的最大好处是可替换性和可观测性。我们在 ModelEngine 上挂了多套模型配置分别对应知识问答、意图判断和情感分析业务侧完全无感知调优只是改引擎配置不用改代码。另一个隐藏价值是审计能力。客服系统遇到用户投诉时必须能追溯每一轮的输入输出、模型决策、工具调用记录。ModelEngine 统一收口后这些日志天然就是完整的省掉了在业务侧到处埋点的工夫。1.2 四层架构和主管-专员协作模型整个智能客服系统从外到内分成四层接入层负责网页、App、微信公众号等渠道的消息接入统一转成内部消息协议。会话管理层维护会话状态、槽位信息、历史消息摘要。智能体层由多个职责单一的 Agent 组成包括知识问答、订单服务、售后处理、人工对接。引擎层基于 ModelEngine 统一调度模型、知识库检索和工具调用。这样的分层思路本质上是把对话策略和模型调用解耦。客服逻辑关心的是这个用户要不要转人工、应该走哪个流程引擎层关心的是模型返回什么、工具从哪里取数。两者通过标准指令格式衔接调试时可以单独测任何一层出问题也能快速定位是策略写错还是模型答歪。这里要强调一个关键设计决策为什么不尝试用一个大模型提示词解决所有问题而要多智能体因为客服场景的诉求差异实在太大有的是查文档有的是查订单有的只是情绪宣泄。把所有这些塞进一个提示词里指令会越来越长、相互干扰效果很难收敛。多智能体本质上是对问题空间做切分每个 Agent 只关注自己擅长的一小块提示词更短、行为更可控、测试也更方便。代价是引入了路由和协作的复杂度但这部分复杂度可以通过架构约束来控制。我们采用的协作模式是主管-专员单向调度。主管 Agent 负责意图判断专员 Agent 负责执行Agent 之间不直接通信只通过共享的会话上下文交互。这个选择在后面多次验证是正确的它把失控概率降到了最低。2. 知识库构建RAG 链路的第一步也是最容易翻车的一步2.1 数据清洗与切分别在表格中间切一刀知识库质量决定了答案上限这句话怎么强调都不过分。项目初期我们把产品文档、历史工单、FAQ 全都导进去结果效果很差查文档的问题返回了一堆历史工单用户看着牛头不对马嘴。后来做了一套清洗流程才逐步稳定下来。清洗这一步具体做什么首先是按业务域拆分产品文档、售后政策、订单规则各自作为独立知识源检索时可以按业务线过滤。然后是格式统一文档里的表格转成 Markdown 表格全角半角、乱码、特殊符号逐一处理。这一步虽然无聊但直接影响后续切分和向量化的质量。表格是文档切分里最容易翻车的地方直接用 Python 的 split 按字符数切文档很容易从表格中间断开检索时拿到半截表格模型只能瞎猜。切分策略我们调了很多轮。目标是保证每个块是一个相对完整的语义单元而不是追求最小块。对客服场景块太大检索慢、答案容易啰嗦块太小又答不全。所以默认配置是 350 字左右作为软上限优先按标题层级和段落自然边界切两个相邻块之间保留 30 字重叠。重叠的作用是防止语义在边界处被截断比如一个问句正好跨在两个块的交界处有重叠就能保证关键词至少在一个块里完整出现。这里给一个切分逻辑的示例def split_by_heading_and_paragraph(text, max_len350, overlap30): # 先按标题层级拆出章节 sections split_by_markdown_headings(text) chunks [] for section in sections: # 每个章节内按段落边界聚合 paragraphs split_by_blank_line(section) buf for para in paragraphs: if len(buf) len(para) max_len and buf: chunks.append(buf) buf buf[-overlap:] para else: buf \n para if buf: chunks.append(buf) return chunks这个代码看着简单但解决了我们 90% 的语义割裂问题。切完之后还要做一个语义去重尤其是 FAQ 和历史工单经常表述不同但指向同一个答案。我们后来统一整理了一批同一意思不同表述的对齐数据比如买了东西没到货和物流一直不更新都映射到物流延迟咨询这个标准问题。这一步对检索效果的提升非常直接。2.2 混合检索与重排向量不是万能的知识库切完了检索也不是直接用向量就完事。客服问题里有很多专有名词、型号、功能短句纯向量召回容易漏掉精确匹配因为向量模型对罕见词的区分度不够。我们的方案是关键词检索与向量检索并行再用重排模型统一打分。BM25 召回一批候选向量检索召回一批候选两边合并去重后交给精排模型打分最后取 Top-K 作为答案依据。项目里实际用的 Top-K 是 4 到 6 条相似度阈值设在 0.7 左右。低于阈值的直接返回知识库暂未收录不硬答。这个阈值是拍脑袋定的吗不是我们拿了一批历史真实问题和对应准确答案做验证集把阈值从 0.5 到 0.9 扫了一遍观察准确率和召回率的变化。0.7 附近准确率开始显著上升而召回率下降不明显于是确定为默认值。不同知识库的最佳阈值可能有差异建议都做一次这种扫参。embedding 模型的选择也值得一提。通用 embedding 模型对常识语义理解得不错对内部型号和别名就经常抓瞎。我们做了一个低成本方案在知识库里预置别名映射表用户问买了东西没到货先改写成标准问法物流延迟咨询再走向量检索。效果提升明显而且改动量比微调 embedding 小得多。如果你的团队有标注资源后续再做领域适配微调也不迟。重排模型的选择同样关键。我们试过用生成模型自己做重排效果可以但耗时翻倍用户等不起。后来改用精排模型单条打分在毫秒级配合召回阶段 Top 20 的候选整体效果和成本都满意。这里还有一个细节知识块里如果有表格检索时最好把表格上下文和表格内容作为一个整体参与召回否则模型拿到半截表格经常答非所问。2.3 知识更新与失效让知识库长期可用知识库上线后面临两个现实问题文档更新后旧知识还在会造成新旧版本共存业务下线后过期知识还在被检索到。如果不解决系统上线第一周效果不错一个月后越答越差大概率就是知识没更新导致的。我们给每个知识块挂了元信息包括来源文档、业务线、生效起始时间、失效时间。检索时元信息作为过滤条件参与召回失效时间为空的才进入候选集。听起来简单实际排查的时候发现坑很多比如新文档向量入库时把旧文档也一起删了而检索逻辑里有一段缓存还保留着旧向量索引新知识就始终没生效。后来统一改成先写新索引、再切换线上版本切换前做一致性校验这类问题才彻底解决。对新上线的文档我们还走了一条审核流先草稿入库由人工抽查部分问答对确认无问题后批量置为生效。上线后自动统计每条知识被命中的次数和用户反馈命中率低且被用户多次点踩的知识块会进入二次审核列表。这套机制花的时间不多但保证了知识库是活的而不是一堆死文档堆在那里。很多团队把精力全放在模型调优上忽略知识更新最后效果下滑了都找不到原因就是这个环节缺失。3. 多智能体协作从路由到执行的完整链路3.1 智能体角色划分与协作协议多智能体协作的第一步不是写代码而是先划清楚每个 Agent 的职责边界。我们的系统里定义了这样几个角色路由 Agent负责意图判断决定请求分给谁。知识问答 Agent从知识库检索作答只处理文档类问题。订单服务 Agent对接订单查询、物流查询等内部工具。售后处理 Agent处理退货退款、投诉建议必要时触发转人工。兜底 Agent闲聊或无法识别意图时的通用回复。多个 Agent 之间通过一个共享的会话上下文协作。路由 Agent 判断为订单查询会把会话上下文转给订单服务 Agent后者读取槽位中的订单号、用户 ID调用工具后把结果写回上下文。某个 Agent 发现信息不全比如用户没提供订单号它可以发起追问追问结果更新到上下文。这实际上就是主管-专员模式主管负责调度专员负责执行。多个 Agent 之间不直接通信这是我们的硬性约束。原因是在另一个模拟项目里试过让两个 Agent 互相传消息去完善一个答复结果因为各自提示词约束不够出现来回传递、迟迟不产出最终答案的情况。客服场景里客户可没耐心等两个 Agent 互相拉扯所以坚持单向调度为主。每个 Agent 只跟上下文交互不感知其他 Agent 的存在这样出问题也好排查每一轮谁调用谁一目了然。协作协议上每个 Agent 的输出必须结构化。路由 Agent 输出意图分类和置信度任务类 Agent 输出回复文案、槽位更新、是否需要更多信息等字段。这个协议从一开始就定死后面加新 Agent 只需要按协议写配置不用改动主链路。3.2 基于 ModelEngine 的 Agent 配置与调度ModelEngine 的编排能力是我们选型的主要原因。流程上每个 Agent 被定义成一组配置角色描述、可用工具列表、提示词模板、输出协议。这里给一个订单服务 Agent 的配置示例{ agent: order_service, role: 负责订单查询、物流跟踪, tools: [query_order, query_logistics], prompt_template: 你是客户服务助理只能基于工具返回结果回答禁止编造订单信息。, output_schema: { type: object, properties: { reply: {type: string}, need_more_info: {type: boolean}, slot_updates: {type: object} } } }一次完整请求的处理链路大致是这样的会话管理层把当前消息和精简后的上下文发送给 ModelEngine。路由 Agent 先用低延迟模型做意图判断温度设得比较低保证稳定。根据意图分发知识类直接走检索链路订单售后类进入任务类 Agent 流程。Agent 执行过程中需要调用工具的地方会输出一个工具调用指令ModelEngine 负责实际调用对应 API再把结果回填给 Agent。所有结果最终汇总为一个回复写入会话存储。这里最值得强调的是超时和失败降级。多智能体链路里只要一个环节超时用户就等不到回复。我们给每轮 Agent 调用设了 3 秒超时整体链路 8 秒上限。超时后走兜底策略比如知识问答改为直接返回检索到的原文摘要不再生成润色文案。这样体验虽然略糙但至少用户不会干等。路由模型的选择上我们刻意不用最大号的模型。意图判断是分类任务小模型的准确率已经够用而且延迟低。真遇到小模型拿不准的情况可以设置一个置信度阈值低于阈值默认转人工或走兜底比强行让大模型猜更稳妥。这也是把路由和生成模型拆开的另一个好处。3.3 上下文分层管理与槽位记忆多轮对话里最大的坑是上下文越积越长。刚开始我们也尝试把所有历史消息都塞给模型成本飙升模型对早期信息的关注度下降出现忘事现象。比如用户最开始说了一个订单号聊了五轮之后模型就把订单号忘了开始瞎编。后来采用分层记忆效果立竿见影短期记忆保留最近 6 轮完整消息直接进入模型上下文。长期记忆超过 6 轮的多余内容在每次会话结束后生成一段摘要存成一条记忆记录。下次请求带着摘要一起送进去。槽位记忆订单号、用户类型、诉求类型等关键信息单独存储不依赖摘要每次请求先拼装槽位信息。这是一种非常实用的折中既保证上下文有足够的即时信息又避免长期对话导致输入 token 爆炸。客服场景里转人工的会话交接也依赖这套记忆。用户之前和机器人聊了什么、填了什么信息转人工时把结构化槽位摘要给人工客服人工接手效率明显高很多。这里我们踩过一个坑用户先后说了两个订单号槽位信息里没有区分哪个是当前有效订单导致订单查询 Agent 偶尔答错订单。后来把槽位改成带时间戳的列表Agent 追问您指的是哪个订单时把候选列表呈现给用户选择问题彻底解决。上下文管理还有一个细节不是每条消息都要进入长期记忆。我们把用户消息按类型分级闲聊类只保留摘要订单相关消息必须保留全文和槽位。这样记忆存储不会爆炸关键信息也不会被摘要压缩丢失。4. 参数调优与效果评估把系统调稳比调聪明更重要4.1 生成参数、检索参数怎么定客服场景的回复要求严谨所以生成参数普遍偏保守。温度我们设在 0.3 以下top_p 设为 0.9避免发散。路由这类分类任务温度甚至直接设为 0。有人可能觉得温度越高越智能但在客服领域稳定性永远比灵活性重要。宁可答得稳妥不要答得花哨。用户问的是退款政策你答得再有文采关键信息错了就是事故。检索参数里面除了前面说的 Top-K 和阈值重排模型的选择也很关键。我们试过用生成模型自己重排效果可以但耗时翻倍。后来用精排模型单条打分在毫秒级配合召回阶段 Top 20 的候选整体效果和成本都满意。还有一个细节知识块里如果有表格检索时最好把表格上下文和表格内容作为一个整体参与召回否则模型拿到半截表格经常答非所问。超时参数我们这么定路由 Agent 的模型调用必须 1 秒内返回知识检索控制在 500 毫秒内生成模型的调用控制在 3 秒内整体链路不超过 8 秒。这些数字不是拍脑袋是统计了线上真实延迟分布后给出的 p95 值。如果链路超时比例超过 1%就说明某个环节需要扩容或换更快的模型而不是靠调参掩盖。4.2 提示词迭代的四步法提示词不能拍脑袋写我们按这个顺序迭代。第一步先用一条极简提示词跑通流程观察主要失败模式。第二步针对失败模式补规则。比如如果知识库没有明确答案必须回复知识库暂未收录禁止编造这类约束每次都加在提示词末尾不是插在中间模型对末尾约束的遵循度明显更高。第三步加入 2~3 个少样本示例示例一定来自真实用户问题不要自己编。编出来的示例往往过于理想化模型学不到真实问题的表达方式。第四步把指令拆成角色 任务 约束 示例 输出格式五段方便单独调试。一个容易被忽略的细节是多智能体里的输出协议。每个 Agent 的输出必须严格遵循 JSON Schema不能给大模型自由发挥。我们直接让 ModelEngine 校验输出格式格式不对就重试一次。重试仍然失败就走兜底回复。这个规则让下游解析代码省了很多 if 判断稳定性提高也很明显。曾有一个版本提示词没写清楚输出格式要求结果路由 Agent 偶尔返回带 markdown 的文本解析失败率飙到 15%排查好久才定位到。提示词的版本管理也是经验。prompt 改来改去总得知道哪个版本效果最好。我们给每个版本的提示词记录了生效时间和线上效果指标回滚就是一键的事。没有版本管理的 prompt 迭代本质上是在碰运气。4.3 评估体系与指标口径系统上线阶段我们做了一套轻量评估每周抽 200 条真实对话人工标注三个指标——回答是否准确、是否完整、是否需要转人工。这里人工标注很费人力但客服系统的评价不能只看模型自评必须结合真实场景。为了减少标注成本我们优先抽那些模型自身置信度低于阈值、或者被用户点踩的对话。这样标注样本覆盖的几乎都是疑难问题能更快暴露系统短板。另一套口径是线上指标解决率、转人工率、平均回复时长。转人工率从 40% 降到 18% 是这次项目最直观的收益。但要注意一个误区转人工率不是越低越好。如果系统硬扛所有问题用户反复得不到有效答案体验反而更差。我们给转人工设置了一个兜底机制当用户明确表达不满或要求人工立即转接绝不拦截。判断依据是简单的情感分析加上关键词比如人工、投诉、客服这类词一旦出现直接转人工。评估里还有一个容易忽视的信号用户回复率。用户如果连续三条都只回嗯好的大概率是没耐心了。我们把这个信号也纳入监控作为转人工的一个触发条件。把评估体系建好调优才有方向。不然今天这个参数明天那个 prompt改了没有任何反馈项目就成了玄学工程。5. 常见问题与排查经验5.1 高频问题速查表把项目里周期出现的高频问题整理成一张速查表方便团队其他同事定位现象可能原因处理建议知识问答答非所问切分块语义不完整检查切分粒度按段落和标题切检索量大但答案偏重排环节未生效确认召回合并后是否做了重排打分模型不按格式输出提示词约束弱增加 JSON Schema 校验并重试Agent 来回传递协作逻辑复杂改为单向调度只通过上下文通信多轮对话后期答错上下文过长覆盖槽位启用摘要压缩与槽位独立存储新文档上线没生效元信息缓存未更新检查生效时间过滤和索引切换回复超时链路模型推理过慢降低路由模型延迟启用降级策略这张表不是一次性整理的是每次排查完问题后往里面补充一条。三个月下来团队新同事接手问题的时候基本都能对着表快速定位不用老员工反复救火。5.2 三个印象深刻的排查案例第一个是知识库更新后线上不生效。排查了大半天发现新文档向量入库时顺手把旧文档也一起删了而检索逻辑里有一段缓存还保留着旧向量索引。后来统一改成先写新索引、再切换线上版本切换前做一致性校验问题不再出现。这个案例说明知识库的运维流程跟数据库迁移一样要有明确的发布和回滚机制。第二个是订单查询 Agent 偶尔答错用户订单前面说过的槽位列表问题。这里再补充一句多轮对话里的槽位不是简单覆盖就行要保留候选和置信度。用户可能先问 A 订单位置再问 B 订单价格模型必须能区分当前话题是哪个订单。把槽位改成带时间戳的列表后这类歧义就大大减少。第三个是某个时段系统整体回复质量波动。监控日志发现路由 Agent 触发了高延迟模型的保温机制部分请求走了慢路径。我们把路由模型和生成模型彻底拆成不同实例并对慢路径增加独立告警波动恢复正常。这三个案例的共同特征是问题都不在模型本身而在工程链路。这也是我坚持先搭好可观测性再调模型的原因。从第一天开始就给每个请求打上了链路 ID事件和耗时都落日志排查问题的时间直接缩短一个量级。5.3 一个调优纪律一次只改一个变量最后分享一个我们团队内部的死规矩每次调整提示词或检索参数不要一次改多个变量。看到很多人同时调温度、换模型、改切分结果效果变差都不知道是哪一步引起的。我们定了个规矩一次只改一个变量每个改动先跑回归集再做线上灰度。回归集是几百条带标注的历史问题每次改动后先跑一遍和上一个版本的指标对比没有明显退步才放行。这套笨办法看着慢但实际上是最快的调优路径。因为调优的核心不是改得多而是能归因。坚持这个纪律之后我们发现很多所谓的玄学现象都有了明确解释。比如某次回答变差查下来是因为知识库同日更新了一批文档而模型和提示词都没动问题出在数据不在模型。没有版本记录和链路追踪这种问题真的会排查到怀疑人生。按我的个人体会智能客服系统最值得投入精力的顺序是数据与知识库治理大于多智能体编排大于模型调优。模型是最容易迭代的部分而知识和流程是真正体现业务壁垒的部分。如果你也在做类似项目建议先把知识库的清洗切分和更新机制做好再考虑上多智能体协作。这个顺序能帮你少走不少弯路。拿我们这次来说花在数据治理上的时间占了将近四成但正是这四成的投入让后续的模型替换和智能体扩展都变得非常轻松。