像 L4 自动驾驶一样，用 Agent 破局网络变更之痛

对网络工程师而言，「变更」这两个字天生带着重量。变更重点在于「变」字，网络有个朴素的规律：不动，就不坏。重大活动封网期间往往是故障最少的日子，这几乎是行业共识。但业务不会静止。从简单扩缩容到复杂架构改造，变更是网工无法回避的日常。

在百度集团内部，排除标准化预授权变更后，我们每年仍要完成超过 5000 次深夜变更，而且这个数字还在持续攀升。业务的边界在扩张，网络的复杂度在增长，变更的数量在激增——而人力，是有限的。一边是追求极致的稳定，另一边是不断攀升的工作量与风险。

今天我们想分享的，就是百度智能云如何用 AI 破局：让变更从「深夜的人工割接」走向「白天的智能自治」，让网络工程师从繁琐的操作中解放出来，回归更有价值的架构设计与规则定义。

1.    数字时代的网络变更之困

变更，始终是网络行业从业者的一大痛点。在追求极致稳定的天平另一端，是巨大的人力损耗与不可控的风险。无论是海外的各大厂商，还是国内的互联网大厂与运营商，都曾因一次细微的网络变更引发过「地震级」故障。

这些事故中，既有由于疏漏导致的低级错误，也有经过层层评审、专家把关后的方案在落地瞬间「翻车」。变更为什么这么难？除了显而易见的故障风险，行业还面临着哪些难以言说的痛点？

痛点一：网络不可知，精心设计的方案难逃「混沌定律」

在复杂的现网环境中，经验主义正在失效：

• 架构的「隐形地雷」：随着业务迭代，网络架构如同原始森林般错综复杂，任何一个被遗忘的配置角落，都可能埋藏着足以瘫痪全局的隐患；
• 蝴蝶效应：在高耦合的系统里，一次看似人畜无害的配置微调，都可能引发雪崩式的连锁反应；
• 设备「黑天鹅」：方案逻辑再完美，也无法预判设备底层的代码 Bug。这种随机发生的「降维打击」，往往让网工在变更现场猝不及防。

痛点二：效能瓶颈，深陷「人肉作战」的传统泥潭

• 激增的工作量：业务在高速发展，网络规模越来越大，保障底层的网络变更，却仍停留在依赖「人肉」的农耕时代；
• 深夜割接的「至暗时刻」：网络变更通常被严格限制在业务低峰的凌晨进行，凌晨 12 点到 6 点。那是一段生理机能最脆弱、精神高度紧绷、却容错率极低的真空期。
• 「孤岛式」变更的巨大压力：深夜的割接现场往往是孤立无援的。一旦变更偏离预设脚本，面对突如其来的断网报警，工程师必须在极短的时间窗口内做出正确决策。这种背负着业务生命线的心理重压，让「变更」二字成了许多网工挥之不去的 PTSD。

面对稳定性和人效的双重挑战，如果保持不变，我们终将被淹没在海量的变更和故障中，破局变更迫在眉睫。

2.    百度的智能网络变更的演进之路

在介绍智能变更的具体实现之前，不妨先思考一个问题：什么样的变更，才称得上「智能」？

是一套需要人工逐项填写的电子表单？是一键执行的自动化模板？还是只要说一句话，变更就自动完成？

这里可以用大家熟悉的自动驾驶来做类比。今天，自动驾驶已不再是科幻概念——一些新能源车已实现点到点的准 L3 级辅助驾驶，而在武汉、亦庄等地区，百度的 L4 级自动驾驶出租车萝卜快跑已经服务了超过 2000 万人次。你只需说「去黄鹤楼」，它就能载着你跨江而过，沿途你可以睡觉、听歌、打游戏，完全不必操心路况。

智能变更也可如此：网络工程师只需输入一句话——「下周四凌晨升级 TJZJ 的 LE 设备」或「下周五部署 SZTH 的 LILOU SERVER」——AI 便能自动完成建单、审核，深夜准时执行变更。而工程师本人，可以像乘客一样，回归正常的生活，不再需要熬过那些孤守屏幕的凌晨。

参照自动驾驶的分级标准，我们将网络变更的自动化水平划分为 L0 至 L5，每个等级的定义如下：

​编辑

在传统的变更流程中，一个完整的变更通常需要经历以下六个环节（相对简单的变更通常会简化 1-2 个步骤） ：

1. 需求分析与拆解： 工程师接到业务需求后，需要深入理解需求背景，拆解出对网络架构的具体影响，判断涉及哪些设备、哪些协议、哪些流量路径等；
2. 方案设计与脚本编写： 基于需求分析结果，人工梳理现网配置和拓扑依赖，设计详细的变更方案，包括操作顺序、配置命令、回退预案，并逐行编写执行脚本；
3. 多层评审与方案打磨： 方案需要经过组内评审、专家评审等多轮审核，论证方案可行性，排查潜在风险；
4. 变更窗口申请与协调： 由于变更必须在业务低峰的凌晨进行，工程师需要提前申请窗口，协调上下游业务方，等待审批通过，并做好各方通知准备；
5. 深夜人工执行与实时监控： 在生理最疲惫的后半夜，工程师登录设备执行脚本或通过 SDN 执行下发，同时紧盯屏幕，实时观察设备状态和业务监控指标，随时准备应对突发情况；
6. 结果验证与收尾关闭： 变更完成后，进行业务连通性测试、流量验证等操作，确认无误后清理现场，输出变更报告，关闭变更流程。

