• LLM 智能客服案例
  • 行业现状
  • 案例
    • 总结
    • 【2025-9-*】微软 customer-chatbot-solution-accelerator
    • 【2025-9-*】customer-service-ai-agent
    • 【2026-4-24】OpenAI 客服智能体
    • Shopify
      • 销售助手-RepAI
    • 瓴羊
    • 微众银行 AI Agent
    • Cognigy
    • Coze
    • Bland AI 热线
    • 容联七陌
      • 传统客服问题
      • 大模型客服
      • Agent 架构
      • 机器 or 人工 ?
      • 人机协同模式
    • 阿里店小蜜
    • 微软外呼机器人
• 结束

LLM 智能客服案例

智能客服背景知识详见转内专题 智能客服

行业现状

智能客服业界落地案例：

• 2023年3月，电商saas服务商Shopify集成ChatGPT
• 2023年12月，成立于2014年的Kore.ai完成1.5亿D轮融资，估值8亿
• 2023年底，德国创业公司Cognigy AI推出AI Copilot，用llm重新定义企业Agent协助，rise联络中心，AI改造传统客服；2024年6月，融资1亿美金
• 2023年成立的Bland AI 支持语音克隆、多语言支持、无限呼叫
• 国内，阿里小蜜已完成llm全方位升级重构，传统nlu+fsm方案退出
• sierra 融资较多

【2024-5-14】2024中国“大模型+智能客服”最佳实践案例TOP10重磅发布

【2024-6-27】Kore.ai：LLM能否为AI客服带来新一轮洗牌与机遇

【2023-6-30】AIGC 重构后的智能客服，能否淘到大模型时代的第一桶金

以 ChatGPT 为代表的大模型已经在许多企业中用于智能客服应用。它通过自动回答常见问题、解决简单问题和提供基本支持，减轻人工客服的负担。大语言模型通过深度学习和大量的语言数据训练，能够理解和生成人类语言，使得用户能够以自然的方式与它交互。在一些常见的客户查询和问题解答方面，这类大模型已经取得了相当不错的效果。

然而，当前大语言模型在实际应用于智能客服场景中时仍存在一些挑战

• 可能会生成错误或不准确的回答，尤其是对于复杂问题或领域特定知识，这就对智能化程度提出了更高的要求。未来的在线客服系不仅需要更高级的算法和机器学习技术，还需要更多精准的自然语言处理能力。这将对在技术上不太强大的企业形成巨大的压力。
• 随着用户数量和访客量的增多，未来智能客服将需要处理超大规模并发请求。这需要系统在多种方面都拥有特殊的设计，如负载均衡、高可扩展性和高可用性等。

市面上很多对话机器人，回答单一固定，变化比较少，与真实的人与人对话还有差距，未来的智能客服系统将需要进一步加强对用户行为的自适应性和个性化服务。这就需要系统学习更多的用户数据和信息，并适应不同的用户行为，为他们提供更好的服务和体验。

如何提升用户体验就成为了智能客服供应商主攻的方向。具体来讲，主要应从人性化服务、个性化服务和拟人化的对话交互方面进行改进。

• 首先是人性化服务。在场景和意图理解精准的基础上，附加更有温度的对话语境，可以让机器人在拟人化上，再进一步。
  • 多模态情感计算是实现这一步的有效方法。目前正在推进虚拟数字人客服进行人机交互对话，在此过程中结合情感计算，可识别用户通过视频、语音、文本所传递的情感表达，让智能客服在应对是作出相应情感反馈，打造具有情感理解、有温度的人机交互。这种多模态情感计算技术的实现方法主要是通过基于专家规则和基于机器学习两种。其中，基于机器学习的方法通过训练模型来自动学习情感状态的分类标准，可以更好地适应不同领域、不同语境下的情感表达，效果相对更优些。
• 其次是拟人化的对话型交互。
  • 通过场景化设计优化，比如问题拆解、主题继承、多轮对话、上下文理解等等，机器人能够带来一种更加贴近自然对话场景的对话型交互模式。
• 第三是个性化服务。
  • 根据客户画像千人千面提供个性化服务，从多角度出发进行语义理解，此外还要附加语音情绪判别。

大模型诞生后，无疑为智能客服领域注入了新的“营养剂”。这种“革新”体现在多个方面，包括座席辅助和座席提效、闲聊寒暄、话术优化建议、提供语料扩写等。

• 座席辅助和座席提效：过去的智能辅助更多局限于按单轮对话来完成，基于大模型的能力能够快速分析并生成面向客户侧的系统支撑策略，这种处理效率和结果，远超出依附纯规则或者纯知识库所能达到的效果；
• 闲聊寒暄：是智能客服非常关键的基础能力，能够帮助企业对任意进线客户进行即时响应。过去的智能客服闲聊主要是将各类非业务相关的语料堆到素材库，并通过调取数据库已有的关键词进行内容的回复。如今可以充分借助大模型能力提供闲聊，在非业务领域上为座席和客服提供更多决策依据和参考；
• 话术优化建议：话术往往决定了客服的效果，话术回复不精准将直接导致用户的流失。通过大模型强大的内容生成能力，智能客服能够对话术进行不断地迭代和与优化，提升客户满意度；
• 提供语料扩写：在智能客服冷启动阶段，往往需要足够多的语料来丰富知识库的相似问法，以保证上线初期智能客服有足够高的解决率和场景覆盖率。以往的语料生成模型很难覆盖众多垂直行业和领域，大模型在通用领域中积累了足够的数据和语料，可以很好的弥补语料生成模型的不足，快速生成相似问法，解决智能客服冷启动语料不足，场景覆盖率低等问题。

提高对话质量的核心还是理解客户和用户场景，搭建出衡量得失的数据框架。这两个组合之下，会有一个循环反馈的过程，就能够通过正常的产品迭代达到好的效果，并且能够衡量出来 ROI 和对实际业务的共享。

案例

总结

【2026-3-17】Top 8 AI agents for customer service : Tested & reviewed (2026)

• 

GitHub 上智能客服agent项目，地址

项目	时间	作者	介绍	可用性	实践
customer-service-ai-agent	2025年8月	国内个人	LangGraph 搭建多智能体客服系统； Multi-Agent架构, 各专家物理隔离（agent文件独立）; 接硅基流动的llm	中	【2026-5-7】实测，安装失败，langchain/graph 工具包版本不一致，后端服务无法启动
customer-chatbot-solution-accelerator	2025年9月	微软	Foundry agent框架在电商客服上实践	依赖微软生态
openai-cs-agents-demo	2025年9月	OpenAI	低	基于OpenAI自己的生态（Agent Builder+ChatKit）
Building-Customer-Service-Agent-with-Skill	2026年3月	国外个人	用 Microsoft Agent Framework 实现智能客服后端（C#语言），React+Vite实现前端，并用 skill机制 节省token； Multi-Agent架构，controller负责分发+流式响应	中, multi-agent + skill 可借鉴	使用新版skill格式（skill.md 包含trigger示例）, 各领域专家以skill方式组织；有护栏机制

