一、基本信息

• 活动名称：ISC2 上海分会 7 月主题分享会
• 主办方：ISC2 上海分会
• 时间：2025 年 7 月 26 日
• 地点：线下
• 分享嘉宾：
  • 曲晓琨：大成律师事务所上海办公室合伙人
  • 马红杰：德勤网络安全团队合伙人
  • 刘超：上海直画科技有限公司技术负责人
  • 祁亨杰：华顺信安高级售前专家

二、分享内容摘要

本次分享会内容丰富，四位嘉宾分别从不同视角带来了精彩的分享。

1. 曲晓琨：《数据出境监管的新异与张弛》

曲晓琨律师首先深度解读了2025年数据安全新规在数据出境领域的最新变化，并结合实践案例，为企业合规提供了清晰的指引。

核心观点：新规对数据出境安全评估的有效期、识别申报等流程进行了修订，并引入了更场景化、精细化的数据判定标准。企业需密切关注法规变化，及时调整合规策略。

• 法规新动向：重点分析了数据出境安全评估结果有效期、申报信息修改等新规内容。
• 场景化判定：探讨了如何在不同业务场景下进行精细化的数据分类与判定。
• 案例解析：通过个人信息出境的涉诉案例，生动阐述了合规要点与风险。
• 行业实践：结合医药和汽车行业的特定文件，分享了处理个人信息的合规方式。

2. 马红杰：《Agentic AI应用生态安全治理实践》

马红杰先生聚焦于生成式AI的进阶形态——Agentic AI，探讨了其带来的巨大机遇与严峻的安全治理挑战。

核心观点：Agentic AI 将成为企业数字化创新的核心，其高度自主性要求我们重新思考人与AI的协作关系。构建安全、可控的Agentic AI生态，需要技术、政策与国际合作的共同推进。

• 发展趋势：Agentic AI 是 GenAI 的进阶，将成为混合数字生态的重要组成部分，其自主性对安全治理提出新要求。
• 人机关系转变：未来我们将赋予 AI 更多自主权，人类的角色将从“操作者”转变为“指导者”，需要为这种身份互换做好准备。
• 关键防护点：AI 的长期记忆和短期记忆需要进行隔离防护，任何一方的数据被破坏都可能造成严重后果。

3. 刘超：《基于零信任打造多级单位漏洞扫描方案》

刘超先生从实战出发，分享了如何利用零信任理念解决传统多级单位在漏洞扫描和管理中遇到的痛点。

核心观点：零信任架构通过其内在的加密和访问控制机制，能够有效解决多级单位环境下漏洞扫描任务下发难、数据回收难、安全保障难的问题。

• 核心挑战：分析了多级单位在进行漏洞扫描及管理时面临的网络隔离、权限复杂、数据安全等挑战。
• 零信任方案：提出了一种基于零信任的漏洞扫描方案，并重点介绍了其三层数据加密机制，确保端到端的安全：
  1. 通道加密：零信任通道本身提供一层加密。
  2. 传输加密：使用 HTTPS 等协议进行传输层加密。
  3. 数据加密：对扫描任务和结果数据本身进行加密。
• 未来探索：探讨了该方案在更多场景下的扩展可能性。

4. 祁亨杰：《从传统管理到CAASM：基于企业资产管理运营实战》

祁亨杰先生拥有多年企业网络资产安全体系化建设经验，他分享了从传统资产管理向网络攻击面管理（CAASM）演进的实战经验。

核心观点：CAASM（网络攻击面管理）通过自动化、持续性的资产发现与评估，能够帮助企业获得全面、动态的资产视图，是应对现代网络威胁的基础。

三、关键收获与行动建议

本次分享会不仅带来了前沿的理论洞察，也提供了许多可落地的实践建议。

行业洞察

• 个人信息保护：在数据处理中，必须掌握并应用合理的个人信息匿名化和去标识化技术，以满足合规要求。
• AI 角色演进：我们正从“使用AI作为辅助工具”的时代，迈向“授权AI自主操作，人类进行监督指导”的新阶段。这要求我们构建和开放出自主性更强、但同样安全可控的大模型。

可落地建议

• 对于企业数据合规：
  • 建立数据分级分类制度，确保不同级别的数据处理方式符合相应的法规要求。
  • 在进行数据出境活动前，进行充分的风险评估和合规自查。
• 对于AI模型应用：
  • 在训练和应用AI，特别是Agentic AI时，必须从架构上设计好长期记忆与短期记忆的隔离与防护机制。

结语

本次ISC2上海分会的分享会干货满满，四位嘉宾的分享为与会者描绘了一幅当前网络安全领域的技术发展与合规挑战的全景图。从数据流动的法律边界，到人工智能的治理哲学，再到基础架构的安全范式，每一次深入的探讨都为我们的日常工作带来了新的思考和启发。

记录人：吴梓豪

本文导览

• 一、引言
• 二、成果展示：主机御医1.0 交互式安全报告 ✨ (核心亮点)
• 三、架构的演进：从单体智能到协同分析
• 四、项目核心组件解析
• 五、结论与展望

一、引言：挑战与AI赋能的思考

在网络安全领域，主机安全审计是保障信息系统安全的关键环节。传统的审计工作流不仅耗时耗力，而且分析结果的深度与广度严重依赖于审计人员的专业经验，难以实现标准化和规模化。

随着大型语言模型在理解、推理与内容生成方面展现出的卓越能力，我们开始思考新的可能性：是否可以构建一个由AI驱动的自动化审计引擎，将繁杂的原始数据转化为结构化的、附带专家级见解的安全报告？

