用 MCP 把 AI 能力集成到网络运维：系列第一章

这是一个关于使用 MCP 和 Agent Skills 进行 AI 辅助网络运维的 7 部分系列的第 1 部分。

从私有 chatbot 到共享、可复用的基础设施：MCP 服务器、Agent Skills、知识目录和安全模型，将 AI 转变为真正的网络运维团队成员。

问题：无法接触网络的 AI

从个人 AI 到团队 AI

MCP 实际上是什么（对网络工程师而言）

当今形势：谁拥有网络设备的 MCP 服务器？

乐高积木，而非整体方案

MCP 服务器是逐步成长的，不是开箱即用的

什么成为可能

不同于现有网络自动化的地方

知识问题（以及为什么这是困难的部分）

本系列即将推出的内容

今天，每个使用 AI 的工程师都在一个私有的孤岛中工作。一位支持工程师在个人 chat 中调查一个告警。一位架构师在另一个 chat 中设计解决方案。一位开发者在第三个 chat 中进行调试。每次对话中获得的 AI 知识在 chat 关闭时就消失了。Skills 和 MCP 服务器由一个人构建，由一个人使用，永远成不了公司资产。

与此同时，大多数构建 AI 应用的团队将提示语、数据访问、检索逻辑和安全检查编织到一个无法分解或共享的单一代码库中。当框架过时时，他们从头开始重建。

有更好的办法。Model Context Protocol（MCP）和 Agent Skills 创建模块化、可组合的构建块，每个都有明确的边界。你一次构建它们，在团队间共享，并在技术形势变化时进行调整。本文解释了为什么网络工程师应该关心，当今形势是什么样的，以及当你以正确的方式将 AI 连接到真实设备时会成为可能。

问题：无法接触网络的 AI

以下是当网络工程师尝试使用 AI 助手进行实际工作时会发生的情况：

场景 1 "显示 sf-163-187 上的活跃告警。"工程师复制 CLI 输出，粘贴到 chat 中，要求 AI 解释。AI 根据一般网络知识猜测告警含义。它不知道供应商的告警字典。它不知道哪些告警会阻止配置工作。它给出一个似乎合理的答案，可能正确也可能不正确。

场景 2 "设计一个跨越三个 ETX-2 单元的 ERP 环。"工程师向 AI 描述拓扑。AI 产生一个通用的 ERP 环配置，也许接近教科书上的内容，但对于特定固件版本不是即插即用的。端口命名约定因系列而异。配置保护 erp 的语法各不相同。AI 不知道它不知道什么。

场景 3 "更改 sf-163-187 上的位置字符串为 TLV 实验室机架 3。"没有人会让 AI 在生产交换机上进行配置更改。他们这样做是对的——没有安全网。没有备份。没有 diff 预览。没有批准门槛。没有审计日志。风险是不可接受的。

所有三个场景都有相同的根本原因：AI 没有连接到设备，没有了解该设备。它是基于训练数据进行回答，而不是基于你的网络的现实。

但有一个更深层的问题：即使一个工程师在其个人 AI chat 中解决了这些场景，下一个面临同一问题的工程师也必须从头开始。调查、知识、安全规则——都没有被共享。每个工程师重新构建相同的上下文，发现相同的陷阱，并产生在 chat 关闭时就消失的答案。

从个人 AI 到团队 AI

转变不是从"无 AI"到"有 AI"。它是从个人 AI 到团队 AI——从"一个工程师可以使用 AI"到"一个团队可以共享 AI 调查、知识和基础设施"。

这不是理论性的。这个愿景看起来是这样的：一个共享工作区，其中多个工程师和 AI 智能体从事同一个调查。人们从不同角色贡献——支持、架构、开发——专门的 AI 智能体处理不同领域：网络 AI 智能体通过 MCP 连接设备，文档 AI 智能体搜索手册和发布说明，开发 AI 智能体搜索 Git 历史和 Jira。一个共享调查，多个 AI 智能体，可见的会话，以及结合了根本原因、支持证据、CLI 输出、相关问题、手册参考和建议行动的结构化输出。

这是"另一个 chatbot"和基础设施的区别。Skills 和 MCP 服务器应该是公司资产，而不是个人工具。一台笔记本上的 MCP 服务器是原型。MCP 服务器加上一个协作中心，其中多个工程师可以向多个 AI 智能体排队任务，看到每个调查，并恢复任何会话——这是基础设施。

图 1——"另一个 chatbot"和基础设施的区别