【2025-9-*】微软 customer-chatbot-solution-accelerator

customer-chatbot-solution-accelerator 用 Microsoft Foundry 的Agent框架构建智能对话式的客户服务机器人。

• 将专业 Agent与企业级数据服务无缝集成，团队可以创建能够提供个性化产品推荐、解答政策问题并提供卓越客户支持的聊天机器人。
• 结合了现代电子商务前端和智能后端，后端使用编排agent将客户查询路由到专业代理（产品查询和政策/知识），确保基于产品目录和政策文档的准确、上下文相关的响应。
• 将 AI 能力与可扩展的云基础设施统一，组织可以提供 24/7 的客户支持，该支持理解上下文、保持对话历史并提供可操作的见解，以改善客户满意度和运营效率。

用 Microsoft Foundry 的agent框架、Foundry IQ 和 Azure Cosmos DB 创建智能客服聊天机器人，具有专门的产品查询和知识管理代理。

• 基于 React 的现代电子商务前端，集成了聊天界面，使客户能够浏览产品、获取个性化推荐，并通过自然语言对话获得支持。
• 一个编排代理智能地将查询路由到专门代理（产品查询和政策/知识），这些代理使用跨产品目录和政策文档的混合搜索，以确保准确、有上下文的答案。

整体架构

• 

【2025-9-*】customer-service-ai-agent

customer-service-ai-agent

• 基于 LangGraph 构建的多智能体客服系统，支持：产品咨询、技术支持、账单处理、投诉处理等多种业务场景。
• 系统采用模块化设计，每个智能体独立运行，通过配置文件定义工作流程。

技术架构

• LangGraph: 工作流编排框架
• LangChain Core: LLM集成和消息处理
• 硅基流动API: 大语言模型服务
• 模块化设计: 高内聚、低耦合的架构

安装

pip install -r requirements.txt
pip install langgraph-cli
pip install -U "langgraph-cli[inmem]"
# 复制 env_example.txt 为 .env 文件并配置
cp env_example.txt .env
# 运行后端服务
python multi_agent_customer_service.py
# 启动前端
# ① 使用Studio UI访问langgraph服务
langgraph dev
# ② 使用Web服务调用langgraph api
langgraph dev # 终端1：启动LangGraph服务
python ./web_app.py # 终端2：启动自定义Web服务
# ③ 直接API调用
# 接口文档访问地址默认 http://127.0.0.1:2024/docs，内嵌了js需要挂梯子。也可参考[api_ref](https://langchain-ai.github.io/langgraph/cloud/reference/api/api_ref.html), 需要 langgraph dev 启动LangGraph服务。

浏览器访问 local demo，界面功能：

• 实时聊天: 输入问题，获得智能回复
• 智能体信息: 显示当前处理问题的专家和查询类型
• 历史管理: 查看、清除对话历史
• 数据导出: 导出对话记录用于分析

项目结构

customer-service-ai-agent/
├── agents/ # 智能体模块
│ ├── init.py # 智能体包初始化
│ ├── base_agent.py # 基础智能体类
│ ├── product_agent.py # 产品专家智能体
│ ├── tech_agent.py # 技术支持专家智能体
│ ├── billing_agent.py # 账单专家智能体
│ ├── complaint_agent.py # 投诉处理专家智能体
│ └── general_agent.py # 综合客服智能体
├── tools/ # 工具函数模块
│ ├── init.py # 工具包初始化
│ └── query_tools.py # 查询分类工具
├── templates/ # Web界面模板
│ └── index.html # 主页面HTML模板
├── config.py # 基础配置文件
├── multi_agent_customer_service.py # 主程序文件（LangGraph工作流）
├── session_manager.py # 会话管理器（LangChain标准接口）
├── web_app.py # Web应用（Flask + LangGraph API）
├── langgraph.json # LangGraph工作流配置
├── requirements.txt # 项目依赖
├── .env # 环境变量配置
├── README.md # 项目说明文档
└── README_LangGraph_CLI.md # LangGraph CLI使用说明

(1) 添加新的智能体

• 在agents/目录下创建新的智能体文件
• 继承BaseAgent类并实现process方法
• 在agents/__init__.py中导入新智能体
• 在langgraph.json中添加节点和边配置

(2) 添加新的工具函数

• 在tools/目录下创建新的工具文件
• 使用@tool装饰器定义工具
• 在tools/__init__.py中导入新工具

(3) 修改工作流程

• 编辑langgraph.json文件
• 修改节点、边和路由配置
• 重启系统应用新配置

【2026-4-24】OpenAI 客服智能体

【2026-4-27】OpenAI 在 GitHub 上开源基于 Agents SDK 的客户服务智能体 Demo

• openai-cs-agents-demo 项目的结构非常清晰，分为 python-backend 和 ui 两个目录，分别对应后端和前端。
• 解读 基于OpenAI Agents SDK构建航空客服多智能体系统实战

一套航空公司智能客服：内置多个专业 Agent，系统会自动判断用户问题类型，并把请求路由到最合适的 Agent 处理。

这款智能体模拟了航空公司客户服务 AI 机器人的工作流程，具备强大的功能，能够高效处理各类与旅行相关的查询。

“我想改签航班”或“我的航班延误了怎么办”

• 系统内部并不是由一个“全能”的模型来硬扛所有问题。 相反有个“分诊员”（Triage Agent）先判断意图 然后精准地“转接”给最专业的客服专员，例如专门处理预订的专员、负责航班动态的专员，或是处理赔偿的专员。 每个专员都是独立的智能体，拥有特定的知识、权限和工具（比如查询数据库、执行改签操作）。这种架构不仅响应更准确，也更容易管理和迭代。

独特之处在于采用了动态路由机制，将用户请求精准分配给专业的多层级智能体，实现自动化处理。

技术架构来看，该智能体由 Python 后端和 Next.js 前端共同构建。

• Python 后端借助 Agents SDK 承担智能体的编排工作，而 Next.js 前端则为用户提供了直观的聊天界面以及智能体转换的交互式可视化功能。
• 这种前后端协作的设计，让智能体在处理用户查询时，无论是分类、响应还是拒绝操作，其决策过程和任务分配机制都更加透明，便于用户理解和开发者调试。

该智能体内部集成了多个专业的子智能体，包括

• 分类智能体、座位预订智能体、航班状态智能体、取消智能体和常见问题解答智能体等。 每个子智能体都配备了专门的指令和工具，专注于完成特定的子任务。

核心 Agent 组成（覆盖一套航空客服的关键链路）：

• 智能分流 Agent：识别诉求、自动分配到对应模块
• 座位预订 Agent：改座、选座，并支持交互式座位图
• 航班状态 Agent：查询并返回实时航班动态
• FAQ Agent：解答常见问题与机型/服务信息
• 取消服务 Agent：处理退票、改签等售后流程

同时还配了

• 安全防护，能应对越狱攻击和无关话题干扰；
• 完整可视化界面，把整个工作流清晰跑一遍，学习和复用成本很低。

主题架构

