先说一个场景早上九点运营商的工单池里已经堆了上千张单子客户投诉宽带断网、政企客户报障专线抖动、装维师傅催改约时间、后台网管提了传输告警工单。这还只是当天的零头全市一天几万张工单如果靠人工一张张读、一单单派干线班组可能到下午三点才把上午的单分完。这中间有多少紧急单被淹在普通咨询里又有多少重复单被几个班组来回踢皮球干过运营商支撑系统的人心里都有数。我做的这套“电信运营商海量工单智能Agent”核心就是解决三件事把工单自动看懂、把工单精准路由给对的班组、再把处理结果闭环核验回去。简单说就是从分类路由到闭环处置让工单在系统里少转圈、不落地、能追踪。这套东西适合谁参考做运营商OSS/BSS支撑的、做企业客服工单智能化改造的、以及手里握着一堆历史工单不知道怎么用起来的同学都能从里面找到可以抄作业的部分。我不会讲那种拿PPT就能演示的架构图而是把我实际上去过的坑、换过的选型、线上跑出来的数据一条条摆出来。1. 为什么运营商工单需要智能Agent而不是传统规则引擎先搞清楚一个前提运营商工单到底难在哪。搞明白这个问题你才知道为什么要上智能Agent而不是把SQL规则写死就完事。1.1 工单处理的三个核心矛盾第一个矛盾是海量。省级运营商的月工单量在千万量级光靠人工分单每个人的日均处理能力上限就在几百张。人不是不行是读文字的速度有天花板而且在连续疲劳状态下误判率会明显抬升。第二个矛盾是杂乱。前端用户的描述永远是不标准的。有人写“宽带没网了”有人写“家里面那个猫一直闪红灯”还有人直接把一张随手拍的照片丢进来。除了自然语言乱还有大量的图片工单、语音转写工单、PDF附件工单各种格式混在一起。文本里还夹杂着小区名、设备名、业务号同一个设备在不同渠道里叫法又不一样。第三个矛盾是时效。运营商对工单处理是有SLA考核的紧急故障工单可能要求十五分钟内响应普通投诉两小时回复超时就进入服务考核扣分。这意味着工单不仅要分得对还要分得快而且得能追踪每一张单子在每一环节里滞留了多久。这三个矛盾叠加在一起传统思路就撑不住了。1.2 规则引擎、纯大模型、智能Agent三者的边界先说规则引擎。如果只做关键词匹配和正则分类比如出现“断网”就是网络故障类单出现“账单”就是计费类单初始准确率看着还行但真实生产环境里语料千奇百怪规则越写越多规则之间互相冲突维护规则的成本比人工分单还高。最关键的是规则引擎只能分单它不会处置不具备推理能力遇到跨部门单就只能干瞪眼。再说纯大模型。有人上来就把Prompt写好、让大模型直接输出工单分类结果测试集上夺目得很准确率九成以上。但实际线上跑起来你会发现三个问题第一是延迟不可控一次分类要两三秒高峰期并行几百个请求时成本直接爆炸第二是行为不可控同样一张单子今天分给网络部明天可能分给客响中心没有确定性输出就无法考核因为不同班的班长会对同一类单子吵起来订不到一个标准第三是幻觉大模型可能在总结工单内容时脑补出故障原因这在生产系统里非常可怕因为工单是要转去修设备的不是写作文。智能Agent的思路则不同它不是用大模型替代全部流程而是由Agent编排工具、规则、知识库、模型共同完成整条工单处理链路。规则能干的用规则模型擅长的用模型需要查企业知识库的走向量检索需要调外部接口的走API编排。Agent的核心价值是“编排”而不是“生成”。这也是我后来给团队反复强调的一句话智能Agent是调度者不是万能答题器。后来我看到网上说的“扣子开发ai agent智能体应用”其实也是同一个思路只不过扣子把Agent搭建门槛拉低到可视化拖拽了核心逻辑仍然是搭一个能调用工具、能走流程、能决策的智能体。我们在运营商场景里底层思路一致只是接的是运营商内部的工单系统和网管接口。2. 整体技术路径拆解从工单进来到闭环处置如果拿一张图把整个系统画出来从工单进到系统到最终归档可以拆成五个环节接入层做多源数据汇聚预处理层做字段标准化分类路由层做意图识别和派单决策处置执行层做自动化操作和人工辅助闭环稽核层做结果核验和知识回流。2.1 整条链路的五个环节第一个环节是接入层。工单来源有客服系统、营业厅、APP自助报障、微信公众号、外呼语音转写、甚至还有邮件和传真别笑运营商体系里传真工单仍然存在。每个来源的格式都不一样有的给了JSON接口有的只能推CSV文件还有的需要定时去拉库。接入层的核心任务是统一数据格式把不同来源的工单全部转成一套内部字段结构。这一步看起来不起眼却是后面所有解析和路由的地基。第二个环节是预处理层。这里要干的事包括OCR识别图片工单里的文字、清洗文本的噪音字符比如表情符号、乱七八糟的标点、解析附件提取结构化信息、识别工单里的关键实体比如用户手机号、装维地址、设备序列号、判断工单紧急程度和重复性。如果不把这一步做好后面的分类模型吃进去的就是一堆脏数据再好的模型也白搭。第三个环节是分类路由层。这也是标题里说的“分类路由”本质上是把“这张工单是什么问题、应该给谁处理”这个决策自动化。我们这里采用了先粗分类再细分派单的两段式结构后面我会展开讲为什么这么设计。第四个环节是处置执行层。根据工单类型执行不同动作。查余额、查停机状态的Agent直接调CRM接口自动答复。宽带拨号异常的Agent推送自排障指引并预约检测。涉及硬件故障的Agent自动生成维修单并分派给对应区域装维班组。需要跨部门协作的Agent参照历史模板生成协作单并附带相关上下文。第五个环节是闭环稽核层。工单不能“派出去就不管了”。Agent要定期巡检工单状态超时的自动催办被退回的自动重新路由工单结单后Agent要抽查处理结果是否真实解决用户问题识别“假性结单”也就是用户问题压根没解决但工单被打成完结的情况。同时把处理结果沉淀回流到知识库和样本池去优化后续分类和处置效果。2.2 两段式分类路由的设计逻辑为什么搞两段式而不是一段式我最初也试过让模型一次输出“业务大类 处理班组 操作动作”三个标签测试集上表现还行实际运营中用起来发现问题很大大类分错了下游的班组和动作肯定跟着错而且一旦出错你很难判断到底是哪个环节的问题存量。两段式是这么设计的第一段是业务大类识别。也就是先把工单分到“宽带装维、移网故障、计费投诉、政企专线、增值业务”等七八个大类。这一层用相对轻量级的短文本分类模型就够了因为大类之间的差别很大不容易混淆。我们用的是基于预训练语言模型微调的文本分类模型类别数量少准确率可以做到97%以上。第二段是细分路由决策。大类确定后再根据更细的语义特征和知识库召回去决定具体派给哪个区域班组、哪种处理策略。这一层只让大模型参与“少量模糊样本”的兜底判断大多数样本走规则和检索。为什么要大模型兜底因为细分意图的边界很模糊比如“家里两个房间有网客厅没网”这一句规则判断是“无线覆盖问题”但经验丰富的客响人员一看就知道大概率是客厅的光猫到路由器之间网线没插好这种隐含物理位置信息的推理规则做不到向量检索也不一定能命中这时大模型就派上用场了。把两段式的收益说清楚就是大类错了后面全错所以大类用最稳的模型细类错了只是部分环节受影响所以细分可以用弹性更大的方案。这个取舍在线上运营里非常重要。2.3 闭环处置不是“通知一声”那么简单很多人理解的闭环处置就是工单处理完了、回复用户一声就算关闭。但在运营商场景里闭环有更严格的要求还有两个核心指标必须盯住第一是SLA时效卡点。工单进入某个环节后开始计时规定时间内必须完成规定动作。Agent要做的不是到时候提醒一下而是在工单进入疲惫期之前就主动干预。举例来说紧急故障工单要求十五分钟响应那就不能等十五分钟再去提醒班长而是把预警时间设在八分钟八分钟还没有人接单Agent就把工单上升一级并通知值班长。这种“提前半拍”的处置逻辑对达成SLA指标很关键。第二是真实性核验。这里有个“假性结单”的老大难问题。装维师傅上门后拍了张照片传回来说“处理完成”但用户过两小时又投诉说没修好。Agent在结单回访前可以做一道质量关卡比对结单描述和原始工单诉求是否一致对不一致的自动打回补充说明。同时对装机离网类工单Agent可以自动触发回访短信或语音机器人外呼根据用户的回复来判断是否真实解决。闭环中还有一个关键动作是知识回流。每一张完结工单都是一条标注数据。处理结果验证正确后把这条数据和当时的分类结果、处置路径关联起来定期增量加入训练集和知识库。这个飞轮转起来之后模型越用越准知识库越积越厚后面很多工单根本就不需要走大模型推理向量检索直接命中历史相似案例就一键处理了。很多团队忽略这一步导致系统上线三个月后准确率不升反降就是因为样本没有更新模型还是半年前的水平。3. 核心环节落地的关键细节与选型清单做这类项目技术选型非常关键选错了后面返工成本极高。我不做厂商绑定式推荐就把自己实测下来的选型和参数列出来说明白为什么选它、不选它怎么样。3.1 工单标准化OCR和正则这关过不好后面全白搭先说OCR因为电信工单里的图片比重真的不小很多用户不会打字直接把光猫的指示灯拍一张照片传上来。再就是装维师傅回传的照片里面有设备铭牌信息我们要从里面识别出设备型号和序列号。图片工单识别方案我们做了两轮选型。第一轮用了云服务OCR识别准确率确实高但有两个问题一是工单图片里有大量用户的家居环境照片涉及隐私合规敏感不能随便上传第三方平台二是高峰期调用要排队延迟不稳定。第二轮改成私有化部署的PaddleOCR实测下来中文识别效果足以满足我们需求最关键的是它支持本地部署图片不用出厂隐私合规这块就踏实了。跑批场景下单张图片的识别速度控制在几百毫秒量级完全扛得住。这里有一个容易踩的坑工单图片经常是竖拍且歪的OCR之前要加一步图像矫正和增强。任何OCR引擎对于倾斜超过一定角度的文字识别率都会断崖式下降。我们在切图策略上调了一个参数把一张长图切成多块再分别识别结果比整张识别要稳得多。不要嫌弃这个笨办法在工单场景里非常有效尤其Windows截图那种长屏截图不切图识别出来全是乱的。再来说正则和实体抽取。运营商工单里的设备号、手机号、地址是最核心的实体必须用规则方式精确抽取而不是让模型“猜”。比如工单里出现“光猫后面写着TEWA-800E”这种描述正则式要把“TEWA-800E”抓出来用户说“我那号码138xxxxxxxx”手机号就必须被准确捕获。实体抽取错误比分类错误更严重因为工单派给装维师傅后他需要拿这些实体去对应设备库操作。实体错误意味着整张工单作废。我强烈建议实体抽取这块用“正则词典模型”三道保险正则负责抽强规则实体词典负责匹配历史工单里的高频设备名和小区名模型只负责从长文本里抽取弱规则实体。不要一开始就上实体识别模型先把词典库做厚这个便宜又可靠。3.2 分类模型的选型与训练数据准备分类模型我们走了一段弯路。最初为了“追求先进”直接拿一个大模型做零样本分类测试集上效果确实漂亮但上了生产后发现两个问题第一是响应延迟一张工单几秒才能返回分类结果用户体验很差第二是费用不可控千万级工单如果平均每单都掉一次大模型接口成本是笔非常大的开销。后来我们回归到“小模型为主、大模型兜底”的混合架构。大类分类用的是预训练语言模型微调出来的轻量分类模型例如基于BERT类中文预训练模型微调的分类模型或者更轻量的TextCNN这部分模型推理延迟在毫秒级GPU资源消耗也很低。我们对比过几种模型的效果整体上预训练语言模型效果最好TextCNN在短文本上也能打但是长文本上会明显拉胯所以最后主线用了预训练模型TextCNN只作为离线benchmark参考。微调样本到底要多少这个问题很多人问过。我们实际测下来大类分类每个类别准备三千到五千条经过清洗的真实历史工单模型效果就能达到95%以上的准确率。五千条是性价比拐点再多对效果提升就非常有限了。细分类分级的路由决策靠的是历史工单的标签映射关系这个不靠模型靠知识库和规则所以样本需求不大反而更依赖运营经验。准备训练数据的关键点在于几个实操注意事项。第一样本要从上一年已结单工单里抽而且要覆盖不同区域、不同季节。因为电信投诉有明显的季节性夏天宽带报障多冬天可能供暖相关的固话问题多一年周期的样本才能保证覆盖。第二标签不要直接抄工单的原始分类字段需要人工复核。因为历史数据里本身就存在大量误派记录拿误派的标签当金标准训练模型学到的就是错误的分类习惯等于把一个坏习惯教给了一个新员工。我们专门拉了一个运营小组抽了两万张历史工单做标签重标注这个前期工作很枯燥但是后面模型的收敛速度会快得多。第三工单分类标签体系要收敛。我发现不少地市的工单类别动辄上百种类别之间互相重叠运维班组自己也说不清差别。在训练模型之前先把标签体系压缩到主干类别二十个以内二级细分控制在五十个左右。标签体系不收敛模型训练就是灾难。3.3 向量检索与历史工单复用行业里都在提RAG在工单自动处置场景里RAG确实是重要组成部分。工程师接到一张工单最快的处理方式不是从头分析而是先翻历史工单里有没有一样的案例、当时的处理过程是什么、结果如何。这个翻历史的过程不能靠人工搜得靠向量检索。具体做法是把历史已完结工单里的“用户原始描述 处理过程 解决结果”拼成一段文本用嵌入模型转换为向量灌入向量数据库。线上来一张新工单就把当前工单的描述文本转成向量去库里做相似度检索找到top5到top10条最相似的历史案例供处置层参考。向量库选型我们用的是Milvus部署相对简单社区活跃支持中文社区常见问题排查。如果团队运维能力不足也可以用一些托管型向量数据库但数据量达到千万级别之后自建Milvus在成本上更可控。嵌入模型用了中文通用向量模型定量向量维度在768维左右单条工单转向量的延迟在几十毫秒量级。相似度检索里有个隐藏的坑相似主题不等于相似问题。两张工单都写了“宽带连不上”但一张是用户欠费停机一张是光猫故障处理方式完全不同。如果向量检索只按文本相似度召回生成的参考方案可能完全误导人。解决思路是在向量检索的召回阶段叠加“业务大类约束”也就是提前用分类模型锁死大类向量检索只在大类内进行。这个组合方式实测下来检索命中准确率能提高十几个百分点。我们测试过如果只靠纯文本相似度召回top5案例的有效率大概在百分之六十几加上大类约束之后能到百分之八十几。这里的“有效率”定义是检索返回的历史案例与当前工单的处置方案可以互相复用。这个指标要单独建一个评测集持续跟踪。3.4 Agent编排框架自研还是用平台Agent编排是整套系统的中枢。要不要自研编排框架还是用低代码平台这个问题很难一概而论。如果你只做试点、场景比较单一可以用现成的Agent开发平台快速拖出一个Demo省去很多工程工作量网上说的扣子这类低代码平台就属于这种思路。但我们最后没有完全依赖平台原因有几个。底因是运营商生产环境对私有化部署和数据不出域有硬性要求外部的可视化Agent平台很难满足所有要求。其次工单系统需要对接大量内部老系统包括计费、CRM、网管告警、装维App这些对接协议多种多样有的还是老掉牙的接口格式低代码平台的连接器生态覆盖不了。所以现在的架构是内部自研一个轻量级的Agent编排引擎负责流程调度和工作流定义外部平台只作为团队内部的Demo原型工具以及做Prompt调试和预演。自研编排引擎的核心要素有三个工作流引擎、工具调用层、决策节点。工作流引擎负责定义“什么时候调用哪个模型、什么时候执行规则、什么时候调接口”工具调用层封装了所有内部系统的API对上层Agent屏蔽接口异构性决策节点是条件分支的集合比如“工单属于政企专线且紧急程度为高则转人工并由Agent生成处置建议”这本质上是一套可配置的决策树。我自己在这个环节的体会是不要一开始就去实现复杂的Agent自主决策先把流程编排跑通也就是把“确定性流程自动化”做到位再去逐步引入大模型的随机性判断。很多团队一上来就追求“全自主智能体”结果模型在关键节点上随机变异工单被投到错误班组运营团队对系统的信任直接崩塌。先做可控可预期的自动化再做有边界的智能化步子稳一些特别好。4. 实操效果、常见踩坑与排查经验这部分我把线上跑出来的真实数据和踩过的坑整理一下比上面那些理论更实用。4.1 实测数据上线前后对比拿我们落地的一个地市分公司来说上线前日均工单量约一万五千张人工分单的准确率在85%左右这是老员工加班盯出来的水平新员工上岗后掉到75%。上线智能Agent之后做了三个月持续迭代最终的稳定数据如下指标上线前上线后三个月备注首派准确率85%93.6%首派即被受理班组认可的占比平均分单时长12分钟40秒从工单接入到路由完成紧急工单响应达标率89%98.2%十五分钟响应SLA口径人工介入比例100%约26%其余为Agent自动处置或自动辅助重复投诉率8.5%5.8%与处理质量密切相关首派准确率提升看起来只有八个多点实际体验差异很大。因为上线前85%的准确率是靠老员工对本地情况的熟门熟路换来的人一旦休假、人手一紧准确率立刻掉。Agent在准确率之外更重要的价值是稳定它不会因为换班、月底疲劳、新员工上岗而出现水平波动这对我们做服务质量管理帮助很大。分单时长从十二分钟降到四十秒是这批指标里改善最明显的。原来人工分单不是分得慢是工单积压后排队排得慢还有跨部门流转时转来转去的等待。Agent晚上和节假日也在跑凌晨来的工单不再趴到第二天早上这是运维体验上最直观的变化。关于人工介入比例需要说明的是26%不等于“剩下74%完全没人看”。有些工单是Agent自动答复后人工抽查有些是Agent生成建议后人工确认执行。真正全自动无人参与的比例在四成左右集中在催缴查询、装维改约、重复性咨询这几类风险较低的场景。高风险的操作类工单我们始终坚持人工在环。4.2 高频踩坑问题速查把我们在上线过程中遇到的典型问题整理成一张速查表后面有新同学接入项目我会先把这张表甩给他。问题现象根因分析解决经验分类模型上线一周后准确率下降训练集时效性不够节假日前后的工单语料分布变化大训练样本按季度滚动更新保留近三个月的新样本权重向量检索召回的历史案例牛头不对马嘴没有加业务大类约束纯文本相似度误导改为“分类模型粗筛 向量库内检索”的级联召回紧急工单被漏掉只看标题判断紧急度正文里才是“全楼断网”这类的描述紧急度识别改为融合标题、正文、用户等级、区域告警状态多重信号同一类工单被派到不同班组标签体系与班组职责边界没对齐牵头梳理标签到班组的映射关系保持一对一的明确主派关系Agent自动答复触怒用户答复模板语气生硬没有解释为什么不能立即处理答复话术模板改为“解释原因 下一步动作 备用渠道”三段式并在自动化答复前加置信度门槛夜间作业无人复核全自动处置没有兜底措施高风险动作一律不自动执行低风险动作自动执行后留存白光证据链第二天人工抽查这里面特别讲一下“夜间作业无人复核”的问题。运营商工单是二十四小时进单的凌晨三点网络割接产生一批工单按照白天设定的全自动策略让Agent直接动作了早上运营团队看到记录后发现问题。后来我们调整了策略夜间只允许Agent做“信息查询类”和“预约类”的自动化动作所有涉及到改用户资费、断用户业务、触发上门安装的动作一律推送到白班队列里待人工确认。这个策略调整让安全性和效率都回归到了让人舒服的位置。另外一个教训是关于“模板化答复”。Agent自动答复看起来简单但话术模板如果直接写“您好您的问题正在处理中”用户不但不满意还会反复投诉。我们后来把答复话术改成了“您反映的光猫红灯问题已预约今天下午两点装维师傅上门届时请保持电话畅通如果需要修改时间可以回复数字1”同时附上装维工号。有具体动作、有时间、有人的信息这类答复的满意率明显高于空泛的模板话术。4.3 灰度上线与效果评测的具体操作最后说下上线策略这是好多人会忽视的部分。整套系统的上线没做什么“一刀切切换”而是用了一个分三阶段的灰度方案这个方案也可以给其他团队参考。第一阶段是“影子模式”周期两周。Agent系统完整跑完整个处理链路但不对外生效只是把分类结果、路由建议、处置方案全部打到日志表里由运营专家每天对比Agent输出和人工实际处理结果的差异。这一阶段主要验证模型的准确率和规则的覆盖率同时把全量工单的真实分布摸清楚。第二阶段是“辅助模式”周期四周。Agent的路由结果作为建议推送给分单员分单员可以选择采纳或者改派。这阶段的核心指标是“算法建议采纳率”如果采纳率低于七成说明模型或者知识库还有问题需要停下来迭代。我们在辅助模式期发现的最大问题是政企专线工单的误判率偏高原因是对专线业务简称的语料覆盖不足比如“MPLS专线”、“OTN电路”、“云专线”这些术语模型经常识别错后来通过往词典库补充业务术语和增加专线类训练样本解决了。第三阶段是“自动模式”周期长期。只有采纳率稳定在九成以上的工单类别才切换到自动路由剩余类别继续保留在辅助模式。整个系统运行平稳后再不断把新的类别加进自动化范围。千万别做一次性全面自动化尤其是不同故障类型的处理方式差异巨大把“查询类”和“维修类”工单混在一个自动化策略里出事概率会很高。效果评测除了前面说的首派准确率、SLA达标率之外还推荐大家盯一个指标叫“误派返工率”也就是工单派出去之后被受理班组退回重新派单的占比。这个指标比首派准确率更能反映运营实际体验因为首派准确率的统计口径有时候会被模糊掉而返工率直接决定了你有没有浪费人家班组的一个处理工时。我们上线前误派返工率在7%左右三个月后降到了2.6%这个数字的下降对一线班组来说感知非常明显。写到这里我其实最想强调的是这类智能Agent项目的成功与否不完全取决于模型选得有多先进反而取决于工程细节做得有多扎实。标签体系不整理用再大的模型也分不对单OCR不调参图片工单就永远要被人工补录规则和模型没有清晰的边界Agent就会在模糊地带反复横跳。先处理干净数据再设计阶梯策略再谈智能化水平这条路我个人替大家先趟过了整体是稳的。如果你准备做类似的工单智能化改造个人建议可以先从最痛的首派准确率入手把一张工单从接入到首次派出的链路自动化跑通再逐步向后端的闭环处置延伸。