当支持工程师在一个因固件升级而失去关键功能的设备上打开一个案例时，三个角色进行协作：支持工程师检查设备状态，架构师根据设计验证预期行为，开发者检查提交历史和已知问题。三个 AI 智能体支持他们——网络 AI 智能体（设备 CLI + SNMP）、文档 AI 智能体（手册 + 发布说明）和开发 AI 智能体（Git + Jira + CI）。AI 智能体并行工作，每个在自己的终端磁贴中，团队在一个视图中看到全部三个。结构化输出——根本原因、证据、CLI 输出、Jira 问题、手册参考、建议行动——由所有三个 AI 智能体的工作组装而成。

MCP 实际上是什么（对网络工程师而言）

MCP 是由 Anthropic 在 2024 年底引入的开放协议，现在作为社区项目在 modelcontextprotocol.io 进行管理，它标准化了 AI 应用如何连接到外部系统。正如网络工程师的 NetPilot MCP 指南所说，如果你曾经希望供应商 API 像 SNMP 一样通过 MIB 共享一个模式语言，MCP 就是这个想法为 AI 智能体而做的，采用范围已扩大到包括 Claude、GitHub Copilot、OpenAI Codex、Cursor 和 JetBrains 的主要 AI 和开发工具。

协议规范定义了三种传输：stdio（本地子进程，桌面主机的默认值）、Streamable HTTP（远程/多租户的单端点）和 SSE 用于向后兼容。架构很直接：

MCP 服务器包装一个系统（设备 CLI、SNMP 堆栈、库存文件）并公开三件事：工具（类型化、可调用的函数）、资源（可读数据）和提示（可复用模板）。

MCP 客户端存在于 AI 应用中——Claude Code、Claude Desktop、GitHub Copilot、OpenAI Codex——并通过 stdio（本地）或 streamable HTTP（远程）连接到服务器。

AI 模型从不直接与你的设备通话。它看到一个工具定义的列表，带有 JSON 模式，决定调用哪个，客户端通过服务器执行调用。服务器（而不是模型）决定什么被公开，什么不被公开。

最后一点比听起来更重要。服务器是守门人。它可以将读命令列入白名单，拒绝没有明确确认的写入，从响应中隐去凭证，并记录每个操作到审计日志。模型无法绕过这些控制，因为控制存在于服务器，而不是在提示中。

图 2——MCP 服务器是守门人——模型从不直接与设备通话

如果你之前用 Python 和 Netmiko 构建过网络自动化，可以这样想：MCP 是将你现有脚本转变为 AI 智能体可以发现、理解和安全调用的东西的层，而不需要你硬编码工作流。AI 根据你的要求决定链接哪些工具。你决定工具可以和不可以做什么。

当今形势：谁拥有网络设备的 MCP 服务器？

在构建我自己的服务器之前，我花时间调查了现有的形势。下面的调查基于通过 2026 年 7 月的网络搜索找到的公共 GitHub 仓库和供应商文档——将其视为你自己研究的起点，而不是生产认可。在指向真实设备之前，查看每个项目的身份验证模型、写入范围和审计日志。

截至 2026 年中期，现有内容如下：

Cisco（覆盖范围最广）

Cisco 的 RADkit 远程自动化 SDK 在 CiscoDevNet GitHub 组织下有一个 MCP 服务器——设备库存、CLI 执行、通过基于证书的身份验证的配置提交。它标记为"非官方产品"，但存在于 Cisco 自己的组织下。还有社区服务器包装 pyATS/Genie 用于结构化 show 命令解析，以及更轻量的网络助手服务器用于路由策略和设备健康查询。Cisco 在任何供应商中拥有最广泛的覆盖范围。

Juniper（最佳供应商官方支持）

Juniper 在其官方 GitHub 组织中维护了一个 MCP 服务器，支持 stdio 和 streamable-http 传输方式，并提供 Docker 镜像和基于令牌的身份验证。它支持运维查询以及配置加载和提交。Juniper 还为 Paragon Automation 提供了一个控制器层面的 routing-director MCP 服务器。社区也构建了基于 PyEZ 的服务器，并已使用 VS Code/Copilot 进行测试。

Palo Alto Networks 发布了一个官方服务器，但它是用于 MCP 流量的安全中继（Prisma AIRS），并非 PAN-OS 设备管理工具。设备管理方面则由社区服务器覆盖：支持只读模式开关、使用正则表达式验证输入以防止 XPath 注入、明确的写入与提交两步流程；其中一个服务器还支持 .mcpb Desktop Extension，并使用操作系统密钥链存储凭据。

一个准官方的 CloudVision MCP 服务器将 Claude/AI 智能体连接到 CloudVision 的 REST API。社区服务器使用 Netmiko 封装 Arista 实验室环境，支持 TOML 设备清单、show/VLAN/BGP/LLDP 查询，以及跨 spine/leaf 设备群的健康检查提示词。

