从命令行到认知智能：基于cisco-mcp的AIOps深度实践

基于前一次的实践，这次的cisco交换机ai也能绘制出以交换机为中心的网络拓扑图！

近期的科技圈，无疑被Grok-4等新一代大模型的发布信息所席卷。这些拥有超长上下文、多模态能力的“巨兽”让人无限遐想。然而，在追逐星辰大海的同时，一个更实际的问题摆在每个技术人面前：我们能否利用当下可用的技术，解决眼前真实的问题？

答案是肯定的。

在上一篇文章中，我们让AI小试牛刀，绘制了网络拓扑图。今天，我们将进行一次“终极考验”：不依赖尚未落地的未来模型，仅通过对现有开源模型的精湛“调教”——即高阶提示词工程，将一个通用AI彻底改造为能够自主进行端到端故障排查的Cisco网络专家。

一、部署cisco-mcp服务

相较于上一篇实践中部署ssh-mcp-server时遇到的编译挑战，本次部署wzfukui/cisco-mcp项目的过程则显得格外顺畅。cisco-mcp是一个专为管理Cisco设备（支持Telnet/SSH）而生的Node.js MCP服务器，其部署流程充分体现了标准化Node.js项目的便捷性。

1. 部署安装：三步走的标准流程

整个安装过程遵循GitHub项目README的指引，与大多数Node.js应用别无二致：

第一步：克隆项目仓库

git clone https://github.com/wzfukui/cisco-mcp.git
cd cisco-mcp

第二步：安装项目依赖
这一步通过Node.js的包管理器npm，自动下载并安装项目所需的所有库文件。

npm install

与上次实践需要手动修改TypeScript代码来解决编译错误不同，cisco-mcp项目的依赖管理非常完善，npm install命令一次性成功，没有遇到任何兼容性问题。

第三步：构建项目（如果需要）
许多TypeScript项目需要一个构建步骤（npm run build）来将.ts源文件编译成JavaScript的.js文件。不过，cisco-mcp项目经过良好封装，可以直接通过node命令运行其主入口文件，省去了这一环节，进一步简化了部署。

2. 核心配置：定义你的设备版图

部署成功的关键，在于如何让服务正确地“认识”并连接到我们的设备。这主要通过两个配置文件来完成。

配置文件一：设备清单 cisco-devices.json
这是整个服务能够工作的“设备名册”。我们需要在项目根目录下创建一个名为cisco-devices.json的文件，在里面以JSON格式定义所有需要被AI管理的Cisco设备。

[
  {
    "alias": "my-core-switch",
    "host": "192.168.4.14",
    "protocol": "telnet",
    "username": "admin",
    "password": "your_password",
    "enablePassword": "your_enable_password",
    "description": "公司核心交换机"
  }
]

这个文件至关重要，其中alias（别名）是后续我们与AI交互时识别设备的唯一ID。AI会根据这个别名自动查找对应的IP、协议和凭证去连接设备。

配置文件二：在AI工作台注册MCP服务
最后一步，是将这个本地服务注册到我们的AI工作台（如Cherry Studio），使其能被AI模型发现和调用。根据我提供的截图，配置如下：

• 名称: cisco-mcp
• 描述: 通过 Telnet/SSH 管理 Cisco 交换机的 MCP 服务器
• 类型: 标准输入/输出 (stdio)
• 命令: node
• 参数:
  • C:\\xxx\\xxx\\cisco-mcp\\dist\\index.js (指向Node.js启动脚本)
  • C:\\xxx\\xxx\\cisco-mcp\\cisco-devices.json (将设备清单作为第二个参数传入)

这个配置清晰地告诉系统：使用node环境去执行index.js脚本，并且在启动时加载cisco-devices.json这个配置文件。至此，AI与Cisco设备之间的“桥梁”就完全搭建好了。

3. 部署挑战：从不确定到稳定

