做网络运维的同学应该都有过类似的体验：凌晨两点被告警电话叫醒，爬起来登录设备，敲十几条 show 命令，翻路由表、查接口状态、比对变更记录，最后发现是某条光纤链路抖动，半个小时就这么过去了。如果是跨区域网络，还得拉上好几个同事一起对日志、对时间线。更头疼的是，这一套经验往往只存在于几个老师傅的脑子里，新人来了根本接不住。

我这次想聊的项目，就是冲着这个痛点去的——做一套基于 MCP（Model Context Protocol）的智能体平台，把大语言模型真正接进网络运维链路里，让它可以读告警、查设备、跑诊断命令、分析根因，甚至辅助生成变更方案和合规校验报告。项目代号就叫 Agent for Network，从调研到落地大概用了两个多月。这篇文章会把整体设计、核心实现、三个落地场景、以及踩过的坑完整梳理一遍，适合正在做网络运维自动化、或者想用大模型改造内部工具链的朋友参考。

1. 项目概述：MCP 智能体平台要解决什么问题

1.1 网络运维的现状与痛点

先说背景。我们团队负责的网络规模不算小，核心网、数据中心、分支互联加起来有上千台设备，监控平台每天产生的告警量在万条级别。表面看监控、工单、变更流程都有，但实际上大家心里都清楚：

告警风暴严重。一个链路抖动能衍生出几十条告警，真正需要人关注的根因可能就一条。值班人员大量的精力花在“把衍生告警过滤掉”上，而不是判断故障影响。

排障高度依赖个人经验。网络故障不像应用故障有完整的调用链追踪，很多时候就是凭感觉：先看接口 down/up 状态，再看光功率、日志、路由邻居，最后看变更窗口。这套排查顺序每个老师傅心里都有一本账，但很少有人愿意把它沉淀成标准流程。

变更操作风险高。网络设备不像服务器可以随便回滚，一条命令敲错可能直接导致业务中断。变更窗口通常安排在深夜，评审靠人工翻配置，效率低不说，还容易漏掉关联影响。

我们最初的想法很简单：能不能让大模型替我们把“信息收集 + 初步分析”这部分工作干了？但试了一段时间发现，光有模型还不够。模型不能自己登录设备，不能查监控数据，更不能执行命令。它需要一个标准化的“手脚”，也就是工具调用能力。

1.2 MCP 协议为什么适合做这件事

在做 Agent for Network 之前，我们其实已经做过一版基于某大模型私有工具调用接口的自动化脚本。那个版本最大的问题不是不好用，而是太“私有化”了：工具的注册方式、参数描述、调用协议全都绑在特定模型厂商的接口上，换一个模型就要重写一遍对接层，多个 Agent 之间也没法复用工具。

MCP 协议的出现正好解决了这个痛点。它的核心思路很朴素：把“模型能调用的工具”抽象成一套标准接口。工具方只需要实现一个 MCP Server，把每个工具的描述、参数 Schema、调用方式暴露出来；模型所在的 Agent 侧通过 MCP Client 就能动态发现并调用这些工具。模型和工具彻底解耦。

用一句不太严谨但好理解的话说：MCP 之于大模型应用，有点像 USB 之于外设——你只要做出一台支持 USB 标准的设备，插到任何电脑上都能用；你只要写一个符合 MCP 标准的工具服务，任何支持 MCP 的 Agent 都能调度它。

MCP 协议本身的几个特点也和我们场景很匹配：

标准化的工具描述。每个工具用 JSON Schema 描述入参和出参，大模型能基于这个描述自动决定何时调用、传什么参数，不需要我们为每个模型单独写 prompt 来“教”它怎么调用。

支持多种原语。除了最常用的 Tool（可执行操作），MCP 还定义了 Resource（只读数据）和 Prompt（提示词模板）。这三个原语配合起来，既能做设备数据查询，也能提供排障流程模板，比单纯工具调用灵活得多。

传输方式可选。本地进程用 stdio，跨机器部署用 HTTP，我们可以在安全性和灵活性之间做取舍。

生态复用。一个工具服务写好后，多个 Agent 都能接入。后面我们新接告警分析、变更影响评估等场景时，底层的设备诊断工具全都直接复用，没有额外开发成本。

