尧图网页设计 
1. 从零拆解客服 Agent 的 48 关为什么 Tool、RAG、MCP、Eval 一个都不能少做客服 Agent 这件事我前前后后折腾了大半年踩过的坑比吃过的盐还多。一开始我以为客服 Agent 就是个“大模型套壳加个知识库”结果真上手才发现从最基础的 Tool 调用到 RAG 检索增强再到 MCP 协议接入和 Eval 评测体系每一层都有它存在的硬理由。这篇文章不聊虚的就把我趟过的 48 个关键节点拆开揉碎讲清楚适合正在做或准备做客服 Agent 的开发者、产品经理和技术负责人参考。不管你是刚接触 Agent 开发的新手还是已经踩过几轮坑的老手应该都能从里面找到对自己有用的东西。先说清楚这个标题里的几个核心概念。Agent在这里特指能自主决策、调用工具、完成多轮任务的智能体不是那种一问一答的简单机器人。Tool是 Agent 的手和脚让它能查订单、改地址、发工单。RAG是它的记忆外挂把企业知识库、FAQ、历史工单变成可检索的向量数据。MCP是模型上下文协议解决的是 Agent 跟外部系统怎么标准化对接的问题。Eval则是质检员没有它你根本不知道 Agent 到底行不行。这四个东西串起来才构成一个能上生产的客服 Agent。为什么是“48 关”因为从 Demo 到生产我数了数光是必须解决的独立问题就有四十多个。有些是技术架构层面的比如工具调用的幂等性设计有些是工程细节比如 RAG 切片时中文标点怎么处理还有些是业务逻辑比如用户情绪激动时 Agent 该不该继续走流程。每一关单独看都不难但叠在一起就是一座山。下面我按模块把这 48 关拆开把每个关键决策背后的“为什么”讲透。2. Tool 层Agent 的手脚怎么长才不出事2.1 工具注册与描述别让模型猜你的接口Tool 是客服 Agent 最先要搞定的东西。没有工具Agent 就是个只会聊天的废物。但工具怎么注册、怎么描述这里面门道很深。我见过太多人直接把后端 API 文档扔给模型结果模型调用成功率不到 60%。问题出在工具描述上。工具描述不是写给人看的 API 文档是写给模型看的“使用说明书”。每个工具的description字段必须包含三个要素什么时候用、参数怎么填、返回什么。举个例子查订单工具的描述不能只写“查询订单信息”要写成“根据用户提供的订单号或手机号查询订单状态、物流信息和预计送达时间。当用户询问订单进度、物流位置、是否发货时使用此工具。订单号格式为纯数字 12-18 位手机号为 11 位数字。”参数描述同样关键。每个参数的description要说明格式、取值范围、是否必填。我实测下来把参数描述写清楚后工具调用准确率能从 65% 提到 92% 左右。还有一个技巧给每个工具加examples字段用自然语言写两三个调用示例。模型看到示例后对参数的理解会准确很多。注意工具数量不要一次性全注册给模型。我试过把 30 多个工具全塞进 system prompt结果模型选择困难经常调错工具。后来改成按场景分组每次只暴露 5-8 个相关工具准确率明显回升。2.2 工具调用的幂等性与超时处理客服场景有个特点用户会重复问同一个问题。如果 Agent 每次调用查订单工具都去请求后端不仅浪费资源还可能因为网络抖动导致重复下单、重复发工单。所以工具调用必须做幂等。我的做法是在工具层加一个idempotency_key由 Agent 根据用户 ID 意图 时间窗口生成。同一个用户在同一分钟内查同一个订单直接返回缓存结果。这个 key 的生成逻辑要写进工具描述里让模型知道什么时候该复用。超时处理也是血泪教训。客服后端接口平均响应 200ms但高峰期可能到 2s。如果工具调用超时Agent 不能傻等要有降级策略。我的配置是单个工具调用超时 3s超时后返回“系统繁忙请稍后重试”的友好提示同时记录日志。如果连续两次超时Agent 自动切换到人工客服入口。这个逻辑用代码写死在工具调用层不依赖模型判断。# 工具调用超时与降级示例 import asyncio from functools import wraps def tool_timeout(seconds3): def decorator(func): wraps(func) async def wrapper(*args, **kwargs): try: return await asyncio.wait_for(func(*args, **kwargs), timeoutseconds) except asyncio.TimeoutError: return {error: timeout, message: 系统繁忙请稍后重试} return wrapper return decorator2.3 工具返回结果的格式化与截断工具返回的数据往往很长比如订单详情可能包含几十个字段。如果全塞给模型不仅浪费 token还会干扰模型判断。我的经验是工具返回结果要做“摘要化”处理。具体做法是定义一个summary_fields配置每个工具指定哪些字段需要返回给模型。比如查订单工具只返回订单号、状态、物流公司、运单号、预计送达时间这五个字段。其他字段存在上下文里需要时再通过二次工具调用获取。这样能把单次工具调用的 token 消耗降低 70% 以上。还有一个细节返回结果里的敏感信息要脱敏。手机号中间四位打码地址只保留到城市级别。这个在工具层做不要指望模型自己脱敏模型有时候会“忘记”。3. RAG 层知识库不是扔进去就完事3.1 中文文档切片的三个关键参数RAG 是客服 Agent 的知识底座。但很多人做 RAG 就是“文档扔进去、向量化、检索”结果召回率惨不忍睹。问题八成出在切片上。中文文档切片跟英文完全不一样英文按空格和句号切就行中文得考虑标点和语义。我试过三种切片策略最后稳定用的是“按标点切 语义合并”。具体参数是chunk_size500字符chunk_overlap80字符分隔符优先级是[\n\n, \n, 。, , , , ]。为什么是 500因为中文 500 字大约对应 300-400 个 token加上 overlap 后总长度在模型上下文窗口的舒适区。太小了语义不完整太大了检索精度下降。chunk_overlap设 80 是为了保证跨 chunk 的语义连续性。比如一个问题的答案跨了两个段落overlap 能让两个 chunk 都包含部分答案检索时至少有一个能命中。这个值不要设太大否则冗余严重检索时会返回大量重复内容。实操心得切片前一定要做文本清洗。把 PDF 里的换行符、页眉页脚、乱码全去掉。我见过最离谱的案例是 PDF 每行都有个“第 X 页”切片后每个 chunk 都带着这玩意儿检索时全是噪声。3.2 向量模型选型与混合检索向量模型的选择直接决定 RAG 的上限。我对比过七八个模型最后在客服场景下稳定用的是bge-large-zh-v1.5做向量化bge-reranker-large做重排序。为什么不用 OpenAI 的 embedding因为客服数据涉及企业隐私本地部署更稳妥而且中文场景下 bge 系列的表现确实更好。但纯向量检索有个致命问题对专有名词和数字不敏感。用户问“订单号 123456 的物流”向量检索可能返回一堆无关的物流政策文档。所以必须上混合检索向量检索 关键词检索BM25两路结果合并后再用 reranker 精排。我的配置是向量检索取 top 20BM25 取 top 20合并去重后大概 30-35 条再用 reranker 取 top 5 送给模型。这个流程下来召回率能从纯向量的 72% 提到 91% 左右。reranker 的阈值设 0.3低于这个分数的直接丢弃避免噪声干扰。3.3 RAG 知识库的更新与版本管理知识库不是建好就完了客服话术、产品政策、活动规则天天在变。如果知识库更新不及时Agent 就会给出过时答案这比不回答还糟糕。我的做法是给知识库加版本号每次更新生成一个新版本检索时默认用最新版本但保留历史版本用于回滚。更新流程是运营在后台提交新文档 - 自动切片向量化 - 生成新版本 - 灰度 10% 流量测试 - 观察 24 小时无异常 - 全量切换。这个流程看起来麻烦但能避免“更新后 Agent 突然变傻”的事故。我踩过一次坑运营把一份旧版退货政策传上去覆盖了新版结果当天退货咨询全部答错客诉率飙升。从那以后版本管理就成了硬性要求。4. MCP 层标准化对接的利与坑4.1 MCP 到底解决了什么问题MCP 全称 Model Context Protocol翻译过来叫模型上下文协议。它解决的核心问题是Agent 跟外部系统对接时不用每个系统都写一套适配代码。没有 MCP 之前我接一个 CRM 系统要写一套工具接一个工单系统又要写一套代码重复率极高。有了 MCP只要外部系统实现了 MCP ServerAgent 就能通过标准协议直接调用。在客服场景里MCP 的价值特别明显。客服 Agent 通常要对接订单系统、物流系统、会员系统、工单系统、知识库系统。如果每个都自己写工具维护成本巨大。用 MCP 之后这些系统只要暴露标准的 MCP 接口Agent 端统一用 MCP Client 调用新增系统只需要配置一下不用改代码。但 MCP 也不是银弹。我实际用下来最大的坑是协议版本兼容性。MCP 还在快速迭代不同版本的 Server 和 Client 之间可能有字段差异。我的建议是锁定一个稳定版本所有 Server 和 Client 统一版本号升级时一起升。不要混用版本否则会出现“工具列表能拉到但调用报错”的诡异问题。4.2 MCP Server 的部署与安全配置MCP Server 的部署方式直接影响 Agent 的稳定性。我试过三种部署模式本地进程、容器化、远程服务。最后生产环境用的是容器化部署每个 MCP Server 一个独立容器通过内部网络通信。为什么不用本地进程因为本地进程跟 Agent 耦合太紧一个 Server 崩溃可能拖垮整个 Agent。容器化之后每个 Server 有独立的资源限制和健康检查崩了自动重启不影响其他 Server。远程服务模式延迟太高客服场景对响应时间敏感超过 500ms 用户就能感知到卡顿所以不推荐。安全配置是 MCP 最容易忽视的地方。MCP Server 暴露的工具可能涉及敏感操作比如修改订单、退款、发工单。我的做法是所有写操作工具必须加权限校验。MCP Client 调用时带上用户身份 tokenServer 端校验 token 是否有权限执行该操作。没有权限的直接返回 403Agent 收到后转人工处理。// MCP Server 权限配置示例 { tool: update_order_address, required_permission: order:write, rate_limit: 10/minute, audit_log: true }4.3 MCP 与 Tool 的关系不是替代是互补很多人问有了 MCP 还需要 Tool 吗我的答案是两者互补不是替代关系。MCP 解决的是“怎么标准化对接外部系统”Tool 解决的是“Agent 怎么理解和使用这些能力”。具体来说MCP Server 提供的是原始能力接口比如query_order、update_address。但这些接口对模型来说太底层了模型不知道什么时候该调、参数怎么填。所以还需要在 Agent 层定义 Tool把 MCP 接口包装成模型能理解的工具描述。Tool 的description和参数说明还是得写只是底层实现从“直接调 API”变成了“通过 MCP Client 调 MCP Server”。这个分层的好处是MCP 层可以复用同一个 MCP Server 可以被多个 Agent 使用Tool 层可以定制不同 Agent 对同一个 MCP 接口可以有不同描述和参数映射。我现在的架构就是 MCP 层统一对接所有外部系统Tool 层按业务场景定义两层之间用适配器模式连接。5. Eval 层没有评测的 Agent 就是盲盒5.1 客服 Agent 的评测指标体系Eval 是客服 Agent 从 Demo 到生产的最后一道关也是最重要的一道。没有 Eval你根本不知道 Agent 上线后会不会胡说八道。我搭建的评测体系包含四个维度准确性、完整性、安全性和效率。准确性看 Agent 回答的事实是否正确比如退货政策说 7 天无理由Agent 不能说 15 天。完整性看是否覆盖了用户问题的所有方面用户问“怎么退货和退款”Agent 不能只答退货不答退款。安全性看是否有违规承诺、敏感信息泄露、越权操作。效率看响应时间和工具调用次数客服场景下超过 3 秒的响应用户就会不耐烦。每个维度我都定义了具体的量化指标。准确性用人工标注的 500 条测试集计算准确率。完整性用“关键信息覆盖率”把标准答案拆成关键点看 Agent 回答覆盖了几个。安全性用规则引擎自动扫描命中敏感词或越权操作直接判负。效率用 P95 响应时间和平均工具调用次数。5.2 自动化评测流水线的搭建人工评测只能做抽样全量评测必须自动化。我的自动化评测流水线分三步用例生成、批量执行、结果分析。用例生成用“真实日志 合成数据”结合。从线上日志里抽取高频问题再用大模型合成变体比如把“怎么退货”变成“退货流程是什么”“我想退掉刚买的东西”。这样能覆盖更多表达方式。我目前维护了 2000 多条测试用例覆盖 30 多个意图。批量执行用脚本跑每个用例调用 Agent 接口记录完整对话轨迹、工具调用序列、最终回答。执行时要注意并发控制我设的是 10 并发太高了会触发限流太低了跑得慢。2000 条用例大概跑 15 分钟。结果分析用规则 模型结合。规则引擎先扫一遍把明显违规的挑出来。剩下的用 GPT-4 做评分给每个回答打 1-5 分同时给出扣分理由。最后生成评测报告按意图分类统计通过率找出薄弱环节。# 评测流水线核心逻辑示例 async def run_eval(cases, agent_endpoint, concurrency10): semaphore asyncio.Semaphore(concurrency) results [] async def eval_one(case): async with semaphore: response await call_agent(agent_endpoint, case[query]) score await score_response(case, response) return {case: case, response: response, score: score} tasks [eval_one(c) for c in cases] results await asyncio.gather(*tasks) return generate_report(results)5.3 评测驱动的迭代闭环Eval 最大的价值不是打分是驱动迭代。我每周跑一次全量评测把失败用例分类是知识库缺失、工具调用错误、还是模型理解偏差。然后针对性修复。知识库缺失就补文档工具调用错误就优化工具描述模型理解偏差就调整 prompt。修完再跑评测看通过率有没有提升。这个闭环跑上几轮Agent 的准确率能从初期的 60% 提到 90% 以上。避坑技巧评测集要定期更新。我一开始用固定的 500 条用例跑了三个月后发现通过率虚高因为 Agent 已经“背下”了这些用例。后来改成每月从线上日志抽 200 条新用例补充进去保持评测集的“新鲜度”。6. 48 关里的高频坑与排查手册6.1 工具调用类问题速查工具调用是客服 Agent 最容易出问题的地方。我整理了一张速查表覆盖了最常见的六种故障。问题现象可能原因排查方法解决方案模型不调用工具工具描述不清晰检查 description 是否说明使用场景补充“什么时候用”的描述调用参数错误参数格式未说明查看参数 description补充格式、取值范围、示例调用超时后端接口慢查看工具调用日志加超时降级优化后端重复调用无幂等设计检查是否有 idempotency_key加幂等键缓存结果返回结果太长未做摘要查看返回 token 数配置 summary_fields越权操作无权限校验检查 MCP Server 权限配置加 token 校验和审计日志这张表我贴在工位上出问题先对照排查80% 的情况能快速定位。6.2 RAG 检索类问题速查RAG 的问题更隐蔽因为检索结果不对模型可能仍然给出看似合理的回答。我的排查思路是先看检索结果再看模型回答。问题现象可能原因排查方法解决方案召回率低切片不合理检查 chunk 大小和 overlap调整切片参数专有名词检索不到纯向量检索测试关键词检索上混合检索 reranker返回过时信息知识库未更新检查版本号建立版本管理和灰度更新重复内容多overlap 太大查看 chunk 重叠率降低 overlap 到 50-80答案不完整top_k 太小检查检索返回条数增大 top_k 到 5-86.3 MCP 与 Eval 的联动排查MCP 和 Eval 的问题往往在联调阶段暴露。我的经验是先单独测 MCP Server再测 Agent 调用最后跑 Eval。不要跳过任何一步。单独测 MCP Server 用 curl 或 Postman 直接调接口确认返回格式正确。测 Agent 调用时开 debug 日志看 MCP Client 发的请求和收到的响应。跑 Eval 时重点关注工具调用序列看 Agent 是否按预期调用了正确的 MCP 工具。有一次我遇到 Agent 调用 MCP 工具总是返回空结果排查了半天发现是 MCP Server 的返回字段名跟 Tool 描述里的不一致。Server 返回order_statusTool 描述里写的是status模型按status去取取不到就以为没结果。这种问题只能靠联调发现所以 Eval 用例里一定要包含工具调用链路的验证。7. 从 48 关里提炼的六条硬核经验7.1 工具描述比工具实现更重要我花了最多时间的地方不是写工具代码是写工具描述。一个工具的实现可能就 50 行代码但描述我改了十几版。每改一版就跑一次评测看调用准确率有没有提升。最后稳定下来的描述模板是使用场景 参数说明 返回格式 调用示例。这个模板套用到任何工具上准确率都能到 90% 以上。7.2 RAG 的瓶颈在检索不在生成很多人把精力花在换更大的模型上但客服场景下模型能力早就过剩了。真正的瓶颈是检索。检索不准再强的模型也答不对。我的建议是把 70% 的优化精力放在检索上切片、向量模型、混合检索、reranker每个环节都值得反复调。生成环节用中等规模的模型就够了。7.3 MCP 要当基础设施来建MCP 不是“接一下就行”的东西要当基础设施来规划。我的做法是所有外部系统对接统一走 MCPMCP Server 独立部署、独立监控、独立扩缩容。Agent 端只负责调用不关心底层是哪个系统。这样新增系统时Agent 端零改动只需要部署一个新的 MCP Server。7.4 Eval 要自动化、常态化、闭环化Eval 不是上线前跑一次就完了。我现在的节奏是每天跑冒烟测试200 条核心用例每周跑全量评测2000 条每月更新评测集。评测结果直接同步到迭代看板失败用例自动创建修复任务。这个闭环跑起来后Agent 的质量是持续提升的不会因为知识库更新或 prompt 调整而退化。7.5 客服 Agent 的响应时间要卡死客服场景对响应时间极其敏感。我的硬性要求是P95 响应时间不超过 3 秒工具调用不超过 2 次。超过这个阈值用户体验直线下降。为了达标我做了几件事工具调用并行化、RAG 检索结果缓存、模型输出流式返回。流式返回特别重要用户看到字一个个蹦出来感知等待时间会短很多。7.6 人工兜底永远是最后一道防线不管 Agent 做得多好总会有搞不定的情况。我的设计里Agent 连续两次无法解决用户问题或者用户明确要求转人工就自动切人工客服。切换时把对话历史、已调用的工具、检索到的知识库内容一起传给人工坐席坐席不用重新问一遍。这个兜底机制让客诉率降低了 40% 以上。8. 后续可以继续深挖的几个方向这套客服 Agent 跑了大半年48 关基本都趟平了但还有几个方向我觉得值得继续挖。一个是Agentic RAG让 Agent 自己决定检索什么、检索几次而不是固定流程。另一个是多 Agent 协作把售前、售后、投诉处理拆成不同 Agent互相配合。还有Eval 的自动化用例生成用大模型从线上日志自动生成测试用例减少人工维护成本。MCP 这块也在持续演进未来如果支持了更细粒度的权限控制和更丰富的工具类型客服 Agent 能对接的系统会更多。我目前的做法是保持关注但生产环境不追新等协议稳定了再升级。毕竟客服系统稳定压倒一切不能拿线上用户当小白鼠。最后分享一个我踩过的最大的坑不要试图用 prompt 解决所有问题。我一开始什么逻辑都往 prompt 里塞结果 prompt 越来越长模型越来越糊涂。后来把逻辑下沉到代码层prompt 只负责意图理解和话术生成整个系统才稳定下来。Agent 开发的核心思路是能用代码写死的不要交给模型判断。模型只做它擅长的事剩下的交给工程。 客服Agent从Demo到生产：Tool、RAG、MCP、Eval 48个关键节点拆解
1. 从零拆解客服 Agent 的 48 关为什么 Tool、RAG、MCP、Eval 一个都不能少做客服 Agent 这件事我前前后后折腾了大半年踩过的坑比吃过的盐还多。一开始我以为客服 Agent 就是个“大模型套壳加个知识库”结果真上手才发现从最基础的 Tool 调用到 RAG 检索增强再到 MCP 协议接入和 Eval 评测体系每一层都有它存在的硬理由。这篇文章不聊虚的就把我趟过的 48 个关键节点拆开揉碎讲清楚适合正在做或准备做客服 Agent 的开发者、产品经理和技术负责人参考。不管你是刚接触 Agent 开发的新手还是已经踩过几轮坑的老手应该都能从里面找到对自己有用的东西。先说清楚这个标题里的几个核心概念。Agent在这里特指能自主决策、调用工具、完成多轮任务的智能体不是那种一问一答的简单机器人。Tool是 Agent 的手和脚让它能查订单、改地址、发工单。RAG是它的记忆外挂把企业知识库、FAQ、历史工单变成可检索的向量数据。MCP是模型上下文协议解决的是 Agent 跟外部系统怎么标准化对接的问题。Eval则是质检员没有它你根本不知道 Agent 到底行不行。这四个东西串起来才构成一个能上生产的客服 Agent。为什么是“48 关”因为从 Demo 到生产我数了数光是必须解决的独立问题就有四十多个。有些是技术架构层面的比如工具调用的幂等性设计有些是工程细节比如 RAG 切片时中文标点怎么处理还有些是业务逻辑比如用户情绪激动时 Agent 该不该继续走流程。每一关单独看都不难但叠在一起就是一座山。下面我按模块把这 48 关拆开把每个关键决策背后的“为什么”讲透。2. Tool 层Agent 的手脚怎么长才不出事2.1 工具注册与描述别让模型猜你的接口Tool 是客服 Agent 最先要搞定的东西。没有工具Agent 就是个只会聊天的废物。但工具怎么注册、怎么描述这里面门道很深。我见过太多人直接把后端 API 文档扔给模型结果模型调用成功率不到 60%。问题出在工具描述上。工具描述不是写给人看的 API 文档是写给模型看的“使用说明书”。每个工具的description字段必须包含三个要素什么时候用、参数怎么填、返回什么。举个例子查订单工具的描述不能只写“查询订单信息”要写成“根据用户提供的订单号或手机号查询订单状态、物流信息和预计送达时间。当用户询问订单进度、物流位置、是否发货时使用此工具。订单号格式为纯数字 12-18 位手机号为 11 位数字。”参数描述同样关键。每个参数的description要说明格式、取值范围、是否必填。我实测下来把参数描述写清楚后工具调用准确率能从 65% 提到 92% 左右。还有一个技巧给每个工具加examples字段用自然语言写两三个调用示例。模型看到示例后对参数的理解会准确很多。注意工具数量不要一次性全注册给模型。我试过把 30 多个工具全塞进 system prompt结果模型选择困难经常调错工具。后来改成按场景分组每次只暴露 5-8 个相关工具准确率明显回升。2.2 工具调用的幂等性与超时处理客服场景有个特点用户会重复问同一个问题。如果 Agent 每次调用查订单工具都去请求后端不仅浪费资源还可能因为网络抖动导致重复下单、重复发工单。所以工具调用必须做幂等。我的做法是在工具层加一个idempotency_key由 Agent 根据用户 ID 意图 时间窗口生成。同一个用户在同一分钟内查同一个订单直接返回缓存结果。这个 key 的生成逻辑要写进工具描述里让模型知道什么时候该复用。超时处理也是血泪教训。客服后端接口平均响应 200ms但高峰期可能到 2s。如果工具调用超时Agent 不能傻等要有降级策略。我的配置是单个工具调用超时 3s超时后返回“系统繁忙请稍后重试”的友好提示同时记录日志。如果连续两次超时Agent 自动切换到人工客服入口。这个逻辑用代码写死在工具调用层不依赖模型判断。# 工具调用超时与降级示例 import asyncio from functools import wraps def tool_timeout(seconds3): def decorator(func): wraps(func) async def wrapper(*args, **kwargs): try: return await asyncio.wait_for(func(*args, **kwargs), timeoutseconds) except asyncio.TimeoutError: return {error: timeout, message: 系统繁忙请稍后重试} return wrapper return decorator2.3 工具返回结果的格式化与截断工具返回的数据往往很长比如订单详情可能包含几十个字段。如果全塞给模型不仅浪费 token还会干扰模型判断。我的经验是工具返回结果要做“摘要化”处理。具体做法是定义一个summary_fields配置每个工具指定哪些字段需要返回给模型。比如查订单工具只返回订单号、状态、物流公司、运单号、预计送达时间这五个字段。其他字段存在上下文里需要时再通过二次工具调用获取。这样能把单次工具调用的 token 消耗降低 70% 以上。还有一个细节返回结果里的敏感信息要脱敏。手机号中间四位打码地址只保留到城市级别。这个在工具层做不要指望模型自己脱敏模型有时候会“忘记”。3. RAG 层知识库不是扔进去就完事3.1 中文文档切片的三个关键参数RAG 是客服 Agent 的知识底座。但很多人做 RAG 就是“文档扔进去、向量化、检索”结果召回率惨不忍睹。问题八成出在切片上。中文文档切片跟英文完全不一样英文按空格和句号切就行中文得考虑标点和语义。我试过三种切片策略最后稳定用的是“按标点切 语义合并”。具体参数是chunk_size500字符chunk_overlap80字符分隔符优先级是[\n\n, \n, 。, , , , ]。为什么是 500因为中文 500 字大约对应 300-400 个 token加上 overlap 后总长度在模型上下文窗口的舒适区。太小了语义不完整太大了检索精度下降。chunk_overlap设 80 是为了保证跨 chunk 的语义连续性。比如一个问题的答案跨了两个段落overlap 能让两个 chunk 都包含部分答案检索时至少有一个能命中。这个值不要设太大否则冗余严重检索时会返回大量重复内容。实操心得切片前一定要做文本清洗。把 PDF 里的换行符、页眉页脚、乱码全去掉。我见过最离谱的案例是 PDF 每行都有个“第 X 页”切片后每个 chunk 都带着这玩意儿检索时全是噪声。3.2 向量模型选型与混合检索向量模型的选择直接决定 RAG 的上限。我对比过七八个模型最后在客服场景下稳定用的是bge-large-zh-v1.5做向量化bge-reranker-large做重排序。为什么不用 OpenAI 的 embedding因为客服数据涉及企业隐私本地部署更稳妥而且中文场景下 bge 系列的表现确实更好。但纯向量检索有个致命问题对专有名词和数字不敏感。用户问“订单号 123456 的物流”向量检索可能返回一堆无关的物流政策文档。所以必须上混合检索向量检索 关键词检索BM25两路结果合并后再用 reranker 精排。我的配置是向量检索取 top 20BM25 取 top 20合并去重后大概 30-35 条再用 reranker 取 top 5 送给模型。这个流程下来召回率能从纯向量的 72% 提到 91% 左右。reranker 的阈值设 0.3低于这个分数的直接丢弃避免噪声干扰。3.3 RAG 知识库的更新与版本管理知识库不是建好就完了客服话术、产品政策、活动规则天天在变。如果知识库更新不及时Agent 就会给出过时答案这比不回答还糟糕。我的做法是给知识库加版本号每次更新生成一个新版本检索时默认用最新版本但保留历史版本用于回滚。更新流程是运营在后台提交新文档 - 自动切片向量化 - 生成新版本 - 灰度 10% 流量测试 - 观察 24 小时无异常 - 全量切换。这个流程看起来麻烦但能避免“更新后 Agent 突然变傻”的事故。我踩过一次坑运营把一份旧版退货政策传上去覆盖了新版结果当天退货咨询全部答错客诉率飙升。从那以后版本管理就成了硬性要求。4. MCP 层标准化对接的利与坑4.1 MCP 到底解决了什么问题MCP 全称 Model Context Protocol翻译过来叫模型上下文协议。它解决的核心问题是Agent 跟外部系统对接时不用每个系统都写一套适配代码。没有 MCP 之前我接一个 CRM 系统要写一套工具接一个工单系统又要写一套代码重复率极高。有了 MCP只要外部系统实现了 MCP ServerAgent 就能通过标准协议直接调用。在客服场景里MCP 的价值特别明显。客服 Agent 通常要对接订单系统、物流系统、会员系统、工单系统、知识库系统。如果每个都自己写工具维护成本巨大。用 MCP 之后这些系统只要暴露标准的 MCP 接口Agent 端统一用 MCP Client 调用新增系统只需要配置一下不用改代码。但 MCP 也不是银弹。我实际用下来最大的坑是协议版本兼容性。MCP 还在快速迭代不同版本的 Server 和 Client 之间可能有字段差异。我的建议是锁定一个稳定版本所有 Server 和 Client 统一版本号升级时一起升。不要混用版本否则会出现“工具列表能拉到但调用报错”的诡异问题。4.2 MCP Server 的部署与安全配置MCP Server 的部署方式直接影响 Agent 的稳定性。我试过三种部署模式本地进程、容器化、远程服务。最后生产环境用的是容器化部署每个 MCP Server 一个独立容器通过内部网络通信。为什么不用本地进程因为本地进程跟 Agent 耦合太紧一个 Server 崩溃可能拖垮整个 Agent。容器化之后每个 Server 有独立的资源限制和健康检查崩了自动重启不影响其他 Server。远程服务模式延迟太高客服场景对响应时间敏感超过 500ms 用户就能感知到卡顿所以不推荐。安全配置是 MCP 最容易忽视的地方。MCP Server 暴露的工具可能涉及敏感操作比如修改订单、退款、发工单。我的做法是所有写操作工具必须加权限校验。MCP Client 调用时带上用户身份 tokenServer 端校验 token 是否有权限执行该操作。没有权限的直接返回 403Agent 收到后转人工处理。// MCP Server 权限配置示例 { tool: update_order_address, required_permission: order:write, rate_limit: 10/minute, audit_log: true }4.3 MCP 与 Tool 的关系不是替代是互补很多人问有了 MCP 还需要 Tool 吗我的答案是两者互补不是替代关系。MCP 解决的是“怎么标准化对接外部系统”Tool 解决的是“Agent 怎么理解和使用这些能力”。具体来说MCP Server 提供的是原始能力接口比如query_order、update_address。但这些接口对模型来说太底层了模型不知道什么时候该调、参数怎么填。所以还需要在 Agent 层定义 Tool把 MCP 接口包装成模型能理解的工具描述。Tool 的description和参数说明还是得写只是底层实现从“直接调 API”变成了“通过 MCP Client 调 MCP Server”。这个分层的好处是MCP 层可以复用同一个 MCP Server 可以被多个 Agent 使用Tool 层可以定制不同 Agent 对同一个 MCP 接口可以有不同描述和参数映射。我现在的架构就是 MCP 层统一对接所有外部系统Tool 层按业务场景定义两层之间用适配器模式连接。5. Eval 层没有评测的 Agent 就是盲盒5.1 客服 Agent 的评测指标体系Eval 是客服 Agent 从 Demo 到生产的最后一道关也是最重要的一道。没有 Eval你根本不知道 Agent 上线后会不会胡说八道。我搭建的评测体系包含四个维度准确性、完整性、安全性和效率。准确性看 Agent 回答的事实是否正确比如退货政策说 7 天无理由Agent 不能说 15 天。完整性看是否覆盖了用户问题的所有方面用户问“怎么退货和退款”Agent 不能只答退货不答退款。安全性看是否有违规承诺、敏感信息泄露、越权操作。效率看响应时间和工具调用次数客服场景下超过 3 秒的响应用户就会不耐烦。每个维度我都定义了具体的量化指标。准确性用人工标注的 500 条测试集计算准确率。完整性用“关键信息覆盖率”把标准答案拆成关键点看 Agent 回答覆盖了几个。安全性用规则引擎自动扫描命中敏感词或越权操作直接判负。效率用 P95 响应时间和平均工具调用次数。5.2 自动化评测流水线的搭建人工评测只能做抽样全量评测必须自动化。我的自动化评测流水线分三步用例生成、批量执行、结果分析。用例生成用“真实日志 合成数据”结合。从线上日志里抽取高频问题再用大模型合成变体比如把“怎么退货”变成“退货流程是什么”“我想退掉刚买的东西”。这样能覆盖更多表达方式。我目前维护了 2000 多条测试用例覆盖 30 多个意图。批量执行用脚本跑每个用例调用 Agent 接口记录完整对话轨迹、工具调用序列、最终回答。执行时要注意并发控制我设的是 10 并发太高了会触发限流太低了跑得慢。2000 条用例大概跑 15 分钟。结果分析用规则 模型结合。规则引擎先扫一遍把明显违规的挑出来。剩下的用 GPT-4 做评分给每个回答打 1-5 分同时给出扣分理由。最后生成评测报告按意图分类统计通过率找出薄弱环节。# 评测流水线核心逻辑示例 async def run_eval(cases, agent_endpoint, concurrency10): semaphore asyncio.Semaphore(concurrency) results [] async def eval_one(case): async with semaphore: response await call_agent(agent_endpoint, case[query]) score await score_response(case, response) return {case: case, response: response, score: score} tasks [eval_one(c) for c in cases] results await asyncio.gather(*tasks) return generate_report(results)5.3 评测驱动的迭代闭环Eval 最大的价值不是打分是驱动迭代。我每周跑一次全量评测把失败用例分类是知识库缺失、工具调用错误、还是模型理解偏差。然后针对性修复。知识库缺失就补文档工具调用错误就优化工具描述模型理解偏差就调整 prompt。修完再跑评测看通过率有没有提升。这个闭环跑上几轮Agent 的准确率能从初期的 60% 提到 90% 以上。避坑技巧评测集要定期更新。我一开始用固定的 500 条用例跑了三个月后发现通过率虚高因为 Agent 已经“背下”了这些用例。后来改成每月从线上日志抽 200 条新用例补充进去保持评测集的“新鲜度”。6. 48 关里的高频坑与排查手册6.1 工具调用类问题速查工具调用是客服 Agent 最容易出问题的地方。我整理了一张速查表覆盖了最常见的六种故障。问题现象可能原因排查方法解决方案模型不调用工具工具描述不清晰检查 description 是否说明使用场景补充“什么时候用”的描述调用参数错误参数格式未说明查看参数 description补充格式、取值范围、示例调用超时后端接口慢查看工具调用日志加超时降级优化后端重复调用无幂等设计检查是否有 idempotency_key加幂等键缓存结果返回结果太长未做摘要查看返回 token 数配置 summary_fields越权操作无权限校验检查 MCP Server 权限配置加 token 校验和审计日志这张表我贴在工位上出问题先对照排查80% 的情况能快速定位。6.2 RAG 检索类问题速查RAG 的问题更隐蔽因为检索结果不对模型可能仍然给出看似合理的回答。我的排查思路是先看检索结果再看模型回答。问题现象可能原因排查方法解决方案召回率低切片不合理检查 chunk 大小和 overlap调整切片参数专有名词检索不到纯向量检索测试关键词检索上混合检索 reranker返回过时信息知识库未更新检查版本号建立版本管理和灰度更新重复内容多overlap 太大查看 chunk 重叠率降低 overlap 到 50-80答案不完整top_k 太小检查检索返回条数增大 top_k 到 5-86.3 MCP 与 Eval 的联动排查MCP 和 Eval 的问题往往在联调阶段暴露。我的经验是先单独测 MCP Server再测 Agent 调用最后跑 Eval。不要跳过任何一步。单独测 MCP Server 用 curl 或 Postman 直接调接口确认返回格式正确。测 Agent 调用时开 debug 日志看 MCP Client 发的请求和收到的响应。跑 Eval 时重点关注工具调用序列看 Agent 是否按预期调用了正确的 MCP 工具。有一次我遇到 Agent 调用 MCP 工具总是返回空结果排查了半天发现是 MCP Server 的返回字段名跟 Tool 描述里的不一致。Server 返回order_statusTool 描述里写的是status模型按status去取取不到就以为没结果。这种问题只能靠联调发现所以 Eval 用例里一定要包含工具调用链路的验证。7. 从 48 关里提炼的六条硬核经验7.1 工具描述比工具实现更重要我花了最多时间的地方不是写工具代码是写工具描述。一个工具的实现可能就 50 行代码但描述我改了十几版。每改一版就跑一次评测看调用准确率有没有提升。最后稳定下来的描述模板是使用场景 参数说明 返回格式 调用示例。这个模板套用到任何工具上准确率都能到 90% 以上。7.2 RAG 的瓶颈在检索不在生成很多人把精力花在换更大的模型上但客服场景下模型能力早就过剩了。真正的瓶颈是检索。检索不准再强的模型也答不对。我的建议是把 70% 的优化精力放在检索上切片、向量模型、混合检索、reranker每个环节都值得反复调。生成环节用中等规模的模型就够了。7.3 MCP 要当基础设施来建MCP 不是“接一下就行”的东西要当基础设施来规划。我的做法是所有外部系统对接统一走 MCPMCP Server 独立部署、独立监控、独立扩缩容。Agent 端只负责调用不关心底层是哪个系统。这样新增系统时Agent 端零改动只需要部署一个新的 MCP Server。7.4 Eval 要自动化、常态化、闭环化Eval 不是上线前跑一次就完了。我现在的节奏是每天跑冒烟测试200 条核心用例每周跑全量评测2000 条每月更新评测集。评测结果直接同步到迭代看板失败用例自动创建修复任务。这个闭环跑起来后Agent 的质量是持续提升的不会因为知识库更新或 prompt 调整而退化。7.5 客服 Agent 的响应时间要卡死客服场景对响应时间极其敏感。我的硬性要求是P95 响应时间不超过 3 秒工具调用不超过 2 次。超过这个阈值用户体验直线下降。为了达标我做了几件事工具调用并行化、RAG 检索结果缓存、模型输出流式返回。流式返回特别重要用户看到字一个个蹦出来感知等待时间会短很多。7.6 人工兜底永远是最后一道防线不管 Agent 做得多好总会有搞不定的情况。我的设计里Agent 连续两次无法解决用户问题或者用户明确要求转人工就自动切人工客服。切换时把对话历史、已调用的工具、检索到的知识库内容一起传给人工坐席坐席不用重新问一遍。这个兜底机制让客诉率降低了 40% 以上。8. 后续可以继续深挖的几个方向这套客服 Agent 跑了大半年48 关基本都趟平了但还有几个方向我觉得值得继续挖。一个是Agentic RAG让 Agent 自己决定检索什么、检索几次而不是固定流程。另一个是多 Agent 协作把售前、售后、投诉处理拆成不同 Agent互相配合。还有Eval 的自动化用例生成用大模型从线上日志自动生成测试用例减少人工维护成本。MCP 这块也在持续演进未来如果支持了更细粒度的权限控制和更丰富的工具类型客服 Agent 能对接的系统会更多。我目前的做法是保持关注但生产环境不追新等协议稳定了再升级。毕竟客服系统稳定压倒一切不能拿线上用户当小白鼠。最后分享一个我踩过的最大的坑不要试图用 prompt 解决所有问题。我一开始什么逻辑都往 prompt 里塞结果 prompt 越来越长模型越来越糊涂。后来把逻辑下沉到代码层prompt 只负责意图理解和话术生成整个系统才稳定下来。Agent 开发的核心思路是能用代码写死的不要交给模型判断。模型只做它擅长的事剩下的交给工程。