凌晨三点四十七分，一条汇聚层光缆被第三方施工挖断。十分钟后，网管大屏上挂出了四千多条告警。值班工程师盯着满屏的红色，要在其中回答一个问题：真正断的，到底是哪一根？
这不是虚构的极端案例，而是每一个维护过传输网、承载网、核心网的工程师都经历过的日常。一个物理故障会在几分钟内衍生出海量连锁告警，业界常说的“故障与告警放大效应”就来自这里——根因只有一处，告警却铺满全屏。而今天要聊的，是AI怎么接下这个夜班：从告警瘦身、根因推理，一直到大模型直接给出处置建议的完整闭环。这也是全球运营商“自智网络”（Autonomous Networks）演进路线里，最接近商用落地的一段。
先看一场典型的告警风暴是怎么炼成的。以一个省公司规模的承载网为例，公开报道中常见的原始告警量级是每天数万条，逢割接窗口和恶劣天气还会翻倍。这些告警里，真正的“根因告警”往往只占极小比例——大量是衍生告警：光缆断了，跑在上面的几十条业务通道同时报LOS，下游的端口、板卡、保护倒换状态跟着一起报警，再叠加网元之间心跳超时的次生告警。
放大链条通常是这样的：一处物理中断，直接触发上游设备的信号丢失；每一条经过该链路的业务路径各报一条；网管系统对每条业务再做阈值判断，又各派生若干条性能告警。三到四层放大之后，一个根因变成数千条告警，是行业里反复被验证的现象。
对值班工程师来说，痛点不在“看不过来”本身，而在三个更隐蔽的地方：
第一，跨网管的命名鸿沟。 同一根光缆，在传输网管里叫某个光路编号，在IP承载网管里是某个端口down，在.cmdb（配置管理数据库）里又是另一个资产编码。要把这四千条告警归并到同一个物理根因，得先跨系统对齐拓扑——这是所有告警治理项目真正的地基。
第二，告警的时序陷阱。 衍生告警的到达顺序受轮询周期、上送队列影响，未必和因果顺序一致。“谁先到”不等于“谁是因”，纯靠时间戳排序做归并，准确率的天花板很低。
第三，夜间人力断档。 告警风暴高发时段（割接窗口、雷雨夜）恰恰是值班人力最薄的时段。高级工程师不可能天天值夜班，而告警处置偏偏最吃经验。
这三条决定了：规则引擎能解决一部分问题，但解决不干净。这也是AI被寄予厚望的原因——不是替代人看告警，而是把“归并、定根因、出处置建议”这条链路自动化。
聊AI运维绕不开一个行业框架。TM Forum（全球电信管理论坛）在其自治网络（Autonomous Networks）项目里，把网络自治水平划分为L0到L5六个等级，这已经成为全球运营商评估AI运维进展的通用标尺（项目主页见文末参考来源[1]）。这一框架的推广与中国移动密切相关——据公开资料，中国移动2019年在业界率先提出“自智网络”构想，并推动分级理念进入TM Forum等行业组织，其公开路线图设定了“2023年整体达到L3、2025年在重点场景迈向L4”的目标。
六个等级的准确含义，工程师容易记混，列成表更清楚：
| 等级 | 名称 | 核心特征 | 人的角色 |
|---|---|---|---|
| L0 | 人工运行 | 无自动化，纯手工操作 | 全部决策与执行 |
| L1 | 工具辅助 | 单点脚本与工具，碎片化 | 人主导，工具辅助 |
| L2 | 部分自治 | 具备感知与执行能力，闭环规则预设 | 人做判断，系统执行 |
| L3 | 有条件自治 | 特定专业场景内AI闭环，关键决策人工确认 | 人监督，场景内自治 |
| L4 | 高度自治 | 跨场景跨专业闭环，人只定规则与例外 | 人定期审核例外 |
| L5 | 完全自治 | 全域自演进，无需人工干预 | 行业普遍视为愿景 |
两个容易被误读的点：一是L3的“自治”是有边界的——它发生在单个专业域（比如仅传输、仅无线）的单个场景（比如仅告警根因）内，出了场景就要交还人工；二是L4的关键不是“更聪明”，而是跨域协同——无线、传输、核心的AI各管一段不算L4，能把跨域告警串成一条因果链才是。目前全球头部运营商的公开口径普遍处于“整体L2.7到L3、重点场景冲击L4”的阶段（据TM Forum及各运营商公开发布的表述），L5在可预见的规划期内没有任何一家给出时间表。
回到那四千条告警。一套达到L3水平的AI告警治理系统，处理流程大致是一条流水线。标准允许多种实现，各厂商产品形态有差异，但功能分段高度趋同，华为iMaster NCE、诺基亚AVA、爱立信Service Automator、中兴uSmartNet等公开材料描述的架构都可以映射到这条流水线上（具体能力口径以各厂家官方文档为准）：
flowchart TD
A[网元与链路] --> B[告警采集网关]
B --> C[标准化与去重]
C --> D[关联归并引擎]
D --> E[告警风暴识别]
E --> F[根因推理AI]
F --> G{置信度判定}
G -->|高置信| H[自动处置动作]
G -->|中置信| I[生成建议工单]
G -->|低置信| J[人工值班席]
H --> K[处置结果校验]
I --> K
K -->|验证通过| L[闭环归档]
K -->|验证失败| J
L --> M[知识库回填]
M --> D
逐段拆开看，每一段都有讲究：
标准化与去重。 把不同网管、不同厂商网元的告警统一成标准模型（TM Forum的告警信息模型是常见基础）。这一段是最枯燥也最决定成败的——某省项目上线三个月效果不佳，最后排查发现是同一板卡在两套网管里的序列号写法不同，导致去重失效。AI救不了脏数据。
关联归并。 基于拓扑和时间窗，把衍生告警挂到疑似根因下面。传输网里这部分相对成熟，因为光路拓扑是静态可知的；无线网难得多，一个小区退服可能是馈线、电源、传输、板卡四类原因，拓扑线索弱。
根因推理。 这是AI真正的用武之地。主流做法是图推理+历史案例匹配：把告警、拓扑、工单历史建成图谱，用图算法定位因果链源头，再用历史处置记录校准置信度。华为、诺基亚等厂商在公开材料中普遍以“告警压缩率90%以上”作为这类产品的宣传口径——这是厂商营销数据，实际效果高度依赖现网数据质量，采购时务必要求POC实测而非只看PPT。
置信度门限与闭环。 这是L3与L2的分水岭：L2系统做完归并就停，人来做判断；L3系统对高置信事件直接触发预设动作（如端口倒换、板卡复位），中置信生成建议工单，低置信转人工。每次闭环的结果回填知识库，形成越用越准的正循环。
流水线解决的是“结构化告警”，但运维工作里还有大量非结构化知识：3GPP规范、设备手册、历史故障复盘、老师傅脑子里的经验。2023年以来，这一块被大语言模型（LLM）补上了。
一个标志性的学术工作是TelecomGPT。据arXiv:2307.09548论文（中国移动等机构研究者，2023年发布，见参考来源[2]），研究者以通用大模型为底座，用3GPP规范、电信教材、行业问答等语料做增量预训练与指令微调，构建了面向电信领域的模型框架和基准测试。论文报告其在电信专业问答、规范条文理解等任务上显著优于同规模的通用大模型——这一结论来自论文作者的自行评测，但它验证了一条路径：通用大模型不懂的“NAS层”、“邻区漏配”、“ANR”，垂直领域模型是可以补课的。
国内运营商的落地同样在推进。据中国移动公开发布，其“九天”人工智能大模型体系已把网络运维列为重点应用方向，典型场景包括智能告警分析、故障处置建议、运维知识问答等。国外方面，各大设备商也纷纷把LLM能力嵌入运维产品线，形态大多是“值班Copilot”：工程师用自然语言提问，系统基于规范、拓扑和历史工单生成处置方案与操作步骤，人确认后执行。
大模型在NOC里真正干得好的三件事，从各厂商公开演示中反复出现：
同样要泼一盆冷水：大模型不适合直接做闭环执行。它擅长的语言推理恰恰伴随幻觉风险，让LLM直接下发网元命令，等于让一个偶尔会一本正经胡说的人握住割接终端。目前行业的共识做法是LLM只出建议，执行由确定性脚本或人完成——这正是第五节方案对比里L3和L4的边界设计逻辑。
把三种典型值班模式放到一张表里，差异一目了然（基于TM Forum分级框架的工程化解读）：
| 维度 | 人工值守（L0-L1） | 场景自治（L3） | 跨域自治（L4） |
|---|---|---|---|
| 告警初筛 | 人肉刷屏 | 系统归并压缩90%以上（厂商口径） | 跨域关联后按业务影响排序 |
| 根因定位 | 老师傅经验+逐段排查 | 单域内AI图谱推理，分钟级 | 跨无线/传输/核心端到端推理 |
| 处置执行 | 人工登录网元操作 | 高置信场景自动执行+人工确认 | 例外上报，常规动作全自动 |
| 夜班人力 | 每席数人轮值 | 值班人力减半常见（各局数据差异大） | 向“日班审核制”演进 |
| 主要风险 | 依赖个人经验，人走经验走 | 误判闭环引发次生故障 | 规则错误被批量放大 |
| 适用阶段 | 小规模网络、过渡期 | 单专业域，当前主流商用形态 | 头部运营商试点中 |
表里“主要风险”一行值得多说一句。L3的误判闭环是真实发生过的事故类型：AI把一次短暂的瞬时抖动判定为“可自愈事件”自动复位，恰好赶上设备已知软件缺陷，复位触发级联故障。这就是为什么成熟的落地路径一定是灰度的——先只开放“读”类动作（查询、定位、出建议），再开放低风险“写”类动作（日志采集、性能复位），高风险动作（倒换、复位、割接）永远留人工确认。
跟一线做过的工程师聊，AI运维项目“上线容易、用好极难”，坎集中在三处：
第一道坎：数据质量。 前面提过CMDB脏数据的坑，再补一个更普遍的——告警文本不规范。同一类故障，不同批次设备上送的告警描述措辞各异，正则和模板难以穷举。这决定了告警治理项目60%以上的工作量其实在数据治理而非算法，预算和工期要按这个比例排。
第二道坎：信任建立。 值班工程师凭什么信AI说的根因？实践中的有效做法是“可解释性展示”：系统给出根因结论时，同时呈现因果链证据（哪几条告警、哪段拓扑、哪几个历史案例支撑了这个判断）。工程师可以像审同事的判断一样审它。凡是只给结论不给证据的系统，最终都会被一线绕开——这是无数AIOps项目烂尾的第一原因。
第三道坎：考核反噬。 告警压缩率是个危险的KPI。只考核压缩率，系统会学会把难归类的告警一压了之——压缩率很漂亮，漏掉的真故障也很致命。成熟的考核必须是成对指标：压缩率之外必须配漏报率（被压缩告警中事后被证实与故障相关的占比），有的局还加了根因命中率（TOP1根因命中真实原因的比例）。单一KPI驱动AI运维，跑偏只是时间问题。
岗位冲击是这个话题绕不开的一层。直说结论：告警压缩消灭的是“人肉刷屏”这类工作，但网络规模在涨、网元复杂度在涨，运维总盘子并没有缩小，变的是岗位技能结构。
正在出现的几类新角色：预案工程师——写和维护AI可执行的处置预案库，要求既懂网络又懂自动化编排；数据治理专员——维护CMDB和告警模型质量，从前没人愿干的脏活正在变成项目成败的手；AI稽核岗——抽查AI闭环案例、标注错判、校准置信度门限，相当于给AI配质检员。
技能迁移的路径也比较清晰：信令分析和故障定位的底层功力不会过时——AI给出根因建议，判断它对不对，依然需要懂协议的人。变化在于工具面：多学一门SQL和Python数据处理的性价比，已经明显高于多背一套网管快捷键。用一句一线的话概括：过去拼谁看告警快，以后拼谁把AI教得好。
回到凌晨三点四十七分那条被挖断的光缆。在L2的网络里，它意味着值班工程师的通宵；在L3的网络里，它是一条已经自动定位根因、预案待确认的工单；在L4的网络里，它可能只是第二天早上日报里的一行字——“夜间汇聚环光缆中断，系统已自动倒换，业务无感知，请安排抢修”。
行业今天真实的坐标是：L3在单域场景批量落地，L4在头部试点，大模型负责补上“读懂规范、说清人话”的最后一环。对工程师而言，这不是“AI抢不抢饭碗”的问题，而是“下一个夜班，你想刷四千条告警，还是审一条AI给出的因果链”。答案不言自明。
（注：文中厂商产品能力数字多为厂商公开宣传口径，实际效果因现网数据质量差异较大；中国移动自智网络路线图与“九天”大模型信息来自其公开发布，具体进展以其官方口径为准。）
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。