1.3 平台定位与目标用户

在做架构之前我们明确了一点：这不是要取代监控平台，也不是要做一套新的运维系统。它更像是在现有监控、工单、设备管理之上加了一层“智能操作层”。监控平台负责发现问题，Agent for Network 负责理解问题、收敛信息、产出判断，把最终决策交给人。

目标用户有三类：一线值班的 NOC 人员，他们用自然语言就能完成大部分日常排障信息收集；二线网络专家，他们用这个平台做变更前的配置预检和影响分析；还有变更评审人员，他们借助平台的合规校验和 diff 结果快速完成审批。

定位明确之后，很多设计决策就好做了：只读诊断能力优先做，写操作（配置变更）放在第二阶段且必须有人工审批；每个工具能自动执行到什么程度、哪些命令允许模型调用，都要在工具设计阶段就定清楚。

2. 整体架构设计与工具集规划

2.1 分层架构与模块职责

整个平台我按四层来设计，每一层只干自己那一摊事，边界尽量清晰：

最上层是接入层，提供 Web 对话界面和 IM 机器人入口，值班人员直接在聊天框里提问，比如“查一下核心交换机最近一小时有没有丢包”“这台设备的 CPU 使用率趋势如何”。

往下是 Agent 编排层，这是智能体的大脑所在。它负责理解用户意图、编排任务、维护多轮对话上下文，并调用 MCP Client 去发现和调用工具。模型本身并不直接操作任何设备，它只负责“思考”和“决策”。

再往下是 MCP 工具层，由一组 MCP Server 组成。我们拆了三个 Server：设备诊断 Server（登录设备执行 show 命令、SNMP 查询）、监控数据 Server（拉取告警、性能指标）、工单与通知 Server（创建工单、发送通知）。拆分的依据是“归属域不同、安全等级不同”，后面做权限控制时也方便。

最底层是基础设施，也就是现网已有的设备、监控平台、工单系统和 CMDB。这一层我们基本没动，只是通过适配器把这些系统的能力封装成工具暴露给上层。

为什么要单独加一个 MCP 工具层，而不是让 Agent 直接连各种系统？因为直接连的话，每接一个新系统，Agent 主流程就要改一次；而且设备和监控系统的接口千差万别，有的走 SSH、有的走 REST API、有的走 SNMP，统一封装到 MCP Server 后，Agent 侧看到的工具就是干干净净的“查询设备状态”“拉取告警列表”，底层的协议差异完全被屏蔽了。这也是整个项目能快速迭代的关键。

2.2 MCP 工具集设计原则

工具设计是整个项目里最花心思的部分。工具粒度、参数设计、描述质量，直接决定了模型能不能正确调用。我们踩了不少坑，最后沉淀出几条原则：

工具粒度分两层。底层是原子工具，比如 ping、查询接口状态、查看路由表，一个工具只做一件事，模型很好理解；上层是组合工具，比如“一键排障诊断”“告警根因分析”，内部封装了多个原子步骤。模型先尝试用组合工具，组合工具覆盖不了的时候会自动降级到原子工具。这个设计对模型非常友好，也减少了调用次数。

工具描述必须“说人话”。MCP 的工具描述是给模型看的，不是给开发看的。我们在每个 tool 的 description 里写明：什么时候该用这个工具（触发条件）、参数含义、返回内容示例。比如描述一个查光功率的工具，我们写的是“当怀疑光模块异常或链路质量下降时使用，返回端口收发光功率值”，模型看到这个描述，就很容易在故障场景中联想到调用它。

参数尽量少而结构化。我们有个惨痛教训：第一个版本的“执行设备命令”工具只给了两个参数（设备地址、命令内容），模型经常自己脑补一些不存在的命令去执行。后来改成“命令白名单枚举”的方式后，模型只能从预先定义好的命令集合里选，误调率大幅下降。对于必须自由输入的场景，我们也加了命令正则校验，不匹配直接拒绝。

每个工具都要标注副作用。我们在工具元数据里加了一个自定义字段risk_level，分成 read-only、low-risk、high-risk 三档。Agent 编排层读到 high-risk 的工具，会自动进入人工审批流程，模型绝对不能直接执行。

2.3 工具清单与权限边界