社区服务器覆盖 FortiOS 7.6.x，提供 200 多个类型化工具、异步 HTTP 客户端以及安全优先的默认配置。还有一个用于集中式策略和设备管理的 FortiManager MCP，并内置安全检查。

MikroTik 的相关项目最为密集，共有六个社区服务器，其中包括 MikroMCP，它提供 117 个类型化工具、dry-run 预览、每台路由器独立的熔断器以及 RBAC。Huawei VRP 方面仍存在空白：目前没有面向物理硬件的成熟 MCP 服务器，不过适用于 VRP 的 NAPALM 驱动程序提供了可供封装的基础组件。虽然存在 Linux/Windows shell MCP 服务器，但它们用于主机管理，并非网络设备工具。

跨厂商的共同模式

这些服务器大多采用了一些值得借鉴的通用安全模式：通过只读环境变量开关控制权限、提交前执行 dry-run/差异对比、使用命令白名单而不是原始 shell 字符串，以及对敏感信息进行脱敏的审计日志。对于多厂商覆盖，Netmiko/NAPALM 的设备类型字符串可以直接映射：arista_eos、cisco_ios、huawei_vrp、junos、rad_etx 都是 Netmiko 支持的平台，因此可以通过同一个代码库中的单一封装器覆盖多个厂商。

既然已经有这么多现成服务器，为什么还要自行构建？有六个原因：

1. 你的设备未被覆盖

如果你使用的设备来自一个没有 MCP 服务器的厂商——而许多厂商确实如此——那么你别无选择。我使用 RAD Data Communications 的设备（ETX-2、SecFlow、Megaplex、MiNID）。搜索“RAD MCP”，找到的都是无关项目：RAD Security（Kubernetes）、Cisco RADkit（不同的产品）、Radicle（git）。没有任何项目面向 RAD 设备。可行的路径与 Huawei 相同：在自己的轻量级 MCP 服务器中封装 Netmiko 的 rad_etx 设备类型。

这也具有战略意义：率先为自己的厂商生态发布 MCP 服务器，可以让你被定位为一家基于 AI 的运维厂商，而不仅仅是设备制造商。该工具包可以嵌入你现有的管理平台——在这个例子中是 RADview——并在每个厂商都被追问“你们的 AI 战略是什么？”的市场环境中，使你的产品线脱颖而出。

2. 知识才是产品，而不仅仅是工具

能够运行 show 命令的 MCP 服务器很有用。如果一个 MCP 服务器还配套了一项技能，能够掌握与你的设备固件版本完全对应的 CLI 参考、告警字典、配置层级和运维最佳实践，那将带来彻底的改变。在我找到的材料中，现有服务器提供了与设备通信的工具，但没有任何一个附带这样的知识：应该检查什么、按照什么顺序检查、什么样的状态才算“正常”，以及哪些命令是安全的。

这正是 Agent Skills 所填补的空白。Agent Skills（采用 SKILL.md 开放标准，目前已由 Anthropic 提供文档，并得到 Claude、Copilot 和 Codex 的支持）是基于文件系统的知识资源，可以自动加载到 AI 智能体中。它们不是代码，而是结构化的专业知识：有序的诊断步骤、真实的配置模式、需要避免的反模式，以及 AI 智能体必须遵循的安全规则。一项技能可以把通用 AI 变成专家。

没有技能时，Claude 给出的是教科书式答案。有了技能，它会给出经验丰富的工程师所遵循的有序诊断步骤、需要运行的确切命令、输出所代表的含义，以及需要避免的反模式。正如 claude-network-skills 项目所说：“区别立刻就能显现出来。”

3. 你可以控制安全模型

自行构建服务器时，你可以从头设计安全模型：

读取操作采用白名单机制——只允许获批的命令前缀，不接受原始 shell 字符串。

写入操作遵循分阶段提交流程：备份当前运行配置、暂存变更、显示差异预览、等待人工明确批准、提交，然后验证。对于某些设备系列（例如 Megaplex-4），服务器会强制执行规定流程：discard-changes → configure → sanity-check → commit → save。

危险操作（重启、恢复出厂设置）被完全排除——不仅仅是加以保护，而是根本不在支持范围内。

凭据绝不会出现在设备清单文件、工具参数或响应中——它们只能存放在环境变量或操作系统密钥链中。

每项操作都会记录到仅可追加的审计轨迹中，并对凭据进行脱敏。

只读开关可以在工具注册时禁用所有写入工具——这对于演示、培训或受限环境非常实用。