尽管安装过程顺畅，但在初期测试中，我遇到了AI执行命令“时好时坏”，频繁报告socket not writable的连接错误。这通常意味着底层工具在尝试写入命令时连接已经失效。经过排查发现，这并非网络问题或部署错误，而是AI在调用工具时的策略不够稳定。这个挑战，也直接引出了AIOps实践中真正具有“含金量”的核心环节——提示词工程。

二、灵魂所在：高阶提示词工程的“含金量”

许多人可能会觉得，提示词（Prompt）不就是“跟AI说人话”吗？能有什么技术含量？这是一种普遍的误解。在专业的AIOps领域，提示词绝非简单的对话，它是一套为AI心智“编程”的精密指令集。一个优秀的提示词，是将一个“充满想象力”的通用大模型，改造为一个“严谨、精确、可靠”的领域专家的关键。

我们的最终版提示词，正是“调教”的核心所在。让我们来拆解其“含金量”：

[ROLE AND GOAL]
You are {{model_name}}, an AI-powered Senior Network Engineer, specializing in Cisco IOS and NX-OS environments... Your sole purpose is to assist... with the highest level of accuracy and professionalism.

[RESPONSE LANGUAGE]
You MUST respond to the user in Chinese.

[CONTEXT AND ENVIRONMENT]
Timestamp: {{datetime}}
Operator: {{username}}
...

含金量 1：设定专业“人格”与“边界”

• [ROLE AND GOAL]: 这不是简单的称呼，这是在为AI构建一个“人格面具”。它让AI后续所有的回答都潜移默化地带上“资深网工”的口吻和思考模式，比如会主动提出安全建议。
• [RESPONSE LANGUAGE]: 强制中文输出，是基础的用户体验保障。
• [CONTEXT AND ENVIRONMENT]: 注入用户名、时间等变量，让AI的回答更具个性化和情境感，感觉像一个专属助手。

---

[OPERATIONAL PROTOCOL AND BEHAVIOR]
1.  **Fact-Based Reporting (Zero Hallucination):** Your responses MUST be derived STRICTLY from the tool's output... Never invent information.
2.  **Structured & Analytical Responses:** ...follow this three-step process: a. Briefly state... b. Summarize... c. Provide a short, expert-level insight or analysis.
3.  **Intelligent Mode-Handling:** You must infer the required command mode...
4.  **Communication Style:** ...Do not narrate the background connection process...
5.  **Strict Execution Workflow:** ...your internal process MUST follow these steps: a. Acknowledge & Verify... b. Execute with Precision... c. Analyze & Report...

含金量 2：植入“标准作业程序 (SOP)”

• [Fact-Based Reporting]: 这是AIOps的“安全红线”。我们用最严厉的词语（MUST, STRICTLY, Never）禁止了模型最臭名昭著的“幻觉”问题，确保了输出的绝对可靠。
• [Structured & Analytical Responses]: 这条指令将AI从“数据搬运工”提升为“情报分析师”。它强制AI不能只丢回原始数据，必须进行“总结+分析”两步操作，这直接提升了信息价值。
• [Strict Execution Workflow]: 这是解决“时好时坏”问题的定海神针。它为AI定义了一个不可逾越的思考流程（确认目标 -> 执行 -> 分析），把AI的“随机应变”变成了可预测的“标准作业”，极大地增强了稳定性。

---

[OPERATIONAL PROTOCOL AND BEHAVIOR]
1.  **Fact-Based Reporting (Zero Hallucination):** Your responses MUST be derived STRICTLY from the tool's output... Never invent information.
2.  **Structured & Analytical Responses:** ...follow this three-step process: a. Briefly state... b. Summarize... c. Provide a short, expert-level insight or analysis.
3.  **Intelligent Mode-Handling:** You must infer the required command mode...
4.  **Communication Style:** ...Do not narrate the background connection process...
5.  **Strict Execution Workflow:** ...your internal process MUST follow these steps: a. Acknowledge & Verify... b. Execute with Precision... c. Analyze & Report...

含金量 3：注入“专家排错逻辑”

