深夜一点半某客户的电话把我从床上薅起来“核心交换机下挂的某段业务不通了你们那张拓扑图还是三个月前的中间加没加设备我们自己也记不清。”那一瞬间我意识到网工手里最缺的其实不是数据——设备配置、链路状态、ARP表都在那儿堆着缺的是一个能把它们“读”出来、随时可问、还能在人的控制下去动手改的工具。所以我给自己和团队做了个 AI 运维工作台拓扑自动发现 受控 Agent 下配置整个链路数据不出本机。这篇文章就把这套东西从架构设计到落地细节完整拆开适合正在做网络运维工具、或者想给网工团队引入 AI 的同学参考。1. 网工的真正痛点不是缺数据是缺“会用数据的人”1.1 先还原一下网工日常的混乱场景我见过太多网络运维团队的真实工作状态拓扑图是某次割接前画的 PPT后来加了三条专线、换了两台接入交换机没人更新配置变更靠远程 SSH 上去手敲改完在记事本里贴一份排障的时候翻聊天记录找上个月的工单问“这个 IP 之前是谁配的”群里安静五分钟。这些事不是网工懒而是传统工具压根没解决“信息到决策”的最后一公里。设备数据一直都在但散落在几十台设备的 CLI 里、几百页的配置里、某个人脑袋里。拓扑自动发现解决的是“信息不全”受控 Agent 解决的是“动设备不安全”数据不出本机解决的是“网络数据太敏感不敢往外送”。这三个词恰好对应网工最痛的三件事。1.2 为什么市面上的网管平台网工用起来总觉得隔了一层市面上不是没有网管系统SNMP 采集、告警大屏、流量图都做得挺漂亮。但实际用起来你会发现一个问题它们把数据采上来之后就停在“展示”这一步了。拓扑图是自动画了但你没法问它“这台设备上个月改过什么”告警是弹了但它不会告诉你“这个告警大概率是上一条变更引起的”。更深一层的问题是这些平台大多把数据收进自己的数据库再通过 Web 界面给你看。网络工程师真正需要的不是一个看板而是一个能对话、能理解网络上下文、还能在授权范围内帮自己执行操作的“副驾”。这也解释了为什么很多网管平台上线半年就变成了电子屏上的背景图画——因为它的数据没有变成决策和行动只是变成了一张图。1.3 我的破题思路把网络变成可提问、可变更的知识体我把目标定得很朴素打开这个工作台能像跟一个熟悉网络的同事聊天一样问它“核心交换机和接入交换机之间有几条链路”“哪些接口下挂的终端数量异常”“帮我把这台接入设备的某个接口划到新 VLAN先出方案给我看”。围绕这个目标整个工作台分成了三块底层是拓扑自动发现引擎把网络结构变成一张实时更新的图中间是AI 编排层负责理解自然语言、查证网络状态、生成变更方案最上层是受控执行通道任何写操作都要经过人工审批并且在指定窗口内通过标准化协议下发。这个架构的核心理念是AI 可以看得多、想得快但不能让它手脚麻利地乱动。网络变更这种高风险操作必须有人在环上拍板。2. 工作台整体架构本地推理、受控执行、最小暴露2.1 三个核心模块各自要解决什么问题先说说整体长什么样。我用了一台普通的服务器双网卡一张网卡接办公网一张接运维管理网。管理网连所有网络设备的带外管理口业务流量完全不经过这套系统避免“监控系统成了故障点”的尴尬。第一个模块是采集与拓扑引擎。它定时通过 SNMP、SSH、NETCONF 从设备上拿邻居关系、接口状态、ARP 表、配置片段把这些信息清洗后写入本地图数据库。这一步解决“网络长什么样”的问题。第二个模块是AI 编排层。用户用自然语言提问编排层先调用检索组件从知识库和设备数据里拿上下文再交给本地大模型做推理最后把结论加工成可读的回答或变更方案。这一步解决“网络发生了什么、应该怎么办”的问题。第三个模块是受控执行通道。它不直接让 AI 登设备而是把 AI 生成的变更方案转成标准变更单推给审批人审批通过后由执行引擎在指定时间窗口内用标准化接口下发并自动做配置备份和回滚。这一步解决“谁来动手、怎么保证安全”的问题。2.2 “数据不出本机”是怎么落地的“数据不出本机”不是一个宣传口号是架构上的硬约束。我有几条红线设备配置、拓扑结构、ARP 表、历史变更记录一律不允许离开这台服务器大模型推理必须用本地部署的模型不调用任何云端 API向量知识库用本地文件存储。这么做除了满足客户的安全合规要求也有现实考量。很多金融、政企客户对网络拓扑和数据中心内部 IP 规划非常敏感这些东西一旦送到外部模型服务就相当于把整个网络的“地图”交了出去。哪怕只是把一段配置匿名化后送过去客户也不放心。所以干脆做离线优先所有环节都能在内网闭环运行。2.3 为什么用图编排框架而不是“一把梭”AI 编排层我没有自己写死一套状态机而是用开源的 LangGraph 这类图编排框架来组织 Agent 的工作流。理由很简单网络排障和变更不是一个单轮的问答而是一个有多步工具调用、需要中间校验、可能要回退的流程。比如用户问“这两台设备之间为什么丢包”Agent 不能只答一句“可能链路有问题”它需要先查拓扑确认两台设备之间有几跳再查每一跳接口的错包计数再比对历史变更看有没有人动过配置最后综合给出判断。这个过程用图编排更容易表达节点是“查拓扑”“查接口”“查变更记录”边是依赖关系每个节点都有独立的工具调用和返回校验。之前我也试过用简单的 if-else 写 Agent结果没撑过三个场景就乱了。网络运维的流程分支太多同一个现象可能对应十几种原因硬编码根本写不完必须让模型根据上下文动态选择路径同时又要保证路径的可控和可回溯。2.4 权限模型人在环上Agent 只能建议和领任务这个工作台最核心的设计决策是Agent 默认没有写权限。它只能做三件事读状态、生成方案、提交变更单。所有写操作都必须经过审批人确认再由执行引擎去设备上执行。实际落地的时候我连执行引擎本身也做了细粒度授权。每台设备、每个命令模板都挂在对应的授权白名单下不在白名单里的操作一律拒绝。例如某台接入交换机只允许做接口 VLAN 调整和端口 shutdown/no shutdown不允许动 OSPF 配置核心设备只允许读连审批都不放给普通操作员。这套权限模型看起来保守但正是它能真正跑起来的原因——网工敢用领导敢批。3. 拓扑自动发现把网络“读”出来而不是“画”出来3.1 采集层SNMP LLDP/CDP ARP 三路交叉验证拓扑自动发现是整个工作台的地基地基不牢后面 AI 说什么都是瞎猜。我的采集层用了三路数据交叉验证而不是只靠一张表。第一路是 SNMP。通过 SNMP 读取设备的基础信息sysDescr 拿型号和版本ifTable 拿接口列表和状态dot1dTpFdbTable 拿 MAC 地址表。这路能解决“设备上有什么接口、接口连着谁”的部分问题。第二路是邻居发现协议。LLDP 是标准协议各家设备基本都支持老的厂商私有 CDP 协议也能采集。邻居关系是构建链路最直接的证据——接口 A 说“我的邻居是设备 B 的接口 3”那这条物理链路基本就坐实了。第三路是 ARP 表。它能帮助识别三层设备之间的交互关系特别是在没有启用 LLDP 的老旧设备上ARP 表是最后一道兜底。我把三路结果都丢进图数据库统一建模成“设备节点”和“链路边”。SNMP 给的是接口侧的事实LLDP/CDP 给的是链路侧的事实ARP 给的是三层逻辑关系三者对不上时以“至少两路一致”为准标记为置信度高的链路。3.2 链路构建与去重为什么不能只信一张表这里有个新手容易踩的坑只开 LLDP 就以为拓扑完整了。实际网络里总有设备不开 LLDP或者跨厂商私有协议不互通这时候拓扑图上会出现一堆只有节点没有边的“孤岛设备”。我做了个交叉校验逻辑如果设备 A 的接口 1 在 MAC 表里能看到设备 B 的 MAC并且设备 B 的 LLDP 邻居表里能看到设备 A那这条链路直接确认。如果只有一边能看到就标记为“疑似链路”在拓扑图上用虚线展示提醒运维人员去核实。而不是假装它不存在。去重也值得说一句。交换机之间会通过聚合链路连在一起LLDP 可能把两条物理成员口都报成邻居如果不做 Port-Channel 聚合识别拓扑图会画出两条平行线看起来好像有冗余链路实际是一条聚合链路的两条成员。我们的方法是对同一对设备之间多条链路做聚合判断接口名带 Port-Channel 或者 Eth-Trunk 关键字的合并成一条逻辑边成员口信息挂在边上作为明细。3.3 物理链路与逻辑链路可视化需要两套视图一开始我只画了一张物理拓扑图后来发现运维同学根本不爱看。为什么因为物理拓扑只告诉他“哪台设备连哪台设备”但排障的时候他更关心的是“哪些终端在哪个 VLAN 里”“三层网关在哪台设备上”。这是逻辑拓扑的范畴。所以我现在维护两套视图物理视图用于链路排查和带宽分析逻辑视图用于 VLAN、子网、网关关系的展示。物理视图的节点是设备边是链路逻辑视图的节点是 VLAN 或子网边是“此 VLAN 在三层设备 A 上终结”“这些终端属于此 VLAN”。两套视图共享底层的图数据只是查询的维度不同。3.4 一个真实的坑SNMP v3 认证不一致导致的“幽灵设备”这个坑我印象特别深不是听来的是自己踩的。某天拓扑图上突然多了一台“幽灵设备”它在某个接入交换机的 LLDP 邻居表里频繁出现又消失但 SNMP 无论如何都采集不到它的信息看起来像一台不存在的设备。排查过程很有意思我先确认 LLDP 报文没有异常邻居关系是真实的说明物理上确实有设备接入。然后测试 SNMP v3 认证发现这台设备的认证用户名和加密方式跟我们的统一模板不一致——它用的是老版本的加密协议而采集脚本只认新配置。根因是之前某次批量替换设备时有一台设备的 SNMP v3 配置被漏改了导致它在网络上“可见但不可管”。这件事给我两个教训第一接入新设备时必须做配置基线扫描SNMP 参数不在基线内直接告警第二拓扑采集的日志要留够细节不然“幽灵设备”这种问题根本无从查起。3.5 增量发现与定时巡检故障前先有基线全量拓扑采集很重如果每 5 分钟跑一次设备多了以后 CPU 和带宽都受不了。我的做法是分级采集核心设备每 5 分钟做一次轻量 SNMP 状态采集接口 up/down、CPU、内存每 30 分钟做一次邻居关系增量扫描接入设备每天凌晨做一次全量同步配合 ARP 表和 MAC 表的增量更新。这个节奏的好处是拓扑变化有人插拔线、新增设备最迟 30 分钟内反映到图上接口状态变化 5 分钟内就能触发告警。更重要的是系统会积累“基线”——比如某接口平时收发包量是多少、错包率是多少。有了基线AI 在回答“这台设备有没有异常”时就有据可依而不是瞎猜。4. 受控 Agent 下配置AI 提方案人来拍板4.1 为什么不让 AI 全自动一次误删 VLAN 的教训我最早做原型的时候也幻想过“AI 全自动运维”跟它说一句“帮我把某端口划到新 VLAN”它自己嗖嗖地就把命令敲完了。直到有一次测试环境翻车我让它给某台交换机加一个 VLAN 接口地址它理解偏差直接把原有的 VLAN 接口 shutdown 了一个网段的终端全部掉线。虽然测试环境没什么影响但那次把我吓出一身冷汗。LLM 的指令遵循能力再强也会在“意图理解”上出问题你说的是“在这个 VLAN 上加地址”它可能理解成“修改这个 VLAN 的地址”。网络配置的特点是一次错误命令的影响范围可能是整个网段甚至全网而且很多操作没有后悔药。所以从那天起我定了一条铁律AI 只做方案不做动作。所有配置类操作必须经过“人审”这个节点审批通过后才能执行。这条铁律后来被证明是这套系统能落地的最关键因素——运维团队放心了安全团队也放心了。4.2 受控 Agent 的执行链路意图→方案→人审→变更窗口→执行→回滚现在受控 Agent 的完整执行链路是这样的每一步都有明确的责任边界第一步用户在对话界面输入意图比如“把接入交换机 SW-ACC-03 的 GE0/24 接口划到 VLAN 120”。第二步Agent 先做信息核查它不会立刻生成命令而是先查拓扑确认 SW-ACC-03 存在、GE0/24 当前属于哪个 VLAN、VLAN 120 是否已在该设备上创建、接口是否被聚合链路引用。这些检查项全部通过才开始生成方案。第三步Agent 生成变更方案包括变更前状态、具体命令、变更后预期状态以及风险提示。方案以变更单形式推送给审批人。第四步审批人在界面上一键审批或者驳回。这里可以加备注比如“改成下班后的窗口执行”。第五步执行引擎按照审批通过的方案在指定时间窗口内连接设备先自动备份当前配置再执行命令。第六步执行后自动校验。命令敲完不等于变更成功执行引擎会重新读接口状态、VLAN 配置跟方案里的预期状态比对不一致就自动回滚到备份配置并生成变更报告。4.3 从自然语言到变更单一个完整示例举个例子某天一位运维同学在对话界面输入“把办公区二层那台接入交换机的 3 号口从 VLAN 10 挪到 VLAN 20这个口之前接了打印机。”Agent 处理过程如下先根据“办公区二层”“接入交换机”这些关键词定位到设备结合我们维护的资产标签再查 3 号口的当前 VLAN 归属发现确实是 VLAN 10且 MAC 表里有打印机厂商的 OUI 前缀然后查 VLAN 20 是否已在该交换机上创建结果没创建于是方案里会包含“创建 VLAN 20”这一步并给出提示该操作为一次性变更建议在业务低峰期执行。生成变更单后审批人看到的不只是“把 3 号口划到 VLAN 20”这一句而是一份包含命令序列、影响范围该口下挂终端数量、回滚方案切回 VLAN 10、风险等级低的完整表单。审批通过后执行引擎自动完成创建 VLAN、切换 access VLAN、校验端口状态三个动作全程耗时不到 30 秒。整个过程中 AI 没有直接登录设备它只是“出方案的人”动手的是受控执行引擎。4.4 白名单、命令防误和回滚给 Agent 套上缰绳受控通道的安全设计我总结成三层第一层是设备级白名单。每台设备按角色分类核心设备默认只读接入设备允许接口类变更出口设备只允许查看。白名单挂在设备标签上执行引擎每次操作前先校验设备角色是否匹配。第二层是命令级防护。执行引擎内置一个命令解析器所有要下发的命令都要按模板校验。比如接口类变更只允许“switchport access vlan”“shutdown”“no shutdown”“description”这几种命令其他命令一律拒绝。这一步能挡住 LLM 生成命令时最常见的“命令幻觉”问题。第三层是自动回滚。执行前自动备份配置到本地版本库执行后 30 秒内做状态校验一旦发现接口状态、VLAN 配置与预期不符立即回滚并通知审批人。这三层下来Agent 自由度被限制在一个非常小的区域里。很多同事问我“这样是不是把 AI 的手脚绑太死了”我的回答是网络运维要的是可靠不是炫技。AI 的真正价值在于把“网工花 20 分钟查资料、写命令、反复确认”的过程压缩到 2 分钟同时把“人为误操作”这个最大风险交给流程去兜底。4.5 踩过的坑上下文过期、并发冲突、LLM 命令幻觉这个模式也不是一帆风顺踩过几个具体的坑写出来给大家避雷。坑一上下文过期。第一次做对话式变更时用户上午问了某接口状态下午说“刚才那个接口帮我换个 VLAN”Agent 还拿上午的状态当依据结果接口配置在这期间已经被别人改过了。后来我加了强制校验方案生成前必须重新采集一次实时状态对话上下文里的状态信息只能参考不能作为执行依据。坑二并发变更冲突。两个审批单同时通过执行引擎并发去同一台设备做变更结果第二个变更把第一个的结果覆盖了。现在的做法是同一台设备同一时间只允许一个变更任务执行其他任务排队等待并在队列里标注“该设备有变更进行中”。坑三LLM 命令幻觉。模型偶尔会生成设备不支持的参数比如在该厂商设备上用了另一个厂商的语法。我的解决办法是命令模板固定化Agent 不直接生成命令原文而是生成“意图标签 参数”比如“set_interface_vlan 接口 VLAN 号”再由执行引擎根据设备厂商的模板渲染成真实命令。这样一来模型永远不会输出设备不认识的命令因为渲染逻辑是代码控制不是模型控制的。5. “数据不出本机”的工程落地离线优先5.1 本地大模型选型参数量、显存、推理延迟怎么权衡既然要求数据不出本机推理就必须用本地部署的模型。我测试过几档配置分享一些实际感受。7B 级别的模型是性价比最高的起点量化后在 8GB 显存能跑单次推理延迟在 2 到 5 秒之间满足对话场景。14B 级别理解能力明显更强尤其在“基于多段上下文做判断”的任务上更稳但需要 16GB 以上显存延迟也涨到 5 到 10 秒。再往上 32B 级别日常问答质量最好但硬件成本高单机部署需要 24GB 以上显存推理延迟接近 15 秒对话体验会打折。我的建议是别盲目追求大模型。网络运维场景里真正决定回答质量的是能不能拿到准确上下文而不是模型参数多 10 倍。7B 模型加上一套好的检索增强管道效果远超裸奔的 70B 模型。我现在生产环境用的是 14B 量化版准确性和速度之间相对均衡。5.2 私有知识库把设备手册、历史工单变成私有记忆模型本身的训练数据里没有你们网络的专属信息所以必须给它喂“私货”。我把这几类数据导入了本地知识库设备厂商手册里关于 CLI 命令的说明、历史变更工单、常见故障处理方法、网络架构文档。知识库用的是开源的本地向量数据库数据文件放在服务器本地磁盘不做任何外传。每次用户提问编排层先做两步检索第一步从图数据库拉实时网络状态第二步从向量库拉相关历史知识和手册片段把两者拼接成带上下文的提示词再交给模型。这一步是效果好坏的分水岭——没有检索模型只能泛泛而谈有了检索它才能回答“你们这种设备型号怎么配 QoS”。5.3 网络与部署层面的封闭设计数据不出本机不只靠模型本地化网络层面也要封闭。服务器放在运维管理网段防火墙规则默认拒绝出站连接只允许它访问被管理设备的带外地址入站只开放 Web 界面的端口给运维内网访问SSH 管理端口只允许跳板机 IP 访问。有意思的是这套封闭设计有一个意外的好处因为整条链路都在内网没有外部 API 调用所以系统几乎不受大模型服务商限流影响批量跑拓扑分析的时候不会因为配额报错。5.4 一次完整对话的效果还原举个实际排障的例子让你感受一下这套组合拳的效果。某天有终端反馈“上不了网”用户在工作台里输入“某号楼几个终端访问不了内网 OA可能是什么原因”Agent 的处理路径是这样的先通过终端 IP 查 ARP 表和 MAC 表定位接入交换机端口发现该端口状态是 up 但错包计数异常高说明物理链路大概率有问题再查链路两端的 LLDP 邻居信息发现对端是楼层弱电间的接入交换机顺手比对配置基线发现这个端口最近 7 天没有变更记录排除了“改配置改坏的”可能最后输出结论链路层有高错包率建议先更换该端口连接的网线或模块并给出排除步骤。整个过程用了三次工具调用耗时大约 20 秒如果靠人来做至少需要登录两台设备逐条敲命令。而这个回答里的每一步都有数据支撑不是模型编的。6. 从能用到好用性能、审计和维护6.1 性能优化全量发现从 40 分钟压到 6 分钟第一版拓扑自动发现脚本被我写成了串行模式一台接一台地 SSH 登录设备跑完一台再跑下一台。设备一多全量跑完要 40 分钟拓扑图基本就是“历史遗迹”了。后来我做了三个改动一是把采集任务改成并发池同时跑 20 个采集任务SSH 连接复用二是把 SNMP 采集和 SSH 采集分开SNMP 走独立线程池快很多三是把全量刷新改成“先拉邻居表再增量拉新增设备的明细”而不是每次把所有设备全部重新采集一遍。效果立竿见影全量发现时间压到 6 分钟左右增量发现控制在 30 秒以内。这里有个经验之谈设备采集的瓶颈通常不是设备性能而是采集脚本的并发设计和网络连接复用。大部分企业级交换机同时扛几十个 SNMP/SSH 会话毫无压力敢开并发速度就上来了。6.2 审计日志等于给 Agent 装了“行车记录仪”受控执行通道每一步都写审计日志谁提的变更单、AI 生成的方案原文、审批人是谁、审批时间、执行开始时间、执行的命令、执行后返回结果、回滚有没有触发。日志直接写本地文件按月归档同时备一份到运维团队的共享目录。有一次客户问我们“上周有人动过核心设备的 BGP 配置吗”我直接查审计日志三秒钟给出答案没有最近一次变更记录是两周前在接入交换机上的接口操作。这种“所有动作都有据可查”的能力在出问题的时候能省掉大量扯皮时间也是这套系统能被运维团队接纳的重要原因。6.3 日常维护模型、知识库、设备变更都要管这套系统上线后不是一劳永逸日常维护主要有三件事模型版本更新、知识库内容更新、设备配置基线同步。模型更新我基本跟着开源社区的节奏走有修复明显问题的版本就升一次但每次升级前会用固定的测试集跑一遍回归确认排障问答和变更方案生成的准确性没有下降。知识库更新跟着网络架构走新增了设备型号或者改了布线方案就把新文档导入向量库重新索引。设备基线同步是最容易忽略的新设备入网时必须先做一次配置基线采集否则后面查变更记录会出现断档。6.4 适用场景边界什么样的网络适合上这套工作台最后说说边界。这套工作台最适合的是设备数量在几十台到几百台之间、有标准管理协议支持、并且运维团队愿意做流程改造的网络。设备太少了比如三五台手工管理成本本来就低上这套系统反而是负担设备太多了上万台单服务器的采集和推理能力会不够需要分布式改造那是另一个量级的工程。还有一点很关键这套系统的价值不是替代网工而是把网工从重复劳动里解放出来。它擅长的是“查状态、找差异、出方案、执行标准化操作”不擅长的是“完全没见过的诡异故障”。真遇到后者还得靠人的经验去判断。我常跟同事说它是个干活特别快、但需要有人盯着的实习生而不是一个能独当一面的专家。个人体会是AI 运维工具能不能落地九成在工程不在模型。拓扑自动发现要把数据采得准、全、快受控 Agent 要把权限管得严、审计做得细数据不出本机要把架构封得死。这三件事做好了7B 模型也能干出很漂亮的效果。如果后续要继续扩展我建议从“变更影响分析”入手——在 AI 出方案前把它对全网路由、VLAN 传播、链路冗余的影响自动算一遍把风险评估做得更提前。这一步做好网工真正“躺着看报告”的日子也就不远了。 
长河君 · 2026/10/22 11:54:55 · 阅读 1.2k AI网络运维工作台：拓扑自动发现与受控Agent实战拆解
深夜一点半某客户的电话把我从床上薅起来“核心交换机下挂的某段业务不通了你们那张拓扑图还是三个月前的中间加没加设备我们自己也记不清。”那一瞬间我意识到网工手里最缺的其实不是数据——设备配置、链路状态、ARP表都在那儿堆着缺的是一个能把它们“读”出来、随时可问、还能在人的控制下去动手改的工具。所以我给自己和团队做了个 AI 运维工作台拓扑自动发现 受控 Agent 下配置整个链路数据不出本机。这篇文章就把这套东西从架构设计到落地细节完整拆开适合正在做网络运维工具、或者想给网工团队引入 AI 的同学参考。1. 网工的真正痛点不是缺数据是缺“会用数据的人”1.1 先还原一下网工日常的混乱场景我见过太多网络运维团队的真实工作状态拓扑图是某次割接前画的 PPT后来加了三条专线、换了两台接入交换机没人更新配置变更靠远程 SSH 上去手敲改完在记事本里贴一份排障的时候翻聊天记录找上个月的工单问“这个 IP 之前是谁配的”群里安静五分钟。这些事不是网工懒而是传统工具压根没解决“信息到决策”的最后一公里。设备数据一直都在但散落在几十台设备的 CLI 里、几百页的配置里、某个人脑袋里。拓扑自动发现解决的是“信息不全”受控 Agent 解决的是“动设备不安全”数据不出本机解决的是“网络数据太敏感不敢往外送”。这三个词恰好对应网工最痛的三件事。1.2 为什么市面上的网管平台网工用起来总觉得隔了一层市面上不是没有网管系统SNMP 采集、告警大屏、流量图都做得挺漂亮。但实际用起来你会发现一个问题它们把数据采上来之后就停在“展示”这一步了。拓扑图是自动画了但你没法问它“这台设备上个月改过什么”告警是弹了但它不会告诉你“这个告警大概率是上一条变更引起的”。更深一层的问题是这些平台大多把数据收进自己的数据库再通过 Web 界面给你看。网络工程师真正需要的不是一个看板而是一个能对话、能理解网络上下文、还能在授权范围内帮自己执行操作的“副驾”。这也解释了为什么很多网管平台上线半年就变成了电子屏上的背景图画——因为它的数据没有变成决策和行动只是变成了一张图。1.3 我的破题思路把网络变成可提问、可变更的知识体我把目标定得很朴素打开这个工作台能像跟一个熟悉网络的同事聊天一样问它“核心交换机和接入交换机之间有几条链路”“哪些接口下挂的终端数量异常”“帮我把这台接入设备的某个接口划到新 VLAN先出方案给我看”。围绕这个目标整个工作台分成了三块底层是拓扑自动发现引擎把网络结构变成一张实时更新的图中间是AI 编排层负责理解自然语言、查证网络状态、生成变更方案最上层是受控执行通道任何写操作都要经过人工审批并且在指定窗口内通过标准化协议下发。这个架构的核心理念是AI 可以看得多、想得快但不能让它手脚麻利地乱动。网络变更这种高风险操作必须有人在环上拍板。2. 工作台整体架构本地推理、受控执行、最小暴露2.1 三个核心模块各自要解决什么问题先说说整体长什么样。我用了一台普通的服务器双网卡一张网卡接办公网一张接运维管理网。管理网连所有网络设备的带外管理口业务流量完全不经过这套系统避免“监控系统成了故障点”的尴尬。第一个模块是采集与拓扑引擎。它定时通过 SNMP、SSH、NETCONF 从设备上拿邻居关系、接口状态、ARP 表、配置片段把这些信息清洗后写入本地图数据库。这一步解决“网络长什么样”的问题。第二个模块是AI 编排层。用户用自然语言提问编排层先调用检索组件从知识库和设备数据里拿上下文再交给本地大模型做推理最后把结论加工成可读的回答或变更方案。这一步解决“网络发生了什么、应该怎么办”的问题。第三个模块是受控执行通道。它不直接让 AI 登设备而是把 AI 生成的变更方案转成标准变更单推给审批人审批通过后由执行引擎在指定时间窗口内用标准化接口下发并自动做配置备份和回滚。这一步解决“谁来动手、怎么保证安全”的问题。2.2 “数据不出本机”是怎么落地的“数据不出本机”不是一个宣传口号是架构上的硬约束。我有几条红线设备配置、拓扑结构、ARP 表、历史变更记录一律不允许离开这台服务器大模型推理必须用本地部署的模型不调用任何云端 API向量知识库用本地文件存储。这么做除了满足客户的安全合规要求也有现实考量。很多金融、政企客户对网络拓扑和数据中心内部 IP 规划非常敏感这些东西一旦送到外部模型服务就相当于把整个网络的“地图”交了出去。哪怕只是把一段配置匿名化后送过去客户也不放心。所以干脆做离线优先所有环节都能在内网闭环运行。2.3 为什么用图编排框架而不是“一把梭”AI 编排层我没有自己写死一套状态机而是用开源的 LangGraph 这类图编排框架来组织 Agent 的工作流。理由很简单网络排障和变更不是一个单轮的问答而是一个有多步工具调用、需要中间校验、可能要回退的流程。比如用户问“这两台设备之间为什么丢包”Agent 不能只答一句“可能链路有问题”它需要先查拓扑确认两台设备之间有几跳再查每一跳接口的错包计数再比对历史变更看有没有人动过配置最后综合给出判断。这个过程用图编排更容易表达节点是“查拓扑”“查接口”“查变更记录”边是依赖关系每个节点都有独立的工具调用和返回校验。之前我也试过用简单的 if-else 写 Agent结果没撑过三个场景就乱了。网络运维的流程分支太多同一个现象可能对应十几种原因硬编码根本写不完必须让模型根据上下文动态选择路径同时又要保证路径的可控和可回溯。2.4 权限模型人在环上Agent 只能建议和领任务这个工作台最核心的设计决策是Agent 默认没有写权限。它只能做三件事读状态、生成方案、提交变更单。所有写操作都必须经过审批人确认再由执行引擎去设备上执行。实际落地的时候我连执行引擎本身也做了细粒度授权。每台设备、每个命令模板都挂在对应的授权白名单下不在白名单里的操作一律拒绝。例如某台接入交换机只允许做接口 VLAN 调整和端口 shutdown/no shutdown不允许动 OSPF 配置核心设备只允许读连审批都不放给普通操作员。这套权限模型看起来保守但正是它能真正跑起来的原因——网工敢用领导敢批。3. 拓扑自动发现把网络“读”出来而不是“画”出来3.1 采集层SNMP LLDP/CDP ARP 三路交叉验证拓扑自动发现是整个工作台的地基地基不牢后面 AI 说什么都是瞎猜。我的采集层用了三路数据交叉验证而不是只靠一张表。第一路是 SNMP。通过 SNMP 读取设备的基础信息sysDescr 拿型号和版本ifTable 拿接口列表和状态dot1dTpFdbTable 拿 MAC 地址表。这路能解决“设备上有什么接口、接口连着谁”的部分问题。第二路是邻居发现协议。LLDP 是标准协议各家设备基本都支持老的厂商私有 CDP 协议也能采集。邻居关系是构建链路最直接的证据——接口 A 说“我的邻居是设备 B 的接口 3”那这条物理链路基本就坐实了。第三路是 ARP 表。它能帮助识别三层设备之间的交互关系特别是在没有启用 LLDP 的老旧设备上ARP 表是最后一道兜底。我把三路结果都丢进图数据库统一建模成“设备节点”和“链路边”。SNMP 给的是接口侧的事实LLDP/CDP 给的是链路侧的事实ARP 给的是三层逻辑关系三者对不上时以“至少两路一致”为准标记为置信度高的链路。3.2 链路构建与去重为什么不能只信一张表这里有个新手容易踩的坑只开 LLDP 就以为拓扑完整了。实际网络里总有设备不开 LLDP或者跨厂商私有协议不互通这时候拓扑图上会出现一堆只有节点没有边的“孤岛设备”。我做了个交叉校验逻辑如果设备 A 的接口 1 在 MAC 表里能看到设备 B 的 MAC并且设备 B 的 LLDP 邻居表里能看到设备 A那这条链路直接确认。如果只有一边能看到就标记为“疑似链路”在拓扑图上用虚线展示提醒运维人员去核实。而不是假装它不存在。去重也值得说一句。交换机之间会通过聚合链路连在一起LLDP 可能把两条物理成员口都报成邻居如果不做 Port-Channel 聚合识别拓扑图会画出两条平行线看起来好像有冗余链路实际是一条聚合链路的两条成员。我们的方法是对同一对设备之间多条链路做聚合判断接口名带 Port-Channel 或者 Eth-Trunk 关键字的合并成一条逻辑边成员口信息挂在边上作为明细。3.3 物理链路与逻辑链路可视化需要两套视图一开始我只画了一张物理拓扑图后来发现运维同学根本不爱看。为什么因为物理拓扑只告诉他“哪台设备连哪台设备”但排障的时候他更关心的是“哪些终端在哪个 VLAN 里”“三层网关在哪台设备上”。这是逻辑拓扑的范畴。所以我现在维护两套视图物理视图用于链路排查和带宽分析逻辑视图用于 VLAN、子网、网关关系的展示。物理视图的节点是设备边是链路逻辑视图的节点是 VLAN 或子网边是“此 VLAN 在三层设备 A 上终结”“这些终端属于此 VLAN”。两套视图共享底层的图数据只是查询的维度不同。3.4 一个真实的坑SNMP v3 认证不一致导致的“幽灵设备”这个坑我印象特别深不是听来的是自己踩的。某天拓扑图上突然多了一台“幽灵设备”它在某个接入交换机的 LLDP 邻居表里频繁出现又消失但 SNMP 无论如何都采集不到它的信息看起来像一台不存在的设备。排查过程很有意思我先确认 LLDP 报文没有异常邻居关系是真实的说明物理上确实有设备接入。然后测试 SNMP v3 认证发现这台设备的认证用户名和加密方式跟我们的统一模板不一致——它用的是老版本的加密协议而采集脚本只认新配置。根因是之前某次批量替换设备时有一台设备的 SNMP v3 配置被漏改了导致它在网络上“可见但不可管”。这件事给我两个教训第一接入新设备时必须做配置基线扫描SNMP 参数不在基线内直接告警第二拓扑采集的日志要留够细节不然“幽灵设备”这种问题根本无从查起。3.5 增量发现与定时巡检故障前先有基线全量拓扑采集很重如果每 5 分钟跑一次设备多了以后 CPU 和带宽都受不了。我的做法是分级采集核心设备每 5 分钟做一次轻量 SNMP 状态采集接口 up/down、CPU、内存每 30 分钟做一次邻居关系增量扫描接入设备每天凌晨做一次全量同步配合 ARP 表和 MAC 表的增量更新。这个节奏的好处是拓扑变化有人插拔线、新增设备最迟 30 分钟内反映到图上接口状态变化 5 分钟内就能触发告警。更重要的是系统会积累“基线”——比如某接口平时收发包量是多少、错包率是多少。有了基线AI 在回答“这台设备有没有异常”时就有据可依而不是瞎猜。4. 受控 Agent 下配置AI 提方案人来拍板4.1 为什么不让 AI 全自动一次误删 VLAN 的教训我最早做原型的时候也幻想过“AI 全自动运维”跟它说一句“帮我把某端口划到新 VLAN”它自己嗖嗖地就把命令敲完了。直到有一次测试环境翻车我让它给某台交换机加一个 VLAN 接口地址它理解偏差直接把原有的 VLAN 接口 shutdown 了一个网段的终端全部掉线。虽然测试环境没什么影响但那次把我吓出一身冷汗。LLM 的指令遵循能力再强也会在“意图理解”上出问题你说的是“在这个 VLAN 上加地址”它可能理解成“修改这个 VLAN 的地址”。网络配置的特点是一次错误命令的影响范围可能是整个网段甚至全网而且很多操作没有后悔药。所以从那天起我定了一条铁律AI 只做方案不做动作。所有配置类操作必须经过“人审”这个节点审批通过后才能执行。这条铁律后来被证明是这套系统能落地的最关键因素——运维团队放心了安全团队也放心了。4.2 受控 Agent 的执行链路意图→方案→人审→变更窗口→执行→回滚现在受控 Agent 的完整执行链路是这样的每一步都有明确的责任边界第一步用户在对话界面输入意图比如“把接入交换机 SW-ACC-03 的 GE0/24 接口划到 VLAN 120”。第二步Agent 先做信息核查它不会立刻生成命令而是先查拓扑确认 SW-ACC-03 存在、GE0/24 当前属于哪个 VLAN、VLAN 120 是否已在该设备上创建、接口是否被聚合链路引用。这些检查项全部通过才开始生成方案。第三步Agent 生成变更方案包括变更前状态、具体命令、变更后预期状态以及风险提示。方案以变更单形式推送给审批人。第四步审批人在界面上一键审批或者驳回。这里可以加备注比如“改成下班后的窗口执行”。第五步执行引擎按照审批通过的方案在指定时间窗口内连接设备先自动备份当前配置再执行命令。第六步执行后自动校验。命令敲完不等于变更成功执行引擎会重新读接口状态、VLAN 配置跟方案里的预期状态比对不一致就自动回滚到备份配置并生成变更报告。4.3 从自然语言到变更单一个完整示例举个例子某天一位运维同学在对话界面输入“把办公区二层那台接入交换机的 3 号口从 VLAN 10 挪到 VLAN 20这个口之前接了打印机。”Agent 处理过程如下先根据“办公区二层”“接入交换机”这些关键词定位到设备结合我们维护的资产标签再查 3 号口的当前 VLAN 归属发现确实是 VLAN 10且 MAC 表里有打印机厂商的 OUI 前缀然后查 VLAN 20 是否已在该交换机上创建结果没创建于是方案里会包含“创建 VLAN 20”这一步并给出提示该操作为一次性变更建议在业务低峰期执行。生成变更单后审批人看到的不只是“把 3 号口划到 VLAN 20”这一句而是一份包含命令序列、影响范围该口下挂终端数量、回滚方案切回 VLAN 10、风险等级低的完整表单。审批通过后执行引擎自动完成创建 VLAN、切换 access VLAN、校验端口状态三个动作全程耗时不到 30 秒。整个过程中 AI 没有直接登录设备它只是“出方案的人”动手的是受控执行引擎。4.4 白名单、命令防误和回滚给 Agent 套上缰绳受控通道的安全设计我总结成三层第一层是设备级白名单。每台设备按角色分类核心设备默认只读接入设备允许接口类变更出口设备只允许查看。白名单挂在设备标签上执行引擎每次操作前先校验设备角色是否匹配。第二层是命令级防护。执行引擎内置一个命令解析器所有要下发的命令都要按模板校验。比如接口类变更只允许“switchport access vlan”“shutdown”“no shutdown”“description”这几种命令其他命令一律拒绝。这一步能挡住 LLM 生成命令时最常见的“命令幻觉”问题。第三层是自动回滚。执行前自动备份配置到本地版本库执行后 30 秒内做状态校验一旦发现接口状态、VLAN 配置与预期不符立即回滚并通知审批人。这三层下来Agent 自由度被限制在一个非常小的区域里。很多同事问我“这样是不是把 AI 的手脚绑太死了”我的回答是网络运维要的是可靠不是炫技。AI 的真正价值在于把“网工花 20 分钟查资料、写命令、反复确认”的过程压缩到 2 分钟同时把“人为误操作”这个最大风险交给流程去兜底。4.5 踩过的坑上下文过期、并发冲突、LLM 命令幻觉这个模式也不是一帆风顺踩过几个具体的坑写出来给大家避雷。坑一上下文过期。第一次做对话式变更时用户上午问了某接口状态下午说“刚才那个接口帮我换个 VLAN”Agent 还拿上午的状态当依据结果接口配置在这期间已经被别人改过了。后来我加了强制校验方案生成前必须重新采集一次实时状态对话上下文里的状态信息只能参考不能作为执行依据。坑二并发变更冲突。两个审批单同时通过执行引擎并发去同一台设备做变更结果第二个变更把第一个的结果覆盖了。现在的做法是同一台设备同一时间只允许一个变更任务执行其他任务排队等待并在队列里标注“该设备有变更进行中”。坑三LLM 命令幻觉。模型偶尔会生成设备不支持的参数比如在该厂商设备上用了另一个厂商的语法。我的解决办法是命令模板固定化Agent 不直接生成命令原文而是生成“意图标签 参数”比如“set_interface_vlan 接口 VLAN 号”再由执行引擎根据设备厂商的模板渲染成真实命令。这样一来模型永远不会输出设备不认识的命令因为渲染逻辑是代码控制不是模型控制的。5. “数据不出本机”的工程落地离线优先5.1 本地大模型选型参数量、显存、推理延迟怎么权衡既然要求数据不出本机推理就必须用本地部署的模型。我测试过几档配置分享一些实际感受。7B 级别的模型是性价比最高的起点量化后在 8GB 显存能跑单次推理延迟在 2 到 5 秒之间满足对话场景。14B 级别理解能力明显更强尤其在“基于多段上下文做判断”的任务上更稳但需要 16GB 以上显存延迟也涨到 5 到 10 秒。再往上 32B 级别日常问答质量最好但硬件成本高单机部署需要 24GB 以上显存推理延迟接近 15 秒对话体验会打折。我的建议是别盲目追求大模型。网络运维场景里真正决定回答质量的是能不能拿到准确上下文而不是模型参数多 10 倍。7B 模型加上一套好的检索增强管道效果远超裸奔的 70B 模型。我现在生产环境用的是 14B 量化版准确性和速度之间相对均衡。5.2 私有知识库把设备手册、历史工单变成私有记忆模型本身的训练数据里没有你们网络的专属信息所以必须给它喂“私货”。我把这几类数据导入了本地知识库设备厂商手册里关于 CLI 命令的说明、历史变更工单、常见故障处理方法、网络架构文档。知识库用的是开源的本地向量数据库数据文件放在服务器本地磁盘不做任何外传。每次用户提问编排层先做两步检索第一步从图数据库拉实时网络状态第二步从向量库拉相关历史知识和手册片段把两者拼接成带上下文的提示词再交给模型。这一步是效果好坏的分水岭——没有检索模型只能泛泛而谈有了检索它才能回答“你们这种设备型号怎么配 QoS”。5.3 网络与部署层面的封闭设计数据不出本机不只靠模型本地化网络层面也要封闭。服务器放在运维管理网段防火墙规则默认拒绝出站连接只允许它访问被管理设备的带外地址入站只开放 Web 界面的端口给运维内网访问SSH 管理端口只允许跳板机 IP 访问。有意思的是这套封闭设计有一个意外的好处因为整条链路都在内网没有外部 API 调用所以系统几乎不受大模型服务商限流影响批量跑拓扑分析的时候不会因为配额报错。5.4 一次完整对话的效果还原举个实际排障的例子让你感受一下这套组合拳的效果。某天有终端反馈“上不了网”用户在工作台里输入“某号楼几个终端访问不了内网 OA可能是什么原因”Agent 的处理路径是这样的先通过终端 IP 查 ARP 表和 MAC 表定位接入交换机端口发现该端口状态是 up 但错包计数异常高说明物理链路大概率有问题再查链路两端的 LLDP 邻居信息发现对端是楼层弱电间的接入交换机顺手比对配置基线发现这个端口最近 7 天没有变更记录排除了“改配置改坏的”可能最后输出结论链路层有高错包率建议先更换该端口连接的网线或模块并给出排除步骤。整个过程用了三次工具调用耗时大约 20 秒如果靠人来做至少需要登录两台设备逐条敲命令。而这个回答里的每一步都有数据支撑不是模型编的。6. 从能用到好用性能、审计和维护6.1 性能优化全量发现从 40 分钟压到 6 分钟第一版拓扑自动发现脚本被我写成了串行模式一台接一台地 SSH 登录设备跑完一台再跑下一台。设备一多全量跑完要 40 分钟拓扑图基本就是“历史遗迹”了。后来我做了三个改动一是把采集任务改成并发池同时跑 20 个采集任务SSH 连接复用二是把 SNMP 采集和 SSH 采集分开SNMP 走独立线程池快很多三是把全量刷新改成“先拉邻居表再增量拉新增设备的明细”而不是每次把所有设备全部重新采集一遍。效果立竿见影全量发现时间压到 6 分钟左右增量发现控制在 30 秒以内。这里有个经验之谈设备采集的瓶颈通常不是设备性能而是采集脚本的并发设计和网络连接复用。大部分企业级交换机同时扛几十个 SNMP/SSH 会话毫无压力敢开并发速度就上来了。6.2 审计日志等于给 Agent 装了“行车记录仪”受控执行通道每一步都写审计日志谁提的变更单、AI 生成的方案原文、审批人是谁、审批时间、执行开始时间、执行的命令、执行后返回结果、回滚有没有触发。日志直接写本地文件按月归档同时备一份到运维团队的共享目录。有一次客户问我们“上周有人动过核心设备的 BGP 配置吗”我直接查审计日志三秒钟给出答案没有最近一次变更记录是两周前在接入交换机上的接口操作。这种“所有动作都有据可查”的能力在出问题的时候能省掉大量扯皮时间也是这套系统能被运维团队接纳的重要原因。6.3 日常维护模型、知识库、设备变更都要管这套系统上线后不是一劳永逸日常维护主要有三件事模型版本更新、知识库内容更新、设备配置基线同步。模型更新我基本跟着开源社区的节奏走有修复明显问题的版本就升一次但每次升级前会用固定的测试集跑一遍回归确认排障问答和变更方案生成的准确性没有下降。知识库更新跟着网络架构走新增了设备型号或者改了布线方案就把新文档导入向量库重新索引。设备基线同步是最容易忽略的新设备入网时必须先做一次配置基线采集否则后面查变更记录会出现断档。6.4 适用场景边界什么样的网络适合上这套工作台最后说说边界。这套工作台最适合的是设备数量在几十台到几百台之间、有标准管理协议支持、并且运维团队愿意做流程改造的网络。设备太少了比如三五台手工管理成本本来就低上这套系统反而是负担设备太多了上万台单服务器的采集和推理能力会不够需要分布式改造那是另一个量级的工程。还有一点很关键这套系统的价值不是替代网工而是把网工从重复劳动里解放出来。它擅长的是“查状态、找差异、出方案、执行标准化操作”不擅长的是“完全没见过的诡异故障”。真遇到后者还得靠人的经验去判断。我常跟同事说它是个干活特别快、但需要有人盯着的实习生而不是一个能独当一面的专家。个人体会是AI 运维工具能不能落地九成在工程不在模型。拓扑自动发现要把数据采得准、全、快受控 Agent 要把权限管得严、审计做得细数据不出本机要把架构封得死。这三件事做好了7B 模型也能干出很漂亮的效果。如果后续要继续扩展我建议从“变更影响分析”入手——在 AI 出方案前把它对全网路由、VLAN 传播、链路冗余的影响自动算一遍把风险评估做得更提前。这一步做好网工真正“躺着看报告”的日子也就不远了。