news 2026/6/13 22:53:58

企业级 Multi-Agent 需求调研:如何精准捕捉业务痛点与用户需求?

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
企业级 Multi-Agent 需求调研:如何精准捕捉业务痛点与用户需求?

企业级 Multi-Agent 需求调研:如何精准捕捉业务痛点与用户需求?


引言

痛点引入

各位技术负责人、产品经理、AI落地工程师,最近是不是被「企业级 Multi-Agent」(多智能体系统)这个词“轰炸”得晕头转向?从OpenAI DevDay的GPT Store + Assistants API「批量组网」演示,到字节跳动豆包AI Agent Factory的「Agent即API」生产模式,再到阿里通义千问大模型的「AutoGen企业版」「Coze企业私有化方案」,仿佛一夜之间,不搞个Multi-Agent都不好意思说自己在做数字化转型3.0

但我见过的90%以上的企业级Multi-Agent落地项目,都倒在了「需求调研关」——

  • 某制造业搞了个「生产全链路Agent群」,用了8个不同模型的Agent,但业务线只用了其中1个做「订单邮件自动分类」,剩下7个要么功能重叠(比如同时有两个库存预警Agent),要么完全脱离场景(比如强行加了个代码调试Agent给不懂编程的车间主任);
  • 某电商公司搞了个「客服-运营-供应链Agent协作系统」,原型演示时能流畅处理“客户下单没库存→运营临时提需求找代工厂→供应链对接物流」,但上线后天天出bug:客服Agent识别方言成功率只有30%,运营Agent不懂促销规则生成错误库存补充单,供应链Agent对接的旧ERP系统没有开放API;
  • 更绝的是我前东家内部孵化的一个项目:为了蹭Multi-Agent热度,直接把原本用规则引擎就能搞定的「员工报销单自动审核」,拆成了「发票识别Agent」「费用合规Agent」「预算控制Agent」「财务主管初审模拟Agent」「CEO终审模拟Agent」5个模块,技术栈搞了LangChain + AutoGen + 3个云API大模型,成本是规则引擎的20倍,效率还低了15%——因为每个Agent之间的沟通要等大模型生成响应,偶尔CEO模拟Agent还要“假装思考”5秒才能通过(产品经理说这叫「有温度的AI」,财务总监直接骂娘)。

为什么会这样?核心原因不是技术不够成熟——现在的大模型已经具备了基本的推理、协作能力,Agent开发框架也越来越完善(LangChain、AutoGen、MetaGPT、Coze、AgentScope随便挑)——而是我们搞Multi-Agent的需求调研时,还是在用传统的单AI(比如单对话机器人、单图像识别模型)甚至单软件系统的思路:要么只听老板的“拍脑袋需求”,要么只做表面的“用户访谈问卷”,要么没有深入分析业务流程的「可Agent化拆解条件」,要么没有考虑企业的「技术栈兼容性」「数据隐私安全性」「成本ROI」这些落地门槛。

解决方案概述

今天这篇文章,我就结合自己在字节跳动参与过3个百万级别以上日活的内部Multi-Agent项目、作为AI落地顾问帮5家传统制造、电商、金融企业做过Multi-Agent需求调研的经验,给大家分享一套专门针对企业级Multi-Agent的「四维精准需求调研方法论」——

  1. 业务维度:从「战略目标」「业务流程拆解」「关键绩效指标(KPI)」三个层面,找到Multi-Agent能真正解决的「核心业务痛点」,而不是老板的“炫技点”;
  2. 用户维度:采用「角色分层访谈法」「场景模拟法」「痛点量化法」,精准捕捉不同角色(一线员工、中层管理者、高层决策者)的「真实用户需求」,而不是表面的“想要一个AI助理”;
  3. 技术维度:从「大模型选型」「Agent开发框架选型」「企业现有技术栈兼容性」「数据隐私安全性」「成本ROI测算」五个层面,验证需求的「技术可行性」和「经济可行性」;
  4. 落地维度:从「MVP最小可行产品定义」「分阶段落地路径规划」「测试验收标准制定」三个层面,确保需求能「真正落地」,而不是停留在原型演示阶段。

为了让大家更容易理解,我会在每个方法论的后面,都附上我之前帮某国内头部家电制造企业(就叫它「A家电」吧)做的「售后全链路Multi-Agent协作系统」需求调研的真实案例——这个项目最终落地后,售后工单处理效率提升了65%,售后成本降低了32%,一线售后工程师的满意度从3.2分(满分5分)提升到了4.7分,ROI在上线后第8个月就转正了。

最终效果展示(A家电真实案例)

在进入正式的方法论之前,先给大家看一下A家电「售后全链路Multi-Agent协作系统」的最终效果截图(因为涉及企业隐私,我做了模糊处理):