而智能变更只需三步：

1. 用户用自然语言提出需求；
2. 用户二次确认 AI 生成的变更单；
3. 用户白天确认结果。

中间的现网分析、参数获取、命令生成、风险通告、变更执行等所有环节，均由 AI 和自动化系统完成。人工只需要在需求提出、变更单复核和结果确认三个节点参与——毕竟，最终的责任还在人身上。就这样，一个完整的变更，完成了。

​

百度网络团队经过多年的发展与持续迭代，于 2022 年全面告别手工变更时代，2025 年正式迈入智能变更新阶段。上述智能变更能力的实现，依托于我们构建的三层网络变更技术架构：变更 Agent 层、网络平台层与 AI 基建层。

​

AI 基建层： 是整个体系的底层支撑，包括多维度的数据采集与交互能力：

• 数据采集：SNMP、Telemetry、Netstream 等；
• 监控探测：Pingmesh、TCP 拨测等；
• 设备交互：SDN 控制器、GNMI、Netconf 等协议通道；
• 物理网络底座：覆盖百度 DCN 数据中心网络、HPN 高性能网络、骨干网、公网、专线、边缘节点等全部网络场景。

网络平台层：是智能体获取数据、交互操作的自动化平台，也是变更能力的承载底座。其中变更直接相关的核心平台包括：

• 无尤变更平台：统一管理变更场景、指令模板、变更执行与变更通告的全流程平台；
• BNE 平台：BNE（Baidu Net Engine）流程引擎提供流程编排与自动化执行的运行时环境；
• 变更雷达：实时监控变更过程中的网络告警，进行智能分析与风险判别。

此外，网络平台层还依赖三个基础数据平台：

• 权威字典：网络元数据的唯一源头，涵盖设备信息、IP 地址、拓扑关系、配置等全量网元数据；
• 建设平台：网络规划与交付系统，网元数据的源头，负责生产网络架构信息、规划数据；
• 监控平台：提供黑盒探测、白盒采集、业务监控等多维度的网络运行数据。

变更 Agent 层： 是整个系统的智能核心。根据功能定位与应用场景，我们构建了三个专业智能体：

1. 写单 Agent：负责理解用户自然语言需求，自动生成标准化的变更单
2. 审单 Agent：对生成的变更方案进行多维度审核，识别潜在风险
3. 执行助手 Agent：全程跟进变更执行过程，提供变更盯屏、实时分析与决策支持，总结输出变更报告

三层架构各司其职、协同运作：AI 基建层提供数据与交互能力，网络平台层承载业务逻辑与自动化流程，变更 Agent 层则在此基础上实现意图理解、方案生成、风险审核与执行辅助，共同构建起百度智能变更的技术底座。

一个完整的变更，可以拆解为两个核心阶段：准备阶段与执行阶段。准备阶段对应的是写单与审单，执行阶段则是实际对网络设备进行割接操作。

接下来，我们将分别深入这两个阶段，详细拆解智能变更的实现方式与落地效果。

3.    意图驱动：一句话生成复杂变更

写单与审单这两个看似「纸上谈兵」的环节，为何值得投入如此多的技术资源？在深入技术实现之前，我们不妨先停下来思考一个根本性问题：为什么网络变更的「编写」和「审核」如此重要，以至于在 2026 年的今天，我们依然将其视为智能化的核心战场？

3.1.    传统的写单、审单工作模式

对于写单和审单的痛点，网络工程师们再熟悉不过。但研发同学或非网络专业的读者可能会疑惑：为什么到了 2026 年，我们还在执着于变更的编写和审核阶段？那些看似不起眼的语法错误，真的有那么大风险吗？是不是我们过度紧张了？又或者说，写错配置只是工程师水平问题，提升人员能力就能解决？

其实，用一个简单的类比就能说清楚：「网络变更，就像是直接在生产环境数据库上执行 SQL 或者修改 Schema，而且没有备份，几乎没有回滚机会。」

为了更直观地理解这种挑战和风险，我们可以从以下几个维度，将网络变更与软件研发进行对比：

没有 AI CODING 能力：全手工编写

• 写代码时：当前顶尖的代码大模型如 Claude、GLM-5 和非代码领域的通用大模型如 ChatGPT、DeepSeek 都已经有了非常强的代码能力，大多数程序员已经在工作中深度使用，大幅提高了开发效率。

