如何把客服 Agent 准确率做到 98%+

项目经历

2025 年 1 月至今，深流 AI 已交付数十个头部客户的客服 Agent，准确率 98% 以上，高于原人工客服团队。每个项目都经历了“山重水复疑无路，柳暗花明又一村”的心路历程，也旁观了同期多家自研项目失败。

分享 5 条客服 Agent 的“反共识”经验。

经验 1：第一性原理 ＞ 一切开源框架

无需迷信 Dify / Coze / LangChain！

这些产品大多以 Agent 早期某些学术思想、学术 Demo 为目标构建系统。

学术 Demo ≠ 企业生产。

深流 AI 第一性公式：

准确率 = 输入质量 × 模型能力 × 透明管道

输入质量 = 完整 + 准确 + 易理解，缺一不可。

Agent 产品就是围绕着 LLM 调用构建透明的信息管道，以便全流程检查信息、迭代信息。

很多企业会使用 Dify 之类的产品作为基础来自研 Agent，不敢动手改底层，只在画布提供的配置空间里操作。Dify 类产品在客服场景有很大的局限性，需要基于第一性原理大胆改造，才能解决很多问题。

想一想，你的 Agent 有多少配置是基于低代码 Agent 平台的限制，“不得不”“只能这样”配的？

深流 AI 一开始就选择了基于客服需求原创自研 Agent，实践下来效果不错。

经验 2：架构简单，技术深入

在 10 个文档中召回不准，怎么做？

• A 方案（99% 团队选择）：LLM 先分类 → 再小范围召回，画布两分钟拖完。
• B 方案：深入研究召回的底层技术，对症下药，解决 10 个文档中的召回问题。

忍住 A 方案的诱惑，选择 B 方案。

A 方案的问题

1. 增加一次 LLM 调用，增加响应时间。
2. 分类的文本描述是分类的不完备信息，引入新的不确定性。
3. 解决方案难以泛化。

B 方案的优势

1. 召回问题用召回解决，对症下药，不增加架构复杂性，保持原架构的简洁性。
2. 解决当前问题的同时，整体性地提升召回能力。

对于 Agent 各模块，产研人员都要具备深入底层研究改造的能力。

“Low-code” 不是 “low-tech”，越少节点，才能逼自己把每个节点做深。

不要让 Agent 画布上有几百个节点，变得不可维护、不敢维护。

经验 3：用好 ES

向量数据库自带的 BM25 ≈“玩具版”搜索。

深流做法：使用 ES（Elasticsearch）来做 BM25 搜索，利用 ES 非常强大的搜索能力，持续迭代优化，构建出一套适合切片的搜索方案。

Agent 产品经理也应该熟悉 ES 的各种参数、各种搜索优化技巧。

经验 4：AI 时代要勇于人工

再强的模型也救不了脏数据。

要确保输入 LLM 的信息是完整的、准确的、易于理解的。面对很多杂乱的文档、表格、文件，很多时候，当下最前沿的技术也无能为力。

是等待 AGI 实现，还是现在投入人工处理、校对，获得高质量的数据？

深流 AI 向客户提供的服务，很重要的一块是数据处理服务。确实是苦活累活，也确实是实现高准确性 Agent 客服的必备。

不要相信 0 人工、免训练的 Agent。

经验 5：组织重构

传统瀑布流：需求 → 排期 → 开发 → 交付，不适合现在的 Agent 产品。

Agent 产品目前没有成熟的方法论和最佳实践，企业内的研发团队没办法在限定的时间完成任务。限定了时间，实际操作中往往是采用现成的、但不适合的框架快速开发上线，然后有问题就只能得到“大模型就这样的”的回答。

深流 AI 构建了研究型组织架构，走难而正确的路，在挑战中创新，在交付项目中积累了大量的客服 Agent know-how，然后面向客户提供端到端的、从知识到会话的服务。