电信运营商每天要处理的工单量放在省级维度看动辄几十万到上百万条这里面有宽带报障、套餐变更、投诉建议、故障派单、资源核查还有大量重复提交和语义模糊的一句话工单。传统做法是靠规则引擎加人工坐席分拣规则写了几千条维护成本高得离谱新业务一上线就得重新配一遍而且规则之间还会打架。这两年大模型能力成熟之后我陆续参与了几个省级运营商的工单智能化改造项目从最早的用大模型做意图识别这种单点尝试一路做到现在的多智能体协同闭环处置踩过的坑比想象中多得多。这篇就把整套技术路径和选型逻辑摊开讲清楚包括分类路由怎么做、多智能体怎么协同、私有化部署怎么落地、并发怎么扛以及哪些环节看起来简单实际上最容易翻车。1. 工单智能化的真实起点先搞清楚要解决的是哪类问题1.1 运营商工单的三个特殊性很多人一上来就说用AI Agent做智能分类但如果不理解运营商工单的特殊性方案设计一定会跑偏。我总结下来有三个绕不开的特点。第一是工单来源极度分散。客服热线、掌厅APP、微信公众号、线下营业厅、政企客户经理、网管系统自动告警每个渠道的工单格式、字段定义、甚至术语体系都不一样。同一个宽带连不上热线坐席记的是用户反映无法上网网管系统报的是OLT端口告警政企工单写的是专线中断影响业务。如果分类模型只在一个渠道的数据上训练跨渠道迁移时准确率会掉得很厉害。第二是工单语义高度依赖上下文。一条工单写同上、还是老问题、按上次方案处理脱离历史工单根本没法分类。我见过一个案例某省客服系统里重复投诉标签的工单占比超过18%这些工单如果单独看文本模型完全无法判断该路由到哪个处理队列。第三是处置流程涉及多系统联动。一条宽带故障工单分类之后可能要查资源系统确认端口、查网管系统确认告警、查CRM确认用户套餐、最后派给装维人员。这不是一个分类模型能搞定的需要Agent去调用多个系统的API还要处理调用失败、超时、数据不一致的情况。1.2 为什么规则引擎撑不住了早期运营商普遍用规则引擎加工单标签体系我参与过一个项目规则库里有4700多条规则维护团队6个人全职在改规则。问题出在三个地方一是规则爆炸每加一个业务就要加一批规则规则之间优先级冲突越来越难管二是长尾覆盖差规则只能覆盖高频场景低频但重要的工单比如政企专线类经常被误分三是无法处理语义模糊用户写网慢得像蜗牛规则引擎匹配不到任何关键词。大模型介入之后最直接的价值不是替代规则而是把规则从精确匹配升级为语义理解。原来需要写20条规则才能覆盖的宽带故障场景现在一个意图分类Prompt就能搞定而且能处理各种口语化表达。但这里有个关键认知大模型不是用来替代整个工单系统的而是用来做规则引擎做不了的那部分。高频、格式固定的工单规则引擎又快又稳没必要上大模型语义模糊、长尾、需要上下文理解的工单才是大模型的战场。1.3 智能Agent在工单链路中的定位把工单全生命周期拆开看智能Agent能介入的环节其实有五个接入归一化、意图分类、路由决策、处置执行、闭环回访。每个环节对Agent的能力要求完全不同。接入归一化需要的是信息抽取和格式转换能力把多源异构工单统一成标准结构意图分类需要的是语义理解和多标签分类能力路由决策需要的是规则推理和优先级判断能力处置执行需要的是工具调用和多系统协同能力闭环回访需要的是状态跟踪和异常检测能力。我见过不少项目一上来就想做一个全能Agent把所有环节都包了结果每个环节都做得不深。更务实的做法是按环节拆分Agent每个Agent专注一件事通过编排层串联。这也是后面要讲的多智能体协同架构的由来。2. 意图分类与路由从单模型到多级分类的演进路径2.1 单模型分类的天花板在哪里最开始我们用的是单模型多分类方案把一个省的全部工单类别大概200多类交给一个模型做分类。实测下来Top-1准确率能到78%左右Top-3能到91%。看起来还行但放到生产环境就出问题了。问题一是类别不均衡导致的偏置。高频类别宽带故障、套餐咨询样本多模型学得好低频类别政企专线、国际业务样本少准确率只有50%出头。而恰恰是这些低频类别误分的代价最高——政企工单误分到个人业务队列可能延误几个小时。问题二是类别体系本身在变。运营商业务调整频繁今天合并两个类别明天新增三个类别每次变动都要重新训练模型周期太长。问题三是单模型无法处理层级关系。工单类别天然有层级比如宽带故障下面分无法上网、网速慢、频繁掉线单模型扁平分类丢失了这种结构信息。2.2 两级分类架构的设计与实测数据后来我们改成了两级分类架构一级做粗分类大概15-20个大类二级在每个大类下做细分类。这个改动看起来简单效果提升很明显。一级分类用大模型做Few-shot分类每个大类给3-5个示例准确率能到94%以上。二级分类因为类别范围收窄了可以用小模型比如微调后的BERT类模型做推理速度快准确率也能到88%左右。整体算下来端到端准确率比单模型方案提升了约12个百分点。这里有个关键设计一级分类用大模型二级分类用小模型。为什么这么分因为一级分类的类别少、语义跨度大需要大模型的泛化能力二级分类的类别多但语义接近小模型微调后足够用而且推理成本低一个数量级。实测下来这个组合在保证准确率的同时把单条工单的分类成本从0.03元降到了0.008元左右。方案Top-1准确率单条成本新类别上线周期单模型多分类78%0.03元2-3周两级分类大小90%0.008元3-5天纯规则引擎65%0.001元1-2周2.3 路由决策不只是分类结果的转发很多人以为分类完了直接按类别路由就行实际上路由决策要考虑的因素多得多。我总结下来至少有五个维度工单优先级、处理队列负载、处理人技能匹配、SLA时限、历史处理质量。举个例子一条政企专线故障工单分类结果是专线中断但路由到谁如果只看类别可能路由到政企支撑组。但如果当前政企支撑组队列积压了50条工单而隔壁的综合故障组有专线处理资质且负载很低是不是应该动态调整再比如某条工单SLA只剩30分钟是不是应该优先路由给当前在线且处理速度最快的人这些决策靠分类模型做不了需要路由Agent基于规则加实时状态做推理。我们的做法是把路由规则写成结构化的决策表Agent根据分类结果和实时状态查询决策表输出路由目标。决策表可以热更新不需要重新训练模型。2.4 处理分类置信度低工单的兜底策略实测中大概有8%-12%的工单模型分类置信度低于阈值。这些工单怎么处理直接决定了整个系统的可用性。我们的策略是三级兜底置信度在0.7以上的直接路由0.5-0.7的进入待确认队列由人工坐席快速确认平均耗时15秒0.5以下的进入疑难队列由资深坐席处理同时把这些工单作为难例样本回流到训练集。这里有个经验不要追求100%自动分类。强行把置信度阈值调低看似自动化率上去了但误分导致的返工成本更高。我们测算过置信度阈值设在0.7时综合成本最低。低于这个值误分返工成本上升高于这个值人工确认成本上升。3. 多智能体协同为什么单Agent扛不住工单闭环3.1 工单闭环处置的完整链路拆解一条工单从产生到关闭完整链路大概是接入解析 → 意图分类 → 路由决策 → 资源核查 → 派单执行 → 进度跟踪 → 结果回访 → 归档复盘。这八个环节里每个环节需要的能力不同涉及的系统不同失败模式也不同。接入解析要对接6-8个渠道系统处理各种格式异常意图分类要调用模型服务路由决策要查询实时状态资源核查要调用资源系统、网管系统、CRM的API派单执行要对接工单系统和人员调度系统进度跟踪要轮询或订阅工单状态结果回访要触发回访流程归档复盘要写回数据仓库。如果用一个Agent串行做这些事会有两个致命问题一是单点故障任何一个环节卡住整条工单就卡住了二是性能瓶颈串行处理一条工单平均耗时可能到几十秒高峰期根本扛不住。3.2 编排式多Agent架构谁负责决策谁负责执行我们的架构是一个编排Agent加多个执行Agent。编排Agent负责理解工单、制定处置计划、协调执行Agent执行Agent各自负责一个具体能力比如分类Agent、路由Agent、资源核查Agent、派单Agent、回访Agent。编排Agent的核心是计划生成和状态管理。它拿到一条工单后先调用分类Agent拿到类别再根据类别决定需要哪些执行Agent参与然后按顺序或并行调用。每个执行Agent返回结果后编排Agent更新状态决定下一步。这个架构的好处是每个Agent可以独立优化和替换。比如分类Agent从大模型换成小模型只要接口不变编排层不用改。资源核查Agent新增一个系统对接也只影响它自己。3.3 Agent之间的通信协议与状态同步多Agent协同最容易出问题的地方是状态同步。我们踩过的坑是编排Agent认为工单已经派单了但派单Agent实际调用失败了状态不一致导致工单卡住。后来我们引入了统一状态机每个工单有一个状态对象所有Agent的状态变更都要通过状态机。状态机定义了合法的状态转移路径非法转移会被拒绝。比如已派单状态只能从待派单转移过来不能从已归档跳过来。通信协议上我们用的是异步消息加同步回调的混合模式。编排Agent发消息给执行Agent是异步的避免阻塞但关键节点比如派单结果用同步回调确认保证状态一致。3.4 实测中的Agent失效场景与恢复机制实测中遇到过几种典型的Agent失效场景分享出来供参考。第一种是模型服务超时。分类Agent调用大模型API高峰期响应时间从200ms涨到3秒导致编排Agent等待超时。我们的处理是设置分级超时500ms内没返回就降级到小模型2秒内没返回就降级到规则引擎5秒内没返回就转人工。第二种是外部系统API限流。资源核查Agent并发调用资源系统触发限流被拒绝。处理方式是加令牌桶限流同时做请求合并——同一时间多条工单查同一个资源合并成一次查询。第三种是状态机死锁。两个Agent互相等待对方的状态更新导致工单卡死。处理方式是给状态机加超时超过一定时间没有状态变更就触发告警和人工介入。4. 私有化部署运营商场景下的硬约束与选型4.1 为什么运营商必须私有化部署运营商对数据安全的要求是硬约束工单数据包含用户信息、网络拓扑、业务配置绝对不可能走公有云API。这就意味着所有模型必须私有化部署包括分类模型、路由决策模型、以及Agent编排用的基础模型。私有化部署带来的直接约束是显存有限、并发有限、模型更新周期长。公有云上可以随便调GPT-4私有化环境下可能只有几张A100或者昇腾卡要同时跑分类、路由、生成多个模型。4.2 模型选型大模型做理解小模型做分类我们的选型策略是大模型做理解和生成小模型做分类和抽取。具体来说意图分类用微调后的7B模型或者BERT类模型单卡能跑推理延迟控制在100ms以内信息抽取用规则加小模型处理工单里的关键字段用户ID、故障现象、时间编排Agent的决策逻辑用规则加小模型不需要大模型只有需要生成回复话术或者处理复杂语义时才调用大模型。这样分配下来一张A100 80G的卡可以同时跑一个7B分类模型、一个BERT抽取模型、一个7B生成模型支撑的并发大概在50-80 QPS。如果工单峰值是每秒100条就需要2-3张卡做负载均衡。模型类型参数量单卡并发延迟用途分类模型7B30 QPS80ms意图分类抽取模型BERT-base100 QPS20ms字段抽取生成模型7B20 QPS200ms话术生成编排决策规则小模型200 QPS10ms路由决策4.3 推理框架与硬件适配的实操经验推理框架我们试过几种最后选的是vLLM加TensorRT-LLM的混合方案。vLLM负责大模型的推理PagedAttention对显存利用率提升很明显TensorRT-LLM负责小模型的推理延迟更低。硬件适配上有个坑不同批次的卡性能差异很大。我们遇到过同一型号的卡不同批次在FP16精度下推理速度差了30%。后来做了统一的基准测试按实测性能分配负载而不是按卡的数量平均分。还有一个经验是模型量化要谨慎。INT8量化能把显存占用降一半但分类准确率会掉2-3个百分点。对于分类任务这2-3个点可能意味着几千条工单误分。我们的做法是分类模型用FP16生成模型用INT8抽取模型用INT8在精度和成本之间找平衡。4.4 灰度发布与模型热更新的工程实现私有化环境下模型更新是个麻烦事不能像公有云那样随时切。我们的做法是双模型并行加灰度流量。新模型上线时同时加载新旧两个模型流量按比例分配比如新模型10%旧模型90%。对比两个模型的分类结果和下游指标如果新模型表现更好逐步提高流量比例如果变差立即回滚。模型热更新用共享内存加版本号实现。新模型加载到共享内存后编排Agent根据版本号决定调用哪个模型。切换时不需要重启服务只需要更新版本号配置。5. 高并发场景下的性能设计与压测实录5.1 工单峰值的特征分析与容量规划运营商工单的峰值特征很明显早高峰9-11点和晚高峰19-21点峰值流量是平峰的3-5倍。还有突发峰值比如大面积网络故障时工单量可能在几分钟内暴涨10倍。容量规划不能按平均值算要按峰值加冗余。我们的做法是基础容量按平峰流量的1.5倍配置弹性容量按峰值的1.2倍配置。弹性部分用容器化部署高峰期自动扩容低谷期缩容。具体数字上一个省级运营商平峰工单量大概是每秒20-30条峰值到每秒100-150条突发峰值可能到每秒500条。按每条工单平均调用3个Agent、每个Agent平均耗时100ms算需要的并发处理能力大概是150-450个并发槽位。5.2 异步化与批处理把吞吐量提上去同步处理是吞吐量的最大杀手。我们最开始的设计是同步调用一条工单从进入到完成处置平均耗时8秒QPS只能到30左右。后来改成全异步架构QPS提升到了200以上。异步化的核心是消息队列加回调。工单进入后先写消息队列编排Agent从队列消费调用执行Agent时发消息而不是直接调用执行Agent处理完后回调编排Agent。这样编排Agent不会被阻塞可以同时处理多条工单。批处理是另一个提升点。分类Agent可以把多条工单攒成一批一起推理batch size设到16时单条推理成本降低约40%。但batch size不能太大否则延迟会上升。实测下来batch size 8-16是延迟和吞吐的最佳平衡点。5.3 压测方案设计与瓶颈定位过程压测我们用的是全链路压测从工单接入开始模拟真实流量打到整个系统。压测工具用的是Locust加自定义的工单生成器能模拟不同渠道、不同类别的工单。压测中发现过几个瓶颈。第一个是数据库连接池工单状态更新频繁连接池被打满导致状态更新超时。后来把状态存储从关系数据库换成了Redis加定期持久化QPS从500提升到了5000。第二个是模型推理的显存碎片。长时间运行后显存碎片导致新请求无法分配显存推理失败。后来用了vLLM的PagedAttention显存碎片问题基本解决。第三个是消息队列积压。高峰期消息生产速度超过消费速度队列积压导致延迟上升。处理方式是增加消费者实例同时给队列设置优先级高优先级工单先消费。5.4 降级策略当系统扛不住时保什么降级策略是生产系统的保命符。我们定义了四级降级一级降级关闭非核心Agent比如回访Agent保分类和派单二级降级分类模型从大模型降级到小模型准确率降但速度升三级降级关闭自动派单只做分类和路由建议人工确认后派单四级降级全量转人工系统只做接入和存储。降级触发条件是综合指标不是单一指标。比如队列积压超过1000条且持续30秒触发一级降级模型推理P99延迟超过2秒触发二级降级。降级后要有恢复机制指标恢复正常后自动逐级恢复。6. 闭环处置的最后一公里回访、复盘与持续优化6.1 自动回访的触发条件与话术生成工单处置完成后回访是闭环的最后一环。但不是所有工单都需要回访我们的策略是按类别和结果差异化回访。故障类工单处置完成后自动触发回访确认故障是否真的解决咨询类工单如果用户没有二次来电默认满意不主动回访投诉类工单必须回访而且回访话术要更谨慎。回访话术用大模型生成但要有模板约束。我们给模型一个话术框架模型只填充具体内容避免生成不合适的话术。实测下来约束生成的话术合规率从85%提升到了99%以上。6.2 工单复盘数据的自动归集复盘是持续优化的基础。我们做了一个自动复盘Agent每天凌晨跑批把前一天的工单数据归集起来计算几个关键指标分类准确率、路由准确率、处置时长、一次解决率、回访满意度。这些指标会按类别、按渠道、按处理人维度拆解找出异常点。比如某个类别的分类准确率突然下降可能是业务调整导致语义变化某个处理人的处置时长明显偏高可能是技能不匹配。6.3 难例回流与模型迭代的自动化链路难例回流是模型迭代的关键。我们把三类工单标记为难例分类置信度低于阈值的、人工修正过分类的、回访发现处置有问题的。这些工单自动进入难例池每周做一次增量训练。增量训练用LoRA微调不需要全量重训一张卡几小时就能完成。新模型经过离线评估和灰度测试后上线。整个链路从难例产生到新模型上线周期控制在两周以内。6.4 从单点智能到系统智能的演进思考做了几个项目之后我最大的体会是工单智能化的价值不在单点准确率而在系统闭环。分类准确率从90%提到95%对业务的影响可能有限但把分类、路由、处置、回访串成闭环让系统能自动发现和修正问题价值是数量级的提升。下一步的演进方向是从被动响应到主动预测。现在系统是等工单来了才处理未来可以根据网络告警、用户行为、历史工单预测哪些区域、哪些用户可能出问题提前介入。这需要把工单数据和网络数据、用户数据打通做更复杂的因果推理。不过这些都是后话眼下最实在的还是把分类准确率、路由效率、闭环率这几个核心指标做扎实。我见过太多项目追求概念先进结果基础指标一塌糊涂。工单智能化这件事稳比快重要闭环比单点重要。