1. 从标题拆解客服 Agent 的真实战场“客服 Agent 渡劫 48 关”这个标题第一次看到的时候我笑了很久因为它太真实了。做过客服 Agent 的人都知道这东西不是“接个大模型 API 就完事”的活儿它更像是一场持续不断的打怪升级——每过一关前面还有一关等着你。而标题里点出的 Tool、RAG、MCP、Eval 这四个词恰好就是这条渡劫路上最核心的四道坎。先把这四个词用大白话翻译一遍方便不同基础的读者对齐认知。Agent在这里指的是能自主调用工具、检索知识、做出决策并完成客服任务的智能体不是那种只会一问一答的聊天机器人。Tool是 Agent 能调用的外部能力比如查订单、改地址、发起退款、查物流。RAG是检索增强生成简单说就是让 Agent 在回答前先去知识库里捞相关资料而不是凭记忆瞎编。MCP是一种让 Agent 和外部工具、数据源之间标准化对接的协议思路解决的是“每接一个系统就要写一套胶水代码”的问题。Eval是评估是判断这个 Agent 到底行不行、有没有退步、能不能上线的唯一客观手段。为什么我说这是“渡劫”因为客服场景是所有 Agent 落地场景里最苛刻的一类。它要求响应快、答案准、语气稳、边界清、可追溯、可回滚还要扛得住并发。用户不会因为你背后用了多先进的架构就原谅你答错一个退款金额。所以这篇文章我想把这 48 关里最关键的几类问题拆开讲把 Tool 怎么设计、RAG 怎么不翻车、MCP 怎么落地、Eval 怎么做成体系一次性讲透。适合正在做客服 Agent 的工程师、产品经理也适合刚接触 Agent 开发想找一个真实场景练手的朋友。2. 整体架构设计与方案选型思路2.1 为什么客服 Agent 不能只靠一个大模型很多人一开始的想法很朴素把公司知识库塞进提示词接个大模型做个对话界面收工。我试过这条路走不通而且死得很难看。原因有三个每一个都是硬伤。第一上下文窗口是有限的而客服知识是无限的。产品手册、退换货政策、活动规则、FAQ、历史工单这些东西加起来动辄几十万字你不可能全塞进去。就算塞进去了模型在长上下文里的注意力也会稀释关键信息反而被淹没。第二模型会编。你问它“我这个订单能不能退”它如果没有实时订单数据就会根据政策“推理”出一个答案而这个答案很可能是错的。客服场景里一个错误的承诺就是一次投诉。第三业务动作必须真实执行。用户说“帮我改收货地址”这不是生成一段文字就完事你得真的去调订单系统的接口。模型本身没有手你得给它装手这就是 Tool 的意义。所以一个能打的客服 Agent架构上必须是“模型 工具 知识 评估”四位一体。模型负责理解和表达工具负责执行和取数知识负责提供依据评估负责兜底和迭代。缺任何一个这个 Agent 都上不了生产。2.2 Tool、RAG、MCP、Eval 四者的分工与协作我把这四个东西的关系用一个生活化的类比讲清楚。把客服 Agent 想象成一个刚入职的客服新人。RAG是他手边的那本《业务知识手册》遇到不确定的问题先翻书。Tool是他桌上的电话和电脑能打电话给仓库查库存、能在系统里改地址。MCP是公司统一的工单系统和权限规范规定了新人能用哪些系统、怎么用、用什么格式提交。Eval是质检员每天抽听他的通话录音打分告诉他哪里说错了。这四者不是并列关系而是有依赖的。没有 RAGAgent 会瞎答没有 ToolAgent 只会说不会做没有 MCP每接一个新系统都要重写一遍对接逻辑维护成本爆炸没有 Eval你根本不知道改了一个提示词之后Agent 是变好了还是变坏了。我见过太多团队前三个都做了唯独 Eval 是拍脑袋结果上线后问题频出回滚都不知道回滚到哪个版本。2.3 方案选型的几个关键取舍在动手之前有几个选型决策会直接影响后面的工作量我把自己踩过的坑列出来。自建 Agent 框架还是用现成的。现成框架上手快但客服场景往往有很特殊的工具调用逻辑和权限控制框架的抽象层有时候反而碍事。我的建议是如果团队有工程能力核心调度逻辑自己写只在 RAG 检索和 Eval 这两个相对标准的环节用成熟库。RAG 用向量检索还是混合检索。纯向量检索在语义相似度上表现好但对专有名词、订单号、产品型号这类精确匹配很弱。客服场景里用户经常直接甩一个订单号过来这时候纯向量就是灾难。所以混合检索向量 关键词几乎是必选项。MCP 是自研协议还是对齐社区标准。如果只是内部几个系统对接自研一套简单的工具描述规范就够了。但如果要接第三方能力或者团队规模会扩大对齐社区已有的 MCP 思路能省很多沟通成本。这一点后面会展开讲。3. Tool 设计给 Agent 装一双靠谱的手3.1 工具粒度怎么切才合理工具设计是客服 Agent 最容易做砸的地方没有之一。我见过两种极端。一种是工具切得太细比如“查询订单状态”“查询订单金额”“查询订单物流”分成三个工具Agent 为了回答一个简单问题要连续调三次延迟高、出错概率大。另一种是工具切得太粗一个“处理订单问题”的工具包揽所有事参数复杂到模型根本填不对。我的经验是按用户意图切而不是按后端接口切。后端可能有二十个接口但用户能表达的意图可能只有五六个。比如“查订单”这个意图后端可能要调订单主表、物流表、支付表但对 Agent 来说它只需要一个query_order工具传入订单号返回一个聚合后的结果。这样模型调用简单后端聚合逻辑藏在工具内部各司其职。具体到客服场景我通常会先切出这几类工具查询类订单、物流、账户、积分、操作类改地址、取消订单、申请退款、修改手机号、转接类转人工、转专属客服、知识类这个可以交给 RAG不一定做成工具。每一类下面再根据业务复杂度决定要不要细分。3.2 工具描述与参数设计的坑工具描述是给模型看的不是给人看的。这一点极其重要。很多工程师写工具描述像写 API 文档一堆技术术语模型看了根本不知道什么时候该用。好的工具描述应该回答三个问题这个工具是干什么的、什么时候用、参数怎么填。举个例子一个查物流的工具描述不要写“调用物流查询接口返回物流轨迹”而要写“当用户询问包裹到哪里了、什么时候能到、物流为什么没更新时使用。需要提供订单号订单号是用户下单后收到的以字母开头的字符串”。后面这句关于订单号格式的说明能大幅降低模型传错参数的概率。参数设计上能不给模型选的就不给。比如退款原因如果后端支持十种枚举值不要让模型自由填而是在工具描述里把这十个值列出来让模型从中选。模型在封闭集合里做选择准确率远高于开放式生成。另外必填参数越少越好。如果订单号能从上下文里拿到就不要让模型再问用户一遍。3.3 工具调用的错误处理与兜底工具会失败这是常态。网络超时、接口限流、参数非法、业务规则拒绝每一种都要有明确的处理策略。我的做法是把工具返回结果分成三类成功、可重试失败、不可重试失败。成功就正常返回数据。可重试失败比如超时让 Agent 自动重试一次还失败就告诉用户“系统繁忙请稍后再试”。不可重试失败比如“该订单已超过退款期限”要把具体的业务原因返回给 Agent让它能用人话解释给用户。这里有个细节错误信息不要直接抛给用户因为后端错误信息往往是给工程师看的用户看不懂。要让 Agent 基于错误码生成一句友好的解释。提示工具返回结构里一定要带一个明确的status字段和error_code不要让 Agent 去解析自然语言判断成功失败那样极不稳定。4. RAG 实战让 Agent 答得有依据4.1 知识库怎么建才不翻车RAG 的第一步是知识库建设这一步做不好后面检索再牛也白搭。客服知识库的来源通常很杂产品文档、政策文件、历史工单、聊天记录、表格。我的处理原则是先分类再清洗后切分。分类是指按知识类型分开存。政策类、产品类、操作类、话术类它们的检索需求不一样。政策类要求精确产品类要求全面话术类要求语气匹配。混在一起检索很容易捞出不相关的内容。清洗是最费时间但最不能省的环节。历史工单里全是噪音用户的口语、客服的简写、重复的内容直接入库会污染检索结果。我一般会做几件事去掉明显的无效对话、统一术语比如“退款”和“退钱”统一成“退款”、把表格转成结构化文本、给每段内容打上来源和更新时间标签。切分是技术活。切太大检索出来的内容包含太多无关信息模型容易被干扰切太小语义不完整检索不到。我的经验值是按语义段落切每段 200 到 500 字同时保留一定的重叠。对于政策类文档按条款切对于 FAQ一问一答作为一个单元对于长文档按小标题切。切完之后每段前面加上所属文档的标题作为上下文能显著提升检索准确率。4.2 检索策略向量、关键词还是混合前面提过客服场景必须用混合检索。具体怎么混我分享一下自己的配置。向量检索用 embedding 模型把 query 和文档都转成向量算余弦相似度负责语义匹配。关键词检索用 BM25 或类似算法负责精确匹配。两路结果各自排序后用一个加权公式融合比如向量权重 0.6、关键词权重 0.4具体权重根据业务调。这里有个容易被忽略的点查询改写。用户的问题往往很口语“我那个东西咋还没到”直接拿去检索效果很差。我会在检索前加一步让模型把用户问题改写成几个更适合检索的查询比如“订单物流未更新”“包裹延迟送达”然后多路检索再合并。这一步能明显提升召回率。还有一个进阶玩法是元数据过滤。给每段知识打上标签比如适用产品线、生效时间、地区。检索时先按元数据过滤再在子集里做相似度匹配。比如用户问的是 A 产品的政策就只在 A 产品的知识里检索避免捞到 B 产品的政策造成误导。4.3 RAG 的常见瓶颈与破解RAG 做久了会发现几个反复出现的瓶颈。第一个是检索到了但没用上。模型明明拿到了正确资料却还是按自己的理解回答。这通常是提示词的问题要明确告诉模型“必须基于提供的资料回答资料里没有就说不知道”。第二个是检索不到。用户问法和知识库表述差异太大这时候查询改写和多路召回就派上用场。第三个是检索到过时的内容。知识库更新不及时或者新旧版本共存。解决办法是给知识打时间戳检索时优先返回最新版本同时在提示词里告诉模型当前日期。注意RAG 不是万能的有些问题它天然解决不了。比如需要实时计算的问题“我这个月消费了多少”必须走 Tool 查数据库不能靠 RAG。分清楚哪些问题该检索、哪些该查库是架构设计的基本功。5. MCP 落地把工具对接标准化5.1 MCP 到底解决什么问题在没有 MCP 之前每接一个新系统工程师就要写一套对接代码定义工具、写参数校验、处理返回、映射错误码。十个系统就是十套逻辑维护起来是噩梦。MCP 的核心价值就是把“Agent 怎么发现和调用工具”这件事标准化。工具提供方按照统一规范暴露自己的能力Agent 侧按照统一规范去发现和调用中间的胶水代码大幅减少。用生活化的类比MCP 就像 USB 接口。以前每个设备有自己的接口鼠标一个、键盘一个、打印机一个现在统一成 USB插上就能用。MCP 之于 Agent 工具就是 USB 之于外设。5.2 工具服务端的实现要点实现一个 MCP 工具服务端核心是定义清楚三件事工具清单、每个工具的参数 schema、调用入口。工具清单要包含名称和描述描述要写得让模型能判断什么时候用。参数 schema 用 JSON Schema 描述明确类型、是否必填、枚举值。调用入口接收参数执行逻辑返回结构化结果。我踩过的一个坑是权限和鉴权。工具服务端不能裸奔必须校验调用方身份并且根据调用方身份限制可用的工具和可操作的数据范围。比如普通客服 Agent 只能查自己负责的订单不能查全部。这个权限逻辑要放在服务端不能指望 Agent 侧自觉。另一个坑是超时和限流。工具服务端要设置合理的超时时间避免一个慢接口拖垮整个 Agent 响应。同时要有限流防止 Agent 在异常情况下疯狂重试打爆后端。5.3 客户端接入与工具发现Agent 侧作为 MCP 客户端要做的是发现工具、选择工具、调用工具、处理结果。工具发现可以是启动时拉取一次清单缓存起来也可以每次动态获取。我倾向于启动时拉取加定期刷新兼顾性能和实时性。工具选择这一步如果工具数量少比如二十个以内可以把所有工具描述都放进提示词让模型选。如果工具多就要做分层先让模型判断意图类别再在类别内选具体工具。这样能降低模型的决策负担提升准确率。调用结果的处理要统一。不管底层工具返回什么格式客户端都应该归一化成统一结构再交给模型这样模型看到的输入格式一致行为更稳定。6. Eval 体系怎么知道 Agent 到底行不行6.1 评估集怎么建才有代表性Eval 是客服 Agent 的质检员但很多团队的评估集是拍脑袋凑的几十条问题覆盖不了真实场景。我的做法是从真实日志里采样。上线前用历史工单上线后用真实对话日志按意图分布分层抽样保证每个高频意图都有足够样本低频但重要的意图比如涉及资金、投诉也要覆盖。评估集要包含几类样本正常问题、边界问题比如订单号格式错误、对抗问题用户故意刁难、多轮问题需要上下文才能回答、工具失败场景。每类样本都要有明确的期望结果这个期望结果可以是标准答案也可以是评判标准比如“必须包含退款时限”。评估集不是建一次就完事要持续维护。每次发现新的 bad case就补进评估集这样评估集越来越贴近真实回归测试也越来越有价值。6.2 自动评估与人工评估的配合全自动评估快但不够准全人工评估准但太慢。我的做法是自动评估做初筛人工评估做精判。自动评估可以用规则匹配比如答案里是否包含关键信息、可以用模型打分让另一个模型判断回答是否准确、是否友好、也可以用工具校验比如 Agent 说改了地址就去查系统确认是否真的改了。自动评估里模型打分是性价比最高的方式但要注意几点打分模型要和被评模型不同避免自己评自己打分标准要写清楚最好给出评分细则和示例打分结果要定期和人工评估对齐校准打分模型的偏差。人工评估主要看自动评估覆盖不到的东西语气是否得体、有没有过度承诺、多轮对话是否连贯、异常处理是否合理。人工评估不用全量抽检即可但抽检要随机不能只挑好的看。6.3 评估指标与上线门槛客服 Agent 的评估指标我一般分四层。准确性答案是否正确工具调用是否正确。完整性是否回答了用户的所有问题。安全性有没有泄露敏感信息、有没有越权操作、有没有不当承诺。体验响应速度、语气、多轮连贯性。每一层都要有量化指标。准确性可以用准确率完整性可以用覆盖率安全性可以用违规率体验可以用人工评分。上线门槛要提前定好比如准确率不低于 90%、违规率为零、平均响应时间低于 3 秒。达不到就不上别抱侥幸心理。提示评估要跑在和生产一致的环境上包括同样的模型版本、同样的知识库版本、同样的工具版本。环境不一致评估结果没有参考价值。7. 常见问题与排查技巧实录7.1 高频问题速查表问题现象可能原因排查方向解决思路Agent 答非所问检索结果不相关检查 query 改写和检索权重调整混合检索权重优化查询改写工具调用参数错误工具描述不清检查工具描述和参数 schema补充参数格式说明缩小枚举范围响应特别慢工具串行调用过多看调用链路耗时并行化独立工具调用加缓存多轮对话丢失上下文上下文管理有问题检查历史消息截断策略保留关键信息摘要压缩历史模型编造政策提示词约束不足检查系统提示词强化“基于资料回答”约束工具失败后 Agent 卡住错误处理缺失检查工具返回结构统一错误码明确重试策略并发上来后大量超时资源瓶颈看工具服务和模型服务负载加限流、加缓存、扩容7.2 几个我踩过的深坑第一个坑是过度依赖模型判断工具调用。早期我让模型自己决定调不调工具结果它经常该调不调、不该调乱调。后来改成在提示词里明确规则比如“涉及订单状态必须调用 query_order”准确率立刻上来了。模型不是不能用是要给它清晰的规则。第二个坑是知识库更新后没重新评估。有一次更新了退款政策知识库改了但没跑评估上线后发现 Agent 还在按旧政策回答。后来我把知识库更新和评估跑批绑定每次更新自动触发回归测试。第三个坑是忽略并发下的状态污染。多用户同时对话时如果上下文管理没做好A 用户的信息可能串到 B 用户的会话里。这个问题的根源通常是用了全局变量或者缓存 key 设计不当。解决办法是每个会话有独立的 session id所有状态都挂在 session 下。7.3 性能优化的几个实用技巧客服 Agent 对响应速度要求高优化空间主要在三个地方。检索层加缓存相同或相似 query 直接返回缓存结果用更快的向量索引减少检索的文档数量。工具层能并行调用的工具并行调不要串行给工具加超时和降级慢接口不要拖垮整体。模型层简单问题用小模型复杂问题用大模型流式输出让用户先看到部分内容感知上更快。还有一个容易被忽略的点是提示词长度。提示词越长模型首 token 延迟越高。定期精简提示词把不必要的内容移到 RAG 里能明显改善响应速度。8. 一些实操后的个人体会做客服 Agent 这一年多我最大的体会是这东西的难点不在模型而在工程。模型能力已经足够强了真正决定成败的是工具设计得合不合理、知识库建得干不干净、评估做得严不严谨、异常处理得到不到位。我见过太多团队把精力全花在调提示词上结果工具一调用就出错知识一检索就翻车评估全靠感觉最后上线即翻车。另一个体会是别追求一步到位。48 关不是一次能过完的先让 Agent 能回答高频问题再逐步加工具、加知识、加评估。每加一个能力就跑一次回归确保没把之前的能力搞坏。小步快跑比憋大招靠谱得多。最后分享一个我一直在用的小技巧把每次线上 bad case 都当成一次免费的评估样本。用户反馈的问题比你自己造的测试用例真实得多。建一个 bad case 库定期复盘你会发现 Agent 的进步速度比闭门造车快好几倍。这个库积累到一定程度就是你最宝贵的资产。
客服Agent渡劫48关：Tool、RAG、MCP、Eval实战全解析
1. 从标题拆解客服 Agent 的真实战场“客服 Agent 渡劫 48 关”这个标题第一次看到的时候我笑了很久因为它太真实了。做过客服 Agent 的人都知道这东西不是“接个大模型 API 就完事”的活儿它更像是一场持续不断的打怪升级——每过一关前面还有一关等着你。而标题里点出的 Tool、RAG、MCP、Eval 这四个词恰好就是这条渡劫路上最核心的四道坎。先把这四个词用大白话翻译一遍方便不同基础的读者对齐认知。Agent在这里指的是能自主调用工具、检索知识、做出决策并完成客服任务的智能体不是那种只会一问一答的聊天机器人。Tool是 Agent 能调用的外部能力比如查订单、改地址、发起退款、查物流。RAG是检索增强生成简单说就是让 Agent 在回答前先去知识库里捞相关资料而不是凭记忆瞎编。MCP是一种让 Agent 和外部工具、数据源之间标准化对接的协议思路解决的是“每接一个系统就要写一套胶水代码”的问题。Eval是评估是判断这个 Agent 到底行不行、有没有退步、能不能上线的唯一客观手段。为什么我说这是“渡劫”因为客服场景是所有 Agent 落地场景里最苛刻的一类。它要求响应快、答案准、语气稳、边界清、可追溯、可回滚还要扛得住并发。用户不会因为你背后用了多先进的架构就原谅你答错一个退款金额。所以这篇文章我想把这 48 关里最关键的几类问题拆开讲把 Tool 怎么设计、RAG 怎么不翻车、MCP 怎么落地、Eval 怎么做成体系一次性讲透。适合正在做客服 Agent 的工程师、产品经理也适合刚接触 Agent 开发想找一个真实场景练手的朋友。2. 整体架构设计与方案选型思路2.1 为什么客服 Agent 不能只靠一个大模型很多人一开始的想法很朴素把公司知识库塞进提示词接个大模型做个对话界面收工。我试过这条路走不通而且死得很难看。原因有三个每一个都是硬伤。第一上下文窗口是有限的而客服知识是无限的。产品手册、退换货政策、活动规则、FAQ、历史工单这些东西加起来动辄几十万字你不可能全塞进去。就算塞进去了模型在长上下文里的注意力也会稀释关键信息反而被淹没。第二模型会编。你问它“我这个订单能不能退”它如果没有实时订单数据就会根据政策“推理”出一个答案而这个答案很可能是错的。客服场景里一个错误的承诺就是一次投诉。第三业务动作必须真实执行。用户说“帮我改收货地址”这不是生成一段文字就完事你得真的去调订单系统的接口。模型本身没有手你得给它装手这就是 Tool 的意义。所以一个能打的客服 Agent架构上必须是“模型 工具 知识 评估”四位一体。模型负责理解和表达工具负责执行和取数知识负责提供依据评估负责兜底和迭代。缺任何一个这个 Agent 都上不了生产。2.2 Tool、RAG、MCP、Eval 四者的分工与协作我把这四个东西的关系用一个生活化的类比讲清楚。把客服 Agent 想象成一个刚入职的客服新人。RAG是他手边的那本《业务知识手册》遇到不确定的问题先翻书。Tool是他桌上的电话和电脑能打电话给仓库查库存、能在系统里改地址。MCP是公司统一的工单系统和权限规范规定了新人能用哪些系统、怎么用、用什么格式提交。Eval是质检员每天抽听他的通话录音打分告诉他哪里说错了。这四者不是并列关系而是有依赖的。没有 RAGAgent 会瞎答没有 ToolAgent 只会说不会做没有 MCP每接一个新系统都要重写一遍对接逻辑维护成本爆炸没有 Eval你根本不知道改了一个提示词之后Agent 是变好了还是变坏了。我见过太多团队前三个都做了唯独 Eval 是拍脑袋结果上线后问题频出回滚都不知道回滚到哪个版本。2.3 方案选型的几个关键取舍在动手之前有几个选型决策会直接影响后面的工作量我把自己踩过的坑列出来。自建 Agent 框架还是用现成的。现成框架上手快但客服场景往往有很特殊的工具调用逻辑和权限控制框架的抽象层有时候反而碍事。我的建议是如果团队有工程能力核心调度逻辑自己写只在 RAG 检索和 Eval 这两个相对标准的环节用成熟库。RAG 用向量检索还是混合检索。纯向量检索在语义相似度上表现好但对专有名词、订单号、产品型号这类精确匹配很弱。客服场景里用户经常直接甩一个订单号过来这时候纯向量就是灾难。所以混合检索向量 关键词几乎是必选项。MCP 是自研协议还是对齐社区标准。如果只是内部几个系统对接自研一套简单的工具描述规范就够了。但如果要接第三方能力或者团队规模会扩大对齐社区已有的 MCP 思路能省很多沟通成本。这一点后面会展开讲。3. Tool 设计给 Agent 装一双靠谱的手3.1 工具粒度怎么切才合理工具设计是客服 Agent 最容易做砸的地方没有之一。我见过两种极端。一种是工具切得太细比如“查询订单状态”“查询订单金额”“查询订单物流”分成三个工具Agent 为了回答一个简单问题要连续调三次延迟高、出错概率大。另一种是工具切得太粗一个“处理订单问题”的工具包揽所有事参数复杂到模型根本填不对。我的经验是按用户意图切而不是按后端接口切。后端可能有二十个接口但用户能表达的意图可能只有五六个。比如“查订单”这个意图后端可能要调订单主表、物流表、支付表但对 Agent 来说它只需要一个query_order工具传入订单号返回一个聚合后的结果。这样模型调用简单后端聚合逻辑藏在工具内部各司其职。具体到客服场景我通常会先切出这几类工具查询类订单、物流、账户、积分、操作类改地址、取消订单、申请退款、修改手机号、转接类转人工、转专属客服、知识类这个可以交给 RAG不一定做成工具。每一类下面再根据业务复杂度决定要不要细分。3.2 工具描述与参数设计的坑工具描述是给模型看的不是给人看的。这一点极其重要。很多工程师写工具描述像写 API 文档一堆技术术语模型看了根本不知道什么时候该用。好的工具描述应该回答三个问题这个工具是干什么的、什么时候用、参数怎么填。举个例子一个查物流的工具描述不要写“调用物流查询接口返回物流轨迹”而要写“当用户询问包裹到哪里了、什么时候能到、物流为什么没更新时使用。需要提供订单号订单号是用户下单后收到的以字母开头的字符串”。后面这句关于订单号格式的说明能大幅降低模型传错参数的概率。参数设计上能不给模型选的就不给。比如退款原因如果后端支持十种枚举值不要让模型自由填而是在工具描述里把这十个值列出来让模型从中选。模型在封闭集合里做选择准确率远高于开放式生成。另外必填参数越少越好。如果订单号能从上下文里拿到就不要让模型再问用户一遍。3.3 工具调用的错误处理与兜底工具会失败这是常态。网络超时、接口限流、参数非法、业务规则拒绝每一种都要有明确的处理策略。我的做法是把工具返回结果分成三类成功、可重试失败、不可重试失败。成功就正常返回数据。可重试失败比如超时让 Agent 自动重试一次还失败就告诉用户“系统繁忙请稍后再试”。不可重试失败比如“该订单已超过退款期限”要把具体的业务原因返回给 Agent让它能用人话解释给用户。这里有个细节错误信息不要直接抛给用户因为后端错误信息往往是给工程师看的用户看不懂。要让 Agent 基于错误码生成一句友好的解释。提示工具返回结构里一定要带一个明确的status字段和error_code不要让 Agent 去解析自然语言判断成功失败那样极不稳定。4. RAG 实战让 Agent 答得有依据4.1 知识库怎么建才不翻车RAG 的第一步是知识库建设这一步做不好后面检索再牛也白搭。客服知识库的来源通常很杂产品文档、政策文件、历史工单、聊天记录、表格。我的处理原则是先分类再清洗后切分。分类是指按知识类型分开存。政策类、产品类、操作类、话术类它们的检索需求不一样。政策类要求精确产品类要求全面话术类要求语气匹配。混在一起检索很容易捞出不相关的内容。清洗是最费时间但最不能省的环节。历史工单里全是噪音用户的口语、客服的简写、重复的内容直接入库会污染检索结果。我一般会做几件事去掉明显的无效对话、统一术语比如“退款”和“退钱”统一成“退款”、把表格转成结构化文本、给每段内容打上来源和更新时间标签。切分是技术活。切太大检索出来的内容包含太多无关信息模型容易被干扰切太小语义不完整检索不到。我的经验值是按语义段落切每段 200 到 500 字同时保留一定的重叠。对于政策类文档按条款切对于 FAQ一问一答作为一个单元对于长文档按小标题切。切完之后每段前面加上所属文档的标题作为上下文能显著提升检索准确率。4.2 检索策略向量、关键词还是混合前面提过客服场景必须用混合检索。具体怎么混我分享一下自己的配置。向量检索用 embedding 模型把 query 和文档都转成向量算余弦相似度负责语义匹配。关键词检索用 BM25 或类似算法负责精确匹配。两路结果各自排序后用一个加权公式融合比如向量权重 0.6、关键词权重 0.4具体权重根据业务调。这里有个容易被忽略的点查询改写。用户的问题往往很口语“我那个东西咋还没到”直接拿去检索效果很差。我会在检索前加一步让模型把用户问题改写成几个更适合检索的查询比如“订单物流未更新”“包裹延迟送达”然后多路检索再合并。这一步能明显提升召回率。还有一个进阶玩法是元数据过滤。给每段知识打上标签比如适用产品线、生效时间、地区。检索时先按元数据过滤再在子集里做相似度匹配。比如用户问的是 A 产品的政策就只在 A 产品的知识里检索避免捞到 B 产品的政策造成误导。4.3 RAG 的常见瓶颈与破解RAG 做久了会发现几个反复出现的瓶颈。第一个是检索到了但没用上。模型明明拿到了正确资料却还是按自己的理解回答。这通常是提示词的问题要明确告诉模型“必须基于提供的资料回答资料里没有就说不知道”。第二个是检索不到。用户问法和知识库表述差异太大这时候查询改写和多路召回就派上用场。第三个是检索到过时的内容。知识库更新不及时或者新旧版本共存。解决办法是给知识打时间戳检索时优先返回最新版本同时在提示词里告诉模型当前日期。注意RAG 不是万能的有些问题它天然解决不了。比如需要实时计算的问题“我这个月消费了多少”必须走 Tool 查数据库不能靠 RAG。分清楚哪些问题该检索、哪些该查库是架构设计的基本功。5. MCP 落地把工具对接标准化5.1 MCP 到底解决什么问题在没有 MCP 之前每接一个新系统工程师就要写一套对接代码定义工具、写参数校验、处理返回、映射错误码。十个系统就是十套逻辑维护起来是噩梦。MCP 的核心价值就是把“Agent 怎么发现和调用工具”这件事标准化。工具提供方按照统一规范暴露自己的能力Agent 侧按照统一规范去发现和调用中间的胶水代码大幅减少。用生活化的类比MCP 就像 USB 接口。以前每个设备有自己的接口鼠标一个、键盘一个、打印机一个现在统一成 USB插上就能用。MCP 之于 Agent 工具就是 USB 之于外设。5.2 工具服务端的实现要点实现一个 MCP 工具服务端核心是定义清楚三件事工具清单、每个工具的参数 schema、调用入口。工具清单要包含名称和描述描述要写得让模型能判断什么时候用。参数 schema 用 JSON Schema 描述明确类型、是否必填、枚举值。调用入口接收参数执行逻辑返回结构化结果。我踩过的一个坑是权限和鉴权。工具服务端不能裸奔必须校验调用方身份并且根据调用方身份限制可用的工具和可操作的数据范围。比如普通客服 Agent 只能查自己负责的订单不能查全部。这个权限逻辑要放在服务端不能指望 Agent 侧自觉。另一个坑是超时和限流。工具服务端要设置合理的超时时间避免一个慢接口拖垮整个 Agent 响应。同时要有限流防止 Agent 在异常情况下疯狂重试打爆后端。5.3 客户端接入与工具发现Agent 侧作为 MCP 客户端要做的是发现工具、选择工具、调用工具、处理结果。工具发现可以是启动时拉取一次清单缓存起来也可以每次动态获取。我倾向于启动时拉取加定期刷新兼顾性能和实时性。工具选择这一步如果工具数量少比如二十个以内可以把所有工具描述都放进提示词让模型选。如果工具多就要做分层先让模型判断意图类别再在类别内选具体工具。这样能降低模型的决策负担提升准确率。调用结果的处理要统一。不管底层工具返回什么格式客户端都应该归一化成统一结构再交给模型这样模型看到的输入格式一致行为更稳定。6. Eval 体系怎么知道 Agent 到底行不行6.1 评估集怎么建才有代表性Eval 是客服 Agent 的质检员但很多团队的评估集是拍脑袋凑的几十条问题覆盖不了真实场景。我的做法是从真实日志里采样。上线前用历史工单上线后用真实对话日志按意图分布分层抽样保证每个高频意图都有足够样本低频但重要的意图比如涉及资金、投诉也要覆盖。评估集要包含几类样本正常问题、边界问题比如订单号格式错误、对抗问题用户故意刁难、多轮问题需要上下文才能回答、工具失败场景。每类样本都要有明确的期望结果这个期望结果可以是标准答案也可以是评判标准比如“必须包含退款时限”。评估集不是建一次就完事要持续维护。每次发现新的 bad case就补进评估集这样评估集越来越贴近真实回归测试也越来越有价值。6.2 自动评估与人工评估的配合全自动评估快但不够准全人工评估准但太慢。我的做法是自动评估做初筛人工评估做精判。自动评估可以用规则匹配比如答案里是否包含关键信息、可以用模型打分让另一个模型判断回答是否准确、是否友好、也可以用工具校验比如 Agent 说改了地址就去查系统确认是否真的改了。自动评估里模型打分是性价比最高的方式但要注意几点打分模型要和被评模型不同避免自己评自己打分标准要写清楚最好给出评分细则和示例打分结果要定期和人工评估对齐校准打分模型的偏差。人工评估主要看自动评估覆盖不到的东西语气是否得体、有没有过度承诺、多轮对话是否连贯、异常处理是否合理。人工评估不用全量抽检即可但抽检要随机不能只挑好的看。6.3 评估指标与上线门槛客服 Agent 的评估指标我一般分四层。准确性答案是否正确工具调用是否正确。完整性是否回答了用户的所有问题。安全性有没有泄露敏感信息、有没有越权操作、有没有不当承诺。体验响应速度、语气、多轮连贯性。每一层都要有量化指标。准确性可以用准确率完整性可以用覆盖率安全性可以用违规率体验可以用人工评分。上线门槛要提前定好比如准确率不低于 90%、违规率为零、平均响应时间低于 3 秒。达不到就不上别抱侥幸心理。提示评估要跑在和生产一致的环境上包括同样的模型版本、同样的知识库版本、同样的工具版本。环境不一致评估结果没有参考价值。7. 常见问题与排查技巧实录7.1 高频问题速查表问题现象可能原因排查方向解决思路Agent 答非所问检索结果不相关检查 query 改写和检索权重调整混合检索权重优化查询改写工具调用参数错误工具描述不清检查工具描述和参数 schema补充参数格式说明缩小枚举范围响应特别慢工具串行调用过多看调用链路耗时并行化独立工具调用加缓存多轮对话丢失上下文上下文管理有问题检查历史消息截断策略保留关键信息摘要压缩历史模型编造政策提示词约束不足检查系统提示词强化“基于资料回答”约束工具失败后 Agent 卡住错误处理缺失检查工具返回结构统一错误码明确重试策略并发上来后大量超时资源瓶颈看工具服务和模型服务负载加限流、加缓存、扩容7.2 几个我踩过的深坑第一个坑是过度依赖模型判断工具调用。早期我让模型自己决定调不调工具结果它经常该调不调、不该调乱调。后来改成在提示词里明确规则比如“涉及订单状态必须调用 query_order”准确率立刻上来了。模型不是不能用是要给它清晰的规则。第二个坑是知识库更新后没重新评估。有一次更新了退款政策知识库改了但没跑评估上线后发现 Agent 还在按旧政策回答。后来我把知识库更新和评估跑批绑定每次更新自动触发回归测试。第三个坑是忽略并发下的状态污染。多用户同时对话时如果上下文管理没做好A 用户的信息可能串到 B 用户的会话里。这个问题的根源通常是用了全局变量或者缓存 key 设计不当。解决办法是每个会话有独立的 session id所有状态都挂在 session 下。7.3 性能优化的几个实用技巧客服 Agent 对响应速度要求高优化空间主要在三个地方。检索层加缓存相同或相似 query 直接返回缓存结果用更快的向量索引减少检索的文档数量。工具层能并行调用的工具并行调不要串行给工具加超时和降级慢接口不要拖垮整体。模型层简单问题用小模型复杂问题用大模型流式输出让用户先看到部分内容感知上更快。还有一个容易被忽略的点是提示词长度。提示词越长模型首 token 延迟越高。定期精简提示词把不必要的内容移到 RAG 里能明显改善响应速度。8. 一些实操后的个人体会做客服 Agent 这一年多我最大的体会是这东西的难点不在模型而在工程。模型能力已经足够强了真正决定成败的是工具设计得合不合理、知识库建得干不干净、评估做得严不严谨、异常处理得到不到位。我见过太多团队把精力全花在调提示词上结果工具一调用就出错知识一检索就翻车评估全靠感觉最后上线即翻车。另一个体会是别追求一步到位。48 关不是一次能过完的先让 Agent 能回答高频问题再逐步加工具、加知识、加评估。每加一个能力就跑一次回归确保没把之前的能力搞坏。小步快跑比憋大招靠谱得多。最后分享一个我一直在用的小技巧把每次线上 bad case 都当成一次免费的评估样本。用户反馈的问题比你自己造的测试用例真实得多。建一个 bad case 库定期复盘你会发现 Agent 的进步速度比闭门造车快好几倍。这个库积累到一定程度就是你最宝贵的资产。