(此处插入3张模糊处理后的截图:

  1. 工单入口:用户通过A家电APP、微信公众号、400电话提交工单后,由「工单智能分派Agent」自动识别用户的问题类型、地理位置、家电型号,然后派给最适合的「备件调度Agent」「技术支持Agent」「售后工程师对接Agent」;
  2. 协作界面:备件调度Agent、技术支持Agent、售后工程师对接Agent在同一个协作界面上沟通,比如用户提交的是「冰箱不制冷」的工单,地理位置在北京市朝阳区,家电型号是BCD-528WKK1FPA:
    • 首先,「备件调度Agent」自动查询朝阳区分中心的备件库存,发现BCD-528WKK1FPA型号的压缩机没有库存,只有蒸发器和温控器有库存,于是自动生成「临时备件调配需求单」,发给北京市总中心;
    • 然后,「技术支持Agent」自动查询BCD-528WKK1FPA型号的维修手册,生成「初步维修方案」(先检查温控器,再检查蒸发器,最后检查压缩机),同时自动调取该用户的历史维修记录(该用户3个月前刚换过温控器),把初步维修方案调整为「先检查蒸发器,再检查压缩机」;
    • 最后,「售后工程师对接Agent」自动查询朝阳区所有空闲的、有5年以上冰箱维修经验的、最近3个月维修过BCD-528WKK1FPA型号的售后工程师,发现只有张师傅符合条件,于是自动把工单、临时备件调配需求单、调整后的维修方案发给张师傅,同时自动预约张师傅明天上午10点上门;
  3. 数据看板:中层管理者和高层决策者可以通过数据看板实时查看售后工单处理效率、售后成本、一线售后工程师的满意度、备件库存周转率等关键指标)。

准备工作

在开始正式的「四维精准需求调研方法论」之前,我们需要先做一些必要的准备工作——这些准备工作虽然繁琐,但能大大提高后续需求调研的效率和准确性,避免走弯路。

环境/工具

1. 需求调研团队组建

企业级Multi-Agent的需求调研,绝对不能只由产品经理或者AI落地工程师单独完成——必须组建一个「跨部门、跨职能的需求调研团队」,团队成员至少应该包括:

  • 业务代表:1-2名来自核心业务线的中层管理者(比如A家电的售后中心副主任),负责提供战略目标、业务流程、KPI等业务层面的信息;
  • 用户代表:2-3名来自核心业务线的一线员工(比如A家电的2名一线售后工程师、1名400电话客服),负责提供真实的用户体验和痛点;
  • 产品经理:1名,负责需求的收集、整理、分析、优先级排序;
  • AI落地工程师:1-2名,负责验证需求的技术可行性、经济可行性;
  • 数据安全专员:1名,负责评估需求的数据隐私安全性;
  • 财务专员:1名,负责协助AI落地工程师进行成本ROI测算。

A家电案例补充:我们帮A家电组建的需求调研团队一共有8人:

  • 业务代表:售后中心副主任李姐(负责售后全链路业务流程)、备件管理科科长王哥(负责备件库存管理);
  • 用户代表:一线售后工程师张师傅(10年维修经验,主要负责朝阳区高端家电维修)、一线售后工程师刘师傅(5年维修经验,主要负责海淀区中端家电维修)、400电话客服组长赵姐(8年客服经验,负责处理高端家电用户的投诉);
  • 产品经理:字节跳动内部产品经理转去A家电做数字化转型顾问的小林;
  • AI落地工程师:我(资深AI落地工程师,负责技术可行性验证)和A家电内部的AI工程师小陈(负责企业现有技术栈兼容性评估);
  • 数据安全专员:A家电信息安全部的小张;
  • 财务专员:A家电财务部的小刘。
2. 需求调研工具清单

为了提高需求调研的效率和准确性,我们需要准备一些专业的需求调研工具

  • 业务流程梳理工具:Lucidchart、Draw.io、Visio(用于绘制AS-IS(现状)业务流程图);
  • 用户访谈工具:Zoom、腾讯会议(用于远程访谈)、录音笔(用于记录访谈内容,注意要提前征得用户的同意)、飞书文档/Notion(用于整理访谈笔记);
  • 痛点量化工具:飞书多维表格/Excel(用于统计痛点的发生频率、影响范围、解决成本);
  • 需求优先级排序工具:RICE评分法、MoSCoW法则、Kano模型(用于对收集到的需求进行优先级排序);
  • 技术可行性验证工具:LangChain Playground、AutoGen Studio、Coze企业私有化版(用于快速搭建原型,验证需求的技术可行性);
  • 成本ROI测算工具:飞书多维表格/Excel(用于计算成本和收益,ROI的计算公式我会在后面的技术维度详细讲)。

基础知识

在开始正式的需求调研之前,我们需要让整个需求调研团队都掌握一些关于企业级Multi-Agent的基础知识——避免在后续的调研中出现“鸡同鸭讲”的情况(比如业务代表不知道什么是「Agent协作协议」,AI落地工程师不知道什么是「售后工单响应时效KPI」)。

1. 什么是企业级Multi-Agent?

首先,我们需要明确「什么是Multi-Agent」——Multi-Agent System(多智能体系统,简称MAS)是由多个自主、灵活、能够相互协作的智能体(Agent)组成的系统,这些智能体可以共享信息、分工合作,共同完成单个智能体无法完成的复杂任务