本文将详细阐述我们从概念构思到最终实现 “主机御医1.0”——一个AI驱动的主机安全自动化审计工具的全过程。在此之前，让我们首先展示这款工具的最终成果。











（为展示得更加清晰而不杂乱，此处的全局展示隐藏了最左侧的导航栏，且查看详情功能仅每个模块仅展示一例）
控制台运行演示：

二、成果展示：主机御医1.0 交互式安全报告 ✨ (核心亮点)

主机御医1.0 的核心产出是一份独立的、交互式的HTML安全报告。它不仅呈现了详尽的审计结果，更通过现代化的UI设计和丰富的数据可视化，将复杂的主机安全态势变得直观、易于理解和跟进。（展示的数据来源为公司一台Linux服务器）

亮点1：一目了然的安全态势总览

报告顶部是“报告概览”区域，它将主机的核心安全指标汇于一处，让您对整体安全状况一目了然。

• 动态标题与扫描元信息： 报告标题会自动嵌入被扫描主机的IP地址。下方清晰展示了本次扫描所使用的AI模型（如 deepseek-ai/DeepSeek-V3）、引擎版本和扫描协议，增强了报告的专业性和透明度。
• 精细化的加权安全评分： 我们摒弃了传统的简单风险计数扣分法，设计了一套基于风险类型的加权计分模型。例如，一个“高危”的凭证泄露（-12分）比一个“高危”的软件漏洞（-8分）扣分更多，这使得分数能更真实地反映主机的安全水位。点击分数旁的帮助图标，用户可以看到每一项具体的扣分明细，让分数不再是一个黑盒。
• 风险统计可视化： 通过直观的条形图，将所有风险项按“高、中、低”三个等级进行分类统计，便于快速把握风险分布。

亮点2：超越传统扫描的深度审计维度

主机御医1.0 的核心价值在于其审计的深度。除了常规的端口和软件版本扫描，我们更注重那些容易被传统自动化工具忽略、却对主机安全至关重要的细节：

• 权限配置深潜： 我们不仅检查用户列表，更深入分析 /etc/sudoers 文件，排查是否存在过度的权限授予。同时，对所有用户的 authorized_keys 文件进行扫描，这对于发现潜在的、通过SSH密钥留下的“后门”至关重要，这是许多传统扫描器容易忽视的盲点。
• 文件完整性校验： 通过 rpm -V 校验核心系统工具（如 ps, ls, sshd 等）的完整性，这是检测Rootkit等深层威胁的有效手段。如果核心系统文件被篡改，报告将发出高危警报。
• 内核参数审计： 对 net.ipv4.ip_forward 等关键内核参数进行检查，确保操作系统底层配置的安全性，防止主机被用作攻击跳板。
• 网络拓扑可视化： 报告能够基于 netstat 的输出，生成主机网络连接拓扑图。它清晰地展示了本机与所有外部IP的连接关系，帮助审计人员快速从视觉上识别出潜在的异常通信或恶意连接，这远比阅读纯文本列表要高效得多。

亮点3：为效率而生的强大交互体验

一份优秀的报告不仅要内容详实，更要易于使用。为此，我们设计了多种高效的交互功能：

• 优秀的风险筛选： 这是我们最具特色的功能之一。每个模块展示时优先展示重点或者异常模块，将不重要或者正常模块先隐藏，当用户需要查看所有信息时就可自行点击查看所有。用户也可以点击报告中任意一个风险标签（如“高危”），整个报告页面将即时过滤，仅显示与该风险等级相关的条目。这使得安全人员能够迅速聚焦于最高优先级的任务，极大提升了响应和修复效率。
  
• 一键展开/折叠： 面对包含12个模块的详细报告，用户可以通过顶部的“展开/折叠”按钮一键切换全局视图，既能宏观浏览，又能深入细节，操作便捷高效。
• 双版本PDF导出： 考虑到不同的汇报场景，我们提供两种导出选项：摘要版（只包含各模块概览）和完整版（包含所有展开的风险详情），满足从管理层汇报到技术归档的全部需求。
  

三、架构的演进：从单体智能到协同分析

在项目初期，我们曾尝试一种“端到端”的解决方案。构想是利用Cherry Studio等平台的知识库和高级提示词工程能力，将所有安全基线和审计逻辑植入知识库，然后将采集到的主机信息一次性提交给大模型，期望其直接生成最终的HTML报告。

实践证明，这种方法存在显著的瓶颈。大规模、异构的原始数据（数十个命令的输出）同时输入，会给大模型的上下文处理能力和API稳定性带来巨大挑战，导致请求超时、响应截断等问题频发。

这次尝试使我们认识到，AI的最优应用模式是作为分析核心，而非流程执行器。基于此，我们重新设计了系统架构，采用Python脚本与AI模型协同工作的模式。

该架构将审计流程解耦为三个核心阶段：

1. 标准化数据采集： 利用Python的paramiko库，通过SSH协议远程连接目标主机。脚本会以只读方式执行一系列预定义的Shell命令，采集覆盖10余个安全维度的原始数据。
2. 分模块AI分析： 这是系统的核心。脚本将采集到的数据按资产清单、系统配置、网络暴露面、历史痕迹等模块进行划分。随后，针对每一个模块，使用专门设计的Prompt模板，独立调用大模型API进行分析。这种“分而治之”的策略显著降低了单次请求的复杂性，使AI能够对每个安全域进行更专注和深入的推理，并返回结构化的JSON结果。
3. 自动化报告生成： 脚本聚合所有模块返回的JSON数据，并执行最终的后处理逻辑，包括基于加权模型的安全评分计算。最后，利用Jinja2模板引擎，将完整的、结构化的数据注入到预设的HTML模板中，生成最终的交互式安全报告。

