<!-- title: 爱立信Agentic rApp让RAN自愈闭环 -->

当5G-Advanced网络的参数维度从4G时代的几百个膨胀到上万个，当一张商用RAN里同时跑着数万个小区、每分钟产生数百万条性能与告警数据，传统"人工巡检+工单派发+专家定位"的运维范式已经彻底失灵。GSMA的统计曾给出一个刺眼的数字：全球5G核心网与无线网故障的平均修复时间（MTTR）仍高达4.2小时，运营商每年因此损失超20亿美元收入。而在无线接入侧，问题更为隐蔽——配置漂移、邻区漏配、链路自适应失准这些"软故障"不会触发红色告警，却像慢性病一样持续蚕食着频谱效率与用户体验，传统手段几乎无能为力。

正是在这个背景下，爱立信（Ericsson）走了一条与"堆砌独立AI模型"截然不同的路：它没有把AI做成一个黑盒大脑，而是基于O-RAN架构，把AI能力拆解成一个个可组合、可上架、可即取即用的**rApp（RAN自动化应用）**，并通过智能自动化平台（EIAP, Ericsson Intelligent Automation Platform）实现闭环编排。2025年6月，爱立信认知网络解决方案（Cognitive Network Solutions）与AWS宣布合作，把这套体系升级为**Agentic rApp as a Service（智能体rApp即服务）**——rApp不再只是被动执行预设规则的脚本，而是具备感知-推理-决策-执行能力的智能体（Agent），可在Amazon Bedrock大模型底座上自主完成RAN劣化的发现与自愈。这条路径的终极目标，是TM Forum定义的**自主网络L5（全自治）**。

## 一、案例背景：RAN运维为何需要"自愈智能体"

理解这套方案，先要理解现代RAN运维的三个死结。

**第一，配置漂移的"温水煮青蛙"。** 一张大型商用网络里，工程割接、应急回退、版本升级会不断改写小区参数。时间一长，现网实际配置与设计基线之间的偏差越积越大——某个邻区关系被误删、某组功率参数被临时调高后忘了还原。这些漂移不会立即断服，却会让切换成功率悄悄下滑、干扰抬升。传统做法是定期人工导出配置做比对，周期以"月"计，等发现时劣化已成既定事实。

**第二，链路自适应的"静态规则失配"。** 5G-Advanced的MCS（调制编码策略）、波束权值、PRB分配需要随信道实时变化。传统链路自适应依赖厂家预设的固定查表规则，无法适应复杂多变的信道环境，尤其在高速移动、密集城区场景下，规则与实际信道严重脱节，导致下行吞吐量远低于理论值。

**第三，专家知识的"人肉搬运"。** RAN优化高度依赖资深网优工程师的经验，而这类人才稀缺。一个邻区漏配问题，从告警关联、路测分析、根因定位到参数修正，可能要耗费数小时人工。5G America等机构指出，运营商迫切需要把专家经验固化成可自动执行的rApp，并让第三方开发者也能参与进来，形成开放生态。

爱立信的解题思路是：**把"自愈"从一次性的人工动作，变成平台化、智能化、可即取即用的rApp流水线。**

## 二、方案详情：从EIAP到Agentic rApp as a Service

### 1. 三层架构：rApp如何变成"会思考的自愈单元"

爱立信这套方案的核心是O-RAN的rApp体系。rApp运行在O-RAN架构的**非实时RIC（Non-RT RIC）**之上，时间窗口大于10ms，负责策略级、优化级的决策，与负责毫秒级实时控制的Near-RT RIC协同。整个自愈闭环可分为三层：

- **感知层**：从网管、网元采集海量性能指标（PM）、配置数据（CM）、告警（FM）、路测与最小化路测（MDT）数据，构建网络实时画像。
- **认知决策层（Agentic核心）**：基于Amazon Bedrock的大模型能力，智能体rApp对多源数据进行关联分析，识别配置漂移、邻区异常、链路劣化等问题，自主生成修复策略，并评估爆炸半径与回滚预案。这是从"规则引擎"到"推理智能体"的关键跃迁。
- **执行编排层（EIAP）**：智能自动化平台负责把决策翻译成对网元的配置变更动作，执行后做效果验证，形成**感知-决策-执行-验证**的闭环自愈。