• 写网络变更时：当前任何一款大模型对网络配置的支持甚至无法做到 2 年前大模型的代码能力，它能理解大多数网络配置，但是当需要生成时，语法错误、语义错误等低级错误频出。所以几乎所有的变更单都是纯手工或半手工编写的，自动化能力比较强的公司已经通过 jinja2 等模板维护了大多数配置，但是很多参数仍然需要网工手动填写，一个复杂的变更可能需要数天之久，耗时耗力还极易出现错误。

没有「编译」阶段：风险前置，无处隐藏

• 写代码时：有编译器、解释器、IDE 作为第一道防线。它们会实时检查语法错误、类型不匹配、未定义变量等低级错误。一个分号错误都通不过编译。

• 写网络配置时：网络 CLI 更像是一种「伪代码」，行业内没有通用标准，更没有「编译器」。不同厂商、不同型号的设备都有自己私有的语法和逻辑，且绝大多数命令行互不兼容。设备不会提示「这里有逻辑错误」，它会「忠实」地执行这条错误指令，然后静待灾难发生。网络变更要求 100% 的「一次写对」，所有语法检查都依赖人脑完成。

匮乏的测试环境：从「模拟器」到「真枪实弹」

• 写代码时：拥有从本地环境、测试环境、沙盒环境、预发环境到生产环境的完整链条，可以在无限接近真实的环境中进行充分验证。

• 测试网络变更时：网络设备全部为物理硬件，拓扑极其复杂。所谓的测试环境往往只是一个「功能模拟器」，无法 100% 复现生产网络庞大的流量、复杂的路由策略和异构的设备交互。很多问题，只有在生产环境「真枪实弹」地执行时才会暴露。网络变更更多依赖于理论推演和审单人的经验与技术能力。

没有绝对的「灰度发布」和「快速回滚」：箭已离弦，覆水难收

• 写代码时：可以通过金丝雀发布、分批发布等手段，先让 1% 的流量验证新功能。一旦出错，可以秒级回滚到上一个稳定版本。

• 执行网络变更时：变更本身就是在修改「公路」本身。改一条核心路由，就像是瞬间拆掉了所有车流都在使用的立交桥。影响是全局的、即刻的。回滚？敲下 no 命令可能需要时间生效，而网络协议收敛、路由重建更需要时间——这可能是几分钟到几十分钟的服务中断。「雪崩」在网络世界里，发生得远比想象中容易。网络变更的「发布」是非原子性的，其「回滚」也不是一键秒级，而是痛苦的抢救或者止损过程。

不可控的「爆炸半径」

• 代码中的一个 Bug：通常影响的是一个服务、一个 API、一个功能模块。它的影响范围通常是可控、可隔离的。

• 网络配置中的一个错误：其「爆炸半径」是整个网络平面。一条错误的路由可能导致一个机房、一个地域、甚至所有用户的访问中断。网络配置错误是系统性、平台级风险，其影响范围是指数级放大的。

所以，在软件研发中，责任由「编写、测试、发布」等多个环节共同分担。而在网络变更中，由于测试和验证环节只能模拟功能，绝大部分的责任和风险，都前置并压在了「编写」和「审单」这两个纯粹依靠人脑的阶段。这就是为什么我们对变更如此谨慎甚至「苛刻」，却又在很长一段时间里显得「落后」的原因。

3.2.    技术方案介绍

写单和审单如此耗费人力又极易出现错误，智能变更的首要目标就是通过 AI 让写单变得足够简单，让审单变得足够可靠。我们不仅要让工程师从繁琐的「填空题」中解放出来，更要在风险最前置的环节筑牢第一道防线。

写单、审单智能化的目标非常清晰：

• 写单智能化：将「工程师适应系统」转变为「系统理解工程师」，支持自然语言直接生成标准化变更单据，将单次变更的写单耗时从天级压缩到分钟级

• 审单自动化：实现变更方案的全维度自动审核，覆盖语法检查、语义验证、风险识别，将人工审单的负担转化为 AI 兜底的防线

• 错误率趋零：通过 AI 能力拦截低级语法错误、参数错误、逻辑错误，让「一次写对」从要求变为现实

• 经验可沉淀：将分散在工程师头脑中的经验知识，转化为可复用、可迭代的模型能力

写单和审单虽然都是变更的前期准备阶段，但是其实现方式和技术原理有很大差异：写单主要是生成，要求 AI 在理解用户意图的情况下主动去查询网络架构、网络拓扑、设备信息、客户信息等所需参数，根据变更单所需的参数逐步完成填充和编写；审单主要是分析、推理、总结，要求AI能够发现变更单中的语法错误、语义错误、逻辑错误。

所以两个 Agent 的基本框架不同：

• 写单主要采用 Agentic Workflow + Plan-Act 架构——先规划任务路径，再按需调用工具获取参数；
• 审单主要采用 Reason-Reflect 架构——先推理分析配置风险，再通过自我反思验证判断的准确性。

3.2.1.    写单 Agent 实现原理

• 智能体工作流（Agentic Workflow）作为主要框架，对写单流程进行约束，非必要不介入AI能力，减少大模型的幻觉和自由发挥，确保可达生产级别要求；

