你以为 Agent 能干活了？其实差了 100 步：医疗器械售后 Agent 生产化实战
导语
大量客户对 Agent 的印象都停留在“用不起来”。能不能用起来——是衡量企业级 Agent 落地的标准。本文结合 M 医疗项目的实践案例，拆解在医疗器械行业，ADP FDE 如何通过售后服务 AI 助手，实现客户年 60%+ 的工单拦截率；并以此为契口，让客户从“单一场景 Agent”延伸到“300+ Agent”，形成多业务应用场景的 AI 平台底座。
当前，Agent 几乎无所不能。“我们这个 Agent 已经差不多能用了。”很多项目在 PoC 阶段都会给出类似判断。但一到真实业务现场，问题马上变得具体：准确率只有 60% 左右，型号容易串，答案缺少引用，遇到边界问题不会拒答，业务吐槽答非所问。客户项目组仍然不敢直接拿来服务客户。
久而久之，客户的 AI 平台从“深度落地”变成“深度落灰”。
医疗器械售后服务，就是企业级 AI 最典型的深水区之一。这里既有庞大的设备装机规模，也有严格的设备安全和服务合规要求；既有海量文档、相似型号和频繁版本更新，也有依赖专业经验的故障诊断。大量客户的售后 AI 客服形同虚设，医疗器械更是难啃的硬骨头。
在 M 项目中，我们先从售后客服的场景出发，接入客户 86 万份知识库，通过标签过滤、多路检索、元数据等多重方案，为 M 项目建立生产级售后 AI 服务助手。一期上线后反响不错，营销业务口学习交流，促成二期；同时，内部 AI 创新也如火如荼，ADP 逐步覆盖成客户必备的 AI Agent 底座。
一、为什么医疗器械售后是企业级 Agent 的深水区？
售后场景太普遍了。看起来就是一个简单的问答场景：工程师问故障怎么处理，系统给出答案。但真实难点并不在“回答”，是在“怎么结合庞大且复杂的业务知识，在海量知识库里找到正确无误且可追溯的答案”。
以 M 项目为例，客户的产品应用已覆盖到全球 190 多个国家，服务国内近 11 万家医疗机构和 99% 以上的三甲医院。庞大的装机规模背后，是大体量售后资料、复杂产品型号、频繁文档更新和多角色协作网络。
在客户需要推送到 AI 的知识库里，所有文档约 400G，覆盖 500 多个机型，10 余种文件格式。日常的售后咨询回复，极度依赖原厂产品研发专家，每个产线都需要安排专门的人员参与用户服务解答。
由此，真正让 AI 替代售后客户服务业务，成了客户切实的刚需。但实际落地推进时，我们遇到了五个难题：
- 知识资产庞杂、检索太耗时。 数十万份资料，服务手册、技术通知、软件包、案例库、培训资料等等，散落在多个平台、格式多样，难以统一维护和查找，口径不一。传统关键词检索往往返回 160 多条候选，仍需一线人员人工判断，导致大量本可自主解决的问题因信息难获取而转人工。
- 产品型号太相近。 众多产品型号、工艺代号是一串长长的编码，不仅长，还非常接近，差异可能仅在少数字符。对于通用模型的解析而言，怎么切分都是个问题，要识别很困难，极容易混淆。
- 产品型号、工艺代号关系复杂。 工艺代号与型号并不是一对多匹配的，而是“一个代号对应多个型号、一个型号对应多个代号”的多对多关系，对代号提问时，型号非常容易错误匹配。
- 版本更新频繁。 医疗器械维保需要使用最新有效资料，问答也是必须按最新版本检索。依据过期资料维修，还是可能导致操作错误或合规风险。
- 多权限、多语种。 不同员工的角色对应不同知识库检索和回答范围。且海外部门多，query 可能是葡萄牙语、西班牙语、英语、中文等多种语言。
- 通用 AI 的幻觉不可接受。 Agent 不只是对内，同样会对客使用，答案的错误会直接影响服务质量、设备安全和客户信任。
二、一期 FDE 的实现路径：我们做了什么？
传统的 FDE 有很强的“人力服务”属性。我们在交付中，尽量摈弃项目通用的定制大法，将企业智能体围绕客户真实业务场景展开，从概念验证推进到生产运行，不只是关心模型效果，也关心常用的知识工程、运营闭环、客户赋能工具沉淀和反哺产品能力。
我们围绕“知识库梳理清洗—知识对接—ADP 检索能力—技术调优—上线治理”五个环节展开，产品能力与交付套件协同推进，确保知识真正进入应用并持续产生高频使用。
具体来说，我们在项目中解决五件事情：
2.1 清洗多源知识，搭建标签体系
项目首先对两类核心知识库进行盘点和梳理：
第一种，技术资料库：服务手册、招标版物料清单、软件包、用户手册、推荐库存清单、技术通知、历史技术通知、视频、案例库和培训资料等。特点是资料规模大、格式多。
第二种，诊断知识库：诊断处理方案、套餐类型，特点是结构化知识，具有明确的树状分类和字段结构。
在 AI Infra 层，项目对知识执行知识清洗、结构统一，并进行标签化、去重、命名规范，再汇入 ADP 统一知识库。其中技术信息服务主库文档超过 2 万份，综合知识库单库超过 1 万份，服务手册库超过 80 万份，并按产品线、机型和问题分类建立多级检索维度。
想要每次 query 都在 86 万份材料里轮循一遍，实现秒级应答几乎不可能，第一个策略便是化整为零，缩小检索范围，结构化检索。有序的知识是 AI 可用的第一步。
2.2 知识同步与标签传递，建立可管理的知识底座
客户知识来自多个生产系统和业务流程。项目上将 ADP 知识库作为知识库检索平台，打通承接客户 PLM 数字工程、Portal 发布资料、手动上传资料和 ECR/用服流程等多个渠道，并构建统一标签体系。基于此，让新增资料、变更资料、流程产物能够持续进入检索体系，形成可管理的知识底座。
进入 ADP 前，资料会经过清洗、结构化和标签化处理，并传递产品线、机型大类、型号、工艺代号、市场定位等标签，避免不同产品范围的资料相互干扰。这套机制连接了知识生产系统与知识消费应用，使新增和变更资料持续进入检索体系。
对于型号密集的医疗器械行业，标签传递直接决定 AI 会不会避免跨产品线、跨机型串线。
2.3 元数据过滤解决相似型号串线
我们测试发现，原有出现的 badcase 中，10% 以上的问题都是因为型号太过接近，导致不同产品线或机型串线，相似型号对应切片被错误召回。针对型号密集、名称相似的特点，方案上先通过用户交互和隐藏参数，比如问题类别、机器型号、产品线、工艺大类、工艺代号、市场定位（国内/外），将 86 万份材料进行范围缩小和材料类型定位，大幅缩减了检索耗时和召回型号混淆的现象。
基于此，产品上也探索了元数据方案，通过 query 提取关键词，并定位切片对应文档的元数据，比如标签、产品编码、分类、文档标题等内容，将这些信息作为元数据参与检索。元数据从查询中提取并参与召回与排序。
此外，时间戳也可以作为元数据参与排序，同时能解决前期困扰客户的文档版本新旧的时效性问题。该机制把型号识别从模型的模糊判断转化为“实体抽取—元数据匹配—范围过滤—结果精排”的可控链路。
2.4 RAG 调优 + 技术迭代
客户资料横跨十几种文档类型，单一路径检索很难覆盖所有问题。ADP 采用多路混合召回——将用户问题分发到向量召回、问答召回、拒答召回、图片召回、文本跨模态召回、Text2SQL 等不同链路。各路结果经过 Merge、RRF 融合、Rerank、合并排序、去重、小找大合并、大 TopN 向量补召，最终输出带参考来源片段的回复。
ADP 产品也已同步推进上线了 Agentic RAG，并完成了与工作流的结合。Agentic RAG 在原 RAG 基础上增加了 Agent 的链式推理，在非结构化知识库结构化拉取数据，并进行交叉验证和决策。与前期方案融合后，检索效果相比之前有明显提升。
即便如此，产品实际落地也离不开为客户进行定向的 badcase 分析和调优。ADP 专门沉淀了运营排查系统和 badcase 分析工具，也规划上线 ADP ALHF（Agent Learning from Human Feedback），让应用调优能自我学习、生效和改进，形成 Agent-业务的进化闭环。
2.5 上线运营：授人以渔，联合客户共同成功
M 项目的售后用服助手，不是上线就完成了，而是从上线那天才真正开始运营飞轮。项目采用小范围灰度验证，每次对话的点赞、点踩、转人工、引用命中和问题闭环情况，都会进入客户与 ADP FDE 的 badcase 分析链路。
ADP 运营团队同步赋能客户服务团队，按照“问题收集—针对性归因—模型与 RAG 精调—回归验证—语料沉淀”的方式持续迭代：对知识缺失问题补充资料和标准答案；对切片或召回问题调整切片、关键词、RRF、Rerank 与图谱权重；对型号和业务规则问题补充元数据及映射关系；对表达与边界问题优化提示词、拒答清单和人工接管策略。
此外，客户项目组也联合业务侧共同参与 badcase 解析和优化，高频 badcase 会纳入 3 天闭环的考核机制，跟踪直到验证通过。
每一轮调优都会沉淀为标准答案、测试集、知识标签、提示词模板、流程规则和治理方法，为后续场景复用提供资产。
三、客户感知怎么样？
“收益是非常明显的”——这是客户的原话。
“一期的效果不错，我们也来学习交流下”——一期团队给其他业务团队的培训交流。
项目一期上线后，客户已将各个应用接入到客户外部服务小程序、工单系统、Web 和内部工作台，覆盖从内部员工（售后工程师、客服、渠道、运维人员）到代理商，以及客户（医院）等各层级用户。
整体使用情况上，早期自建的几个 Agent 版本，准确率约在 60%，一轮上线时在 83% 左右，运行调优后达到 93% 以上。检索响应从人工查找的 10—30 分钟缩短至秒级。
当前单场景总会话量 3 万+ 次/月，其中工单系统相关服务占约 80%。AI 工单处理量占全工单比例 60%。也就是说，即使不考虑团队资源整合，售后 AI 助手至少节省了原工单投入 60% 的人力。
团队资源上，过往各产线都有专门投入在售后的产研人员，此次交付后，产线的专家人力上实现了大批量释放；过往无法承接专业咨询任务的外部人员、新员工，通过售后服务助手，可以快速进行标准化服务。不论是业务团队还是服务团队，不仅资源实现了高效产能整合，业务能力也有突飞猛进的提升。业务侧积极性被极大激发，非常乐意进行自发的数据飞轮，并将点赞点踩的闭环率纳入业务考量，大大提升团队参与度。业务团队对点赞、点踩和闭环率的参与，又反过来提升了数据质量和 Agent 的可用性。
此外，项目逐步实现以点带面。营销业务侧主动跟一期团队进行交流学习，并自发整合营销培训、产品说明、售前、海报等业务材料，加速启动二期营销服务助手项目。
用户服务侧也以售后 AI 助手为切入点，拓展至 ITR、LTC、PLM、数据分析等多个场景，内部创新探索已达 300 多个智能体。客户内部也在推行创新比赛，以成功项目为牵引，鼓励员工在更多场景上 ADP Agent，逐步形成企业级 AI 平台和 AI 生态。
四、项目价值：我们收获了什么？
这次落地带来的价值，一方面，在知识库检索的落地应用场景上，我们有了实打实的可复制的项目案例和交付范式；另一方面，项目趟过的难题，也反哺到了 ADP 的产品演进与交付体系，沉淀到了产品和交付能力上。
在产品能力上，ADP 沉淀了元数据检索增强、复杂实体关系映射、时效性检索、AHLF 闭环优化、检索配置等能力，使复杂售后知识能够分层检索、精准召回和持续优化。
在交付体系上，项目暴露并沉淀了大量知识库交付工具需求，包括知识清洗工具、调优工具、切分工具、评测工具、测试集管理、badcase 运营、建库运营等。这些工具化能力会反向降低同类项目的交付人力投入，让后续行业复制不再从零开始。
toB FDE 耕耘的长期价值，来自真实业务中的持续使用。每一次问题、反馈、转人工和工单闭环，都会成为知识与产品优化的输入；每一个成熟场景，又会为下一个场景提供可复用的知识框架、流程组件和治理标准。
五、不仅仅是医疗器械行业……
医疗器械只是一个典型样本。消费医疗、医药流通，乃至工业设备、智能终端、冷链物流等行业，也普遍存在这几个典型特征：产品复杂、型号众多、知识量大、错误答案成本高。只要售后服务高度依赖知识检索、专家经验，就具备用 ADP 产品 + ADP FDE 进行生产化落地的场景。
对产品而言，产品能力、交付工具得到反哺沉淀；对于客户而言，有实际的案例、效果、交付路径可以借鉴，客户知识可以形成资产，专家能力能够实现复用，团队对外实力能大幅提升。这是共赢的合作策略。
我们非常期待在各个行业，ADP FDE 都可以帮助企业，完成从单一场景到多场景规模化落地，直至企业级 AI 平台的升级跃迁。
