# 第二届 AI 大赛参赛项目建议书

## 项目名称

AI 智能巡检与故障归因 Agent 平台

## 赛道建议

赛道 A：商业创新线

## 一、项目执行摘要

本项目面向政企网站、业务系统和运行环境保障场景，建设一套集智能巡检、服务监测、日志分析、告警归集与初步故障归因为一体的 Agent 平台。平台围绕“异常发现更早、问题定位更快、结果留痕更完整、后续扩展更容易”的目标，尝试将浏览器自动化巡检、宿主机 Agent 监测、日志摘录分析、告警事件管理与后续 AI 诊断能力整合到统一系统中。

项目当前已经形成可本地部署、可外网代理访问、可真实执行的 MVP。系统已完成登录、工作台、巡检任务、执行记录、巡检报告、环境监测、告警事件、Agent 节点等核心模块，能够真实执行浏览器巡检任务，完成多类服务目标监测，生成运行记录、日志分析结果与告警事件，并支持从告警跳转到对应的目标对象和监测记录。

本项目的核心特点，不是单纯“做一个脚本执行工具”，也不是单纯“做一个服务监控页面”，而是将前台可见现象与后台运行状态尽可能统一到一个平台之内。它既能从用户视角发现页面异常，也能从服务视角采集运行状态，并通过日志摘录、模板归类和问题建议，把原本割裂的巡检、监测、日志、告警和报告链路串联起来，形成可演示、可落地、可继续增强的智能运维雏形。

## 二、项目背景与现实痛点

在政企网站保障、重点专题值守、重保支撑和应用系统运维场景中，人工巡检仍承担大量重复性工作。日常值守往往需要定时访问页面、核查栏目、验证关键功能、截图留痕、登记结果并汇总日报。一旦发现异常，还要切换到服务监测、端口检查、进程确认、日志排查等后端工作，定位链路长，响应效率低。

当前常见模式主要存在以下问题：

1. 巡检流程重复度高，人工成本和注意力消耗长期居高不下。
2. 页面异常与后台服务状态割裂，前台能看到问题，但难以快速判断问题源头。
3. 巡检、监测、日志、告警、报告分散在不同工具和流程中，缺乏统一工作台。
4. 政企场景普遍存在本地部署、内外网隔离、代理访问和安全合规要求，通用 SaaS 工具难以直接落地。
5. 传统监控更偏“发现是否异常”，缺乏“辅助理解异常、给出处置方向”的能力。

因此，本项目聚焦一条务实主线：先把异常发现、证据留存、事件归集和初步归因跑通，再逐步增强智能分析能力，最终形成适合政企环境的智能巡检与故障归因平台。

## 三、建设目标

1. 建设统一的巡检与服务监测平台，减少多系统切换和重复操作。
2. 打通前台页面巡检与后台服务监测，形成“现象 + 状态 + 日志”的联合判断能力。
3. 建立告警事件中心，实现从运行结果到问题事件的自动归集与联动查看。
4. 以规则分析和日志模板归类为起点，逐步演进到真实大模型辅助归因和建议生成。
5. 兼顾本地部署、Nginx 代理访问、Agent 回连执行和后续安全增强等落地要求。

## 四、总体方案与架构设计

本项目总体采用“一个平台中枢、两条执行主链、两类沉淀能力”的架构。

### 4.1 平台中枢

平台后端作为统一中枢，负责：

- 巡检任务与监测目标配置
- 调度执行与运行记录管理
- Agent 节点注册、控制与任务分发
- 日志接入、分析编排和告警事件生成
- 报告、详情和联动视图输出

### 4.2 两条执行主链

#### 主链一：外网智能巡检链

通过 Playwright 执行真实浏览器巡检，完成页面访问、关键交互、断言验证、截图留痕、步骤日志记录和巡检报告生成。

#### 主链二：环境监测与 Agent 执行链

通过平台直接执行或宿主机 Agent 执行方式，对 HTTP、TCP、Redis、RabbitMQ、Elasticsearch、Java 应用等目标进行监测，采集运行结果、日志摘录和监测明细，并生成告警事件。

### 4.3 两类沉淀能力

#### 事件沉淀

将页面异常、监测失败、日志异常和状态变化统一沉淀为告警事件。

#### 知识沉淀

逐步沉淀日志模板、问题分类、建议动作和归因经验，为后续知识库和真实大模型接入奠定基础。

## 五、核心功能模块

### 5.1 智能巡检模块

- 巡检任务创建、编辑、启停
- 按周期执行和手动执行
- Playwright 真实浏览器巡检
- 页面截图、步骤日志、执行记录
- 巡检报告查看与结果留痕

### 5.2 服务监测模块

当前已支持以下目标类型：

- HTTP / HTTPS
- TCP
- Redis
- RabbitMQ
- Elasticsearch
- Java 应用

系统支持目标配置、执行、运行记录、日志摘录和监测详情查看。

### 5.3 告警事件模块

- 真实生成监测与日志分析告警事件
- 支持严重级别、状态流转和问题摘要
- 支持从告警跳转至目标对象和监测记录
- 支持原始结构化详情、可能原因和建议动作展示

### 5.4 Agent 节点模块

- Agent 节点注册与管理
- 节点在线状态与能力开关
- 宿主机 Agent 回连、领任务、执行反馈和日志摘录回传
- 为后续内网探针、边缘执行和端云协同扩展预留基础

### 5.5 日志分析与初步归因模块

当前已实现：

- 日志摘录和最近日志分析
- 异常模板归类
- 问题分类与严重级别判定
- 可能原因与建议动作生成

当前这一能力主要采用本地规则分析与模板归类实现，后续可逐步接入真实日志平台和外部大模型。