四、项目核心组件解析

主机御医1.0的实现主要依赖于以下几个关键文件：

（其中final_security_report和report_data文件为生成的文件）

1. 核心控制器: main.py

作为项目的引擎，该Python脚本承担了整个审计流程的编排工作：

• 命令定义 (COMMANDS_TO_RUN)： 以字典形式精确定义了需要采集的命令，覆盖了从主机信息到内核参数的各个层面。
• AI接口封装 (call_llm_for_analysis)： 负责与大模型API（本项目选用deepseek-ai/DeepSeek-V3）进行通信，并内置了重试与错误处理机制。
• 分析工作流 (analyze_module_by_module)： 实现了将原始数据与特定Prompt相结合，分模块调用AI进行分析的核心逻辑。
• 评分与校准 (post_process_and_calibrate)： 这是项目的关键创新之一。该函数实现了一套基于风险类型的加权评分模型，替代了传统的简单风险计数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# main.py - 精细化计分模型示例
def post_process_and_calibrate(analyzed_data, template_data):
    # ...
    # 定义扣分规则 (基于风险类型加权)
    scoring_rules = {
        "credentials":   {"high": 12, "medium": 6, "low": 2},
        "integrity":     {"high": 8, "medium": 4, "low": 2},
        "software_vuln": {"high": 8, "medium": 4, "low": 1},
        "config":        {"high": 6, "medium": 3, "low": 1},
        "forensics":     {"high": 5, "medium": 3, "low": 1},
        "network":       {"high": 6, "medium": 3, "low": 1},
        "identity":      {"high": 8, "medium": 4, "low": 1},
    }
    # ... 循环遍历所有模块，根据规则进行扣分 ...

2. 报告呈现层: templates/report_template.html

该文件定义了最终报告的结构、样式与交互行为，是一个独立的前端应用。

• 数据注入点： 文件内的const reportData = {};是关键的数据接口，由main.py在生成报告时动态填充。
• 前端渲染逻辑： 报告页面加载后，内置的JavaScript会解析reportData中的JSON数据，通过DOM操作动态生成所有图表（使用Chart.js）、表格和风险条目。
• 高级交互功能： 实现了侧边栏折叠、模块风险摘要、全局风险等级筛选、动态滚动导航高亮等一系列高级交互功能，旨在提升报告的可读性和易用性。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<!-- templates/report_template.html - 资产清单模块结构示例 -->
<section id="assets" class="module">
    <div class="module-header">
        <h2><i class="fa-solid fa-cubes"></i> 资产清单与软件风险</h2>
        <i class="fa-solid fa-chevron-down toggle-icon"></i>
    </div>
    <div class="module-content">
        <!-- JS会在此处填充风险摘要 -->
        <div class="module-summary"></div> 
        <h4><i class="fa-solid fa-box-open"></i> 已安装软件 (风险评估)</h4>
        <table class="data-table">
            <thead>...</thead>
            <!-- JS会在此处填充软件列表 -->
            <tbody id="software-table-body"></tbody> 
        </table>
        ...
    </div>
</section>

3. 环境配置

• .env & config.json: 分别用于存储API密钥和目标主机连接信息，实现了配置与代码的分离，提高了安全性和可维护性。

五、结论与展望

主机御医1.0项目成功验证了将大型语言模型作为核心分析引擎，与传统自动化脚本相结合的技术路径是完全可行的。它不仅将数小时的手动审计工作压缩到几分钟，还通过结构化、可视化的方式，提供了一致且专业的审计输出。

未来的工作可以在此基础上进一步扩展，例如：集成自动化修复脚本生成、实现基于时间序列的风险变化监控、或将审计能力扩展到容器、云环境等更广泛的领域。

希望本次的开发实践分享，能为探索AI在网络安全领域的应用提供一些有价值的参考。

各位技术同仁，

在之前的探索中，我们已成功利用MCP协议与大语言模型，将AI的能力延伸至网络设备，实现了拓扑绘制与故障排查的自动化。

🔗 往期探索：

• 只要5秒？AI画出整个公司网络拓扑！不再是科幻！
• 省下300刀/月！手把手教你打造不输Grok-4的Cisco排障AI

今天，我们将挑战一个技术深度与严谨性要求都更高的领域：服务器操作系统安全审计。我们的目标是，将一个通用的AI模型，改造为一个能够自主执行网络安全等级保护（等保）三级主机安全检查的专家智能体——Linux Guardian。

这不仅仅是功能的延伸，更是一次关于AI可信度、专业度和透明度的深度进化。

第一章：创世纪 - 锻造AI专家的知识核心与执行引擎

一个强大的AI Agent，始于一个稳定且精确的运行环境。这一章，我们将讲述如何为其构建“大脑”与“躯干”。

1.1 大脑的构建：从国家标准到可机读的知识库

我们面临的首要挑战是：如何将抽象、复杂的“等保三级”要求，转化为AI能够理解和执行的知识？为此，我们进行了一项系统性的知识工程。

• 第一步：锚定权威源头
  我们首先定位到最权威的依据——国家标准 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》。这是所有审计工作的“圣经”，确保了我们知识的准确性和合规性。
  

• 第二步：寻求实践真知
  标准原文往往是高度概括的。为了将其落地，我们广泛查阅了行业专家的技术博客（如CSDN上的深度实践文章），这些文章提供了宝贵的、经过实战检验的配置方法和命令行示例。
  