然后,我们需要明确「什么是企业级Multi-Agent」——企业级Multi-Agent是指专门为企业场景设计的Multi-Agent System,它需要满足企业的「数据隐私安全性」「技术栈兼容性」「成本ROI可测性」「稳定性」「可扩展性」「可维护性」等核心要求,而不是只追求技术的先进性

2. 企业级Multi-Agent的核心组成要素

企业级Multi-Agent一般由以下5个核心组成要素构成:

  1. 智能体(Agent):是Multi-Agent System的基本单元,每个Agent都有自己的「目标」「能力」「记忆」「交互规则」。根据Agent的功能,可以把企业级Multi-Agent分为以下几类:
    • 感知Agent:负责收集和处理外部信息(比如A家电的「工单智能分派Agent」可以感知用户提交的工单信息、地理位置信息、家电型号信息);
    • 决策Agent:负责根据收集到的信息做出决策(比如A家电的「备件调度Agent」可以根据备件库存信息做出临时调配的决策);
    • 执行Agent:负责执行决策(比如A家电的「售后工程师对接Agent」可以自动把工单发给张师傅、自动预约上门时间);
    • 监控Agent:负责监控整个系统的运行状态(比如A家电的「系统监控Agent」可以实时监控每个Agent的响应时间、准确率);
    • 协调Agent:负责协调不同Agent之间的协作(比如A家电的「售后全链路协调Agent」可以协调「工单智能分派Agent」「备件调度Agent」「技术支持Agent」「售后工程师对接Agent」之间的沟通)。
  2. Agent协作协议:是不同Agent之间进行沟通和协作的规则,比如:
    • 消息格式:不同Agent之间发送的消息需要遵循统一的格式(比如JSON格式);
    • 通信机制:不同Agent之间的通信可以采用「同步通信」(比如Agent A发送消息后必须等待Agent B的响应才能继续执行)或者「异步通信」(比如Agent A发送消息后不需要等待Agent B的响应就可以继续执行);
    • 协作模式:不同Agent之间的协作可以采用「顺序协作」(比如Agent A先执行,然后Agent B再执行)、「并行协作」(比如Agent A和Agent B同时执行)或者「混合协作」(比如先并行执行Agent A和Agent B,然后再顺序执行Agent C)。
  3. 知识共享平台:是不同Agent之间共享知识的平台,比如:
    • 企业知识库:比如A家电的维修手册、备件库存信息、用户历史维修记录;
    • Agent记忆库:每个Agent都有自己的短期记忆(比如当前正在处理的工单信息)和长期记忆(比如之前处理过的类似工单的经验);
    • 全局状态库:存储整个Multi-Agent System的全局状态信息(比如当前正在处理的工单数量、空闲的售后工程师数量、备件库存周转率)。
  4. 大模型底座:是企业级Multi-Agent的“大脑”,为Agent提供推理、协作、自然语言处理等核心能力。企业级Multi-Agent的大模型底座一般需要满足以下要求:
    • 私有化部署能力:因为企业的数据涉及隐私,所以大模型底座最好支持私有化部署;
    • 多模态能力:如果企业的场景涉及图像、音频、视频等多模态数据,那么大模型底座最好支持多模态能力;
    • 低延迟、高并发能力:因为企业级场景一般需要处理大量的请求,所以大模型底座最好支持低延迟、高并发能力;
    • 微调能力:因为企业的场景有自己的特殊性,所以大模型底座最好支持微调能力;
    • 可控性:因为企业需要对Agent的输出进行控制(比如不能让Agent泄露企业的机密信息),所以大模型底座最好支持可控性(比如通过提示工程、对齐微调、安全审查等方式)。
  5. 管理监控平台:是企业级Multi-Agent的“控制台”,用于管理和监控整个系统的运行状态,比如:
    • Agent管理:可以添加、删除、修改Agent的配置;
    • 协作流程管理:可以添加、删除、修改Agent之间的协作流程;
    • 监控告警:可以实时监控每个Agent的响应时间、准确率、内存使用情况、CPU使用情况等指标,如果某个指标超过了阈值,就会自动发送告警;
    • 日志分析:可以查看每个Agent的运行日志,分析系统的问题;
    • 数据看板:可以查看整个系统的关键指标(比如A家电的售后工单处理效率、售后成本、一线售后工程师的满意度、备件库存周转率)。
3. 企业级Multi-Agent的适用场景

企业级Multi-Agent并不是“万能药”——它只适用于**「单个智能体无法完成」「需要多个角色分工合作」「有明确的业务流程和规则」「数据相对结构化」**的复杂任务。

企业级Multi-Agent的常见适用场景包括:

  • 售后全链路服务:比如A家电的「售后全链路Multi-Agent协作系统」;
  • 电商全链路运营:比如客服-运营-供应链-物流Agent协作系统;
  • 金融全链路风控:比如客户身份识别Agent-信用评估Agent-风险预警Agent-催收Agent协作系统;
  • 生产全链路管理:比如订单管理Agent-生产计划Agent-库存管理Agent-质量检测Agent协作系统;
  • 医疗全链路诊断:比如患者信息采集Agent-病历分析Agent-影像诊断Agent-治疗方案制定Agent协作系统。

