如果你在运营商体系里做过工单系统一定对“量大、类杂、时效紧”这七个字深有体会。宽带故障、移机改套餐、投诉催办、政企专线报障、基站退服告警……每天涌进来的工单动辄几十万张分门别类靠人眼派单靠经验处置靠嗓子喊。我这两年带着团队做了一套面向电信运营商海量工单的智能Agent系统核心就三件事分类路由、意图理解、闭环处置。这篇文章把我踩过的坑、选型的逻辑、以及一条工单从进来到最后归档的全过程都拆开讲清楚。项目还在持续迭代但现阶段的效果已经实打实把人工干预率降到了15%以内平均处置时长缩短了大概60%。无论你是在运营商做运营支撑还是在ToB公司做客服智能化这套技术路径和选型思路都可以直接拿去参考。1. 为什么运营商工单体系必须引入智能Agent1.1 海量工单的三大压力量、类、急先看一组我实际接触到的数据。某省级运营商日均工单量在20万到30万张之间高峰期比如寒暑假宽带装机季能冲到50万张。工单类型粗分有六七十类细分到二级、三级目录接近三百种。这么多工单覆盖了家庭宽带、移动网络、政企客户、账务投诉、网络运维、资源变更等完全不同的业务域每一类工单的处理动作、时限要求、责任部门都不一样。“急”是另一个大头。运营商工单有很多是带SLA的比如政企专线故障承诺两小时恢复用户升级投诉要求四小时首次响应。以前靠人工盯屏、超时前群发提醒经常是业务部门被考核指标追着跑一线的调度员压力非常大。量太大、类太杂、时限又急这三座大山叠在一起靠堆人已经解决不了问题。我测算过如果完全用人工做工单分拣和初步诊断一个熟练的调度员一天最多处理三百张而且还不能保证每张都判断准确。也正是因为这些压力我们才决定做一个专门的智能Agent而不是简单套用传统的工单系统加几个规则。普通的工单流程引擎只解决“流转”的问题不解决“判断”的问题。而运营商工单的核心矛盾恰恰在于判断——这张单子到底是什么故障、该派给谁、能不能自动先做一轮诊断、哪些话术能安抚用户情绪这些都需要一个能理解语义、能调用工具、能持续跟进的智能体来承接。1.2 传统工单处理流程到底卡在哪里传统模式下一张工单的生命周期基本是这样的客服或系统录入工单调度员人工判断工单类型然后手动选择处理部门或人员一线处理完填回单质检员再抽检。这个流程有三个结构性问题。第一分类完全依赖人的经验。工单标题写“宽带不好使”和“网速太卡了”可能是同一种故障也可能是完全不同的两种情况。一个刚入职三个月的调度员和一个干了十年的老师傅对同一张工单的判断经常不一样。这种一致性缺失直接导致派单错误派错单就要退单重派一来一回时间翻倍。第二重复劳动严重。大量故障工单其实有固定套路光猫红灯先重启没光信号先查分光器账号拨不上先查欠费。这些诊断逻辑是高度标准化的完全不需要人来做但传统系统没有任何自动执行的能力所有动作都要靠人看一遍、点一遍。第三缺少闭环反馈。工单处置完就结束了但处置结果对不对、用户的真实问题有没有解决没人关心。回单内容写“已处理”实际上是不是处理好了只有用户下次再报修的时候才知道。这种断裂导致系统无法自我优化同样的错误每天重复发生。正是这三个卡点让我意识到传统流程引擎加规则模板的老路走不通。我们需要的是一个能自主判断、动手操作、并对结果负责的智能Agent。2. 整体技术路径设计从分类路由到闭环处置的四段式架构2.1 架构总览感知、决策、执行、反馈整个系统我用一句话概括先把工单读懂再决定谁来做然后让Agent动手做最后检验做没做好。落到架构上是四层。第一层是感知层负责把工单的非结构化信息结构化。工单标题、描述、用户历史账单、设备状态、历史工单记录这些数据格式五花八门有文本、有JSON、有数据库表需要统一接入并做预处理。第二层是决策层核心是工单分类模型和路由策略引擎这一步决定“这是什么单、该走哪条路”。第三层是执行层由多个专业子Agent组成比如宽带诊断Agent、政企故障Agent、投诉安抚Agent每个子Agent有自己专属的工具集和知识库能调用网管接口、发短信、操作计费系统。第四层是反馈层回单校验、用户满意度预测、分类模型增量训练都在这层闭环。这四层不是简单的串行流水线而是一个带反馈回路的循环。Agent在处置过程中如果发现信息不足会主动触发“补充信息”动作生成一条待办给用户回传资料如果发现分类置信度低会转人工兜底同时把这个case记录为bad case反哺训练集。我们这套架构最初是用一个通用Agent编排框架搭的后面自己改了非常多。你如果图快也可以用扣子这类低代码智能体开发平台做一版MVP验证流程它自带大模型配置、插件机制、知识库和对话工作流非常适合先把“分类-路由-处置-闭环”这条链路跑通。但生产环境要接入运营商内部的网管接口、CRM系统、资源系统低代码平台往往扛不住定制化要求和信创合规约束所以我们最终选择了自研编排层底层再对接国产化大模型和向量数据库。2.2 为什么选择智能Agent而不是传统规则或纯模型这里我需要坦白一个认知转变的过程。项目立项初期团队里有两种主流思路。一种是纯规则派认为工单分类就几百种枚举关键词加正则就够用了另一种是纯模型派觉得直接上一个BERT分类模型加一个抽取模型就能解决所有问题。两个思路我们各自做了实验结果都不理想。规则方案准确率能做到85%以上但维护成本太高。运营商的业务规则每个月都在变新产品上线就要加规则促销活动一结束就要删规则两个月下来规则库膨胀到一万多条互相冲突的风险极高。纯模型方案在分类任务上表现确实好准确率能到92%但模型只解决了“判断”的问题判断完以后呢还是要人去执行后续动作。工单只是被标了个类别该做的诊断、该派的单、该回的话全都没有下文。智能Agent方案本质上把“理解、决策、执行、反馈”串成了一个完整闭环。它不是一个被动的分类器而是有一个目标、能自己规划步骤、能调用外部工具的主体。举个例子一张“宽带频繁掉线”的工单进来Agent不只是判断这是“宽带故障类”它会继续查看这个用户的光猫在线记录如果发现掉线集中在晚上八点到十一点它会自动生成一条“疑似局端olt端口拥塞”的判断然后直接把工单派给对应的接入网维护班组附带完整的诊断报告。这个过程里Agent既做了分类也做了路由还做了一部分一线人员才会做的诊断分析。2.3 数据底座和知识库建设是成败关键第二章节如果只说架构很容易给读者造成一个错觉好像把模型和Agent框架搭好就能跑。实际上在我整个项目里占比最大的不是模型调优而是数据治理和知识库建设。我们花了将近三个月的时间做了一件事把过去三年的历史工单全部清洗、去敏、打标。运营商工单里包含大量用户手机号、家庭住址、设备序列号这些信息必须先脱敏才能进模型训练。清洗规则我总结了三条统一文本编码、合并同义表达、剥离营销噪音。什么叫营销噪音就是工单描述里经常带“用户已同意升级5G套餐”“建议办理融合包”这类话术跟故障本身没关系如果不剥离模型很容易学歪。知识库建设更磨人。我们把计费系统、网管系统、资源系统的操作手册、故障处理手册、运维经验文档全部结构化切成片段后做向量化存储然后按业务域建了六个独立知识库。这些知识库有两个作用一是给大模型做RAG让它在回答和诊断时有据可依二是做Agent的工具说明书让Agent知道什么场景下该调用哪个接口。这里我特别想说的是不要指望知识库一步到位。我们第一批切了四千多个文档片段上线后发现问题很多有些片段是重复的有些是过期规则。后来建了一个知识库质量巡检脚本每周自动跑一遍把一个月以上没有被模型检索到的片段拉出来人工审查是该删除还是该丰富由业务专家确认。到目前知识库已经迭代了十几轮检索命中率从最初的55%提到了89%。3. 核心模块的选型逻辑与实现要点3.1 工单分类模块意图识别与多层分类的取舍工单分类是整个系统的入口它的效果直接影响后续所有环节。我们对模型选型做了三版对比。第一版用传统的TF-IDF加LightGBM准确率82%速度极快但无法处理口语化的长尾表达。第二版用BERT微调准确率直接干到93%但推理速度有点慢单张工单平均需要150毫秒而且对显卡资源要求高。第三版我们尝试了国产化的大模型做少样本分类准确率能到89%左右但用大模型做分类的成本还是偏高。最终的生产方案是两层级联第一层用小规模的预训练模型做粗分类把三百类工单先归到十几个大类第二层用大模型RAG做细分类只有在大类确定后需要进一步判断子类时才调用大模型。这么设计的好处是80%的工单在粗分类阶段就能确定处理路径不需要走到大模型只有那些真正模糊的长尾case才动用大模型的深度理解能力。路由决策不能只看分类结果因为分类是静态的而工单的状态是动态的。所以我们把路由模块做成了一个人工规则跟实时状态结合的三段式判断。第一段做硬性规则过滤比如工单积分等级高的用户自动加急政企客户的专线故障必须走VIP通道第二段做软性匹配基于分类结果和历史处理人的效率数据计算最优处理班组第三段做动态兜底如果前面两段都没有给出高置信度的路由结果工单进人工调度池同时把特征数据记录下来用于后续优化。这个三段式设计上线后路由准确率稳定在96.5%左右退单率从8.3%降到了2.1%。3.2 路由策略规则引擎与大模型的混合决策3.3 处置Agent的工具编排与动作执行处置层是整个系统最有“Agent味”的部分。每个子Agent本质上是一个大模型驱动的调度器它自己决定调用哪些工具、按什么顺序调用、如何根据返回结果调整计划。工具定义上我们没有把大模型的能力边界撑得太大而是把所有外部动作标准化成了三十多个可调用的工具函数。比如“查询光猫在线状态”“重启用户端口”“查询账户欠费”“发送满意度短信”“生成故障诊断报告”“创建维修工单”每个工具都有明确的参数说明和返回值格式。在Agent的提示词里我们把这些工具的描述、参数示例、调用条件写得很细目的只有一个让大模型在规划时能用最少的调用次数完成目标。我记得有个典型案例对我们启发很大。一张“宽带无法上网”的工单进来我们原本预期Agent至少调用光猫查询、设备查询、账号查询三个工具但实际运行发现Agent只调用了“查询光猫在线状态”发现光猫离线后直接派单给装维人员并附带了一句备注“建议优先检查用户家中光猫供电”。后来我们复盘是因为知识库里有一篇老运维写的手记提到三层设备离线最常见的原因是用户误拔电源。这个案例让我意识到知识库的另一个价值是让Agent学会在真实业务里“抄近道”。工具调用过程中一定要做参数校验。我们踩过一次挺深的坑某个Agent在调用“发送短信”工具时把用户手机号字段填成了工单编号结果把工单号发到用户手机上。排查下来是大模型没有理解字段语义参数名和用户实际值对应错位了。后来我们给所有工具的敏感参数加了正则校验和值域校验比如手机号必须是11位数字开头为1工单编号必须是特定前缀加数字不满足直接拦截并要求Agent重新生成。3.4 闭环处置回单校验、质检与知识反哺闭环不能只做成“派单、执行、归档”三个字。真正的闭环是系统能从每一张工单的处理结果里学习持续改进自己的判断。回单校验是我们最先实现的闭环能力。一线人员在工单系统里填写回单内容后我们的Agent会先做一道“回单质检”读取回单文本结合工单原始描述判断处理措施是否真的覆盖了用户问题。如果回单只写了“已处理”没有任何措施描述系统直接打回要求补充。如果回单描述的措施与工单问题不匹配比如用户报修的是宽带故障回单写“已为用户查询费用”系统也会拦截并人工复核。这道自动质检上线后回单规范率从74%提升到了98%。更重要的反哺机制是Bad Case回流。我们每周都会把人工纠偏过的case汇总自动剔除重复和低质量样本增量打标后混合进训练集。分类模型的训练数据初期只有历史工单但三个月后训练集里新增的bad case占比已经接近20%模型的精准度提升非常明显。这个迭代机制本身也是一个Agent在跑——我们叫它“标注助手”它会先筛选出最值得人工修正的case而不是让业务专家盲审。4. 实操过程一条宽带故障工单的完整Agent处理流程4.1 工单接入与预处理环节到这里我结合一个具体case带大家走一遍全流程。某天上午十点零三分系统接入一张用户通过App渠道提交的工单原文是“家里网速特别慢视频一直卡测速只有20M刚续费了宽带套餐”。预处理模块先做了几步动作。第一步脱敏把用户手机号、家庭地址替换成脱敏ID。第二步标准化把“网速慢”“视频卡”“测速20M”提取成结构化字段同时关联了这个用户近三个月的账单发现用户确实在三天前完成了一次套餐续费。第三步调用大模型做意图识别判断这张工单的核心意图是“速率不达标”附加意图是“套餐变更后的效果疑虑”。这个过程在传统流程里是调度员手工完成大概需要五到十分钟。Agent这边全部执行完花了四秒。预处理完成后系统给工单打上了优先级标签。因为用户刚续费了高价值融合套餐按规则这条工单被标记为“高价值用户保障工单”SLA时限从普通的八小时缩短到了四小时。4.2 智能诊断与路由决策过程进入决策层后分类模块给出的结果是“家庭宽带-速率异常-有线接入”置信度91%。路由模块结合用户地址关联到所属分光器设备和OLT端口系统做了两步自动预诊断。第一步查询OLT端口的历史速率数据发现这个端口在上午九点到十点之间有流量突增记录峰值利用率达到92%远超70%的阈值。第二步查询用户光猫的最近七天在线记录没有发现掉线日志。两个数据交叉Agent给出初步判断用户速率慢大概率是因为OLT端口拥塞导致而非光猫故障。这之后路由模块做了决策工单不派给普通装维而是直接派给接入网优化班组附带的诊断报告里自动生成了三行建议包括优化端口带宽、负载均衡调整、以及联系用户确认测速时间段。我们很多初看这套流程的同事都觉得意外明明是一张用户投诉工单Agent却把问题定位到了局端设备这在传统人工模式下几乎不可能因为调度员没有权限也没有时间去做这种跨系统数据关联。但Agent可以它天生擅长一次性查多个系统、做交叉判断。4.3 处置执行、回单闭环与结果反馈接入网优化班组收到工单后工程师核对了Agent生成的诊断结论确认OLT端口确实存在拥塞执行了带宽扩容。全过程用了四十分钟工单回填内容描述了优化操作和预期效果。这时候闭环校验Agent又开始工作。它读取回单结合原始工单信息做了三个校验处理措施是否覆盖用户“速率慢”的核心问题、是否有明确的解决方案而不是模糊话术、是否需要进一步告知用户。校验通过后系统自动触发了一条服务短信给用户内容包含处理结果和一条“测速恢复正常后如仍有问题可随时联系我们”的回复。工单在上午十一点零九分正式归档全程耗时六十六分钟远小于四小时的SLA要求。这个故事最值得玩味的是整张工单从接入到归档没有人手动做过一次判断或转派。调度员只做了一件事在Agent把工单派给接入网班组时点了确认。确认动作是流程合规要求但实际决策全部由Agent完成。这就是我在项目里反复强调的智能Agent价值——它不是替代人而是把人从重复判断中解放出来让人只做最后的关键确认和异常兜底。5. 落地过程中的常见问题与排查实录5.1 分类准确率上不去标注一致性比模型结构更重要我们遇到过最典型的场景模型上线时准确率92%跑了两周反而降到88%。排查下来发现不是模型衰退而是人工标注规范没有统一。同样的case上午班标注成“宽带故障”晚班标注成“网络质量-有线”模型学到两套答案自然越学越乱。解决办法是建了一个标注SOP加仲裁机制。标注SOP里把容易混淆的类型做成正反例对照表比如“光猫红灯”归设备故障而不是线路故障“测速不达标但无掉线”优先归速率异常类。每个礼拜抽20%的标注结果做二次审核有分歧的case由业务专家仲裁。这套机制运行起来后标注一致性从81%提升到94%模型准确率也跟着涨回来并稳定在93%以上。我给你的建议是上模型之前先花两周时间把标注一致性打牢这个投入一定比你多调十个epoch有用。分类模型的上限是标注质量决定的模型只是把你的标注习惯学出来而已。5.2 路由死循环与工单卡住兜底策略必须前置设计Agent系统上线后我们遇到过几次工单在路由环节反复跳动的情况。一张工单先派给了A班组A班组退回并备注“不属于本班组”系统又自动派给了B班组B班组又退回。最夸张的一张工单在两个班组之间跳了七次整整卡了两小时。根因在于退单语义没有被Agent理解。A班组退回时写的“请网络部处理”系统只识别到了“退单”动作没有识别“转派给网络部”的意图。修复方案有两步第一步在路由Agent的提示词里增加对退单备注的意图识别指令退单原因里有“请XX部门处理”这类关键词时直接转到对应部门而不是回到原路由节点。第二步设计了一个兜底熔断机制同一张工单路由跳转超过三次自动转为人工调度同时给调度员附带一张完整的跳转轨迹图。这个熔断机制上线后非常管用即使后面再出现新的路由bug最坏情况也就是转人工不会让工单无限空转。任何做Agent落地的人我强烈建议你在设计路由模块时就预留这种兜底因为Agent的自主性越强就越可能出现你预料不到的循环行为。5.3 大模型幻觉在工单场景的典型表现与控制手段大模型幻觉在工单场景里是个大事因为工单是要进考核系统、甚至可能被用户看到的错了就是事故。我们遇到过Agent在诊断报告里编造了一个根本不存在的告警代码也遇到过Agent在与用户平台交互时声称“已经为您办理了退费”实际上完全没调用退费工具。控制幻觉我们用了三重保险。第一重是RAG强约束要求Agent的所有诊断结论都必须引用知识库或工具返回的数据来源提示词里明确写了“没有数据依据时必须回答信息不足而不是猜测”。第二重是输出校验模型用一个轻量级模型对Agent生成的报告做事实抽检抽取报告中的关键实体——如设备号、告警代码、时限时间——与工具调用日志比对不一致就打回重新生成。第三重是高风险动作二次确认涉及退费、销户、发送短信这类敏感操作Agent不能直接执行必须先输出操作申请由真人审核后执行。在这里我想纠正一个常见误区好多人喜欢在提示词里写“你必须基于事实回答不得编造”但光写这句话没用模型还是会幻觉。真正的解决思路是给Agent装“刹车”——你让它执行的所有动作都要有对应的工具调用记录和返回值日志把这些日志作为生成内容的唯一数据源幻觉空间就会被压缩到很小。5.4 成本与性能的平衡算力账单和单张工单成本核算大模型Agent的成本很容易失控这个坑我必须拿出来单独讲。我们曾经统计过一次月账单调用量最大的一天光模型推理费用就相当于团队两个人一个月工资。这个成本如果不控制老板随时让你下线系统。我的建议是把“贵模型”和“便宜模型”混着用。在工单分类、意图识别、实体抽取这些高频但难度相对低的场景用小参数模型就够了只有在复杂诊断、报告生成、多轮规划这些真正需要深度推理的场景才用旗舰大模型。我们现在的策略是约60%的工单只走小模型加规则就能完成闭环35%走中模型RAG真正调用旗舰大模型的只有5%的疑难工单。另外一个有效手段是工具结果缓存。同一台光猫、同一个OLT端口在短时间内状态不会剧烈变化。我们把常见的查询类工具做了结果缓存TTL设置为五到十分钟。这个优化立竿见影工具调用量直接降了40%模型推理费用跟着降下来一半以上。5.5 常见问题速查表与排查锦囊最后把我们在项目一线最常被问到的几个问题和解法汇总成一张表方便你实际开发时对照排查。现象可能原因排查思路解决方案分类准确率波动大标注标准漂移抽检近一周标注样本计算一致性建标注SOP仲裁机制兜底工单路由转圈退单意图未识别查看路由轨迹日志解析退单备注退单语义识别三次跳转熔断报告出现虚假数据模型幻觉比对报告与工具调用日志RAG强约束输出校验模型工单处置时间反而变长工具调用次数过多监控单工单平均工具调用数提示词压缩工具清单结果缓存大模型费用飙升场景未区分难易按业务场景统计调用分布大小模型分级混合策略新业务上线后分类异常训练数据未覆盖收集新业务case人工打标增量训练知识库同步更新还有一个经验是Agent系统上线后一定要做灰度对比测试。我们上了整整两个月的影子模式Agent跑归跑但结果只记录不采用人工流程照常走。两个月积累了将近四十万条Agent决策日志分析出127类问题修完这些坑之后才敢正式接管一部分真实工单。这个节奏看起来慢但实际上是全项目里冒风险最小、回报最高的一步。我自己在这套系统上最大的体会是智能Agent落地的难点从来不是模型能力而是工程化。把历史数据洗干净、把工具接口治理好、把兜底逻辑设计周全、把成本账算明白这四件事任何一件做不好模型再强都白搭。做这类项目你要有一颗当“系统工程师”而不是“算法研究员”的心。工单这个场景足够复杂也足够有价值值得任何一个做Agent应用的人投入去钻研。 
长河君 · 2026/10/4 7:15:59 · 阅读 1.2k 智能Agent重构运营商海量工单：分类路由与闭环处置实战
如果你在运营商体系里做过工单系统一定对“量大、类杂、时效紧”这七个字深有体会。宽带故障、移机改套餐、投诉催办、政企专线报障、基站退服告警……每天涌进来的工单动辄几十万张分门别类靠人眼派单靠经验处置靠嗓子喊。我这两年带着团队做了一套面向电信运营商海量工单的智能Agent系统核心就三件事分类路由、意图理解、闭环处置。这篇文章把我踩过的坑、选型的逻辑、以及一条工单从进来到最后归档的全过程都拆开讲清楚。项目还在持续迭代但现阶段的效果已经实打实把人工干预率降到了15%以内平均处置时长缩短了大概60%。无论你是在运营商做运营支撑还是在ToB公司做客服智能化这套技术路径和选型思路都可以直接拿去参考。1. 为什么运营商工单体系必须引入智能Agent1.1 海量工单的三大压力量、类、急先看一组我实际接触到的数据。某省级运营商日均工单量在20万到30万张之间高峰期比如寒暑假宽带装机季能冲到50万张。工单类型粗分有六七十类细分到二级、三级目录接近三百种。这么多工单覆盖了家庭宽带、移动网络、政企客户、账务投诉、网络运维、资源变更等完全不同的业务域每一类工单的处理动作、时限要求、责任部门都不一样。“急”是另一个大头。运营商工单有很多是带SLA的比如政企专线故障承诺两小时恢复用户升级投诉要求四小时首次响应。以前靠人工盯屏、超时前群发提醒经常是业务部门被考核指标追着跑一线的调度员压力非常大。量太大、类太杂、时限又急这三座大山叠在一起靠堆人已经解决不了问题。我测算过如果完全用人工做工单分拣和初步诊断一个熟练的调度员一天最多处理三百张而且还不能保证每张都判断准确。也正是因为这些压力我们才决定做一个专门的智能Agent而不是简单套用传统的工单系统加几个规则。普通的工单流程引擎只解决“流转”的问题不解决“判断”的问题。而运营商工单的核心矛盾恰恰在于判断——这张单子到底是什么故障、该派给谁、能不能自动先做一轮诊断、哪些话术能安抚用户情绪这些都需要一个能理解语义、能调用工具、能持续跟进的智能体来承接。1.2 传统工单处理流程到底卡在哪里传统模式下一张工单的生命周期基本是这样的客服或系统录入工单调度员人工判断工单类型然后手动选择处理部门或人员一线处理完填回单质检员再抽检。这个流程有三个结构性问题。第一分类完全依赖人的经验。工单标题写“宽带不好使”和“网速太卡了”可能是同一种故障也可能是完全不同的两种情况。一个刚入职三个月的调度员和一个干了十年的老师傅对同一张工单的判断经常不一样。这种一致性缺失直接导致派单错误派错单就要退单重派一来一回时间翻倍。第二重复劳动严重。大量故障工单其实有固定套路光猫红灯先重启没光信号先查分光器账号拨不上先查欠费。这些诊断逻辑是高度标准化的完全不需要人来做但传统系统没有任何自动执行的能力所有动作都要靠人看一遍、点一遍。第三缺少闭环反馈。工单处置完就结束了但处置结果对不对、用户的真实问题有没有解决没人关心。回单内容写“已处理”实际上是不是处理好了只有用户下次再报修的时候才知道。这种断裂导致系统无法自我优化同样的错误每天重复发生。正是这三个卡点让我意识到传统流程引擎加规则模板的老路走不通。我们需要的是一个能自主判断、动手操作、并对结果负责的智能Agent。2. 整体技术路径设计从分类路由到闭环处置的四段式架构2.1 架构总览感知、决策、执行、反馈整个系统我用一句话概括先把工单读懂再决定谁来做然后让Agent动手做最后检验做没做好。落到架构上是四层。第一层是感知层负责把工单的非结构化信息结构化。工单标题、描述、用户历史账单、设备状态、历史工单记录这些数据格式五花八门有文本、有JSON、有数据库表需要统一接入并做预处理。第二层是决策层核心是工单分类模型和路由策略引擎这一步决定“这是什么单、该走哪条路”。第三层是执行层由多个专业子Agent组成比如宽带诊断Agent、政企故障Agent、投诉安抚Agent每个子Agent有自己专属的工具集和知识库能调用网管接口、发短信、操作计费系统。第四层是反馈层回单校验、用户满意度预测、分类模型增量训练都在这层闭环。这四层不是简单的串行流水线而是一个带反馈回路的循环。Agent在处置过程中如果发现信息不足会主动触发“补充信息”动作生成一条待办给用户回传资料如果发现分类置信度低会转人工兜底同时把这个case记录为bad case反哺训练集。我们这套架构最初是用一个通用Agent编排框架搭的后面自己改了非常多。你如果图快也可以用扣子这类低代码智能体开发平台做一版MVP验证流程它自带大模型配置、插件机制、知识库和对话工作流非常适合先把“分类-路由-处置-闭环”这条链路跑通。但生产环境要接入运营商内部的网管接口、CRM系统、资源系统低代码平台往往扛不住定制化要求和信创合规约束所以我们最终选择了自研编排层底层再对接国产化大模型和向量数据库。2.2 为什么选择智能Agent而不是传统规则或纯模型这里我需要坦白一个认知转变的过程。项目立项初期团队里有两种主流思路。一种是纯规则派认为工单分类就几百种枚举关键词加正则就够用了另一种是纯模型派觉得直接上一个BERT分类模型加一个抽取模型就能解决所有问题。两个思路我们各自做了实验结果都不理想。规则方案准确率能做到85%以上但维护成本太高。运营商的业务规则每个月都在变新产品上线就要加规则促销活动一结束就要删规则两个月下来规则库膨胀到一万多条互相冲突的风险极高。纯模型方案在分类任务上表现确实好准确率能到92%但模型只解决了“判断”的问题判断完以后呢还是要人去执行后续动作。工单只是被标了个类别该做的诊断、该派的单、该回的话全都没有下文。智能Agent方案本质上把“理解、决策、执行、反馈”串成了一个完整闭环。它不是一个被动的分类器而是有一个目标、能自己规划步骤、能调用外部工具的主体。举个例子一张“宽带频繁掉线”的工单进来Agent不只是判断这是“宽带故障类”它会继续查看这个用户的光猫在线记录如果发现掉线集中在晚上八点到十一点它会自动生成一条“疑似局端olt端口拥塞”的判断然后直接把工单派给对应的接入网维护班组附带完整的诊断报告。这个过程里Agent既做了分类也做了路由还做了一部分一线人员才会做的诊断分析。2.3 数据底座和知识库建设是成败关键第二章节如果只说架构很容易给读者造成一个错觉好像把模型和Agent框架搭好就能跑。实际上在我整个项目里占比最大的不是模型调优而是数据治理和知识库建设。我们花了将近三个月的时间做了一件事把过去三年的历史工单全部清洗、去敏、打标。运营商工单里包含大量用户手机号、家庭住址、设备序列号这些信息必须先脱敏才能进模型训练。清洗规则我总结了三条统一文本编码、合并同义表达、剥离营销噪音。什么叫营销噪音就是工单描述里经常带“用户已同意升级5G套餐”“建议办理融合包”这类话术跟故障本身没关系如果不剥离模型很容易学歪。知识库建设更磨人。我们把计费系统、网管系统、资源系统的操作手册、故障处理手册、运维经验文档全部结构化切成片段后做向量化存储然后按业务域建了六个独立知识库。这些知识库有两个作用一是给大模型做RAG让它在回答和诊断时有据可依二是做Agent的工具说明书让Agent知道什么场景下该调用哪个接口。这里我特别想说的是不要指望知识库一步到位。我们第一批切了四千多个文档片段上线后发现问题很多有些片段是重复的有些是过期规则。后来建了一个知识库质量巡检脚本每周自动跑一遍把一个月以上没有被模型检索到的片段拉出来人工审查是该删除还是该丰富由业务专家确认。到目前知识库已经迭代了十几轮检索命中率从最初的55%提到了89%。3. 核心模块的选型逻辑与实现要点3.1 工单分类模块意图识别与多层分类的取舍工单分类是整个系统的入口它的效果直接影响后续所有环节。我们对模型选型做了三版对比。第一版用传统的TF-IDF加LightGBM准确率82%速度极快但无法处理口语化的长尾表达。第二版用BERT微调准确率直接干到93%但推理速度有点慢单张工单平均需要150毫秒而且对显卡资源要求高。第三版我们尝试了国产化的大模型做少样本分类准确率能到89%左右但用大模型做分类的成本还是偏高。最终的生产方案是两层级联第一层用小规模的预训练模型做粗分类把三百类工单先归到十几个大类第二层用大模型RAG做细分类只有在大类确定后需要进一步判断子类时才调用大模型。这么设计的好处是80%的工单在粗分类阶段就能确定处理路径不需要走到大模型只有那些真正模糊的长尾case才动用大模型的深度理解能力。路由决策不能只看分类结果因为分类是静态的而工单的状态是动态的。所以我们把路由模块做成了一个人工规则跟实时状态结合的三段式判断。第一段做硬性规则过滤比如工单积分等级高的用户自动加急政企客户的专线故障必须走VIP通道第二段做软性匹配基于分类结果和历史处理人的效率数据计算最优处理班组第三段做动态兜底如果前面两段都没有给出高置信度的路由结果工单进人工调度池同时把特征数据记录下来用于后续优化。这个三段式设计上线后路由准确率稳定在96.5%左右退单率从8.3%降到了2.1%。3.2 路由策略规则引擎与大模型的混合决策3.3 处置Agent的工具编排与动作执行处置层是整个系统最有“Agent味”的部分。每个子Agent本质上是一个大模型驱动的调度器它自己决定调用哪些工具、按什么顺序调用、如何根据返回结果调整计划。工具定义上我们没有把大模型的能力边界撑得太大而是把所有外部动作标准化成了三十多个可调用的工具函数。比如“查询光猫在线状态”“重启用户端口”“查询账户欠费”“发送满意度短信”“生成故障诊断报告”“创建维修工单”每个工具都有明确的参数说明和返回值格式。在Agent的提示词里我们把这些工具的描述、参数示例、调用条件写得很细目的只有一个让大模型在规划时能用最少的调用次数完成目标。我记得有个典型案例对我们启发很大。一张“宽带无法上网”的工单进来我们原本预期Agent至少调用光猫查询、设备查询、账号查询三个工具但实际运行发现Agent只调用了“查询光猫在线状态”发现光猫离线后直接派单给装维人员并附带了一句备注“建议优先检查用户家中光猫供电”。后来我们复盘是因为知识库里有一篇老运维写的手记提到三层设备离线最常见的原因是用户误拔电源。这个案例让我意识到知识库的另一个价值是让Agent学会在真实业务里“抄近道”。工具调用过程中一定要做参数校验。我们踩过一次挺深的坑某个Agent在调用“发送短信”工具时把用户手机号字段填成了工单编号结果把工单号发到用户手机上。排查下来是大模型没有理解字段语义参数名和用户实际值对应错位了。后来我们给所有工具的敏感参数加了正则校验和值域校验比如手机号必须是11位数字开头为1工单编号必须是特定前缀加数字不满足直接拦截并要求Agent重新生成。3.4 闭环处置回单校验、质检与知识反哺闭环不能只做成“派单、执行、归档”三个字。真正的闭环是系统能从每一张工单的处理结果里学习持续改进自己的判断。回单校验是我们最先实现的闭环能力。一线人员在工单系统里填写回单内容后我们的Agent会先做一道“回单质检”读取回单文本结合工单原始描述判断处理措施是否真的覆盖了用户问题。如果回单只写了“已处理”没有任何措施描述系统直接打回要求补充。如果回单描述的措施与工单问题不匹配比如用户报修的是宽带故障回单写“已为用户查询费用”系统也会拦截并人工复核。这道自动质检上线后回单规范率从74%提升到了98%。更重要的反哺机制是Bad Case回流。我们每周都会把人工纠偏过的case汇总自动剔除重复和低质量样本增量打标后混合进训练集。分类模型的训练数据初期只有历史工单但三个月后训练集里新增的bad case占比已经接近20%模型的精准度提升非常明显。这个迭代机制本身也是一个Agent在跑——我们叫它“标注助手”它会先筛选出最值得人工修正的case而不是让业务专家盲审。4. 实操过程一条宽带故障工单的完整Agent处理流程4.1 工单接入与预处理环节到这里我结合一个具体case带大家走一遍全流程。某天上午十点零三分系统接入一张用户通过App渠道提交的工单原文是“家里网速特别慢视频一直卡测速只有20M刚续费了宽带套餐”。预处理模块先做了几步动作。第一步脱敏把用户手机号、家庭地址替换成脱敏ID。第二步标准化把“网速慢”“视频卡”“测速20M”提取成结构化字段同时关联了这个用户近三个月的账单发现用户确实在三天前完成了一次套餐续费。第三步调用大模型做意图识别判断这张工单的核心意图是“速率不达标”附加意图是“套餐变更后的效果疑虑”。这个过程在传统流程里是调度员手工完成大概需要五到十分钟。Agent这边全部执行完花了四秒。预处理完成后系统给工单打上了优先级标签。因为用户刚续费了高价值融合套餐按规则这条工单被标记为“高价值用户保障工单”SLA时限从普通的八小时缩短到了四小时。4.2 智能诊断与路由决策过程进入决策层后分类模块给出的结果是“家庭宽带-速率异常-有线接入”置信度91%。路由模块结合用户地址关联到所属分光器设备和OLT端口系统做了两步自动预诊断。第一步查询OLT端口的历史速率数据发现这个端口在上午九点到十点之间有流量突增记录峰值利用率达到92%远超70%的阈值。第二步查询用户光猫的最近七天在线记录没有发现掉线日志。两个数据交叉Agent给出初步判断用户速率慢大概率是因为OLT端口拥塞导致而非光猫故障。这之后路由模块做了决策工单不派给普通装维而是直接派给接入网优化班组附带的诊断报告里自动生成了三行建议包括优化端口带宽、负载均衡调整、以及联系用户确认测速时间段。我们很多初看这套流程的同事都觉得意外明明是一张用户投诉工单Agent却把问题定位到了局端设备这在传统人工模式下几乎不可能因为调度员没有权限也没有时间去做这种跨系统数据关联。但Agent可以它天生擅长一次性查多个系统、做交叉判断。4.3 处置执行、回单闭环与结果反馈接入网优化班组收到工单后工程师核对了Agent生成的诊断结论确认OLT端口确实存在拥塞执行了带宽扩容。全过程用了四十分钟工单回填内容描述了优化操作和预期效果。这时候闭环校验Agent又开始工作。它读取回单结合原始工单信息做了三个校验处理措施是否覆盖用户“速率慢”的核心问题、是否有明确的解决方案而不是模糊话术、是否需要进一步告知用户。校验通过后系统自动触发了一条服务短信给用户内容包含处理结果和一条“测速恢复正常后如仍有问题可随时联系我们”的回复。工单在上午十一点零九分正式归档全程耗时六十六分钟远小于四小时的SLA要求。这个故事最值得玩味的是整张工单从接入到归档没有人手动做过一次判断或转派。调度员只做了一件事在Agent把工单派给接入网班组时点了确认。确认动作是流程合规要求但实际决策全部由Agent完成。这就是我在项目里反复强调的智能Agent价值——它不是替代人而是把人从重复判断中解放出来让人只做最后的关键确认和异常兜底。5. 落地过程中的常见问题与排查实录5.1 分类准确率上不去标注一致性比模型结构更重要我们遇到过最典型的场景模型上线时准确率92%跑了两周反而降到88%。排查下来发现不是模型衰退而是人工标注规范没有统一。同样的case上午班标注成“宽带故障”晚班标注成“网络质量-有线”模型学到两套答案自然越学越乱。解决办法是建了一个标注SOP加仲裁机制。标注SOP里把容易混淆的类型做成正反例对照表比如“光猫红灯”归设备故障而不是线路故障“测速不达标但无掉线”优先归速率异常类。每个礼拜抽20%的标注结果做二次审核有分歧的case由业务专家仲裁。这套机制运行起来后标注一致性从81%提升到94%模型准确率也跟着涨回来并稳定在93%以上。我给你的建议是上模型之前先花两周时间把标注一致性打牢这个投入一定比你多调十个epoch有用。分类模型的上限是标注质量决定的模型只是把你的标注习惯学出来而已。5.2 路由死循环与工单卡住兜底策略必须前置设计Agent系统上线后我们遇到过几次工单在路由环节反复跳动的情况。一张工单先派给了A班组A班组退回并备注“不属于本班组”系统又自动派给了B班组B班组又退回。最夸张的一张工单在两个班组之间跳了七次整整卡了两小时。根因在于退单语义没有被Agent理解。A班组退回时写的“请网络部处理”系统只识别到了“退单”动作没有识别“转派给网络部”的意图。修复方案有两步第一步在路由Agent的提示词里增加对退单备注的意图识别指令退单原因里有“请XX部门处理”这类关键词时直接转到对应部门而不是回到原路由节点。第二步设计了一个兜底熔断机制同一张工单路由跳转超过三次自动转为人工调度同时给调度员附带一张完整的跳转轨迹图。这个熔断机制上线后非常管用即使后面再出现新的路由bug最坏情况也就是转人工不会让工单无限空转。任何做Agent落地的人我强烈建议你在设计路由模块时就预留这种兜底因为Agent的自主性越强就越可能出现你预料不到的循环行为。5.3 大模型幻觉在工单场景的典型表现与控制手段大模型幻觉在工单场景里是个大事因为工单是要进考核系统、甚至可能被用户看到的错了就是事故。我们遇到过Agent在诊断报告里编造了一个根本不存在的告警代码也遇到过Agent在与用户平台交互时声称“已经为您办理了退费”实际上完全没调用退费工具。控制幻觉我们用了三重保险。第一重是RAG强约束要求Agent的所有诊断结论都必须引用知识库或工具返回的数据来源提示词里明确写了“没有数据依据时必须回答信息不足而不是猜测”。第二重是输出校验模型用一个轻量级模型对Agent生成的报告做事实抽检抽取报告中的关键实体——如设备号、告警代码、时限时间——与工具调用日志比对不一致就打回重新生成。第三重是高风险动作二次确认涉及退费、销户、发送短信这类敏感操作Agent不能直接执行必须先输出操作申请由真人审核后执行。在这里我想纠正一个常见误区好多人喜欢在提示词里写“你必须基于事实回答不得编造”但光写这句话没用模型还是会幻觉。真正的解决思路是给Agent装“刹车”——你让它执行的所有动作都要有对应的工具调用记录和返回值日志把这些日志作为生成内容的唯一数据源幻觉空间就会被压缩到很小。5.4 成本与性能的平衡算力账单和单张工单成本核算大模型Agent的成本很容易失控这个坑我必须拿出来单独讲。我们曾经统计过一次月账单调用量最大的一天光模型推理费用就相当于团队两个人一个月工资。这个成本如果不控制老板随时让你下线系统。我的建议是把“贵模型”和“便宜模型”混着用。在工单分类、意图识别、实体抽取这些高频但难度相对低的场景用小参数模型就够了只有在复杂诊断、报告生成、多轮规划这些真正需要深度推理的场景才用旗舰大模型。我们现在的策略是约60%的工单只走小模型加规则就能完成闭环35%走中模型RAG真正调用旗舰大模型的只有5%的疑难工单。另外一个有效手段是工具结果缓存。同一台光猫、同一个OLT端口在短时间内状态不会剧烈变化。我们把常见的查询类工具做了结果缓存TTL设置为五到十分钟。这个优化立竿见影工具调用量直接降了40%模型推理费用跟着降下来一半以上。5.5 常见问题速查表与排查锦囊最后把我们在项目一线最常被问到的几个问题和解法汇总成一张表方便你实际开发时对照排查。现象可能原因排查思路解决方案分类准确率波动大标注标准漂移抽检近一周标注样本计算一致性建标注SOP仲裁机制兜底工单路由转圈退单意图未识别查看路由轨迹日志解析退单备注退单语义识别三次跳转熔断报告出现虚假数据模型幻觉比对报告与工具调用日志RAG强约束输出校验模型工单处置时间反而变长工具调用次数过多监控单工单平均工具调用数提示词压缩工具清单结果缓存大模型费用飙升场景未区分难易按业务场景统计调用分布大小模型分级混合策略新业务上线后分类异常训练数据未覆盖收集新业务case人工打标增量训练知识库同步更新还有一个经验是Agent系统上线后一定要做灰度对比测试。我们上了整整两个月的影子模式Agent跑归跑但结果只记录不采用人工流程照常走。两个月积累了将近四十万条Agent决策日志分析出127类问题修完这些坑之后才敢正式接管一部分真实工单。这个节奏看起来慢但实际上是全项目里冒风险最小、回报最高的一步。我自己在这套系统上最大的体会是智能Agent落地的难点从来不是模型能力而是工程化。把历史数据洗干净、把工具接口治理好、把兜底逻辑设计周全、把成本账算明白这四件事任何一件做不好模型再强都白搭。做这类项目你要有一颗当“系统工程师”而不是“算法研究员”的心。工单这个场景足够复杂也足够有价值值得任何一个做Agent应用的人投入去钻研。