推荐语

Agent + PAN-OS MCP 让防火墙巡检更智能，不懂开发也能轻松管理设备！

核心内容：
1. Agent 与 MCP 工具结合，简化防火墙巡检与管理流程
2. 自然语言交互实现设备查询、配置修改及报告生成
3. 项目适用场景与当前优化方向

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

写在前面：

起了个比较俗气的标题，还请大家见谅。

虽然上篇文章对 MCP 有不少批判，但忽略那些缺陷，单纯作为辅助工具用起来还是挺丝滑的。

本文算是对 MCP 工具设计及使用的总结，希望可以帮到大家。

TL;DR

• Agent 搭配 MCP 工具能让防火墙等设备管理和巡检变得“更简单”，对不懂开发的人员也很友好

• 但简单的同时，也带来了新的要求：

• MCP 工具开发者需要精心设计 Tools，让 Agent 能够正确理解并准确调用工具；

• MCP 工具使用者需要精心编写提示词，准确指导 Agent 来完成需要的任务，避免 Agent 执行走偏。

• 当前项目可用于简单的场景，复杂的场景仍需要优化，当前可能出现 Token 耗费过多，任务执行时上下文过长导致任务失败等问题。

pan-os-mcp 项目概要

最近随着 MCP 大火，不少客户开始问我们是否支持 MCP（关于 MCP 的背景知识，可以阅读上篇文章），以及是否能用它来做防火墙 AIOps、巡检报告等自动化任务。

网上虽然已经有一些 pan-os mcp server 项目，试了下要么功能不完善，要么 tools 定义不准确，于是花了点时间重新加工测试，做了个增强版的 mcp server 出来，项目地址见：🔗 https://github.com/zm1990s/pan-os-mcp

项目中也贴了一些使用示例，欢迎测试使用。

该项目可以干什么？

简单来说，可以让你用自然语言，通过 Agent 来管理防火墙。

比如：

• 通过自然语言，让 Agent 执行防火墙命令，进行信息查询或者配置修改；

• 写一套巡检提示词，让 Agent 输出巡检报告（替代写脚本）。

这对于日常巡检、临时信息查询、防火墙配置修改等场景都适用，尤其适合缺乏自动化脚本经验的网络运维人员。

下面贴两个使用示例（使用 VSCode + Cline）：

查询设备接口信息

提示词示例：

根据devices.conf中的设备列表和凭据，使用您拥有的适当MCP工具。向我显示PA-440上所有接口的流量统计信息。识别任何具有异常流量模式或错误的接口，并提供每个活动接口的吞吐量摘要。您可能需要使用此命令：<show><counter><interface>all</interface></counter></show>

编写巡检报告

提示词示例：

你是一个严谨的智能巡检助手，会定期执行 Palo Alto Networks 防火墙的深度健康与安全状态检查。自动收集运行状态、性能指标、授权信息、安全配置细节和潜在风险点，生成标准化的 Markdown 格式检查报告，并提供具体、可操作的告警与优化建议。请将结果输出到一个 Markdown 文件中，文件名使用 panw-firewall-report-[当前年月日].md
你需要严格遵照下列规范：* 所有巡检結果均使用 Markdown 表格格式輸出。* 关键告警和建议应该在表格下方以粗体或列表形式突出展示。- `get_system_info`：获取基本系统信息- `op_command`：使用XML执行操作命令  ---- 篇幅原因详细内容省略 ----
接下来，是你要检查以及整理的内容：目标设备为： devices.conf 中定义的 PA-440
### **1. 基本运行状态检查 (Runtime & System Health Check)*** **指令：** 收集防火墙的基本运行信息和系统健康概览。* **输出要求：** 以 Markdown 表格形式输出以下信息：
| 项目         | 值          | 状态/告警                                 || :----------- | :---------- | :---------------------------------------- || 主机名       | `[Hostname]` | OK                                        || 管理 IP      | `[Management IP]` | OK                                        || 序列号       | `[Serial Number]` | OK                                        || 型号         | `[Model]`     | OK                                        || PAN-OS 版本  | `[PAN-OS Version]` | OK                                        | ---- 篇幅原因详细内容省略 ----
* **相关 XML API 命令示例：*** 获取基本系统信息（主机名、IP、序列号、PAN-OS 版本、内容版本、运行时长、系统时间、最后配置提交时间）：<show><system><info></info></system></show>* 获取 HA 状态：<show><high-availability><state></state></high-availability></show>* 获取风扇、电源和温度状态<show><system><environmentals></environmentals></system></show>
#### **2. 设备许可与订阅服务检查 (License & Subscription Service Check)** ---- 篇幅原因详细内容省略 ---- 详细示例见：https://github.com/zm1990s/pan-os-mcp/blob/main/Agent-Prompt-Examples-CN/Routine%20Inspection-Example-CN.txt