这些安全原语同样出现在为本项目提供依据的厂商基线调研中，并被列为值得借鉴的模式。Huawei 的一份 IETF Internet-Draft 也针对基于 MCP 的网络管理提出了同意工作流、审计轨迹和 LLM 隔离方案——这表明标准组织正在认真对待这一问题。

4. 为团队构建，而不只是为自己构建

为一名工程师在一台笔记本电脑上构建的 MCP 服务器只是原型。为团队构建的 MCP 服务器则属于基础设施：它使用 HTTP 传输，使多名工程师能够连接同一个实例；采用基于令牌的访问控制，让每个人获得适当权限；提供共享知识目录，确保所有人得到与固件版本完全对应的一致答案；并保留审计轨迹，使每一项由 AI 驱动的操作都可追溯。

rad-collab-hub 项目展示了这种模式的实际应用：这是一个 Web 平台，多个 AI 智能体可以在平铺终端中并排运行；共享任务队列会自动将工作分派给空闲的 AI 智能体；会话浏览器则让每项调查都可见、可标记且可恢复。一名支持工程师将设备调查加入队列，一名架构师添加设计问题，AI 智能体并行处理这两项任务。两名工程师都不必等待对方，而且聊天关闭后，两项调查都不会丢失。

5. 良好的基础设施可以降低对模型的要求

一个设计良好、提供有边界查询工具的 MCP 服务器，再配合轻量级技能层，不仅能让 AI 更智能，还能降低运行成本。当基础设施负责精确查找、结构化检索和验证时，模型的任务就从“理解这台设备的一切”缩减为“读取这些结构化结果并组织响应”。

每一项将智能从模型转移到基础设施的设计决策，也都会降低 token 消耗：

有边界的 MCP 查询返回 10 条结果，而不是整个目录——上下文更小

技能只嵌入 5 条关键规则，而不是一份 50 页的手册——减少系统提示词开销

使用 SQLite FTS5 精确查找，而不是加载整个手册章节——无需在上下文中放入 180KB 内容

严格的 JSON schema 输出——模型生成结构化数据，而不是自由形式的长文

在代码中执行验证，而不是交给模型——无需额外的纠错推理过程

知识由目录提供，而不是打包在技能文件中——使用轻量级技能（56KB），而不是捆绑参考资料（14MB）

这意味着更少的 token、更低的 API 成本，并且可以使用更小型或自行托管的模型运行。具有数据主权要求的组织可以在本地运行开放权重模型——知识存储在 SQLite 目录中，而不是模型权重中。预算有限的团队可以使用更小的 API 模型——有边界的查询能够控制 token 成本。良好的基础设施可以拉平差距。

6. 组织内部收益

该工具包不仅是一项技术资产，它还会改变组织的工作方式。在 POC 期间，显现出了六项收益：

预算节省——日常工作从昂贵的专家工时转移到 AI 辅助工作流。自动配置备份可以避免代价高昂的故障。

更快的周转速度——数秒内即可获得答案，并以可直接粘贴的 CLI 代码块呈现。新设备可以在几分钟内独立完成接入，而不是耗费数天。

人力杠杆——初级工程师或 AI 智能体可以完成资深人员水平的工作，因为知识目录和技能已经将专业经验编码其中。减少对少数熟悉各种特殊细节人员的依赖。

流程纪律——每项变更都遵循同一条路径：检查、备份、暂存、批准、执行、验证，并配有权限控制和审计机制。不再存在没有任何记录的临时 SSH 会话。

技能成长——每个答案都会引用其来源：使用了哪条命令、来自哪个章节、受到哪些约束。工程师能够从经过验证的流程中学习——AI 像导师一样通过示范进行教学。新团队成员可以通过阅读引用的参考资料更快上手。

知识会在人员流动中幸存下来——当那位了解 ETX-2 ERP 时序怪癖的资深工程师离职时，这些知识不会随之消失。它们被保存在目录中，在 Git 中版本化，对下一个人可用。专业知识变成了资产，而不是依赖于人的风险。

这些不是产品功能——它们是组织转变。MCP 服务器是工具；知识目录是资产；安全模型是策略。它们一起改变了团队的运作方式。

积木而非整体

现在大多数 AI 应用都是作为整体构建的。一个团队使用 LangChain（或 LlamaIndex，或原生提示工程）来构建"ERP 诊断应用"，提示、检索逻辑、数据访问、安全检查和输出格式都编织在单个代码库中。应用能工作。但知识被困在里面。安全规则与应用的逻辑耦合。设备访问是自定义的。其他团队无法重用任何东西，除非复制粘贴代码，而这些副本会产生漂移。

