AI运维网关

前言

最近工作中新增了一些运维相关的内容。为了提升效率，我尝试引入AI参与部分运维流程。

我使用的是OpenClaw：运维请求仍然由人工发起，但具体的执行、查询和结果整理可以交给OpenClaw以及其他组件完成。后面我也尝试过使用Hermes。但无论是OpenClaw还是Hermes，只要让AI进一步接近真实运维环境，就一定会遇到一个核心问题：

如何让AI在参与运维执行时，既能自动化完成任务，又能保证执行动作安全、可控、可审计？

一方面，我们希望AI能够处理一些重复性、标准化的运维动作，例如查询服务状态、查看磁盘占用、执行预定义排障命令等，减少人工反复操作。另一方面，我们又不能让AI直接连接目标主机并执行任意shell命令，否则很容易带来误操作、越权操作和高风险命令执行的问题。

如果每一步执行都依赖人工手动确认，那么安全性虽然提高了，但自动化效率会明显下降，AI也很难真正融入运维流程。因此，真正需要解决的不是“AI能不能执行命令”，而是：

如何在不完全放开权限的前提下，让AI自动化调用一组受控的运维能力？

基于这个问题，我搓了一个运维网关项目：AI OPS Gateway，它位于大模型和被运维主机之间，作为一层安全运维网关存在。AI不能直接访问目标主机，也不能执行任意命令，只能根据网关中预先配置好的runbook列表发起执行请求。每一次执行请求都会经过runbook白名单校验、目标主机校验、参数校验、权限校验和命令模板安全渲染，最终再由网关通过SSH在目标主机上执行。这样一来，AI可以负责理解需求、选择合适的运维动作并解释执行结果，而真实执行能力始终被限制在网关允许的范围内。

简而言之：

Agent负责理解需求和解释结果，Gateway负责约束能力和安全执行。

工作流程

通用执行模型

在通用执行模型中，用户、消息入口、Agent、AI OPS Gateway和目标主机构成了一条标准运维链路。AI OPS Gateway并不直接面向终端用户，而是作为后端安全执行层接入Agent系统；用户通过消息入口向Agent提交自然语言运维需求。

AI运维流程

一个典型的AI运维流程如下：

1. 用户使用自然语言向消息入口输入运维需求。
2. 消息入口将用户需求转发给后端Agent。
3. Agent识别用户意图，判断该请求是否属于允许的运维场景；必要时通过MCP工具调用AI OPS Gateway的查询接口，获取当前可用的runbook列表。
4. AI OPS Gateway返回当前可用的runbook摘要列表。
5. Agent根据用户需求和runbook列表，构造结构化执行请求，并通过MCP工具调用AI OPS Gateway的执行接口。
6. AI OPS Gateway对执行请求进行runbook白名单校验、目标主机校验、参数校验、权限校验和命令模板安全渲染，校验通过后再通过SSH在目标主机上执行。
7. 目标主机将命令输出、错误信息和执行状态返回给AI OPS Gateway。
8. AI OPS Gateway将底层执行结果封装为结构化结果，并返回给Agent。
9. Agent读取结构化结果，解释执行情况、失败原因和可能的风险，并根据结果判断是否需要建议下一步处理动作，随后将整理后的结果发送给消息入口。
10. 人类用户通过消息入口读取最终运维结果。

实际接入形态

在实际接入时，通用执行模型中的每个角色都可以展开成多个具体实现：多个用户可以同时发起请求，消息入口可以是飞书、QQ、Discord或Telegram，Agent可以是OpenClaw或Hermes，目标主机也可以是多台服务器或现场工控机。

AI运维实际接入形态

• 多个用户可以在不同会话中同时发起运维请求，例如有人通过飞书机器人提交需求，也有人通过QQ、Discord或Telegram等入口发起请求；上游消息入口和Agent可以为每个请求维护独立的用户身份、会话上下文和权限信息。
• 多个消息入口可以接入同一个Agent，也可以根据部署方式路由到不同Agent。
• OpenClaw和Hermes这类Agent位于同一抽象层，它们可以作为不同的Agent实现接入AI OPS Gateway。对于Gateway来说，它并不依赖请求来自哪个具体Agent，只要请求符合约定的结构化协议即可。
• AI OPS Gateway作为统一的安全执行网关，负责接收来自多个Agent的查询请求和执行请求，并在内部完成runbook白名单校验、目标主机校验、参数校验、权限校验和命令模板安全渲染。
• 当多个独立请求同时到来时，AI OPS Gateway可以分别对每个请求完成安全校验、命令渲染和受控SSH执行，并将对应目标主机返回的命令输出、错误信息和执行状态封装为结构化结果返回给对应Agent。
• Agent拿到结构化结果后，再结合原始用户上下文进行解释和整理，最终通过原消息入口把结果回传给对应用户。

案例分享

案例中的主体如下：

• 用户：我和我的同事们。
• 消息入口：飞书机器人
• Agent：Hermes
• 运维网关：AI OPS Gateway
• 目标主机：现场的若干工控机

一个真实案例是：有同事反馈某台工控机的某次采图任务出现丢图现象，并给出了任务号和丢图统计信息。这个问题需要同时查看任务日志、服务日志、系统状态和相机SDK相关日志，比较适合交给Agent通过受控runbook进行多轮查询。

这个问题进入AI运维链路后，大致会经历以下过程：

1. 运维人员接到反馈后，在飞书中向机器人输入自然语言运维需求（私聊的话直接交互即可，群聊需要手动@飞书机器人）
2. Hermes理解意图后先调用AI OPS Gateway查询当前可用的runbook，再根据用户需求构造结构化执行请求。
3. AI OPS Gateway收到请求后，内部会完成一系列安全检查，确认该请求是否被允许执行。只有通过校验的请求，才会被渲染成受控命令，并通过SSH发送到目标主机。
4. 目标主机返回命令输出、错误信息和执行状态，通过AI OPS Gateway返回给Hermes。
5. Hermes读取结果并判断是否需要继续排查。如果信息不足，会继续构造新的执行请求进行补充查询；如果证据足够，则停止执行。
6. Hermes分析多轮查询结果，并整理成面向运维人员的结论，通过飞书机器人返回给用户。
7. 运维人员通过与飞书机器人的对话读取最终运维结果。

架构设计

整体架构图

敬请期待…

核心设计

敬请期待…

总结