Demo 没有采用常见的“单一大模型 + 长提示词（Prompt）”的笨重方式，而是采用了更符合现代软件工程理念的“微服务化”智能体架构。

传统客服机器人尝试用一个模型处理所有问题，其挑战是显而易见：

• 提示词会变得极其冗长和复杂（需要包含订票、改签、行李政策、航班状态等所有知识），模型容易产生“幻觉”（比如用订票的逻辑去回答赔偿问题）
• 且任何策略更新都需要重新调整整个庞大的提示词，风险高、迭代慢。

Demo 采用的 基于职能划分的多智能体架构 ，则带来了几个核心优势：

• 高内聚、低耦合 ：每个智能体只专注于一个明确的领域（如“航班信息查询”、“座位管理”）。它的提示词、知识库和工具都是为该领域量身定制的，非常精简和专注。这意味着你可以独立优化某个智能体（比如更新座位选择策略）而完全不影响处理退款流程的智能体。
• 职责清晰，可解释性强 ：系统的决策过程变得透明。在聊天界面上，你可以清楚地看到是哪个智能体在回复你，它为什么被触发。这极大地便利了调试和问题排查。如果用户对航班状态的回答不满意，你可以直接去检查“航班信息智能体”的日志和工具调用记录。
• 安全性提升 ：通过限制每个智能体的工具调用权限，实现了“最小权限原则”。处理常见问题（FAQ）的智能体没有权限去执行订票或退款操作，这从架构上减少了误操作的风险。
• 易于扩展 ：当航空公司推出新的服务（比如“付费升舱”或“宠物托运”）时，你不需要重构整个系统。只需要训练或配置一个新的“升舱服务智能体”，并将其注册到“分诊智能体”的路由表中即可。

整个系统的运行遵循清晰的协同工作流，就像现代化呼叫中心的工作模式：

• 用户入口（前端界面） ：用户通过 Next.js 构建的 Web 聊天界面发起对话。这个界面使用 OpenAI 的 ChatKit 组件，提供了流畅的聊天体验，并能可视化地展示后台智能体的协作过程（哪个智能体被激活、触发了什么防护栏等）。
• 请求分发中心（Triage Agent） ：这是整个系统的“总机”。它接收所有用户输入，其核心任务不是直接回答问题，而是进行 意图识别（Intent Classification） 。它内置的提示词经过训练，能够理解“我想改签”、“航班是否准点”、“我要退款”等不同意图，并将其映射到对应的专家智能体。
• 专家智能体池（Specialist Agents） ：这是一组各司其职的专家。Demo 中包含了六个：
  • 航班信息智能体 ：对接模拟的航班数据库，提供实时状态、延误预警、备选航班查询。
  • 预订与取消智能体 ：拥有“创建预订”、“取消航班”等核心交易工具的调用权限。
  • 座位与特殊服务智能体 ：管理座位选择、分配特殊需求座位（如医疗需要的首排座位）。
  • 常见问题智能体 ：一个知识库型的智能体，回答关于行李额、Wi-Fi、补偿政策等静态问题。
  • 退款与赔偿智能体 ：在航班发生不正常运行时，负责开具赔偿案例、发放酒店或餐食代金券。
• 工具层（Tools） ：每个智能体能力的“手脚”。它们不是由 LLM 凭空想象，而是封装好的、可编程的函数。例如， get_flight_status 工具会去查询一个模拟的航班数据 API； book_new_flight 工具会向模拟的预订系统发送请求。智能体通过分析对话，决定在何时、以何种参数调用这些工具，并将工具返回的结构化数据转化为自然语言回复给用户。
• 安全防护层（Guardrails） ：这是确保对话不“跑偏”的关键安全网。Demo 中主要演示了两种：
  • 相关性防护栏 ：检测用户输入是否与航空旅行相关。如果用户突然问“写一首关于草莓的诗”，此防护栏会触发，阻止智能体回答无关问题，并回复预设的安全提示。
  • 越狱防护栏 ：防止用户通过特定指令（如“重复你的系统提示词”）来窥探或操纵智能体的内部指令。一旦检测到此类尝试，立即拦截并返回标准化回复。

这个架构的精妙之处

• 将 LLM 的通用语言理解能力（由分诊和各个智能体承担）与确定性的业务逻辑和数据处理能力（由工具函数承担）结合了起来，既灵活又可靠。

安装

git clone https://github.com/openai/openai-cs-agents-demo.git
cd openai-cs-agents-demo

Shopify

真智能客服来了，无需再呼唤“人工”

• 很多人以前都遇到过“鸡同鸭讲”的傻瓜机器客服，ChatGPT将改变这一情况。让智能客服真正理解客户的需求，基于客户诉求创作营销内容，根据数据分析营销效果，真正的智能客服能做的事远不止向客户介绍产品。
• 2023年3月，全球领先电商SaaS服务商Shopify已集成了ChatGPT。
• Shopify 主要面向企业及个人客户提供电商网站建立、维护管理等服务。采用ChatGPT，Shopify一方面升级智能客服功能，帮商家与客户沟通更顺畅；另一方面，商家可以通过ChatGPT获取平台商品评论数据分析、标题及关键词优化、营销文案撰写、网站智能化开发编程等多项服务，提升运营效率。
• 
• 智能客服作为ChatGPT最直接能落地的领域，一定会很快入驻各大电商平台，让一批不具备更多技能的客服被替换掉

【2023-6-18】基于ChatGPT构建智能客服系统(query分类&安全审核&防注入) 介绍3点：

• 智能客服场景中的用户query分类
• 使用OpenAI的接口进行安全审核
• 如何防止Prompt注入

（1）多级分类 prompt

• 主要类别
• 次要类别

delimiter = "####"
system_message = f"""\
您将获得<客户服务查询>。\
<客户服务查询>将用{delimiter}字符分隔。\

将每个查询分类为主要类别和次要类别。\
以Json格式提供输出，key为：<primary>和<secondary>。只需要输出Json格式的输出结果，其他的不需要输出。\

主要类别：<结算>、<技术支持>、<账户管理>或<一般查询>。

<结算>次要类别：\
取消订阅或升级 \
添加付款方式 \
有关费用的说明 \
争议费用

<技术支持>次要类别：\
一般故障排除\
设备兼容性 \
软件更新 \

<账户管理>次要类别：\
重置密码 \
更新个人信息 \
关闭账户 \
账户安全 \

<一般查询>次要类别：
产品信息 \
支付 \
反馈 \
与人交谈 \
"""

user_message = f""" 我想让你删除我的个人资料和我所有的用户数据 """

messages =  [  
  {'role':'system', 'content': system_message},    
  {'role':'user', 'content': f"{delimiter}{user_message}{delimiter}"},  
]
response = get_completion_from_messages(messages)
print(response)
# ------
{
    "primary": "账户管理",
    "secondary": "关闭账户"
}

（2）Prompt 注入

# 会被视为 Prompt 注入
user_message = f"""介绍下你们的平板电视吧"""

