OpsPilot：面向企业业务系统的智能运维 Agent 平台（8）

Caiquanxxy

202人浏览 · 2026-06-22 13:48:40

Caiquanxxy · 2026-06-22 13:48:40 发布

1. 项目背景

传统告警系统虽然能够及时发现问题，但在真实运维场景中仍然存在几个典型痛点：

告警噪声多，重复告警和无效告警会大量占用值班人员时间
告警到处置之间缺少自动化分析环节，定位问题仍然依赖人工经验
高风险操作需要审批，但审批链路与实际执行往往是分离的
告警、分析、审批、执行和记录分布在多个系统中，缺少统一闭环
基于这些问题，本项目设计并实现了一个面向运维场景的 AI 驱动平台：OpsPilot。
它的核心目标不是单纯“接收告警”，而是将告警接入、分析、工具调用、审批、执行和存储整合成一个完整闭环。

项目整体可以概括为：

告警接入 -> 去重调度 -> LLM 分析 -> 工具调用/审批 -> 执行处置 -> 过程留痕

其中，后端负责运行时逻辑与智能体调度，前端负责提供可视化控制台，用于查看系统状态、跟踪会话过程、执行人工审批与联调测试。

2. 项目整体架构

2.1 后端架构

后端采用 Python 异步架构实现，整体由以下几个层次构成：

接入层 Ingestion 负责接收来自 Prometheus、Grafana 或通用 Webhook 的告警，并将不同格式的原始输入归一化为统一的 AlertEvent 结构。

调度层 Dispatcher 负责告警去重、队列调度和 Worker 消费。它决定哪些告警进入处理链路，哪些告警因重复或已恢复而被跳过。

会话层 Session 负责管理分析会话生命周期。每一条需要分析的告警都会进入一个 AgentSession，会话中维护当前状态、事件记录、等待审批信息等上下文。

智能体层 Agent 负责基于上下文组织消息、调用大语言模型、生成分析报告，并在需要时触发工具调用或审批中断。

动作层 Action 负责工具注册、工具执行、安全分级和审批策略。例如 Shell、K8s、数据库操作、通知等都在这个层面统一管理。

存储层 Storage 负责将告警、会话、分析、工具调用、审批记录等持久化到 SQLite 数据库中。

配置层 Config 负责统一加载 YAML 配置，并支持环境变量替换与配置热重载。

通知层 Notify 负责通过外部渠道发送结果或告警通知。

2.2 前端架构

前端采用独立工程实现，技术栈为：

Vue 3
Vite
Vue Router
Pinia
Element Plus
ECharts
Axios
前端围绕文档定义的运维控制台信息架构展开，页面覆盖：

登录页
Dashboard 总览
告警列表与详情
会话列表与详情
审批台
分析详情
项目列表与详情
工具注册表
通知渠道页
Webhook 测试页
配置中心
系统设置
错误页
前端的主要作用不是“展示静态数据”，而是为值班人员、SRE 和平台管理员提供统一的交互入口。

3. 后端核心设计

3.1 告警接入与统一模型

后端的接入层并不直接处理各类监控系统的原始字段，而是先通过 normalizer 转换为统一的 AlertEvent。
这样做有两个好处：

屏蔽 Prometheus、Grafana、通用 Webhook 之间的数据结构差异
为后续调度层和智能体层提供一致的数据契约
统一模型的核心价值在于：一旦 AlertEvent 被构造完成，后续流程就不再关心原始告警来自哪里，而只关心标准化后的字段。

3.2 去重与调度机制

在真实运维环境中，重复告警很多，因此后端设计了 Dispatcher 层来完成：

去重
优先级队列管理
Worker 消费
调度器会维护队列大小、活跃 Worker 数量、累计接受数量、累计去重数量等统计信息，这些统计也被前端 Dashboard 直接消费。

这种设计体现了一个关键思想：
告警系统不应该一收到输入就立即进入分析，而应该先经过调度层控制吞吐和噪声。

3.3 会话管理与状态机

每个进入处理链路的告警都会被包装到一个分析会话中。
会话层负责管理：

当前状态
当前节点
迭代次数
事件时间线
等待中的工具或审批项
结果摘要
一个典型会话可能经历以下状态：

queued
llm_running
waiting_tool
pending_approval
completed
failed
escalated
cancelled
前端的会话详情页和 Dashboard 都直接围绕这一状态机展开展示。

3.4 LLM 分析与工具调用

后端的 Agent 层负责整合上下文并驱动 LLM 完成问题分析。
其核心任务包括：

组织系统提示词与上下文消息
基于告警信息生成分析报告
在需要时调用工具
在危险操作前触发审批中断
在审批通过后恢复执行
工具体系支持：