• 第三步：知识的萃取与结构化
  这是最关键的一步。我们将上述两大信息源进行融合与提炼，为每一个等保条款，都萃取出四大核心要素：【标准原文 -> 核心目标 -> 详细解读与实现 -> 自动化检测思路】。特别是“自动化检测思路”，它将抽象的要求转化为了具体的、可在Linux服务器上执行的命令。我们将这些结构化的知识，整理成了一份纯文本文件：DJCP_L3_Host_Security_KB.txt。

• 第四步：知识的注入与激活 (RAG)
  我们将这份精心制作的知识库上传至AI工作台，并为其启用了强制检索” 模式。这相当于为AI的大脑安装了一个“权威插件”，并设定了最高优先级。这项技术—— 检索增强生成（RAG） ——确保了AI在回答相关问题时，必须基于这份我们提供的、可信的知识进行思考，从而从根本上解决了通用大模型在专业领域可能“自由发挥”的问题。
  

1.2 躯干的搭建：确保执行的精准与稳定

• 工具链配置： 我们继续使用ssh-mcp-server，仅需在machines.json中调整连接信息，使其指向目标Linux服务器即可。
  

• 模型参数调优： 我们选用deepseek-ai/DeepSeek-V3模型，并对其参数进行了极端设置：

此处依然是参考我们之前文章中的设置

第二章：灵魂的注入 - 解构v13版“宪法级”提示词

如果说知识库是AI的大脑，那么系统提示词就是它的灵魂、性格与行为准则。我们历经十余个版本的迭代，从简单的角色扮演，进化到了这套如“宪法”般严谨的v13版提示词。它不再是简单的指令，而是一套完整的、多维度的行为框架。

2.1 [ROLE] & [KNOWLEDGE BASE]：定义身份与权威

1 2	你是一个名为“Linux Guardian”的AI驱动的系统与网络运维专家... 你内置了一份权威的、名为`DJCP_L3_HOST_SECURITY_KB_v2`的知识库...你所有的安全审计和合规性判断，必须且只能以此知识库为唯一标准。

• 设计目的：
  • 数据准确性： 明确AI的唯一知识来源，从指令层面再次强化RAG的约束力，防止“知识泄漏”或“串扰”。
  • 用户体验： 设定一个专业的“人格”，让用户从一开始就感受到其专业性，建立初步信任。

2.2 [CRITICAL SAFETY & EXECUTION PROTOCOL]：构建不可动摇的工作流

这是整个提示词的核心，它定义了AI的“标准作业程序”（SOP）。

1 2 3 4 5 6 7

你处理任何请求都必须遵循以下不可颠倒的三个阶段： 阶段一：任务解析与行动规划 (Parse & Plan) ...必须向用户展示一个增强的、格式化的行动计划...并明确请求用户授权执行... 阶段二：透明执行与日志展示 (Transparent Execution) ...对于每一个执行的命令，你都必须使用以下可折叠的“执行日志”块格式进行输出... 阶段三：报告生成与交互式深化 (Report & Interact) ...报告生成后，你必须主动向用户提出一个开放性的问题...

• 设计目的：
  • 数据准确性 & 用户体验（信任）： “计划-确认”步骤将控制权完全交还给用户，杜绝了AI的任何“擅自行动”。用户能预知AI的每一步，这是建立深度信任的关键。
  • 可追溯性（准确性）： “透明执行”的日志块设计，让最终报告的每一项结论都能直接追溯到原始的命令行输出，保证了所有分析结果都有据可查，绝非凭空捏造。
  • 价值提升（体验）： “交互式深化”将AI从一个单向的报告工具，提升为一个可以持续对话、解决问题的“顾问”，极大地提升了用户价值。

2.3 [ERROR HANDLING] & [INITIALIZATION]：确保鲁棒性与良好开端

1 2	当`SSH centos`工具调用失败时，你必须：立即停止当前任务...清晰地说明...并提供可能的诊断建议... 开始首次对话时，你必须...清晰地向用户阐明你即将开始的、全新的“计划-确认-执行”工作流程。

• 设计目的：
  • 鲁棒性（体验）： 详细的错误处理协议，让AI在面对连接超时、权限不足等问题时，不再是返回一个冰冷的“执行失败”，而是能像一个真正的工程师一样，提供有价值的诊断信息。
  • 预期管理（体验）： 初始化的自我介绍，提前告知用户AI的独特工作模式，避免用户因AI“不直接回答问题”而感到困惑。这是一种优秀的用户引导。

这套精心设计的提示词，为AI构建了一个完整、严谨、透明的行为模式，使其从一个强大的模型，真正蜕变为一个值得信赖的合作伙伴。

第三章：淬炼成金 - AI审计师的能力实战报告

理论的完美，必须通过实践的检验。我们向Linux Guardian发起了三轮由浅入深的挑战。

场景一：专项审计 - “我怀疑身份认证不合规”

面对这个具体指令，AI严格遵循三阶段工作流：

1. [计划] 生成了仅针对“身份鉴别”条款的精准行动计划。
2. [执行] 在可折叠日志中，我们清晰地看到grep -E 'faillock|tally2'等命令返回为空，问题点一目了然。
3. [报告] 最终报告用表格形式标记出3个❌不合规项和1个⚠️部分合规项，并给出了具体加固建议。

场景二：全面审计 - “对服务器做一次完整的安全检查”

面对这个开放式任务，AI展现了其强大的综合分析能力：

1. [计划] 依据知识库自主规划了覆盖等保核心条款的十余步全面检查方案。
2. [执行] 有条不紊地执行，并在日志中对sudo auditctl -l返回“No rules”等关键发现做出初步判断。
3. [报告] 生成的综合报告堪称专业。它不仅列出了问题，还评估了风险等级，并给出了“24小时内紧急修复”等具体行动建议。