企业级Multi-Agent的不适用场景包括:

  • 完全无规则的创造性任务:比如写小说、画油画(单个创意大模型可能比Multi-Agent做得更好);
  • 只有单个角色就能完成的简单任务:比如员工报销单自动审核(规则引擎可能比Multi-Agent更便宜、更高效);
  • 数据完全非结构化的任务:比如分析一篇10万字的学术论文(虽然大模型可以做到,但Multi-Agent的优势不明显);
  • 对响应时间要求极高的任务:比如股票高频交易(因为每个Agent之间的沟通要等大模型生成响应,延迟太高)。

核心步骤一:业务维度——从战略到流程,找到核心业务痛点

1.1 从企业战略目标出发,锚定Multi-Agent的「价值定位」

很多企业搞Multi-Agent的需求调研时,都是「先找技术,再找场景」——比如先看了OpenAI的GPT Store演示,然后就想“我们公司也搞个类似的东西吧”,结果根本找不到场景。

正确的做法应该是「先找战略,再找场景,最后找技术」——因为企业级Multi-Agent的最终目的是帮助企业实现战略目标,而不是技术炫技。

1.1.1 如何收集企业的战略目标?

收集企业的战略目标,最好的方法是直接访谈企业的高层决策者(比如CEO、COO、CTO)——因为只有他们才知道企业的长期战略目标和短期业务目标。

在访谈高层决策者时,我们可以问以下几个问题:

  1. 长期战略目标:未来3-5年,企业的长期战略目标是什么?(比如A家电的长期战略目标是「成为全球家电行业的售后服务领导者」);
  2. 短期业务目标:未来1-2年,企业的短期业务目标是什么?(比如A家电的短期业务目标是「把售后工单处理效率提升50%,把售后成本降低25%,把一线售后工程师的满意度提升到4.5分以上」);
  3. 当前面临的最大挑战:为了实现这些战略目标和业务目标,企业当前面临的最大挑战是什么?(比如A家电的高层决策者说:「当前面临的最大挑战是售后全链路服务效率太低、成本太高——400电话客服每天要接10000多个工单,工单智能分派的准确率只有40%,剩下60%的工单需要人工二次分派,导致工单响应时效太长;备件库存周转率只有30%,很多备件积压在仓库里过期,同时又有很多备件缺货,导致上门维修的成功率只有70%;一线售后工程师每天要花30%的时间在找备件、查维修手册、和400电话客服沟通上,真正用于维修的时间只有70%,满意度很低」);
  4. 对Multi-Agent的期望:您希望Multi-Agent能帮企业解决哪些问题?(比如A家电的高层决策者说:「我希望Multi-Agent能帮我们解决售后全链路服务效率太低、成本太高的问题——具体来说,就是把工单智能分派的准确率提升到90%以上,把备件库存周转率提升到60%以上,把一线售后工程师花在非维修工作上的时间降低到10%以下」)。

A家电案例补充:我们访谈了A家电的COO王总,王总给我们提供了以下信息:

  • 长期战略目标:未来3-5年,成为全球家电行业的售后服务领导者,售后服务收入占比从现在的10%提升到20%;
  • 短期业务目标:未来1年,把售后工单处理效率提升50%(从现在的平均48小时处理完一个工单,提升到平均24小时处理完一个工单),把售后成本降低25%(从现在的平均每个工单花费200元,降低到平均每个工单花费150元),把一线售后工程师的满意度提升到4.5分以上(从现在的3.2分),把上门维修的成功率提升到90%以上(从现在的70%);
  • 当前面临的最大挑战:售后全链路服务效率太低、成本太高,具体表现在:
    1. 400电话客服每天要接12000多个工单(其中APP和微信公众号提交的工单占60%,400电话提交的工单占40%),工单智能分派的准确率只有38%,剩下62%的工单需要人工二次分派(由售后中心的30名调度员负责),导致工单响应时效太长(平均从用户提交工单到派给售后工程师需要6小时);
    2. 备件库存周转率只有28%,全国有30个分中心,平均每个分中心积压了500万元的过期备件,同时又有很多常用备件缺货(平均每个月有15%的工单因为备件缺货而延迟上门),导致售后成本太高;
    3. 一线售后工程师每天要花32%的时间在找备件、查维修手册、和400电话客服/调度员沟通上,真正用于维修的时间只有68%,而且很多时候上门后才发现备件带错了或者查不到维修手册,导致需要二次上门,满意度很低;
  • 对Multi-Agent的期望
    1. 把工单智能分派的准确率提升到92%以上,把人工二次分派的比例降低到8%以下,把从用户提交工单到派给售后工程师的时间降低到30分钟以下;
    2. 把备件库存周转率提升到55%以上,把过期备件的积压金额降低到每个分中心平均100万元以下,把因为备件缺货而延迟上门的比例降低到5%以下;
    3. 把一线售后工程师花在非维修工作上的时间降低到10%以下,把二次上门的比例降低到5%以下,把一线售后工程师的满意度提升到4.6分以上;
    4. 希望整个系统能在6个月内落地,ROI在上线后12个月内转正。
1.1.2 如何锚定Multi-Agent的「价值定位」?