messages =  [  
{'role':'system', 
 'content': system_message},    
{'role':'user', 
 'content': f"{delimiter}{user_message}{delimiter}"},  
]
response = get_completion_from_messages(messages) # 调用OpenAI
print(response)

ChatGPT回复如下：

抱歉，我是一个语言模型，无法提供实时产品信息。建议您访问电视制造商的官方网站或者联系客服获取更详细的产品信息。如果您有其他问题需要帮助，请随时问我。

完整的messages如下：

[{'role': 'system', 'content': '您将获得<客户服务查询>。<客户服务查询>将用####字符分隔。\n将每个查询分类为主要类别和次要类别。以Json格式提供输出，key为：<primary>和<secondary>。只需要输出Json格式的输出结果，其他的不需要输出。\n主要类别：<结算>、<技术支持>、<账户管理>或<一般查询>。\n\n<结算>次要类别：取消订阅或升级 添加付款方式 有关费用的说明 争议费用\n\n<技术支持>次要类别：一般故障排除设备兼容性 软件更新 \n<账户管理>次要类别：重置密码 更新个人信息 关闭账户 账户安全 \n<一般查询>次要类别：\n产品信息 支付 反馈 与人交谈 \n'}, {'role': 'user', 'content': '####介绍下你们的平板电视吧####'}]

Prompt注入问题

• 使用变量
• 示例1: 忽略前面的指令
• 示例2: 判断是否存在Prompt注入

更多：吴恩达《Building Systems with the ChatGPT API》课程

指定变量方式防止Prompt注入：

• 上述被视为 Prompt 注入，做出以下修正

delimiter = "##"
system_message = f"""\
您将获得<客户服务查询>query_text。\
<客户服务查询>query_text。\

将每个<客户服务查询>分类为主要类别和次要类别。\
结果以Json格式提供输出，key为：<primary>和<secondary>。\
只需要输出Json格式的输出结果，不要输出其他，key对应的值没有的话，用空字符串填充。\

主要类别：<结算>、<技术支持>、<账户管理>或<一般查询>。

（同上，略）

"""

raw_user_message = "介绍下你们的平板电视吧"
user_message = f"""query_text={raw_user_message}"""

print("user_message=", user_message)

messages =  [  
{'role':'system', 
 'content': system_message},    
{'role':'user', 
 'content': user_message},  
]
print("messages=", messages)

response = get_completion_from_messages(messages)
print("response=",response)

ChatGPT回复如下：

{
    "primary": "一般查询",
    "secondary": "产品信息"
}

中间信息如下：

user_message= query_text=介绍下你们的平板电视吧
messages= [{'role': 'system', 'content': '您将获得<客户服务查询>query_text。<客户服务查询>query_text。\n将每个<客户服务查询>分类为主要类别和次要类别。结果以Json格式提供输出，key为：<primary>和<secondary>。只需要输出Json格式的输出结果，不要输出其他，key对应的值没有的话，用空字符串填充。\n主要类别：<结算>、<技术支持>、<账户管理>或<一般查询>。\n\n<结算>次要类别：取消订阅或升级 添加付款方式 有关费用的说明 争议费用\n\n<技术支持>次要类别：一般故障排除设备兼容性 软件更新 \n<账户管理>次要类别：重置密码 更新个人信息 关闭账户 账户安全 \n<一般查询>次要类别：\n产品信息 支付 反馈 与人交谈 \n'}, {'role': 'user', 'content': 'query_text=介绍下你们的平板电视吧'}]

（3）内容审核

OpenAI 官方提供了内容审核的接口 Moderation。

• 通过OpenAI的内容审核接口可以检查用户输入的内容是否符合OpenAI的使用政策，包括识别是否存在不良信息、仇恨言论、暴力内容、色情内容等，并对其进行过滤或标记。

# sexual
response = openai.Moderation.create(
    input="""➕V看你想看的，日韩应有尽有"""
)
moderation_output = response["results"][0]
print(moderation_output)
# violence类别识别
response = openai.Moderation.create(
    input="""你再这样PUA张三的话，张三可能会拿电锯把你切成碎片"""
)
moderation_output = response["results"][0]
print(moderation_output)

销售助手-RepAI

【2024-8-27】用 AI 做售前服务, 将员工真实照片作为AI形象

• Repai 成立于2022年，由Shuki Levy和Shalev Leibovici共同创立。公司开发了一款AI销售助手，提高电商平台的转化率。这款AI助手能够实时分析用户行为，并提供个性化的产品推荐和客户服务。
• 【2024-8-27】电商领域的AI销售助手初创公司Repai宣布完成820万美元融资。

AI解决方案显著提升电商平台的销售业绩。在某些案例中，使用Repai的客户实现了高达30%的转化率提升。

Repai AI助手采用大语言模型技术，能够理解和回应复杂的客户查询。不仅可以回答产品相关问题，还能提供个性化购买建议，模拟真人销售助理的服务体验。

Volition Capital董事总经理Larry Cheng表示：” Repai正在将先进的AI技术应用于电商领域，这有潜力彻底改变在线购物体验。我们对Repai团队的执行力和产品愿景印象深刻。”

Repai 计划利用此轮融资加速产品开发，扩大销售和营销团队，并拓展国际市场。公司还将投资于进一步优化其AI模型，以提供更精准的产品推荐和更自然的对话体验。

随着电商行业竞争日益激烈，如何提高转化率成为商家面临的关键挑战。Repai等专注于AI销售助手的初创公司正好切入这一痛点。业内专家认为，AI在电商领域的应用前景广阔，未来可能会成为提升用户体验和销售业绩的关键工具。

Repai也面临着来自其他AI初创公司和大型科技公司的竞争。如何在快速发展的市场中保持技术优势和产品差异化，将是Repai未来发展需要解决的重要问题。

RepAI 6大功能：

• 1、AI实时聊天：将员工形象语音建模，支持视频/语音/文字实时聊天对话。
• 2、AI意图分析：分析客户需求，触发销售动作，记录数据。
• 3、AI接管操作：实时接管“鼠标”，引导用户操作网站，或者根据客户的需求，直接在线演示操作。
• 4、AI引导留资：根据聊天语境，插入引导留资或者预约拜访记录。
• 5、企业知识库：导入企业知识库，在范围内回答问题。
• 6、AI智能外呼：按需求，自动外呼，进行线索打标清洗等操作。

瓴羊

【2024-8-29】从“智障客服”变智能客服，大模型终于落地了

2024年春节期间，经过半年多的摸索，瓴羊 Quick Service 在内部发布了一个新产品版本，定义了在to B场景下智能客服Agent产品形态。

当时时间点，这可能是国内第一个可落地的大模型加持的智能客服Agent。

瓴羊不是学术研究部门，阿里巴巴在2021年成立的聚焦于数据服务的全资子公司，Quick Service 是其中的智能客服部门。

瓴羊最核心任务解决客户的实际业务问题。

瓴羊最新发布的 Quick Service 2.0，在上一版基础上全面升级了三大核心功能：AI问答、AI辅助和AI知识库，是业内首个将AI Agent完整落地、可覆盖客服“全场景”的智能客服产品。