Skills 和 MCP 采取了不同的方法。每项功能都是一个自包含的块，有明确的边界：

LangChain 应用是一件雕塑——漂亮，但你无法将其分解并用来构建其他东西。Skills 和 MCP 是乐高积木，你可以构建、分解、重新组合和共享。

团队 A 使用 MCP 服务器、ERP skill 和 MIB 目录构建"ERP 环诊断"工作流。团队 B 需要"固件升级验证"工作流。他们重用团队 A 的 MCP 服务器。他们重用相同的 MIB 目录。他们编写一个新 skill（固件验证策略），并将其与现有块组合。发布时间：几天，而不是几个月。用 LangChain 应用试试——你会在复制代码、重写提示、复制安全逻辑和祈祷两个版本不会漂移之间度过。

基础设施能度过技术转变

AI 与数据的交互在快速演变。今天 MCP 是新兴标准。两年后，可能是别的东西——新协议、新抽象、模型访问外部数据的新方式。这不是猜测；这是每个技术周期的模式。REST 替代了 SOAP。GraphQL 挑战了 REST。每次转变都需要重建数据访问层。

直接建立在当今框架上的应用针对当今的范式进行了优化。当范式转变时，你从头开始重建，因为知识、安全和访问逻辑都纠缠在应用内部。2023 年的 LangChain 应用已经显得过时了。

Skills 和 MCP 创建了关注点的分离，使基础设施能够适应：

当下一个协议到来时，你替换传输层。知识目录保持不变。安全规则保持不变。Skills 保持不变。你通过改变接口而不是重建基础设施来适应。

这不是理论。在 2026 年 7 月，MCP 规范发布了一个主要修订版本（2026-07-28），它删除了有状态初始化握手，消除了 HTTP 会话，引入了强制的 server/discover RPC，并用多轮往返请求替换了采样/根/启发。对于硬编码了 MCP 客户端行为的单体 LangChain 应用，这意味着需要重做——找到每个假设会话的调用站点，重写采样回调，更新资源订阅逻辑。

对于本系列中描述的模块化基础设施，迁移仅限于传输层：实现一个新 RPC 处理程序（server/discover），移除初始化处理程序，向列表结果添加两个元数据字段（ttlMs、cacheScope）。知识目录——未改动。安全模型——未改动。Skills——未改动。驱动程序抽象——未改动。审计追踪——未改动。几小时的传输层工作，第 6 部分的相同验证阶梯证明没有破损：金标准 MIB 提示仍然返回相同的 OID 和源哈希，分阶段提交流仍然在未确认时拒绝，工具状态矩阵仍然显示相同的工具。应用针对一个时间点构建。基础设施针对一个时间轴构建。两者都是合理的，但要知道你在构建哪个。

MCP 服务器是成长而来，不是发布而来

构建一个能 SSH 连接到设备并运行 show 命令的 MCP 服务器是个周末项目。但你的 MCP 服务器第一个版本会有问题。不是"损坏"的问题——意思是它会缺少你实际需要的工具，因为你无法预测工程师什么时候会提出什么要求。

本系列背后的工具包经历了相同的演变。它从基础读取工具开始（run_show、get_config、health_check）。实际使用揭示了差距：

新工具出现是因为工程师提出了现有工具无法回答的问题。"AI 能检查 SNMP 吗？"导致了 snmp_probe、snmp_get、snmp_walk。"哪张卡提供 16 个 E1 端口？"导致了数据表层。"这个告警是什么意思？"导致了手册摄取流水线。

工具被增强是因为一个适用于一个设备族的工具在另一个族上损坏了。run_show 命令需要每个族的白名单——某些族有看起来像 show 命令的危险命令。端口命名是特定于族的：SecFlow 使用 ethernet 3，ETX-1p 使用 ethernet lan1，ETX-2 使用 ethernet 0/2。该工具必须学习每个族的方言。

安全规则被精化是因为真实设备操作暴露了边界情况。Megaplex-4 需要强制 discard-changes → configure → sanity-check → commit → save 流程——这是只有在对真实设备上的配置变更进行分阶段操作时才发现的。

知识层增长是因为问题跨越了当前层覆盖的范围。CLI 参考存在是因为有人问"这个设备支持哪些命令？"MIB 目录（35,977 个对象）存在是因为有人问"AI 能否在不打开 SSH 会话的情况下检查 ERP 状态？"数据表层存在是因为有人问"哪张卡有 16 个 E1 端口？"每个问题都是一个差距。每个差距都变成了一个工具。

这些都不是提前计划的。每一个都是通过使用发现的。