1. 项目概述运营商工单系统到底卡在了哪里在通信行业干过几年运维或数字化的人几乎都逃不过一类东西工单。装维工单、故障工单、投诉工单、网络优化工单、政企业务开通单……我见过一个中等规模的省级运营商一天的工单量能做到几十万张高峰期翻倍。这些工单从客服、网管、营业厅、集客经理等十几个入口涌进来格式五花八门有的带故障码有的就是一句“用户家里网不好”有的是大段语音转文字。过去的人工分拣模式靠班组长抢单、凭经验派发结果是流转慢、错派多、回退率居高不下最终用户感知就是“报修没人理、处理没人跟”。这个项目的核心就是用一套基于大模型能力和任务编排的智能Agent体系把传统工单系统里“人肉分类—人工路由—被动响应—手工闭环”的链路改造成“自动分类—智能路由—工具调度—闭环跟踪”的自动化闭环。这听起来像是把一套Ticketsystem加了个AI外壳但真正落地时你会发现它远不是加个ChatGPT外挂那么简单。它涉及的是和存量BSS/OSS系统的深度集成、模型选型、任务拆解、异常回退机制以及一整套围绕“可靠性”的工程设计。这篇文章的目标读者是正在做运营商数字化、政企IT支撑、或者大客服系统改造的同行。如果你手头也在琢磨怎么用大模型处理海量工单或者正在为“智能工单系统到底怎么选型”发愁这篇东西应该能给你几条可以直接落地的思路。下文所有方案要么是我在项目里实际验证过的要么是结合行业实践梳理出来的可靠替代路径关键参数和选型理由我会一并讲清楚。2. 整体设计思路工单智能Agent不是“一个机器人”是一套流水线很多人一上来就想要一个“能读工单、能回工单”的机器人这是个大误区。真实运营商场景里工单处理链条长、系统多、职责划分复杂一个Agent根本吃不下整个流程。我的做法是先拆流水线再定Agent的边界。2.1 从“人找人”到“系统找人”四个核心环节的职责切分我把整个工单智能处置拆成四个环节分类识别、路由分发、处置执行、闭环验证。四个环节对应四类能力可以共用一个Agent内核但在工程上要解耦。分类识别解决的是“这张工单到底是什么问题”。比如“家里宽带频繁掉线”“IPTV看一会儿就卡”“政企专线延迟高”这三句话如果落到传统规则引擎里得堆几百条正则。落到大模型或者精调过的文本分类模型上就是一次高并发推理。这里要说明一下我并不是上来就推荐上大模型分类这种高频低难度任务小模型性价比更高后面选型章节我会展开。路由分发解决的是“这单该给谁”。运营商的组织架构里家宽故障和政企专线故障往往分属不同部门甚至同一个专业下还分一二线。传统路由靠工单类型映射表但工单描述有歧义时映射表就失灵了。智能路由要在分类结果之上结合区域、设备归属、服务等级协议等结构化字段输出一个带置信度的目标队列。处置执行是最复杂的一环。一部分工单可以自动化处置比如远程重启光猫、下发配置、查账详单另一部分则要辅助人工比如生成处理建议、调取历史工单、整理影响范围。这里Agent的角色从“分拣员”变成了“参谋”。我在设计时把处置执行拆成了工具调用层和决策层两层避免Agent权限过大导致误操作。闭环验证负责“最后一步”。工单处理完不算完要验证是否真的解决。运营商最头疼的就是工单已办结但用户继续投诉也就是假闭环。Agent要在办结后自动回访、自动巡检指标、自动比对前后状态确认无误才能归档否则打回重处理。2.2 目标架构存量系统之上搭一层Agent编排层很多厂商喜欢推“颠覆式重构”把工单系统整个换掉。我的观点是运营商核心系统动不得尤其是计费、网管、CRM这些系统经历了多次割接牵一发动全身。智能Agent要做的是在存量系统之上叠加一个“智能编排层”不改动底层数据模型只对接接口和消息队列。目标架构里最关键的组件是Agent编排引擎。它负责接收全量工单事件调用分类模型推理查路由策略表调度处置工具记录每一步的决策日志。整套流程跑在事件驱动框架上——工单进入消息队列编排引擎消费并触发流程每一步的状态都持久化到流程实例表里。这里有个容易被忽视的点所有外部系统交互都要走适配层不让Agent直接碰核心库。比如要给光猫下发重启指令Agent只负责生成“意图”具体指令的翻译和执行由适配层完成。这样即便Agent推理出错也不会直接对现网产生破坏性操作。这也是整个设计里我认为最值得坚持的一条原则。3. 分类路由模块让机器先学会“读题”再学会“分诊”分类路由是整个Agent体系的入口如果这一层错了后面所有环节都错。我见过不少项目把精力全放在处置模型上结果分类准确率只有85%路由错派率居高不下最终AI反而成了新的故障源。所以这个模块值得单独花大篇幅讲透。3.1 分类模型选型为什么我用“小模型打底、大模型兜底”的双层策略运营商工单分类面临一个特殊矛盾样本量大、标注成本高、类别极不均衡。故障类、咨询类、投诉类工单占比可能差两个数量级。如果只用生成式大模型做分类一是单次推理成本压不下来二是时延不稳定高峰期排队会堵死入口。但只用传统的BERT类小模型又很难处理口语化、错别字、方言转写等噪声。最终我采用双层策略。第一层用精调过的中文文本分类模型常见的可选方案有ERNIE 3.0、BERT-base、以及一些开源的工单分类模型。这一层做粗粒度分类输出大类比如“家宽故障”“政企故障”“计费咨询”“投诉升级”等。第二层只对第一层置信度低于阈值的样本交给大模型做细粒度判定。这样做的好处很明显80%以上的样本由小模型低时延处理剩余疑难杂症交给大模型整体成本可控。这里给一个分类类别的设计经验不要一开始就设计五十个细类先从一级类目做起稳定后再拆二级类目。我见过一个项目组花一个月定义了六十多个工单类型结果标注一致性只有70%模型训练出来效果很差。类别越细边界越模糊人都不一定分得清机器更难。3.2 路由策略设计规则为骨、模型为魂、置信度兜底分类拿到的是“问题类型”路由要解决“派给谁”。这两者不是一一对应的。举个例子“家宽故障”可能派给装维班组但如果这个用户是企业客户即使问题相同也要走政企专线故障通道。这就是为什么路由不能只依赖分类结果必须结合结构化字段做综合决策。我的路由策略是一个三段式流水线。第一段是规则引擎把“产品类型区域服务等级故障类型”组合成路由键查映射表直接定位到目标队列。规则引擎的命中率能做到60%以上这部分完全可解释、可审计也符合运营商对流程合规的要求。第二段是模型路由对规则未命中的工单用小模型或大模型综合判断工单描述中隐含的组织归属、技术栈归属输出候选队列及置信度。第三段是回退机制低于阈值的工单不进自动路由进入人工池由班组长人工分派。3.3 分类路由的落地细节预览队列、热更新、阈值调参分类路由上线后运维团队最关心的不是准确率而是“错派率”。错派一张工单意味着一个用户问题被多个部门踢皮球比慢派更损害感知。所以我坚持在自动路由前设置一个“预览期”系统给出推荐队列和理由但不直接推送让班组长审核一周积累人工修正样本再逐步放开自动执行比例。阈值调参方面我建议盯住三个指标分类置信度、路由置信度、人工修正率。如果一个队列的人工修正率持续偏高说明该队列的映射规则或模型阈值有问题需要单独复盘。此外分类模型要支持热更新因为运营商经常推出新套餐、新业务工单里会出现新词、新概念模型如果冻结半年准确率必然下滑。我通常会安排每周增量训练一次任务用新增标注样本自动触发训练和评估。4. 闭环处置引擎让Agent从“会分”到“会干”再到“干完能验收”分类路由只是把工单送到正确的人手里真正的价值在于处置本身。这个环节最考验工程能力因为Agent要操作真实系统既要解决问题又得不出事故。4.1 处置动作的能力边界哪些动作可以自动化哪些必须人审我做过一个动作分级表把所有处置动作分成L1到L4四个级别。L1是只读操作比如查用户资料、查历史工单、查设备状态Agent可以全自动执行L2是低频低风险写操作比如发短信通知、生成预检报告Agent执行但记录日志L3是可能影响现网的操作比如重启设备、修改配置参数Agent生成建议并提交人工一键确认L4是大范围变更Agent只能输出方案不许直接推送给一线人员执行要提交到变更管理流程。这个分级看起来简单实际是闭环处置安全性的核心。我见过有厂商宣传“全自动处理故障”听着很酷但运营商不敢用因为一旦批量误操作后果是重大通信事故。所以做智能工单Agent技术很重要但更重要的是一开始就明确“哪些事绝对不能全自动”。4.2 状态机驱动的闭环流程工单不是一把梭而是状态流转闭环处置不能设计成一个线性流程因为工单会回退、会挂起、会升级。我在项目里用状态机来建模工单生命周期。大体状态包括待分类、已分类待路由、已路由待处理、处理中、待验证、验证中、已归档、已打回、已升级。每个状态之间的迁移条件必须在代码里显式定义。举个例子“已归档”这个状态不能简单由操作人点击按钮触发。在Agent体系里归档必须有前置条件验证记录存在、用户满意度回访完成、若涉及故障单则关联的告警已恢复。把这些条件做成校验函数不满足则状态机不允许迁移。这样就把“假闭环”从机制上堵死了。4.3 知识库与外呼验证Agent闭环处置的“最后一公里”工单处置后能不能算闭环光看系统指标是不够的。我处理的案例里有一次光猫重启后ping测试通了但用户实际是WiFi信号覆盖问题技术侧指标一切正常用户感知仍然是“网不好”。所以验证环节除了指标比对还要加上用户侧确认这就用到智能外呼或短信问卷。我们的方案是对故障处置类工单在处置完成20分钟后触发智能外呼询问“您家网络是否恢复”用户回复“未恢复”则工单自动打回并附加外呼录音转写文本处理班组可以直接看到用户原话。这个设计上线后重复投诉率明显下降。知识库方面Agent要能自动沉淀每次成功处置的经验把“故障现象处置动作验证结果”三元组写入知识库后续同类工单可复用处置方案。5. 选型逻辑智能Agent的技术栈不是越贵越好而是匹配场景这个话题最容易被厂商带偏。很多方案商上来就推千亿参数大模型、全套AI中台、向量数据库、知识图谱预算动辄几百上千万。但实际跑起来你会发现工单智能Agent的核心不是模型参数规模而是流程编排的稳定性和成本的可控性。5.1 模型选择按任务频率和复杂度分档我习惯把Agent使用的大模型相关能力分成四档。第一档是极高频短文本分类用轻量模型6亿参数以内单次推理成本控制在毫厘级。第二档是高频意图识别和要素抽取用中等规模模型大约70亿参数部署在内部GPU集群。第三档是低频复杂推理比如疑难工单根因分析、多系统关联诊断用公共大模型API或内部大模型集群。第四档是知识问答和总结生成作为辅助能力时延敏感度低可以用性价比高的模型。选型时一定要先算量级。假设日均工单30万张其中20万张需要分类如果用大模型API单张处理成本0.01元算一天就是2000元一年70多万这还只是一个分类环节。所以我把高并发低难度任务全部压在小模型上大模型只处理每天几百到几千张疑难单成本能降一个数量级。5.2 任务编排是选型中最容易被忽视的部分Agent能不能稳定跑起来一半靠模型一半靠编排。我用的编排方案有两条路。一条是自研轻量级状态机加决策引擎适合流程相对固定、各系统接口成熟的企业。另一条是基于主流Agent框架做二次开发适合需要快速迭代、多工具调用的场景。两条路我都试过前者可控性强后者开发效率高没有绝对优劣。这里提一个我踩过的坑市面上很多Agent框架擅长“自由发挥”让模型自主决定调用哪些工具这在工单场景里是危险的。模型可能跳过前置校验直接执行写操作或者陷入工具调用的死循环。我的做法是给Agent套上“工作流外壳”把每一步的选择空间框死模型只能在预设的选项里做选择题而不是自由发挥。这相当于把Agent从“自动驾驶”降级为“辅助驾驶”但可靠性大幅提升。5.3 Agent框架与外部工具集成接口网关和权限隔离是关键Agent要发挥作用就必须接外部工具比如CRM查单、OSS告警查询、网管设备操作、短信网关、外呼平台。每一个接口的对接都涉及协议、鉴权、限流、超时控制。我强烈建议在Agent和外部系统之间加一层统一的接口网关由网关统一负责鉴权、限流、重试和审计日志。权限隔离方面Agent执行任何操作时都要以最小权限原则调用接口。比如查用户资料的Agent只授权读取与工单相关字段的只读权限绝对不能给它一个“全库查询”的数据库账号。这是教训换来的早期测试阶段我就因为图省事统一授权结果Agent在一次异常循环中把某张表的记录拉了几十万条对业务库造成了压力还好是只读查询不然后果更大。6. 落地实施中的常见问题与排查实录再好的设计上线过程中也一定会遇到问题。我把这个项目里最典型的五类问题列出来每类附上排查思路和解决建议供参考。6.1 分类模型准确率达标但路由错派率降不下来现象模型在测试集上分类准确率到了93%但上线后错派率一直有7%左右。排查发现问题不在分类而在路由映射表。同一种分类结果因用户所处区域不同要派到不同班组映射表里区域维度维护得不准确导致一堆工单错派。解决方式是把映射表做成可配置化并在路由前增加“区域归属校验”环节不一致时报警提示。6.2 Agent调用工具超时导致工单卡住现象Agent在调用网管接口时部分设备响应时间超过10秒而编排引擎的默认超时是5秒超时后任务直接失败工单卡在“处理中”。解决方式是区分接口等级核心接口设置30秒超时并可重试一次非核心接口超时后直接降级为“转人工处理”不能让单个接口故障拖死全流程。6.3 大模型输出不稳定导致处置建议不可用现象同样一类故障单大模型有时输出“建议重启光猫”有时输出“请注意光衰建议上门处理”看起来都对但一线人员反而不知道信哪个。解决方式是把处置建议从“自由文本生成”改成“结构化决策树输出”模型只能在预先定义的处置选项中选择并补充参数而不是自由发挥。6.4 知识库内容质量差Agent“学坏”了现象知识库自动沉淀的处置经验里混入了错误处置案例后续Agent把错误方案推荐给一线造成二次故障。解决方式是知识入库前增加质量校验至少满足三个条件才入库工单最终办结成功、用户回访满意、处置动作在预定义安全范围内。不满足任一条件只记录不入库。6.5 高峰期推理队列阻塞现象故障爆发期比如台风天、大面积断网工单量是平日的5倍以上分类模型所在推理集群被打满新工单排队时间超过10分钟。解决方式是建设弹性推理池高峰期自动扩容同时设置多级降级策略GPU集群不可用时自动降级到CPU小模型再不行降级到关键词规则分类保证系统不瘫、工单不丢。7. 效能评估与复盘智能Agent到底值不值得上做了这么多技术工作最后还是要回到一个问题上这套智能Agent体系到底给运营带来了什么。没有量化评估的上线等于没有落地我习惯从效率指标和业务质量指标两个维度做复盘。7.1 效率指标分拣时长和流转时长的前后对比上线前后对比最有说服力的指标有三个。第一是工单首次分拣时长从平均40分钟压到了2分钟以内这个环节的提升最明显因为原来人工是批量处理现在系统实时处理。第二是路由正确率上线前90%上线稳定后达到97%错派导致的跨部门流转明显减少。第三是工单平均关闭时长这部分受处置复杂度影响自动处置类工单缩短了35%但需要人工上门的工单变化不大这也符合预期。7.2 业务质量指标重复投诉率和用户满意度效率提升只是基础我更看重业务层面的变化。原先工单错派会导致用户被转多家单位重复投诉率高上线后重复投诉率下降了约20%。处理完成后的外呼验证让工单闭环的真实性大幅提升以前那种“系统显示办结但用户没感知”的情况明显好转。用户满意度是多种因素的结果但工单处理及时率和准确率的提升在月度满意度评分中有正向拉动。7.3 持续优化的运营机制说几个我可以直接复用的打法这套系统不能上线后就不管。我跑了一个日常优化机制每天对人工修正的工单做一次聚类分析找到反复被修正的模式优先修正路由映射表或补充训练样本。每周对分类模型的混淆矩阵做一次复盘重点关注混淆最严重的类别对增加针对性样本。每月做一次成本复盘统计各档模型的调用量、耗时和费用动态调整模型档位的分配比例。这些机制执行下来系统的准确率不是一成不变的而是像一套持续进化的流水线。现在内部讨论都说这不是上一个项目是给工单系统装了一个不停学习的大脑。作为主导过这类项目的技术负责人我最大的体会是智能Agent在运营商场景的价值不取决于AI模型多先进而取决于它在复杂的存量系统、严格的流程合规和海量的业务压力下能不能稳定地当好一个“辅助角色”。如果要做类似系统我的建议是先别急着选大模型先把工单分类、路由、处置、闭环这四个环节的业务规则梳理清楚再用Agent能力去补规则覆盖不了的空白稳扎稳打。这套思路至少在我们这个项目里是真正跑通了。