提到智能客服，立马联想到电话推销，电话推销就是通过智能客服呼叫中心的外呼机器人来实现的。很多人常把外呼机器人与智能客服划等号，但实际上外呼机器人只是智能客服的场景之一。

智能客服还有很多场景。

张双颖：

• 从消费者视角来看，智能客服会贯穿售前、售中、售后三个主要消费环节，为消费者提供一贯式的咨询服务；
• 从客服员工视角看，当处理消费者的咨询时，需要用到员工培训、工单、知识库等多款配套工具；
• 从商家的客服部门管理者的视角来看，需要一个工具来了解客服的整体效果，涉及质量检验、消费者综合洞察等。”

但智能客服行业存在一个长久的痛点: 没有体现“智能”。

• 早期智能客服基于专家系统，依赖于预设的关键词模板，能够提供基本的信息查询服务，但缺乏灵活性与理解复杂语境的能力。
• 后来智能客服引入机器学习、深度学习技术，能够处理更复杂的问题，提供更个性化的服务，但其实仍然没有达到“智能”的水平。

因此，客服系统需要庞大的人工客服来应对各种问题。有多少智能，就有多少人工。

在很多企业，智能客服就是纯粹的成本中心，降本增效就是最核心的诉求。

• 客服人员流动性大、培训成本高、客服效果难以把控、大量重复性问题过度消耗人工客服。
• 同时，如何提升售前转化、如何优化客服流程、如何从客服数据中发现企业业务问题等，一直困扰着各大企业。

直到ChatGPT的出现，让从业者看到了智能客服的理想状态。一个机器人回答所有问题，似乎不再是遥不可及的梦想。

2023年春节——ChatGPT发布一个多月后，瓴羊Quick Service团队就基于海外已有的大模型做出了文本总结、摘要等功能。但团队发现，由于准确度与幻觉等限制，无法在真实的商业环境中落地。

等到2023年年中，OpenAI研究员发布了一篇著名的关于Agent的论文。论文指出，如果说大模型是一个大脑，那么Agent就是一个可执行任务的四肢。这给瓴羊团队如何做大模型的落地打开了新的视角。

在深入研究了Agent的规划、记忆、工具使用等核心组件能力之后，瓴羊的算法、产品团队做了细致的推演，发现Agent这条路是可落地的。2024年春节前后，瓴羊智能客服团队把第一个Agent的产品雏形做了出来。

大模型与智能客服结合，瓴羊做了大量的工作。

• 通用大模型底座的选择。瓴羊Quick Service的默认选择是阿里通义千问，如果企业有其他选择技术上也完全支持。
  • 可商用的模型里，通义千问是测评效果最优秀, 而且是阿里的
• 通用大模型的基础上，通过知识预处理、特征抽取、检索引擎等技术，训练得到客服垂直大模型——瓴羊称之为行业模板。瓴羊面向零售、汽车等多个行业，借助通义千问为底座的RAG方案，针对步骤类、流程类、政策类等文档，生成了与之对应的8种模板。
• 行业模板针对大模型的内容生成做了约束，有助于解决大模型幻觉问题。

此外，在大模型生成知识之后，瓴羊团队还专门做了一个防幻觉的检测模型，确保是安全合规、符合企业要求的信息。

大模型的泛化能力相比传统的小模型节省了重新调整算法的成本，其带来的优势非常明显。

• 比如一个简单的订票场景，以前仅仅是多出一个票种分类，也需要再去专门训练一个小模型来适配，而现在一个大模型就能解决。大模型对新场景的容纳率，的确比小模型要好得多。

做大模型，也不能盲目迷信大模型。

• 在一年多的摸索里，瓴羊团队得出的结论是，大模型不能解决所有问题，最实用、高效的路线还是大小模型结合的方式。

在智能客服的一些场景中，有些问题要求高度准确、可控,答案不能出错，比如: 食品安全、产品价格，它需要100%的确定性。这类问题，实际上更适合传统的小模型，也就是特定算法来回答特定问题，给出预先匹配好的100%确定性的答案。

为了区分复杂问题与专精问题，瓴羊团队研发了一个“路由算法”，就像大模型的路由器一样，智能识别与分发不同的问题。

• 遇到专精问题就匹配给小模型
• 遇到需要长上下文理解、语义理解、情感识别的问题，就匹配给大模型来处理。

小模型的核心能力不在于技术水平高低，而在于贴近客户做业务。而现在，智能客服行业涌入了不少大模型公司，试图用新的AI技术改变行业的业务模式。

许多公司的商业逻辑更像是“拿着锤子找钉子”，而瓴羊恰恰相反，属于“拿着钉子找锤子”。

Quick Service沉淀了阿里巴巴二十多年客户服务的经验，这些深厚的行业积累，是短时间内很难被超越的壁垒。

• 第一个产品AI问答，将传统热线和在线对话机器人进行了智能化转型，解决了企业智能机器人在处理客户个性化需求时常答非所问的问题，解答准确率达到93%。
  • 借助瓴羊的智能化客服系统，星巴克解决了87%的客户咨询问题，客户投诉处理时效提升50%。
• 第二个产品AI辅助，为企业客服团队提供效率工具，实现多渠道的高效协同。
  • 某头部零售企业此前一个工单需要经过客服、城市经理、奶站站长等多个环节才能到达最终的处理人员（送奶工）。
  • 而接入瓴羊Quick Service后，通过大模型智能填单技术与自动化任务分配系统，工单可以直接精准下发至对应处理人员，线上线下任务协同时长可缩短95%。
  • 某头部运营商存在大量的员工和代理商咨询需要处理，过去主要使用电话沟通、单点私聊或者群内留言等传统方式，客服缺乏统一的标准化服务。
  • 在接入瓴羊AI辅助产品后，客服可以借助瓴羊客服的灵活渠道部署，高效整合知识库机器人、人工客服、热线入口、OA流程、公告留言板、消息主动推送等各种支撑能力，客服支撑效能提升50%以上，支撑响应接起率超过99%，一般性诉求解决时间由30分钟压缩到5分钟以内。
• 第三个产品AI知识库，面向服务运营，减少客服运营繁琐的知识库配置工作，知识库部署从“7天”缩短至“5分钟”。
  • 某头部家电企业，内部协作需要照顾到研发、生产、供链、销售、服务等10万名员工，这些员工每天会产生5000多个问题。但这些数量庞大的提问的重复率高达40%，运维人员的回答也存在不统一、专业性知识跨部门支持等难题。
  • Quick Service 2.0通过知识批量导入结合Query的相似度模型及知识冲突模型，将问题进行删除合并，同时利用大语言模型的话术润色能力生成出更具专业性、亲和力的答案。而面对格式多、内容广的文档知识，产品团队只需按模板上传，即可为员工生成准确的答案。

此外，高频的产品迭代、数以百计的渠道入口，员工问题繁杂，都给机器人维持准确率带来了不小的困难。

