做运营商行业数智化改造这几年工单系统一直是个“看起来简单、做起来难受”的领域。尤其到了省级或集团级别“海量工单”四个字背后是每天几万到几十万张单子从接入到装维、从传输到核心网、从故障到投诉的滚滚洪流。最近我们团队把一套基于智能Agent的工单处理链路从设计到落地完整走了一遍覆盖分类路由、意图识别、工具调用、闭环处置全流程。这篇文章把技术路径和选型逻辑完整拆出来适合正在做运营商OSS域智能化改造、或者被工单量压得想上AI但不知道怎么落地的团队参考。先说清楚这套系统是干什么的。它不是简单做个“智能客服”或者“工单自动分拣”的小工具而是要把一张工单从进入系统开始到最终处置完成、回单确认用Agent串成一条自动化的闭环链路。工单来了先自动分类、自动路由然后由Agent读取工单内容、理解故障现象、检索知识库、调用网管和运维工具最终生成处置建议甚至直接执行部分修复动作跑通了再自动归档回单。这套东西听起来像是把“运维专家”塞进了流水线实际上落地过程中踩的坑、做的取舍比想象中多得多。1. 需求拆解运营商工单系统的“三座山”1.1 工单量级带来的第一个冲击分类路由不能靠人先说大家都熟悉的痛点。运营商一张工单从客户侧或者网管侧产生后第一件事就是判断“这是谁的活”。传统做法是靠人工经验判断从工单标题和内容里找关键字路由到对应专业组。但工单量一旦上来问题就非常具体一个省一天几万张工单有家庭宽带用户报障的、有政企专线中断的、有基站退服的还有核心网设备告警自动生成的。每张单子内容描述五花八门有的用户就说“网断了”有些描述里夹杂着大量无关信息。靠人工一张张看要么积压要么分错分错了后续处理全是浪费。这里有个关键理解运营商工单和互联网公司的工单完全不一样专业域划分极其细。传输、无线、核心网、动环、家宽、政企、IT支撑每个域还有二级三级子类。人工派单靠的是“老员工脑子里的那张路由表”新人根本扛不住。智能Agent解决的问题首先不是“聪明”而是“稳定”——把老师傅的路由经验固化下来用语义理解和规则约束保证一万张单子的分类结果基本一致。1.2 跨专业协作的现实闭环处置不能只靠一个模型第二个难点在于处置环节。运营商工单的闭环处置牵涉到多个系统网管平台、资源管理系统、工单系统、知识库还有各种自动化运维脚本。传统做法是工单分下去之后由运维人员打开网管看告警、查资源、翻知识库、手动执行操作。Agent在这里要替代的不仅仅是“阅读理解”而是整套“看懂问题—定位原因—拿出方案—执行动作—验证效果”的能力链。我见过不少团队一开始只做“智能分单”做完了发现价值有限因为分类只是入口后面的处置才是真正耗时耗力的环节。我们把目标定为“从分类路由到闭环处置”核心逻辑就在这里Agent要能走完一个完整的业务动作链而不只是提供一个分类标签。这意味着Agent框架必须有状态流转、工具调用、异常处理、人工兜底这些能力单纯调一个LLM接口远远不够。1.3 适合谁来参考这套路径这篇文章面向的直接读者我猜大概率是三类人。第一类是运营商省公司或集团侧IT规划和技术架构的人正在立项做工单智能化第二类是给运营商做OSS系统集成的厂商研发团队需要一套落地可行、选型有理有据的方案第三类是对Agent工程化感兴趣的同行想看看在真实业务场景里Agent是怎么被约束、被调用、被评价的。无论哪类我觉得最有价值的不是“某某大模型很强”的结论而是从需求到架构到细节实现这条完整的决策链。2. 技术路径Agent从“看懂工单”到“自己干活”要拆几步2.1 第一层工单分类路由的语义化改造工单分类这件事传统的实现方式无非两种基于规则的匹配和基于统计的文本分类。规则匹配的问题是运营商工单的描述太“活”了规则写得再多也覆盖不完真实表达方式尤其是“网不好”“上不了网”“网页打不开”这种口语化描述。统计文本分类模型的效果比规则好一些但在几百个细分类别上的准确率不够而且类别之间边界模糊比如“家宽故障”和“政企专线故障”都可能有“网不通”的描述只靠文本本身区分难度极高。我们的做法是把分类路由变成“语义理解业务规则约束”的双层结构。第一层用Embedding模型把工单文本转成向量做粗分类定位到一级业务域第二层用LLM基于工单原文、网元类型、客户类型和关联告警信息做细粒度判定输出二三级分类结果。这里有个非常核心的设计LLM的输出不是自由文本而是受JSON Schema约束的结构化字段包括业务域、分类编码、处理团队、优先级、路由策略。这个约束极其重要否则LLM每次返回的“分类结果”格式不一致下游系统根本没法解析。分类路由这层我强烈建议把“置信度”暴露出来。不是所有工单都能被自信地分类遇到置信度低的单子不要硬分直接挂到人工复审池。这个设计牺牲了一点自动化率但保护了整体的路由准确率。在实际运营中一张分错的单子造成的返工成本远高于十张进复审池的单子。2.2 第二层要素提取与信息补齐工单分类只能回答“这是谁的活”Agent接着要回答“这个活具体是什么情况”。运营商工单的信息质量普遍不高很多时候只有一句话“XX小区用户反应宽带网速慢请尽快处理”缺少设备类型、光猫型号、故障现象分类等关键字段。Agent的能力在这里体现为从工单标题、描述、附带的告警编号、客户信息里抽取结构化要素并识别缺失项。做到位之后有个经验不要把所有的字段都交给LLM去“猜”。比如设备型号、资源编码这类信息靠猜是靠不住的必须通过资源管理系统接口去查。所以我们的设计是LLM做“要素提取”和“缺失项识别”把提取到的一级要素作为输入去调后端接口补全数据。LLM在这里更像是一个“信息协调者”而不是一个“信息生产者”。凡是能从系统里查到的数据绝不让模型编。2.3 第三层处置动作的生成与工具调用处置是Agent全链路里最有技术含量的环节。一张工单被正确分类、要素齐备之后Agent要基于运维知识库和历史处置案例生成处置动作序列。例如从网管拉取设备告警、Ping测链路、查看光功率、检查流量占用判定故障根因然后给出处置建议或者直接执行某些自动化的修复操作。这里用到的是典型的ReAct模式。Agent每执行一步把工具返回的结构化结果连同当前状态交给LLM分析LLM决定下一步动作循环往复直到完成处置。举一个例子某张政企专线中断的工单Agent先调用网管接口查询专线两端设备状态发现远端设备上报“信号丢失”再调用资源管理系统确认该设备所属物理路由结合知识库判断大概率是光缆中断于是触发光缆故障流程把工单转向传输专业并附上定位信息。整个过程看似简单实际模式里每一步LLM有两个选择继续调用下一个工具、直接生成最终结论、或者请求转人工。这个“决策边界”必须在设计阶段用提示词和Agent状态约束好。工具调用层面的一个重点所有工具的入参和出参必须严格定义。我们踩过很深的坑是让LLM“自由发挥”参数结果它把设备IP和告警ID写在错误字段工具调用直接失败。后来所有工具都做成“参数模板枚举值校验”LLM只能从模板选择参数值不能再自由编造。2.4 第四层闭环验证与自动回单处置完成不代表流程结束。运营商工单系统要求“闭环处置”也就是说Agent执行完操作之后必须验证效果并生成符合规范的回单内容。处置验证有两个层面一是工具层面的验证比如执行了重启操作后必须再查设备状态确认恢复二是业务层面的验证比如修复完成后需要触发一次拨测或性能检查确认用户体验恢复。自动回单是另一个容易被低估的环节。工单回单不是随便写几行字就能过关的回单要包含故障原因、处理过程、修复时间、遗留问题等结构化字段且要满足考核规范。我们的方案是让Agent基于全链路的执行记录自动生成回单草稿再由值班人员一键确认或者修改。这个设计的价值很大回单这件事本身占用运维人员大量时间生成草稿能把“从零写”变成“改几笔”效率提升非常明显。3. 选型逻辑模型、框架与工程架构怎么定3.1 模型选型通用大模型与行业微调的取舍模型选型是Agent项目里争议最多的话题。我们经过多轮对比最终选择的是基于开源底座做私有化部署的路径。原因很现实运营商对工单数据出境和数据安全要求极高工单内容里包含客户姓名、身份证号、具体地址、业务办理信息绝对不能调用外部API处理。所以像GPT-4或者国内公有云大模型API这条路基本不现实只能选私有化底座。私有化之后还有一个选择直接用开源通用模型还是做行业微调。我们实际的结论是优先用底座模型的通用能力微调放到后期按需再做。原因在于Agent链路上的很多能力——工具调用、意图理解、结构化输出——底座模型已经具备而且在工单分类这个任务上提示词工程的效果远大于微调。微调更适合的场景是“特定输出风格或领域术语的稳定生成”比如回单内容的格式和措辞。我们在第二期做了轻量微调让模型更稳定地输出符合运营商规范的回单语句效果不错但那是锦上添花不是地基。对比维度上我用一个表格把当时评估的几个核心指标列一下选型维度通用大模型API开源底座私有化行业垂直大模型数据安全差数据出境好完全内网好完全内网初始效果强中需提示词工程中上依赖训练数据质量迭代成本低中高可控性差依赖厂商高可调可改高但改不动基础能力试错成本低中极高运营商场景要的是可控和稳妥私有化开源底座是性价比最高的起点。3.2 Agent框架用LangGraph还是自研状态机Agent框架的选型直接决定了开发效率和后续维护复杂度。我们对比了LangChain、LangGraph、自研框架三类方案。LangChain上手快但偏“胶水层”流程稍微复杂一点就变得难以控制LangGraph能显式定义状态图和节点流转适合工单处置这种固定流程动态决策混合的场景自研框架最灵活但成本太高我们评估后认为第一版没必要。最终核心链路采用了LangGraph来做编排。原因是工单处置流程的确定性很强——“查告警→查资源→查知识库→生成结论→执行操作→验证效果”——这些步骤有明确的顺序但每步之间又依赖LLM做动态判断。LangGraph的状态机模型正好匹配这个需求节点是确定的动作边是LLM的决策结果。状态图定义好之后每一步的输入输出都有明确的Schema控制不会出现流程漂移。框架层面有个非常重要的实操建议不要让Agent“完全自由地决定下一步”。很多人做Agent喜欢让LLM自己选工具、自己决定流程看起来很强实际运营中很难把控。正确的姿势是把80%的流程用代码固定只留20%的决策点给LLM。比如“工具链顺序”这种用状态图固定“查告警后是否继续查光功率”这种判断点才交给模型。这样既保留智能性又保住确定性。3.3 关键工程决策私有化部署、权限隔离和可观测性模型和框架定了之后工程架构上还有几个绕不开的决策。第一是部署形态。我们选的是“GPU集群统一部署多场景共享”的方式而不是每个业务场景单独部署一套模型。工单Agent、知识库问答、回单生成共用一个模型服务通过路由策略分发到不同Prompt模板。这样GPU利用率高很多运维成本也可控。第二是权限隔离。Agent要调用网管接口、执行自动化脚本这意味着Agent具备了运维操作权限。必须设计严格的工具权限边界Agent默认只能调用只读类工具需要执行变更操作时必须先申请令牌且令牌有效时间内只允许执行白名单命令。这个设计保护的不是“防止Agent乱来”而是防止Prompt注入攻击导致Agent被恶意引导执行危险操作。第三是可观测性。Agent链路的每一步推理、每一次工具调用的入参和出参都必须被完整记录。我们给每条工单生成了全链路trace相当于给Agent的每个决策拍了X光片。这样做的好处有两个一是排查问题时有据可查二是后续优化Prompt和模型时能精准定位到出问题的环节。可观测性不是锦上添花是Agent系统能持续迭代的前提。4. 核心实现落地的几个关键细节4.1 Prompt设计的几个真实经验Prompt工程在Agent链路里占比很重我分享几条基于实测的经验。第一Agent的System Prompt必须讲清楚“你是谁、你在哪、你能干什么、你不能干什么”尤其要把工具边界讲清楚。工单Agent的System Prompt里明确写着“你只能使用提供的只读工具查询信息和检索知识库所有变更操作必须先申请变更令牌”这比在工具层拦截更有效因为模型在决策阶段就会规避不该做的事情。第二分类路由的Prompt要用“少样本枚举约束”的方式把工单类型的枚举值、判定标准、相似场景的区分点直接塞进Prompt。比如家宽故障和政企专线故障怎么区分光猫重启和基站退服怎么区分这些判定规则要写得非常明确。少样本示例尽量选真实工单改写比凭空编的示例有用得多。第三工具调用的Prompt要分两层工具描述层和调用规则层。工具描述告诉模型这个工具是干嘛的、入参是什么调用规则告诉模型“什么条件下才调用这个工具、参数怎么填”。我们把这个设计叫做“用法与场景分离”这样工具新增时只要改描述不需要动核心Prompt。4.2 工单层级路由的实现思路分类路由虽然看起来简单但要真正做到“分得准、分得稳”实现上是分层处理。我们在代码里定义了一个三级路由配置一级是业务域二级是子类三级是具体的处理团队和流程模板。LLM产出的分类结果是一个结构化的Category对象包含三级编码。路由模块拿到编码后从配置中心加载对应的处理流程模板决定后续Agent节点的启用与顺序。这段代码思路大概是这样的class WorkOrderRouter: def __init__(self, category_config): self.category_config category_config # 三级分类配置 def route(self, category: dict, work_order: dict): # 根据LLM输出的三级分类编码查找路由策略 strategy self.category_config.get(category[domain]) \ .get(category[sub_type]) \ .get(category[detail_type]) if not strategy: return {action: review, reason: category_not_found} # 优先级叠加规则重大故障、重复报障、VIP客户加权 priority self.calculate_priority(category, work_order) return { action: dispatch, team: strategy[team], flow_template: strategy[flow_template], priority: priority }路由结果的稳定性比“完全智能”更重要所以配置中心里维护的流程模板是一张“该走什么路”的地图Agent只负责判断“当前在哪条路、下一步怎么走”。4.3 RAG知识库建设决定Agent专业度的隐形关卡Agent能给出什么样的处置建议很大程度取决于知识库能检索到什么内容。运营商运维知识库的现状是“资料很多、结构很乱、更新很慢”。我们建设RAG知识库时做了几件事第一把历史工单处理记录转化为问答对这是一座巨大的金矿因为历史工单里记录了真实的故障现象和处置动作第二把设备厂商的维护手册分成章节切片按设备类型和故障类型打标签第三网管告警的解释和影响分析整理成结构化条目。检索策略上我们做了混合检索——向量相似度与关键字匹配结合。原因是知识库里大量专业术语是“告警名称设备型号故障代码”的组合纯向量检索找不准纯关键字召回又不全混合模式的召回效果最好。在实测发现一个有趣现象对历史工单构建的问答对用向量检索效果极好对厂商手册关键字的BM25召回更可靠。同一个知识库里不同数据源用不同检索比重这个配置经验直接让最终答案的准确率提升了一截。4.4 工单闭环处置的状态机设计闭环处置的流程控制我们用LangGraph实现了一个状态机。状态集合包括待分类、分类完成、要素提取中、信息补齐中、处置方案生成、工具调用中、变更审批、处置验证、回单生成、人工复核、已关闭。每个状态代表一个稳定的阶段LLM的决策只发生在状态转换的时刻不会影响状态的完整性。有一个状态设计上的细节值得展开变更审批状态。Agent执行完诊断分析之后如果需要执行修复操作并不是直接执行而是先进入“变更审批”。审批通过后Agent才能执行实际操作。审批这个动作可以根据变更等级自动完成低风险变更比如重启用户侧光猫Agent自己就能批高风险变更比如重置核心网设备必须推到运维专家确认。这个分级审批机制既提升了自动化率又把安全红线牢牢守住是闭环链路里最值得优先实现的部分。5. 踩坑实录与排查速查表5.1 高频问题清单任何系统落地都不可能不踩坑这里把真实项目中遇到的高频问题整理成速查表给各位做一个避坑参考问题现象根因分析解决思路LLM输出的分类结果格式不固定Prompt约束不足引入JSON Schema强制结构化输出解析失败就重试一次再失败转人工Agent调用工具时参数填错工具参数描述不清晰把参数改成枚举值模板禁止模型自由填写字符同一张工单反复被Agent处置缺少幂等控制工单维度加处置状态锁Agent启动前检查是否已有进行中任务知识库检索结果不相关数据切片和召回策略不匹配按数据源分配合适的检索权重做混合检索Agent环消息分析后给出错误结论模型幻觉要求模型必须输出“证据引用”字段无证据不能下结论并发量一高推理延迟明显模型服务缺少调度优化增加vLLM等推理框架启用continuous batching回单内容不合规范模型对业务规范理解不足回单生成使用专用Prompt模板微调生成后自动过一轮规则校验5.2 几个值得说透的避坑建议第一个建议不要把LLM当成“万能的”。在工单处置这个场景里LLM负责的是理解、判断、生成建议但真正执行操作必须走确定性代码路径。所有工具的调用都要有参数校验和结果校验。LLM的角色是“决策者”不是“执行者”这个边界越清晰系统的稳定性越高。第二个建议Agent的结果必须能被审计。工单系统是运营商生产系统每一张工单的处理过程都要能追溯到人或者系统。我们的方案是给Agent链路的每一步生成审计日志Agent的推理过程、工具返回、中间结论全部记录。这样一旦出问题可以快速复盘到底是模型判断错了还是工具数据错了。第三个建议设立人工兜底的逃生舱。无论Agent做得多么好都不能完全去掉人工。我们设计了一个“Agent处置置信度”指标Agent内部对每个环节的置信度做综合评分低于阈值的工单自动转人工处理。这个设计看起来保守但实际价值非常大因为它保证了Agent能力的上限同时用人兜住了下限。第四个建议评估指标不能只看准确率。工单Agent的效果要用“闭环率”“平均处置时长”“人工介入率”“返工率”这些业务指标来评价而不是只看分类准确率。我们第一期只统计分类准确率看起来很好但真正上生产后发现处置时长的优化没有想象中明显。后来改成“端到端闭环率”作为北极星指标整个系统的优化方向才真正对齐了业务价值。6. 后续演进方向这套系统落地之后我们已经开始规划第二阶段的演进。方向一是把Agent从“被动处置”升级为“主动预防”基于历史工单和告警数据训练预测模型在故障发生前主动生成巡检任务和处理预案。方向二是让Agent具备跨工单的关联分析能力——几张工单看起来是独立的家庭宽带故障但Agent发现都集中在同一台OLT设备下就能自动聚类并向上报告可能的设备级隐患。方向三是工单处置经验的自动沉淀——Agent每天都在处理工单产生的大量有效处置路径应该被自动提炼成新的知识库条目形成“越用越聪明”的正循环。我个人在实际操作中最大的体会是Agent项目的成败技术选型只占三成剩下七成在工程化细节。模型再强没有严格的参数约束、没有结构化的输入输出、没有完整的可观测性落到生产环境都会变成一团乱麻。做运营商工单Agent尤其如此生产环境对稳定性和安全性的要求极高任何一环的“自由发挥”都会付出代价。反过来只要把工程的骨架搭扎实了模型能力提升带来的收益会非常直接地被业务看到。希望这篇基于实战的梳理能帮正在这条路上的同行少走几个弯路。