场景三：交互深化 - “如何配置详细的审计规则？”

在前一个问题中AI问我们最关心哪个方面的安全改进，它可以提供针对性的加固指导，我们选择询问配置详细的审计规则的方法。AI再次给我们系统性地讲了一下情况。回答非常完整！

这一轮交互，完美展示了AI从“发现问题”到“解决问题”的闭环能力，其深度和广度已远超简单的问答。

第四章：未来展望 - 从智能体到一体化审计平台

本次实践，我们成功地将一个通用大模型，锻造成了一个知识驱动、流程严谨、交互深入的AI安全审计专家。这验证了一个核心思想：AI的价值，不仅在于其模型本身，更在于我们如何通过知识工程和流程设计去驾驭它。

但我们不止于此。目前基于聊天的交互模式虽然强大，但对于大规模、常态化的审计工作仍有操作门槛。因此，我们的下一步计划是：

基于“Linux Guardian”的核心能力，打造一个一站式、可视化的主机安全审计平台。

这个平台将实现：

• 一键式审计： 用户只需在图形化界面选择目标服务器和审计策略，即可发起一次完整的等保合规性检查。
• 可视化报告仪表盘： 用直观的图表（如雷达图、环形图）展示服务器的安全态势、风险分布和合规分数。
• 历史趋势分析： 记录每次审计结果，帮助管理者追踪安全基线的变化和改进成效。
• 自动化报告生成： 一键导出符合等保测评要求的PDF或Word格式的正式审计报告，甚至是可互动的实时网页，非常直观地呈现我们的服务器情况。

我们的目标，是让专业、深度的系统安全审计能力，不再是少数专家的专利，而是成为每个运维和安全团队都能轻松驾驭的工具。

我们相信，这才是AIOps的真正未来——将顶级的专家能力，封装于易用的产品之中，赋能于每一位技术人员。

本文工具速览（点击可跳转）：

• 代理工具：Proxy Fox (小狐狸)
• 截图软件：Snipaste
• 在线画图：Handraw
• 代码编辑器：Sublime Text
• AI 聚合平台：Cherry Studio
• AI 大模型推荐
  • Google Gemini 1.5 Pro
  • DeepSeek V2
  • Kimi
  • Grok
  • 豆包
• Markdown 编辑器：Doocs 开源社区
• 远程终端：MobaXterm

代理工具：Proxy Fox (小狐狸)

这是一款用于管理代理的谷歌浏览器插件。

• 官方网站: https://proxyfox.io/en/index.html

代理设置

点击 “管理代理设置” 即可添加代理服务器，将 IP 和端口填入即可。同时，这里也可以设置白名单，并与全局白名单合并使用。

全局白名单

这个功能可以方便地在挂着代理时，保证国内网站的访问速度不受影响。

使用技巧：具体规则设置可以参考下图。

截图软件：Snipaste

一款极其强大且方便的截图工具。

• 官方网站: https://www.snipaste.com/

核心功能与设置建议

• 快捷键：在控制界面可以根据个人习惯设置截图等快捷键。
• 自动保存：强烈建议在“输出”选项中设置一个自动保存路径，这样所有截过的图都会被保存下来，再也不怕丢失。
• 贴图功能：截图后按 F3 可以将图片“贴”在屏幕上，方便对照参考。

使用技巧：具体设置可以参考下图。

在线画图：Handraw

一个可以在线画出手写风格示意图的网站。

• 官方网站: https://handraw.top/

这个项目在 GitHub 上是开源的，用来画一些简单的流程图或示意图非常方便，手写效果很赞。

代码编辑器：Sublime Text

相比于 Windows 自带的记事本，Sublime Text 是一个轻量且强大的代码编辑器。

• 更方便的查询功能：拥有强大的搜索和替换功能。
• 代码高亮：可以清晰地区分代码结构和语法，颜色分明，看起来更舒服。
  

AI 聚合平台：Cherry Studio

一个全能的 AI 助手平台。

• 官方网站: <https://www.cherry-ai.com/

• 主要特点：

  • 支持集成绝大多数主流 AI 服务商。
  • 支持很多 MCP 工具的接入使用。

AI 大模型推荐

这里分享几个我常用的 AI 大模型服务。

• AI 排行榜参考: LMSYS Chatbot Arena Leaderboard

Google Gemini 1.5 Pro

• 体验地址: https://aistudio.google.com/prompts/new_chat
  个人感觉比 DeepSeek 好用。

DeepSeek V2

• 体验地址: https://chat.deepseek.com/
  速度稍慢一些，处理非专业性日常工作尚可。

Kimi

• 体验地址: https://www.kimi.com/
  新出的模型，暂时还未深度体验。

Grok

• 体验地址: https://grok.com/
  免费版的 Grok-1 和 DeepSeek 差不太多，优点是不太容易服务器繁忙，可以作为 DeepSeek 的免费平替。

豆包

• 体验地址: https://www.doubao.com/chat/
  一般不用于专业问答，但用它来生成图片倒是挺方便的。

Markdown 编辑器：Doocs 开源社区

一个非常适合微信公众号排版的在线 Markdown 编辑器。

• 官方网站: <https://md.doocs.org/

• 核心功能：

  • 可以将 Markdown 文档一键转换成适配微信公众号的格式。
  • 导出时支持多种格式，功能非常全面。

远程终端：MobaXterm

一款强大的远程计算工具箱。