### 2. 智能体化的关键：rApp as a Service

2026年2月，爱立信正式发布**Agentic rApp as a Service（rApp aaS）**，把rApp以SaaS方式部署在AWS上。这意味着运营商不再需要为每个rApp单独部署算力与运行环境，而是像调用云服务一样即取即用。AWS官方博客披露，爱立信借助Amazon Bedrock的预置模型与基础设施，实现了rApp的**快速开发与部署（rapid development and deployment）**，显著缩短了从"专家经验"到"上线自愈"的周期。CSP（通信服务商）还可通过标准API把安全监控与SOC（安全运营中心）打通，实现运维与安全的协同闭环。

### 3. 开放生态：第三方与GenAI生成的rApp

这套体系的另一突破是**开放性**。2025年7月，AT&T联合爱立信宣布，首次将一个**第三方开发者**的rApp部署到现网生产环境，通过EIAP对真实网络发起配置变更——这是行业首次第三方rApp商用部署。同月，AT&T、Aira Technologies与爱立信更进一步，在AT&T测试环境中部署了**GenAI生成的rApp**，即由生成式AI自动编写代码生成的rApp，开创了"AI造AI运维应用"的先河。这标志着rApp生态从"厂家封闭提供"走向"开放市场+AI自动生成"。

下面这张图展示了爱立信Agentic rApp自愈闭环的架构与数据流：

```mermaid
flowchart TB
    subgraph 感知层
        A1[网元PM/CM/FM数据]
        A2[MDT路测数据]
        A3[告警与KPI流]
    end
    subgraph 认知决策层_Agentic核心
        B1[Amazon Bedrock 大模型底座]
        B2[智能体rApp<br/>配置一致性EACC]
        B3[智能体rApp<br/>链路自适应]
        B4[GenAI生成rApp]
        B1 --> B2 & B3 & B4
    end
    subgraph 执行编排层_EIAP
        C1[策略翻译与爆炸半径评估]
        C2[网元配置变更执行]
        C3[效果验证与回滚]
        C1 --> C2 --> C3
    end
    subgraph 网络层
        D1[Non-RT RIC]
        D2[O-RAN网元/基站]
    end
    A1 & A2 & A3 --> B1
    B2 & B3 & B4 --> C1
    C2 --> D1 --> D2
    C3 -.效果反馈.-> B1
    D2 -.实时数据.-> A1
    style B1 fill:#fff3cd
    style C3 fill:#d1ecf1
```

## 三、真实部署案例：三家运营商的差异化落地

爱立信这套rApp自愈体系并非纸上谈兵，已在多家头部运营商现网落地，且每家的切入点都不一样。

### 案例1：Telstra——EACC rApp搞定"配置漂移自愈"

2024年7月，澳大利亚电信（Telstra）与爱立信宣布完成一项**全球首次**：在商用现网上成功试验**EACC（Ericsson Automated Configuration Consistency，爱立信自动化配置一致性）rApp**。该rApp运行在爱立信智能自动化平台（EIAP）之上，自动扫描现网配置与设计基线之间的偏差，识别出漂移的小区参数并自动发起修正闭环。这是把"配置一致性自愈"从人工月度比对推向实时自动化的里程碑——以往需要专家逐小区核对的配置漂移，现在由rApp自动发现并修复，把RAN"慢性病"的处置周期从"月"级压缩到分钟级。

### 案例2：Bell Canada——AI原生链路自适应让吞吐量涨两成

2025年4月，加拿大贝尔（Bell Canada）与爱立信宣布完成**全球首次**AI原生链路自适应技术的现网field test。该技术在爱立信渥太华R&D中心研发，是爱立信5G-Advanced组合的一部分。Fierce Network的报道给出了硬数据：**实时AI将下行吞吐量提升最高20%、频谱效率提升10%**。这是Agentic思路在物理层链路自愈上的直接体现——AI不再依赖静态查表规则，而是根据实时信道状态自主调整MCS、波束等参数，把链路从"规则失配的劣化状态"实时自愈到最优工作点。Bell成为全球首个现网验证该技术的运营商。