• AI 写单并非从 0 生成 CLI，而是基于白屏化、自动化的沉淀，在变更模板、自动化流程的基础上使用 AI 彻底解放网工；

• 充分发挥 AI 在分析、推理、总结上的长处：

  • 意图分析模块，基于历史变更经验，将主流的变更类型使用 RAG 和 Prompt 工程管理起来，确保 Agent 可以充分理解变更需求；
  • 变更场景的平滑接入，参考 MCP 协议将数百个变更场景用 MCP Server 管理起来（本质上是提供功能说明让 Agent 可以通过意图正确选择每个变更场景，并且类 MCP 工具可以实现灵活接入）；
  • 基于 Plan-Act 架构的无尤变更单编写，将设备信息、网段信息、客户信息、拓扑信息等海量网络数据构建为 MCP 工具，Agent 在写单时根据表单字段规划任务并按需调用工具获取参数，最终生成完整的变更单；

• 支持多轮交互修正补齐，对于用户输入的自然语言描述的需求不清晰的地方，Agent 不会去琢磨原始意图，会向用户确认需求细节，Agent 具备记忆存储和会话保持能力，多轮互动后即可生成正确的变更单（需求没有歧义的情况下一轮对话即可实现）

​

3.2.2.    审单 Agent 实现原理

• 规范审核、配置审核、意图审核解耦，通用大模型审核规范和意图，微调大模型审核配置；
• 加入 RAG（厂商手册、历史审核记录），降低审单幻觉，提升审单准确率；
• 基于积累的变更单历史数据（历史经验的沉淀，有成功和失败的案例），进行模型训练、微调，让 AI 具备参考历史来判断当前的能力，进一步提升审单准确率；
• 引入自我反思架构（一个模型输出 + 另一个模型 double check 审批，如果有问题则反馈具体问题到第一个模型，第一个模型根据第二个模型的反馈结果进行反思，重新进行处理），实际测试观察到准确率和召回率有显著提升；

​

编辑

3.2.3.    模型微调：让 AI 更懂网络

在写单和审单的智能化实践中，我们遇到一个根本性瓶颈：当前主流的大模型，对交换机、路由器等设备的专用配置命令，理解和生成能力仍有显著不足。

在决定微调之前，我们遵循一套渐进式原则：先 Prompt，再 RAG，后 MCP、SKILL，最后才考虑微调。能用简单方案解决的问题，绝不引入复杂流程增加系统风险。

但在网络配置这个场景，我们最终走到了「最后一步」。原因在于：网络配置要求 100% 的语法准确和语义严谨，RAG 可以帮助模型「查到」正确配置，但模型本身对配置语法的内在理解不足，生成的配置仍存在结构性错误——就像查了词典的外国人，写出来的句子语法还是不通。

微调的目标，就是让模型从「查着写」变成「真的懂」。

训练微调全流程（基于百度千帆平台）如下：

1. 收集过往正反例（从历史变更单中提取）；
2. 数据清洗（命令和当前设备型号版本不匹配、命令重复、配置质量低等）；
3. 数据生成和均衡，因为历史数据中变更失败的反例相对于变更成功的正例比较少，使用 LLM 基于少量的高质量的种子数据构造反例（日常积累的各类型错误的变更单），并逐个进行人工标注；
4. 指令遵循（SFT） + 偏好对齐（e.g., KTO、DPO）进行多轮训练调整，并持续观察效果。

其中，1-3 步的数据准备过程耗时耗力，但是直接决定了微调的成败。第 4 步的模型微调我们则是基于百度千帆平台集成的常用微调技术，训练微调的具体步骤如下：

第 1 步：SFT（监督微调）—— 教会模型「写得对」

SFT 的目标是让模型学会遵循指令，按照人类期望的方式生成内容。我们使用数万条高质量的指令-回答对，对基座模型进行微调。

训练过程中，模型学习的不再是「预测下一个词」，而是「当收到一个网络变更指令时，应该如何生成符合规范的配置脚本」。SFT 让模型掌握了：

• 不同厂商、不同型号设备的配置差异；
• 配置命令之间的依赖关系；
• 变更方案的完整结构（操作步骤、回退预案、验证方法）；

经过 SFT 后，模型生成的配置在语法准确率上有质的提升——从通用模型的不足 60%，提升到 90% 以上。

在训练方式上，我们根据数据量灵活选择：

• 数据量少（<1000 条）：优先选择 LoRA 微调，只更新少量参数，保留模型的通用能力；
• 数据量多（>5000 条）：可以选择全量微调，让模型更专注于网络这个垂直领域。

第 2 步：偏好对齐—— 教会模型「选得好」

SFT（监督微调）是「请家教讲清题型与作答格式」，而偏好对齐则是「让多人当评委，告诉模型哪种回答更受欢迎，再按这个口味持续纠偏」。它直接用相对偏好（A 比 B 更好）而非绝对分数，把「用户更想要什么」落实到训练目标里，典型路线源于「从人类偏好中做强化学习（RLHF）」

