1. 这到底是怎么一个项目工单池里长出来的隐形主管先交代一下背景。我在一家省级电信运营商干了快六年一直在OSS域运营支撑系统混工单系统是每天都要打交道的东西。如果你没在运营商待过可能很难想象工单池到底有多恐怖——宽带装维、故障申告、投诉转派、资源变更、政企专线开通、存量割接……光工单类型就有上百种每天涌进来的工单量是以万为单位的高峰期甚至能到几十万。干过工单运营的人都知道真正吃人的不是工单本身而是工单的流转这张单子该派给哪个部门是装维班组还是传输班组是省公司专家台席还是地市综调工单优先级怎么定处理时限怎么算有没有同类故障可以合并处理完以后质检合不合格这几个环节但凡有一个掉链子工单就会像皮球一样被踢来踢去最后变成投诉。这个项目的核心目标就是做一个面向海量工单的智能Agent系统把从工单进来到工单关闭之间的所有人工判断环节接过去。不是做一个花哨的AI对话框而是让Agent自动完成四件事识别工单类型、判断该往哪儿派、给出处置建议、跟进闭环结果。说白了就是给工单池配一个不知疲倦的隐形主管。项目上线后我们最关心的指标其实就三个首次分拣准确率、平均处理时长、工单积压率。第一个指标决定Agent能不能被信任第二个指标决定它的价值第三个指标决定它会不会把系统搞崩。这篇文章不讲PPT上的大道理就讲我们实际踩过的坑、对比过的方案、以及最终为什么选了这样一条技术路径。2. 分类路由才是真正的硬骨头不是套个BERT就完事2.1 为什么分类路由是整个系统的生死线很多做智能工单的人上来就扑向意图识别知识库问答这些听起来高级的方向但我必须泼一盆冷水分类路由没做好后面全是空中楼阁。原因很简单。工单Agent的每一次处置动作几乎都以这张工单是什么为前提。你连这是宽带故障还是政企专线变更都没分对后面给出的处置建议、派单部门、SLA时限全是错的。我在项目初期做过一个统计人工复核阶段发现分类错误导致的工单二次流转平均每单多消耗47分钟——这个数字听起来不多但乘以每天几万的工单量就是巨大的浪费。而且电信工单的分类有个特别恶心的特点类别边界高度模糊。用户宽带无法上网可以是接入层故障也可以是认证平台故障还可以是OLT上行链路故障电视卡顿可能是IPTV平台问题也可能是家庭WiFi覆盖问题。同样的现象描述落到不同场景就是不同分类。这跟电商工单退货退款那种干净利落的分类完全不是一个量级。2.2 规则引擎打底先用笨办法建立安全网我们一开始就没有直接上深度学习模型而是先搭了一套规则引擎 关键词库的基础分拣系统。理由很实在Agent上线初期必须保证不闯大祸而规则引擎的行为完全可解释、可回溯出了问题能立刻定位。规则引擎的核心是三层判断第一层工单来源和工单类型字段。运营商工单系统里其实有大量结构化字段比如业务类型产品类型故障代码很多模型方案把这些字段丢了只做文本分类非常可惜。我们把这些字段当作最高优先级的特征字段能定死的就不让模型猜。第二层关键词命中。针对每个工单类别维护一套关键词库比如光猫闪红灯LOSPON口这种词命中后直接指向接入层故障认证失败691radius这类词指向AAA认证域。第三层兜底规则。以上两层都解决不了的走默认路由到人工复核队列绝不硬分。这套规则引擎上线后首轮分拣准确率大概在78%左右。听起来不高但它非常稳定而且所有分拣理由都能用红框标出来——因为工单包含关键词X所以派往Y部门。这在初期建立运维团队信任感上起了决定性作用。没有这个笨办法打底后面模型调优阶段大家会吵翻天。2.3 模型分级融合为什么最后选了轻量模型 大模型兜底规则引擎的瓶颈很快就暴露了它可以覆盖高频的、话术雷同的工单但面对那些描述冗长、夹杂情绪、甚至包含错别字和方言的工单关键词匹配就开始失灵。比如我家网速测出来只有20M路由器重启了也没用以前都好好的——这种句子关键词很少但语义指向非常明确。我们对比测试了三种方案方案思路测试准确率平均单耗推理时间问题A传统机器学习TF-IDF SVM/GBDT文本向量化后分类82.1%约20ms对长尾类别和语义泛化能力弱BBERT类预训练模型微调句向量 分类头89.6%约80ms需要持续维护标注数据推理资源有压力C规则层 轻量模型主分类 LLM兜底三级递进94.3%混合链路复杂需要设计好调度逻辑最终我们采用了方案C。触发逻辑是这样的规则层能定死的直接出结果不再浪费时间规则层搞不定的交给一个微调过的ALBERT模型比BERT轻量得多推理速度更快做主力分类ALBERT的置信度低于阈值我们设为0.75或者命中了难例队列再调用大模型做深度语义理解。为什么不让大模型直接处理全部工单一句话成本和延迟扛不住。电信工单每天几万条全部走大模型推理成本按API计费就是天文数字而且大模型单次推理的延迟分钟级以内虽然可接受但高峰期并发会直接把网关打爆。让便宜快准的规则和轻量模型处理80%的流量只把真正难的20%交给大模型这是工程上的必然选择。尤其是在生成式AI大火的这两年不少团队容易陷入什么都让大模型来的冲动但真实的业务场景里性价比和稳定性往往比炫技重要得多。2.4 工单分类的标注体系比模型更重要的长期资产分类路由这一节我必须单独聊聊标注体系。很多团队做分类项目翻车不是模型不行而是标注数据根本没法用。我们的工单数据有几个绕不开的老大难第一历史工单的处理结果并不等于正确标签因为人工处理本身就是可能出错的第二类别分布极端不均衡宽带故障类工单占了60%以上一些政企专线类工单一个月也出现不了几十条第三同一类别的语义中心是漂移的比如光猫这个词在两年前可能只出现在接入故障里现在家庭组网场景越来越复杂它也可能出现在WiFi覆盖类工单里。我们做了三件事来控制标注质量标注规范先行。在启动标注前写了一份极详细的标注手册每个类别都配3个正向样例和3个负面样例界定了模糊边界怎么处理。比如宽带故障和网速慢之间怎么切分手册里有明确规定核心是看用户是否明确表达无法使用。多人标注 仲裁机制。每条工单至少由2人独立标注不一致的进入第三轮仲裁。上线前我们抽检过标注一致率从最初的74%提到了89%。定期回流修正。模型上线后每周抽500条预测结果回灌给标注团队重新标注用预测-人工复核的差异来持续发现类别边界的变化。我们后来发现大约每两个月工单的语义分布就会有一次明显漂移这跟营销活动、网络割接、季节故障都有关系——比如夏季雷雨季节光猫被雷击坏的工单会突然变多这类工单的描述方式和关键词分布和平时完全不同。3. 闭环处置不是回个解决方案就完了状态机才是灵魂3.1 从单点聪明到流程闭环的进化路径先把闭环处置这个词拆开揉碎。很多Agent项目做到给出处置建议就宣布大功告成但真正在运营商业务里建议没人执行等于什么都没做。我们的闭环处置设计要求是Agent不仅要告诉运维人员这张工单应该怎么处理还要负责跟踪处理完了没有处理结果是否正确用户满不满意。这相当于把过去一个工单处理人员从接单到回单的完整动作拆给Agent来做一部分人只需要在关键节点做确认或兜底。这里我用一个例子来展示单点建议和闭环处置的区别。同样是用户光猫LOS灯闪红灯的工单单点建议模式Agent给出建议请检查光猫至分光器之间的光纤链路然后就没有然后了后续执行全靠人工。闭环处置模式Agent生成工单处理预案并附带操作SOP同时自动创建一条光纤链路排查子任务定时检查工单状态超过30分钟未回复则自动升级提醒处理完成后自动核对回单内容是否与预案一致不一致则打回重新处理。3.2 工单状态机的完整设计闭环处置的技术核心是一套工单状态机。我们的状态机定义了七个状态待分拣、分拣完成、待处置、处置中、已回单、待质检、已关闭外加一个回退重分的补偿分支。这里放一下简化版的流转逻辑# 工单状态机核心流转逻辑简化示意 STATE_TRANSITIONS { 待分拣: [分拣完成, 回退重分], 分拣完成: [待处置, 回退重分], 待处置: [处置中, 回退重分], 处置中: [已回单, 待处置], 已回单: [待质检, 处置中], 待质检: [已关闭, 处置中], 已关闭: [], } def transition(current_state: str, event: str, payload: dict) - str: if current_state 处置中 and event submit_result: # 回单后自动进入质检而不是直接关闭 return 待质检 if current_state 待质检 and event quality_fail: # 质检不通过打回处置注意这里需要保留原处置上下文 return 处置中 # ... 其他分支这个状态机看起来简简单单但实际开发中踩了两个大坑第一个坑状态跳变的非法路径控制。一开始我们的状态机允许从待分拣直接跳到已关闭本意是给一些明显无效工单一个快速通道。结果上线后大量工单被运维人员用这个捷径秒关——因为有些工单确实没有处置价值但也有一部分是因为运维人员想偷懒导致用户问题根本没解决就被静默关闭。后来我们紧急改掉了这条路径所有工单必须经过待质检才能关闭并且在质检环节增加了用户满意度字段是否已填写的强校验。第二个坑超时升级机制。工单在处置中卡住了怎么办状态机里必须有超时看板。我们给每类工单设定了不同的SLA时限宽带故障4小时、政企专线2小时、资源变更24小时超时自动触发三级升级第一级推送提醒给处理人第二级升级到班组长第三级升级到部门经理同时工单进入红色展示序列。这个设计看起来粗暴但在运营商这种责任层层压实的组织文化里非常有效。3.3 质检环节闭环里的最后一道闸门质检是整个闭环里最容易被忽视但最关键的环节。我们遇到过很讽刺的情况Agent给出处置建议运维人员确实去处理了结果回单内容写得驴唇不对马嘴——比如工单是宽带故障回单却写着已联系用户解释资费问题。这就是典型的处理了但没对症。我们的质检模块做三层校验字段完整性校验回单里必填项是否齐全处理后状态码是否有效时间戳是否符合逻辑处理完成时间不能早于工单创建时间。内容相关性校验用文本相似度对比工单原文和回单内容如果两个文本的语义相似度过低说明回单很可能答非所问直接打回。结果一致性校验将回单里填写的故障原因和处理动作与Agent预案里的建议做匹配如果不匹配且没有合理解释打回重新回单。这三层校验层层递进把回单质量从完全依赖人的自觉变成了一套可量化的流程。上线质检模块后我们一度需要人工复核的工单量下降了22%因为很多低质量回单在自动环节就被拦截了。4. Agent的大脑与手脚意图识别之外工具调用如何设计4.1 为什么Agent不能只靠会说话我们做的这个Agent按现在的行业话术说属于有工具调用能力Function Calling的智能体。也就是说它不只是理解工单文本然后输出一段结论而是要真正去操作业务系统——查历史工单、查用户资料、查设备状态甚至在安全可控的范围内修改工单字段。这就牵扯到一个基础架构问题Agent的大脑和手脚怎么分工。我们的架构分三层编排层Orchestration由一个大模型作为调度员负责理解工单的全局意图并决定调用哪个工具、以什么参数调用、什么时候结束。工具层Tools一组封装好的API包括工单查询工具、用户信息查询工具、网络设备状态查询工具、历史同类工单检索工具、处置预案生成工具。执行层Runtime负责把工具返回的结果拼装成最终输出同时记录整个Agent的决策轨迹供审计和复盘。4.2 工具调用的全链路设计细节这里直接给一个工具调用的完整设计示例供大家参考。以下是一个简化版本的工具定义用JSON Schema描述输入输出这是目前Function Calling的主流做法{ type: function, function: { name: query_olt_status, description: 查询OLT设备PON口光功率、在线状态等信息, parameters: { type: object, properties: { olt_id: { type: string, description: OLT设备ID }, pon_port: { type: string, description: PON口编号可选 } }, required: [olt_id] } } }工具调用的决策逻辑我用伪代码来表示。整个流程的要点是Agent先判断这个问题需不需要查设备状态再决定调用哪个工具然后把工具返回的数据和工单文本一起作为下一轮推理的上下文。def agent_reasoning(work_order_text: str, tool_functions: list) - str: # 第一轮大模型分析工单判断是否需要工具调用 response llm.chat( messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: work_order_text} ], toolstool_functions ) # 如果模型返回工具调用指令 if response.tool_calls: for tool_call in response.tool_calls: result execute_tool(tool_call.name, tool_call.arguments) # 把工具结果追加到上下文进行第二轮推理 response llm.chat( messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: work_order_text}, {role: assistant, content: new_content}, {role: tool, content: json.dumps(result)} ] ) return response.text这里面有非常多的坑。最典型的是工具返回的数据太大。查一次OLT设备的详细信息返回JSON可能有几千个字段如果全量塞进大模型的上下文代价很高而且反而会干扰模型判断所谓大海捞针问题。我们的解法是在工具层做一次字段裁剪只返回对当前判断有意义的字段。比如工单提到光衰过大那就只返回光功率相关字段和端口状态其他历史性能数据一律不返回。另一个坑是工具调用的失败降级。查询工具偶尔会超时或者返回报错Agent必须学会优雅降级。我们设计了一个规则如果工具调用连续两次失败Agent停止重试改为直接输出建议人工核查设备状态并在回复中标注工具查询失败以下建议仅供参考。这个设计保证Agent面对系统异常时不会无限卡死而是把问题交给真正能解决的人。4.3 Agent的知识库内部知识库和实时检索的配合做电信工单Agent必须解决一个知识新鲜度问题。网络设备的型号更新、客服话术的调整、阶段性营销活动导致的热点故障类型这些都构成了时效性知识。如果Agent的知识只停留在微调模型的那批训练数据时间点一旦出现新的故障模式比如新型号光猫的兼容性问题Agent会直接抓瞎。我们最终采用RAG检索增强生成架构来解决知识更新问题。具体做法是把网管中心的故障处理手册、历史疑难工单的处理记录、厂商发布的设备公告等清洗后存入向量数据库Agent在分析工单时先对工单文本做向量化去知识库检索Top-K个相关片段检索结果作为上下文注入大模型推理过程再让大模型结合实时的工具查询数据给出最终判断。这里分享一个调优心得RAG的检索效果对文本切块粒度极其敏感。我们试过512字符一个块、256字符一个块、甚至按段落切块最后发现电信故障手册最适合按故障现象处理步骤这样的语义单元切块而不是机械地按字符数切。因为一段完整的处理指导只有在现象和步骤同时存在时才有意义切碎了以后检索到的内容往往是残缺的反而误导模型。5. 系统的工程落地与稳定性设计海量工单背后的架构博弈5.1 异步处理架构不要把Agent塞进同步链路先讲一个我们前期架构设计的血泪教训。项目第一版我们天真地把Agent的推理过程直接嵌在了工单系统的同步处理链路里——工单一进来调用AgentAgent推理完返回分类结果工单才继续走下一步流转。这相当于在关键链路上插了一个不确定延迟的节点。后果可想而知大模型偶尔一个请求就要好几秒高峰期工单一多直接把上层接入服务拖垮。后来我们改成了异步消息队列架构整体流程变成了工单创建后立刻进入一个待分拣的Redis队列独立的Agent Worker集群从队列里批量拉取工单逐条执行分类和预案生成处理结果通过消息通知回写工单系统触发状态机流转。这样一来Agent的延迟不再阻塞工单入库工单先按默认规则进入队列排队Agent处理完以后再更新状态。从用户的体感上工单进入系统这个动作是瞬间完成的后续的分拣和派单在后台悄悄进行。我们用Kafka作为消息中间件Agent Worker支持水平扩容高峰期可以临时拉起来几十个Worker实例分担流量。5.2 重试与幂等Agent调用失败不能搞出脏数据涉及到Agent调用的稳定性有两个词必须刻在脑门上重试和幂等。重试机制不用多说大模型接口偶尔超时是家常便饭重试策略我们用的是指数退避 抖动第一次失败等2秒第二次等4秒第三次等8秒最多重试5次。这里要特别强调加随机抖动的重要性——不加抖动的重试在并发高峰时会形成重试惊群同一批失败的请求约好了似的在同一时刻集体重发直接把上游服务再打挂一次。幂等设计这个坑更隐蔽。假设一个Worker从Kafka里拉了一条工单刚处理完还没来得及回写状态进程突然重启了——重启后Kafka重放消息这条工单会被Agent再处理一遍。如果Agent的处理动作是纯读取性的那没事但一旦Agent会调用更新工单状态这类写操作重复处理就会导致状态错乱、甚至生成两份互相矛盾的预案。我们的解法是在每个工单上加一个全局唯一的处理批次号Agent的每次处理动作都携带这个批次号写操作强制做乐观锁校验——批次号变了就拒绝写入并提示该工单已被其他实例处理。5.3 灰度上线与AB实验Agent说的每句话都要有人背书最后聊一聊上线策略。我们这套Agent系统在推向全省之前做了整整两个月的灰度运营。灰度分三层递进影子模式Agent的所有判断结果只写入日志不实际影响工单流转。我们拿影子模式下Agent的预测结果去跟线上人工处理结果做对比统计了一大批数据来评估准确率和召回率。建议模式Agent的判断结果作为推荐展示给工单处理人员由人来决定接受还是拒绝。这个阶段Agent开始接触真实业务流程但决策权还在人手里。自动模式Agent的判断结果直接生效但保留人工申诉通道——如果处理人对Agent的判断有异议可以一键回退并填写原因回退数据自动回流到训练集。每一步都跑了至少两周看数据稳定了再进下一步。这个渐进式路径的价值在于每一步产生的反馈数据都是下一阶段的训练燃料同时业务部门对Agent的信任度是逐步建立起来的。到自动模式全量开放时一线运维人员对Agent的抗性已经很小了因为他们亲眼看着这个系统从提建议到做决定的过程中间几乎每个决策样本都有据可查。6. 选型逻辑复盘为什么不选标准答案选了一条中间路线6.1 自研还是外购我们算了一笔账项目筹备期最激烈的争论是市面上有没有成熟产品可以直接买当时有几家厂商的智能工单产品来演示过功能看起来都挺全从工单分类、智能派单到知识库都有。但最终我们决定自研核心原因是系统集成深度的不可控。电信运营商的工单系统不是一套孤立系统它上游连着CRM客户关系管理、网络告警监控平台下游连着资源管理系统、综调系统、短信网关。市售智能工单产品大多是标准接口它们可以接入你系统里的工单数据但很难做到跟你的内部系统“双向实时交互”——查一下这台光猫最近的在线状态、看这个用户是否在某个营销活动名单里、查历史投诉记录并自动关联。这些深度集成需求外购产品要么做不到要么定制开发的成本堪比自研。但是要说实话自研的代价也很高。核心模型训练、工具层开发、稳定性保障每一项都需要一个完整的技术团队。我们团队规模不大前后端加起来十二个人走得比较累。我的建议是如果你们的业务复杂度低、工单量不大比如日均几千单直接买成熟产品可能更划算一旦工单量上万、业务流程复杂、内部系统交互频繁自研的长期价值更大。6.2 模型选型的真实考量准确率之外的三把尺子模型选型那场会开了整整三天最后我用三把非准确率尺子说服了团队第一把尺子推理成本。每天几万条工单每个推理请求都意味着真金白银。大模型单次推理的成本是ALBERT模型的几十倍如果准确率只提升三四个点根本覆盖不了成本差。第二把尺子延迟可预测性。大模型的输出长度不固定推理延迟有抖动。对于需要稳定SLA的工单系统来说这种不可预测性是致命的。轻量模型规则的路径P99延迟可以稳稳压在两秒以内。第三把尺子可解释性。我自己对AI的信任阈值是模型可以犯错但不能说不清楚为什么犯错。规则引擎可以告诉你分了什么类、依据是什么关键词ALBERT模型可以提供注意力权重告诉你主要看了哪些词大模型虽然能跑通但它给出分类结果的解释往往是事后合理化这在审计视角下不够扎实。三把尺子量下来层级递进的方案是最优解。这个结论放到今天的大模型浪潮下依然成立——Agent不是越大越好的关键是在系统里找到它最合适的位置然后围绕这个位置做好配套。就像一支球队中锋再强也踢不了门将的位置你需要的是每个位置都有人站岗而且整体阵型不散。7. 写在最后Agent系统不是模型项目而是组织项目项目上线到现在我对这类系统有了一个比较深的体会它表面上是技术项目实际上是一个组织项目。最大的阻力从来不是模型准确率不够而是流程规则本身在变化。运营商的业务流程几乎每月都在变新开了一个业务线、调整了一次服务等级协议、上线了新的营销活动全都要求Agent的知识库和规则引擎同步调整。这意味着系统必须有一套高效的运营维护机制而不是做完一次就一劳永逸。我们专门设了一个规则运营岗由业务经验最丰富的一位老专家负责每周跟算法团队开一次会把业务侧的变化转译成规则更新和标注样本。这个岗位有多重要呢有一次某地区上线了新的云电脑业务工单分类里根本还没有这个类别第一周相关工单全被规则引擎误判成宽带故障。老专家发现后迅速在关键词库里补充了云电脑云终端软终端等一批词并紧急标注了两百条样本给模型做增量训练三天内这个问题就解决了。如果这个岗位缺位误判工单至少会持续两三周用户投诉早就爆了。最后再分享一个我个人的经验给业务方演示Agent系统时不要一上来就展示AI自动处理工单有多快而是先展示AI处理不明白的工单如何交还给人工。信任这种东西是靠兜底能力建立的不是靠智能化水平建立的。你能让业务方放心地把后背交给系统这个系统才真正算站住了。