设备诊断 Server 是我们第一个做的，也是后续所有场景的地基。它的核心工具如下：

这里要说明一下exec_show_command和上面那些结构化工具的区别。理论上我们尽量用结构化工具，因为返回的是字段清晰的 JSON，模型好理解；但网络设备的诊断场景五花八门，总有覆盖不到的查询，所以保留一个白名单内的“自由命令”工具兜底。白名单的维护方式是把设备厂商和命令类别做成配置表，新增命令要走评审，防止模型拿到一把“万能钥匙”乱来。

监控数据 Server 则是把现有监控平台的数据查询能力封装进来，包括按时间范围拉取告警，聚合告警，查询性能指标趋势，查询拓扑和依赖关系。工单通知 Server 比较简单，就是创建工单、更新工单状态、发送 IM 通知。

3. 核心环节实现：从 MCP Server 到 Agent 工作流

3.1 搭建 MCP Server 与工具注册

实现 MCP Server 我们直接用官方 Python SDK，里面提供了 FastMCP 这个高层封装，写一个工具函数加一个装饰器就能完成注册，开发效率非常高。下面这段代码是我们设备诊断 Server 的骨架（做了简化）：

from mcp.server.fastmcp import FastMCP from typing import Annotated mcp = FastMCP(name="network-device-server") @mcp.tool( description=( "查询网络设备的基本状态信息。" "当需要了解某台设备的存活情况、CPU/内存使用率、运行时长时使用。" "返回结果为结构化 JSON。" ) ) def get_device_status( device_ip: Annotated[str, "设备管理地址，如 192.0.2.10"] ) -> dict: """只读操作：查询设备版本、CPU、内存、上线时长。""" row = cmdb.query_device(device_ip) snmp_data = snmp_get(device_ip, OID_DEVICE_BASIC) return { "device_ip": device_ip, "device_name": row["name"], "device_model": row["model"], "uptime_seconds": snmp_data["uptime"], "cpu_usage_percent": snmp_data["cpu"], "memory_usage_percent": snmp_data["memory"], } @mcp.tool( description=( "在目标设备上执行 show/display 类诊断命令。" "命令必须在白名单内，白名单外的命令会被拒绝。" "适合在结构化工具无法覆盖的查询场景下使用。" ) ) def exec_show_command( device_ip: Annotated[str, "设备管理地址"], command: Annotated[str, "要执行的诊断命令，如 display interface GigabitEthernet0/0/1"], ) -> str: """只读操作：执行白名单内的诊断命令。""" return device_access.exec_show(device_ip, command)

从代码里能看到，工具函数本身很薄，真正的逻辑都在device_access层。FastMCP 会自动根据函数的类型注解和 docstring 生成 MCP 协议需要的 JSON Schema。这一点特别重要，因为 Schema 的描述质量直接决定模型的理解质量，我们在 docstring 和 description 上花了大量精力反复打磨。

启动 Server 的方式也值得说一下。开发阶段用 stdio 传输，直接在本地起进程，调试方便；生产环境改成 HTTP 传输，部署成独立服务，多个 Agent 实例可以共享同一个 Server。切换只是换一下 serve 方式的参数，工具代码一行都不用动：

# 开发环境：stdio 传输 mcp.run(transport="stdio") # 生产环境：HTTP 传输，监听 8085 端口 mcp.run(transport="http", host="0.0.0.0", port=8085)

3.2 网络设备接入层实现

MCP Server 只是壳，真正硬核的是设备接入层。网络设备的访问方式和互联网应用完全不一样，没有 REST API，最常见的还是 SSH 命令行。我们把这层单独立起来做，核心解决三个问题：会话管理、命令白名单、输出解析。

会话管理方面，设备连接不能每次现连，SSH 握手一次好几秒，故障场景下等不起。我们做了一个连接池，按设备 IP 缓存 SSH session，设置空闲超时和最大连接数，复用已有连接。跳板机（堡垒机）场景也做了支持，所有设备访问都经过跳板机，平台自身不直接暴露在办公网之外。

命令白名单不能只挡“明显危险”的命令，还得防模型“无意”执行影响较大的查询——比如某些厂商的 show 命令在负载高时也会消耗设备 CPU。我们的白名单按设备型号分组维护，每条命令都标注预计影响的等级。实现上用一个装饰器统一拦截：