收集完企业的战略目标和高层决策者的期望后,我们需要从中锚定Multi-Agent的「价值定位」——也就是明确Multi-Agent在企业中的「角色」和「作用」。

企业级Multi-Agent的常见价值定位包括:

  1. 效率提升者:帮助企业提高业务流程的效率,降低人工成本(比如A家电的Multi-Agent的核心价值定位就是「售后全链路效率提升者」);
  2. 成本降低者:帮助企业降低运营成本(比如备件库存积压成本、二次上门成本);
  3. 质量提升者:帮助企业提高业务流程的质量(比如工单智能分派的准确率、上门维修的成功率);
  4. 满意度提升者:帮助企业提高用户和员工的满意度(比如A家电的用户满意度和一线售后工程师的满意度);
  5. 收入增长者:帮助企业增加收入(比如A家电的售后服务收入占比提升)。

A家电案例补充:根据王总的期望,我们锚定了A家电「售后全链路Multi-Agent协作系统」的核心价值定位

售后全链路效率提升者+成本降低者+质量提升者+满意度提升者:通过Multi-Agent协作,提高售后工单处理效率、备件库存周转率,降低售后成本、人工二次分派比例、延迟上门比例、二次上门比例,提高工单智能分派准确率、上门维修成功率、用户满意度、一线售后工程师满意度,最终帮助A家电实现长期战略目标和短期业务目标。

1.2 从AS-IS(现状)业务流程拆解入手,找到Multi-Agent的「可优化节点」

锚定了Multi-Agent的价值定位后,我们需要从AS-IS(现状)业务流程拆解入手,找到Multi-Agent的「可优化节点」——也就是找到那些「耗时最长、成本最高、错误率最高、人工参与最多」的业务节点。

1.2.1 如何绘制AS-IS(现状)业务流程图?

绘制AS-IS(现状)业务流程图,最好的方法是「业务代表主导,用户代表参与,产品经理记录,AI落地工程师观察」——因为只有业务代表和用户代表才最熟悉现状业务流程。

绘制AS-IS(现状)业务流程图的步骤如下:

  1. 确定业务流程的边界:明确业务流程的「起点」和「终点」——比如A家电的售后全链路业务流程的「起点」是「用户提交售后工单」,「终点」是「用户确认工单完成并给出评价」;
  2. 收集业务流程的信息:通过访谈业务代表和用户代表、观察用户代表的工作、查看企业的业务规则文档和历史数据,收集业务流程的信息——比如每个业务节点的「名称」「负责人」「输入」「输出」「耗时」「成本」「错误率」「人工参与度」;
  3. 绘制AS-IS(现状)业务流程图:使用Lucidchart、Draw.io、Visio等工具,按照业务流程的顺序,绘制AS-IS(现状)业务流程图——流程图中应该包括「起点」「终点」「业务节点」「决策节点」「数据节点」「流程线」「负责人」等元素;
  4. 验证AS-IS(现状)业务流程图:把绘制好的AS-IS(现状)业务流程图发给业务代表和用户代表,让他们验证是否正确——如果有错误,就及时修改。

A家电案例补充:我们帮A家电绘制的「AS-IS(现状)售后全链路业务流程图」如下(因为流程图太长,我只放了核心部分,完整的流程图可以在我的GitHub仓库中下载:[链接]):