Shell
Kubernetes
数据库
通知
升级人工处理
MCP 扩展工具
这意味着平台不只是“能看懂告警”，而是具备把分析结果进一步转化为动作的能力。

3.5 审批机制

高风险动作不能直接执行，因此系统设计了审批中断机制。
当智能体识别到危险工具调用时，会暂停会话并生成待审批项，等待人工做出决策。

审批结果包括：

批准
拒绝
审批信息被单独记录，并和分析、工具调用建立关联关系。
这使得系统既能支持自动化，又能满足运维场景对可控性的要求。

3.6 存储设计

后端目前采用 SQLite 作为默认存储，核心表包括：

alerts
sessions
analyses
tool_calls
approvals
这种结构对应了完整的业务链路：

一个告警可能触发一次或多次分析
一个分析中可能包含多次工具调用
一次工具调用可能关联一个审批过程
存储层的价值不只是“保存数据”，更重要的是支持后续的：

页面查询
过程追溯
问题复盘
指标统计

4. 前端实现思路

4.1 页面信息架构

前端不是简单的管理后台，而是严格围绕业务闭环设计。
页面组织逻辑如下：

Dashboard：看总体运行态势
Alerts：看输入侧的告警记录
Sessions：看分析与执行过程
Approvals：看人工审批工作台
Analyses：看单次分析详情
Projects / Tools / Config：看平台配置和能力边界
Webhook Tester：做接口联调和模拟输入
这种页面组织方式的意义是：
前端界面本身就映射了后端运行过程。

4.2 工程结构设计

前端目录结构按业务域拆分：

src/api/
src/pages/
src/layouts/
src/router/
src/stores/
src/utils/
其中 API 层进一步拆分为：

alerts.js
sessions.js
approvals.js
analyses.js
stats.js
projects.js
tools.js
config.js
webhook.js
这使页面与接口天然对应，降低了维护复杂度。

4.3 请求层与运行时配置

前端通过 src/api/client.js 统一封装 Axios，请求层主要负责：

解析 API Base URL
自动带上 X-Operator
统一错误提示
兼容环境变量与本地设置
当前 API 地址支持两种来源：

.env 中的 VITE_API_BASE_URL
/settings 页面修改后写入的 localStorage
这让前端可以灵活切换不同后端地址，方便本地联调和部署测试。

4.4 登录与路由守卫

由于后端暂时没有完整用户系统，前端实现了轻量的本地操作员标识方案：

登录页只输入操作员名称
操作员名称保存在本地
请求头中统一附带 X-Operator
未登录时禁止访问受保护页面
这种实现非常适合当前阶段，因为它既满足了页面流程需求，也不和未来正式认证体系冲突。

4.5 Dashboard 与可视化

Dashboard 页面聚合多个后端统计接口，包括：

调度器统计
会话统计
告警总数
待审批列表
同时使用 ECharts 展示会话状态分布图。
图表类型主要使用饼图和柱状/折线图注册机制，以支持后续指标扩展。

这个页面的设计思路不是“图表越多越好”，而是要让运维人员一进系统就能判断：

队列有没有积压
会话是否卡住
当前是否存在待审批风险项
系统是否在线

4.6 会话详情与闭环交互

会话详情页是整个前端最关键的页面之一。
它负责承接从自动分析到人工介入的全过程，主要包含：

会话基础信息
运行状态
结果摘要
事件时间线
关联分析
合并相关告警
操作按钮
支持的人工动作包括：

批准
拒绝
取消会话
注入消息
这意味着前端不只是查询界面，而是真正具备处置入口。

4.7 Webhook 测试页

当前后端已经真实提供 POST /api/webhook/{project} 接口，因此前端实现了独立的 Webhook 测试页。
该页面支持：

选择项目
选择告警来源
输入 Webhook Secret
编辑 Payload JSON
查看响应结果
并提供了三类模板：

Prometheus
Grafana
Generic
这在联调阶段非常重要，因为它允许开发人员不依赖外部监控系统，也能主动构造测试数据。

5. 前后端接口契约关系

从整体上看，本项目采用的是“后端运行时 + 前端控制台”的解耦模式。
接口契约主要分为两类：

5.1 已有真实接口

当前后端代码中，最明确落地的是：

POST /api/webhook/{project}
这一接口由 FastAPI Webhook Router 实现，是告警进入系统的入口。

5.2 规划与封装完成的接口

前端已经按文档封装了如下接口域：

/api/stats/*
/api/alerts/*
/api/sessions/*
/api/approvals/*
/api/analyses/*
/api/projects/*
/api/tools
/api/sources
/api/notify/channels
/api/config/*
这些接口中有一部分在后端已经具备底层 Python 方法，但尚未全部以 HTTP 路由形式暴露出来。
因此，前端与后端之间当前处于一种“契约先行、实现逐步补齐”的联调关系。