干网工这行最磨人的不是设备本身有多复杂而是那些重复得让人麻木的活儿拓扑图过期了没人更新新设备上线得手动画线批量改配置的时候一台台 SSH 上去敲命令敲完还得再核对一遍远程排查故障现场同事拍照、打电话信息来回传递还容易失真。所以当我决定搞一个AI 运维工作台的时候目标定得很朴素让网工少做点重复劳动但绝对不能把网络的控制权稀里糊涂交给一个会一本正经胡说八道的模型。这个工作台最后做成了跑在本地的一套轻量系统核心就三件事拓扑自动发现、通过受控 Agent 下发配置、数据不出本机。它适合所有被拓扑图和批量配置折磨的网工参考也适合想往网络自动化方向转型的运维同学。我尽量把踩过的坑和实际方案讲透而不是只给一个概念框架。1. 需求画像与整体方案为什么拓扑要自动发现配置要受控下发1.1 真实工作场景里网工最痛的三件事我在动手之前先把自己过去几年的运维经历和身边同行吐槽的点梳理了一遍最后收敛成三个高频痛点。第一个是拓扑图过期。很多网络的拓扑图只在项目交付时画过一次之后每次割接、加设备、调整链路图基本没人同步。等真正要用它的时候图上标的设备跟实际对不上端口号也是错的。我见过不少同行排查故障前先花半小时考古对着旧图猜链路效率低不说还容易误导判断。第二个是配置变更靠人肉。常规操作比如把某个端口划到指定 VLAN、改接口描述、调整静态路由听起来简单但设备多了以后就是体力活。尤其几十台上百台设备要同步改一类配置时逐台登录、逐条敲命令、逐项核对任何一个环节手滑轻则配置回滚重则造成业务中断。更麻烦的是改之前往往没有完整的配置基线改错了想恢复连备份都找不齐。第三个是远程操作信任问题。让 AI 直接接管设备配置网工心里是不踏实的因为大模型天然会自由发挥而网络设备最忌讳的就是不确定。但完全靠人肉又确实累所以中间需要一个受控的缓冲层——让 AI 出方案让人做决策机器只执行被审批过的、模板化的命令。1.2 方案选型为什么不直接上现成网管平台一开始我也考虑过直接用开源网管系统或者商业网管平台毕竟省事。但调研了一圈发现它们跟我的需求错位挺明显。现成的开源网管平台功能确实全拓扑发现、性能监控、告警都有但部署架构偏重依赖数据库、消息队列、Web 服务一堆组件跑起来之后维护成本不低。而且它们的拓扑发现和配置管理通常是割裂的——拓扑模块只画图配置模块只管备份真正看图说话直接改配置的闭环能力几乎没有。商业网管产品倒是成熟但有两个问题让我却步一是价格和授权模式对中小规模网络不友好二是不少产品的数据要上云或集中到厂商平台这一点在客户侧很难接受。我做这个项目的一个硬性要求就是数据不出本机很多商业方案天然不满足。另外现成工具大多是监控视角而不是变更视角。它们能告诉你设备 down 了但不会帮你分析这个 down 跟昨天那次配置变更有没有关系更不会在你输入一句把这两台设备的互联接口加入一个聚合组之后自动帮你检查两端接口状态、生成命令、等审批通过后执行并回验。这个空缺正是我这个工作台要补的位置。1.3 数据不出本机是保守还是必须标题里数据不出本机这个约束很多人第一反应是合规要求。确实客户的网络拓扑、设备 IP、配置片段都属于敏感信息拿这些数据去调用公有云的大模型接口哪怕只是做一次文本分析也等于把内部网络结构暴露给了第三方。这在不少行业是直接违规的。但除了合规还有一个更实际的原因断网可用性。运维场景经常是网络出问题的时候才更需要 AI 辅助结果 AI 服务在云端网络一断辅助也断了这就很尴尬。把推理和知识库全部放到本机意味着即使整个网络处于半瘫痪状态工作台依然能基于本地拓扑、本地配置快照给出排查建议和修复命令。所以我最终确定的架构原则是一切数据本地存储AI 推理本地运行设备访问只发生在内网所有变更操作必须经过 Agent 审批闸门。这个原则贯穿了整个项目后面每一块设计都围绕它展开。2. 拓扑自动发现从手动画图到五分钟出全貌2.1 发现协议选型与信息采集原理拓扑自动发现听起来高大上核心原理其实不复杂让每台设备告诉你它跟谁连着然后把这些邻居关系拼起来就是一张拓扑图。实现手段主要有两条路SNMP 读 MIB 表和 SSH 执行命令抓回显。我两条路都用了因为实际网络里不同厂商、不同型号的设备开放能力差别很大。先说 SNMP 这条路。主流设备都支持 SNMP通过标准 MIB 可以拿到很干净的邻居信息。以 LLDP 为例标准 LLDP-MIB 里有一张远程邻居表里面记录了本地接口、对端 chassis ID、对端端口 ID、对端系统名这些关键字段。只要轮询所有设备把这张表读出来就能知道每台设备在每个接口上发现了谁。类似地ARP 表、MAC 地址转发表FDB、路由表也能通过对应的 MIB 读到。ARP 表能帮你发现同一广播域内的主机 IPFDB 能帮你定位某个 MAC 从哪个端口学到路由表能辅助判断三层链路关系。再说 SSH 这条路。有些设备 SNMP 配置不全或者 community 权限只给了只读且 MIB 视图受限这时候就得靠命令行采集。用 Python 的 netmiko 库连接设备执行show lldp neighbors detail不同厂商命令名不同但思路一致拿到回显后用 TextFSM 模板解析成结构化数据。TextFSM 的好处是网上有大量现成的厂商模板不用自己从头写正则。我实际采集时是两条腿走路优先 SNMP 批量采集速度快、不占设备 CPUSNMP 拿不到或解析异常的设备再用 SSH 补采。两种方式得到的数据最终都归一化成统一的邻居关系表格式大概是这样的字段含义示例local_device本端设备名core-sw-01local_interface本端接口名GigabitEthernet1/0/5remote_device对端设备名access-sw-02remote_interface对端接口名GigabitEthernet0/0/24discovered_via发现方式lldp / cdp / arp / fdb2.2 设备指纹识别与拓扑关系建模有了邻居关系还得知道每个节点是什么类型的设备否则画出来的图就是一堆方块没法区分交换机、路由器、防火墙和服务器。设备类型识别我用的方法比较传统但很有效组合看三条信息。第一条是系统描述sysDescrSNMP 里直接有设备型号和软件版本描述比如厂商和产品系列字段一匹配就能猜个大概。第二条是系统对象 IDsysObjectID厂商会在企业私有分支下给每个产品线分配唯一 ID这个非常准维护一张 ID 到设备型号的映射表就行。第三条是 MAC 地址前缀也就是 OUI。每张网卡 MAC 的前三段是 IEEE 分配的厂商代码通过 OUI 库可以判断这个设备是哪家厂商出的对于没有运行 LLDP 的主机、打印机、摄像头之类尤其好用。设备类型识别完拓扑图就不只是谁连着谁了还能表达层次关系。网络拓扑天然分接入层、汇聚层、核心层我根据设备类型、链路数量、连接方向给每个节点算一个层级权重再用图布局算法自动分层。画图的话推荐用前端可视化库把 networkx 算好的节点和边直接丢给渲染引擎支持力导向布局、缩放、拖拽比静态图片实用得多。2.3 实际效果与边界情况我拿一个大约 40 台设备、200 多条链路的模拟园区网络做了测试全部设备配置好 LLDP 之后从扫描到出图大概用了 5 分钟基本能达到上架即发现的效果。但真实网络里没有这么理想几个边界情况得提前有预期。第一个是 LLDP 没开。不少老设备默认没开 LLDP或者只开了 CDP思科私有协议甚至啥都没开。我的处理是两层兜底一是通过 ARP 表和 FDB 表做二次发现比如两台交换机之间虽然没 LLDP但只要它们属于同一个 VLANARP 表就能看到对方的 IPFDB 能看到对方 MAC 从哪个端口学到配合 OUI 库就能推断出连接关系二是提供手动补边入口遇到实在发现不了的特殊链路直接在界面上画一条线并标记为手动添加后续扫描时保留不覆盖。第二个是聚合链路。两台交换机之间常用多个物理端口做链路聚合如果不处理画出来就是一堆平行线。我在建模阶段会做聚合检测如果发现同一对设备之间存在多条链路且端口速率、端口状态一致就合并成一条聚合链路并在边上标注成员端口数量。第三个是二三层混合拓扑。交换机之间是二层链路路由器之间是三层链路画在同一张图里容易乱。我的做法是分两个视图物理拓扑视图和三层拓扑视图。物理视图基于 LLDP/邻居关系生成三层视图基于 OSPF/BGP 邻居和路由表生成两个视图可以切换排查故障时对照着看特别有用。3. 受控 Agent 与配置下发让 AI 干活但缰绳在网工手里3.1 Agent 架构为什么是 Agent 而不是直接 SSH工作台里最敏感的模块是配置下发。一开始我确实想过让工作台直接 SSH 到设备上执行命令实现最简单但很快否掉了原因有三点。第一安全边界不清晰。工作台如果持有所有设备的 SSH 凭据等于拿到了一把万能钥匙一旦工作台本身被攻破或者误操作整个网络的管理权限全丢了。第二网络可达性问题。工作台所在的位置不一定能直连所有设备尤其设备分散在不同安全域的时候直连方案要打通一堆网络策略。第三缺少在场的执行反馈。配置变更最好能感知设备的实时状态变化直连方式做状态回验比较费劲。所以我设计了轻量 Agent 的模式。Agent 是一个部署在设备侧的小程序可以跑在一台能管理设备的跳板机上也可以跑在每台设备旁边的运维终端上。它不做决策只做三件事接收工作台下发的指令模板、执行前的本地确认、执行后的结果回传。工作台和 Agent 之间用加密通道通信跑在内网里不与外网有任何交互。Agent 相比直连最大的价值是隔离工作台不直接持有设备凭据凭据放在 Agent 侧Agent 只接受白名单范围内的命令模板超出范围直接拒绝每一步执行都有日志且支持按设备维度做并发限制。这样一来就算 AI 解析出错Agent 这层也能把风险拦截住。3.2 配置下发的四道闸门配置下发流程是这套系统最核心的环节我给它设计了四道闸门任何一道不过命令都不会真正到达设备。第一道是模板闸门。设备配置命令不是自由文本必须是预定义的命令模板比如将接口X加入VLAN Y对应一段固定结构。LLM 的作用不是发明命令而是从用户的自然语言里提取出设备、接口、动作、参数这些结构化字段然后去填充模板。假如用户说把核心交换机的上联口加个描述LLM 会提取出设备名、接口名、描述文本套到interface description模板里而不是自己编命令。第二道是参数校验闸门。提取出来的参数必须通过校验才能进入下一步。设备名要能在拓扑库里查到接口名要符合该设备型号的命名规范VLAN ID 要在合法范围内。这一步能拦住绝大多数模型幻觉问题比如 LLM 把接口名从 G1/0/5 识别成 Gi1/0/5从规范化角度这两个是同一个但要先通过正则将其转换为设备实际识别的格式。校验不通过就直接打回让用户重新描述。第三道是影响评估闸门。命令发出去之前先对照当前配置快照做影响面分析。比如要改某端口的 VLAN系统会先看看这个端口现在属于哪个 VLAN、是不是 trunk、有没有挂 ACL如果这个端口是上行口或者有特殊策略系统会提示该操作可能影响 xx 业务。影响评估不需要多高级的算法本质是配置基线比对加静态规则判断。第四道是人工审批闸门。这是最后一道也是最不可省略的一道。评估通过后系统会把将要执行的完整命令列表发给审批人也就是网工自己审批人可以在工作台界面上逐条查看、勾选、放行或拒绝。放行后 Agent 才会真正执行。整个审批过程有审计记录谁审的、什么时候审的、执行结果如何全部留痕。3.3 本地模型如何懂网络数据不出本机意味着 AI 能力必须跑在本地。我调研过几类方案最后用的是本地推理框架加载量化模型模型参数量不需要太大8B 级别在量化后跑在普通带独显的工作站上就能有不错的响应速度。如果机器没有独显CPU 推理也能跑只是延迟会高一些对变更操作场景来说几百毫秒和几秒的差别其实不影响因为真正的时延大头在人工审批环节。本地模型在项目里承担两个职责意图解析和知识问答。意图解析就是把用户的中文描述转成结构化参数这个任务对模型要求不高关键在于约束输出格式我用提示词把输出限制成 JSON 结构并在下游做严格校验。知识问答则是让网工可以用自然语言问某台设备的 xxx 接口为什么 down系统检索本地配置快照和监控数据组织成上下文喂给模型由模型生成回答。这里的上下文来源完全是本机的数据库和文件不涉及任何外部 API。为了让模型懂具体网络的细节我还给每个设备建了一份设备画像里面包含设备型号、软件版本、接口列表、当前配置摘要、邻居信息。模型回答问题时先通过向量检索找到相关设备画像片段再基于这些片段生成答案。这种方式比直接拿全网数据硬塞给模型更高效也更容易控制回答的准确性。4. 实操落地从零搭一个最小可用的 AI 运维工作台4.1 环境与模块划分这个项目我用了 Python 作为主语言原因很直接网络自动化生态最成熟netmiko、pysnmp、networkx 这些库都是现成的。整个系统按功能拆成了五个模块每个模块相对独立方便单独测试和替换。模块作用关键依赖采集模块通过 SNMP/SSH 采集设备信息pysnmp / netmiko / textfsm拓扑模块设备指纹识别、邻居关系建模、拓扑绘图networkx / 可视化库配置模块配置快照管理、基线比对、变更评估difflib / 本地存储Agent 模块命令执行、审批流、回滚加密通信 / 本地任务队列推理模块意图解析、知识问答本地推理框架 / 向量检索启动时先跑一次全量采集生成初始拓扑和配置基线之后可以设置定时增量采集比如每 30 分钟跑一次发现新设备就自动补进拓扑配置有变化就生成新的快照版本。4.2 拓扑发现模块核心代码拓扑发现的代码其实不复杂关键是处理好数据归一化。下面是我用的采集流程简化版# 拓扑自动发现核心流程简化示例 import netmiko from netmiko import ConnectHandler # 1. 通过 SSH 登录设备抓取 LLDP 邻居信息 def get_lldp_neighbors(device): conn ConnectHandler( device_typedevice[device_type], # 按实际厂商选择 hostdevice[ip], usernamedevice[username], passworddevice[password], secretdevice.get(secret, None), # 特权模式密码 ) # 不同厂商命令不同此处以通用方式示意 output conn.send_command(show lldp neighbors detail) conn.disconnect() return parse_lldp_output(output) # 用 TextFSM 或正则解析 # 2. 解析时统一成标准字段 def parse_lldp_output(output): neighbors [] # 提取 local_interface / remote_device / remote_interface # 省略具体解析逻辑核心是把非结构化文本转成结构化记录 return neighborsSNMP 侧的采集逻辑更直接用 pysnmp 去读 LLDP-MIB 的远程邻居表。核心代码思路是这样的from pysnmp.hlapi import * def snmp_walk_neighbors(ip, community): results [] iterator nextCmd( CommunityData(community, mpModel1), # SNMPv2c UdpTransportTarget((ip, 161)), ContextData(), ObjectType(ObjectIdentity(1.0.8802.1.1.2.1.4.1.1.7)), # lldpRemSysName 的 OID lexicographicModeFalse, ) for errorIndication, errorStatus, errorIndex, varBinds in iterator: if errorIndication: break for varBind in varBinds: results.append(str(varBind[1])) return results所有设备采集完之后用 networkx 建图把设备当节点、链路当边再根据 OUI 和 sysDescr 判断设备类型给节点打标签。最后把图数据序列化成 JSON 推给前端渲染。4.3 Agent 与审批流配置Agent 的核心是收到指令后先确认再执行。它的配置文件长这样白名单命令模板决定了它能执行什么# agent_config.yaml 简化示例 agent: device_credentials_path: /secure/credentials.json allowed_templates: - name: configure_interface_vlan command: interface {interface}; switchport access vlan {vlan_id} - name: configure_interface_description command: interface {interface}; description {description} - name: add_static_route command: ip route {network} {mask} {next_hop} approval_required: true max_parallel_tasks: 1 backup_before_change: true rollback_on_failure: true audit_log: /var/log/agent/audit.log审批流在工作台侧实现用户提交变更请求后系统生成一个变更单变更单里包含目标设备、前置状态当前配置快照、将要执行的完整命令列表、影响评估结果。审批人打开变更单逐条确认后点击放行命令才会推给 Agent。执行完成后Agent 回传执行输出系统自动抓取设备最新配置做差异比对如果发现执行后配置与预期不符自动触发回滚。这里有一个细节值得多说一句备份和回滚命令要提前放在模板里而不是执行完再临时想。比如备份用copy running-config startup-config加时间戳命名回滚用configure replace或直接加载变更前的配置文件。每家厂商命令不一样需要针对设备型号维护一套动作脚本但这个投入是值得的因为它能把误操作的恢复时间从小时级降到分钟级。4.4 前端展示与交互工作台界面我用 Web 方式实现不需要多花哨核心是三个页面拓扑页、设备页、变更页。拓扑页实时展示自动发现的结果支持点击节点查看设备详情点击链路查看两端接口和速率支持拓扑搜索和过滤。设备页按类型和位置分组展示所有纳管设备每台设备点进去能看配置快照历史、邻居列表、接口状态。变更页是审批的核心区域待审批的变更单会列在这里点开能看到完整命令和影响评估审批通过后流转到已执行状态。交互设计上我刻意做了一个约束所有变更类操作必须在变更页完成拓扑页和设备页只提供只读信息。这样做的目的是把看和改分离防止网工在浏览拓扑的时候手滑误触发变更。这个设计后来被证明非常必要有一次测试环境里我差点在拓扑页点了什么按钮触发批量操作后来发现交互入口根本不在这里才避免了一场事故。5. 常见问题与排查技巧实录这个项目从开发到内测踩过的坑不少我把典型问题和排查思路整理成一张速查表方便后续维护和扩展时参考。问题现象根因解决办法只发现了部分设备另一部分在拓扑图上消失SNMP community 权限不够读不到邻居 MIB先用 SSH 补采确认设备在线再调整 SNMP 只读视图范围或直接改用 SSH 采集LLDP 邻居表有数据但解析出来是乱码不同厂商对 LLDP 描述字段的编码实现有差异对描述字段做编码归一化统一转成 UTF-8同时保留原始文本作为兜底ARP 表把大量终端 IP 也当成网络设备没有区分交换机/路由器和终端设备结合 sysObjectID 和 OUI 库综合判断只把具有转发能力的设备纳入拓扑节点终端类节点折叠到接入交换机Agent 连接工作台经常断线网络隔离策略限制长连接改用带外管理网部署 Agent或在工作台侧配置心跳重连机制模型把接口名识别错了不同型号接口命名规则差异大模型没有被约束在模型输出后加一层接口名规范化模块用正则和型号规则库做二次校验不匹配就打回重提批量执行时设备 CPU 飙高同时登录多台设备执行命令通过 Agent 的 max_parallel_tasks 参数限制并发同时把执行队列改为串行配置回滚失败设备处于异常状态无法正常加载配置回滚前先检测设备可达性和状态失败时保留现场日志并发出人工介入告警排查技巧方面我最想强调的是日志先行。Agent 执行每一步都要写审计日志包括收到什么指令、校验结果、审批人、执行输出、执行耗时、回滚动作。很多问题初看诡异翻日志发现是某个字段在传输过程中被截断了或者某个设备型号的模板没覆盖到。日志是定位问题的第一手材料务必要完整。另外拓扑发现模块要支持局部重扫的能力。不用每次全量扫描当在拓扑图上新增一台设备时只对这台设备及其邻居做增量采集速度更快对设备的影响也小。全量扫描可以放到夜间低峰期定时执行。6. 后续可以往哪些方向扩展工作台目前已经能解决拓扑可视 受控变更这个核心闭环但用了一段时间后我明显感觉到还有几个方向值得继续做。一个是配置合规基线。可以把企业内部的配置规范比如密码策略、SNMP community 复杂度、禁用明文协议变成自动检查规则定期对全网配置做基线比对发现不合规项主动提醒。这个其实不难因为配置快照已经全量存下来了跑规则分析就行。另一个是故障定位辅助。结合拓扑和实时状态当某条链路 down 的时候可以自动做影响范围分析列出下游受影响的设备并给出先查哪台、再查哪台的建议路径。对于大型网络这个价值是实打实的。还有一块是变更窗口管理。实际运维里很多变更只能在工作时间窗口做工作台可以加一个变更计划功能先录入变更内容和窗口时间到点自动执行并把执行结果和期间产生的告警关联起来方便事后复盘。最后拓扑图如果能自动和 CMDB 做联动把资产编号、负责人、维保信息挂到对应设备节点上网工在做变更评估的时候就能直接看到这台设备是谁负责的、上次变更是什么时候信息完整度会大幅提升。我在实际使用中最大的体会是AI 运维工作台的定位不该是替代网工而是给网工配一个靠谱的助手。拓扑自动发现解决的是信息缺失问题受控 Agent 解决的是操作安全问题数据不出本机解决的则是信任问题。这三者缺一不可少了任何一块这个工作台要么变得不可靠要么变得不敢用。如果你也在琢磨网络自动化这件事建议先别急着堆功能把数据从哪来、操作怎么控、出错了怎么恢复这三件事想明白再动手不迟。