(此处插入一张模糊处理后的AS-IS售后全链路业务流程图:

  1. 起点:用户提交售后工单(APP/微信公众号/400电话);
  2. 业务节点1:工单信息预处理(400电话客服/APP后台自动识别)——输入:用户提交的工单信息;输出:结构化的工单信息(问题类型、地理位置、家电型号、用户联系方式、用户描述);负责人:400电话客服(处理400电话提交的工单)/APP后台自动识别(处理APP和微信公众号提交的工单);耗时:400电话提交的工单平均10分钟,APP和微信公众号提交的工单平均1分钟;成本:400电话提交的工单平均5元(400电话客服的工资),APP和微信公众号提交的工单平均0.1元(APP后台自动识别的成本);错误率:400电话提交的工单平均8%,APP和微信公众号提交的工单平均3%;人工参与度:400电话提交的工单100%,APP和微信公众号提交的工单0%;
  3. 决策节点1:是否需要人工二次预处理?——判断标准:结构化的工单信息是否完整(比如是否缺少家电型号、地理位置);
  4. 业务节点2:人工二次预处理(400电话客服组长)——输入:不完整的结构化工单信息;输出:完整的结构化工单信息;负责人:400电话客服组长;耗时:平均15分钟;成本:平均8元(400电话客服组长的工资);错误率:平均2%;人工参与度:100%;
  5. 业务节点3:工单智能分派(旧规则引擎)——输入:完整的结构化工单信息;输出:初步分派的售后工程师名单;负责人:旧规则引擎;耗时:平均1分钟;成本:平均0.1元;错误率:平均62%(因为旧规则引擎的规则太简单,只考虑了地理位置和家电类型,没有考虑家电型号、售后工程师的维修经验、空闲时间、历史维修成功率等因素);人工参与度:0%;
  6. 决策节点2:是否需要人工二次分派?——判断标准:初步分派的售后工程师名单是否符合要求(比如是否有空闲时间、是否有足够的维修经验);
  7. 业务节点4:人工二次分派(售后中心调度员)——输入:完整的结构化工单信息、初步分派的售后工程师名单;输出:最终分派的售后工程师;负责人:售后中心调度员;耗时:平均30分钟;成本:平均12元(售后中心调度员的工资);错误率:平均5%;人工参与度:100%;
  8. 业务节点5:备件查询(售后工程师)——输入:完整的结构化工单信息;输出:所需备件的清单;负责人:售后工程师;耗时:平均10分钟;成本:平均3元(售后工程师的工资);错误率:平均10%(因为售后工程师有时候会记错备件型号);人工参与度:100%;
  9. 业务节点6:备件申请(售后工程师)——输入:所需备件的清单;输出:备件申请单;负责人:售后工程师;耗时:平均5分钟;成本:平均1.5元;人工参与度:100%;
  10. 业务节点7:备件审批(备件管理科科员)——输入:备件申请单;输出:审批通过/不通过的结果;负责人:备件管理科科员;耗时:平均20分钟;成本:平均7元;错误率:平均3%;人工参与度:100%;
  11. 决策节点3:备件审批是否通过?;
  12. 业务节点8:备件调度(备件管理科科员)——输入:审批通过的备件申请单;输出:备件出库单、备件派送计划;负责人:备件管理科科员;耗时:平均25分钟;成本:平均8元;错误率:平均5%(因为有时候会派错备件或者送错地址);人工参与度:100%;
  13. 业务节点9:备件派送(第三方物流公司)——输入:备件出库单、备件派送计划;输出:备件送达确认单;负责人:第三方物流公司;耗时:平均24小时(如果分中心有库存)或者平均72小时(如果需要从总中心调配);成本:平均20元(如果分中心有库存)或者平均50元(如果需要从总中心调配);错误率:平均2%;人工参与度:0%(第三方物流公司的人工参与度不算在A家电的成本里);
  14. 业务节点10:维修手册查询(售后工程师)——输入:完整的结构化工单信息;输出:维修手册;负责人:售后工程师;耗时:平均15分钟;成本:平均4.5元;错误率:平均8%(因为有时候会查错维修手册);人工参与度:100%;
  15. 业务节点11:用户预约上门时间(售后工程师)——输入:完整的结构化工单信息;输出:上门时间确认单;负责人:售后工程师;耗时:平均10分钟;成本:平均3元;人工参与度:100%;
  16. 业务节点12:上门维修(售后工程师)——输入:完整的结构化工单信息、备件、维修手册、上门时间确认单;输出:维修完成确认单;负责人:售后工程师;耗时:平均60分钟(如果是简单问题)或者平均120分钟(如果是复杂问题);成本:平均60元(如果是简单问题)或者平均120元(如果是复杂问题)(售后工程师的工资+差旅费);错误率:平均15%(因为有时候会修错或者备件带错);人工参与度:100%;
  17. 决策节点4:是否需要二次上门?——判断标准:维修是否完成;
  18. 业务节点13:工单回访(400电话客服)——输入:维修完成确认单;输出:用户评价;负责人:400电话客服;耗时:平均5分钟;成本:平均2.5元;人工参与度:100%;
  19. 终点:用户确认工单完成并给出评价)。
1.2.2 如何找到Multi-Agent的「可优化节点」?

绘制完AS-IS(现状)业务流程图后,我们需要从中找到Multi-Agent的「可优化节点」——也就是找到那些「耗时最长、成本最高、错误率最高、人工参与最多」的业务节点。

为了更直观地找到可优化节点,我们可以制作一个「AS-IS业务节点分析表」——表格中应该包括「业务节点名称」「负责人」「输入」「输出」「平均耗时」「平均成本」「错误率」「人工参与度」「是否可Agent化」「可优化空间」等列。

可Agent化的判断标准(这是我根据自己的经验总结出来的,大家可以根据实际情况调整):

  1. 有明确的输入和输出
  2. 有明确的业务规则和流程
  3. 不需要完全的创造性思维
  4. 数据相对结构化
  5. 人工参与度超过50%(或者错误率超过10%,或者平均耗时超过10分钟)。

可优化空间的计算方法(可选):

  • 效率提升空间:(现状平均耗时 - Agent化后预计平均耗时)/ 现状平均耗时 × 100%;
  • 成本降低空间:(现状平均成本 - Agent化后预计平均成本)/ 现状平均成本 × 100%;
  • 错误率降低空间:(现状错误率 - Agent化后预计错误率)/ 现状错误率 × 100%;
  • 综合可优化空间:(效率提升空间 × 0.4) + (成本降低空间 × 0.3) + (错误率降低空间 × 0.3)——权重可以根据实际情况调整。

A家电案例补充:我们帮A家电制作的「AS-IS业务节点分析表」如下(因为表格太长,我只放了核心的可优化节点,完整的表格可以在我的GitHub仓库中下载:[链接]):