### 5.6 报告与留痕模块

- 巡检报告
- 执行记录详情
- 页面截图与异常证据
- 监测结果与告警联动回溯

## 六、当前 MVP 完成情况

截至目前，项目已经形成可运行、可演示、可验证的最小可行产品。

### 6.1 已跑通的真实能力

1. 登录与后台工作台。
2. 巡检任务管理、执行记录和巡检报告主链路。
3. Playwright 真实浏览器巡检。
4. 服务监测目标配置与执行。
5. 宿主机 Agent 回连、领任务、回传结果。
6. 日志摘录、异常分类和建议动作生成。
7. 真实告警事件生成与 `/alerts` 页面展示。
8. `/monitors` 与 `/alerts` 之间的对象级联动跳转。
9. 本地部署、Nginx 代理访问和自检脚本校验。

### 6.2 当前仍处于 MVP 阶段的部分

1. 外部通知通道尚未正式接入。
2. OpenObserve 与 Drain3 当前为适配边界，尚未接成真实外部服务。
3. AI 诊断目前以本地规则和模板归类为主，尚未接真实 LLM API。
4. 服务进程守护与稳定生产部署仍需增强。

## 七、项目 AI 属性与创新点

### 7.1 从单点自动化走向统一闭环

本项目并不把 AI 等同于“一个聊天框”或“单次模型调用”，而是尝试将巡检、监测、日志、告警和报告整合进一条可执行、可留痕、可回看、可增强的链路中，使系统具备从自动执行向辅助判断逐步升级的能力。

### 7.2 端云协同的执行模式

平台采用“平台中枢 + 宿主机 Agent”的执行模式。执行能力尽量靠近现场，分析能力集中沉淀到平台，更适合政企环境下的内外网隔离、分节点部署和后续边缘扩展。

### 7.3 页面现象与服务成因的联合分析

传统巡检只关注页面能否打开，传统监控又只关注服务是否在线。本项目尝试将页面异常、服务状态、日志模式和告警事件统一关联，推动问题发现与问题定位一体化。

### 7.4 渐进式 AI 路线

项目没有一开始就把全部能力建立在大模型之上，而是先以真实执行链路、规则分析和模板归类跑通 MVP，再逐步接入真实大模型能力。这种路径更稳健，也更适合真实落地和持续迭代。

### 7.5 面向政企环境的落地设计

项目从设计之初就考虑了本地部署、Nginx 代理访问、数据库切换、Agent 执行和后续安全扩展等要求，更贴近政企项目实际实施条件。

## 八、技术实现说明

### 8.1 前端

- Next.js 16
- React 19
- TypeScript

### 8.2 后端

- NestJS
- Node.js
- TypeORM

### 8.3 自动化与执行

- Playwright：执行外网真实浏览器巡检
- 宿主机 Agent：执行服务监测、日志摘录和结果回传

### 8.4 数据库与存储

- MariaDB / MySQL 已跑通
- Kingbase 已做兼容接入方案

### 8.5 部署方式

- 支持本地部署
- 支持 Nginx 代理访问
- 当前适合演示、试运行和小范围验证

## 九、应用价值与推广前景

### 9.1 直接应用价值

本项目可直接服务于以下场景：

- 政务门户与集团网站日常巡检
- 专题页面和重点栏目保障
- 运维值守和重保场景
- 服务运行状态检查与日志排查辅助
- 异常说明、汇报留痕和复盘分析

### 9.2 推广前景

项目具备向 2G / 2B 运维保障类场景扩展的潜力，可逐步形成：

- 网站与站群巡检产品
- 服务监测与告警平台
- Agent 节点执行平台
- 面向内外网协同的智能运维底座

随着日志平台、通知通道、知识库和真实大模型能力逐步接入，平台有机会从“可用 MVP”演进为“可落地产品化方案”。

## 十、后续演进路线

### 10.1 短期目标

- 巩固当前 MVP 的稳定性
- 完善服务进程守护和部署方式
- 优化巡检、告警、监测和联动体验

### 10.2 中期目标

- 接入真实通知通道
- 接入真实日志平台与模板引擎
- 完善规则中心、去重、静默和升级机制
- 增强内外网协同和 Agent 执行能力

### 10.3 长期目标

- 引入真实大模型 API
- 建立运维知识库与问题画像
- 实现更强的根因分析、报告生成和对话式诊断
- 支撑多项目、多租户和更多行业场景扩展

## 十一、与同类方案相比的项目特色

相较于单纯的网站巡检工具，本项目更强调“页面巡检 + 服务监测 + 日志分析 + 告警归因”的一体化。

相较于单纯的监控平台，本项目更强调“前台现象”和“后台成因”的联动，以及真实巡检证据和运行证据的统一留存。

相较于完全概念化的 AI 运维方案，本项目当前已经具备真实执行链路、真实 Agent 监测和真实告警事件能力，更适合参赛展示，也更适合后续继续落地。

## 十二、结语

AI 智能巡检与故障归因 Agent 平台不是停留在概念层面的题目，而是一项已经形成本地可运行示例、真实执行链路和明确演进路线的项目。项目立足政企网站与应用系统保障场景，围绕“巡检自动化、监测在线化、分析智能化、结果可追溯”构建核心能力，兼具现实应用价值、参赛展示价值和后续深化空间。

从当前阶段看，项目已经完成了简易 MVP 的关键闭环；从后续空间看，项目又具备沿着端云协同、日志智能分析和大模型归因方向继续增强的清晰路径。作为参赛项目，它既有真实落地基础，也有持续升级的技术空间，适合用于当前阶段的报名展示和后续深化推进。