1. 先看清战场运营商工单体系为什么先胖起来再受困于胖凌晨三点某省运营商的宽带故障告警像开了闸一样往下刷。NOC班长的手机震动频率比心跳还快他需要在十分钟内判断哪些是真障、哪些是抖动、哪些是重复告警然后把工单派到对应的维护网格。那天的局面是四十几号人三千多张工单处理到第二天早上八点仍然有八百多张滞留。这不是个别现象是运营商工单体系的标准日常。1.1 一张工单背后其实是一整套系统的交互先说清楚工单在运营商场景里到底指什么。它不是一个简单的用户售后请求而是一个跨B域业务域和O域网络域的协同单元。我接触过的真实工单类型大致有这么几类网络告警类工单由网管系统比如华为iManager、中兴NetNumen、爱立信OSS自动派发包含故障码、网元ID、影响范围通常带着大量冗余信息用户投诉类工单来自10086/10000客服入口是用户用自然语言描述的网络问题网速特别慢电视盒子一直卡宽带经常断这类说法没有统一格式装移修类工单装机、移机、修障等作业工单涉及预约时间、施工人员、工艺规范政企专线故障单SLA要求高通常有明确的时限指标和处罚条款定位稍微慢一点就要折款跨部门协办单一个故障牵扯无线、传输、核心网多个专业需要跨班组流转。这些工单每天的体量在省级运营商通常是数万到数十万张高峰值翻两三倍也常见。单看数据量还不算真正可怕可怕的是每一张工单都要过一遍人客服坐席要理解用户描述NOC值班长要人工判断告警归属派单员要根据经验找到对口班组处理人员要去查网管、回用户、出方案。一个人一天能精处理的工单量是有限的一旦量级上来瓶颈不在系统算力而在人的认知带宽。1.2 量大但质低的真正根源不是人手不足如果只是人手不足加人就能解决问题没这么简单。我复盘过大量滞留工单发现真正的病根有三个。第一个是信息密度极不对称。告警工单里全是专业字段用户工单里全是口语表达同一故障在不同入口的描述方式完全不一样。传统系统按模板填字段一个人填出来的描述永远是残缺的后面的人看不懂只能反复打电话确认。这个确认动作就是工单滞留的最大时间黑洞。第二个是分类路由依赖个人经验。哪个问题该派给哪个班组老员工看几行描述就能判断新人则要查手册、问同事。人一走经验就没了。我见过有的省公司派单准确率在七成上下徘徊剩下三成工单在班组之间来回被退回非本班组职责一张单光流转就能耗掉三四个小时。第三个是闭环形同虚设。工单系统里状态写的是已解决但实际上可能只是处理人员点了个按钮用户侧根本没恢复。缺少自动验证的手段也就缺少对解决的信任。想清楚这三个病根之后我当时的结论是这不是加几个人或者优化一下派单规则能解决的需要重新设计一套能够看懂工单、自动路由、执行处置、反验结果的系统。这正好是智能Agent的用武之地。2. 智能Agent能干到什么程度职责边界是第一设计跟很多人的第一反应不同我在一开始就把Agent的任务限定得非常窄它不是一个全自动外包团队而是一个高水平的工单助手。把职责边界想清楚后面的技术选型才不跑偏。2.1 适合交给Agent的环节我在项目里划了五个可落地的环节工单分类把自然语言的用户投诉和结构化的告警信息归一到统一的分类树比如传输故障/光缆中断/接入侧这是后续一切动作的基础意图识别与信息抽取从工单正文里提取关键实体如网元名称、故障码、影响区域、用户预约时间知识检索与方案推荐在故障知识库、历史工单、应急预案库中检索最匹配的处理方案输出给处理人员或Agent执行摘要与话术生成把冗长的告警信息压缩成一段人话给客服生成回复用户的话术统一口径处置子任务的编排与执行当Agent判断某个故障符合预设预案条件时调用网管接口执行预检、重启单板、调整参数等动作并在执行后自动验证。这五件事有两个共同特征它们都是非确定性推理任务存在多种合理答案同时又都是高重复性的劳动。重复加不确定刚好是模型的强项。2.2 必须留在流程外的部分以下环节我在项目里明确不让Agent碰工单编号、SLA计时、超时升级这类强一致性操作必须由传统流程引擎保证模型生成的输入只允许作为建议不能直接改写这些字段涉及权限变更、账号开通、资费修改等敏感操作一律走原有的人审流程Agent最多完成审批材料的预填工单最终的归档和审计必须保留完整人工操作痕迹Agent的每一步动作都要有日志不能有黑盒用户个人信息的原样流转姓名、身份证号、家庭住址等字段在模型链路里一律脱敏。这个边界看起来保守但恰恰是它能上线的关键。运营商的合规审计非常严格如果让Agent直接闭环改资费、给权限系统根本过不了评审。Agent的价值应该是把90%的信息处理工作做完让人的精力集中在真正需要判断的10%上。3. 分类路由的选型规则兜底、模型居中、LLM做纠偏的三明治分类路由是整个系统的地基。路由错了后面一切自动化都白搭还会引发新的工单风暴。这个模块我前后换过三版架构最终稳定在规则 传统模型 LLM三层混合的形态。3.1 三种方案各自的脾气纯规则方案用正则表达式和关键词表匹配。优点是快、稳定、可解释性好、审计方便缺点是覆盖面窄泛化能力几乎为零。用户写网速慢得想砸手机规则靠关键词是抓不住慢的更抓不住情绪。机器学习分类方案我用过fastText和BERT系模型做工单标题/正文的短文本分类。它比规则灵活能理解一定的字面语义但需要足够的标注样本而且对长尾类别的识别能力有限。运营商的故障类别里有大量低频但重要的场景比如某个老旧设备的特定告警这类样本量太少模型学不好。LLM方案大模型对语义的理解力最强零样本和少样本就能开展工作能处理各种不按套路出牌的描述。但它有两个问题一是成本高每张工单都跑一次大模型推理量起来之后开销不小二是时延不稳定高峰期的推理抖动会影响路由时效。更关键的是可解释性差出问题后你很难说清楚它为什么派错了。单一方案都不完美于是我把它们组合起来让每种方案负责自己最擅长的部分。3.2 混排架构的完整路由判定流程我落地时采用的判定链路是这样的第一步工单进来后先做字段规整和实体抽取把设备类型、故障码、区域、专业等关键字段结构化第二步规则引擎优先判断。命中高确定性规则比如特定故障码对应特定设备厂家的直接路由不经过模型第三步规则没有命中或置信度不足的进文本分类模型。模型输出一个分类结果和置信度得分。置信度大于0.9的直接按模型结果路由置信度在0.6到0.9之间的交给LLM做二次纠偏LLM结合知识库判断给出推荐类别和理由置信度小于0.6的进入人工复核队列同时把LLM给出的几个候选类别作为提示给值班员。这个三明治结构我用了很久之后体会最深的一点是它不是为了炫技术而是为了把成本用在刀刃上。高确定性工单可能占了总量的40%完全用规则零成本秒掉中间一部分用相对便宜的BERT模型处理只有长尾、复杂、边界模糊的单子才舍得让LLM去推理。整体算下来每张工单的平均推理成本比纯LLM方案低了60%以上时延也更可控。3.3 为什么最终没有选择纯LLM路由其实最开始我也做过纯LLM的Demo效果看起来很惊艳分类准确率甚至比混合方案还高两个点。但到了上线评估的时候几个现实问题让我放弃了。第一个是成本。纯LLM方案在日处理二十万张工单的量级下GPU成本和API调用费是混合方案的数倍。就算只让大模型跑长尾工单也已经能达到同样效果没必要让简单工单付同样的钱。第二个是稳定性。我遇到过模型供应商在深夜做版本升级第二天凌晨整批工单的分类结果全部变了口味。工单路由这种东西要的是每天早上八点跟凌晨四点的行为一致模型行为随版本漂移是生产系统的大忌。第三个是可审计性。运营商内部对派单有明确的SLA和差错考核规则和传统模型的结果可以逐条回溯而LLM的推理过程很难做差错定责。这三个原因加一起我最终把LLM定位成纠偏器和兜底者而不是主路由。这不是保守是技术选型要匹配业务责任的必然结果。4. 闭环处置从看懂工单到替班组长干活分类路由解决了这张单该谁处理的问题闭环处置要解决的是这张单怎么算结束的问题。这是智能Agent价值最能被管理层直观感知的部分。4.1 闭环的主干状态机我先定义了一套完整的工单生命周期状态Agent的所有动作都围绕状态机推进初始状态是已受理工单进入系统Agent完成信息补全和分类待分派完成路由等待接受班组或直接推送给对应资源处理中Agent或运维人员正在执行处置动作等待用户确认处置完成但需要用户侧反馈验证的例如远程重启光猫后需要用户确认网络恢复待验收系统自动做了健康检查等待值班长最终确认已关闭或重开验收通过归档或者用户反馈再次故障后自动重开。状态机必须是硬编码的流程不能由大模型自由跳转。Agent能做的是在状态机允许的框架内操作比如在处理中状态下调用工具在待验收状态下执行自动验证。这样做主要是为了让整个流程可追踪、可回滚、可审计。4.2 主动告警驱动的自治闭环告警工单场景是Agent自动化程度最高的部分。我举个例子说明整个闭环是怎么转的。假设网管凌晨报出一条某PTN设备单板端口CRC错误率超阈值的告警。Agent收到后做的事情是这样的从告警信息中抽取网元ID、板卡槽位、端口号、告警开始时间自动查询该网元的资产台账确认型号和所属维护网格检索知识库和历史工单找出过去三个月同类故障的处置记录统计成功率如果历史记录显示60%的情况可以通过端口软复位恢复Agent会判断这是低风险操作走预案通道调用网管北向接口下发软复位指令等待三分钟再次查询该端口的CRC误码率是否回落、告警是否清除告警清除则自动验证通过生成本次处置的摘要日志状态置为待验收如果告警还在则升级为人工工单附上Agent已经做过的所有操作记录。这套流程跑通之后我看过一次真实数据某地市一周的传输告警工单里大约有18%的工单实现了全自动闭环从发现到恢复平均耗时从人工处置的42分钟降到了6分钟。这18%看着不多但它们通常是分布在最让人头疼的凌晨时段正好是人手最紧缺的时候。4.3 用户投诉驱动的处置闭环用户投诉工单比告警工单难很多因为信息藏在口语里而且故障现场可能在用户家里。Agent在这个场景里的定位不是直接操作网络设备而是快速理解问题、给出可执行的排障路径。用户的投诉是家里网络电视时不时卡光猫的信号灯看着正常。Agent收到后抽取关键实体业务类型IPTV、现象卡顿、设备状态光猫指示灯正常对照台账确认该用户使用的接入方式、光猫型号、套餐带宽检索知识库找到该光猫型号的已知问题和对应排障流程如果知识库有标准处理流程Agent生成一份分级排查建议先是用户侧自查重启光猫/检查网线如果用户反馈无效则升级为上门检测工单并自动附上光猫近一段时间的日志调取请求整个过程中Agent与用户的交互话术、排障建议全部生成草稿由客服坐席确认或直接通过自助渠道发送给用户。这个场景里Agent的价值不是替代装维师傅而是把原先是客服一个人边听边查系统边想方案的工作变成了系统先梳理好人只需要审核。我实测下来客服的单通平均处理时长从380秒降到了190秒左右而且新员工的培训期从三个月缩到了不到两周。4.4 工具调用、记忆与编排的落地细节支撑上面两类闭环的是Agent的三块基础设施。工具调用层我封装了网管北向接口、资产查询、知识库检索、工单系统CRUD、短信/公众号触达等十几个工具。每个工具都有独立的鉴权和超时配置。特别是网管操作类工具只读操作可以直接授权写操作必须在预案白名单内且要留审计记录。记忆层对单张工单而言Agent要维护一份工单上下文记录当前状态、已执行动作、模型判断依据对系统层面它要周期性维护一份知识索引把新沉淀的处置案例回写知识库。编排层我用的是工作流引擎加速而不是自由发挥式Agent。对高确定性的场景直接用预编排流程只有碰到流程分支交叉时才引入大模型做判断。这样做的原因很简单编排确定行为就确定行为确定审计才成立。5. 工具链选型逻辑扣子Coze、自研框架与商业平台的取舍聊完架构聊聊实际落地时工具链怎么选。这个话题几乎每次交流都会被问到因为很多团队一上来就陷入到底要不要自研的纠结。5.1 三类路线的核心差异对比我把市面上能走通的路线分成三类自研框架基于LangChain、FastGPT、RagFlow等开源项目搭建、低代码Agent平台比如扣子Coze、商业垂直产品各厂商的工单AI解决方案。三类方案的差异我用一张表列过维度自研框架低代码Agent平台扣子Coze等商业垂直产品开发周期长通常3-6个月起步短1-2周可以出可演示原型最短开箱即用模型可替换性高一套代码可以自由切不同模型中平台内可切但换平台要重搭低通常绑定厂商与内部系统对接最灵活直接写接口中支持HTTP接口和插件扩展看厂商能力通常需要定制私有化部署完全可控部分场景支持需评估网络要求高但成本也高权限与安全审计自建需要专门投入平台能力为准需自己补审计厂商提供相对完善长期维护成本高中高许可费定制费5.2 我建议的落地节奏我自己比较推荐的路径是用低代码平台做原型用自研框架或平台化方案做生产。具体操作是先别急着写代码。用扣子Coze这类平台把工单分类路由的流程搭一个可交互的Demo接入几个模拟工具让业务方NOC班长、客服主管先真实点一点、用一用。这一步花不了两周但能解决最大的需求风险你以为需要的能力业务方可能根本不用业务方天天抱怨的痛点你原以为不是问题的反而是核心诉求。原型阶段让业务方提意见比你闷头开发三个月再去推倒重来成本低一个数量级。把这个原型跑通、需求圈定之后再评估生产方式。如果只需要处理十万级工单且算力预算紧张可以考虑自研精简版如果团队没有专门的AI工程资源那就继续在低代码平台上做大流量优化把插件、知识库、工作流用熟然后把平台能力跟内部系统通过API打通。我们当时就是先拿扣子搭了两周原型确认了业务主流程才回头补齐自研系统的接口和权限设计整个需求讨论时间压缩了一半以上。5.3 与运营商B域/O域系统的对接边界无论选哪条技术路线真正的对接难点都不在Agent内部而在Agent跟外部系统的衔接。我踩过的主要有三处。第一处是网管接口的协议差异。不同厂家的网管北向接口格式完全不同有的提供RESTful有的只有CORBA或者SNMP。我的处理方式是统一封装一层适配层在网关层做格式转换Agent只管调用标准化的内部API屏蔽厂商差异。第二处是工单系统的写权限。很多老系统的工单创建、流转靠的是数据库直接改字段接口能力很差。我们没有硬改而是接消息队列通过监听工单变更事件调用异步回写接口的方式实现闭环避免把Agent直接怼进老系统的数据库。第三处是数据字典的统一。B域的客户信息、O域的网络资源两边用的术语体系完全不一样板卡在B域叫硬件模块在O域叫单板。Agent在做知识检索之前必须先做一轮术语映射否则检索出来的知识全是不匹配的。这块我们在知识库里单独维护了一份术语对照表效果比让大模型现场推理稳定得多。6. 踩过的坑准确率飘移、数据合规与模型自信过头技术方案的坑如果光看技术文章很少被提醒我这里把我踩过最惨的几个列一下你们上线前一定提前绕开。6.1 模型置信度陷阱传统分类模型会给一个softmax概率当置信度但这个概率对是否可以直接路由并不总是可靠。我遇到过某类工单模型给出的置信度是0.92结果照样分错原因就是这个类别本质上特征模糊模型只是习惯性地高自信。后来我做的改进是加了一个路由可信度的后置校验逻辑让LLM对模型的高置信结果做抽样复核发现某种特征组合频繁出错的就把这一类降级为人工复核。6.2 Prompt与模型版本的漂移生产环境里我吃过一次大亏某个Prompt模板在测试环境连续用了一个月都没问题结果模型供应商更新了底座版本后同一条Prompt的输出风格大变影响了路由纠偏结果。从那以后我们建立了Prompt版本管理所有Prompt模板都纳入Git管理每次上线前跑一遍固定的回归测试集测试集里包含200条历史工单的标准答案准确率低于阈值就不允许发布。6.3 个人信息脱敏和操作审计客服投诉工单里有大量用户个人信息。我们的模型链路统一做了脱敏姓名替换为占位符、手机号/居住地模糊化模型只处理脱敏后的文本。知识库和日志系统也分开部署Agent调用的模型完全看不到原始个人信息。这个设计一开始大家都觉得多此一举后来安全检查的时候发现正是这个设计让整个系统顺利过审。6.4 资源开销与熔断设计大模型推理是不定时炸弹高峰时段的请求可能抖动。我的做法是在Agent和模型推理服务之间加了一层熔断器连续出错或超时比例超过阈值自动降级为纯规则人工模式宁可让工单多走一步人工也不能让整条生产链路堵死。这个熔断器救过我两次一次是模型提供商的上游故障一次是我们自己误发了一批语料导致推理服务瘫痪。7. 效果量化与持续迭代ROI怎么算才靠谱做工程的人最终要回答一个问题这套系统到底值不值。我建议用四个指标回答而不是一个。7.1 一套实测的指标体系我们在项目中重点盯这四个分类路由准确率、首派及时率、自动化闭环处置率、平均处理时长。分类路由准确率对比人工标准答案系统直接派单与最终处理部门的匹配比例。上线前人工经验分单约70%混合架构跑稳后到了92%左右。剩下的8%不是模型不行而是很多工单本身就模糊尤其是跨专业故障这类单子拉入人工复核是合理的。首派及时率分单动作在工单到达后一分钟内完成的比例。从原来的23%升到了89%因为规则和模型都是毫秒级决策只有少量长尾单才会触发人工。自动化闭环处置率这指的是不需要人参与就从始到终完成处置的工单占比。我们从0做到15%左右不要小看这个数字它相当于每天自动处理了几千张最辛苦的基础工单。平均处理时长针对可控范围内的常见故障平均处理时长下降了约35%。这个数字在管理汇报里最好用因为它直接影响了客户满意度指标。7.2 从bad case到周迭代的正循环指标只是结果真正的关键是迭代机制。我们每周五固定做一次bad case review把所有被业务方退回的工单集合起来按原因归成几类——是路由错了、知识库没匹配到、还是模型判断过程出错了。然后分类处理如果是规则覆盖不足就补规则如果是知识库缺方案就沉淀拆解文档如果是模型问题就把这批case加入标注集重新训练或构造Prompt的few-shot示例。这个循环坚持了三个月准确率和闭环率的提升其实主要来自这个机制而不是某一个模型一夜之间的改进。到后期每周新增的bad case数量从几十条降到了个位数说明系统的知识沉淀已经进入了一个相对稳定的状态。7.3 个人复盘与后续想做的方向最后想说的是这套系统真正难的从来不是算法而是把模型当成工单处理流水线上的一个普通协作者来看待。它要足够快、足够稳、足够可回溯而不是越聪明越好。我在实际项目中体会最深的是早期我把精力过多放在调Agent的智能上后期才把重心转回到流程、数据、评估和审计这些苦功夫上而后者恰恰是让系统能真正长期跑在生产系统的原因。后续如果想继续扩展我会优先做两件事一是把知识库的能力往半自动更新推进让运维人员在处置故障时随手沉淀的方案能自动进入候选库二是支持多省联合部署让不同省份的工单分类经验和处置预案能安全地横向共享。这两个方向目前在架构上已经留好了接口。