def whitelist_guard(device_model: str): def decorator(func): def wrapper(device_ip: str, command: str, *args, **kwargs): allowed = command_whitelist.get(device_model, set()) if command not in allowed: raise PermissionError( f"命令 {command} 不在设备型号 {device_model} 的白名单内" ) if is_dangerous_pattern.search(command): raise PermissionError("命令命中危险模式，已拦截") return func(device_ip, command, *args, **kwargs) return wrapper return decorator

输出解析是另一个大坑。网络设备的 show 命令输出是纯文本表格，不同厂商、不同型号的格式千差万别，模型直接读原始文本容易错。我们在 agent 侧做了规范化处理：每种白名单命令都配一个解析器，把文本转成结构化 JSON。解析器维护在一个独立目录里，命令格式变化时只改解析器，不影响 Agent 逻辑。

3.3 Agent 工作流编排与工具调度

Agent 编排层要回答一个问题：模型怎么在合适的时机调用合适的工具，并且把多次调用的结果串起来。我们采用了 ReAct（Reasoning + Acting）模式，每一步让模型先思考再行动，工具返回后带着观察结果继续思考，直到得出结论。

核心循环用伪代码描述就是这样：

async def run_agent(user_query: str): messages = [{"role": "user", "content": user_query}] # 最多执行 8 步，防止模型陷入无限循环 for step in range(MAX_STEPS): # 让模型基于当前上下文决定下一步动作 response = await llm.chat( messages, tools=await session.list_tools(), # 动态获取 MCP Server 的工具列表 ) if not response.tool_calls: # 模型认为不需要再调用工具，直接返回最终答案 return response.content messages.append(response) for call in response.tool_calls: result = await session.call_tool(call.name, call.arguments) messages.append({ "role": "tool", "tool_call_id": call.id, "content": result.content, })

实际实现比这个复杂不少，比如多轮工具调用结果的缓存、上下文压缩、并行工具调用等。但我建议第一版一定从最简单的顺序执行开始，先把链路跑通，再优化性能。

编排层里我们还加了三个“安全刹车”：

最大步数限制。任何任务最多执行 8 步工具调用，超过就强制停止并汇总现有结果，避免模型在错误方向上越走越远。这个限制来自实测：正常排障流程 3-5 步就能收敛，超过 8 步几乎都是模型跑偏了。

写操作拦截。编排层识别到 high-risk 工具时，不会直接执行，而是先把完整操作方案（做什么、影响什么、如何回滚）生成成审批单，推送给人工。人工确认后平台才继续执行，执行结果会自动记录审计日志。

关键结论必须附证据。模型给出“链路有问题”这类结论时，我们要求它必须引用具体的工具输出片段作为依据，并在界面展示引用来源。没有证据支撑的结论会被标记为“待确认”，不会直接进入告警通知。

3.4 安全管控与审计设计

网络设备的操作权限非同小可，安全这块我们几乎是按照“账号权限最小化 + 操作全程留痕”的原则来设计的。

账号体系上，平台连接设备使用的是专门的巡检账号，账号权限只开放只读命令和部分低危命令，没有配置修改权限。高危操作走独立的变更账号，该账号的密码不落库，使用时从密钥管理系统动态获取，并且在执行完成后立即失效。

审计日志分两层。MCP Server 层记录所有工具调用请求，包括入参、出参、耗时、调用方标识；Agent 编排层记录模型的思考过程、工具选择结果和最终结论。两层日志互相关联，出了问题可以完整回放一次排障过程。这个设计后来在查问题时帮了大忙——有次模型生成了一个可疑的结论，我们回溯日志，发现是工具返回的数据源本身出了问题，模型只是“忠实”地转述了错误数据。

另外就是敏感信息治理。设备登录凭据、监控平台的 Token 都不会传给模型，模型看到的只是脱敏后的设备别名和标号。涉及账号密码的对话内容，平台会在落盘前做字段级脱敏。

4. 场景落地实践：从原型到可用

4.1 场景一：网络故障自动排查与根因收敛