### 案例3：AT&T——开放生态与GenAI生成rApp

2025年7月，AT&T通过爱立信EIAP部署了行业首个第三方rApp到现网生产网络，让第三方开发者编写的rApp首次能对真实商用网络发起配置变更。紧接着，AT&T联合Aira与爱立信，在测试环境部署了由生成式AI自动生成的rApp。AT&T的案例证明：rApp自愈生态可以打破厂家封闭，让更多场景（尤其是长尾、定制化场景）的自愈能力被快速生产出来。

## 四、效果数据：自愈能力的量化收益

下表汇总了爱立信Agentic rApp体系在上述部署中的关键效果数据：

| 运营商/场景 | rApp类型 | 自愈/优化维度 | 效果数据 | 数据来源 |
|---|---|---|---|---|
| Bell Canada（现网field test） | AI原生链路自适应 | 链路参数实时自愈 | 下行吞吐量+20%、频谱效率+10% | Fierce Network |
| Telstra（商用现网） | EACC配置一致性rApp | 配置漂移自动检测修复 | 处置周期从"月"级压至分钟级（全球首次） | Ericsson新闻稿 |
| AT&T（现网生产网络） | 第三方rApp | 开放生态自愈 | 行业首次第三方rApp现网配置变更 | AT&T/5G Americas |
| AT&T测试环境 | GenAI生成rApp | AI自动生成自愈应用 | 行业首次GenAI生成rApp部署 | Aira/Ericsson |
| 欧洲某运营商试点（据行业报道） | Agentic AI自愈 | 故障自愈效率 | 自愈效率提升约200% | 行业媒体报道 |
| 爱立信核心网切片（技术论文） | 策略自愈 | 切片故障策略迭代 | 迭代周期72h→4h、成功率95% | 爱立信技术论文 |

需要说明的是，"欧洲某运营商自愈效率提升200%"与"核心网切片策略迭代72h→4h"来自行业报道与爱立信技术论文的间接引用，具体口径应以厂商最终披露为准；而Bell Canada的20%/10%、Telstra与ATTT的"全球首次"则有明确的厂商新闻稿与权威媒体背书，是本文最硬的实证数据。

## 五、对比分析：Agentic rApp为何不同于传统方案

为了说清爱立信这条路的差异化价值，下面从六个维度对比"传统人工运维"、"传统规则型rApp（非智能体）"与"爱立信Agentic rApp aaS"：

| 对比维度 | 传统人工运维 | 传统规则型rApp | 爱立信Agentic rApp aaS |
|---|---|---|---|
| 决策方式 | 专家经验+人工判断 | 预设if-then规则 | 大模型推理+智能体自主决策 |
| 配置漂移处置 | 月度人工比对 | 周期性规则扫描 | EACC rApp自动发现并闭环修复 |
| 链路自适应 | 静态查表规则 | 规则优化 | AI原生实时自愈（Bell +20%吞吐） |
| 应用来源 | 厂家封闭 | 厂家封闭 | 开放生态+GenAI自动生成（AT&T） |
| 部署形态 | 本地脚本 | 平台内置 | AWS SaaS即取即用（rApp aaS） |
| 自治等级目标 | L1-L2 | L3 | L4-L5（自主网络） |

这张表揭示了一个关键判断：**真正的"自愈"不在于有没有AI，而在于AI能否闭环、能否开放、能否即取即用。** 传统规则型rApp虽然也自动化，但规则是死的，遇到规则未覆盖的新故障模式就束手无策；而Agentic rApp依托大模型推理，具备处理未见过场景的泛化能力，并能通过GenAI快速生成新的rApp来填补能力空白——这正是迈向L5全自治网络的核心逻辑。

