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的"智能"上，后期才把重心转回到流程、数据、评估和审计这些苦功夫上，而后者恰恰是让系统能真正长期跑在生产系统的原因。
后续如果想继续扩展，我会优先做两件事：一是把知识库的能力往"半自动更新"推进，让运维人员在处置故障时随手沉淀的方案能自动进入候选库；二是支持多省联合部署，让不同省份的工单分类经验和处置预案能安全地横向共享。这两个方向，目前在架构上已经留好了接口。