第一个上线的场景是告警驱动的自动排障。流程是这样的：监控平台产生告警后，把告警推送给 Agent for Network 的信息接收接口；Agent 首先调用监控数据 Server 拉取该告警周边时间段内的所有相关告警，做聚合去重；然后基于告警涉及的设备，调用设备诊断 Server 获取设备状态、接口状态、日志；最后综合所有信息生成一份排障简报，自动推到值班 IM 群。

这里有个很关键的细节：Agent 的判断结果不直接触发处置动作，而是“建议”。比如它发现某接口 down、光功率为 0、日志里有大量 CRC 错误，会给出“疑似物理链路或光模块故障，建议现场检查光纤连接和光模块”的建议，由值班人确认后再执行后续操作。

我们拿一个真实故障案例做了复盘。某日上午 10 点 23 分，监控平台收到核心交换机下联端口 down 的告警。Agent 在 40 秒内完成了这些动作：拉取告警发现同一时间段还有对端设备端口 down 的告警（这两条告警在监控平台上相隔几分钟，值班人容易当成两次独立事件）；登录两端设备查看接口状态和光功率，发现对端光功率为 0；查看两端设备日志，均无端口手动关闭记录。Agent 最终收敛判断为物理链路中断或光模块故障，并生成了包含两端设备端口号、光功率读数、建议处理步骤的完整报告。值班同事拿到报告后直接安排现场人员带光模块和光纤过去处理，整个响应时间从过去的半小时级别缩短到几分钟。

说实话这个效果超出了我们预期。我们原本以为模型在这种场景下只能做“信息搬运工”，实际跑下来发现，它做告警收敛的价值最大——把分散在多个告警里的信息关联成一条时间线，这是人类值班员最容易遗漏的。

4.2 场景二：配置变更辅助与合规校验

网络变更的评审有两块最花时间：一是对照基线检查新配置是否符合规范，二是评估变更影响范围。这两块正好都是 Agent 的强项。

变更前，工程师把变更配置文本粘贴到平台上，Agent 会自动完成三件事。第一，语法检查——把配置逐条解析，和不支持的命令模板比对，提前暴露语法错误。第二，合规校验——检查配置里是否有不符合规定的项，比如 SNMP community 用了默认字符串、AAA 认证未配置、日志服务器地址写错等。第三，影响分析——根据变更涉及的接口、VLAN、路由条目，去 CMDB 和拓扑库里查关联业务，输出“本次变更会影响哪些设备、哪些链路、哪些业务”的清单。

这个场景做出来之后，变更评审的通过率明显提高了。以前评审人面对复杂的 BGP 配置变更，全靠经验判断影响范围；现在 Agent 能自动列出受影响的对端 AS、涉及的网段和客户业务，评审人只需要确认 Agent 的清单是否完整。最直接的收益是，变更导致的“意外影响”投诉少了——因为大部分关联关系在变更前就被 Agent 识别出来了。

需要说明的是，Agent 在这个场景里不做自动下发。配置的下发和回滚仍然由工程师在变更窗口手动执行，平台只提供预检和校验。我们一直坚持“模型不动配置”的原则，宁可多一道人工确认，也不给事故留口子。

4.3 场景三：网络变更影响分析与容量评估

第三个场景是前两个的自然延伸：Agent 不仅能做变更前的合规校验，还能做容量评估和趋势预测。

举个例子，有一次网络团队要评估“能否在核心交换机上新增一个重要业务网段”，传统做法是人工登录设备查 CPU、内存、带宽使用率的峰值，再凭经验判断。Agent 的做法是：拉取该设备过去 30 天的 CPU、内存、接口流量指标，按天聚合计算峰值和均值；对比同类设备的指标基线；再结合新增网段的预估流量模型，输出一份容量评估报告，明确说明“当前设备 30 天 CPU 峰值为 X%，内存峰值为 Y%，按现有业务增速，不建议在流量高峰时段实施变更，建议扩容后再接入”。

这个场景的价值不仅在于省人力，更在于评估的客观性——指标数据都是真实采集的，结论有数据支撑，减少了“我觉得还行”“我估计没问题”这类拍脑袋判断。对我们这种设备资源接近饱和的网络，这种数据化的容量评估非常实用。

5. 常见问题与排查实录

5.1 工具调用超时与连锁反应