SFT 解决了「写得对不对」的问题，但还没解决「写得好不好」的问题。同一个变更需求，可能有多种实现方式，有的更优（更安全、更简洁、更易回滚），有的则存在隐患。

偏好对齐的目标，就是让模型学会选择「更好的那一种」。我们用历史数据中的正反案例，构建「优选回答」和「拒答回答」的配对数据。例如：

• BGP 链路缩容场景

  方案 A：先对 PEER 隔离路由、再关闭 PEER 最后删除 PEER；

  方案 B：直接删除 PEER。

我们标记方案 A 为「优选」，方案 B 为「拒答」。通过偏好对齐如 KTO、DPO 训练让模型学会倾向于生成方案 A 这种符合配置依赖关系的正确顺序。

当 AI 审单完成后，工程师可以对审核结果进行标注反馈。我们根据标注结果，将每一次审核沉淀为四类数据：

• TP（真正例）：模型预测 CLI 有问题，实际也有问题。例如模型准确识别出「undo ip pv6-prefix」这条命令存在语法错误——这是模型做对了，需要强化。

• FP（假正例）：模型预测 CLI 有问题，实际没问题。例如模型把正常的「sys（system-view 缩写）」命令误报为错误——这是模型误判，需要纠正。

• FN（假反例）：模型预测 CLI 没问题，实际有问题。例如模型没发现「undo ip pv6-prefix」的错误——这是模型漏报，最需要警惕，必须重点学习。

• TN（真反例）：模型预测 CLI 没问题，实际也没问题。例如模型正确放过正常的「sys（system-view缩写）」命令——这是模型做对了，可以强化。

这四类数据被定期回收，通过 RAG 更新或增量微调的方式，持续优化审单 Agent 的能力。今天被误报的问题，明天就不会再犯；今天漏掉的问题，明天就能准确识别。

这套闭环机制，让模型在每一次变更中持续进化。

3.3.    实际效果展示

3.3.1.    AI 写单落地效果

当运维同学需要对一批设备进行变更升级时，只需要输入「下周二凌晨，100.108.124.50 100.108.124.51 安排一下软件版本升级」。

​

写单 Agent 会帮你写好操作时间、团队、类型、客户影响范围、通告邮件、变更影响等。同时也会创建好可执行的无尤变更单。

​

​

当工程同学需要部署一个网关时，只需要输入「帮我创建一个变更，本周三凌晨，LILOUSERVER 基础服务上线，TOR:100.110.56.199 服务器机架位：SZTH4D2C-04-05-1」。Agent 会首先去理解什么是 LILOUSERVER，上线这样一个基础服务需要通告哪些内容，使用哪个变更场景，选择好后再去准备具体的无尤变更单，最终完成创建。

​

创建好的变更都会自动进入 AI 审单流程，AI 审核通过后就会进入人工审批环节（流程机制，需要团队内专家一审和团队经理二审）。

3.3.2.    AI 审单落地效果

无论是 AI 创建的变更单还是人工创建的变更单都可以进行一键 AI 审单。

下图是一个原始的 CLI 变更，你发现其中的问题了吗？（小提示：CE8850E 是华为的设备）

​

下图是 AI 审核的结果。

​

上述是一种比较常见的命令错误，但是有些时候通用模型会漏报或者误报，这时通过模型微调和 RAG 可以有效提升准召率。

• 案例 1：微调前，基于通用大模型的 Agent 漏报；微调后，基于微调大模型的 Agent 成功发现问题

​

​

• 案例 2：加入 RAG 前，Agent 误报；RAG 添加对应说明后，Agent 审核通过

​

​

4.    无人值守：全自动的夜间变更执行模式

操作单通过评审后，紧接着就是变更割接环节——这是网络变更中最令人「闻风丧胆」的一关。如果说写单审单是战前的沙盘推演，那么执行割接就是真正的短兵相接。前文我们提到，智能变更的最终目标是让工程师只需「白天确认结果」，而将深夜的煎熬交给系统。那么，从「一句话生成变更」到「无人值守执行」，中间还隔着怎样的技术鸿沟？

4.1.    传统的夜间割接

前文提到，深夜割接是网络工程师的「至暗时刻」——凌晨 12 点到 6 点，生理最脆弱、精神最紧绷、容错率几乎为零的真空期。而传统的变更执行，正是将这个最煎熬的时段交给了最孤立的个人。

工程师需要在业务低峰期登录设备，按照预设计划逐步执行操作，并实时观察设备状态和业务监控指标。整个过程要求全程保持高度专注，每完成一步都需要确认网络是否按照预期收敛、业务是否出现波动。然而，正如第一章痛点一所述，网络本身存在「不可知」的混沌定律——架构中埋藏的隐形地雷、高耦合系统里的蝴蝶效应、设备底层的代码黑天鹅，都可能让精心设计的方案在落地瞬间翻车。当这些预期之外的状况发生时，工程师面临的就是第一章痛点二描绘的场景：孤立无援的深夜，突如其来的异常，必须在极短时间内做出「回滚还是推进」的生死决策。而回滚操作本身也需要时间生效，期间业务中断的风险持续存在。