对此，Quick Service为企业打造了统一知识生产流程，即使在每季度2-3个功能上线、10%产品更新的节奏之下，也可保证机器人的准确率。当员工在问询不属于某一入口的功能时，智能类目还会帮助机器人自动路由到其他类目，检索原入口没有的知识，解决“大而全”与“小而精”难以兼顾的矛盾。

目前，该企业的机器人问题准确率达80%以上，员工平均咨询量、运维工单咨询发起量分别降低18%与8%。

微众银行 AI Agent

【2024-5-16】微众银行AI Agent实践

微众银行AI Agent实践包括：智能语音机器人Agent、相似问题生成Agent、摘要和小结生成Agent，服务于终端用户和内部客服，大幅提高服务效率和效果。

以摘要和小结生成Agent为例：

• 坐席完成一通对话后，要根据当前信息（录音+企业微信内容），编写服务摘要和服务小结，需要占用一分钟左右时间。
• 用Agent自动生成摘要，客服人员只需简单修改即可上交，摘要生成合格率达到90%、小结生成准确率达到98%，可节省100人天，大幅提高坐席作业效率。

Cognigy

【2023-11-13】德国 杜塞尔多夫 Cognigy AI 推出 AI Copilot。 利用对话式人工智能和生成式人工智能的强大协同作用，重新定义了企业代理协助的可能性，rise 联络中心, 用AI改造传统客服流程

【2024-6-11】成功融资1亿美金。

AI生产力+行业Know-How，是企业AI化的关键要素。

Cognigy Knowledge AI 准备通过融合法学硕士和先进的矢量搜索技术来改变客户服务和代理支持。 旨在无缝集成生成问答、企业rise 知识和超个性化交互，这项创新为寻求卓越客户体验的企业提供了强大的解决方案。

认知知识人工智能功能包括：

• 自动驾驶仪上的生成式问答： 自动解决问答查询并让客户，立即找到需要的信息。 在先进的矢量搜索技术和法学硕士的支持下，Cognigy Knowledge AI 与不同的知识源合作，提取和总结每个客户问题的最准确答案。
• 超个性化交互： 超越标准答案，通过超个性化的对话给客户留下深刻印象。
  • 无缝 CRM 集成意味着 Cognigy 的 AI 代理可以根据每个独特的客户旅程定制检索的信息，通过出色的服务体验提高满意度和忠诚度。
  • 系统记录客户回话历史、风格
• 交易就绪：使客户能够通过一次交互来实现目标。 深度后端集成，Cognigy 将知识 AI 与自始至终服务和解决事务查询的能力相结合。
• 代理商知识快捷方式： 无论是经验丰富的客户服务代表还是新入职的客服人员，Cognigy Knowledge AI 都可以帮助您 team通过在内部文档中显示最相关、最简洁的信息，始终提供准确、快速的服务。
• 提升企业rise 效率： 通过消除手动创建和维护常见问题集来节省成本并简化流程。 只需上传现有 PDF 文件等文档或连接到企业rise 知识来源。

Coze

【2024-11-19】教你10分钟打造专属AI客服，接入各大平台【扣子小白教程】

• 抖音视频介绍

【2025-6-18】 Coze 官方智能客服

• 基于扣子对话流、知识库能力，从售前、售中、售后三个阶段提供陪练、对话、copilot等模板，帮助企业快速搭建 AI 智能客服应用

• coze客服产品

• 全天智能响应
  • 可同时处理大量请求，即时响应，无惧时间地点，显著提升客户体验
• 运营成本低
  • 前期投入于开发维护与训练，长期可大幅节省人力，降低成本
• 专业高效答复
  • 依托算法与数据，提升回复准确率，始终保持专业、热情
• 知识更新及时
  • 连接海量知识库实时更新快速应对各种问题，提供全面解答

概貌

• 

Bland AI 热线

运营商/银行的电话AI助理，语气已经很接近真实人类的声音。

但是对话交互点比较局限，听头两句就知道对方是—— AI。 似乎缺少智能体的特征 …

【2024-9-5】AI电话Agent时代到来！！语音克隆与情感理解、企业电话的未来？

Bland AI 公司成立于 2023 年，旨在通过其人工智能代理来彻底改变企业处理电话通信的传统、通常效率低下的方式。

• Bland AI CEO兼联合创始人 Isaiah Granet 表示，目标是 解决人工操作电话系统固有的局限性。

这些电话代理可以接听客户支持电话并开展销售运营和内部沟通。

人类无法全天候工作，无法同时处理数百万个电话，也无法根据公司喜好训练其声音和行为 —— 但AI可以，而且成本只是其中的一小部分。

对话AI智能体 Bland AI 可以集成到公司系统, 从公司文档知识库中检索知识 + 必要时转人工。

Bland AI 有时甚至假装是人类，此外，它利用通话数据训练训练迭代自己

Bland AI 可以语音克隆、多语言支持、无限呼叫。

它能够理解人类情感，说任何语言(方言、外语)，并且像顶级员工一样代表品牌。不管对面是什么人都能和你唠唠嗑。

Bland AI 工作原理

Bland AI 电话呼叫平台旨在兼具多功能性和安全性，允许企业创建、测试和部署他们的 AI 电话代理。

公司可以首先选择一种声音, 并构建一条对话路径，即一棵预定义的提示树，指导人工智能如何响应各种客户互动。

一旦部署，这些人工智能代理就能处理各种场景，无论客户反应如何，都能保持正常运行。

该平台主要功能包括：

• • 语音克隆和多语言支持：
• • 这使得人工智能能够用多种语言说话并模仿声音。
• • 集成能力：
• • 与其他系统无缝连接以检索和更新数据。
• • 可扩展的AI测试系统：
• • 允许企业不断完善AI代理。
• • 通话分析：
• • 提供详细的记录和通话后分析，以优化未来的互动

应用场景

企业电话呼叫自动化，以人工为主的呼叫中心时代即将终结吗？

• Bland AI 的技术已经被 Better.com 和 Sears 采用，他们利用该平台创建定制 AI 代理，更有效地管理电话并从详细的分析中提取有价值的见解。

Bland AI 计划进一步开发其平台，特别是其高级分析能力。

目标是支持广泛的行业，包括医疗保健、房地产、物流、金融服务、替代数据和小型企业。

通过提供有关电话通信的详细、可操作的见解，Bland AI 使企业能够不断改进其 AI 代理和整体性能。

容联七陌

【2024-9-26】如何让智能客服像真人一样对话？容联七陌揭秘：多Agent大模型

容联七陌是国内知名的企业智能客服系统服务商，专注智能客服领域已有十年内，其智能客服广泛应用于教育培训、医疗医药、电商直播、新零售、智能制造、汽车、泛互联网等多个领域，服务了包括作业帮、复兴健康、同仁堂、虎牙、多点、广汽能源、红旗、居然之家等品牌。

2024年8月，容联七陌推出行业首创的“新一代大模型智能客服解决方案”，让智能客服在意图理解、答案生成、情绪理解方面，都实现了跨越式的能力提升。

