干网络这一行的人多少都体会过凌晨被电话叫醒的感觉。我这里说的网络变更不是加一条静态路由那么简单而是那种要动核心设备、牵一发动全身的变更调整路由策略、修改访问控制、切换链路冗余、升级设备版本。过去这些事靠的是评审文档、变更窗口和几十条手工命令现在越来越多团队开始聊 Agent也就是用智能体去接管网络变更的规划、执行和验证就像把车从 L2 辅助驾驶一路推到 L4 高度自动驾驶。这篇文章不聊玄学就聊聊我自己的理解、一次变更是怎么被 Agent 拆解的以及实际落地时踩过的坑。先说明一点Agent 做网络变更不是简单地把“敲命令”这个动作自动化。真正的难点在于变更前要知道改哪里、变更中要感知有没有出问题、变更后要确认业务不受影响出问题还要能安全退回去。这一整条链路过去靠人肉盯着现在靠 Agent 闭环。我会从为什么网络变更这么痛讲起再把自动驾驶分级映射到网络领域然后拆解一套可以落地的 Agent 架构和执行流程最后分享几个只有真跑过才会懂的实战教训。1. 网络变更为什么这么痛1.1 一个让我失眠的典型事故场景先还原一个场景。某次模拟割接演练里变更目标是调整骨干路由器上的路由过滤策略。白天评审全员通过方案写了三页纸命令准备好了回滚脚本也导出了一份 running-config 备份。到了凌晨变更窗口负责执行的同事登录设备因为终端窗口开太多把本该敲在备机上的命令敲到了正在承载业务的主设备上。恰好那条命令是一条大范围过滤规则一敲进去核心路由表瞬间被刷掉一大片业务告警五六分钟后才响起来可这五分钟已经足够让整个网络从正常变成瘫痪。这种事故听起来像是“手滑”但核心问题不在手滑而在变更链路没有闭环。命令敲出去之后的实时校验是缺失的没有人能在五秒内感知路由表被清空也没有机制能在异常出现的第一时间自动回滚。所谓变更方案在纸面上完整在现实中却是一堆零散动作的拼接。1.2 人工变更的“死亡链条”我复盘过不少变更故障发现它们几乎都会经过一条类似的链条需求描述不精确。业务侧说“让某段流量慢一点”这并不能直接变成 QoS 策略中间需要人脑做转换。变更前的状态感知不足。网络是动态的接口流量、路由表、CPU 占用都在实时变化可变更执行人拿到的往往是几小时前甚至几天前的静态信息。执行过程靠 SSH 手工敲命令。命令顺序、设备差异、拼写错误每一个都是风险点。验证手段太弱。很多团队所谓验证就是 ping 一下管理地址通了就算成功完全没看业务流量是否正常转发。回滚想当然。以为把备份配置刷回去就能恢复忽略了动态路由协议需要重新收敛、接口要重新协商、邻居状态需要重建。这条链条里人是最不可控的因素。尤其在凌晨两三点注意力下降、疲劳累积、备份命令都容易敲错但网络变更偏偏最喜欢在这个时间窗口发生。越是想尽量减少业务影响越是把人推到最容易犯错的状态。我并不是主张完全抛弃人工而是说如果把网络变更看成一个“感知—规划—执行—验证—回滚”的闭环那么人只适合做其中的监督和审批而不是每一个环节的苦力。这也是我后来转向研究 Agent 的根本原因。2. 像自动驾驶分级一样给网络自动化定位2.1 从 L0 到 L5每一级意味着什么自动驾驶领域用 L0 到 L5 描述系统替代人的程度这套坐标其实特别适合网络自动化。我把它改写成网络变更场景下的描述级别名称网络变更中的表现L0无自动化工程师逐条登录设备手工敲命令完全依赖个人经验和现场运气L1脚本辅助用脚本批量推送固定配置但参数、顺序、结果都靠人盯着L2部分自动化系统能自动采集状态、生成命令人逐条审批后执行L3条件自动化系统在限定范围内自动执行、验证、触发回滚人只在异常时干预L4高度自动化系统在特定变更场景和窗口内自行闭环人只负责审批和紧急接管L5完全自动化任意场景、任意设备都能自动变更全程无需人参与放在网络领域L5 在现实中非常难实现。网络不像代码仓库可以随便改错了再回滚到上一个 commit。网络设备有物理链路状态、光模块衰减、协议收敛时间、老版本设备的各种怪癖长尾多到数不清。所以我认为当前真正值得追求的目标是 L4系统能自己完成一次变更的完整闭环但人在环路中保留一个“安全员”的位置平时不干预异常时一键接管。2.2 Agent 和传统自动化脚本的本质区别很多人一听“用 Agent 做网络变更”第一反应是“这不就是写个 Python 脚本吗”。还真不是。传统脚本是一个“固定程序”参数变了或环境没按预期走它就愣在那里不会根据现场情况调整策略。Agent 的本质是有感知、有规划、有反思、会调用工具的智能体它执行的不是一串死命令而是一个可以动态调整的闭环。打个比方传统脚本是沿着地图上画好的路开遇到封路就只能停Agent 是车里坐了一个会看路况、会重新规划路线、还会判断是否掉头的驾驶系统。大模型是它的推理引擎网络工具链是它的手脚规则库和校验器是它的安全带。这个区别具体到网络变更里非常明显。传统脚本只能按“登录设备、下发配置、退出”的顺序走一旦设备返回异常脚本除了抛错几乎没有其他动作。Agent 可以在异常时先采集当前状态再判断是继续、重试还是回滚。它不执着于原有步骤而是围绕“让网络达到目标状态”这个最终目标做决策。2.3 Agent 眼中的一次网络变更长什么样用一句话概括Agent 把一次网络变更看成“从当前状态到目标状态的一次受控迁移”。它收到的输入不再是“敲哪几条命令”而是一个目标。这里我用一个简化后的任务结构来展示{ intent: 在核心设备 A 和 B 上新增 ACL 规则拒绝某个内网段访问管理网段, targets: [core-a, core-b], constraints: [ 不能影响现有业务转发面, 只能在变更窗口内执行, 所有变更必须经过审批 ], verification: [ 接口状态保持正常, 管理通道可达, 目标内网段到管理网段的访问被拒绝, 非目标网段访问管理网段不受影响 ] }这个结构看起来简单但落地时难点在于怎么从模糊的自然语言变成精确约束。比如用户说“把某个网段收一下”Agent 需要去查地址规划库确定这个网段在哪些设备上出现过涉及的 ACL 编号是什么当前有没有匹配这条规则的流量以及拒绝之后会不会误伤其他业务。这些步骤不是大模型拍脑袋想出来的而是通过调用 CMDB、监控系统、设备状态查询工具逐步完成的。这也决定了 Agent 不能是一个孤零零的大模型必须接入一套完整的工具链和状态源。3. 用 Agent 跑通一次网络变更的落地拆解3.1 整体架构五个层面各司其职我在实际设计一个模拟网络变更 Agent 时会把系统拆成五个层面每一层职责单一避免大模型什么事都干。接入层接受工单、聊天消息、命令行触发把自然语言转成结构化变更意图。引擎层负责意图解析、任务拆解、生成执行计划、处理异常。这一层是 Agent 的大脑但不直接接触设备。工具层封装设备连接、配置采集、命令行下发、配置备份、状态验证、监控查询等能力让 Agent 以“调用工具”的方式操作网络。安全层权限校验、资源锁、审批闸口、配置语法校验、沙箱验证、审计日志全部卡在执行链路之外。状态层保存 CMDB 数据、设备快照、历史变更记录、回滚预案为 Agent 提供实时感知依据。这五层缺一不可。没有工具层Agent 就是纸上谈兵没有安全层大模型一句幻觉可能直接干翻全网没有状态层Agent 连“当前网络正不正常”都判断不了。3.2 核心流程的七步实操拆解一次完整的 Agent 网络变更我会把它拆成七个步骤每一步都有明确的输入输出和校验条件。第一步目标解析。用户提交“把某管理网段的访问收掉”这类需求后Agent 先解析出目标网段、动作类型、影响范围再去 CMDB 里查这个网段在哪些设备上有相关策略。这一步如果不透后面全白干。第二步状态快照。通过工具层采集目标设备的 running-config、接口状态、CPU 利用率、BGP 邻居状态、当前路由表生成一份独立的快照文件。这个快照既用于变更前影响分析也用于回滚时的基线对照。第三步生成变更计划。Agent 根据目标、快照约束和网络拓扑生成一组候选配置并安排好执行顺序。比如两台核心设备之间存在依赖关系就先改一台验证稳定后再改第二台而不是两台同时并行。第四步沙箱验证与静态校验。所有 LLM 生成的配置必须先过三道关设备语法校验、与现有配置的差分比对、模拟环境验证。这一步的核心原则是大模型生成的内容永远不能直接执行必须走确定性校验。第五步人工审批。把变更计划、影响面、风险等级、回滚方案一起推给审批人。审批人不是看命令文本而是看 Agent 给出的解释和风险评估。第六步执行与逐步校验。执行时严格要求“一步一验”每下发一条配置等待一个合理的收敛时间采集关键指标确认没有异常再执行下一步。出现任何一条验证失败立即停止并触发回滚。第七步收尾与归档。确认全部验证通过后更新 CMDB 状态生成变更审计报告保存完整截图、命令输出和监控指标。这一步很多人忽略但它是后续 Agent 迭代和问题追溯的基础。3.3 让 Agent “不瞎改”三层护栏和人工审批LLM 生成配置的能力越来越强但幻觉问题也如影随形。我见过的大多数严重事故根源不是大模型能力不够而是没有护栏就把它的输出下发给了设备。所以我的建议是任何 Agent 变更都必须过三层护栏。第一层是约束校验配置命令必须匹配设备型号和版本。不同厂商、不同版本甚至不同板卡支持的语法都有差异Agent 必须有一份设备能力模板而不是靠大模型记忆硬写。第二层是差分比对把生成的候选配置和当前配置做 diff剔除无关变更。有时候 Agent 为了达成一个目标会顺手“优化”掉一些不该动的东西差分校验能把这种风险挡在门外。第三层是业务验证执行后从设备层、协议层、业务层三个维度确认状态。设备层看 CPU、内存、接口状态协议层看路由表、邻居状态业务层看关键路径的丢包和时延。我还坚持一个原则默认情况下所有变更都需要人工审批。只有某类变更已经在历史任务中稳定运行足够多次、验证覆盖率百分之百、回滚方案经过演练才能进入“自动放行”白名单。这个白名单的建立过程要慢宁可一步慢不可一步错。下面是一个极简的执行逻辑示例用来表达“步骤校验”在代码层面的样貌def execute_change_step(device, command, expected_state, converge_wait): backup snapshot(device) run_command(device, command) time.sleep(converge_wait) if not verify(device, expected_state): rollback_to(device, backup) return False, rollback triggered return True, step ok实际生产系统当然比这个复杂得多但这个骨架说明了 Agent 执行变更时的核心思想每一步都预设一个“可验证的期望状态”达不到就回滚而不是硬着头皮继续。4. 实际跑过之后最深的几个坑4.1 大模型一本正经地编造配置我第一次尝试用 Agent 自动优化 OSPF 汇总配置时它生成了类似“summary-address 10.10.0.0 255.255.0.0”的命令。乍一看没问题但目标设备其实要求用 CIDR 格式而不是点分十进制掩码。如果没人拦截这条命令就会在设备上报错甚至导致整段配置会话中断。那次之后我彻底明白LLM 对网络设备语法的记忆并不可靠尤其是小众参数、老版本兼容性问题它经常会“自信地胡编”。应对方式是把设备语法校验做成一个独立的确定性服务让 Agent 生成完后强制走一遍校验任何不通过的配置一律不进入执行环节。我还会让 Agent 按设备角色读取对应的“配置模板说明书”在生成之前就把正确语法约束注入到它的上下文中。4.2 回滚脚本比变更本身更容易翻车这是我最想强调的一个坑。有次变更执行后设备 CPU 异常升高Agent 触发了自动回滚但回滚脚本只是把备份配置重新刷回设备没有等待路由协议收敛。结果配置是恢复到了旧版本但 OSPF 邻居反复重建接口状态在 up 和 down 之间来回抖动业务影响反而比变更前更大。后来我在回滚逻辑里加入了一个关键参数收敛等待时间。具体做法是在恢复配置后先不做任何动作等待至少三个 OSPF dead interval让协议有足够时间完成邻居重建和路由收敛。不同的路由协议等待时长不一样通常我会把预估收敛时间乘以 1.5 作为保守值。回滚不是简单地把配置倒回去而是要把整个网络状态重新稳定下来。回滚脚本必须像变更脚本一样在平时就反复演练。4.3 并发执行引发的配置锁冲突做自动化时大家都会有“多台设备并行下发”的冲动。我第一次跑并行变更时用并发工具同时给两台设备下发配置结果其中一台在修改配置还未保存时另一个任务又尝试进入配置模式直接报配置锁冲突导致配置会话异常中断。解决这个问题不能靠设备自觉。我在工具层引入了一个分布式资源锁同一台设备同一时间只允许一个任务持有写锁其他任务要么等待要么直接拒绝。变更队列也要按设备维度做串行化不同设备可以并行但同一设备的写操作必须严格排队。同时每个操作都要写审计日志记录操作者、任务 ID、命令摘要和时间戳方便出问题时回溯。下面是一个常见的排查速查表整理了我实际遇到过的几类问题症状可能原因解决方案设备提示配置锁冲突多个自动化任务并行写同一设备引入资源锁同一设备串行化变更后部分设备状态不一致只执行了部分设备或部分步骤用设备组变量和批量校验保证全量覆盖回滚后仍出现业务异常路由协议没有重新收敛回滚脚本中加入收敛等待时间大模型生成不存在的命令LLM 幻觉或设备型号语法不匹配强制走语法校验和差分比对4.4 别把实时状态全部塞给大模型早期我犯过一个设计错误为了让 Agent “更懂网络”把大量设备状态、路由表、监控数据直接拼进提示词里。结果大模型上下文被塞爆不仅响应变慢决策质量也下降因为它被无关信息干扰了。后来的实践经验是不要做大而全的“状态搬运”而是把状态查询做成工具让 Agent 按需调用。它需要确认某条路由是否被过滤就直接调用一个 route_verify 工具工具返回的是一段精简结果比如“目标网段在 core-a 上被前缀列表 block-10 过滤”而不是几千条路由表原文。这就是检索增强的思路。大模型负责判断和规划确定性工具负责提供精确事实两边各干各擅长的事。我还会把“是否进入回滚”这类关键判断交给确定性代码而不是让大模型自己拍板。因为回滚决策需要用明确的阈值和基线来判定比如“连续 30 秒丢包率超过 5% 就回滚”这种逻辑用规则引擎远比用大模型可靠。Agent 可以建议回滚但触发的最终动作必须经过一个可解释的确定性决策层。5. 从 L3 走向 L4 的几个关键动作5.1 渐进放开不要第一天就让人睡觉如果你问我 L4 怎么落地我的答案一定是“渐进式放权”。第一步先用 Agent 辅助生成变更单和候选命令人审、人执行Agent 只当参谋。第二步放开自动执行但每一步都要人工确认这时候相当于 L2 到 L3 之间。第三步把验证和回滚都自动化人只在计划审批和异常接管时介入这才算真正进入 L3。第四步把那些低风险、高验证覆盖率、有成熟回滚预案的变更类型加入自动放行名单进入 L4。每次放权都要搭配一个强约束所有自动放行的变更必须能在五分钟内被全局回滚必须能明确说出“这次改了什么、影响哪些路径、用什么指标衡量是否成功”。做不到这三点的变更类型永远留在人工审批区。5.2 可观测性是 L4 的前提条件没有可观测性就不要谈自动化回滚。Agent 每次决策依赖的数据至少应该覆盖三个方面设备级指标包括 CPU、内存、温度、接口错包协议级指标包括路由表条目数、BGP 邻居状态、OSPF 收敛状态业务级指标包括关键路径的时延、丢包、吞吐量变化。这些数据要能实时查询能自动计算出“是否偏离基线”。我见过不少团队先搭了 Agent 框架却没有把监控数据整理成可被程序调用的接口结果 Agent 说“验证通过”实际上它的验证逻辑只是跑了一个 ping。L4 的底气不是模型多强而是你手里的监控和状态数据多全、多准。Agent 只是把数据变成行动数据本身才是闭环的基础。5.3 最后分享一点个人体会我做网络自动化这些年踩的最深的坑就是对“自动化”这三个字的误解。自动化不是把命令敲得更快而是把每一次变更都变成一次可以理解、可以控制、可以回头的状态迁移。Agent 的出现其实不是为了取代工程师而是把我们从凌晨的割接现场里解放出来让我们有精力去处理那些真正需要人类判断的事情。我个人现在给自己定了几条铁律任何变更先做快照任何命令先过校验任何回滚先等收敛任何自动放行先有白名单。这几条看起来很笨但正是它们让我敢在变更窗口关闭之后安心睡觉。L4 不是玄学它是一点一点用工程方法堆出来的安全感。 
长河君 · 2026/10/18 7:45:29 · 阅读 1.2k 用Agent驱动网络变更自动化：从人工割接到L4自动驾驶
干网络这一行的人多少都体会过凌晨被电话叫醒的感觉。我这里说的网络变更不是加一条静态路由那么简单而是那种要动核心设备、牵一发动全身的变更调整路由策略、修改访问控制、切换链路冗余、升级设备版本。过去这些事靠的是评审文档、变更窗口和几十条手工命令现在越来越多团队开始聊 Agent也就是用智能体去接管网络变更的规划、执行和验证就像把车从 L2 辅助驾驶一路推到 L4 高度自动驾驶。这篇文章不聊玄学就聊聊我自己的理解、一次变更是怎么被 Agent 拆解的以及实际落地时踩过的坑。先说明一点Agent 做网络变更不是简单地把“敲命令”这个动作自动化。真正的难点在于变更前要知道改哪里、变更中要感知有没有出问题、变更后要确认业务不受影响出问题还要能安全退回去。这一整条链路过去靠人肉盯着现在靠 Agent 闭环。我会从为什么网络变更这么痛讲起再把自动驾驶分级映射到网络领域然后拆解一套可以落地的 Agent 架构和执行流程最后分享几个只有真跑过才会懂的实战教训。1. 网络变更为什么这么痛1.1 一个让我失眠的典型事故场景先还原一个场景。某次模拟割接演练里变更目标是调整骨干路由器上的路由过滤策略。白天评审全员通过方案写了三页纸命令准备好了回滚脚本也导出了一份 running-config 备份。到了凌晨变更窗口负责执行的同事登录设备因为终端窗口开太多把本该敲在备机上的命令敲到了正在承载业务的主设备上。恰好那条命令是一条大范围过滤规则一敲进去核心路由表瞬间被刷掉一大片业务告警五六分钟后才响起来可这五分钟已经足够让整个网络从正常变成瘫痪。这种事故听起来像是“手滑”但核心问题不在手滑而在变更链路没有闭环。命令敲出去之后的实时校验是缺失的没有人能在五秒内感知路由表被清空也没有机制能在异常出现的第一时间自动回滚。所谓变更方案在纸面上完整在现实中却是一堆零散动作的拼接。1.2 人工变更的“死亡链条”我复盘过不少变更故障发现它们几乎都会经过一条类似的链条需求描述不精确。业务侧说“让某段流量慢一点”这并不能直接变成 QoS 策略中间需要人脑做转换。变更前的状态感知不足。网络是动态的接口流量、路由表、CPU 占用都在实时变化可变更执行人拿到的往往是几小时前甚至几天前的静态信息。执行过程靠 SSH 手工敲命令。命令顺序、设备差异、拼写错误每一个都是风险点。验证手段太弱。很多团队所谓验证就是 ping 一下管理地址通了就算成功完全没看业务流量是否正常转发。回滚想当然。以为把备份配置刷回去就能恢复忽略了动态路由协议需要重新收敛、接口要重新协商、邻居状态需要重建。这条链条里人是最不可控的因素。尤其在凌晨两三点注意力下降、疲劳累积、备份命令都容易敲错但网络变更偏偏最喜欢在这个时间窗口发生。越是想尽量减少业务影响越是把人推到最容易犯错的状态。我并不是主张完全抛弃人工而是说如果把网络变更看成一个“感知—规划—执行—验证—回滚”的闭环那么人只适合做其中的监督和审批而不是每一个环节的苦力。这也是我后来转向研究 Agent 的根本原因。2. 像自动驾驶分级一样给网络自动化定位2.1 从 L0 到 L5每一级意味着什么自动驾驶领域用 L0 到 L5 描述系统替代人的程度这套坐标其实特别适合网络自动化。我把它改写成网络变更场景下的描述级别名称网络变更中的表现L0无自动化工程师逐条登录设备手工敲命令完全依赖个人经验和现场运气L1脚本辅助用脚本批量推送固定配置但参数、顺序、结果都靠人盯着L2部分自动化系统能自动采集状态、生成命令人逐条审批后执行L3条件自动化系统在限定范围内自动执行、验证、触发回滚人只在异常时干预L4高度自动化系统在特定变更场景和窗口内自行闭环人只负责审批和紧急接管L5完全自动化任意场景、任意设备都能自动变更全程无需人参与放在网络领域L5 在现实中非常难实现。网络不像代码仓库可以随便改错了再回滚到上一个 commit。网络设备有物理链路状态、光模块衰减、协议收敛时间、老版本设备的各种怪癖长尾多到数不清。所以我认为当前真正值得追求的目标是 L4系统能自己完成一次变更的完整闭环但人在环路中保留一个“安全员”的位置平时不干预异常时一键接管。2.2 Agent 和传统自动化脚本的本质区别很多人一听“用 Agent 做网络变更”第一反应是“这不就是写个 Python 脚本吗”。还真不是。传统脚本是一个“固定程序”参数变了或环境没按预期走它就愣在那里不会根据现场情况调整策略。Agent 的本质是有感知、有规划、有反思、会调用工具的智能体它执行的不是一串死命令而是一个可以动态调整的闭环。打个比方传统脚本是沿着地图上画好的路开遇到封路就只能停Agent 是车里坐了一个会看路况、会重新规划路线、还会判断是否掉头的驾驶系统。大模型是它的推理引擎网络工具链是它的手脚规则库和校验器是它的安全带。这个区别具体到网络变更里非常明显。传统脚本只能按“登录设备、下发配置、退出”的顺序走一旦设备返回异常脚本除了抛错几乎没有其他动作。Agent 可以在异常时先采集当前状态再判断是继续、重试还是回滚。它不执着于原有步骤而是围绕“让网络达到目标状态”这个最终目标做决策。2.3 Agent 眼中的一次网络变更长什么样用一句话概括Agent 把一次网络变更看成“从当前状态到目标状态的一次受控迁移”。它收到的输入不再是“敲哪几条命令”而是一个目标。这里我用一个简化后的任务结构来展示{ intent: 在核心设备 A 和 B 上新增 ACL 规则拒绝某个内网段访问管理网段, targets: [core-a, core-b], constraints: [ 不能影响现有业务转发面, 只能在变更窗口内执行, 所有变更必须经过审批 ], verification: [ 接口状态保持正常, 管理通道可达, 目标内网段到管理网段的访问被拒绝, 非目标网段访问管理网段不受影响 ] }这个结构看起来简单但落地时难点在于怎么从模糊的自然语言变成精确约束。比如用户说“把某个网段收一下”Agent 需要去查地址规划库确定这个网段在哪些设备上出现过涉及的 ACL 编号是什么当前有没有匹配这条规则的流量以及拒绝之后会不会误伤其他业务。这些步骤不是大模型拍脑袋想出来的而是通过调用 CMDB、监控系统、设备状态查询工具逐步完成的。这也决定了 Agent 不能是一个孤零零的大模型必须接入一套完整的工具链和状态源。3. 用 Agent 跑通一次网络变更的落地拆解3.1 整体架构五个层面各司其职我在实际设计一个模拟网络变更 Agent 时会把系统拆成五个层面每一层职责单一避免大模型什么事都干。接入层接受工单、聊天消息、命令行触发把自然语言转成结构化变更意图。引擎层负责意图解析、任务拆解、生成执行计划、处理异常。这一层是 Agent 的大脑但不直接接触设备。工具层封装设备连接、配置采集、命令行下发、配置备份、状态验证、监控查询等能力让 Agent 以“调用工具”的方式操作网络。安全层权限校验、资源锁、审批闸口、配置语法校验、沙箱验证、审计日志全部卡在执行链路之外。状态层保存 CMDB 数据、设备快照、历史变更记录、回滚预案为 Agent 提供实时感知依据。这五层缺一不可。没有工具层Agent 就是纸上谈兵没有安全层大模型一句幻觉可能直接干翻全网没有状态层Agent 连“当前网络正不正常”都判断不了。3.2 核心流程的七步实操拆解一次完整的 Agent 网络变更我会把它拆成七个步骤每一步都有明确的输入输出和校验条件。第一步目标解析。用户提交“把某管理网段的访问收掉”这类需求后Agent 先解析出目标网段、动作类型、影响范围再去 CMDB 里查这个网段在哪些设备上有相关策略。这一步如果不透后面全白干。第二步状态快照。通过工具层采集目标设备的 running-config、接口状态、CPU 利用率、BGP 邻居状态、当前路由表生成一份独立的快照文件。这个快照既用于变更前影响分析也用于回滚时的基线对照。第三步生成变更计划。Agent 根据目标、快照约束和网络拓扑生成一组候选配置并安排好执行顺序。比如两台核心设备之间存在依赖关系就先改一台验证稳定后再改第二台而不是两台同时并行。第四步沙箱验证与静态校验。所有 LLM 生成的配置必须先过三道关设备语法校验、与现有配置的差分比对、模拟环境验证。这一步的核心原则是大模型生成的内容永远不能直接执行必须走确定性校验。第五步人工审批。把变更计划、影响面、风险等级、回滚方案一起推给审批人。审批人不是看命令文本而是看 Agent 给出的解释和风险评估。第六步执行与逐步校验。执行时严格要求“一步一验”每下发一条配置等待一个合理的收敛时间采集关键指标确认没有异常再执行下一步。出现任何一条验证失败立即停止并触发回滚。第七步收尾与归档。确认全部验证通过后更新 CMDB 状态生成变更审计报告保存完整截图、命令输出和监控指标。这一步很多人忽略但它是后续 Agent 迭代和问题追溯的基础。3.3 让 Agent “不瞎改”三层护栏和人工审批LLM 生成配置的能力越来越强但幻觉问题也如影随形。我见过的大多数严重事故根源不是大模型能力不够而是没有护栏就把它的输出下发给了设备。所以我的建议是任何 Agent 变更都必须过三层护栏。第一层是约束校验配置命令必须匹配设备型号和版本。不同厂商、不同版本甚至不同板卡支持的语法都有差异Agent 必须有一份设备能力模板而不是靠大模型记忆硬写。第二层是差分比对把生成的候选配置和当前配置做 diff剔除无关变更。有时候 Agent 为了达成一个目标会顺手“优化”掉一些不该动的东西差分校验能把这种风险挡在门外。第三层是业务验证执行后从设备层、协议层、业务层三个维度确认状态。设备层看 CPU、内存、接口状态协议层看路由表、邻居状态业务层看关键路径的丢包和时延。我还坚持一个原则默认情况下所有变更都需要人工审批。只有某类变更已经在历史任务中稳定运行足够多次、验证覆盖率百分之百、回滚方案经过演练才能进入“自动放行”白名单。这个白名单的建立过程要慢宁可一步慢不可一步错。下面是一个极简的执行逻辑示例用来表达“步骤校验”在代码层面的样貌def execute_change_step(device, command, expected_state, converge_wait): backup snapshot(device) run_command(device, command) time.sleep(converge_wait) if not verify(device, expected_state): rollback_to(device, backup) return False, rollback triggered return True, step ok实际生产系统当然比这个复杂得多但这个骨架说明了 Agent 执行变更时的核心思想每一步都预设一个“可验证的期望状态”达不到就回滚而不是硬着头皮继续。4. 实际跑过之后最深的几个坑4.1 大模型一本正经地编造配置我第一次尝试用 Agent 自动优化 OSPF 汇总配置时它生成了类似“summary-address 10.10.0.0 255.255.0.0”的命令。乍一看没问题但目标设备其实要求用 CIDR 格式而不是点分十进制掩码。如果没人拦截这条命令就会在设备上报错甚至导致整段配置会话中断。那次之后我彻底明白LLM 对网络设备语法的记忆并不可靠尤其是小众参数、老版本兼容性问题它经常会“自信地胡编”。应对方式是把设备语法校验做成一个独立的确定性服务让 Agent 生成完后强制走一遍校验任何不通过的配置一律不进入执行环节。我还会让 Agent 按设备角色读取对应的“配置模板说明书”在生成之前就把正确语法约束注入到它的上下文中。4.2 回滚脚本比变更本身更容易翻车这是我最想强调的一个坑。有次变更执行后设备 CPU 异常升高Agent 触发了自动回滚但回滚脚本只是把备份配置重新刷回设备没有等待路由协议收敛。结果配置是恢复到了旧版本但 OSPF 邻居反复重建接口状态在 up 和 down 之间来回抖动业务影响反而比变更前更大。后来我在回滚逻辑里加入了一个关键参数收敛等待时间。具体做法是在恢复配置后先不做任何动作等待至少三个 OSPF dead interval让协议有足够时间完成邻居重建和路由收敛。不同的路由协议等待时长不一样通常我会把预估收敛时间乘以 1.5 作为保守值。回滚不是简单地把配置倒回去而是要把整个网络状态重新稳定下来。回滚脚本必须像变更脚本一样在平时就反复演练。4.3 并发执行引发的配置锁冲突做自动化时大家都会有“多台设备并行下发”的冲动。我第一次跑并行变更时用并发工具同时给两台设备下发配置结果其中一台在修改配置还未保存时另一个任务又尝试进入配置模式直接报配置锁冲突导致配置会话异常中断。解决这个问题不能靠设备自觉。我在工具层引入了一个分布式资源锁同一台设备同一时间只允许一个任务持有写锁其他任务要么等待要么直接拒绝。变更队列也要按设备维度做串行化不同设备可以并行但同一设备的写操作必须严格排队。同时每个操作都要写审计日志记录操作者、任务 ID、命令摘要和时间戳方便出问题时回溯。下面是一个常见的排查速查表整理了我实际遇到过的几类问题症状可能原因解决方案设备提示配置锁冲突多个自动化任务并行写同一设备引入资源锁同一设备串行化变更后部分设备状态不一致只执行了部分设备或部分步骤用设备组变量和批量校验保证全量覆盖回滚后仍出现业务异常路由协议没有重新收敛回滚脚本中加入收敛等待时间大模型生成不存在的命令LLM 幻觉或设备型号语法不匹配强制走语法校验和差分比对4.4 别把实时状态全部塞给大模型早期我犯过一个设计错误为了让 Agent “更懂网络”把大量设备状态、路由表、监控数据直接拼进提示词里。结果大模型上下文被塞爆不仅响应变慢决策质量也下降因为它被无关信息干扰了。后来的实践经验是不要做大而全的“状态搬运”而是把状态查询做成工具让 Agent 按需调用。它需要确认某条路由是否被过滤就直接调用一个 route_verify 工具工具返回的是一段精简结果比如“目标网段在 core-a 上被前缀列表 block-10 过滤”而不是几千条路由表原文。这就是检索增强的思路。大模型负责判断和规划确定性工具负责提供精确事实两边各干各擅长的事。我还会把“是否进入回滚”这类关键判断交给确定性代码而不是让大模型自己拍板。因为回滚决策需要用明确的阈值和基线来判定比如“连续 30 秒丢包率超过 5% 就回滚”这种逻辑用规则引擎远比用大模型可靠。Agent 可以建议回滚但触发的最终动作必须经过一个可解释的确定性决策层。5. 从 L3 走向 L4 的几个关键动作5.1 渐进放开不要第一天就让人睡觉如果你问我 L4 怎么落地我的答案一定是“渐进式放权”。第一步先用 Agent 辅助生成变更单和候选命令人审、人执行Agent 只当参谋。第二步放开自动执行但每一步都要人工确认这时候相当于 L2 到 L3 之间。第三步把验证和回滚都自动化人只在计划审批和异常接管时介入这才算真正进入 L3。第四步把那些低风险、高验证覆盖率、有成熟回滚预案的变更类型加入自动放行名单进入 L4。每次放权都要搭配一个强约束所有自动放行的变更必须能在五分钟内被全局回滚必须能明确说出“这次改了什么、影响哪些路径、用什么指标衡量是否成功”。做不到这三点的变更类型永远留在人工审批区。5.2 可观测性是 L4 的前提条件没有可观测性就不要谈自动化回滚。Agent 每次决策依赖的数据至少应该覆盖三个方面设备级指标包括 CPU、内存、温度、接口错包协议级指标包括路由表条目数、BGP 邻居状态、OSPF 收敛状态业务级指标包括关键路径的时延、丢包、吞吐量变化。这些数据要能实时查询能自动计算出“是否偏离基线”。我见过不少团队先搭了 Agent 框架却没有把监控数据整理成可被程序调用的接口结果 Agent 说“验证通过”实际上它的验证逻辑只是跑了一个 ping。L4 的底气不是模型多强而是你手里的监控和状态数据多全、多准。Agent 只是把数据变成行动数据本身才是闭环的基础。5.3 最后分享一点个人体会我做网络自动化这些年踩的最深的坑就是对“自动化”这三个字的误解。自动化不是把命令敲得更快而是把每一次变更都变成一次可以理解、可以控制、可以回头的状态迁移。Agent 的出现其实不是为了取代工程师而是把我们从凌晨的割接现场里解放出来让我们有精力去处理那些真正需要人类判断的事情。我个人现在给自己定了几条铁律任何变更先做快照任何命令先过校验任何回滚先等收敛任何自动放行先有白名单。这几条看起来很笨但正是它们让我敢在变更窗口关闭之后安心睡觉。L4 不是玄学它是一点一点用工程方法堆出来的安全感。