第一个线上问题就是超时。网络设备的 CLI 响应速度不稳定，尤其在高负载时，一条 show 命令可能卡几十秒。而大模型对工具调用有等待时限，超时后模型会误判工具不可用，甚至开始编造“可能的结果”。

我们的解决办法是分两层处理：工具执行层给每条命令设置独立的超时时间（查询类 30 秒，批量类 60 秒），超时后立刻释放会话并返回明确的错误信息；Agent 编排层接收到超时错误后，会向用户说明“工具执行超时，可能原因是设备负载过高或网络延迟”，而不是让模型自行脑补。同时，超时重试限制为最多一次，二次超时直接放弃该工具，避免反复点击拖垮设备。

5.2 上下文膨胀与输出截断

第二个坑是模型上下文被设备输出撑爆。一条完整的路由表 show 输出可能有几千行，模型每调用一次工具，输出就塞进上下文，几轮下来就接近窗口上限了。更糟的是，上下文被大量原始文本占据后，模型的推理准确率明显下降。

我们的解法是在工具层做“输出精简”：解析器把文本转成 JSON 后，还会做摘要处理——只保留关键字段和异常项。比如路由表不再返回完整表项，而是返回“路由条目总数、BGP 邻居状态摘要、有异常的条目明细”。这样模型看到的始终是结构化摘要，需要细节时再通过二级工具查具体条目。

5.3 并发冲突与写操作竞态

多 Agent 实例并发调用时，出现过一次查配置的会话把另一个变更会话的会话池挤掉的问题。排查后发现是连接池的全局锁粒度太大，一个长时间运行的查询把整个池子锁住了。

后来把连接池按任务维度做了隔离，查询类任务和变更类任务使用不同的连接池。写操作本身也加了分布式锁，同一个设备同一时间只允许一个变更任务执行，从根上避免并发下发配置导致的状态错乱。

5.4 模型幻觉与危险操作防控

幻觉是所有人最担心的问题。我们遇到过两次模型“一本正经地编造设备输出”——一次是模型说某台设备 BGP 邻居状态是 Established，但实际上我们并没有调用过相关工具。原因是在多轮对话中模型丢失了工具调用的轨迹，开始凭记忆补全。

针对这个问题的排查和防治，我们做了三件事。第一，在提示词里强行约束：没有工具输出的信息一律不得写入结论，所有关键结论后必须附证据编号。第二，界面上把工具调用轨迹和最终结论分开展示，用户可以展开每条结论查看对应证据。第三，抽样人工审核，每周随机抽取一定比例的排障报告，检查结论与工具输出的对应关系。上线的头一个月人工审核发现了十几处证据不完整的情况，后面明显减少，AI 生成痕迹重的结论基本被界面规则拦住了。

5.5 常见问题速查表

6. 踩坑之后的几点体会

项目跑到现在，最大的体会是：写 MCP Server 本身不难，难的是把网络设备的“脏活累活”处理好。设备输出解析、连接管理、命令白名单、超时处理，这些看起来不起眼的底层能力，决定了上层 Agent 的可用性。模型再聪明，工具返回的是乱糟糟的文本，它也分析不出什么有价值的东西。

工具描述的质量直接决定 Agent 的智商。同一个工具，描述写成“查询设备状态”和写成“当怀疑设备异常或需要了解设备基本健康度时使用，返回 CPU、内存、运行时长”，模型的调用准确率差一大截。如果你想做类似项目，我建议把工具描述当成需求文档来写，多花点时间绝对值得。

还有一点想提醒后来者：别急着放开写操作。我们最初也被“自动下发配置”吸引，但冷静下来之后决定只读先行。现在平台 95% 的调用都是只读诊断和预检，真正的高危操作全部走人工确认。这个克制让平台在团队里获得信任，大家才敢放心把故障排查交给它。先把只读诊断做到足够可靠，再考虑更进一步的自动化。

这个平台后续还有几个方向可以扩展：把流式遥测数据接进来做更实时的预测性分析；把老师傅的排障手册知识库化，让 Agent 在诊断时参考历史经验；还有把平台开放给更多一线运维团队，让每个团队可以自定义自己的工具集和流程模板。路还长，但方向和效果已经跑出来了。