网络运维这行有大把时间不是花在解决故障上而是花在搞清楚网络现在长什么样上。我自己被这几件事折磨过拓扑图画到一半发现设备早就换了型号巡检要登录几十台设备抄同样的命令排障时在核心、汇聚、接入三层界面之间来回跳。后来我给手里的运维工作加了AI能力但真正卡住我的不是AI精度而是数据能不能出去。最终做出来的方案是一个完全本地运行的AI运维工作台拓扑自动发现、受控Agent下发配置、本地模型解释回显所有数据不出本机。这篇文章把架构、落地细节和踩坑过程完整说一遍适合正在被重复运维动作消耗时间的网工参考。1. 网工的日常里哪三件事最该被自动化1.1 最耗时间的不是故障是搞清楚网络现状大多数网络不是没有拓扑图而是拓扑图永远比现实慢半拍。交接时拿到的图纸可能是两三年前的设备型号、VLAN划分、互联地址全对不上号。新来的网工只能自己重新摸方法也很原始一台台登录设备看邻居表、看路由表、看接口配置再手工往画图工具里拖节点、连线。这套操作熟练的人来做几十台设备也得花上大半天中途接个电话、改个工单回头就得重新核一遍。拓扑这东西一旦没人专职维护很快就变成一张仅供参考的旧地图。巡检就更不用说了它是网络运维里最典型的重复劳动。每周登录几十上百台设备执行同一批命令人眼扫输出里有没有异常。不同厂牌的命令风格还不一样有的叫show有的叫display有的严格区分大小写有的又完全不区分。即便有人已经写了脚本做批量回显一旦要按设备差异调整命令脚本的维护成本立刻上来。我见过很多网工的电脑里存着几十个半成品的脚本每个脚本只适配某一种设备换一批设备就废了。排障场景是第三个痛点。用户报告某块网络慢网工的第一反应是翻自己的IP地址表然后从接入层往核心一层层登录试探。跨设备跳转的代价是每个上下文都要重新建立命令历史互不相通查过的接口状态、路由条目只能在脑子里临时记着。排查链路越长漏掉中间节点的概率越高最后经常是绕了一大圈才发现是某个上联口的错误包在涨。这三件事的共同点很明显高频、重复、有明确规则。它们不考验网工多聪明只考验谁更耐得住性子。可过去没有人把它们收拢到一个工作台上因为要做这件事你得同时解决设备交互、数据建模、命令适配三个问题。另一个让网工犹豫的问题是AI在线AI确实能帮忙翻译命令、解释回显但网工手里的设备清单、IP段、型号组合、链路矩阵合起来就是一张网络地图。把这张地图发给任何在线服务都要承担不可控的泄露风险。所以能用AI和敢用AI之间差的就是一套本地方案。1.2 工具要解决的是把网工从人肉采集器里解放出来想清楚这一点之后我给这个工作台定的目标就非常朴素拓扑不要手工画设备不要逐台登AI可以参与但设备只认受控的Agent所有采集与配置数据只在本机落地。后面的所有设计都是围绕这三条线展开的。2. 本地优先的整体架构设备、Agent、工作台三者怎么咬合2.1 数据链路上的三条边界这套系统的数据链路并不复杂但每条边界都是刻意设计的。设备侧只有一条入口Agent。Agent是唯一能主动连到网络设备的程序它通过SSH登录设备执行命令把回显原样拿回来。Agent本身不能编排命令它只接收来自本地工作台服务的指令执行完把结果返回自己不留存任何敏感数据。第二层是工作台服务。它跑在网工的管理机或者内网一台普通服务器上负责调度Agent、存储拓扑数据、管理设备凭证、记录操作审计、提供本地Web页面。所有采集到的配置回显、拓扑关系、审计日志都写进本机的数据库里不对外提供任何公网回调。第三层是本地推理引擎也就是跑在本地的大模型。它负责把自然语言翻译成候选命令、把设备回显翻译成自然语言、基于拓扑数据做故障推理。模型权重从本地磁盘加载推理请求走本机接口整个过程没有任何请求发到外网。这三条边界合在一起就实现了数据不出本机设备不会主动外联Agent不落地数据工作台服务不暴露公网模型天然离线。网工手里那份最值钱的网络地图始终留在自己的磁盘上。2.2 为什么没有做成传统网管平台一开始也有人问我这不就是网管平台吗还真不是。传统网管平台的核心是SNMP轮询加集中告警它是用来盯网络的。它的拓扑通常靠MIB里的接口和邻居表自动生成但生成出来的拓扑往往缺二层细节对链路聚合、双上联这类常见场景处理得很粗糙。更关键的是网管平台普遍不擅长干活——你很难在它上面做一次受控的配置变更更难让AI参与命令生成和回显解读。我要做的是一个干活辅助工作台不是监控系统。它不需要7x24小时盯着所有设备的CPU和内存它需要的是网工说一句看看核心交换机的CPU趋势它能自动生成采集命令并执行网工想改一组接口配置它能先备份、再预检、最后让人确认。监控可以继续用现有平台工作台专注在运维操作的效率提升上两者互补不抢地盘。2.3 模块划分与权限收口实现上我把它分成三个独立进程互不混跑。Agent进程可以部署在能管理到网络设备的跳板机上也可以和管理服务跑在同一台机器通过本地IPC通信。工作台服务是心脏所有业务逻辑都走它。本地模型进程只做推理不碰设备凭证。权限收口是另一个我花了不少时间的地方。设备凭证统一由工作台服务加密保管Agent在需要执行命令时才拿到一次性会话执行完立即失效。模型进程完全接触不到凭证它只能看到被脱敏后的设备标识和回显。这样即使本地模型被意外诱导出奇怪内容也拿不到任何能直接登录设备的凭据。3. 拓扑自动发现从LLDP邻居到一张干净的二三层地图3.1 邻居发现拓扑的第一张草稿自动发现的第一步一定是邻居发现。标准做法是优先开启LLDP链路层发现协议通过SNMP去读设备的LLDP邻居表OID大致落在lldpRemTable那一组里。一次读取就能拿到本端设备本端接口远端设备远端接口的完整对应关系这是最干净的直连链路数据源。但现实里不是每台设备都给你开好LLDP有的老交换机默认关着这个功能有的只开了厂家的私有邻居发现协议还有的堆叠设备会把多个成员口上报成同一个逻辑口处理起来有些麻烦。我的做法是分级探测。第一优先LLDP读到邻居表直接用。第二优先兼容私有邻居发现协议老设备里这一项能补上不少缺口。第三优先退到MAC地址表交叉推断给交换机下发一条查MAC表的命令收集所有学习到的MAC地址与端口对应关系然后拿两台设备的接口列表做交叉比对——如果交换机的某个端口和另一台交换机的某个端口都出现过同一批MAC基本可以判定它们之间是直连。这个方案不够完美但在LLDP被禁用、又没有私有协议兜底的老网络里它是最后一根救命稻草。3.2 二三层拓扑合并与链路清洗邻居发现拿到的是二层物理链路但网工看拓扑时还需要知道三层网段关系。我在同一张图上做了三层叠加通过路由表和ARP表推导设备之间的三层互联网段再把每条二层物理链路映射到对应的网段上。画出来的图既有物理连接也有逻辑网段排障时一眼就能看出某条业务流量实际经过了哪些设备。链路清洗是整个发现过程里最影响观感的一步。最开始跑出来的拓扑惨不忍睹两台设备之间因为做了链路聚合画出了四五条平行线同一条物理链路因为LLDP和MAC表两种方式重复识别被画了两次还有些设备上报了奇怪的邻居关系拓扑图上凭空多出一条根本不存在的环路。我在清洗阶段做了三件事按聚合组把成员口合并成一条逻辑链路按设备对去重同一对设备之间只保留一条最可信的链路保留可疑环路并高亮让网工人工判断不直接抹掉。3.3 持久化与增量发现拓扑不能每次重新全量跑那样既慢又容易抖动。我把发现结果写进本地数据库设备信息、链路信息、历史快照各一张表。首次全量扫描之后后续用增量发现兜底新设备上线、配置变更触发一轮局部重扫把变化的节点和链路更新进去。每晚再自动跑一次低频全量校准拓扑图就能长期保持在一个可信状态。这里还有个额外收益因为每天都有拓扑快照哪天网络里被插了一台未知设备或者有人改了一条关键链路对比快照就能立刻看出来。这个能力在手工画图时代几乎不可能实现。4. 受控Agent下配置给AI配一副刹车而不是一个裸终端4.1 受控到底控制哪些事标题里受控Agent不是噱头它是我整个设计里最要紧的一层。受控有三个维度。第一是命令白名单读类命令比如查看运行配置、查看接口状态、查看路由表Agent允许自动执行。变更类命令比如进入配置模式、修改接口参数、保存配置必须经过人工审批。高风险命令比如删除VLAN、清空配置、重启设备、关闭接口必须双重确认。第二是厂商语法适配Agent内置了一套命令模板按设备型号匹配对应的命令风格AI生成的命令在到达设备之前必须过一遍语法模板校验命令里的参数与设备实际支持的规格对不上直接在预检阶段拦下。第三是目标范围限制Agent永远只对工作台指定的一台或一组设备执行命令不允许泛执行、不允许遍历。这样设计的目的很简单Agent可以非常勤快但它的每一次动作都被约束在网工能接受的规则内。它不是一个裸终端而是一个戴着镣铐的执行器。4.2 一次配置变更的标准流程我拿一个常见场景举例把一批接入交换机的接口速率和双工模式从自动协商改成固定百兆全双工。整个流程在界面上看起来是几步但Agent在后台做了大量工作。第一步网工在对话框里输入目标AI或模板引擎把它转成候选命令。第二步Agent先自动备份当前配置然后做预检检查目标设备型号、命令语法、接口是否真实存在、改完后会不会影响当前管理会话。预检通过后工作台弹出变更预览把将要执行什么命令、影响哪些接口、备份结果如何全部摊开。第三步网工确认Agent执行命令执行完立刻再采集一次配置做diff确认结果符合预期。第四步如果diff发现配置没有变成预期值Agent自动回滚到之前备份的配置并在审计日志里记录一次失败变更。这个流程里Agent用的是命令模板不是AI自由发挥。模板的好处是可维护、可解释、可测试。命令模板大致长这样tasks: - name: 修改接口速率双工 device_group: access-switches precheck: - show interface status - show running-config interface interface commands: - interface interface - speed 100 - duplex full postcheck: - show interface interface rollback: restore from pre-change backup risk_level: medium4.3 为什么AI永远不直接执行配置这个问题我反复想过。技术上让AI直接登录设备、直接敲命令完全做得到但我从一开始就否掉了这个方向。原因有三个。第一网络设备没有事务回滚命令敲错一步影响面可能是整段业务普通事务机制在真实网络里救不回来。第二大模型有幻觉它可能一本正经地生成一条设备根本不支持的命令也可能漏掉一条必要的前置命令。让它直接操作等于把一个没有执照的实习生扔进机房。第三是责任边界运维操作需要一个明确的审批人自动执行一旦出问题定位和追责都变成一团乱麻。所以我的结论是AI可以做翻译、做解释、做建议但永远不碰执行键。执行键只属于受控Agent审批键只属于网工。这套AI建议、Agent校验、人审批的铁三角既保留了AI的效率又把安全边界画得清清楚楚。5. 本地模型的接入方式AI怎么翻译、怎么解释、怎么被拦住5.1 本地模型的选型原则模型选型上我没有追大参数。在管理机这种环境里跑一个几百GB的大模型不现实推理速度也扛不住。我的原则是能本地跑、能密集推理、能输出结构化结果。量化后的中等尺寸模型足够用7B到13B这个区间是性价比最高的档位显存占用量在可控范围内CPU也能凑合推理只是慢一些。真正重要的不是参数大小而是模型要支持工具调用和结构化输出这样它才能按工作台定义的格式返回命令候选和诊断结果而不是自由发挥写一大段散文。因为模型是本地加载每次启动的加载时间我能接受但推理时最好用流式输出界面响应会好很多。实测下来处理一条回显解读请求大约几秒完全在可用范围内。5.2 AI在链路里做的那三件事第一件事是自然语言到候选命令的翻译。网工不用再记某设备家族的命令风格直接说需求模型把需求映射成候选命令然后交给Agent的白名单和语法模板校验。这一步的价值在于降低多设备命令差异的学习成本而不是替代网工懂命令。第二件事是设备回显翻译。show interface的输出、日志里的报错模型把它转成自然语言指出这个接口的错误包在持续增长或者这条路由没有生效。第三件事是故障诊断建议。工作台会把脱敏后的拓扑摘要和设备状态摘要喂给模型模型基于这些真实数据给出排查路径而不是凭记忆瞎猜。这三个功能合在一起一个典型的使用场景是这样的网工输入为什么某个区域网络慢模型看到拓扑里这个区域的所有流量都汇聚到一台接入交换机而这台设备最近的接口利用率已经接近饱和于是给出建议先查这台设备的上联口再看是不是有广播风暴。网工点同意Agent执行查询命令回显回来再喂给模型解释整个排查闭环在工作台内完成。5.3 防幻觉的三层闸门本地模型同样会幻觉这点我不抱幻想。所以我在设计里硬性塞了三层闸门。第一层是工具调用限制模型能调用的只有工作台暴露的几个只读工具比如查询拓扑、查询设备状态、生成命令候选它没有任何渠道直接执行或修改网络。第二层是Agent校验兜底模型生成的每条命令候选都要过白名单和语法模板非法命令直接丢弃这条我在测试里拦下过不少次幻觉后面细说。第三层是引用约束模型输出的诊断结论必须引用真实数据证据比如明确的设备名、接口名、数值如果它给不出证据这条回答会被标记为低可信度不会直接展示给网工作为结论。这样折腾下来模型在里面的角色更像一个懂网络、会查资料的分析师而不是拍脑袋下结论的预言家。6. 实测数据与踩坑记录自动发现在真机环境里的表现6.1 测试环境与实测数据我在一套模拟三层办公网的环境里做了验证核心层2台设备汇聚层4台接入层34台加起来40台设备。链路包含不少常见坑点有链路聚合、有双上联、有两台老设备没有开LLDP、还有几条跨设备的互联没有按规范命名。第一次全量自动发现在只开SNMP只读、LLDP未完全开启的条件下跑完一遍大约用了十几分钟。生成的拓扑经过清洗后直连链路的准确度维持在较高的水平剩下几条可疑环路被标出来人工核对很快确认是测试环境里故意保留的冗余线路和异常跳线。巡检采集的对比更直观。之前手动登录40台设备做一轮基础巡检快的话也要一两个小时中间还容易漏设备。用工作台批量执行几分钟拉完全量回显输出按设备归档好模型再把异常项标注出来。这个时间差对日常运维的意义不需要我做太多解释。6.2 五个印象最深的坑坑现象根因处理方式LLDP未全局开启很多设备发现不到邻居组网默认配置没开LLDP分级探测先LLDP再私有协议再MAC表交叉推断SNMP权限过宽用读写串做发现风险高设备上沿用旧配置随便给读写串发现只用只读串读写串一律不收进系统聚合链路重复线一对设备之间画出多条平行线聚合组成员端口被当作独立链路按聚合组合并成一条逻辑链路模型幻觉命令模型生成设备根本不支持的参数小模型记错厂商命令行细节Agent语法模板预检拦截AI生成永远不直达设备批量执行把设备CPU打高低端接入交换机批量查询时负载突增并发线程开得太大并发数压到个位数按设备分组慢速执行其中模型幻觉命令这个坑我必须多写几句。它出现在一次测试里网工问查一下接口下错包计数模型生成了一条厂商A风格的命令但目标环境里有一部分设备是厂商B命令经过了语法模板校验参数格式并不支持在将要执行前被Agent拦了下来。这次拦截让我彻底坚定了AI建议、Agent执行的分层设计如果当时让AI直接连设备敲命令这条命令大概率会报错报错还是小事怕的是它生成一条语法正确但语义错误的命令比如把接口shutdown了那影响就大了。6.3 还能往哪走做完这版之后我脑子里其实已经堆了不少后续方向。比如配置备份可以做成每日自动下载配合拓扑快照做配置变更影响面分析再比如把链路聚合的成员口健康度合到一起展示双上联的故障切换成功率也可以做成一个独立视图还可以把整套东西扩展成模板化批量执行但要保留逐台确认机制方便一次性给一批接入交换机做安全加固。我在实际项目里最深的一个体会是运维AI要解决的不是AI有没有能力而是能力的边界怎么划。自动发现拓扑、Agent受控执行、本地模型解释回显这套组合真正解决了我的日常重复劳动。把重复留给工具把判断留给人这大概是运维工作台最正确的打开方式。后面如果你也打算搭一套类似的本地工具建议先把哪些命令可以自动跑、哪些必须让人确认这个边界定清楚再谈AI接入顺序不能反。