背后的实现

该项目的工作原理很简单：

• 本地安装 Cline 等支持 MCP 工具调用的 Agent 

• 通过 Python 按照 MCP协议的规范编写脚本（MCP Server），将 NGFW 的 XML API 封装成一个个 tools

• Cline 中添加上述 MCP Server，通过提示词调用即可。

本质上，PAN-OS MCP Server 是一个 API 中转工具，方便 Agent 去发现并调用防火墙的 API。

但考虑到日常使用场景，做了一些微小的优化：

• 基于防火墙的 XML API 实现

PAN-OS 本身提供多种 API，但其中 XML API 的功能最全，灵活性最高，仅需要写少量的 Tools 即可支持大部分功能。

Tools 相当于一个个 API，PAN-OS 的功能非常多，按照传统做法如果每项功能都做成 Tools，那么代码量会很大，这间接会使得 Agent 上下文变长，Agent 调用工具的精度下降（假如多个 Tools 功能描述相似，可能导致 Agent 选择错误的工具）。

如下图是 PAN-OS REST API 的清单，单 Object 资源对象就有 30+，加上 Policy、Network、Device 等对象，数量会在 100+，对应可能需要 100+ 个 tools 实现。 XML API 命令拼接可以很好地解决此问题。

• 凭据解耦，支持多设备

凭据管理其实是 MCP 的一个老大难问题，在上篇文章的后面详细介绍过。

常见的 MCP 工具都在启动时通过环境变量等方式将认证信息带入工具中，然后通过工具去访问后端资源（比如 API），这种方式存在两个问题：

• 一个 MCP Server 仅能使用一组 key，间接导致只能工具只能访问一台设备，多设备下会抓瞎

• 密钥存储不安全

• 通过提示词来准确指导 Agent 执行任务

前面提到项目使用 XML API，而这种 API 类似于以前网络设备的命令一样（如 show ip int br），虽然基础命令没几个，但组合变化很多。

为了使得 Agent 调用准确，提示词中需要告诉 Agent 做什么事情应该执行什么命令，比如：

根据devices.conf中的设备列表和凭据，使用您拥有的适当MCP工具。请对PA-440-2进行全面的健康检查。检查系统资源，包括CPU、内存和会话使用情况。还要验证接口状态和状态。您需要以下XML命令：<show><session><info></info></session></show><show><system><resources></resources></system></show><show><interface>all</interface></show><show><system><state></state></system></show>

所以，虽然 MCP Tools 少了，但是 API 没少，只是将这部分功能放在提示词中，简单、灵活、适用性强。

距离生产化，依然有段路要走

使用上述工具进行简单任务应该 OK，但距离一个成熟的项目还有段路要走：

• 当前仅支持本地 Agent（即仅支持 stdio 模型），未来会增加 Streamable HTTP 接口支持，同时提供容器部署版本；

• 处理复杂任务上下文不足：处理日志等任务时，可能因日志量过大导致 Agent 上下文超限，如果要解决这个问题可以做任务拆解，一次只用一个会话做一件事，最后再汇总结果（有点类似多 Agent 架构）；或者用工作流等方式去获取和过滤数据，然后 Agent 做总结（类似于传统编程+Agent 结合）

• 对设备功能需要很熟：在 AI 时代大家都说提示词很重要，如果要借助工具准确输出自己想要的报告，就需要知道需要查看设备的哪些信息，以及判断哪些指标是异常的/值得关注的，然后再编写提示词。本文中的提示词示例基于一位同事 @shell 的巡检报告用 AI 编写的。

• Token 杀手：在使用 Cline 进行测试时，完整输出一份报告可能需要数百万 Token，原因依然在于获得的裸数据量较大，比如日志信息、设备状态信息等，因此在编写提示词时一定要写好过滤条件，减少不必要的检索。

• 凭据管理优化：目前使用本地配置文件存储密钥，虽支持多设备，但这样有一些安全风险，而且调用时 Key 也会发送给 LLM，有可能造成数据泄露。

  未来更好的实现方式是 Agent 具备凭据托管功能，在调用 Tools 时自动填充凭据，而不是让模型去填充（Agent 厂家请发力）。

  还有一种办法是动态口令，但这对设备认证体系、Agent 等也有一定要求。