说起 PAN-OS 防火墙的自动化管理，大多数运维同行最初的反应可能是编写脚本、调用 API——门槛较高，有时还需要请开发同事协助。但如果你稍微关注过 AI Agent 与 MCP 工具的组合，就会发现这件事已经换了一种玩法。与其说这是 AI 替代了运维工程师，不如说它真正把“对话式管理”这个概念，落地到了一个可实际使用的状态。
先简单总结一下：这篇文章想要分享的，是一套基于 MCP 协议实现的 pan-os 管理工具。它让不具备编程背景的运维人员，也能通过日常对话的方式完成防火墙巡检、信息查询和配置修改。但从落地实践来看，距离一个真正能在生产环境放心使用的工具，还有不少细节需要打磨。
快速了解核心要点
Agent 搭配精心设计的 MCP 工具，确实显著简化了防火墙的巡检与管理流程。对于不擅长写代码的运维人员来说，这可能是最友好的切入方式。
但“简单”二字背后其实对两边都提出了新要求：工具的开发者需要把 MCP 的接口定义得足够清晰，让 AI 能正确理解并调用；而使用者也需要花心思打磨提示词，把任务目标一步步交代清楚，才能避免 Agent 偏离预期执行。
就当前阶段而言，这套做法更适合一些边界明确的场景，处理复杂任务时可能遇到 Token 消耗过多、上下文过长导致中途失败的情况。
pan-os-mcp 项目想解决的问题
近期 MCP 在圈内热度很高，不少人跑来问我们是否支持，能不能用它来跑防火墙的 AIOps 或自动生成巡检报告。
网上其实已有一些开源的 pan-os mcp server 项目，但测试下来发现，要么功能不够全面，要么 tools 定义不够精准，Agent 调用起来很不顺手。所以我们干脆自己动手，重新设计并测试了一套增强版 mcp server。核心思路很简单：把防火墙的 XML API 封装成一个个标准的 MCP 工具，Agent 通过自然语言就能调用它们。
它能帮你做什么？
本质上就是让你用自然语言指挥 Agent 去管理防火墙，举个例子：
- 直接说“帮我查一下 PA-440 上所有接口的流量统计”，Agent 就会自动调用对应工具去执行命令并返回结果。
- 写一套完整的巡检提示词，告诉 Agent 需要检查哪些项目、输出什么格式的报告，它就能像执行脚本一样完成一次周期性巡检。
这种方案对日常巡检、临时查询、甚至简单的配置修改都非常适用，尤其适合那些缺乏脚本经验但需要管理设备的运维人员。
查询设备接口信息
提示词示例：
根据devices.conf中的设备列表和凭据，使用您拥有的适当MCP工具。向我显示PA-440上所有接口的流量统计信息。识别任何具有异常流量模式或错误的接口，并提供每个活动接口的吞吐量摘要。您可能需要使用此命令：all
编写巡检报告
提示词示例（经过精简）：
你是一个严谨的智能巡检助手，会定期执行 Palo Alto Networks 防火墙的深度健康与安全状态检查。自动收集运行状态、性能指标、授权信息、安全配置细节和潜在风险点，生成标准化的 Markdown 格式检查报告，并提供具体、可操作的告警与优化建议。
背后的原理与设计考量
整个方案的技术链路并不复杂：本地安装支持 MCP 的 Agent（例如 Cline），再编写一个 Python 脚本作为 MCP Server，将 PAN-OS 的 XML API 封装成一个个 tools，最后通过提示词让 Agent 去调用。
在具体实现时，我们做了几项针对性优化：
基于 XML API，而非 RESTful API。 PAN-OS 的 REST API 资源对象多达上百个，逐一封装成 tools 会导致代码膨胀，而且 tools 之间功能相似，Agent 选错工具的概率也会升高。XML API 则灵活得多，几个基础命令就能通过拼接覆盖大部分场景，tools 的数量被控制在很低的范围内。
凭据解耦，支持多设备管理。 多数 MCP 工具在启动时通过环境变量绑定一组密钥，这种方法虽然简单，但只能管理一台设备。这个项目将设备凭据和工具调用分离开，Agent 在调用时动态传入设备标识和密钥，配合一个 devices.conf 配置文件，多设备管理变得顺畅许多。当然，密钥存储安全一直是个老大难问题，目前也只能建议用户妥善保存配置文件、定期更新密钥。
依靠提示词来引导 Agent 工作。 既然 tools 较少，那么具体的命令执行细节就必须交由提示词去补全。比如你要让 Agent 检查系统资源，就得在提示词里明确告诉它应该使用哪个 XML 命令。这反而是这套方案最灵活的地方——无需改动代码，只需调整提示词，就能让 Agent 执行完全不同的任务。
距离正式投产，还有哪些坎要过？
用这套工具处理简单任务基本没什么问题，但想要在生产环境稳定运行，目前还有几个硬伤：
协议支持还比较单一。 目前只兼容 stdio 模式（本地 Agent），后续计划增加 Streamable HTTP 接口，并给出容器化部署方案。
复杂任务容易把上下文撑爆。 例如处理大量日志时，裸数据量过大可能导致 Agent 上下文超限。一个可行的方向是进行任务拆解，一次只处理一件事，最后再汇总；或者用传统编程逻辑做数据过滤，Agent 只负责总结。
对使用者的设备熟悉度有一定要求。 提示词写得好不好，直接决定输出报告的质量。你必须清楚哪些信息是巡检需要关注的，哪些指标属于异常信号，才能写出有效的提示词。
Token 消耗相当惊人。 测试时发现，完整生成一份巡检报告可能消耗数百万 Token。根本原因还是裸数据量太大，一个接口的状态、一张日志表都可能导致上下文急剧膨胀。因此提示词里一定要写明过滤条件，避免 Agent 扫描全量数据。
凭据管理仍需完善。 当前使用本地配置文件存储密钥，调用时 Key 也会被发送给 LLM，存在一定安全风险。最理想的方案是 Agent 本身具备凭据托管能力，调用 tools 时自动填充，而不是让模型去处理密钥。另一种思路是采用动态口令，但这又对认证体系和 Agent 的配合提出了更高要求。