这种「人肉值守」的模式，正是传统变更之痛的集中体现——将巨大的心理压力和操作风险，压在了深夜孤军奋战的工程师身上。

4.2.    技术方案介绍

面对这样的困境，一个朴素的想法自然浮现：既然 AI 能在写单审单环节帮我们规避风险，为什么不能在执行环节也替我们值守？

但现实远没有这么简单。在变更执行阶段，一点错误都不允许发生。如果一个命令下发后路由变化不符合预期，而 AI 却「自信满满」地认为一切正常，变更继续执行下去就很可能酿成严重故障。

因此，在变更执行层面，我们选择了一条更为务实的路径：将 AI 的作用由「主导」转为「辅助」，让人与 AI 各司其职、协同作战。这也是业内使用AI的通用做法——例如 AI 生成的代码、AI 生成 shell 指令，需要人来进行最后的执行确认。基于这一理念，我们将无人值守的变更体系拆解为三大核心模块：

• 流程引擎：自动驾驶中的决策中枢，负责将变更按照编排好的流程依次执行，确保每一步都精准、可靠、可追溯。它是整个执行体系的「大脑」和「底盘」；
• 变更雷达：汽车的激光雷达，负责实时监控变更过程中的全网状态——网络侧的告警、业务侧的指标、流量的波动，无一不在它的感知范围内。一旦发现异常，立即上报；
• AI 执行助手：副驾驶位的智能协驾，全程跟进变更过程，对执行流程进行监控和总结。它不能直接操控车辆，但可以在必要时提醒「安全员」提前关注风险。

而用户，则是坐在云端的「安全员」——正常情况下放手让系统自动驾驶，一旦出现异常，安全员来紧急接手处理。

4.2.1.    流程引擎：可靠的自执行系统

BNE（Baidu NetEngine）流程引擎是整套自动驾驶体系的底盘与控制中枢。为了将工程师从繁琐的指令敲击和深夜守候中解放出来，我们构建了一套标准化、确定性的执行闭环。

核心能力：将确定性做到极致

• 可视化场景编排： 变更不再是碎片化的脚本堆砌。工程师可以像「搭积木」一样，在可视化界面上设计变更场景，将复杂的逻辑封装为标准步骤。
• 精密的分批策略： 支持设备级与批次级的灵活执行。每一批次、每一环节都可配置严格的间隔时间与准入条件，确保变更节奏始终处于受控状态。
• 「无人值守」运行： 对于高频、成熟的变更场景，流程引擎支持 7×24 小时全自动执行。在强大的安全准入限制下，实现从定时启动到自动结单的全流程无人驾驶。
• 全生命周期状态管理： 引擎实时追踪每一个节点、每一台设备、每一条指令的反馈。这种细粒度的状态透视，让任何微小的异常都能被瞬时捕获并定格。

安全设计的「底线思维」

为了确保自动化不变成「自动失控」，我们设计了严格的约束体系：

1. 灰度记录校验： 每一个流程在投入「无人值守」前，必须在现网成功执行 5 次以上。通过对厂商、型号、历史成功率的深度透视，只有通过「灰度考评」的方案才会被放行。
2. 强制回滚能力： 所有无人值守场景必须强制挂载回滚流程。一旦执行偏离预期，引擎将立刻启动「防撞墙」机制。
3. 柔性人工接管： 系统提供「安全员」介入开关。在任何时刻，工程师都可以一键接管，将变更由自动驾驶切回手动模式，确保风险绝对不外溢。

​

4.2.2.    变更雷达：智能的环境感知系统

在自动驾驶中，最怕的是系统对周围环境「失明」。变更雷达就是我们的「环境感知系统」。

4.2.2.1.    多维监控数据

网络侧监控

经过多年沉淀，百度的网络团队和网管研发团队构建了一套全方位的黑盒质量监控平台——离娄平台，可以覆盖 TOR、POD、集群、机房、城域、广域等多个层级的东西向、南北向的流量路径，无论是内网、外网还是 HPN，无论是 underlay 的物理路径还是 overlay 的到专线网关的路径，均实现了链路的 100% 覆盖。而在白盒告警上，我们也有一套强大全面的监控平台——飞鹰平台，可以涵盖硬件、软件、端口、表项、配置等多个维度的告警数据。基于离娄平台和飞鹰平台，我们可以感知到全面的网络运行状态。

业务侧监控

虽然网络团队的监控能力已经足够全面，但依旧有网络无法覆盖的区域（例如百度智能云网关的多级 overlay 流量路径），在网络监控没能及时发现故障的时候，往往需要业务同学的报障才发现问题。从发现故障到回滚变更，通常需要很长时间。还有一些情况是，业务自身出现了故障，此时网络变更可能会加剧其故障，也需要及时感知并中止变更。因此我们接入了百度智能云公网 IP、云网关、计算、存储、CDN 等多个重要业务方向的自身监控，将监控能力从网络覆盖到百度集团。