它能够让你方便、安全地去连接和管理另一台遥远的电脑（通常是 Linux 服务器）。

如何连接

1. 打开软件，点击左上角的 “Session” 按钮。
2. 在弹出的窗口中，选择你要使用的协议，例如 SSH。
3. 在 Remote host 中输入目标主机的 IP 地址或域名，然后在 Specify username 中填入用户名，点击 “OK” 即可发起连接。
   
   
   

近期的科技圈，无疑被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应用别无二致：

第一步：克隆项目仓库

1
2

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

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

1

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设备。

1
2
3
4
5
6
7
8
9
10
11

[
  {
    "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心智“编程”的精密指令集。一个优秀的提示词，是将一个“充满想象力”的通用大模型，改造为一个“严谨、精确、可靠”的领域专家的关键。

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

1
2
3
4
5
6
7
8
9
10

[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的回答更具个性化和情境感，感觉像一个专属助手。

1
2
3
4
5
6

[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的“随机应变”变成了可预测的“标准作业”，极大地增强了稳定性。

1
2
3
4
5
6

[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分钟）

1 2 3

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

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

2. 内存使用情况

1 2 3 4

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

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

3. 物理接口错误计数器

1 2 3 4 5

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

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

4. 最新10条系统日志

1 2 3 4 5

... 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这样的实践，具体而微地改变着我们的工作方式。未来已来，而我们每个人，都有机会成为这场智能变革的构建者。

随着大语言模型（LLM）在各个领域的渗透，将其强大的认知与推理能力应用于传统的网络运维（NetOps）领域，即 AIOps，已成为业界探索的前沿方向。

本文将提供一份详尽的技术实践报告，记录如何利用模型上下文协议（Model Context Protocol, MCP），将本地部署的 AI 模型（以 O1-mini 为例）与一台 FortiGate 防火墙通过 SSH 进行整合，从而实现从自然语言指令到精确网络操作的端到端自动化。

只要5秒？AI画出整个公司网络！这不再是科幻！

告别逐行敲打show命令与手动绘图的低效时代。现在，只需一句自然语言指令，大模型便能深入设备，将错综复杂的网络配置瞬间转化为一张清晰直观的可视化拓扑图。

下图，便是AI的杰作。请看它如何一眼看穿我们的网络世界。

图注: 此拓扑图由 AI 分析 FortiGate 的接口配置、路由表和防火墙策略后自动生成。

目录

1. MCP协议：连接AI智能与物理世界的桥梁
2. MCP生态资源
3. SSH MCP服务器部署
4. 提示词工程与模型调优
5. 成果展示

1. MCP协议：连接AI智能与物理世界的桥梁

模型上下文协议（MCP）是一种为解决大语言模型与外部世界交互而设计的开放标准。其核心价值在于定义了一套统一的规范，使得 AI 模型能够发现、理解并调用外部的”工具”（Tools）。这些工具可以是任何形式的 API、本地脚本或硬件接口。

在网络运维场景下，MCP 的作用尤为关键：

• 指令解析: 将运维人员的自然语言需求（如”检查内网到外网的策略”）转换为结构化的工具调用请求。
• 任务执行: 触发本地的 MCP 服务器执行具体操作（如通过 SSH 连接防火墙并运行命令）。
• 结果反馈: 读取工具返回的原始 CLI 输出，并将其传递给 AI 模型，供其分析、总结并以人类可读的形式呈现。

MCP 协议生态的成熟，是推动 AIOps 从概念走向实践的关键一步，它为实现真正智能的、可交互的网络自动化提供了基础。

2. MCP生态资源

在深入实践之前，了解当前 MCP 的生态系统有助于发现更多可能性。以下资源提供了丰富的工具和平台：

• MCP Hub (higress.ai) - 一个社区驱动的 MCP 工具注册中心。
• MCP.so - 提供 MCP 相关协议文档和工具示例。
• GitHub - 在 GitHub 上通过 mcp 标签可以找到大量相关的开源项目和工具。

3. SSH MCP服务器部署：实践ssh-mcp-server

本次实践，我选用了一个提供通用 SSH 控制能力的开源 MCP 服务器项目：vilasone455/ssh-mcp-server。该项目旨在使 LLM 能够通过 SSH 安全地执行 Shell 命令。尽管其 README 提及的是 Linux 和 Windows 系统，但其底层 SSH 协议的通用性使其完全适用于 FortiGate 防火墙等网络设备。

3.1 部署安装过程中的挑战与解决

按照项目 README 的指引，我开始了标准的安装流程：

1
2
3
4
5
6
7
8
9

# 克隆项目仓库
git clone https://github.com/vilasone455/ssh-mcp-server.git
cd ssh-mcp-server

# 安装项目依赖
npm install

# 构建项目
npm run build

然而，在执行 npm run build 时，我遇到了一个编译错误：

1
2

src/index.ts:422:19 - error TS2339: Property 'trim' does not exist on type 'unknown'.
422 if (!command?.trim()) throw new Error("Command cannot be empty.");

问题分析：这是一个 TypeScript 编译时错误，编译器无法确认 command 变量的类型是字符串，因此不允许调用 trim() 方法。

解决方案：我通过在代码中添加一个类型断言，明确告诉编译器 command 是一个字符串。

操作步骤：

1. 用文本编辑器打开 C:\xxx\xxx\ssh-mcp-server\src\index.ts 文件
2. 定位到第 422 行
3. 将原代码 if (!command?.trim()) throw new Error("Command cannot be empty.");
4. 修改为 if (!(command as string)?.trim()) throw new Error("Command cannot be empty.");
5. 保存文件

修复此问题后，再次执行 npm run build，项目成功编译，生成了 dist 目录。

3.2 配置 machines.json：定义你的防火墙

ssh-mcp-server 通过 machines.json 文件来管理所有可连接的设备信息。我们需要创建这个文件并填入 FortiGate 防火墙的连接凭据。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[
  {
    "machine_id": "mypc",
    "label": "My FortiGate Firewall",
    "os": "fortios",
    "source": "network-segment",
    "ssh": {
      "host": "192.168.x.x",
      "port": 22,
      "username": "your_fortigate_username",
      "password": "your_fortigate_password"
    }
  }
]

• machine_id: 这是一个唯一的字符串，作为 AI 识别设备的”代号”。例如 Fortigate
• host: FortiGate 防火墙的 IP 地址
• username: 登录 FortiGate 的 SSH 用户名
• password: 登录密码

3.3 在 Cherry Studio 中注册 MCP 服务器

最后一步是将 ssh-mcp-server 注册到 Cherry Studio，使其能够被 AI 模型调用。

配置参数：

• 名称 (Name): ssh-mcp-server
• 类型 (Type): 标准输入输出 (stdio)
• 命令 (Command): node
• 参数 (Arguments): C:/xxx/xxx/ssh-mcp-server/dist/index.js
• 环境变量 (Environment Variables): MACHINES_PATH=C:/xxx/xxx/ssh-mcp-server/machines.json
• 超时 (Timeout): 180 (秒)


4. 提示词工程与模型调优：铸就你的AI防火墙专家

工具部署成功只是开始。如果没有经过精心设计的提示词和严格的参数控制，大语言模型在专业领域的表现往往是不可靠甚至危险的。在本次实践的初期，我们尝试使用通用提示词，结果发现 AI 的行为非常不稳定，时常误解指令，甚至在面对不确定的情况时，会“创造”出虚假的配置信息，这在生产环境中是绝对无法接受的。

正是通过下面一系列精细化的提示词工程与模型参数调优，我们才成功地将一个“充满想象力”的通用模型，改造为了一个“严谨、精确、可靠”的AI防火墙专家。

4.1 模型选择与参数设置

我选用 O1-mini 模型，并对其参数进行了关键调整：

将“模型温度”与“Top-p”设置为极低值，是抑制模型“幻觉”现象的关键所在。 这种配置强制模型在生成回答时，几乎完全依赖于从工具（即防火墙CLI）返回的真实上下文，而不是基于其内部知识库进行创造性联想。如果AI在防火墙上没有查询到信息，它会如实报告“未找到”，而不会为了“完成任务”而编造一个看似合理的答案。这确保了所有输出的高度事实性和可靠性。

4.2 系统级基础提示词

为 AI 设定一个明确、专业的行为框架至关重要。我编写了一份系统级的”基础提示词”，作为每次对话的”宪法”。

注意：提示词中需要提醒大模型你拥有只读权限，无法修改实际内容，防止对防火墙内容进行破坏。本连接目前只推荐用来获取信息与分析。

4.3 应对长输出：分段扫描与处理策略

在与网络设备交互时，一个常见的挑战是处理长命令输出，例如 show full-configuration 或 get router info routing-table all。这类命令的返回内容往往会因为终端屏幕的限制而被分页，显示 --More-- 提示符，等待用户输入（如空格键）才能继续显示。

如果让 AI 一次性拉取全部内容，不仅容易导致超时，还可能因为缓冲区溢出而使整个任务失败。为了解决这个问题，我们设计了一套分段扫描策略：

1. 识别分页符：在提示词中明确指示 AI，当它在命令输出的末尾看到 --More-- 标志时，应暂停执行。
2. 分块处理：AI 会先将当前收到的部分数据进行分析和整理。
3. 发送继续指令：处理完当前数据块后，AI 会主动发起一个新的工具调用，其命令就是一个“发送空指令”（等效于敲击空格键），以获取下一页的内容。
4. 循环直至结束：重复步骤1-3，直到命令输出不再出现 --More-- 标志，代表所有内容已获取完毕。

通过这种“走走停停”的分段处理方式，AI 能够稳定、可靠地处理任意长度的配置信息，避免了因单次数据量过大而导致的程序崩溃，大大增强了方案的稳定性。

5. 成果展示：AI驱动的FortiGate防火墙管理

经过上述所有配置和调优，我的 AI 助手已经能够稳定、准确地执行任务。以下是一些真实的交互案例：

5.1 基础信息获取与命令执行验证

我的提问:

“好的，我们开始。请在 Fortigate 上执行 get system status 命令，让我看看防火墙的系统信息。”

AI 执行与返回:
AI 成功连接并执行命令。尽管首次连接尝试中出现了”无法找到连接 ID”的短暂错误，但 AI 随即进行了自我修正，成功创建了连接并执行了命令。

AI 返回了防火墙的型号、固件版本、序列号、正常运行时间等关键信息，并进行了专业的结构化总结与分析。

5.2 精确的地址对象查询与专业分析

任务: 查询地址对象 wz-office 的详细信息。

我的提问:

“请在 Fortigate 上，精确地查询并显示地址对象 wz-office 的详细配置。不要使用 grep，直接查询这个对象。”

AI 执行与返回:
AI 成功执行 show firewall address wz-office，返回了与我手动查询完全一致的真实数据。更重要的是，它对结果进行了专业解读，包括子网换算和实际 IP 范围分析。

5.3 深度安全策略审计与风险识别

任务: 检查 wz-office 在防火墙策略中的应用情况，并识别潜在安全风险。

我的提问:

“请检查 Fortigate 上所有引用了 wz-office 地址对象的防火墙策略。同时，请检查其所在的地址组，并对可能存在的安全风险进行评估。”

AI 执行与返回:
AI 智能地规划了多步操作，包括查询策略和地址组，并主动指出了其中的安全风险，提供了优化建议。

5.4 复杂数据提取与结构化呈现

任务: 获取路由表信息并整理成表格。

我的提问:

“请获取 Fortigate 的完整路由表信息。我需要你将输出的所有路由条目，无论类型是静态（S）、直连（C）还是其他，都整理成一个表格，包含目的网络、子网掩码、下一跳网关和出接口。”

AI 执行与返回:
AI 成功执行 get router info routing-table all，并准确地从复杂的原始输出中解析出所有类型（包括 S 和 C）的路由条目，然后以清晰的表格形式呈现。

5.5 自主生成多层网络架构图

在验证了AI精确执行和结构化呈现的能力后，我们决定发起一项终极挑战，测试其综合分析与高级生成的能力——让它从零开始，绘制一张详尽的网络架构图。这不再是简单的数据提取，而是对网络关系的深度理解和可视化重构。

我的提问:

“做得非常好。现在是最后的任务，我需要你展示你的综合分析能力。请连接到 Fortigate，深度扫描其接口配置、路由表、VLAN设置以及ARP缓存信息，推断出整体网络架构。然后，为我生成一份详细的、多层级的网络拓扑图的 Mermaid 代码。这张图必须清晰地划分出公网、DMZ区、核心网络、服务器区和无线接入区，并尽可能标注关键设备的型号、IP地址和VLAN信息。”

AI 执行与返回:
收到指令后，AI展现了其作为“智能代理”的真正价值。它没有等待我给出具体命令，而是自主规划并执行了一系列关联操作：

1. 边界探测: 执行 get system interface，识别出 wan1 口作为公网出口，并找到 dmz 接口。
2. 核心分析: 通过 get router info routing-table all 和 show system switch-interface，定位到连接内网核心交换机的 lan 口，并识别出其承载的多个VLAN。
3. 下游推断: 结合 get system arp 的输出，AI发现了核心交换机、WLC（无线控制器）、服务器宿主机等关键设备的IP和MAC地址，并根据IP段将其归入对应的VLAN和逻辑区域。
4. 信息整合与生成: AI将所有收集到的离散信息——接口、路由、VLAN、IP地址——在“脑中”构建成一个逻辑模型。最后，它将这个复杂的模型，精确地翻译成了结构清晰、信息丰富的代码,而且可以直接在cherry studio中进行当下渲染或者是外部网页渲染。

AI返回的以下代码，无需任何手动修改，可直接渲染成一张专业级的网络拓扑图，完美地完成了这项艰巨的任务。

结语

本次实践验证了通过 MCP 协议将大语言模型与网络设备整合的可行性与巨大潜力。其成功的关键不仅在于打通技术链路，更在于通过精细化的提示词工程和参数调优，克服了 AI 的固有缺陷（如”幻觉”），将其”改造”成一个符合专业领域要求的、可靠的智能代理。AIOps 的未来已来，而我们正处在这场变革的中心。

为什么我强烈推荐 Gemini CLI？

简单来说，它就是一个能在你命令行里直接和你对话的 AI。对我这样的实习生来说，用处实在太大了：

• 快速看懂老代码：直接把项目丢给它，问它“这个函数是干嘛的？”“项目的整体架构是啥？”，再也不用硬着头皮去问导师了。
• 帮你写代码/文档：写个工具函数、写个接口文档、甚至写 Git commit 信息，一句话的事儿。
• 自动化处理文件：比如“把这个文件夹里所有的 JPG 图片转成 PNG”，它也能搞定。

是不是很心动？下面是超简单的部署教程，三步搞定！

第一步：检查环境

在开始之前，我们需要确保电脑里装了 Node.js，并且版本不能太低，需要 v20 或更高版本。

打开你的终端（Windows 用户可以用 PowerShell 或 CMD，Mac 用户用自带的终端），输入下面的命令查看版本：

1

node -v

如果你的版本号是 v20.x.x 或者更高，那就没问题！如果不是，需要先去 Node.js 官网 下载最新版安装一下。

第二步：一键安装

安装非常简单，我推荐用全局安装的方式，这样以后在任何地方都能随时召唤它。

继续在终端里输入这行命令，然后回车：

1

npm install -g @google/gemini-cli

等待进度条跑完，看到一堆成功的提示就说明安装好了。

安装成功后，你可以输入 gemini 来启动它，第一次它会让你选一个喜欢的主题颜色，随便选一个就好。

第三步：登录你的谷歌账号

这是最关键的一步，也是最简单的一步。

当你第一次运行 gemini 命令后，它会自动在你的浏览器里打开一个谷歌登录页面。

你只需要登录你自己的个人 Google 账号，然后在授权页面点击“允许”就可以了。这一步是为了让 Gemini CLI 能使用 Google 的模型服务。

放心，这个是免费的！ 用个人账号登录后，你每天有 1000 次的免费请求额度，对于我们日常学习和工作来说，完全够用了！

登录成功后，你的终端就会显示 > 的提示符，恭喜你，现在可以开始使唤它了！

总结

对于我们实习生来说，Gemini CLI 不仅仅是一个工具，它更像一个不知疲倦的导师。它能帮我们快速融入项目，解决开发中遇到的实际问题，把更多的时间花在学习核心业务和技术上。

部署过程非常简单，几乎零成本。强烈建议你也动手试试，体验一下 AI 辅助编程的快乐！
```