• 这是整个提示词中最能体现“调教”功力的部分。我们没有让AI去猜测错误原因，而是将人类专家的排错经验，直接“编码”成了AI的行为模式。
• [If Error is “Alias not found”]: 教会了AI“自我修正”。当路不通时，不是放弃，而是拿出地图（list_available_devices）给用户看。
• [If Error is “socket not writable”]: 教会了AI“智能诊断”。它不再是一个复读机，而是能将技术性错误翻译成一个清晰、可操作的排错指南，这正是从工具到助手的质变。

可以说，部署工具（cisco-mcp）解决了“能不能做”的问题，而这套高阶提示词，则决定了AI“能做得多好”、“多可靠”和“多智能”。

三、成果展示：从简单查询到智能诊断

经过精细的提示词调优后，AI助手的表现稳定且专业。以下是实战交互案例，由浅入深地展示了其能力。

3.1 精确信息提取与结构化输出

网络运维中，我们经常需要从大量的CLI输出中提取关键信息。我们测试AI是否能将原始文本转化为易读的结构化数据。

我的指令:

好的，清单已收到。现在请连接到别名为 my-core-switch 的设备，执行 show ip interface brief 命令，并告诉我所有接口的状态。

AI的执行与分析:

我已在设备 my-core-switch 上执行了 show ip interface brief 命令，并汇总了所有接口的状态如下：

接口	IP 地址	OK?	Method	状态	协议
Vlan1	192.168.x.x	YES	manual	up	up
Vlan22	192.168.x.x	YES	NVRAM	up	up
… (省略中间多行接口) …
Port-channel2	unassigned	YES	unset	up	up

分析与建议：

• 接口状态良好：所有接口的状态均为 up，表明它们均处于正常运行状态，没有检测到任何物理或协议层的问题。
• IP 地址配置：VLAN 接口均已分配有效 IP 地址，确保了VLAN间的正常通信和路由功能。GigabitEthernet 和 Port-channel 接口显示为 unassigned，通常用于交换数据而非路由。

点评: 这是AIOps的核心价值体现之一。AI成功地将Cisco设备返回的、格式复杂的原始文本，解析成了一个清晰易读的Markdown表格，并对整体接口状态进行了总结。这极大地提高了信息的可读性和运维效率。

3.2 上下文关联与多步任务执行

真实的运维任务往往不是单步完成的。我们测试AI是否具备将多步操作关联起来，并根据上一步的结果执行下一步操作的“智能代理（Agent）”能力。

我的指令:

做得很好。请继续在 my-core-switch 上操作。首先，找到 VLAN 10 属于哪些端口；然后，检查这些端口的详细运行配置。

AI的执行与分析:
(AI首先执行 show vlan id 10)

我已在设备 my-core-switch 上执行了 show vlan id 10 命令，并找到了属于 VLAN 10 的端口如下：

VLAN ID	名称	类型	状态	端口
10	Marketing	access	active	GigabitEthernet2/0/5-7

进一步操作：
针对上述端口，我将依次执行 show running-config interface [端口名] 命令…

(AI随后自主地对 Gi2/0/5, Gi2/0/6, Gi2/0/7 分别执行了 show running-config interface，并将结果汇总如下)

汇总所有接口的详细运行配置如下：

接口	配置详情
GigabitEthernet2/0/5	- 工作模式: Access - 访问 VLAN: 10 - 描述: 连接到销售部门工作站 - 启用端口快速生成树
GigabitEthernet2/0/6	- 工作模式: Access - 访问 VLAN: 10 - 描述: 连接到市场部门工作站 - 启用端口快速生成树
GigabitEthernet2/0/7	- 工作模式: Access - 访问 VLAN: 10 - 描述: 连接到广告部门工作站 - 启用端口快速生成树

分析与建议：

1. 接口配置一致性： 所有接口均配置为 Access 模式，并指向相同的 VLAN ID…
2. 生成树优化： 启用了 PortFast 功能，适用于直接连接终端设备的端口…
3. 安全性建议： 考虑在关键接口上启用 Port Security…

