# 大模型网优开打：数字员工上岗记 ## 概述 2025年12月，GSMA Foundry收录了中国移动与中兴通讯联合打造的“数字员工”案例：一个由知识图谱、图神经网络和大模型驱动的中央AI协调器，在多省现网、数万元网元规模上，把故障平均定位时长从15分钟压到约3分钟，根因识别准确率超过90%。十个月后，2026年8月24日，Verizon与谷歌云宣布把Gemini Enterprise全家桶铺进客户服务与网络运营，剑指L4自智网络，宣称运维成本最高可省35%。一个自研数字员工，一个采购超大规模云厂商AI栈——中美运营商给出了大模型进网管的两条路线。本文用公开数据拆解这两条路各自走到了哪一步，以及哪些数字容易被误读。 --- ## 一、先说清楚：这个“数字员工”到底是个啥 干了十几年核心网运维的人，对网管系统的第一印象大概率是：告警靠刷屏，定位靠经验，闭环靠人扛。凌晨两点一波告警风暴砸下来，先做告警压缩和关联，再翻KQI/KPI曲线，查信令跟踪，必要时拉上无线、传输、IT几个专业的同事开电话会——一次故障定位耗掉半小时是常态，跨厂家、跨专业的问题拖几小时也不稀奇。 中国移动和中兴在GSMA Foundry发布的这份案例（2025年12月18日上线），针对的就是这个环节。按照官方描述，这个“数字员工”的架构分三层： - **感知层**：实时吞进告警、日志、性能数据和客户投诉工单——注意最后一样，投诉数据进根因分析，这是传统网管普遍缺失的一环。用户打10086说“刷视频卡”，和网元的KPI劣化在同一个模型里做关联，这恰恰是大模型最擅长的非结构化数据处理活儿。 - **认知层**：知识图谱负责存“故障传播路径”这类专家知识，图神经网络（GNN）在拓扑上做推理——告警在网元拓扑上的传播天然是图结构问题，GNN比普通机器学习模型更对味；大模型负责把上面这些东西串起来，输出人话版的诊断结论。 - **执行层**：一个中央AI协调器（coordinator）调度多个专科agent，分别负责故障诊断、工单排序、性能优化，覆盖多厂家、跨域环境。诊断之后给出临时措施或永久修复建议，排序依据是业务影响、KPI和SLA，而不是简单的告警级别。 用一句话概括：**它不是又一个“智能告警压缩工具”，而是试图用多智能体架构替代一个初级网优工程师的完整判断链条**。这也是为什么GSMA把它归类为"Coordinating Agentic AI"——多智能体协同，而不是单点AI能力。 ```mermaid flowchart TB subgraph L[感知层：多源数据接入] A1[网元告警] A2[日志] A3[KPI/KQI性能数据] A4[客户投诉工单] end subgraph C[认知层：三件套] B1[知识图谱
故障传播路径] B2[图神经网络GNN
拓扑推理] B3[大模型LLM
诊断结论生成] end subgraph E[执行层：多智能体协同] D0[中央AI协调器] D1[故障诊断agent] D2[工单排序agent] D3[性能优化agent] end A1 & A2 & A3 & A4 --> B1 & B2 B1 & B2 --> B3 B3 --> D0 D0 --> D1 & D2 & D3 D1 --> R1[输出根因+修复建议
临时措施/永久方案] D2 --> R2[按SLA与业务影响排序] D3 --> R3[参数与性能优化建议] R1 --> H[人工审核/闭环确认] H -.经验回流.-> B1 ``` ## 二、实测数据：哪些硬，哪些容易被误读 案例研究给出了多省现网试点（数万元网元规模）的一组数据，我按工程师的习惯逐条过一遍： | 指标 | 数值 | 工程师视角的解读 | |---|---|---| | 根因识别准确率 | >90% | 十次里对九次，剩下10%误判必须有人兜底——这决定了“全自动闭环”短期不现实 | | 平均故障定位时长（MTTD） | 15分钟 → 约3分钟 | 压缩80%，是全组数据里最实的一个；说明AI吃掉的是“查告警、翻日志、对拓扑”这段最耗人力的活 | | 平均修复时长（MTTR） | 最多下降11% | 只有11%！修复环节（换板、割接、参数回退）依然靠人，AI只帮忙“找准病灶”，没替你“动刀” | | 上站维护次数 | 减少5% | 降幅有限，说明远程处理率提升是渐进的，不是革命性的 | | 持续升级部署流程自动化率 | 最高95% | 注意限定语：这是“升级/部署流水线”的自动化率，不是全网运维自动化率，别混着引用 | | 覆盖规模 | 多省试点、数万元网元 | 已过POC阶段，是现网规模验证，不是实验室数据 | 这组数字里最有信息量的，恰恰是那个“不好看”的：**MTTD降80%，MTTR只降11%**。两条曲线一对比就明白——大模型目前在“定位”环节是真有效率红利，在“修复”环节基本帮不上忙，因为修复涉及物理操作、变更审批窗口和风险责任，这些短期内不会交给AI。这组数字的诚实程度，反而比某些“端到端闭环率99%”的宣传更可信。 第二个值得咀嚼的是“95%自动化率”。做过割接的人都知道，版本升级恰恰是最适合自动化的场景：流程固定、可灰度、可回退，本质上是流水线作业。把它自动化到95%符合工程直觉，但把这个词单独拎出来宣传成“运维自动化率95%”，就是另一回事了。 按官方口径，该方案计划2027年在中国全国范围部署。从“多省试点”到“全国推广”，中间要跨过的不只是技术关，还有各省公司流程、考核体系的适配——这在任何国家的运营商里都是硬骨头。 ## 三、另一条路：Verizon把网管交给谷歌 大洋彼岸的打法完全不同。2026年8月24日，谷歌云与Verizon宣布战略合作，把谷歌全栈AI——数据基础设施加Gemini Enterprise——铺进Verizon的客户体验、网络运营、营销、安全和员工办公全场景。这不是初次牵手：据Mobile World Live报道，今年7月VerizonCEO刚为一笔10亿美元级的谷歌合作站台，8月这次是把既有合作升级为企业级全面部署。 几个关键点： **客服侧已经跑出真实数据。** Verizon此前基于谷歌云联络中心技术的系统，已升级为Gemini Enterprise for Customer Experience，官方口径是“每月承接了Verizon绝大部分消费级呼入电话和在线聊天”，并宣称客户满意度和自动解决率都有可量化的提升。据谷歌云新闻稿，这套系统面对的是约2.8万名客服代表的整体转型——AI不是替代客服，而是作为每个客服的副驾落地。Verizon 2024、2025连续两年净利承压，把客户体验留存列为优先事项，这是它砸钱AI的商业逻辑。 **网络侧的核心武器是“时间数字孪生”。** 在今年6月的DTW Ignite大会上，Verizon和谷歌云亮出了号称业界第一个live network的temporal digital twin——一个实时演进的数字孪生模型，目标是“在客户感知之前预测、发现并解决问题”。注意"temporal"这个词：传统数字孪生是静态快照+参数仿真，时间孪生强调的是随时间演化的状态序列，才能做预测。这个方向指向L4自智网络运营，官方给的预期是**运维成本最高节省35%**。 | 维度 | 中国移动+中兴：数字员工 | Verizon+谷歌云：Gemini Enterprise | |---|---|---| | 路线 | 运营商主导自研，设备商深度绑定 | 购买超大规模云厂商全栈AI | | 技术底座 | 知识图谱+GNN+自研大模型（九天） | Gemini大模型+Agentic Data Cloud | | 数据策略 | 网管域内数据为主，投诉数据打通 | 多年数据湖整合，先消灭数据孤岛再上AI | | 已验证效果 | 根因准确率>90%，MTTD 15→3分钟（现网） | 客服AI承接大部分月度呼入（现网）；网络侧35%节支为**预期值** | | 网络侧抓手 | 故障诊断/工单/优化多智能体 | 时间数字孪生 → L4自智网络 | | 商业动机 | 降本+自智网络标准话语权 | 财务承压下的体验留存+降本 | | 关键风险 | 出省出海的规模化、流程适配 | 供应商锁定、数据主权、预期值兑现 | 两条路线的本质差异在**“谁拥有运维知识资产”**。中国移动的九天大模型体系是十余年自研积累的产物——2023年10月发布、国资委口径的“首个央企全可控基座大模型”，2025年7月干脆成立了实体公司九天人工智能科技有限公司，今年2月还把基于九天·九智平台的JoinAI-Agent开源到了GitHub。故障传播路径、专家经验、历史工单，这些知识沉淀在自家知识图谱里，换设备商不换大脑。而Verizon选择把这一层交给谷歌，换来的是更快的部署速度和更强的通用模型能力，代价是运维智能与云厂商深度绑定——网管系统历来是运营商最敏感的域，这个决定不轻松。 ## 四、冷思考：demo与生产网络之间的鸿沟 Mobile World Live今年8月26日有一篇行业综述，标题起得很直白：《在电信落地智能体AI，到底需要什么》，开篇就说“在demo和生产网络之间，智能体AI不断迷失”，整个行业的讨论总是绕着潜力转，而不是证据。这篇文章虽然偏评论性质，但点出的矛盾真实存在： **其一，准确率的“最后一公里”成本极高。** 90%的根因准确率听着不错，但运维是典型的不对称领域——10%的误判如果发生在割接建议上，代价可能是二次故障。所以现实部署必然是“AI建议、人工确认”的半闭环，这又反过来限制了人力节省的上限。这也是MTTR只降11%的深层原因。 **其二，数据治理是前置条件，不是并行任务。** Verizon的做法反而更诚实：先花多年把遗留数据湖整合到统一数据底座，减少数据孤岛，然后才谈AI。国内同行的普遍痛点类似——告警命名不规范、性能counter口径跨厂家不一致、日志格式千奇百怪，这些脏活不干完，再好的模型也是在垃圾上训练。10月MWL另一篇合作特稿的标题把这事说透了：数据策展（data curation）才是网络运营智能化用AI的关键。 **其三，指标口径的营销化倾向值得警惕。** “自动化率95%”不等于运维自动化率，"35%节支”是预期值不是实绩，"MTTD 3分钟”不含修复时长。工程师读行业案例，要养成把每个百分比还原成“分母是什么、周期多长、现网还是试点”的习惯。 ## 五、给国内网优工程师的三点启示 1. **岗位价值正在从“定位”向“决策”迁移。** MTTD 15→3分钟意味着，靠翻告警、查KPI曲线吃饭的初级分析工作正在被规模化替代；而“要不要动这个参数、敢不敢批准这次割接”的判断和担责能力，短期无法被替代。往上走还是往平面走，现在就要想清楚。 2. **投诉数据是网优的金矿。** 数字员工案例里最有启发性的架构选择，是把客户投诉塞进根因分析。绝大部分省公司里，投诉工单和网络KPI分属两套系统两拨人，这个数据墙不拆，任何大模型都只能看到半个网络。 3. **学AI别从炼丹开始，从工程化开始。** 九天体系开源的JoinAI-Agent、各设备商的智能体编排框架，值得花时间研究的是它们的“感知—规划—执行—协同”闭环设计，以及如何把专家知识（知识图谱）喂给模型——这比调参更接近未来网优岗的真实技能需求。 大模型进网管这件事，已经从PPT阶段进入了“报实数”阶段：中国移动报出了现网定位时长，Verizon报出了客服呼入承接量。但修复环节依旧靠人、网络侧节支依旧停留在预期——2027年“数字员工”全国部署的大考，才算真正的分水岭。 --- ## 参考来源 1. [Coordinating Agentic AI for Autonomous Networks – China Mobile & ZTE（GSMA Foundry，2025-12-18）](https://www.gsma.com/get-involved/gsma-foundry/gsma_resources/coordinating-agentic-ai-for-autonomous-networks-zte/) — 数字员工架构与现网实测数据（根因准确率、MTTD/MTTR、自动化率）的主要出处 2. [Verizon taps Google Cloud for enterprise-wide AI push（Mobile World Live，2026-08-24）](https://www.mobileworldlive.com/ai-cloud/verizon-taps-google-cloud-for-enterprise-wide-ai-push/) — Verizon与谷歌云合作范围、客服AI承接量、时间数字孪生与35%节支预期 3. [Google Cloud Announces Strategic Partnership with Verizon to Scale Enterprise AI（Google Cloud官方新闻稿，2026-08-24）](https://www.googlecloudpresscorner.com/2026-08-24-Google-Cloud-Announces-Strategic-Partnership-with-Verizon-to-Scale-Enterprise-AI) — 合作官方口径与2.8万名客服代表数据 4. [移动“九天”人工智能大模型相关报道（国资委英文站，2024-12-30）](https://en.sasac.gov.cn/2024/12/30/c_18553.htm) — 九天作为首个央企全可控基座大模型的官方表述 5. [中国移动九天人工智能科技有限公司成立（China Daily，2025-07-30）](https://mobile.chinadaily.com.cn/cn/html5/2025-07/30/content_014_68892f21ed50ccabe151692d.htm) — 九天实体化公司与12年AI积累背景 6. [JoinAI-Agent（GitHub，opencmit仓库，2026-02开源）](https://github.com/opencmit/JoinAI-Agent) — 中国移动九天·九智平台开源的通用智能体 7. [Verizon cozies up to Google Cloud even more with Gemini integration（Fierce Network，2026-08-24）](https://www.fierce-network.com/wireless/verizon-cozies-google-cloud-even-more-gemini-integration) — 合作三大支柱的第三方视角 --- > 本文由「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 等场景全覆盖。