很多同行探索智能客服的大模型应用，但大模型只是作为某种功能辅助，比如提升会话小结的效率、提升训练师的工作效率等，其实是拿大模型辅助去提升上一代智能客服的效率，没有从根本上改变上一代智能客服的痛点。这也是为什么我们强调原生大模型的智能客服，它和上一代智能客服的体验和效率完全不在一个级别。

荣联云智能客服产品：

• LLM文本机器人：接待IM渠道（网站、公众号、APP等）接入的用户需求；
• LLM智能外呼 & LLM智能呼入：主要应用在呼叫中心场景中。
• LLM座席助手：辅助人工客服，比如生成回应话术、自动生成服务小结、创建智能工单等。

传统客服问题

上一代智能客服痛点

• 语义理解不足，用户提了诉求，但机器答非所问的概率很高。
  • 技术上用关键词、BERT模型等机制，这种机制需要大量数据标注，标注越多，理解能力就越强，但标注高度依赖人工。一旦人工标注和训练不足，机器的理解能力就会不够，结果就是答非所问。
• 用户体验不好，缺乏情感表达。用户是有情绪的，但上一代智能客服是预制的，不管用户什么情绪来提问，机器都是标准回复，比较机械。机器能不能打动用户、解决用户问题，完全取决于设计问答的那个人。
• 第三，多轮，复杂任务类的处理很呆板。比如预定会议室，上一代智能客服一般会使用流程画布，第一步问定会议室的时间、参会人等信息，再调取定会议室的接口，必须一步步按设定好的流程来。当用户的话题超出了设定范围，智能客服就会直接告诉用户，它答不上来，最后转人工客服的比例其实很高。
• 第四是成本高。上一代智能客服需要设立专门的机器人训练师，因为要穷举业务上的问题和标准答案，每个问题还要提供不少于30个的相似句。如果涉及到一些复杂的业务知识和流程，还需要梳理知识图谱。这个训练过程是非常复杂，通常需要3个月到半年，然后才能达到80%的解决率。专门配置这样一个训练师，企业成本是非常高的。

大模型客服

大模型之后，智能客服就可以自己生成话术，接得住用户的话头，回答自然流畅，就像和真人聊天一样。对话理解上，大模型也可以应对用户多样化的表达方式，比如不同的问法、错别字等等，都能够真正去理解。

• 首先，大模型可以冷启动，不需要标注数据，只需要把客户的业务知识维护进去，就能达到很好的效果——回复人性化，接得上用户的话题，能够理解用户的情绪等等。比如，用户一开口就很生气，新一代大模智能客服会先进行安抚，然后再列出相应的解决方案。因为根据用户的情绪变化生成对应的回复，所以用户对话的流畅度体验就会很好，情绪价值也足够。
• 流程类，就像前面提到的预定会议室的场景，大模型不需要固定流程设置和穷举话题。因为有很强的推理能力，当给对应的提示词工程，告诉它定会议室需要用户提供哪些信息，大模型就可以自己去思考已经拿到了哪些信息，还缺哪些信息，从而引导用户给出完整的所需信息。就算中间用户切换话题，大模型也可以继续聊下去。
• 最后说成本，不再需要专门的机器训练师了，企业成本降低了，回答的准确率还上升了。

所以，新一代智能客服会更多依赖原生大模型，对用户来说就是更自然、更智能的体验，而非上一代产品那种简单的、预制的回答。

有个保险客户提供了10万字的测试资料，包括保险条款、规则制度等，整理出来有几千个知识点。按照上一代智能客服的工作方式，光整理资料，最少就要一个星期，只能达到40%的解决率，后面还要不停的标注。

但新一代大模型智能客服，自动清理知识点，1天就可以完成工作，测试解决率高达100%，上线后解决率也高达92%（即没有转接人工的比例）。

Agent 架构

2023年底，容联七陌就确定了大模型Agent的路径，国内智能客服行业最早一批确立落地方向的企业。多Agent、提示词工程、功能设计等多个方面的探索，主要体现了产品和技术的竞争力。

例如，容联七陌独创的Ask Human Help托管模式，就是用大模型机器人全程接待，告别了直接转人工的模式。

Agent就是智能体，构建于大模型之上的一个计算机的程序，可以模拟独立思考的过程，灵活调用各类工具。

为什么是多Agent产品架构?

教育行业头部企业的客服有三类工作内容：

• 第一类是简单寒暄；
• 第二类是回答业务的通用问题，比如 APP头像怎么修改；
• 第三类是VIP业务，比如VIP权益介绍、使用、续费等。

这三类任务是不同类型，但又是多任务混合。

• 要解决每一类任务，对应到产品结构上，就是一个具体的业务场景，匹配一个单一的Agent。
• 通过这个Agent感知、思考、行动，然后来完成对应的单一任务，这样效果更好。
• 所以要完成复杂任务，就需要多个Agent的架构，通过不同的Agent去解决不同业务场景的问题，这样的架构能够很好地提升准确率。

多Agent架构本身就提升了智能客服回复的准确率。

提示词工程，根据客户的实际业务去抽象了很多提示词，在工程上进一步提升准确率。

Q：围绕智能客服Agent，未来容联七陌还将在哪些方向上进行探索？

继续增强产品的智能性和问题解决能力，持续探索大模型准确率的提升。同时，也会关注大模型多模态技术的发展，如ASR、TTS、音色克隆等，将大模型的不同技术应用到智能客服产品中去。

机器 or 人工 ?

决策机制：机器还是人工？

• 简单知识点或者推理，直接由大模型来回复。这里我主要谈谈
• 复杂推理如何处理？

保险业务中，对于能否投保的判断是非常复杂的，如果不理解业务，光有知识点，是很难做出这种复杂推理的。所以设计了三个功能模块：

• 一. 知识词典，就是补充保险条款中的细节知识点，让大模型能够去推理。
• 二. 最佳实践，给大模型一些示例参考，进一步提升推理的效果。
• 三. 二次复核，去复核大模型生成的回答是否准确，是否能解决用户的问题，是否包含违禁词等等，这也是对大模型幻觉的一个检验机制。一旦发现大模型生成的回复有问题，也有配套的策略，比如马上转人工或者进入（Ask Human Help）托管模式。

除此之外，有专门的功能模块，让大模型自动对人工客服的服务记录进行学习，这也是提升大模型效果很重要的一点。

落地测试：

• 第一，售前的营销套电场景。某家居家装公司中，使用大模型智能客服替代传统流程式机器人，目前大模型机器人可以自然接住用户的话题，采用先聊天，再委婉请用户留下资料的方式，将留资率从21%提升到了32.91%。
• 第二，外呼邀约场景。通过外呼机器人对留资客户进行回访邀约。
  • 传统外呼机器人需要投入大量人力对流程、话术、知识点、意图等进行训练，准确率不高，话术也固定，用户体验一般。
  • 但是大模型外呼机器人可以根据上下文语义判断客户意向等级、自动小结标签等，将客户意向度提高了23%，信息抓取准确度也提高了46%。