与同业相比，爱立信的差异在于**"开放生态+云原生SaaS+智能体化"三位一体**。诺基亚的AVA偏向自上而下的闭环AI、强调投诉与体验驱动；华为的核心网大模型更聚焦网元级告警提效；而爱立信选择把自愈能力原子化为rApp，借O-RAN开放架构与AWS云底座，让运营商乃至第三方都能参与"造"自愈应用。这种"平台+生态"的打法，长尾覆盖能力更强，但落地复杂度也更高——需要运营商具备O-RAN架构与多云治理能力。

## 六、闭环的本质：从"修故障"到"防劣化"

回看整条路径，爱立信Agentic rApp体系对"自愈"的重定义值得通信行业深思。

传统AIOps的"自愈"往往被理解成"故障发生后自动修复"——先有红色告警，再有自动工单与脚本回滚。但爱立信的rApp实践指向一个更前沿的方向：**自愈的前沿不在"修"，而在"防劣化"**。EACC rApp在配置漂移尚未引发告警前就完成修复；AI原生链路自适应在吞吐量掉下来之前就把链路拉回最优工作点。这是一种"持续优化即自愈"的范式——网络不再等到病了才治，而是时刻保持在健康工作点上。

同时，AT&T的第三方rApp与GenAI生成rApp，把"自愈能力供给"本身也智能化了。过去一个新场景的自愈能力，要排厂家研发队列、走版本发布周期；如今GenAI可以根据运维需求自动生成rApp原型，第三方开发者也能上架——自愈能力的"上市时间"被大幅压缩。这与整个通信行业从"封闭网管"走向"开放编排"的大趋势同频共振。

当然，这条路并非没有挑战。Agentic rApp让AI自主对现网发起配置变更，**爆炸半径控制与可回滚性**成为生死攸关的工程命题——这正是EIAP中"策略翻译+爆炸半径评估+效果验证与回滚"那一层的价值所在。此外，大模型推理的时延与成本、第三方rApp的安全审查、跨厂商O-RAN互操作等，都是落地中真实存在的摩擦点。但从Telstra、Bell Canada到AT&T的连续突破看，这些工程难题正在被逐一攻克。

对运营商而言，爱立信这条路径的启示很直接：**RAN自愈的下一站，不是再买一个更大的AI模型，而是建一个能让智能体rApp持续生长、即取即用、开放共治的平台。** 当自愈能力从"厂家一次性交付"变成"生态持续供给"，网络离TM Forum定义的L5全自治，才算真正近了一步。

## 参考来源

1. [Bell Canada tests Ericsson's AI-native link adaptation tech](https://www.fierce-network.com/wireless/bell-canada-tests-ericssons-ai-native-link-adaptation-tech) — Fierce Network报道，给出Bell Canada现网field test硬数据：下行吞吐量+20%、频谱效率+10%，全球首次
2. [Agentic AI for RAN optimization: Pathway to autonomous network level 5](https://aws.amazon.com/blogs/industries/agentic-ai-for-ran-optimization-pathway-to-autonomous-network-level-5/) — AWS官方博客，详述Agentic AI驱动RAN优化迈向自主网络L5的路径与Amazon Bedrock底座
3. [Ericsson launches Agentic rApp as a Service on AWS](https://www.ericsson.com/en/press-releases/2026/2/ericsson-launches-agentic-rapp-as-a-service-on-aws-to-accelerate-autonomous-networks-transformation) — 爱立信官方新闻稿，2026年2月正式发布Agentic rApp as a Service
4. [AT&T Deploys First Third-Party rApp](https://about.att.com/story/2025/ericsson-third-party-rapp.html) — AT&T官方公告，行业首次第三方rApp部署到现网生产网络
5. [Telstra and Ericsson achieve world first with EACC rApp trial](https://www.ericsson.com/en/press-releases/7/2024/telstra-and-ericsson-achieve-world-first-with-a-successful-trial-of-the-ericsson-automated-configuration-consistency-eacc-rapp-on-a-live-commercial-network) — 爱立信官方新闻稿，Telstra全球首次商用现网EACC配置一致性rApp试验

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