业务节点名称负责人平均耗时平均成本(元)错误率人工参与度是否可Agent化可优化空间(综合)
工单智能分派旧规则引擎1分钟0.162%0%是(需要升级为Agent,引入家电型号、售后工程师的维修经验、空闲时间、历史维修成功率等因素)90%
人工二次分派售后中心调度员30分钟125%100%是(如果工单智能分派的准确率提升到92%以上,人工二次分派的比例会降低到8%以下,剩下的8%可以由一个协调Agent处理)95%
备件查询售后工程师10分钟310%100%90%
备件申请售后工程师5分钟1.50%100%90%
备件审批备件管理科科员20分钟73%100%是(可以设置一些自动审批规则,比如常用备件、金额低于500元的备件可以自动审批,剩下的可以由一个协调Agent处理)90%
备件调度备件管理科科员25分钟85%100%90%
维修手册查询售后工程师15分钟4.58%100%是(可以引入历史维修记录,生成个性化的维修方案)90%
用户预约上门时间售后工程师10分钟30%100%是(可以自动查询用户的空闲时间和售后工程师的空闲时间,生成几个可选的上门时间,让用户选择)90%

根据「AS-IS业务节点分析表」,我们找到了A家电「售后全链路Multi-Agent协作系统」的10个核心可优化节点

  1. 工单信息预处理(虽然APP和微信公众号提交的工单已经自动识别,但400电话提交的工单还可以用语音识别Agent优化);
  2. 人工二次预处理;
  3. 工单智能分派;
  4. 人工二次分派;
  5. 备件查询;
  6. 备件申请;
  7. 备件审批;
  8. 备件调度;
  9. 维修手册查询;
  10. 用户预约上门时间。

1.3 从关键绩效指标(KPI)验证入手,确认可优化节点的「业务价值」

找到了可优化节点后,我们需要从关键绩效指标(KPI)验证入手,确认可优化节点的「业务价值」——也就是确认优化这些可优化节点后,能否帮助企业实现战略目标和短期业务目标。

1.3.1 如何收集企业的关键绩效指标(KPI)?

收集企业的关键绩效指标(KPI),最好的方法是访谈业务代表和查看企业的历史数据报表——因为只有业务代表才最清楚企业的KPI,只有历史数据报表才能反映KPI的现状。

在访谈业务代表时,我们可以问以下几个问题:

  1. 售后全链路服务的核心KPI有哪些?
  2. 每个核心KPI的现状是多少?
  3. 每个核心KPI的目标值是多少?
  4. 每个核心KPI的计算公式是什么?
  5. 每个核心KPI的影响因素有哪些?

A家电案例补充:我们访谈了A家电的售后中心副主任李姐,李姐给我们提供了以下信息:

  • 售后全链路服务的核心KPI
    1. 工单响应时效:从用户提交工单到派给售后工程师的时间;
    2. 工单处理时效:从用户提交工单到用户确认工单完成的时间;
    3. 工单智能分派准确率:初步分派的售后工程师符合要求的比例(符合要求的定义:有空闲时间、有5年以上对应家电类型的维修经验、有对应家电型号的维修经验、历史维修成功率在90%以上、地理位置在用户所在的区域内);
    4. 人工二次分派比例:需要人工二次分派的工单数量占总工单数量的比例;
    5. 备件库存周转率:年度备件销售成本/平均备件库存金额;
    6. 延迟上门比例:因为备件缺货或者其他原因延迟上门的工单数量占总工单数量的比例;
    7. 二次上门比例:需要二次上门的工单数量占总工单数量的比例;
    8. 上门维修成功率:一次上门就完成维修的工单数量占总上门维修工单数量的比例;
    9. 售后工单平均成本:年度售后总成本/年度总工单数量;
    10. 用户满意度:用户在工单完成后给出的评价的平均分(满分5分);
    11. 一线售后工程师满意度:一线售后工程师每月填写的满意度调查问卷的平均分(满分5分);
  • 每个核心KPI的现状、目标值、计算公式、影响因素:(因为表格太长,我只放了核心的几个KPI,完整的表格可以在我的GitHub仓库中下载:[链接])
KPI名称现状(过去12个月的平均值)目标值(未来12个月的平均值)计算公式影响因素(优先级从高到低)
工单响应时效6小时30分钟Σ(每个工单的响应时效)/ 总工单数量1. 工单智能分派准确率;2. 人工二次分派比例;3. 工单信息预处理时间
工单处理时效48小时24小时Σ(每个工单的处理时效)/ 总工单数量1. 备件库存周转率;2. 延迟上门比例;3. 二次上门比例;4. 上门维修成功率;5. 工单响应时效
工单智能分派准确率38%92%初步分派符合要求的工单数量 / 总工单数量1. 是否考虑了家电型号;2. 是否考虑了售后工程师的维修经验;3. 是否考虑了售后工程师的空闲时间;4. 是否考虑了售后工程师的历史维修成功率;5. 是否考虑了地理位置
售后工单平均成本200元150元年度售后总成本 / 年度总工单数量1. 上门维修成本;2. 备件成本;3. 人工成本(400电话客服、售后中心调度员、备件管理科科员、一线售后工程师);4. 二次上门成本;5. 延迟上门成本
1.3.2 如何确认可优化节点的「业务价值」?