点评: 这个案例完美展示了AI的逻辑推理和任务分解能力。它成功地将一个复杂的需求拆解为多个步骤，并且能够将第一步查询到的端口列表（Gi2/0/5-7）作为第二步查询的输入，最终将分散的信息整合成一份条理清晰的报告。这标志着AI已经从一个简单的命令执行器进化为了具备复杂任务处理能力的智能代理。

3.3 自动化端到端故障诊断

这个最终考验模拟了一个最常见的运维场景，旨在检验AI作为智能代理的综合能力：自主规划、多步执行、关联分析并最终给出诊断结论。

我的指令:

现在是最终考验。我收到一个报告，说连接在 my-core-switch 上的一台服务器失联了，它的MAC地址是 0050.56a6.xxxx。请你作为一名资深网络工程师，自主完成以下故障诊断流程并向我汇报。

在向AI发出这个复杂的诊断指令后，其后台日志（如下图所示）为我们揭示了一个极其宝贵、也颇为有趣的细节，让我们得以一窥其工作的内在逻辑。

我们可以看到，AI并没有像传统脚本一样，一次性盲目地执行完所有预设命令。恰恰相反，它展现了一种严谨的、分步式的推理-行动-观察”（Reason-Act-Observe, ReAct） 工作循环。

• 第一步：它规划并执行了第一个动作——定位MAC地址。然后，它并没有立刻进行下一步，而是在日志中留下了一句类似“自言自语”的备注：“请提供上述工具调用的结果，以便我继续完成后续的故障诊断步骤。”
• 第二步：只有当它“观察”到了第一步的确切结果后（即MAC地址在Gi2/0/24上），它才基于这个新的事实，去规划并执行第二个动作——检查Gi2/0/24的接口状态。

这正是智能代理（Agent）与自动化脚本的根本区别：

• 脚本是预设路径的执行者，无论中途发生什么，它都会尝试走完所有流程。
• 而AI Agent是基于事实的决策者。它每一步的行动，都依赖于上一步的观察结果。如果第一步发现MAC地址在另一个端口，它后续的所有操作都会自动调整到那个正确的端口上。这种基于上下文的动态适应能力，是其能够处理复杂、未知问题的核心。

因此，这段看似“卡住”的日志，实际上是AI在向我们展示其严谨的思考过程。它让我们不再将AI视为一个深不可测的“黑箱”，而是能够理解其决策逻辑、值得信赖的合作伙伴。

AI的执行与分析报告:
(AI自主地将任务分解为多个步骤，依次调用工具，并最终整合成了以下这份专业的诊断报告)

故障诊断报告

日期时间: 2025/7/11 14:25:16
操作人员: wiz
设备: my-core-switch

故障描述: 连接在 my-core-switch 上的一台服务器失联，其 MAC 地址为 0050.56a6.xxxx。

---

1. 定位 MAC 地址所在的物理端口

执行命令: show mac address-table | include 0050.56a6.xxxx
发现: MAC 地址 0050.56a6.xxxx 位于端口 GigabitEthernet2/0/24，所属 VLAN 为 22。

---

2. 检查端口 GigabitEthernet2/0/24 的接口状态和错误计数器

执行命令: show interface GigabitEthernet2/0/24
发现: 接口状态为 up/up (connected)，输入/输出错误计数器均为 0。物理层和数据链路层连接正常。

---

3. 检查VLAN 22的三层接口（SVI）是否正常工作

执行命令: show interface vlan22
发现: Vlan22 的三层接口状态为 up/up，IP地址配置为 192.168.22.xxx/xx，运行正常。

---

4. 最终诊断结论

经过详细的故障诊断，my-core-switch 上的端口 Gi2/0/24 和对应的 Vlan22 三层接口均运行正常，未检测到交换机层面的错误。因此，服务器失联的问题极大概率并非由本交换机引起。

可能的根本原因指向:

• 服务器本身: 操作系统故障、网卡驱动问题或网络配置错误。
• IP 地址冲突: 服务器的IP地址可能与网络中其他设备冲突。
• 上游/下游网络策略: 可能存在防火墙或路由器的ACL策略阻止了服务器的通信。

建议的下一步排查步骤:

