客服场景实战：多智能体如何完成分流、检索、工单与回访

客服场景实战多智能体如何完成分流、检索、工单与回访一、 引言 (Introduction)钩子 (The Hook)你有没有过这样的经历周一早上打开手机发现手机银行APP的转账限额被莫名其妙降到了1000元急得像热锅上的蚂蚁。赶紧点开APP里的“在线客服”——上来是机器人在应付要么重复“请检查您的账户状态”要么翻来覆去那几个没用的FAQ好不容易绕了三圈终于转了“人工客服”结果前面排队还有127个人屏幕上跳着“预计等待时间2小时37分”……等终于接通人工你已经迟到了十分钟的部门早会错过汇报一肚子火还得耐着性子跟客服重复一遍APP里转了半天没解决的问题。更糟的是客服查了十分钟后台跟你说“这个问题比较复杂我帮您转技术岗同事跟进24小时内会有人联系您”——结果第三天下午才收到回访问题解决已经是周末了。这段经历你、我、他她大概率都至少遭遇过3次以上——据艾瑞咨询2024年Q1的《中国智能客服行业发展白皮书》显示传统人工客服的平均问题解决率仅为62.7%用户满意度不足40分满分100单客单次服务成本高达37.9元而早期单一大模型客服机器人虽然解决了“响应快”的问题但FAQ匹配准确率不足68%复杂业务的转人工率超过90%本质上还是个“话术复读机转人工引导员”。怎么办难道就没有一种既能快如闪电响应所有问题又能像资深人工客服一样精准解决60%以上的复杂业务甚至能自动处理不需要权限的高复杂度业务还能把单客单次服务成本压到10元以下的方案吗答案是——有而且已经在美团、京东、腾讯云、招商银行信用卡中心等头部互联网、金融、科技公司大规模落地单一大模型客服机器人已经进化到了“多智能体协同客服系统”的2.0阶段。定义问题/阐述背景 (The “Why”)问题背景传统客服纯人工和早期智能客服单一大模型/规则机器人的痛点本质上是**“单一主体能力边界受限”“人工成本高企与服务质量、响应速度矛盾不可调和”“服务流程割裂信息孤岛严重”**这三大核心问题导致的单一主体能力边界受限纯人工客服每个人的知识储备、业务熟练度、情绪稳定性、多任务处理能力都是有限的——资深人工可能能处理95%的业务但培训成本高达每人3-6个月离职率却常年在40%-60%新人工可能连基础的FAQ都答不利索半年内离职率甚至超过80%。单一大模型/规则机器人规则机器人完全靠人工预设的规则树和关键词匹配覆盖场景极其有限通常只能覆盖5%-10%的高频简单问题遇到规则树没覆盖的问题哪怕只是稍微改了个说法比如把“转账限额被降了”说成“为什么我现在只能转1000块钱了以前明明能转5万的”就直接卡壳转人工。单一大模型客服虽然解决了“关键词匹配不灵活”的问题但大模型是通用型工具没有“客服场景专属知识库”“业务权限控制”“服务流程记忆”“专业工具调用能力”——它可能会给你一堆“如何检查转账限额”的通用建议但绝对不会去查你的银行后台流水、风控记录、实名认证状态它可能会给你“转人工服务”的引导但绝对不会自动帮你生成工单、把问题和你刚才的对话记录一起推给对应的技术岗同事它甚至可能会因为“幻觉”Hallucination给你错误的业务建议比如“您可以直接在我的账户里修改风控等级”——但实际上风控等级只有后台管理员有权限调整导致更大的问题。人工成本高企与服务质量、响应速度矛盾不可调和据智联招聘2024年的《客服行业薪酬报告》显示一线城市的普通客服月薪已经涨到了6000-9000元资深客服月薪甚至超过了15000元加上五险一金、培训成本、场地成本、设备成本单客单次服务成本已经逼近40元——如果要保证“24小时在线”“响应时间≤10秒”“排队人数≤5人”需要的人工客服数量是“正常工作日白天工作时间内人工客服数量”的10-20倍这对于大多数中小企业来说是“不可承受之重”对于头部企业来说也是一笔“巨大的运营开支”。如果为了降低成本减少人工客服数量那么“响应时间”“排队人数”“用户满意度”就会直线下降——据阿里云2023年的《客服效率报告》显示当响应时间超过30秒时用户满意度会下降20%以上当排队时间超过10分钟时转人工放弃率会超过70%当排队时间超过30分钟时转人工放弃率会超过95%。服务流程割裂信息孤岛严重传统客服和早期智能客服的服务流程通常是“割裂”的比如你先在单一大模型客服里问了一堆关于“转账限额被降”的问题然后转了人工客服——人工客服需要你**“重新把刚才的问题说一遍”**因为大模型客服和人工客服后台的对话系统是“分开的”信息无法共享。比如人工客服查了半天后台发现问题比较复杂需要转技术岗同事跟进——人工客服需要你**“提供一下你的手机号、身份证号、账户号、最近的转账记录截图等一堆信息”然后手动填一张纸质或者电子的工单再把工单和这些信息一起通过邮件或者企业微信发给对应的技术岗同事——技术岗同事收到工单后又需要你“重新确认一下刚才的问题和信息”**然后再去查后台解决问题问题解决后技术岗同事需要手动通过邮件或者企业微信通知人工客服——人工客服再手动通过电话或者短信通知你如果你没有及时回复人工客服可能还需要再打几次电话或者发几次短信——整个流程下来少则24小时多则3-5天甚至更久。比如问题解决后通常只有“客服主管”或者“质检专员”会随机抽查一小部分用户的回访——根本无法做到“100%回访”也就无法全面了解用户的满意度和意见建议。问题定义那么什么是“多智能体协同客服系统”它是如何解决这三大核心问题的简单来说多智能体协同客服系统是一种基于大模型通常是多个不同能力的大模型比如通用型大模型、客服场景专属微调大模型、知识图谱检索大模型、工具调用大模型等 知识图谱 RAG检索增强生成技术 Agent智能体技术 业务系统API 工具链比如工单系统、回访系统、风控系统、支付系统等构建的“人机协同、多Agent协同”的新一代智能客服系统。它的核心思路是——把“单一主体”拆分成“多个不同能力、不同分工的智能体”让每个智能体只负责自己擅长的“一小块”业务然后通过“调度智能体”Coordinator Agent把这些智能体连接起来形成一个“协同工作的团队”有的智能体比如“用户意图识别智能体”专门负责“听懂用户的话识别用户的真实意图”有的智能体比如“知识图谱检索智能体”专门负责“从海量的客服知识库中快速找到准确的答案”有的智能体比如“工具调用智能体”专门负责“调用业务系统API和工具链查后台、生成工单、发送短信/邮件等”有的智能体比如“情绪识别智能体”专门负责“识别用户的情绪如果用户情绪激动就自动安抚并优先转人工资深客服”有的智能体比如“回访智能体”专门负责“100%回访用户收集用户的满意度和意见建议”有的智能体比如“知识更新智能体”专门负责“根据用户的对话记录和回访反馈自动更新客服知识库”……这样一来“每个智能体的能力边界都被最大化地缩小专注度和专业度都被最大化地提高”“调度智能体就像‘团队主管’一样根据用户的真实意图和情绪智能地分配任务给对应的智能体让整个服务流程‘无缝衔接’”“知识图谱RAG技术客服场景专属微调大模型解决了大模型的‘幻觉’问题保证了答案的准确性”“业务系统API工具链解决了大模型的‘工具调用能力不足’问题让智能体能够自动处理不需要权限的高复杂度业务”“人机协同让智能体处理80%-90%的高频简单问题和不需要权限的高复杂度问题让人工资深客服只处理10%-20%的需要权限的高复杂度问题和紧急问题既降低了人工成本又保证了服务质量和响应速度”“服务流程记忆信息共享解决了‘服务流程割裂信息孤岛严重’的问题让用户不需要‘重复把刚才的问题说一遍’让整个服务流程‘快如闪电’”。亮明观点/文章目标 (The “What” “How”)亮明观点本文认为多智能体协同客服系统是“客服行业的未来”它将彻底颠覆传统客服和早期智能客服的模式实现“降本、增效、提质、全渠道覆盖、24小时在线、100%回访”的终极目标。文章目标读完这篇文章你将能够全面理解多智能体协同客服系统的核心概念、技术架构、核心要素组成掌握多智能体协同客服系统中最核心的四个模块——“分流模块用户意图识别情绪识别技能路由”“检索模块知识图谱构建RAG检索增强生成”“工单模块工单自动生成工单智能分配工单状态自动更新”“回访模块回访意图识别回访话术生成回访数据收集与分析”——的设计思路、实现原理、核心算法和代码实现通过一个完整的实战项目——“手机银行APP多智能体协同客服系统”——从零开始构建一个简化版的多智能体协同客服系统将学到的理论知识应用到实际场景中了解多智能体协同客服系统的常见陷阱与避坑指南、最佳实践、行业发展与未来趋势对多智能体协同客服系统有一个清晰的认知能够根据自己公司的实际情况选择合适的技术方案和工具构建属于自己的多智能体协同客服系统。文章内容预告本文将按照以下结构展开引言用一个常见的痛点抓住读者的注意力阐述问题背景和定义亮明观点和文章目标基础知识/背景铺垫解释读者在理解文章核心内容前必须知道的关键术语和基本原理比如大模型、RAG技术、知识图谱、Agent技术、多智能体协同等核心内容/实战演练这是文章的主体部分将通过一个完整的实战项目——“手机银行APP多智能体协同客服系统”——从零开始构建一个简化版的多智能体协同客服系统详细讲解四个核心模块的设计思路、实现原理、核心算法和代码实现进阶探讨/最佳实践提供多智能体协同客服系统的常见陷阱与避坑指南、性能优化/成本考量、最佳实践总结结论总结文章最重要的观点或步骤展望未来发展趋势给出行动号召。二、 基础知识/背景铺垫 (Foundational Concepts)在正式进入多智能体协同客服系统的实战演练之前我们需要先掌握一些关键的技术术语和基本原理——这些知识是理解多智能体协同客服系统的“基石”如果没有这些知识后面的实战演练就会变成“空中楼阁”。核心概念定义2.1.1 大模型 (Large Language Model, LLM)核心概念大模型LLM是一种基于深度学习Deep Learning的Transformer架构训练出来的、参数规模通常在数十亿到数万亿之间的、能够理解和生成人类自然语言的通用型人工智能模型。核心原理大模型的核心原理是**“自监督学习Self-Supervised Learning, SSL”“Transformer架构的多头注意力机制Multi-Head Attention”**自监督学习简单来说自监督学习就是“让模型自己从海量的无标注文本数据中学习知识”——不需要人工标注数据只需要把海量的无标注文本数据比如维基百科、新闻资讯、书籍、论文、社交媒体数据等输入到模型中然后让模型做一些“预测任务”比如“预测下一个词是什么”“预测中间缺失的词是什么”“预测一句话的下一句话是什么”等。通过不断地做这些“预测任务”模型会自动学习到文本数据中的“语法规则”“语义关系”“常识知识”“专业知识”等——比如模型会自动学习到“‘苹果’既可以指一种水果也可以指一家科技公司”“‘北京’是中国的首都”“‘转账’需要输入对方的账户号和金额”等。Transformer架构的多头注意力机制Transformer架构是谷歌在2017年发表的论文《Attention Is All You Need》中提出的一种新的深度学习架构——它彻底摒弃了传统的循环神经网络Recurrent Neural Network, RNN和卷积神经网络Convolutional Neural Network, CNN只使用“多头注意力机制”和“前馈神经网络Feed-Forward Neural Network, FFNN”来处理文本数据。多头注意力机制的核心作用是“让模型能够‘关注’到文本数据中的不同部分之间的关系”——比如在处理“为什么我现在只能转1000块钱了以前明明能转5万的”这句话时多头注意力机制会让模型“重点关注”到“只能转1000块钱”“以前能转5万”这两个部分之间的“对比关系”从而更准确地理解用户的真实意图。常见的大模型目前市面上常见的大模型可以分为“通用型大模型”和“垂直领域微调大模型”两类通用型大模型这类大模型是“通用型的”没有针对某个特定的垂直领域进行微调——它们的知识储备非常丰富能够处理各种各样的自然语言任务比如文本生成、文本摘要、文本翻译、问答系统、代码生成等但在某个特定的垂直领域比如客服、医疗、金融、法律等的“专业度”和“准确性”可能不如“垂直领域微调大模型”。常见的通用型大模型有国外OpenAI的GPT-4o/GPT-4 Turbo/GPT-3.5 Turbo、Google的Gemini 1.5 Pro/Gemini 1.5 Flash、Anthropic的Claude 3 Opus/Claude 3 Sonnet/Claude 3 Haiku、Meta的Llama 3/Llama 2等国内百度的文心一言ERNIE 4.0/ERNIE 3.5、阿里的通义千问Qwen 2/Qwen 1.5、腾讯的混元Hunyuan、字节跳动的豆包Doubao、智谱AI的GLM-4/GLM-3等。垂直领域微调大模型这类大模型是“针对某个特定的垂直领域进行微调的”——它们的知识储备可能不如“通用型大模型”丰富但在某个特定的垂直领域的“专业度”和“准确性”要比“通用型大模型”高得多“幻觉”问题也要少得多。常见的垂直领域微调大模型有客服领域百度的文心一言客服版、阿里的通义千问客服版、腾讯的混元客服版、智齿科技的智齿大模型、网易七鱼的七鱼大模型等医疗领域百度的文心一言医疗版、阿里的通义千问医疗版、腾讯的觅影等金融领域百度的文心一言金融版、阿里的通义千问金融版、腾讯的混元金融版等法律领域百度的文心一言法律版、阿里的通义千问法律版、智谱AI的GLM-4法律版等。2.1.2 检索增强生成 (Retrieval-Augmented Generation, RAG)核心概念检索增强生成RAG是一种将“检索Retrieval”和“生成Generation”结合起来的技术——它的核心思路是“在让大模型生成答案之前先从一个‘外部知识库’比如企业的内部文档、FAQ、知识图谱等中快速检索到与用户问题相关的‘上下文信息’然后把这些‘上下文信息’和‘用户的问题’一起输入到大模型中让大模型根据这些‘上下文信息’生成准确的答案”。问题背景为什么需要RAG虽然大模型的能力非常强大但它也有三个“致命的缺点”知识更新滞后大模型的训练数据通常是“截止到某个时间点的”——比如OpenAI的GPT-4o的训练数据截止到2024年5月Google的Gemini 1.5 Pro的训练数据截止到2024年4月百度的文心一言4.0的训练数据截止到2023年12月。如果企业的业务规则、产品信息、FAQ等在大模型的训练数据截止时间之后发生了变化那么大模型就会“不知道”这些变化从而给出“过时的”甚至“错误的”答案——比如企业在2024年6月把手机银行APP的转账限额默认值从5万降到了2万但大模型的训练数据截止到2024年5月那么大模型就会告诉用户“默认转账限额是5万”这显然是错误的。专业知识不足虽然通用型大模型的知识储备非常丰富但它对“企业的内部专业知识”比如企业的内部业务流程、内部规章制度、内部系统的使用方法等了解得非常少甚至完全不了解——比如企业的内部工单系统的使用方法只有企业的员工才知道通用型大模型根本不知道。幻觉问题Hallucination幻觉问题是大模型最“致命的缺点”——简单来说幻觉问题就是“大模型会‘编造’一些看起来很合理但实际上完全不存在的‘事实’或‘信息’”。比如你问通用型大模型“手机银行APP的转账限额被降了应该怎么调整”大模型可能会告诉你“您可以直接在我的账户里找到‘风控等级调整’的入口然后把风控等级从‘高’调整到‘中’这样转账限额就会恢复了”——但实际上手机银行APP里根本没有“风控等级调整”的入口风控等级只有后台管理员有权限调整大模型完全是在“编造”。而RAG技术恰好可以完美地解决大模型的这三个“致命的缺点”知识更新滞后RAG技术的外部知识库是“可以随时更新的”——如果企业的业务规则、产品信息、FAQ等发生了变化只需要把这些变化后的内容更新到外部知识库中RAG技术就可以快速检索到这些变化后的内容从而让大模型生成“最新的”“准确的”答案。专业知识不足RAG技术的外部知识库是“企业的内部专业知识库”——可以把企业的内部业务流程、内部规章制度、内部系统的使用方法、内部文档、FAQ等全部都放到外部知识库中RAG技术就可以快速检索到这些内部专业知识从而让大模型生成“专业的”“准确的”答案。幻觉问题RAG技术的核心思路是“让大模型根据‘检索到的上下文信息’生成答案而不是根据‘大模型自己的知识储备’生成答案”——这样一来大模型就不会“编造”一些看起来很合理但实际上完全不存在的“事实”或“信息”从而大大减少了“幻觉”问题的发生概率。RAG技术的核心流程RAG技术的核心流程可以分为“三个阶段”数据预处理阶段Data Preprocessing这个阶段的主要任务是“把企业的内部专业知识比如内部文档、FAQ、知识图谱等转换成‘大模型和检索系统能够理解的格式’”——通常包括“文档清洗”“文档分块Chunking”“向量化Embedding”“向量存储Vector Storage”这几个步骤文档清洗去除文档中的“无用信息”比如页眉、页脚、广告、链接、重复内容等统一文档的格式比如字体、字号、颜色、段落格式等文档分块把清洗后的“长文档”分成“多个小的文档块Chunks”——因为大模型的“上下文窗口Context Window”是有限的比如OpenAI的GPT-4o的上下文窗口是128K tokensGoogle的Gemini 1.5 Pro的上下文窗口是1M tokens百度的文心一言4.0的上下文窗口是128K tokens如果把“长文档”直接输入到大模型中大模型可能会“读不完”或者“记不住”前面的内容从而影响答案的准确性向量化把每个“小的文档块”转换成“一个高维的向量Embedding Vector”——向量是“大模型和检索系统能够理解的数字表示形式”两个向量之间的“距离比如余弦相似度Cosine Similarity、欧氏距离Euclidean Distance等”越小说明这两个向量对应的“文档块”或“文本”的“语义相似度”越高向量存储把所有的“高维向量”和对应的“文档块的原文”一起存储到“向量数据库Vector Database”中——向量数据库是一种“专门用于存储和检索高维向量的数据库”它能够快速地从“数十亿甚至数万亿个高维向量”中检索到与“用户问题的向量”最相似的“Top K个向量”K通常是5-20。检索阶段Retrieval这个阶段的主要任务是“当用户提出一个问题时快速地从向量数据库中检索到与用户问题最相似的Top K个文档块”——通常包括“问题向量化”“向量相似度计算”“Top K个向量检索”这几个步骤问题向量化用和“文档分块向量化”时“同一个向量化模型Embedding Model”把“用户的问题”转换成“一个高维的向量”向量相似度计算用“向量相似度算法比如余弦相似度Cosine Similarity、欧氏距离Euclidean Distance等”计算“用户问题的向量”和“向量数据库中所有的高维向量”之间的“相似度”Top K个向量检索从向量数据库中检索出“相似度最高的Top K个向量”并取出对应的“文档块的原文”。生成阶段Generation这个阶段的主要任务是“把‘检索到的Top K个文档块的原文’作为‘上下文信息Context’和‘用户的问题’作为‘Query’一起输入到大模型中让大模型根据这些‘上下文信息’生成准确的答案”——通常需要给大模型一个“提示词模板Prompt Template”告诉大模型“应该如何根据上下文信息生成答案”一个简单的提示词模板示例如下你是一位专业的手机银行APP客服人员请你根据以下【上下文信息】回答用户的【问题】。 如果【上下文信息】中没有用户【问题】的答案请你直接告诉用户“抱歉我暂时无法回答您的问题我已经帮您转人工资深客服了请您稍等”不要编造答案。 请你用“通俗易懂、礼貌友好”的语言回答用户的问题。 【上下文信息】 {{context}} 【问题】 {{query}}其中{{context}}是“检索到的Top K个文档块的原文”的占位符{{query}}是“用户的问题”的占位符。2.1.3 知识图谱 (Knowledge Graph, KG)核心概念知识图谱KG是一种用“图Graph”的形式来表示“实体Entities”“属性Attributes”和“实体之间的关系Relationships”的结构化知识库——它的核心思路是“把‘海量的非结构化文本数据’转换成‘结构化的图数据’从而让计算机能够‘理解’这些数据之间的‘语义关系’”。知识图谱的核心要素组成知识图谱的核心要素组成可以分为“三个部分”实体Entities实体是“知识图谱中的‘节点Nodes’”——它是“客观存在的、可以被识别的事物或概念”比如“人”“地点”“组织”“产品”“事件”“概念”等。在手机银行APP的客服场景中常见的实体有用户相关“用户ID”“手机号”“身份证号”“银行卡号”“账户余额”“转账限额”“风控等级”等产品相关“手机银行APP”“转账功能”“理财功能”“贷款功能”“信用卡功能”等业务相关“转账限额被降”“转账失败”“理财赎回失败”“贷款审批失败”等。属性Attributes属性是“知识图谱中的‘节点的属性’”——它是“用来描述实体的‘特征’或‘性质’的”比如“人的姓名”“人的年龄”“人的性别”“地点的名称”“地点的经纬度”“产品的价格”“产品的功能”等。在手机银行APP的客服场景中常见的属性有“用户ID”的属性“创建时间”“最后登录时间”“实名认证状态”等“转账限额”的属性“默认值”“当前值”“调整时间”“调整原因”等“转账功能”的属性“支持的银行”“支持的转账方式”“转账手续费”“转账到账时间”等。实体之间的关系Relationships关系是“知识图谱中的‘边Edges’”——它是“用来描述两个实体之间的‘语义关系’的”比如“人A和人B是朋友关系”“人A在公司B工作”“产品C属于公司D”“事件E发生在地点F”等。在手机银行APP的客服场景中常见的关系有“用户ID”和“手机号”的关系“绑定”“用户ID”和“银行卡号”的关系“绑定”“用户ID”和“转账限额”的关系“拥有”“转账限额被降”和“用户ID”的关系“发生在”“转账限额被降”和“风控等级”的关系“由…导致”“转账功能”和“转账手续费”的关系“包含”。知识图谱的构建流程知识图谱的构建流程可以分为“五个阶段”知识抽取Knowledge Extraction这个阶段的主要任务是“从海量的非结构化文本数据比如企业的内部文档、FAQ、新闻资讯、社交媒体数据等中抽取‘实体’‘属性’和‘实体之间的关系’”——通常包括“实体抽取Named Entity Recognition, NER”“属性抽取Attribute Extraction”“关系抽取Relation Extraction”这几个步骤。知识融合Knowledge Fusion这个阶段的主要任务是“把从‘不同的数据源’中抽取出来的‘相同的实体’‘相同的属性’‘相同的关系’合并在一起消除‘歧义’和‘重复’”——通常包括“实体对齐Entity Alignment”“属性对齐Attribute Alignment”“关系对齐Relation Alignment”这几个步骤。知识存储Knowledge Storage这个阶段的主要任务是“把‘融合后的结构化的图数据’存储到‘图数据库Graph Database’中”——图数据库是一种“专门用于存储和检索结构化的图数据的数据库”它能够快速地从“数十亿甚至数万亿个节点和边”中检索到与“某个实体”相关的“所有的属性和关系”。常见的图数据库有Neo4j、JanusGraph、ArangoDB、OrientDB、NebulaGraph国内等。知识推理Knowledge Inference这个阶段的主要任务是“从‘已有的结构化的图数据’中推理出‘新的知识’”——比如已知“用户A的风控等级是‘高’”已知“风控等级是‘高’的用户的转账限额会被降到1000元”那么就可以推理出“用户A的转账限额会被降到1000元”。知识更新Knowledge Update这个阶段的主要任务是“根据‘新的数据源’或‘用户的反馈’不断地更新知识图谱中的‘实体’‘属性’和‘实体之间的关系’”——保证知识图谱中的知识是“最新的”“准确的”。知识图谱在客服场景中的作用知识图谱在客服场景中的作用主要有“三个方面”提高用户意图识别的准确率知识图谱可以帮助“用户意图识别智能体”更准确地理解用户的真实意图——比如用户问“为什么我现在只能转1000块钱了”知识图谱可以帮助“用户意图识别智能体”理解到“用户的真实意图是‘查询转账限额被降的原因’”而不是“查询转账限额的默认值”或者“查询转账手续费”。提高检索的准确率和召回率知识图谱可以和RAG技术结合起来形成“知识图谱增强的RAG技术KG-RAG”——它不仅可以从向量数据库中检索到与用户问题最相似的Top K个文档块还可以从图数据库中检索到与用户问题相关的“所有的实体、属性和关系”从而大大提高了检索的准确率和召回率。实现“精准的个性化服务”知识图谱可以存储“用户的历史行为数据”比如历史对话记录、历史交易记录、历史登录记录等——“回访智能体”或者“后续的对话智能体”可以根据这些“用户的历史行为数据”为用户提供“精准的个性化服务”比如“如果用户上次问的是‘转账限额被降的原因’这次又问‘转账限额怎么调整’那么就可以直接告诉用户‘您上次问的是转账限额被降的原因是因为您的风控等级被调到了高调整风控等级需要联系后台管理员我已经帮您生成工单了请您稍等’”。2.1.4 智能体 (Agent)核心概念智能体Agent是一种能够“感知环境Perceive Environment”“做出决策Make Decisions”“采取行动Take Actions”“实现目标Achieve Goals”的“自主的Autonomous”“交互的Interactive”“反应式的Reactive”“ proactive的Proactive即主动的”计算机程序或系统。智能体的核心特征智能体的核心特征可以分为“四个方面”自主的Autonomous智能体能够“在没有人类或其他智能体的直接干预下自主地做出决策和采取行动”——它有自己的“目标Goals”“知识库Knowledge Base”“推理引擎Inference Engine”“行动规划器Action Planner”。交互的Interactive智能体能够“与人类、其他智能体或环境进行交互”——它可以通过“自然语言”“图形用户界面GUI”“API”等方式与其他实体进行通信。反应式的Reactive智能体能够“感知环境的变化并及时地做出反应”——比如如果用户的情绪突然变得激动“情绪识别智能体”能够及时地感知到并立即通知“调度智能体”优先转人工资深客服。主动的Proactive智能体不仅能够“对环境的变化做出反应”还能够“主动地寻找机会实现自己的目标”——比如如果“回访智能体”发现某个用户的历史满意度很低那么它可以“主动地”给这个用户打电话询问用户的意见建议而不是等用户来找它。智能体的核心架构智能体的核心架构可以分为“四个部分”感知模块Perception Module这个模块的主要任务是“感知环境的变化收集环境的信息”——比如在客服场景中“对话智能体”的感知模块可以收集“用户的自然语言输入”“用户的情绪信息”“用户的历史行为数据”等。知识库Knowledge Base这个模块的主要任务是“存储智能体需要的‘知识’”——比如在客服场景中“对话智能体”的知识库可以存储“客服场景专属的FAQ”“业务规则”“知识图谱的部分内容”等。推理与决策模块Inference and Decision-Making Module这个模块是智能体的“大脑”——它的主要任务是“根据感知模块收集到的环境信息结合知识库中的知识做出决策规划行动”——比如在客服场景中“对话智能体”的推理与决策模块可以根据“用户的自然语言输入”“用户的情绪信息”“用户的历史行为数据”结合“客服场景专属的FAQ”“业务规则”“知识图谱的部分内容”决定是“直接回答用户的问题”“调用工具查后台”“转人工客服”还是“生成工单”。行动模块Action Module这个模块的主要任务是“执行推理与决策模块规划好的行动”——比如在客服场景中“对话智能体”的行动模块可以“直接回答用户的问题”“调用业务系统API查后台”“通知调度智能体转人工客服”“通知工单智能体生成工单”等。2.1.5 多智能体协同 (Multi-Agent Collaboration, MAC)核心概念多智能体协同MAC是一种将“多个不同能力、不同分工的智能体”连接起来形成一个“协同工作的团队”共同完成一个“复杂的任务”的技术——因为“单一智能体的能力边界是有限的”而“多个智能体协同工作的能力边界是‘无限的’只要你有足够多的不同能力、不同分工的智能体”。多智能体协同的核心模式多智能体协同的核心模式可以分为“三种类型”中心化协同模式Centralized Collaboration Mode这种模式的核心是“有一个‘调度智能体Coordinator Agent’作为‘团队主管’统一管理和调度所有的‘执行智能体Worker Agents’”——所有的执行智能体都必须服从调度智能体的命令调度智能体负责“任务分配”“资源协调”“冲突解决”等。这种模式的优点是“结构简单易于管理和调度”缺点是“调度智能体是‘单点故障’——如果调度智能体出现了故障整个团队就会瘫痪”。这种模式非常适合“客服场景”——因为客服场景的任务通常是“有序的”“可以被分解成多个小的子任务的”而且“调度智能体的任务相对比较简单只需要根据用户的真实意图和情绪智能地分配任务给对应的执行智能体”。分布式协同模式Distributed Collaboration Mode这种模式的核心是“没有‘调度智能体’作为‘团队主管’所有的智能体都是‘平等的’它们通过‘协商Negotiation’‘竞争Competition’‘合作Cooperation’等方式共同完成一个复杂的任务”。这种模式的优点是“没有单点故障——即使某个智能体出现了故障其他智能体也可以继续工作”缺点是“结构复杂难以管理和调度协商和竞争的成本比较高”。这种模式不太适合“客服场景”——因为客服场景的任务通常是“有序的”“需要快速响应的”协商和竞争的成本太高会影响响应速度。混合协同模式Hybrid Collaboration Mode这种模式是“中心化协同模式”和“分布式协同模式”的结合——它既有一个“调度智能体”作为“团队主管”统一管理和调度所有的“执行智能体组Worker Agent Groups”每个执行智能体组内部又是“分布式协同模式”所有的执行智能体组内部的智能体都是“平等的”它们通过“协商”“竞争”“合作”等方式共同完成执行智能体组的任务。这种模式的优点是“既具有中心化协同模式的‘结构简单易于管理和调度’的优点又具有分布式协同模式的‘没有单点故障至少执行智能体组内部没有单点故障’的优点”缺点是“结构比中心化协同模式复杂一些”。这种模式也非常适合“客服场景”——比如可以把“执行智能体”分成“检索组”“工具调用组”“工单组”“回访组”等每个组内部的智能体都是“平等的”它们通过“协商”“竞争”“合作”等方式共同完成组内的任务而“调度智能体”则负责“任务分配”“资源协调”“冲突解决”等。相关工具/技术概览在构建多智能体协同客服系统时我们需要用到很多不同的工具和技术——下面我们就对这些工具和技术进行简要的介绍和对比。2.2.1 大模型平台/API作用大模型平台/API是构建多智能体协同客服系统的“核心基础设施”——它为我们提供了“文本生成”“文本摘要”“文本翻译”“问答系统”“代码生成”“向量化”“工具调用”等能力。常见的大模型平台/API对比大模型平台/API所属公司主要大模型上下文窗口向量化能力工具调用能力国内访问情况价格以1M tokens为例中文输入/输出适合场景OpenAI APIOpenAI美国GPT-4o/GPT-4 Turbo/GPT-3.5 TurboGPT-4o128KGPT-4 Turbo128KGPT-3.5 Turbo16K/128K有text-embedding-3-small/text-embedding-3-large有Function Calling需要翻墙GPT-4o输入约35元输出约105元GPT-4 Turbo输入约20元输出约60元GPT-3.5 Turbo输入约0.8元输出约2.4元通用型多智能体协同系统、预算充足的企业Google Cloud Vertex AIGoogle美国Gemini 1.5 Pro/Gemini 1.5 Flash/Gemini 1.0 ProGemini 1.5 Pro1MGemini 1.5 Flash1MGemini 1.0 Pro32K有text-embedding-004有Function Calling需要翻墙或者使用Google Cloud China RegionGemini 1.5 Pro输入约40元输出约120元Gemini 1.5 Flash输入约0.8元输出约2.4元Gemini 1.0 Pro输入约3元输出约9元需要处理超长文本的多智能体协同系统、预算充足的企业百度文心一言API百度中国ERNIE 4.0/ERNIE 3.5/ERNIE LiteERNIE 4.0128KERNIE 3.5128KERNIE Lite32K有Embedding-V1有Function Calling国内直接访问ERNIE 4.0输入约120元输出约240元ERNIE 3.5输入约12元输出约24元ERNIE Lite输入约0.4元输出约0.8元中文场景的多智能体协同系统、对数据安全要求高的国内企业阿里通义千问API阿里中国Qwen 2/Qwen 1.5/Qwen Turbo/Qwen LiteQwen 2-72B128KQwen 2-32B128KQwen 2-7B32KQwen 1.5-72B128KQwen 1.5-32B128KQwen 1.5-7B32KQwen Turbo128KQwen Lite32K有text-embedding-v2/text-embedding-v3有Function Calling国内直接访问Qwen 2-72B输入约16元输出约48元Qwen 2-32B输入约8元输出约24元Qwen 2-7B输入约0.8元输出约2.4元Qwen 1.5-72B输入约16元输出约48元Qwen 1.5-32B输入约8元输出约24元Qwen 1.5-7B输入约0.8元输出约2.4元Qwen Turbo输入约2元输出约6元Qwen Lite输入约0.4元输出约0.8元中文场景的多智能体协同系统、对数据安全要求高的国内企业、预算有限的企业腾讯混元API腾讯中国Hunyuan Lite/Hunyuan Standard/Hunyuan ProHunyuan Lite3