凌晨两点半，朋友打电话说核心业务全部断网。最终定位的原因是前一天的配置变更里，有人把接口的switchport mode access写错了，导致上联链路被阻塞。一台设备、一行命令、一个深夜，整个部门都在机房吹冷风。这种场景对干网络的人来说太熟悉了——网络永远不是被复杂故障击垮的，而是被随手一条命令坑死的。
就在那个月，我给他做了个 AI 运维工作台。核心就三件事：拓扑自动发现、受控 Agent 下配置、数据不出本机。拓扑让网络不再是黑盒，Agent 让每一次变更都有审批和审计，AI 只在本机跑，配置文件和路由表永远不离开内网。
这东西不是企业级大平台的替代品，而是给每天守着几台到几百台设备的网工，提供一个能跑在自己笔记本或内网服务器上的底座。我把完整的思路、代码结构、踩过的坑全部整理了一遍，分享给同样被网络运维折腾过的朋友。
1. 项目背景与整体设计思路
1.1 网工的真实痛点：黑盒网络和背不完的命令
很多传统网络运维团队的真实状态是：全网只有一两个人知道设备怎么连的，拓扑图是几年前的 Visio，上面标注的 IP 和实际查出来的完全对不上。新来的工程师接手时，只能拿着一台笔记本到机房一根线一根线地捋。更难受的是，设备密码散落在各个 EXCEL 里，有些甚至是明文。
我一开始想做的是个"网络资产管理工具"，后来发现单纯做资产意义不大——你有一堆设备清单，但不知道设备之间怎么连、链路状态如何、改了配置影响多大，这依然是个死清单。真正有价值的是那张"活"的拓扑：哪个交换机下接了哪些终端、哪条链路在跑关键业务、谁跟谁是冗余关系。有了这张拓扑，配置变更才谈得上"影响面评估"。
这个工具适合的人群也很明确：管着几十台到几百台网络设备的工程师、需要给团队搭一个可视化运维底的个人开发者、以及被手工登设备改配置折磨得想辞职的同行。
1.2 为什么是拓扑自动发现 + 受控 Agent，而不是全自动无人值守
聊自动化的时候，很多朋友第一反应是"全自动"。我在设计时反复权衡过：对网络设备做全自动变更，在中小规模网络里是极度危险的事情。设备型号杂，命令语义不统一，有些老设备连条件回滚都不支持，一个语法错误就可能让整个交换机的业务中断。
所以我定的原则是：发现自动化，变更受控化。
发现链路用"尽力而为"的策略，通过 LLDP、SNMP 等多数据源交叉验证，把物理拓扑找出来。变更链路则走"受控 Agent"——每一条命令的生成和执行，都要经过任务校验、权限检查、人工审批。说白了，机器负责干苦力活（采集数据、跑脚本、生成建议），但最终敲回车之前，必须有人确认。
这个思路比较像辅助驾驶而不是无人驾驶：系统帮我观察路况、提醒风险、规划路径，但关键时刻控制权始终在人手里，出了意外人能够随时接管。
1.3 整体架构与数据流
工作台的架构分五层，我简单画了个文字版：
- 采集层：SNMP、SSH、NETCONF 等协议适配器，负责从设备上拿拓扑邻居、接口状态、配置文本
- 数据层：本地 SQLite（或本地 MySQL），存设备信息、拓扑边、配置基线、审计日志
- 控制层：任务管理、审批流、工单记录、回滚机制，负责把"变更"这件事规范起来
- Agent 层：跑在内网跳板机或管理服务器上的轻量级执行体，接收控制层指令并操作目标设备
- AI 层：本地推理服务，负责配置命令解析、日志异常检测、变更影响面预测
数据流大概是：采集层定时把拓扑数据入库 → 拓扑展示层从数据库读节点和边 → 网工发起变更任务 → 控制层记录工单并生成命令模板 → Agent 去目标设备执行 → 回显落库并触发后检 → 全链路审计。
很多刚开始接触这类系统的朋友会误以为 Agent 必须装在交换机上。实际上不用，Agent 只需要跑在一台能 SSH 到网络设备的管理机上，它相当于一个"受控的钥匙串"，负责替你去按设备上的按钮。
2. 拓扑自动发现：把散落的邻居关系拼成一张网
2.1 LLDP 还是 SNMP：协议选型背后的思路
拓扑发现的核心是搞清楚一件事：谁连着谁，哪个口连着哪个口。
最常用的协议是 LLDP（IEEE 802.1AB），它让设备主动向邻居通告自己的身份、端口、系统名，默认 30 秒发一次。这个协议的好处是跨厂商兼容性极好，华为、思科、锐捷、H3C 都支持。操作上执行一条show lldp neighbors，就能看到邻居的设备 ID 和端口。
但只靠 LLDP 有坑：部分老设备默认只开了全局 LLDP，接口层面没启用；还有些设备（比如某些三层交换机默认配置）直接把 LLDP 关了。遇到这种情况，就要靠 SNMP 兜底——通过读取 LLDP-MIB 或 Bridge-MIB（二层转发表）来补全拓扑关系。
我在设计时做了一张对照表，帮助自己判断选用哪种协议：
| 数据源 | 能拿到什么 | 适用场景 | 限制 |
|---|---|---|---|
| LLDP | 物理链路邻居、端口 ID、系统名 | 大多数主流设备 | 设备必须开启 LLDP |
| CDP（某厂商私有） | 邻居设备信息 | 老旧的某系设备 | 非标准协议，跨厂商受限 |
| SNMP Bridge-MIB | MAC 地址表、端口转发表 | 推断二层拓扑 | 无法拿到完整设备身份 |
| 路由协议邻居 | OSPF/BGP 邻居关系 | 验证三层链路 | 只覆盖路由设备 |
| ARP 表 | IP 与 MAC 映射 | 辅助端点定位 | 无法直接表示物理拓扑 |
我的经验是三层数据源交叉验证：LLDP 为主，SNMP 为辅，ARP 和路由表补齐缺口。只信单一数据源一定会出大问题。
2.2 采集流程：从种子设备开始 BFS 遍历
拓扑采集的实现方式是从一台种子设备开始，宽度优先遍历整个网络。
具体流程是这样的：先从种子设备采集 LLDP 邻居，拿到邻居的设备标识和端口信息；然后对每个邻居执行同样的操作，直到没有新设备出现。整个过程类似在地图里从一个城市出发，沿着每条高速公路访问每个城市，再继续深入。
每台设备的采集动作我封装成三个函数：
get_lldp_neighbors(device)：SSH 登录执行show lldp neighbors detail，或通过 SNMP 读取 LLDP MIBget_snmp_bridge_table(device)：读取 MAC 地址转发表，用来补全未启用 LLDP 的二层路径get_device_info(device)：读取系统名、型号、序列号、接口列表，丰富节点属性
SNMP 指令大概是这样的（用的是标准 OID）：
# 读取 LLDP 远程设备 ID snmpwalk -v2c -c public switch 1.0.8802.1.1.2.1.4.1.1.5 # 读取 LLDP 远程端口 ID snmpwalk -v2c -c public switch 1.0.8802.1.1.2.1.4.1.1.7如果设备支持有限，还可以用 SSH 执行show lldp neighbors detail然后解析文本。实际开发时我建议两种方式都保留：SNMP 适合批量采集，SSH 适合细粒度信息和 SNMP 被禁用的环境。
2.3 拓扑图的生成与展示：从数据库到画布
拓扑数据入库时，我把网络建模成图结构：节点是设备，边是链路，链路的属性包含两端端口、VLAN、速率、状态。
数据库设计上，我用了一张devices表存设备信息和一张links表存链路关系。数据量通常不超过 1000 台设备，这样的规模用关系型数据库完全够用，没必要上专门的图数据库。图数据库听起来高级，但对这种规模反而是负担。
前端展示用了可拖拽的画布组件，初始布局用力导向算法自动排列，工程师可以手动调整位置。点击一台设备可以看到详细信息、邻居列表、配置变更历史；点击一条链路可以看到端口状态、流量趋势和关联的 VLAN。
有一点值得提醒：自动布局永远不可能完美。办公楼的拓扑通常天然分层——核心层、汇聚层、接入层——手动按层整理之后比任何算法都清楚，所以一定要支持"手工拖拽 + 坐标持久化"。
2.4 实测中常见的拓扑失真问题与对策
做拓扑发现最怕的不是没有数据，而是数据失真，画出来的拓扑和物理现实对不上。我总结了四个高频问题：
第一，链路聚合的重复上报。Port-channel 把多个物理口绑成一个逻辑接口，LLDP 查询时会报出多条相同的邻居关系，必须做聚合合并，否则拓扑图会出现一堆平行线。
第二，堆叠系统的识别。几台交换机做了堆叠，在 LLDP 里对外显示为一个 chassis，实际上内部包含多个成员设备。拓扑展示时要把堆叠成员拆开或者合并，避免一张图里出现怪异的环。
第三，跨三层设备的发现盲区。路由器或防火墙的接口对 LLDP 透传支持比较弱，很多时候只有直连邻居信息没有二层信息。这时要靠 OSPF 邻居表和 ARP 表补全，才能把三层链路画出来。
第四，无线终端的归属。AP 的上联链路可以通过 LLDP 发现，但无线终端不存在物理网线，拓扑图不会显示它们。对大多数运维场景，画到"接入交换机 + AP"这一层就足够用了，不需要追踪每一台手机。
3. 受控 Agent：配置下发的"授权与执行"分离
3.1 为什么不能直接写脚本循环 SSH
最早这个项目我也走了弯路：直接在管理机上写了个 Python 脚本，循环登录所有设备，批量执行命令。看起来挺爽，三个致命问题很快暴露：
账号密码硬编码在脚本里，谁拿到脚本谁就有全网设备的 root 权限；执行过程没有任何审计，出了问题不知道是谁在什么时候跑了哪条命令；没有回滚机制，手误把接口 shutdown 之后找不到原来的配置。
这就相当于给每个人都发了一套机房万能钥匙，但机房没有监控也没有门禁记录。
受控 Agent 的核心思路是"授权与执行分离"：Agent 本身持有执行能力，但能不能执行、执行什么命令，由中央控制台决定。网工发起任务，控制台做权限校验和审批流转，Agent 才去目标设备上执行。整个过程像一个门禁系统：刷卡进门、楼层受限、核心机房还要二次审批、全程摄像头录像。
3.2 Agent 的任务模型：Job 驱动的执行链
我把 Agent 收到的所有指令统一封装成 Job，结构大概是这样的：
{ "job_id": "20250228-001", "ticket_id": "CHG-2025-0042", "device": "10.10.4.2", "device_type": "huawei", "operation": "execute_commands", "commands": [ "system-view", "interface GigabitEthernet0/0/1", "description To-Core-SW01-Port47", "commit" ], "risk_level": "medium", "require_approve": true, "signature": "HMAC-SHA256(sha256(commands_json)+timestamp)" }Agent 的工作流程是：
- 从控制台拉取待执行 Job，并验证 HMAC 签名
- 从本地密钥库申请目标设备的临时凭据，凭据不落盘
- 通过 SSH 或 NETCONF 连接设备
- 执行命令，处理分页和设备提示符
- 收集回显和状态码，返回控制台
关键设计点是 Agent 不能主动执行命令，只能执行控制台下发的、签名合法的 Job。哪怕有人黑进了 Agent 所在的服务器，也拿不到设备明文密码，因为凭据是通过加密令牌临时申请的，用完即失效。
3.3 命令白名单与高危命令双重审批
受控 Agent 的"受控"不能只停留在理论层面。我实现里加了三道闸：
第一道，命令白名单。控制台维护一个命令模板库，只有模板里出现的命令才允许执行。自由命令会被拒绝，需要管理员单独开权限。
第二道，高危命令拦截。系统内置一个高危命令清单，比如删除 VLAN、关闭接口、恢复出厂配置、重启设备等。凡是命中清单的命令，必须由第二个人在界面上点确认，否则 Job 停在"待审批"状态。
第三道，关键变更双人复核。命令执行前，系统会把将要执行的完整命令列表展示出来，要求审批人逐条确认。审批不是走过场，而是要真正看明白每条命令的影响面。
后来我把这套逻辑复用到了很多场景，包括配置变更和巡检任务，效果很好。有些朋友问这会不会拖慢操作节奏，我的经验是：对于低风险只读命令（比如show），完全不需要审批；只有真正触碰设备配置的命令才走流程，影响面很小。
3.4 变更前备份、变更后回滚的落地细节
配置变更最怕的是执行完发现业务异常，想回滚又找不到原配置。我的实现策略非常简单粗暴：执行任何写命令之前，Agent 先把当前设备的 running-config 完整备份到本地，并记录备份文件哈希。
具体流程是：
- 备份阶段：关闭设备分页（terminal length 0），执行
display current-configuration（或show running-config），把完整配置写入本地文件 - 变更阶段：按 Job 中的命令逐条执行，每执行完一条记录回显
- 后检阶段：再次执行状态检查命令（比如接口状态、OSPF 邻居、路由表），与变更前快照比对
- 回滚阶段（仅在异常时触发）：将备份配置通过配置替换能力推回设备，或者进入配置模式删除错误配置后重新粘贴备份内容
回滚操作最坑的一点是：有些设备不支持直接覆盖配置，必须先全量清空再恢复，这个过程中网络必然中断。所以我的建议是，不是所有变更都值得自动回滚——如果只是改错一个接口描述，反而不回滚更稳妥；只有核心链路断了、路由挂了这种级别人为介入还不够快的故障，才动用回滚脚本。
4. 数据不出本机：本地模型与隐私边界
4.1 为什么强调数据不出本机
网络设备配置文件里有什么？地址规划、接口 IP、路由策略、安全过滤规则、账号口令哈希，甚至还有网络管理员自己都忘了的远程登录凭据。这些数据本质上是一张完整的网络作战地图，任何泄露都等于把核心基础设施的设计图送到陌生人手里。
一些在线 AI 分析工具确实方便，但把配置文件粘贴进去，等于把办公楼安保系统的核心图纸给外包公司看了一遍。真的有同事遇到过，把脱敏后的配置传上去，发现关键信息还是被隐去了很多，分析结果反而没参考价值。这给我提了个醒：自建工具链，数据边界完全由自己掌控，才是真正的信任基础。
"数据不出本机"落地起来分三层：采集的数据不出内网、AI 推理任务不离开本机、审计日志只落在本地存储。三层缺一不可。
4.2 本地 AI 能力如何落地：不只是"跑个大模型"
做 AI 运维工作台，我的原则是：能用规则解决的问题绝不上大模型。
端口 CRC 错包、接口反复 flapping、CPU 突高，这些用阈值和规则判断又快又准，完全可以本地跑。AI 主要负责三件事：配置文本解析（把命令转成结构化对象）、日志异常聚类、自然语言解释设备状态。
本地模型我选择的是开源小模型量化方案，把模型转成 ONNX 或用 GGUF 量化到 8bit，跑在一台 16G 内存的旧服务器上也能接受。效果肯定不如云端大模型，但胜在数据全程不离开内网，而且推理过程可控，没有未知的第三方介入。
实际使用中，配置解析的场景占了 80%。例如输入一段 OSPF 配置，模型输出结构化的 JSON：进程号、网段、区域、邻居关系。这部分如果靠正则表达式写，每个厂商的语法都要单独适配，维护成本极高；用小模型做文本理解，泛化性好很多。
4.3 本地推理的算力约束与应对策略
本地跑模型的代价是算力有限。我在架构上做了几个妥协：
- 优先用传统程序处理结构化采集。比如从设备抓回的
display ip routing-table，直接正则解析比让模型读文本快一百倍 - 模型只处理"自然语言任务"和"语义模糊任务"。那些有明确格式的数据，绝不交给模型
- 控制上下文长度。本地模型对长文本处理能力弱，我先把原始日志做聚合，比如把重复的报错合并成一条带计数的记录，再把压缩后的内容送给模型分析
坦白讲，这个设计注定不是"全自动驾驶"，而是"一个懂网络的助手"。模型给出解释和建议，工程师做最终判断，这恰恰是最安全的组合。
5. 实操与核心环节落地记录
5.1 从零打通第一台设备的拓扑采集
我一般会建议新上手的伙伴先用一台交换机试水，而不是一上来就纳管全部设备。第一步配置 SNMP 只读和 LLDP 开启：
# 以某厂商设备为例 snmp-agent snmp-agent sys-info version v2c snmp-agent community read public lldp enable然后在管理机上测试：
snmpwalk -v2c -c public 10.10.4.2 1.0.8802.1.1.2.1.4.1.1.5如果返回邻居设备 ID，说明设备和管理机之间通信正常。再用 Netmiko 这类 SSH 自动化库执行命令：
# Python 伪代码示意 from netmiko import ConnectHandler device = { "device_type": "huawei", "host": "10.10.4.2", "username": "admin", "password": get_secret_from_vault("10.10.4.2"), } conn = ConnectHandler(**device) output = conn.send_command("display lldp neighbor brief") print(output) conn.disconnect()第一次跑通这个流程时，那种"终于不用一条条手工敲命令"的感觉，确实很提气。
5.2 Agent 执行体的关键实现
Agent 端采用 Python 实现，核心是任务循环和 SSH 交互。任务循环的伪代码思路：
while True: job = fetch_job(api_server=LOCAL_CONTROL_PLANE) if not job: sleep(POLL_INTERVAL) continue if not verify_signature(job): reject_job(job.job_id, reason="签名校验失败") continue execute_with_rollback(job)执行部分有个容易踩的坑：设备回显分页。很多设备默认输出超过一屏会中断，等待用户按键。解决办法很简单，SSH 登录后先执行screen-length 0 temporary（华为）或terminal length 0（思科系）关闭分页。忘记这一步，Agent 会卡在 "---- More ----" 提示符上，直到超时。
另一个坑是设备的命令提示符匹配。不同厂商的提示符规则不一样，有的带路径（比如[Huawei-GigabitEthernet0/0/1]），有的带模式标识。我在执行时用"正则匹配提示符结尾 + 超时控制"的方式，避免误判命令是否执行完成。
5.3 工作台界面与任务流设计
管理端界面我用了"左拓扑右面板"的布局：左侧是画布，右侧是选中设备或链路的详情和操作面板。变更操作统一走"发工单"按钮，填写变更原因、影响范围、操作命令后，生成 Job 提交审批。
审批环节完全可以在手机浏览器上完成。收到审批通知，点进去看到命令列表，如果没问题就通过，如果有疑问就打回并附上备注。这套流程对非技术管理者也很友好，因为他们不用懂命令细节，只需要理解"这是删除接口配置，影响范围包含哪些业务"即可。
5.4 日志防篡改与审计闭环
做运维工作台不能只考虑"变更成功"，更要考虑"出了事能查清"。我把审计日志设计成追加写入模式，不允许修改和删除；每条日志除了记录操作人、时间、设备、命令之外，还包含上一条日志的哈希值，形成哈希链。如果有人试图篡改某一天的日志，后续所有哈希校验都会失败，立刻暴露。
6. 常见问题与排查技巧实录
6.1 拓扑发现不全或断链
出现频率最高的问题是拓扑图中间缺了一条链路。排查顺序我是这样定的：
先验证设备 LLDP 是否真正生效。有些设备全局配置了lldp enable，但接口下没有放通，导致邻居信息为空。执行display lldp neighbor interface看具体接口。
再验证 SNMP 是否只读可用。很多网络团队只给 SNMP 开了读社区，但绑定了访问控制列表，管理机不在允许列表里，导致轮询超时。用snmpwalk单独测一台设备，很快就能定位问题。
最后查 MAC 地址表。如果设备确实启用了二层转发，但 LLDP 信息缺失，可以通过 MAC 表推断出"这个口连着哪台设备的哪个 MAC"，作为兜底方案。
6.2 Agent 任务假死或无回执
Agent 卡死是自动化运维最常见的故障。我主要遇到过两种情况：
一是设备响应慢，SSH 连接建立了但命令回显迟迟不来，Agent 一直阻塞在等待状态。解决方法是给 send_command 加timeout，超时后强制断开连接。
二是任务并发撞车。多个 Job 同时打同一台设备，设备 CPU 可能瞬时飙高，部分连接被拒。我后来在 Agent 端加了信号量，限制并发数为 3，并对高频操作做了排队。
排查时建议先看 Agent 日志中的心跳。Agent 每 30 秒上报一次心跳，如果心跳中断，说明 Agent 进程或网络有问题；如果心跳正常但任务超时，则怀疑是任务逻辑卡死。
6.3 配置下发失败后回滚也失败
这是最让人头大的场景。回滚失败的根因通常有两个：
备份配置不完整。设备输出分页没关掉，备份内容被截断，回滚时把不完整的配置推回去，反而造成更大破坏。所以备份前必须执行screen-length 0 temporary，备份后要校验文件行数和设备实际配置行数是否一致。
备份格式和当前命令语法不兼容。设备升级后旧配置里的一些命令在新版本中已废弃，回滚时系统拒绝执行。这种情况比较罕见，但遇到会非常痛苦。我的经验是：回滚前先做diff预检，看到有被拒风险的命令要及时中止。
任何生产设备变更前，永远先确认备份完整性。宁可多备份一遍，也不要在变更失败后试图手工恢复——你以为你在救火，实际上可能是在放火。
6.4 本地 AI 推理性能不达标
本地小模型在处理超长配置文本时，速度很感人。我的解决办法是：先把配置按段落切分，只把关键段落（比如接口段、路由段）分别送进模型，避免整篇配置一起算。同时把 AI 服务设计成异步任务，前端界面先返回"解析中"，结果出来后再推送通知，避免界面长时间卡住。
凡是能用正则和脚本解决的问题，绝不经过模型。这套原则让 AI 部分的并发压力降到了很低。
结尾：做完这个工作台，我最大的几个体会
说实话，做完这个项目的最大体会是：AI 在里面起的只是"解释和理解"的作用，真正让运维变安全的是"受控流程 + 数据本地化"这套底座。模型给分析建议，流程保证每一步都有人确认，数据自始至终留在自己手里。没有后者，AI 再聪明也只是个没有刹车的引擎。
如果你也打算做类似的工作台，我建议从最小闭环开始：一台设备，跑出 LLDP 邻居，存进数据库，再由 Agent 执行一条只读命令。先把这条链路走通、把数据模型定义清楚，再慢慢扩大设备范围。不要一开始贪多求全，否则排查问题的时间会淹没你所有的成就感。
一个小技巧收尾：给所有 Agent 和采集器的账号设置独立的登录凭据，不要用设备的管理员账号。这样一来，即便某个 Agent 被攻破，也只影响一部分设备，而且审计日志能清楚看到是哪个 Agent 干的，追责和收敛都非常快。网络安全这件事，永远是越往后做，越觉得最笨的办法最可靠。