1. 检查服务器状态: 确认服务器系统、服务及网络配置（IP、网关、DNS）。
2. 验证IP地址冲突: 在交换机上使用 show arp | include [服务器IP] 检查ARP映射。
3. 测试端到端连通性: 从同一VLAN内的其他设备Ping服务器，以及从服务器Ping其网关(192.168.22.xxx)。
4. 物理介质检查: 考虑更换网线或服务器网卡。
   …

点评: 这份报告完美展现了AIOps的巅峰潜力。AI不仅像一个真人专家一样，有条不紊地完成了所有排查步骤，更重要的是，在排除了自身管辖范围内的故障后，它没有止步，而是给出了逻辑严谨的诊断结论和一份极其专业、可执行的跨领域排查指南。这标志着它已经从一个“网络运维工具”进化为了一个具备全局视野的“智能故障协调中心”。

3.4 复杂任务下的深度思考能力对决

为了进一步探究不同AI模型在复杂、多步任务下的表现差异，我们设计了一项综合性更强的“系统健康检查”任务，并将其同时交给了我们之前使用的O1-mini模型和另一款国产AI模型DeepSeek-R1。这项任务要求AI自主执行四项关联性不高的检查，并汇总成一份报告，旨在考验其任务规划、并行处理和深度分析能力。

我的指令:

请对 my-core-switch 进行一次全面的系统健康检查。我需要你检查并汇总以下四个方面的情况，并给我一个最终的摘要报告：

1. CPU利用率（过去5分钟）。
2. 内存使用情况（Processor和I/O内存）。
3. 所有物理接口的错误计数器总和。
4. 最新的10条日志信息。

O1-mini 的表现：机械化的串行执行者

O1-mini模型在处理这个任务时，表现得像一个线性的自动化脚本。它开始执行第一个CPU检查任务，并成功返回了结果。然而，在执行第二个“内存检查”任务时，由于show memory命令返回内容过多导致工具超时，它报告了一个连接错误。

致命缺陷： 在遇到这一个子任务的失败后，O1-mini中止了整个健康检查流程，直接放弃了后续的“接口错误检查”和“日志检查”。最终，它只完成了一份25%进度的、残缺的报告，并将所有问题归咎于一个它未能深入分析的“连接错误”。

结论： O1-mini能够机械化地完成基础、独立的任务。也具备一定的反复试错的能力，但面对复杂的、多步骤的综合性任务时，它的处理逻辑是脆弱的、串行的。任何一个环节的失败都会导致整个任务链的中断，缺乏应对复杂现实世界问题的鲁棒性。

DeepSeek-R1 的表现：具备深度思考的智能分析师

与O1-mini形成鲜明对比的是，DeepSeek-R1展现出了惊人的智能和深度。它似乎在内部将四项检查分解为独立的子任务，并成功地完成了所有指令，即使遇到问题也会不断地反复去试错，虽然完成时间上因为长思考的原因会更久，但最终能呈现一份堪称典范的健康报告。

DeepSeek-R1的诊断报告摘要:

系统健康检查报告：my-core-switch

1. CPU利用率（过去5分钟）

| 时间范围      | 利用率 | 状态评估 |
|---------------|--------|----------|
| 5分钟平均     | 4%     | 低负载   |

分析：CPU利用率处于健康范围，控制平面处理能力充足。

2. 内存使用情况

| 内存类型      | 使用率 |
|---------------|--------|
| Processor     | 9.67%  |
| I/O           | 0.69%  |

分析：内存使用率极低，无内存压力。

3. 物理接口错误计数器

| 错误类型         | 总计数 |
|------------------|--------|
| 输入错误         | 0      |
| 输出错误         | 0      |
| ... (所有错误均为0) ...|

分析：全接口错误计数器为零，表明物理层与数据链路层无传输错误。

4. 最新10条系统日志

...
2. Jun 12 10:23:46.456: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to down
...
9. Jun 12 10:45:40.666: %LINK-5-CHANGED: Interface GigabitEthernet0/1, changed state to administratively down
...

关键日志分析：

1. G0/3接口持续存在协议层故障。
2. G0/1接口被管理关闭。