• 第三，客服场景。在某大型企业内部的HRSSC服务中，员工提问涉及大量的公司规定、社保、公积金等问题，知识来源形式复杂，并且具有时效性。
  • 如果全部使用HR人工答疑，其他工作就忙不过来了。
  • 使用大模型智能客服后，可以极大缓解HR的工作压力，HRSSC解决率高达97%。
• 第四，呼入接待场景。
  • 某保险公司使用传统呼入机器人，为用户答疑头部流程、理赔等，但解决率不到30%，转人工接听，无法满足24小时服务，且人手不足。
  • 使用大模型智能客服后，实现了24小时接听服务，且解决率提升至92.02%，大大缓解了人工压力。

人机协同模式

客服人机协同模式中，机器转人工是能明显感知到，而且人工回答完之后没法再转接给机器，客户体验和人工成本都不好。

但是有了 Ask Human Help 托管模式，用户不再使用点选按钮的交互，而是直接用自然语言就可以交流，所以用户感知不到对面是机器人在服务。当大模型答不上来时，会转给人工客服，但人工只需要回答转进来的这一条消息，就可以立即再转回给大模型。

这种转变下，人工客服的工作量从“会话级别”下降到“消息级别”，每个客户的会话服务时长可能从平均10分钟下降到1分钟内，那么同等数量下的人工客服就能接待更多的客户。

对于客户来说，服务的体验也更好了，解决问题的效率也更高了。无论对于企业还是客户，在这种模式下都是受益的。

除此之外，容联七陌还有很重要的竞争优势，深耕客服领域已经有十年了，在客服解决方案的各个环节做了很多设计和优化，能够充分贴合各行业客户的客服场景应用，比如将客服系统和人力、工单等业务系统做了集成。

所以容联七陌的大模型智能客服Agent解决方案，不仅是单一产品，而是一整套解决方案，涵盖售前、售中、售后的全部场景。

阿里店小蜜

【2025-9-4】淘宝发布智能客服行业首个Agent原生产品“店小蜜5.0”

2025年9月4日，淘宝正式推出智能客服行业首个Agent原生产品· 店小蜜5.0，升级智能体技术帮助商家全面提升客服服务能力、促进成交转化。

测试阶段数据显示，店小蜜5.0帮助商家转人工率降低20%以上，店铺成交转化率提升35%以上。

店小蜜通过底层技术架构的全面升级，大幅提升了店小蜜机器人在知识管理、知识检索和召回等方面的能力，年化成交额增加数十亿，人工服务量下降20%，覆盖商家数增长10倍。”

AI客服质量升级主要体现在智能首页问候、售前精准问答及导购、售后高效服务等方面。

相比起传统AI客服千篇一律的问候和回应，店小蜜5.0会在消费者每一次进线时，动态生成消费者画像并预判意图，精准生成“商品核心卖点+优惠券”组合式种草，或针对物流停滞、发货延迟等场景，在消费者问询前主动提供服务进度通知，实现“开口即服务”的高效体验。

在售前导购对话阶段，店小蜜5.0实现了从传统AI客服“单轮问答”到“多轮探需”的升级。在AI的加持下，店小蜜5.0能够定位买家售前转化的具体环节，精准理解买家发送的文字及图片，主动推理后灵活应对消费者多样化问答，并基于此综合核心产品卖点、服务保障、活动优惠等形成完整的售前种草解决方案包，给消费者提供更真实、个性化的服务。

New Balance智能客服负责人在体验后表示：“过去顾客问一句，机器人干巴巴答一句，像两条平行线。现在Agent会主动对话、会追问细节、会表达情绪。”

在售后阶段，店小蜜5.0以“解决问题”为目标，集成平台能力和商家工单能力，实现售后60%以上的人工工作由机器人自动化处理。在自动生成解释话术及协商方案安抚消费者的同时，店小蜜5.0基于和商家工单系统的联通，实现售后场景关键信息在商家业务部门、仓储、物流服务方等多方自动化流转，具备高效、主动解决售后问题的能力。

对商家而言，店小蜜AI能力的升级也帮助其商家训练师从传统客服机器人繁琐的知识库配置中解放了出来。店小蜜5.0具备自动理解上下文、调取商品属性、结合活动规则算到手价等模型自主学习及推理进化能力，无需训练师再手动配置成千上万的场景答案和关键词和场景。

更重要的是，技术突破带来服务质量全面升级，店小蜜5.0从“被动应答”转变为“主动服务”，真正成为商家的金牌导购和贴心助手，从而创造更高的转化及复购。

目前，店小蜜5.0正面向所有店小蜜商家分批开通中。李宁官方旗舰店智能客服负责人则提到：“回头看日常接待，已经完全没有了之前‘客服忙到炸、客户等得烦’的混乱。店小蜜Agent 解决75% 的简单问题，客服专注20% 的复杂问题，人力成本降了、客户满意度升了、客服价值也体现了，这就是新版工具最实在的价值。”

微软外呼机器人

【2025-11-16】微软语音呼叫系统

微软提供的AI呼叫中心解决方案（概念版），Azure+OpenAI，API请求或直接拨号，AI语音客服即可接/打电话、记录报修、面试预约等。

• 可以呼入、呼出
• 实时语音对话，支持打断、静音检测、多语言TTS/ASR、定制AI语音
• 通话结束后即生成一个网页报告
• 写工单可自定义字段，比如时间、地点、其他信息等
• 可定制任务流、知识库管理、定制AI语气风格

github 地址 call-center-ai

---
title: Claim AI component diagram (C4 model)
---
graph LR
  agent(["Agent"])
  user(["User"])

  subgraph "Claim AI"
    ada["Embedding<br>(ADA)"]
    app["App<br>(Container App)"]
    communication_services["Call & SMS gateway<br>(Communication Services)"]
    db[("Conversations and claims<br>(Cosmos DB)")]
    eventgrid["Broker<br>(Event Grid)"]
    gpt["LLM<br>(gpt-4.1, gpt-4.1-nano)"]
    queues[("Queues<br>(Azure Storage)")]
    redis[("Cache<br>(Redis)")]
    search[("RAG<br>(AI Search)")]
    sounds[("Sounds<br>(Azure Storage)")]
    sst["Speech-to-text<br>(Cognitive Services)"]
    translation["Translation<br>(Cognitive Services)"]
    tts["Text-to-speech<br>(Cognitive Services)"]
  end

  app -- Translate static TTS --> translation
  app -- Sezarch RAG data --> search
  app -- Generate completion --> gpt
  gpt -. Answer with completion .-> app
  app -- Generate voice --> tts
  tts -. Answer with voice .-> app
  app -- Get cached data --> redis
  app -- Save conversation --> db
  app -- Transform voice --> sst
  sst -. Answer with text .-> app
  app <-. Exchange audio .-> communication_services
  app -. Watch .-> queues

  communication_services -- Load sound --> sounds
  communication_services -- Notifies --> eventgrid
  communication_services -- Transfer to --> agent
  communication_services <-. Exchange audio .-> agent
  communication_services <-. Exchange audio .-> user

  eventgrid -- Push to --> queues

  search -- Generate embeddings --> ada

  user -- Call --> communication_services

结束