4.2.2.2.    时空关联算法

变更雷达的核心逻辑可以简单总结为一句话：在正确的地点、正确的时间，关联真正的问题。

通俗地讲，就像刑侦破案一样——既要锁定案发现场（空间），又要卡准作案时间（时间），才能从海量线索中精准抓住真凶，而不是被无关的噪音干扰。

​

• 时空关联算法：为了实现这一目标，我们构建了精密的时空关联算法：

  • 空间计算（Space）：划定「案发现场」

    基于变更内容实时建模，精准计算流量的「爆炸半径」。从物理拓扑到业务逻辑链路，确定变更究竟会波及哪些业务范围，让风险无所遁形。

  • 时间对齐（Time）：锁定「作案时刻」

    将变更操作的每一个「步长」与监控指标的「脉搏」进行秒级对齐。只有当指标波动与操作指令在时间轴上高度吻合时，才会触发预警。

  • 智能判决（Judgment）：区分「真凶」与「路人」

    算法能够敏锐区分「变更引起的次生灾害」与「现网自然的偶发故障」，有效过滤无关干扰，避免误报干扰决策。

• 四级告警体系：基于时空关联的判决结果，我们建立了一套响应极速、权责清晰的防御机制，确保每一笔变更都能安全着陆：

  • L0（必须回滚）：生存线守护

    当核心业务指标受损，且时空关联度极高时，变更雷达将给出 L0 回滚信号，不等待、不纠结，第一时间保住业务命脉。

  • L1（建议暂停）：风险缓冲池

    发现非核心指标异常或由于环境抖动导致的不确定风险，变更雷达将给出 L1 暂停信号，等待工程师确认或告警自然解除，防止风险在深夜悄然扩散。

  • 提示信息（辅助决策）

    捕捉到监控中的轻微波动，交由 AI 执行助手总结分析，将风险问题上报辅助决策。

  • 查询记录（事后复盘）

    对于可能无关的微小偏移，系统静默记录。这些数据将进入复盘库，为后续的架构优化提供长期的参考价值。

4.2.3.    AI 执行助手：认知增强的协同系统

夜间的无人值守变更，虽然没有人的直接参与，但是 AI 执行助手在全程跟进。它不能决定晚上变更的细节，但是可以总结变更中的数据，不断分析自动驾驶中的路况，出现异常（非故障级别）可主动上报升级，没有异常则会沉淀变更数据，以便第二天网工来验收变更结果。

• 盯屏数据智能创建：根据变更内容和用户的需求，自动生成变更监控大屏，辅助网工变更操作。
• 全程跟进与总结： 实时监听变更流水的每一步状态，将变更过程、告警信息、网络运行数据整理为变更报告供用户查看。
• 异常根因分析：当变更雷达发出告警信号时，Agent 会迅速调取上下文，结合当前执行的指令、历史操作经验以及厂商手册（RAG），判断故障是由于「配置下发」还是「存量隐患」导致。
• 决策支持与风险上报：面对异常情况（非故障），它也会自主决策升级给操作人，提前消除非预期情况。

总之，AI 执行助手更像是自动驾驶过程中的汽车助手，不会直接接管车辆，但是可以在必要时给司机或安全员提醒，提前关注驾驶情况。

​

4.3.    实际效果展示

1. 凌晨 1 点自动开始变更

   ​

2. 按步骤依次执行，执行过程遵循流程

   ​

   ​

3. 变更雷达实时监控

   变更雷达无异常

   ​

   变更雷达发现异常

   ​

4. 变更完成后自动结单

   ​

   ​

5. AI 助手生成执行报告

   ​

   ​

5.    L5 网络变更的终极形态？从自动化到认知智能：让变更消融于日常

对于网络工程而言，「变更」是一个自带重量感的词汇。每一次变更都意味着风险、窗口、预案与复盘。然而，当我们站在 L5 级自动驾驶网络的门口回望，一个更深层的趋势正在浮现：网络变更的终极形态，不再是更快地执行变更，而是让变更本身不再是「事件」。

从「事件型变更」到「常态型自治」的技术跨越

在传统运维体系中，变更是离散的、需要人工介入的「例外动作」。而 L5 愿景的核心，是将变更融入网络运行的每一个毫秒级决策周期——自感知系统实时捕捉业务意图与环境变化，自决策引擎在数字孪生空间中完成推演与验证，自学习机制将每一次调整沉淀为知识资产。当这套闭环运转成熟，变更便不再是凌晨三点的割接，而是网络日常呼吸的一部分。

这一跨越的实现，依赖于三重技术突破：

• 数字孪生与因果推演：不仅复现网络状态，更能预测变更的长期涟漪效应。图神经网络与时间序列模型的融合，让网络在变更前就能回答「如果……会怎样」;
• 强化学习与多目标决策：在性能、成本、安全、合规的复杂约束中，动态生成并调优变更策略。可满足性模理论与深度强化学习的结合，让智能体具备在数万种方案中寻找最优解的能力；
• 元学习与知识迁移：每一次变更都转化为可传承的训练数据。系统不仅总结本域最佳实践，更能通过元学习适应未知协议与新型攻击，实现跨场景的进化。