收集完企业的KPI后,我们需要从中确认可优化节点的「业务价值」——也就是确认优化这些可优化节点后,能否影响核心KPI,能否帮助企业实现战略目标和短期业务目标。

为了更直观地确认可优化节点的业务价值,我们可以制作一个「可优化节点-KPI映射表」——表格中应该包括「可优化节点名称」「影响的核心KPI」「影响程度(高/中/低)」「优化后预计能给KPI带来的提升/降低」等列。

影响程度的判断标准(这是我根据自己的经验总结出来的,大家可以根据实际情况调整):

  • :优化这个可优化节点后,能直接影响3个以上的核心KPI,或者能直接影响1个核心KPI的50%以上;
  • :优化这个可优化节点后,能直接影响1-2个核心KPI,或者能直接影响1个核心KPI的20%-50%;
  • :优化这个可优化节点后,只能直接影响1个核心KPI的20%以下,或者只能间接影响核心KPI。

A家电案例补充:我们帮A家电制作的「可优化节点-KPI映射表」如下(因为表格太长,我只放了核心的可优化节点,完整的表格可以在我的GitHub仓库中下载:[链接]):

可优化节点名称影响的核心KPI影响程度优化后预计能给KPI带来的提升/降低
工单智能分派工单响应时效、工单处理时效、工单智能分派准确率、人工二次分派比例、上门维修成功率、二次上门比例工单智能分派准确率从38%提升到92%,人工二次分派比例从62%降低到8%,工单响应时效从6小时降低到30分钟,上门维修成功率从70%提升到85%,二次上门比例从15%降低到8%
备件调度(包括备件查询、申请、审批、调度)工单处理时效、备件库存周转率、延迟上门比例、二次上门比例、上门维修成功率、售后工单平均成本备件库存周转率从28%提升到55%,延迟上门比例从15%降低到5%,二次上门比例从15%降低到5%,上门维修成功率从70%提升到90%,售后工单平均成本从200元降低到160元
维修手册查询(包括引入历史维修记录,生成个性化的维修方案)工单处理时效、二次上门比例、上门维修成功率、一线售后工程师满意度上门维修成功率从70%提升到90%,二次上门比例从15%降低到5%,一线售后工程师满意度从3.2分提升到4.5分
用户预约上门时间工单处理时效、用户满意度、一线售后工程师满意度用户满意度从4.0分提升到4.5分,一线售后工程师满意度从3.2分提升到4.6分

根据「可优化节点-KPI映射表」,我们确认了A家电「售后全链路Multi-Agent协作系统」的可优化节点的业务价值——优化

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/6/13 22:53:24

ALB项目高级技巧:如何最大化利用作弊工具的游戏优势

ALB项目高级技巧:如何最大化利用作弊工具的游戏优势 【免费下载链接】ALB 项目地址: https://gitcode.com/gh_mirrors/alb/ALB 想要在Albion Online中占据绝对优势吗?ALB项目为你提供了终极解决方案!这个强大的作弊工具集合包含了雷达…

作者头像 李华
网站建设 2026/6/13 22:50:02

如何将PyTorch-NPU/dpt_large集成到现有项目中:完整集成方案

如何将PyTorch-NPU/dpt_large集成到现有项目中:完整集成方案 【免费下载链接】dpt_large 项目地址: https://ai.gitcode.com/hf_mirrors/PyTorch-NPU/dpt_large PyTorch-NPU/dpt_large是一款基于PyTorch的深度估计模型,专为NPU(神经网…

作者头像 李华
网站建设 2026/6/13 22:44:52

猫抓浏览器扩展完全指南:5个简单步骤掌握视频资源下载技巧

猫抓浏览器扩展完全指南:5个简单步骤掌握视频资源下载技巧 【免费下载链接】cat-catch 猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension 项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch 你是否曾经在浏览网页时发现…

作者头像 李华
网站建设 2026/6/13 22:41:01

如何快速上手Swin Transformer v2:从零开始的图像分类指南

如何快速上手Swin Transformer v2:从零开始的图像分类指南 【免费下载链接】swinv2-large-patch4-window12-192-22k 项目地址: https://ai.gitcode.com/hf_mirrors/GuangxiAICC/swinv2-large-patch4-window12-192-22k Swin Transformer v2是微软研究院推出的…

作者头像 李华
网站建设 2026/6/13 22:39:55

Sunshine游戏串流:如何打造你的个人云端游戏中心?

Sunshine游戏串流:如何打造你的个人云端游戏中心? 【免费下载链接】Sunshine Self-hosted game stream host for Moonlight. 项目地址: https://gitcode.com/GitHub_Trending/su/Sunshine 你是否曾经梦想过在任何设备上都能流畅游玩PC上的3A大作&…

作者头像 李华
网站建设 2026/6/13 22:39:52

GriddyCode实战指南:基于Godot的视觉化代码编辑器深度解析

GriddyCode实战指南:基于Godot的视觉化代码编辑器深度解析 【免费下载链接】griddycode A code editor made with Godot. Code has never been more lit! 项目地址: https://gitcode.com/GitHub_Trending/gr/griddycode GriddyCode是一款基于Godot引擎开发的…

作者头像 李华