---

最终健康评估摘要

检查项	状态	风险等级	建议
CPU负载	正常	低	无需干预
内存使用	优秀	无风险	持续监控
接口错误	完美	无风险	保持当前状态
日志事件	注意	中	需处理G0/3协议故障

综合结论：
设备整体健康状态优秀，但需重点关注G0/3接口的协议层故障。

建议行动：

1. 立即解决G0/3协商问题（强制速率/双工）。
2. 确认G0/1关闭是否属于计划维护。

点评： 这份报告的含金量极高。DeepSeek-R1不仅完整地执行了所有任务，更展现了几个关键的“智能”特质：

1. 数据聚合与定性分析：它没有罗列枯燥的数字，而是给出了“低负载”、“优秀”等定性判断。
2. 上下文关联：它能从最新的日志中，关联到我们之前排查过的G0/3端口问题，显示了强大的上下文记忆和分析能力。
3. 风险评估与决策：最终的“摘要”表格一目了然地指出了风险等级，并给出了具体、可行的“建议行动”，这已经超越了“报告”，进入了“决策支持”的范畴。

对决结论：
通过这次对比，我们可以得出一个清晰的结论：在处理需要深度思考、多步推理和综合判断的复杂问题时，以DeepSeek-R1为代表的国产AI展现出了远超普通模型的强大能力。它不再是一个简单的任务执行工具，而更像一个能够独立思考、规划并解决问题的“AI专家”。而O1-mini等模型，在现阶段则更适合执行明确、单一的基础自动化任务。这也为我们未来的AIOps实践指明了方向：选择合适的AI模型，是决定项目成败和智能深度的关键所在。

四、未来方向：MCP的星辰大海

本次实践成功地将AI转变为一个Cisco网络专家，但这仅仅是冰山一角。MCP协议与大模型的结合，正为AIOps开启一扇通往未来的大门。

1. 从“被动响应”到“主动防御”：意图驱动的AIOps
   未来的MCP服务将不再仅仅是执行命令的工具。我们可以构建一个“网络意图MCP服务”。运维人员不再说“把G1/0/5端口划入VLAN 10”，而是陈述最终意图：“确保新来的市场部员工PC能访问内网文件服务器和外网”。AI会自己去规划需要配置哪个交换机、哪个端口、哪个VLAN、哪条ACL，生成完整的配置脚本，并在“沙箱”中验证无误后，待审批执行。这是一种更高维度的自动化。

2. 融合多模态：迈向真正的“数字孪生”
   正如马斯克的Grok-4所展示的趋势，未来的模型将是多模态的。我们的cisco-mcp可以与fortigate-mcp（用于绘制拓扑图）等服务进行联动。当诊断故障时，AI不仅能返回文本报告，还能实时地在高亮显示故障路径的网络拓扑图上进行标注，甚至结合摄像头的视频流（例如机房摄像头MCP）来判断“端口灯不亮”这种物理问题。这使得运维从“看命令行”进化到“看数字孪生驾驶舱”。

3. AI Agent集群与分布式决策
   我们可以为网络、服务器、数据库、应用程序各部署一个专精的AI Agent（MCP服务）。当出现“应用访问缓慢”这种复杂问题时，应用AI会首先自检，然后向网络AI发出请求：“请检查从我到数据库服务器10.1.1.5的网络延迟和丢包率”。网络AI完成检查后，可能会再向服务器AI发出请求：“请检查10.1.1.5的CPU和磁盘I/O”。这些AI Agent组成一个分布式的智能诊断集群，通过MCP协议互相协作，在数秒内完成跨多个技术领域的复杂故障定位，这是任何单一的人类专家都难以企及的效率。

结语

从一个简单的show version命令，到一个全自动的故障诊断报告，我们见证了MCP协议与高阶提示词工程相结合所爆发出的巨大能量。AIOps不再是遥远的概念，它正通过像cisco-mcp这样的实践，具体而微地改变着我们的工作方式。未来已来，而我们每个人，都有机会成为这场智能变革的构建者。