让决策智能成为自治底座

网络模型所代表的决策智能能力，正是这一技术闭环的核心组件。它不再停留于「感知」与「执行」，而是深入到「如何决策」的底层逻辑——在复杂的网络拓扑与业务诉求之间，建立可推演、可验证、可优化的决策模型。当百度伐谋一类产品嵌入自治系统，变更的每一个环节都获得了智能加持：事前推演规避风险，事中动态调整节奏，事后复盘沉淀经验。

这意味着，传统意义上的「变更数量」将随着系统自治能力的提升而大幅下降。那些曾经需要人工反复论证的策略调整，正在被系统在数字孪生空间中完成全链路仿真；那些曾经让工程师彻夜值守的割接，正在被智能体在毫秒级决策周期中消化。变更不再是需要「特别对待」的事件，而是融入系统日常运行的背景流。

行业新范式：从「操作」到「训练」的重心转移

当变更消融于日常，网络运维的焦点也在发生根本性转移。工程师不再需要将大量精力消耗在变更执行与应急响应上，而是可以回归到更高阶的工作——训练系统的决策能力、定义业务与网络的映射关系、设计更优的架构与协议。 这不仅是效率的提升，更是职业价值的重塑：我们不再是「变更的操作者」，而是「网络认知能力的训练师」与「数字世界的架构师」。

2025 年全球超 2800 万个生产级智能体的涌现，已经预示了这一趋势。AI 大模型从「对话者」进化为「行动者」，网络则成为智能体落地最密集的领域之一。每一次变更的自主闭环，都在为整个行业沉淀可传承的智慧；每一次数量的下降，都意味着系统成熟度的上升。

站在 2026 年的起点，我们有理由相信：网络变更的终极形态，是「变更」这个概念的消失。当自感知、自决策、自进化成为网络的默认属性，当网络智能决策能力深度融入自治闭环，我们所讨论的将不再是「如何变更」，而是「如何让网络与业务共同进化」。这正是AI赋能的网络运维带给我们这一代从业者最激动人心的技术图景。

6.    结语

五年前，我们开始思考：网络变更能否像自动驾驶一样，让系统承担重复性工作，让人专注于创造性的决策？今天，我们已经给出了肯定的答案。

我们相信，智能化的浪潮将彻底改变网络工程和运维的面貌。当网络变更变得像自动驾驶一样智能可靠时，工程师将获得更大的创造空间，业务将获得更快的迭代速度，整个数字世界将获得更坚实的网络基石。

在推进智能变更的实践中，我们深刻地认识到一个关键挑战：当前主流的大模型（如 Gemini、ChatGPT、Claude、DeepSeek、文心、豆包、千问、元宝等），对于交换机、路由器等网络设备专用的配置命令，其理解、分析和生成能力都有显著不足。

这些配置命令不像 Linux Shell 那样高度通用和开源。它们高度依赖于设备厂商、操作系统版本甚至特定硬件型号，语法独特、语义复杂、上下文依赖性强。这导致了一个根本性的瓶颈：AI 缺乏对网络领域「母语」的深度掌握。

• 理解之困：模型难以准确解析一条复杂配置的真实意图和潜在影响；
• 生成之难：让模型根据需求写出精准、合规、可执行的配置，如同要求一个只学过通用英语的人写出严谨的法律条文，极易产生「幻觉」和错误；
• 创新之限：在此基础上的逻辑审查、方案设计、风险预测等更高阶的智能应用，其准确性和可靠性便难以筑牢根基。

因此，我们在此提出一个朴素的倡议：

如果国内领先的交换机厂商、云服务商、互联网企业与研究机构能够携手，开放并贡献经过脱敏的配置范例、设备手册、变更案例与故障库，共同训练并发布一个面向网络领域的行业大模型—— 一个真正懂交换机和路由器的「网络专家模型」——那么，整个行业智能化进程的基石将被彻底夯实。

这样一个「网络基础模型」将意味着：

1. 标准化理解：为五花八门的 CLI 配置提供统一的语义理解和表示，成为 AI 与网络设备对话的「标准翻译器」（完全可以替代 OCYang，用自然语言交互）。
2. 高质量生成：从根本上提升配置脚本自动生成的准确率与合规性，让「一句话网络变更」真正可靠。
3. 知识沉淀与普惠：将各家公司顶尖网络专家的经验，编码成一个可复制、可迭代、可广泛服务的公共智能资产。
4. 生态繁荣：在此坚实基础上，开发智能运维、自动排障、网络仿真等应用将事半功倍，催生一个繁荣的网络 AI 应用生态。

百度在智能变更上的实践，只是迈出了第一步。真正的质变，需要产业链的协同与数据的共创。我们共同的目标，不仅是用 AI 改变网络变更，更是在定义下一代智能网络的基石。

​