1. 客服 Agent 的 48 关到底在渡什么劫做客服 Agent 这件事外行看热闹内行看门道。很多人以为接个大模型 API挂上知识库再塞几个工具函数一个能自动回答用户问题的客服机器人就完事了。我一开始也这么想直到真正把系统推到线上面对每天几万条真实用户会话才发现从 Demo 到生产之间隔着的不是一条河而是一片海。所谓“渡劫 48 关”不是夸张修辞。从最基础的 Tool Calling 到 RAG 检索增强再到 MCP 协议接入和 Eval 评估体系每一层都有各自的坑。Tool 调用的参数幻觉、RAG 的召回瓶颈、MCP 的上下文膨胀、Eval 的评分标准漂移这些问题不会在开发环境里暴露只会在真实流量下集中爆发。我踩过的坑包括但不限于Agent 把退款金额算错、知识库检索返回三年前的过期政策、工具调用陷入死循环烧掉大量 token、评估集跑出来的分数和人工抽检结果完全对不上。这篇文章面向的是正在做或准备做客服 Agent 的开发者不管你是刚接触 Agent 开发的新手还是已经上线但被各种边界情况折磨的老手都能从中找到可以直接复用的思路和方案。我会按 Tool、RAG、MCP、Eval 四个核心模块拆解每个模块讲清楚设计思路、实操要点、常见问题和排查技巧。全文基于我在实际项目中的经验总结涉及具体参数和配置的地方会给出计算过程方便你直接抄作业。2. Tool 层Agent 的手脚怎么长才不出事2.1 Tool 设计的核心原则与常见误区Tool 是 Agent 与外部世界交互的接口。客服场景下常见的 Tool 包括订单查询、物流追踪、退款申请、工单创建、知识库检索等。看起来简单但设计不好就是灾难现场。第一个原则是工具粒度要适中。我见过有人把“查询订单”和“查询物流”合成一个 Tool参数里加个 type 字段区分。结果模型经常传错 type或者两个场景的参数混在一起导致调用失败。正确的做法是按业务动作拆分每个 Tool 只做一件事参数列表尽量短。一般来说单个 Tool 的参数控制在 5 个以内超过 5 个就要考虑是不是该拆了。第二个原则是参数描述要像写给新人看的文档。模型理解 Tool 的能力完全依赖你给的 schema 描述。我试过把参数描述写成“订单号”结果模型有时候传用户 ID 进来。后来改成“订单号格式为纯数字长度 12-18 位从用户提供的订单截图或短信中提取”准确率直接上了一个台阶。描述里要包含参数含义、格式要求、取值范围、示例值、以及从对话中哪里获取这个值。第三个原则是返回值要结构化且带状态码。不要返回一大段自然语言让模型自己解析。我习惯返回 JSON包含status、data、message三个字段。status用枚举值如success、not_found、permission_denied、system_error模型看到not_found就知道该走“未找到订单”的回复分支而不是瞎编一个订单信息。注意Tool 的返回值里不要包含敏感字段如用户手机号完整号码、身份证号等。如果业务需要做脱敏处理比如手机号显示为 138****1234。2.2 Tool Calling 的参数校验与兜底策略模型生成 Tool 调用参数时幻觉是必然的。我统计过一轮线上数据在没有任何校验的情况下Tool 调用的参数错误率大约在 8%-12% 之间。主要错误类型包括参数缺失、格式错误、值域越界、张冠李戴。解决方案是在 Tool 执行前加一层参数校验中间件。这层中间件做几件事检查必填参数是否齐全、检查参数格式是否匹配正则、检查参数值是否在允许范围内、检查参数之间是否有逻辑矛盾。任何一项不通过不直接执行 Tool而是返回一个结构化的错误信息给模型让它重新生成或向用户追问。举个例子退款 Tool 需要订单号和退款金额两个参数。校验逻辑包括订单号必须匹配^\d{12,18}$退款金额必须是正数且不超过订单实付金额。如果模型传的退款金额是 0 或者负数直接拦截返回{status: invalid_param, message: 退款金额必须大于 0}。模型收到这个反馈后通常会重新生成正确的参数。兜底策略方面我设置了最大重试次数为 3 次。如果模型连续 3 次生成的参数都校验失败就触发降级流程转人工客服或者返回一个标准话术“抱歉我暂时无法处理这个请求已为您转接人工客服”。这个阈值是根据线上数据调的3 次之后模型基本已经陷入死循环继续重试只是浪费 token。2.3 多 Tool 编排与并发调用实战客服场景下用户一个问题往往需要调用多个 Tool。比如“我上周买的鞋子还没到帮我查一下物流如果还没发货就取消订单”这里涉及订单查询、物流查询、取消订单三个 Tool。串行调用是最简单的但延迟高。我实测下来串行调用三个 Tool 的平均响应时间是 2.8 秒用户等待感明显。后来改成并行调用无依赖的 Tool订单查询和物流查询可以同时发起等两个结果都返回后再判断是否需要取消订单。并行之后响应时间降到 1.6 秒左右。实现上我在 Agent 框架里加了一个依赖分析模块。每次模型返回多个 Tool 调用请求时先分析这些调用之间是否有数据依赖。没有依赖的走并行有依赖的走串行。依赖关系的判断规则是如果 Tool B 的某个参数值来自 Tool A 的返回值则 B 依赖 A。# 简化的依赖分析逻辑 def analyze_dependencies(tool_calls): dependencies {} for i, call in enumerate(tool_calls): deps [] for j, other in enumerate(tool_calls): if i ! j and any( param_value.startswith(f$tool_{j}.) for param_value in call[params].values() ): deps.append(j) dependencies[i] deps return dependencies实操心得并行调用时要注意 Tool 的幂等性。查询类 Tool 天然幂等但退款、取消订单这类写操作 Tool 不能并行否则可能重复执行。我在 Tool 注册时加了一个is_idempotent标记只有幂等的 Tool 才允许并行。3. RAG 层知识库检索的瓶颈与突破3.1 RAG 在客服场景下的核心挑战RAG 是客服 Agent 的“记忆系统”。用户问“你们的退货政策是什么”Agent 需要从知识库里检索到最新的退货政策文档然后生成回答。听起来简单但实际做起来RAG 的瓶颈非常明显。第一个瓶颈是召回率与准确率的平衡。召回率高了返回一堆不相关的文档模型容易被干扰召回率低了该找到的文档找不到模型就开始编。我试过纯向量检索、纯关键词检索、混合检索三种方案最终选择了混合检索加重排序的架构。第二个瓶颈是知识库的时效性管理。客服知识库里的政策、活动、产品信息经常更新。如果知识库更新不及时Agent 会拿着过期信息回答用户造成客诉。我的做法是给每个知识片段加effective_date和expiry_date字段检索时自动过滤掉过期内容。同时设置定时任务每天凌晨扫描即将过期的知识片段提醒运营人员更新。第三个瓶颈是多模态知识的处理。客服场景下很多知识以图片形式存在比如操作截图、产品对比图。纯文本 RAG 无法处理这些。我的方案是对图片做 OCR 提取文字同时用多模态模型生成图片描述将文字和描述一起存入知识库。检索时文本查询可以匹配到图片描述从而召回相关图片。3.2 混合检索与重排序的工程实现混合检索的核心思路是向量检索和关键词检索各取所长。向量检索擅长语义匹配比如用户问“怎么退钱”能匹配到“退款流程”文档关键词检索擅长精确匹配比如用户问“XX 型号的保修期”能精确命中包含该型号的文档。我的实现方案是先用向量检索召回 Top 20再用 BM25 关键词检索召回 Top 20合并去重后得到候选集然后用重排序模型对候选集打分取 Top 5 送入生成模型。重排序模型我选的是轻量级的交叉编码器推理延迟在 50ms 以内对整体响应时间影响可控。重排序的输入是“用户查询 候选文档”输出是相关性分数。实测下来加了重排序之后Top 5 的准确率从 72% 提升到 89%。# 混合检索伪代码 def hybrid_retrieve(query, top_k5): vector_results vector_search(query, top_k20) keyword_results bm25_search(query, top_k20) # 合并去重 candidates merge_dedup(vector_results, keyword_results) # 重排序 scored rerank_model.score(query, candidates) scored.sort(keylambda x: x.score, reverseTrue) return scored[:top_k]注意重排序模型的输入长度有限制通常 512 token。如果候选文档太长需要先做截断或分段。我的做法是把长文档按段落切分每个段落单独参与重排序最后取分数最高的段落。3.3 知识库更新与版本管理策略知识库不是建好就完事了它需要持续运营。我设计了一套知识库版本管理机制核心是三个概念草稿、发布、归档。运营人员在后台编辑知识内容时状态是“草稿”不影响线上检索。编辑完成后提交审核审核通过后点击“发布”新内容才会进入检索池。旧版本内容自动转为“归档”状态不再被检索但保留历史记录以便追溯。版本切换时有一个灰度发布的过程。新版本先对 10% 的流量生效观察一周。如果这 10% 流量的用户满意度、问题解决率没有下降再逐步扩大到 50%、100%。如果发现异常一键回滚到旧版本。这套机制解决了一个很实际的问题以前运营人员改完知识库直接生效有时候改错了导致 Agent 大面积答错等发现时已经产生大量客诉。现在有了灰度发布风险可控多了。4. MCP 层协议接入与上下文管理4.1 MCP 协议的核心价值与接入方式MCP 是 Model Context Protocol 的缩写它解决的是 Agent 与外部工具、数据源之间的标准化连接问题。在没有 MCP 之前每接入一个新的工具或数据源都要写一套适配代码。有了 MCP只要工具方实现了 MCP ServerAgent 侧就可以用统一的方式调用。客服场景下MCP 的价值在于快速接入内部系统。比如公司的 CRM 系统、工单系统、订单系统如果都实现了 MCP ServerAgent 就可以通过统一的协议调用不需要为每个系统单独写 Tool。这大大降低了接入成本。接入方式上MCP Server 可以本地运行也可以远程运行。本地运行通过 stdio 通信适合开发调试远程运行通过 HTTP 或 WebSocket 通信适合生产环境。我建议生产环境用远程方式方便做负载均衡和权限控制。{ mcpServers: { order-service: { url: https://internal-api.example.com/mcp/order, headers: { Authorization: Bearer ${ORDER_SERVICE_TOKEN} } }, ticket-service: { url: https://internal-api.example.com/mcp/ticket, headers: { Authorization: Bearer ${TICKET_SERVICE_TOKEN} } } } }4.2 MCP 上下文膨胀问题与压缩策略MCP 用起来爽但有一个坑上下文膨胀。每个 MCP Server 启动时都会把自己的工具列表、资源列表、提示模板注册到 Agent 的上下文中。如果接入了 10 个 MCP Server每个 Server 有 20 个工具那就是 200 个工具的描述信息塞进上下文。这些描述信息可能占用几千甚至上万 token直接挤压了用户对话和知识库检索的空间。我的压缩策略分三步。第一步是按需加载。不是所有 MCP Server 都需要在每轮对话中可用。我根据用户问题的意图分类只加载相关的 MCP Server。比如用户问订单问题只加载订单服务的 MCP Server其他先不加载。第二步是工具描述精简。MCP 协议允许工具描述包含丰富的元信息但实际传给模型时只保留最核心的部分工具名、一句话功能描述、参数列表。详细的文档、示例、注意事项放在外部模型需要时再通过一个“查看工具详情”的 Tool 获取。第三步是动态卸载。如果某个 MCP Server 在连续 5 轮对话中都没有被调用就把它从上下文中卸载释放 token 空间。下次需要时再重新加载。这三步下来上下文占用从平均 8000 token 降到了 2500 token 左右效果非常明显。4.3 MCP 安全与权限控制实践MCP 接入了内部系统安全是重中之重。我做了几层防护。第一层是网络隔离。MCP Server 部署在内网不直接暴露公网。Agent 通过内网网关访问网关做 IP 白名单和请求频率限制。第二层是认证鉴权。每个 MCP Server 调用都需要携带 TokenToken 里包含调用方身份和权限范围。比如客服 Agent 的 Token 只能调用查询类工具不能调用删除类工具。第三层是操作审计。所有 MCP 调用都记录日志包括调用时间、调用方、工具名、参数、返回值、耗时。日志保留 180 天方便事后追溯。第四层是敏感操作二次确认。对于退款、取消订单这类敏感操作MCP Server 不直接执行而是返回一个“待确认”状态Agent 需要向用户确认后再发起第二次调用第二次调用携带确认令牌才真正执行。实操心得MCP 的 Token 不要硬编码在配置文件里用环境变量或密钥管理服务注入。我见过有人把 Token 写在代码里提交到了代码仓库虽然后来删了但历史记录里还能找到风险很大。5. Eval 层评估体系怎么建才靠谱5.1 客服 Agent 的评估指标体系Eval 是 Agent 迭代的指南针。没有 Eval你根本不知道改了一版 prompt 或换了一个模型之后效果是变好了还是变差了。客服 Agent 的评估指标我分成了四类。第一类是任务完成率。用户的问题是否被解决。这个指标最难自动化因为需要判断用户是否满意。我的做法是结合显式反馈和隐式信号。显式反馈是用户点击“已解决”或“未解决”按钮隐式信号包括用户是否在 Agent 回复后继续追问同一问题、是否转人工、是否在会话结束后短时间内再次发起相同咨询。第二类是回答准确率。Agent 的回答是否与知识库一致、是否有事实错误。这个可以用人工抽检加自动评估结合。自动评估用另一个模型做裁判判断 Agent 回答是否与检索到的知识片段矛盾。第三类是工具调用准确率。Tool 调用的参数是否正确、是否调用了正确的 Tool、是否有不必要的调用。这个可以完全自动化因为 Tool 调用的输入输出都是结构化的。第四类是效率指标。包括平均响应时间、平均 token 消耗、平均对话轮次。这些指标影响成本和用户体验需要持续监控。指标类别具体指标目标值测量方式任务完成问题解决率≥ 75%显式反馈 隐式信号回答质量事实准确率≥ 95%模型裁判 人工抽检工具调用参数正确率≥ 98%自动校验效率平均响应时间≤ 2s埋点统计效率平均 token 消耗≤ 3000埋点统计5.2 自动化评估流水线的搭建人工评估成本高、周期长不可能每次改动都跑一遍。我搭建了一套自动化评估流水线核心是三个组件评估数据集、评估执行器、评估报告。评估数据集是精心构造的测试用例每条用例包含用户输入、期望的 Tool 调用序列、期望的回答要点、以及评分标准。数据集覆盖了常见问题、边界情况、对抗样本。我目前维护了 500 条核心用例每次发版前跑一遍。评估执行器负责把测试用例喂给 Agent收集 Agent 的实际输出然后与期望输出对比。对比逻辑分三层Tool 调用序列是否匹配、回答是否包含期望要点、回答是否包含禁止内容。三层都通过才算这条用例通过。评估报告输出通过率、失败用例详情、以及与前一次评估的对比。如果通过率下降超过 2%自动阻断发版流程需要人工介入分析。# 评估执行器核心逻辑 def run_evaluation(agent, test_cases): results [] for case in test_cases: actual agent.process(case[input]) tool_match compare_tool_calls( actual[tool_calls], case[expected_tool_calls] ) content_match check_content( actual[response], case[expected_points], case[forbidden_content] ) results.append({ case_id: case[id], passed: tool_match and content_match, tool_match: tool_match, content_match: content_match, actual: actual }) pass_rate sum(r[passed] for r in results) / len(results) return {pass_rate: pass_rate, details: results}5.3 评估结果分析与迭代闭环评估跑完不是终点分析结果并驱动迭代才是。我每周会花半天时间看评估报告重点关注三类失败用例。第一类是系统性失败。如果某一类问题大量失败说明 Agent 在这个方向上有系统性缺陷。比如所有涉及“修改收货地址”的用例都失败那可能是 Tool 设计有问题或者知识库里缺少相关流程说明。第二类是回归失败。之前能通过的用例这次失败了说明最近的改动引入了回归。这类问题优先级最高需要立即定位是哪个改动导致的。第三类是边界失败。一些极端情况下的失败虽然数量少但反映了 Agent 的鲁棒性不足。比如用户输入包含特殊字符、超长文本、多语言混合时Agent 的表现如何。分析完之后我会把改进项录入任务系统排优先级然后进入下一轮迭代。迭代的内容可能是改 prompt、改 Tool 描述、补充知识库、调整检索参数、或者换模型。每次迭代后重新跑评估确认改进有效且没有引入新的回归。注意评估数据集本身也需要迭代。如果发现评估集里的某些用例期望输出已经过时或者评分标准不合理要及时修正。我每季度会 review 一遍评估集淘汰过时用例补充新场景用例。6. 从 48 关里活下来之后的一些体会这套系统从第一版上线到现在经历了大概 8 个月的高强度迭代。中间有几次大的架构调整比如从纯向量检索换成混合检索、从串行 Tool 调用改成并行、从人工评估为主改成自动化评估为主。每次调整都伴随着阵痛但回头看都是值得的。有一个很深的体会是Agent 的效果上限取决于工程细节而不是模型能力。同样的模型Tool 描述写得好不好、RAG 检索准不准、MCP 上下文管不管得住、Eval 体系全不全最终效果差异巨大。我见过太多团队把精力花在追新模型上却忽略了这些基础工程结果效果一直上不去。另一个体会是客服 Agent 的终极目标不是替代人工而是让人工做更有价值的事。Agent 处理掉 70% 的常见问题剩下 30% 的复杂问题转人工人工客服的效率和满意度都会提升。如果一味追求 Agent 的解决率把复杂问题也硬塞给 Agent用户体验反而会下降。最后分享一个排查问题的技巧当 Agent 表现异常时按Tool → RAG → MCP → Eval的顺序逐层排查。先看 Tool 调用日志确认参数和返回值是否正常再看 RAG 检索结果确认召回的知识是否相关然后看 MCP 上下文确认工具列表是否完整、是否有冲突最后看 Eval 报告确认是否是已知问题。这个顺序覆盖了 90% 以上的异常情况能帮你快速定位问题所在。
客服Agent生产环境实战：Tool、RAG、MCP、Eval四层渡劫指南
1. 客服 Agent 的 48 关到底在渡什么劫做客服 Agent 这件事外行看热闹内行看门道。很多人以为接个大模型 API挂上知识库再塞几个工具函数一个能自动回答用户问题的客服机器人就完事了。我一开始也这么想直到真正把系统推到线上面对每天几万条真实用户会话才发现从 Demo 到生产之间隔着的不是一条河而是一片海。所谓“渡劫 48 关”不是夸张修辞。从最基础的 Tool Calling 到 RAG 检索增强再到 MCP 协议接入和 Eval 评估体系每一层都有各自的坑。Tool 调用的参数幻觉、RAG 的召回瓶颈、MCP 的上下文膨胀、Eval 的评分标准漂移这些问题不会在开发环境里暴露只会在真实流量下集中爆发。我踩过的坑包括但不限于Agent 把退款金额算错、知识库检索返回三年前的过期政策、工具调用陷入死循环烧掉大量 token、评估集跑出来的分数和人工抽检结果完全对不上。这篇文章面向的是正在做或准备做客服 Agent 的开发者不管你是刚接触 Agent 开发的新手还是已经上线但被各种边界情况折磨的老手都能从中找到可以直接复用的思路和方案。我会按 Tool、RAG、MCP、Eval 四个核心模块拆解每个模块讲清楚设计思路、实操要点、常见问题和排查技巧。全文基于我在实际项目中的经验总结涉及具体参数和配置的地方会给出计算过程方便你直接抄作业。2. Tool 层Agent 的手脚怎么长才不出事2.1 Tool 设计的核心原则与常见误区Tool 是 Agent 与外部世界交互的接口。客服场景下常见的 Tool 包括订单查询、物流追踪、退款申请、工单创建、知识库检索等。看起来简单但设计不好就是灾难现场。第一个原则是工具粒度要适中。我见过有人把“查询订单”和“查询物流”合成一个 Tool参数里加个 type 字段区分。结果模型经常传错 type或者两个场景的参数混在一起导致调用失败。正确的做法是按业务动作拆分每个 Tool 只做一件事参数列表尽量短。一般来说单个 Tool 的参数控制在 5 个以内超过 5 个就要考虑是不是该拆了。第二个原则是参数描述要像写给新人看的文档。模型理解 Tool 的能力完全依赖你给的 schema 描述。我试过把参数描述写成“订单号”结果模型有时候传用户 ID 进来。后来改成“订单号格式为纯数字长度 12-18 位从用户提供的订单截图或短信中提取”准确率直接上了一个台阶。描述里要包含参数含义、格式要求、取值范围、示例值、以及从对话中哪里获取这个值。第三个原则是返回值要结构化且带状态码。不要返回一大段自然语言让模型自己解析。我习惯返回 JSON包含status、data、message三个字段。status用枚举值如success、not_found、permission_denied、system_error模型看到not_found就知道该走“未找到订单”的回复分支而不是瞎编一个订单信息。注意Tool 的返回值里不要包含敏感字段如用户手机号完整号码、身份证号等。如果业务需要做脱敏处理比如手机号显示为 138****1234。2.2 Tool Calling 的参数校验与兜底策略模型生成 Tool 调用参数时幻觉是必然的。我统计过一轮线上数据在没有任何校验的情况下Tool 调用的参数错误率大约在 8%-12% 之间。主要错误类型包括参数缺失、格式错误、值域越界、张冠李戴。解决方案是在 Tool 执行前加一层参数校验中间件。这层中间件做几件事检查必填参数是否齐全、检查参数格式是否匹配正则、检查参数值是否在允许范围内、检查参数之间是否有逻辑矛盾。任何一项不通过不直接执行 Tool而是返回一个结构化的错误信息给模型让它重新生成或向用户追问。举个例子退款 Tool 需要订单号和退款金额两个参数。校验逻辑包括订单号必须匹配^\d{12,18}$退款金额必须是正数且不超过订单实付金额。如果模型传的退款金额是 0 或者负数直接拦截返回{status: invalid_param, message: 退款金额必须大于 0}。模型收到这个反馈后通常会重新生成正确的参数。兜底策略方面我设置了最大重试次数为 3 次。如果模型连续 3 次生成的参数都校验失败就触发降级流程转人工客服或者返回一个标准话术“抱歉我暂时无法处理这个请求已为您转接人工客服”。这个阈值是根据线上数据调的3 次之后模型基本已经陷入死循环继续重试只是浪费 token。2.3 多 Tool 编排与并发调用实战客服场景下用户一个问题往往需要调用多个 Tool。比如“我上周买的鞋子还没到帮我查一下物流如果还没发货就取消订单”这里涉及订单查询、物流查询、取消订单三个 Tool。串行调用是最简单的但延迟高。我实测下来串行调用三个 Tool 的平均响应时间是 2.8 秒用户等待感明显。后来改成并行调用无依赖的 Tool订单查询和物流查询可以同时发起等两个结果都返回后再判断是否需要取消订单。并行之后响应时间降到 1.6 秒左右。实现上我在 Agent 框架里加了一个依赖分析模块。每次模型返回多个 Tool 调用请求时先分析这些调用之间是否有数据依赖。没有依赖的走并行有依赖的走串行。依赖关系的判断规则是如果 Tool B 的某个参数值来自 Tool A 的返回值则 B 依赖 A。# 简化的依赖分析逻辑 def analyze_dependencies(tool_calls): dependencies {} for i, call in enumerate(tool_calls): deps [] for j, other in enumerate(tool_calls): if i ! j and any( param_value.startswith(f$tool_{j}.) for param_value in call[params].values() ): deps.append(j) dependencies[i] deps return dependencies实操心得并行调用时要注意 Tool 的幂等性。查询类 Tool 天然幂等但退款、取消订单这类写操作 Tool 不能并行否则可能重复执行。我在 Tool 注册时加了一个is_idempotent标记只有幂等的 Tool 才允许并行。3. RAG 层知识库检索的瓶颈与突破3.1 RAG 在客服场景下的核心挑战RAG 是客服 Agent 的“记忆系统”。用户问“你们的退货政策是什么”Agent 需要从知识库里检索到最新的退货政策文档然后生成回答。听起来简单但实际做起来RAG 的瓶颈非常明显。第一个瓶颈是召回率与准确率的平衡。召回率高了返回一堆不相关的文档模型容易被干扰召回率低了该找到的文档找不到模型就开始编。我试过纯向量检索、纯关键词检索、混合检索三种方案最终选择了混合检索加重排序的架构。第二个瓶颈是知识库的时效性管理。客服知识库里的政策、活动、产品信息经常更新。如果知识库更新不及时Agent 会拿着过期信息回答用户造成客诉。我的做法是给每个知识片段加effective_date和expiry_date字段检索时自动过滤掉过期内容。同时设置定时任务每天凌晨扫描即将过期的知识片段提醒运营人员更新。第三个瓶颈是多模态知识的处理。客服场景下很多知识以图片形式存在比如操作截图、产品对比图。纯文本 RAG 无法处理这些。我的方案是对图片做 OCR 提取文字同时用多模态模型生成图片描述将文字和描述一起存入知识库。检索时文本查询可以匹配到图片描述从而召回相关图片。3.2 混合检索与重排序的工程实现混合检索的核心思路是向量检索和关键词检索各取所长。向量检索擅长语义匹配比如用户问“怎么退钱”能匹配到“退款流程”文档关键词检索擅长精确匹配比如用户问“XX 型号的保修期”能精确命中包含该型号的文档。我的实现方案是先用向量检索召回 Top 20再用 BM25 关键词检索召回 Top 20合并去重后得到候选集然后用重排序模型对候选集打分取 Top 5 送入生成模型。重排序模型我选的是轻量级的交叉编码器推理延迟在 50ms 以内对整体响应时间影响可控。重排序的输入是“用户查询 候选文档”输出是相关性分数。实测下来加了重排序之后Top 5 的准确率从 72% 提升到 89%。# 混合检索伪代码 def hybrid_retrieve(query, top_k5): vector_results vector_search(query, top_k20) keyword_results bm25_search(query, top_k20) # 合并去重 candidates merge_dedup(vector_results, keyword_results) # 重排序 scored rerank_model.score(query, candidates) scored.sort(keylambda x: x.score, reverseTrue) return scored[:top_k]注意重排序模型的输入长度有限制通常 512 token。如果候选文档太长需要先做截断或分段。我的做法是把长文档按段落切分每个段落单独参与重排序最后取分数最高的段落。3.3 知识库更新与版本管理策略知识库不是建好就完事了它需要持续运营。我设计了一套知识库版本管理机制核心是三个概念草稿、发布、归档。运营人员在后台编辑知识内容时状态是“草稿”不影响线上检索。编辑完成后提交审核审核通过后点击“发布”新内容才会进入检索池。旧版本内容自动转为“归档”状态不再被检索但保留历史记录以便追溯。版本切换时有一个灰度发布的过程。新版本先对 10% 的流量生效观察一周。如果这 10% 流量的用户满意度、问题解决率没有下降再逐步扩大到 50%、100%。如果发现异常一键回滚到旧版本。这套机制解决了一个很实际的问题以前运营人员改完知识库直接生效有时候改错了导致 Agent 大面积答错等发现时已经产生大量客诉。现在有了灰度发布风险可控多了。4. MCP 层协议接入与上下文管理4.1 MCP 协议的核心价值与接入方式MCP 是 Model Context Protocol 的缩写它解决的是 Agent 与外部工具、数据源之间的标准化连接问题。在没有 MCP 之前每接入一个新的工具或数据源都要写一套适配代码。有了 MCP只要工具方实现了 MCP ServerAgent 侧就可以用统一的方式调用。客服场景下MCP 的价值在于快速接入内部系统。比如公司的 CRM 系统、工单系统、订单系统如果都实现了 MCP ServerAgent 就可以通过统一的协议调用不需要为每个系统单独写 Tool。这大大降低了接入成本。接入方式上MCP Server 可以本地运行也可以远程运行。本地运行通过 stdio 通信适合开发调试远程运行通过 HTTP 或 WebSocket 通信适合生产环境。我建议生产环境用远程方式方便做负载均衡和权限控制。{ mcpServers: { order-service: { url: https://internal-api.example.com/mcp/order, headers: { Authorization: Bearer ${ORDER_SERVICE_TOKEN} } }, ticket-service: { url: https://internal-api.example.com/mcp/ticket, headers: { Authorization: Bearer ${TICKET_SERVICE_TOKEN} } } } }4.2 MCP 上下文膨胀问题与压缩策略MCP 用起来爽但有一个坑上下文膨胀。每个 MCP Server 启动时都会把自己的工具列表、资源列表、提示模板注册到 Agent 的上下文中。如果接入了 10 个 MCP Server每个 Server 有 20 个工具那就是 200 个工具的描述信息塞进上下文。这些描述信息可能占用几千甚至上万 token直接挤压了用户对话和知识库检索的空间。我的压缩策略分三步。第一步是按需加载。不是所有 MCP Server 都需要在每轮对话中可用。我根据用户问题的意图分类只加载相关的 MCP Server。比如用户问订单问题只加载订单服务的 MCP Server其他先不加载。第二步是工具描述精简。MCP 协议允许工具描述包含丰富的元信息但实际传给模型时只保留最核心的部分工具名、一句话功能描述、参数列表。详细的文档、示例、注意事项放在外部模型需要时再通过一个“查看工具详情”的 Tool 获取。第三步是动态卸载。如果某个 MCP Server 在连续 5 轮对话中都没有被调用就把它从上下文中卸载释放 token 空间。下次需要时再重新加载。这三步下来上下文占用从平均 8000 token 降到了 2500 token 左右效果非常明显。4.3 MCP 安全与权限控制实践MCP 接入了内部系统安全是重中之重。我做了几层防护。第一层是网络隔离。MCP Server 部署在内网不直接暴露公网。Agent 通过内网网关访问网关做 IP 白名单和请求频率限制。第二层是认证鉴权。每个 MCP Server 调用都需要携带 TokenToken 里包含调用方身份和权限范围。比如客服 Agent 的 Token 只能调用查询类工具不能调用删除类工具。第三层是操作审计。所有 MCP 调用都记录日志包括调用时间、调用方、工具名、参数、返回值、耗时。日志保留 180 天方便事后追溯。第四层是敏感操作二次确认。对于退款、取消订单这类敏感操作MCP Server 不直接执行而是返回一个“待确认”状态Agent 需要向用户确认后再发起第二次调用第二次调用携带确认令牌才真正执行。实操心得MCP 的 Token 不要硬编码在配置文件里用环境变量或密钥管理服务注入。我见过有人把 Token 写在代码里提交到了代码仓库虽然后来删了但历史记录里还能找到风险很大。5. Eval 层评估体系怎么建才靠谱5.1 客服 Agent 的评估指标体系Eval 是 Agent 迭代的指南针。没有 Eval你根本不知道改了一版 prompt 或换了一个模型之后效果是变好了还是变差了。客服 Agent 的评估指标我分成了四类。第一类是任务完成率。用户的问题是否被解决。这个指标最难自动化因为需要判断用户是否满意。我的做法是结合显式反馈和隐式信号。显式反馈是用户点击“已解决”或“未解决”按钮隐式信号包括用户是否在 Agent 回复后继续追问同一问题、是否转人工、是否在会话结束后短时间内再次发起相同咨询。第二类是回答准确率。Agent 的回答是否与知识库一致、是否有事实错误。这个可以用人工抽检加自动评估结合。自动评估用另一个模型做裁判判断 Agent 回答是否与检索到的知识片段矛盾。第三类是工具调用准确率。Tool 调用的参数是否正确、是否调用了正确的 Tool、是否有不必要的调用。这个可以完全自动化因为 Tool 调用的输入输出都是结构化的。第四类是效率指标。包括平均响应时间、平均 token 消耗、平均对话轮次。这些指标影响成本和用户体验需要持续监控。指标类别具体指标目标值测量方式任务完成问题解决率≥ 75%显式反馈 隐式信号回答质量事实准确率≥ 95%模型裁判 人工抽检工具调用参数正确率≥ 98%自动校验效率平均响应时间≤ 2s埋点统计效率平均 token 消耗≤ 3000埋点统计5.2 自动化评估流水线的搭建人工评估成本高、周期长不可能每次改动都跑一遍。我搭建了一套自动化评估流水线核心是三个组件评估数据集、评估执行器、评估报告。评估数据集是精心构造的测试用例每条用例包含用户输入、期望的 Tool 调用序列、期望的回答要点、以及评分标准。数据集覆盖了常见问题、边界情况、对抗样本。我目前维护了 500 条核心用例每次发版前跑一遍。评估执行器负责把测试用例喂给 Agent收集 Agent 的实际输出然后与期望输出对比。对比逻辑分三层Tool 调用序列是否匹配、回答是否包含期望要点、回答是否包含禁止内容。三层都通过才算这条用例通过。评估报告输出通过率、失败用例详情、以及与前一次评估的对比。如果通过率下降超过 2%自动阻断发版流程需要人工介入分析。# 评估执行器核心逻辑 def run_evaluation(agent, test_cases): results [] for case in test_cases: actual agent.process(case[input]) tool_match compare_tool_calls( actual[tool_calls], case[expected_tool_calls] ) content_match check_content( actual[response], case[expected_points], case[forbidden_content] ) results.append({ case_id: case[id], passed: tool_match and content_match, tool_match: tool_match, content_match: content_match, actual: actual }) pass_rate sum(r[passed] for r in results) / len(results) return {pass_rate: pass_rate, details: results}5.3 评估结果分析与迭代闭环评估跑完不是终点分析结果并驱动迭代才是。我每周会花半天时间看评估报告重点关注三类失败用例。第一类是系统性失败。如果某一类问题大量失败说明 Agent 在这个方向上有系统性缺陷。比如所有涉及“修改收货地址”的用例都失败那可能是 Tool 设计有问题或者知识库里缺少相关流程说明。第二类是回归失败。之前能通过的用例这次失败了说明最近的改动引入了回归。这类问题优先级最高需要立即定位是哪个改动导致的。第三类是边界失败。一些极端情况下的失败虽然数量少但反映了 Agent 的鲁棒性不足。比如用户输入包含特殊字符、超长文本、多语言混合时Agent 的表现如何。分析完之后我会把改进项录入任务系统排优先级然后进入下一轮迭代。迭代的内容可能是改 prompt、改 Tool 描述、补充知识库、调整检索参数、或者换模型。每次迭代后重新跑评估确认改进有效且没有引入新的回归。注意评估数据集本身也需要迭代。如果发现评估集里的某些用例期望输出已经过时或者评分标准不合理要及时修正。我每季度会 review 一遍评估集淘汰过时用例补充新场景用例。6. 从 48 关里活下来之后的一些体会这套系统从第一版上线到现在经历了大概 8 个月的高强度迭代。中间有几次大的架构调整比如从纯向量检索换成混合检索、从串行 Tool 调用改成并行、从人工评估为主改成自动化评估为主。每次调整都伴随着阵痛但回头看都是值得的。有一个很深的体会是Agent 的效果上限取决于工程细节而不是模型能力。同样的模型Tool 描述写得好不好、RAG 检索准不准、MCP 上下文管不管得住、Eval 体系全不全最终效果差异巨大。我见过太多团队把精力花在追新模型上却忽略了这些基础工程结果效果一直上不去。另一个体会是客服 Agent 的终极目标不是替代人工而是让人工做更有价值的事。Agent 处理掉 70% 的常见问题剩下 30% 的复杂问题转人工人工客服的效率和满意度都会提升。如果一味追求 Agent 的解决率把复杂问题也硬塞给 Agent用户体验反而会下降。最后分享一个排查问题的技巧当 Agent 表现异常时按Tool → RAG → MCP → Eval的顺序逐层排查。先看 Tool 调用日志确认参数和返回值是否正常再看 RAG 检索结果确认召回的知识是否相关然后看 MCP 上下文确认工具列表是否完整、是否有冲突最后看 Eval 报告确认是否是已知问题。这个顺序覆盖了 90% 以上的异常情况能帮你快速定位问题所在。
