一位小企业主正在用5G直播她的新品发布会，台下数万观众在线。此刻，几十公里外的Telstra数据中心里，一台承载着她移动流量云原生网元（CNF）的服务器，电源模块突然开始劣化。换作两年前，这台服务器的呻吟会很快演变成一场事故——直播卡顿、观众流失、投诉涌入，而运维工程师正手忙脚乱地在告警海里翻找根因。
但在2026年2月的巴塞罗那移动世界大会（MWC 2026）现场，Telstra把这场"灾难"演成了一出无声剧：硬件劣化的瞬间，AI智能体就捕捉到异常，自主判断上下文，几分钟后把流量整建制迁移到健康节点。直播只闪了一下，观众甚至没察觉——一台关键基础设施刚刚在实时中被"自动驾驶"地替换掉了。
这不是又一篇"AIOps降伏告警"的同质化故事。它的真正看点在于：Telstra没有把自己绑死在任何一家厂商身上，而是用"知识图谱底座 + 大模型决策层 + 确定性执行层"的三段式解耦架构，在多厂商telco cloud里跑通了基础设施级的自愈闭环。 这条路线，在中国运营商的案例库里几乎找不到对应物。
要理解Telstra为什么非走AI自愈这条路，得先看它背的那个巨无麻袋。
ADAPT（澳洲权威CIO调研机构）在2025年的一场CIO Edge演讲中，记录了Telstra网络与全球技术执行团队Channa Seneviratne和战略转型负责人Nathan Gumley披露的一组硬数字：Telstra每天要处理约1亿条网络事件（100 million network events daily）。1亿条是什么概念？相当于每秒钟都有上千条状态、告警、性能指标在涌入，而其中绝大多数是噪声——"区分哪些事件真正需要采取行动，本身就是一项极其复杂的工程"。
传统运维的瓶颈恰恰卡在"分诊（triage）"这一步。Red Hat官方博客对Telstra演示前的"旧世界"有这样的描述：当技术栈里某个关键组件宕掉，运维工程师往往要花上数小时做手工分诊，回答一连串问题——
工程师成了整个事故响应链路上的"必经瓶颈"。系统真正的极限不在硬件，而在"运维流程本身"——人成了critical path上最慢的一环。1亿条事件的洪流，靠人肉分诊根本顶不住。
这构成了Telstra自智网络（Telstra Autonomous Networks，TAN）战略最迫切的驱动力，也是其面向2030的"互联未来"（Connected Future 2030, CF30）蓝图里最硬的那块骨头。
Telstra最值得拆解的，不是某个炫酷的大模型，而是它把"懂网络的知识"、"会推理的大脑"和"敢动手的双手"彻底拆开的架构哲学。
很多人只看到MWC 2026那台会迁移流量的AI，却不知道Telstra真正下重注的，是更早一步的"知识底座"。2024年，Telstra凭借Knowledge Plane（知识面）创新拿下TM Forum卓越奖（Excellence Award），这是理解其自愈能力的根。
Telstra首席架构师Mark Sanders点破了传统自动化的死穴："以前，要自动化网络的某个部分，人们就写自动化脚本，你必须穷举每一种可能发生的用例。"容量管理、能耗优化、故障规避……全得硬编码进脚本。这条路在L4/L5自智网络面前注定走不通——场景组合是天文数字，脚本永远写不完。
Telstra的解法是"根本性不同"：把"网络域是什么、资源如何运作"这类工程师知识，前置编码进知识图谱（knowledge graph）。为此，Telstra不得不从零造一个电信专用本体（telco-specific ontology）——因为业界根本不存在现成的，他们只能基于TM Forum的信息框架（Information Framework / SID）自己拼。再配上一个领域专用语言（DSL）用来和知识图谱对话，以及一个网络差分引擎（Network Differencing Engine）——它持续比较"当前服务状态"与"期望结果"，把意图翻译成精确动作。
Telstra首席工程师Matt Beanland（差分引擎的发明者）用拉力赛打了个精妙的比方：差分引擎是"导航员"，根据你的目标、策略和经验给出逐弯指令；简化后的编排器是"驾驶员"，负责执行指令并反馈效果。 二者组成一支高性能车队。
这一层让网络"懂得自己"，是后续AI能做对决策的前提。它的业务回报也实实在在：服务创建与上线时间从12-18个月压缩到3个月，订单处理时间减少30%，NPS（净推荐值）提升。
到了2025-2026的MWC演示，Telstra在知识底座之上，叠上了真正会"推理"的大脑——Red Hat OpenShift AI驱动的AI智能体（AI agent）。
这个智能体的厉害之处不在模型本身，而在它的"触手"。它通过MCP（Model Context Protocol，模型上下文协议）服务器，能够即时与第三方管理平台以及Telstra自家的Knowledge DB（知识库）通信。换句话说，它不是个只会背书的书呆子，而是个能"翻柜子查档案、打电话问同事"的行动派——它能调取知识图谱里沉淀的网络拓扑、历史故障、运维Runbook，再结合实时遥测，推理出"现在这个异常，最该用哪一招"。
Dell的官方博客补充了一个关键细节：Dell Telecom Infrastructure Automation Suite（DTIAS，电信基础设施自动化套件）负责提供基础设施遥测，并把自动化能力和agentic AI通过MCP和自然语言集成进来，还提供了一个对话式界面，让SRE（站点可靠性工程师）能在需要时介入，和AI智能体一起做更深的分析和"次优行动（next-best-action）"决策。这构成了"人机协同"的缓冲带。
决策再聪明，最后敢不敢让机器动手，才是电信级自愈的生死线。Telstra把这"最后一公里"交给了Red Hat Ansible Automation Platform：AI智能体一旦确定行动方案，就自动触发Ansible，把纠正动作确定性地施加到应用上。
为什么强调"确定性"？因为大模型会幻觉，电信网不能赌。Ansible用Policy as Code（策略即代码，PaC）、RBAC（基于角色的访问控制）和完整的审计追踪（audit trail）兜底，确保每一个纠正动作都"经过授权、保持一致、且完全可追溯"。这把"AI动手"的风险锁进了一个可审计、可回滚的笼子里。
整套架构用Red Hat自己的话总结就是三句话：OpenShift做应用平台、OpenShift AI做智能层、Ansible Automation Platform做可信执行引擎。 多厂商伙伴Dell提供AI-ready基础设施和DTIAS编排底座，Cisco则作为多厂商网络管理的一极。Telstra把它纳入自家的TRAM（Telstra Reference Architecture Model，参考架构模型），对齐TM Forum的ODA（开放数字架构）。
Telstra很清醒地把这条路分成两步走，这也是它比许多"一步到位"宣传更可信的地方：
flowchart TB
subgraph Layer0["知识底座 (2024·Knowledge Plane)"]
KG["知识图谱 + 电信本体<br/>(基于TMF SID)"]
DFE["网络差分引擎<br/>(导航员: 当前 vs 期望)"]
DSL["领域专用语言 DSL"]
end
subgraph Layer1["智能层 (大脑)"]
AGENT["OpenShift AI 智能体<br/>异常检测 + 推理决策"]
MCP["MCP Servers<br/>跨平台互联"]
KDB["Knowledge DB<br/>知识库/Runbook"]
end
subgraph Layer2["执行层 (双手)"]
ANS["Ansible Automation Platform<br/>确定性执行"]
PAC["Policy as Code / RBAC / 审计"]
end
subgraph Infra["多厂商基础设施层"]
DELL["Dell AI-ready + DTIAS<br/>遥测/编排"]
CISCO["Cisco 网络管理"]
CNF["OpenShift 上的<br/>云原生网元 CNF"]
end
TELE["实时遥测<br/>(1亿事件/天)"]
TELE --> AGENT
KG --> DFE --> KDB
KDB <-->|MCP| AGENT
DELL -.提供遥测.-> AGENT
AGENT -->|推理选定方案| ANS
ANS --> PAC
PAC -->|授权后执行| CNF
CNF -->|工作负载迁移| CNF2["健康节点 CNF"]
AGENT -.对话式介入.-> SRE["SRE 人机协同"]
style Layer0 fill:#e8f5e9
style Layer1 fill:#e3f2fd
style Layer2 fill:#fff3e0
回到开头那位直播的小企业主。MWC 2026现场演示的，正是这样一个生产级telco cloud里的真实剧本：
核心效果数据汇总如下：
| 指标维度 | 传统人工运维 | Telstra AI自愈架构 | 改善幅度 |
|---|---|---|---|
| 故障平均修复时间 MTTR | 数小时（手工分诊） | 分钟级（自主闭环） | 小时→分钟量级跃迁 |
| 网络事件处理规模 | 人工难以筛选 | 每天约1亿条事件实时处理 | 处理能力质的突破 |
| 服务创建与上线周期 | 12–18个月 | 3个月（Knowledge Plane） | 缩短约75%–83% |
| 订单处理时间 | 基线 | 减少30% | -30% |
| 终端用户故障感知 | 明显中断/投诉 | 几乎无感知 | 体验显著提升 |
| 客户净推荐值 NPS | 基线 | 提升 | 正向增长 |
如果说这篇文章只讲风光，那它就沦为了又一篇软文。Telstra的可贵，恰恰在于它没有把PoC吹成全面商用。
ADAPT的记录里，Telstra高管亲口承认：这套自愈能力"仍在进行中（work in progress）"，仍需人工监督，完全闭环自动化尚未实现。这反映了一个残酷的行业现实——88%的领导者强调AI决策必须有人工校验。MWC 2026演示的是概念验证（proof-of-concept），在真实生产环境里大规模铺开，至少还横亘着三道坎：
把镜头拉回国内，Telstra这套打法至少有三点值得通信运维圈咀嚼：
第一，"决策层与执行层解耦"应当成为标配。 国内不少AIOps仍把"分析"和"执行"耦合在一个平台里。Telstra用大模型做决策、用Ansible做确定性执行、用PaC/RBAC/审计做兜底的三段式，本质是把"聪明但不稳"的AI和"死板但可靠"的自动化各自的优点接到了一起——值得在核心网、数通、承载网的自愈设计里借鉴。
第二，知识图谱是被低估的底座。 当所有人都在卷大模型参数时，Telstra把重注押在"把网络知识编码进图谱"上，并基于TM Forum标准自建电信本体。没有高质量的知识底座，大模型再多参数也只能在电信网里"瞎猜"。国内自智网络走向L4/L5，知识图谱与数字孪生的投入可能比模型本身更决定成败。
第三，MCP正在成为AI自愈的"标准化神经"。 Telstra用MCP让AI智能体跨厂商、跨系统调用知识库和工具。这意味着AI自愈正从"各自为战的私有方案"走向"基于开放协议的生态"。谁先在MCP/开放API层面占位，谁就掌握了自智网络互联的主动权。
Telstra的故事最动人的一点，不是它已经把网络做到了完全自治——它坦承还没有。而是它用一套开放、解耦、可审计、可演进的架构，把"让网络自己给自己治病"这件事，从实验室口号变成了生产环境里看得见、摸得着、可复制的工程路径。 那位直播的小企业主或许永远不会知道，她的新品发布会之所以没翻车，是因为大洋彼岸的一个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 等场景全覆盖。