wenlanai/docs/contest-proposal-agent-platform.md

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

项目名称

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

赛道建议

赛道 A：商业创新线

一、项目执行摘要

本项目面向政企网站、业务系统和运行环境保障场景，建设一套集“页面巡检、服务监测、日志分析、告警归集、初步故障归因”于一体的 Agent 平台。项目的出发点并不是简单把巡检、监控、日志和报表功能堆在一个后台里，而是尝试用 Agent 协同执行、事件化归集和 AI 增强分析，重构从“发现异常”到“理解异常”的处理逻辑。

在传统保障模式下，值守人员通常需要自己串联多个动作：先访问页面确认现象，再切到服务监控界面看存活状态，再登录机器查端口、进程和日志，最后把判断结果写进值班记录或日报中。整个过程高度依赖个人经验，信息分散且不可沉淀，一旦换人接班，知识链就容易断裂。本项目希望把这条链路尽可能转化为平台内的一条机器可执行、可回放、可增强的事件链：前台巡检负责发现现象，Agent 监测负责补齐状态，日志分析负责归并问题，告警事件负责收敛结果，后续 AI 能力再继续增强解释和建议。

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

因此，本项目的价值不在于“又做了一个自动化工具”，而在于围绕真实保障场景，提供了一套已经跑通主链路、并且具备继续向智能化演进空间的 Agent 平台原型。它既可以作为当前阶段的实用型保障工具，也适合作为后续智能运维产品化能力的基础底座。

二、项目背景与业务痛点

政企网站和业务系统运维场景有一个非常典型的问题：问题从来不是“看不见”，而是“看见了以后要花很长时间才能定位明白”。很多单位已经有页面巡检、接口检测、日志平台、监控告警、值班台账，但这些系统之间通常彼此割裂，真正故障发生时，仍然依赖人员自己在多个系统之间切换与拼接信息。

2.1 当前常见工作方式

以一个典型网站保障场景为例，值守人员在早班巡检时，往往要完成以下动作：

1. 打开门户首页、栏目页、专题页，检查页面是否可访问、是否白屏、关键内容是否缺失。
2. 对重点功能做简单交互验证，例如搜索、跳转、登录入口、详情页打开等。
3. 出现异常后，先截图留证，再到监控平台查看服务是否在线。
4. 如果页面正常但业务异常，还要继续到服务器或日志系统里排查。
5. 最终将异常现象、初步判断和处理意见再手工记录到日报或值班台账中。

这类工作模式存在三个核心问题：

2.2 现象和原因分离

页面巡检看到的是“现象”，服务监测拿到的是“状态”，日志系统记录的是“过程”，但三者往往并不在同一个工作面里。结果就是：

• 页面异常发现得快，但定位慢。
• 服务告警很多，但不容易判断是否已经影响业务页面。
• 日志很多，但缺乏和具体问题对象的关联关系。

2.3 工具很多，但闭环很弱

很多单位并不缺功能工具，而是缺少一条完整闭环。传统工具更多解决的是单点问题：

• 巡检工具负责定时访问。
• 监控工具负责采集指标。
• 日志工具负责存储检索。
• 告警工具负责发送通知。

但真正故障处置需要的，是把这些片段串成一条连续的认知链。也就是说，系统不仅要告诉人“哪里坏了”，还要尽可能回答：

• 这个问题影响了哪个页面或哪个目标？
• 它属于临时波动还是稳定复现？
• 日志里是否已经出现明确模式？
• 该优先查哪一层？

2.4 经验依赖强，知识沉淀弱

很多判断并没有沉淀在系统中，而是沉淀在值守人员的经验中。例如：

• 看到“连接重置”大概率先查数据库或网络。
• 某个专题页打不开往往是上游发布失败。
• 某类 Java 异常其实是配置或连接问题，而不是页面本身故障。

这些经验在传统模式下很难结构化复用。人员一换班、问题一换场景，之前积累的判断路径就很难被系统接住。

2.5 政企环境对落地方式有实际约束

与互联网公有云产品不同，政企环境通常还有以下落地约束：

• 本地部署需求较强。
• 存在内外网隔离或多级网络结构。
• 需要通过反向代理统一访问。
• 不能完全依赖外部 SaaS 服务。
• 对数据库、部署方式和安全边界有更高要求。

这决定了项目不能只停留在“在线 AI 助手”层面，而必须以可本地运行、可逐步增强为原则，走一条更贴近实际的建设路径。

三、项目目标与设计原则

本项目不追求一步做到“全自动智能运维平台”，而是以真实可交付的 MVP 为起点，逐步增强智能能力。整体目标如下：

3.1 建设目标

1. 建设统一的巡检与服务监测平台，减少多系统切换和重复劳动。
2. 打通前台页面现象与后台运行状态，形成联合分析基础。
3. 建立告警事件中心，把离散结果升级为可跟踪的问题对象。
4. 让规则分析、日志模板归类和后续大模型能力成为同一演进链上的不同阶段，而不是割裂能力。
5. 满足本地部署、代理访问、Agent 回连执行和后续安全扩展要求。

3.2 设计原则

为避免项目走向“功能堆叠”或“概念包装”，本项目坚持以下原则：

1. 先跑通主链路，再逐步增强智能能力。
2. 先保证真实执行、真实留痕，再谈智能解释。
3. 先把问题对象化、事件化，再引入更强归因能力。
4. AI 能力优先重构流程和交互逻辑，而不是仅增加一个摘要输出。
5. 所有智能能力都必须能落回具体执行记录、监测目标和日志证据。

四、总体方案与全局架构

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

4.1 平台中枢

平台后端承担统一中枢职责，负责：

• 巡检任务与监测目标管理
• 调度执行与运行记录管理
• Agent 节点注册、控制和任务分发
• 日志接入、分析编排和告警生成
• 页面展示、详情联动和报告留痕

平台的作用不是单纯承载页面，而是把原本人工拼接的信息链变成一条可编排的处理链。

4.2 两条执行主链

主链一：外网智能巡检链

通过 Playwright 从真实用户视角执行页面访问与交互。平台不仅检查页面是否返回，还可以记录执行步骤、截图证据、异常位置和运行详情。对业务方来说，它看到的不再只是“站点可用/不可用”，而是一条可回看的巡检过程。

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

通过平台直接执行或宿主机 Agent 执行方式，对目标服务进行监测，采集结果、日志和细节信息。对于 Java、Redis、TCP 等组件，平台可以通过不同的执行方式形成更加贴近现场的监测记录。

4.3 两类沉淀层

事件沉淀层

把执行结果、监测异常和日志命中统一收敛成告警事件。这样问题不再只是散落在不同列表中的一条记录，而会成为一个有状态、有严重级别、有上下文的对象。

知识沉淀层

逐步沉淀日志模板、异常模式、建议动作和后续诊断经验，为未来引入知识库和真实大模型做铺垫。

五、核心模块与当前实现路径

5.1 智能巡检模块

系统已实现巡检任务创建、编辑、启停和手动执行，能够通过 Playwright 对真实站点进行浏览器巡检，产出执行步骤、截图留痕和结果记录。与简单接口探活不同，这条链路更接近真实用户视角，更适合政企网站保障和重点页面验证。

5.2 服务监测模块

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

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

对于这些目标，平台可以完成目标配置、执行、结果记录、日志摘录和详情展示，并逐步形成统一的运行画像。

5.3 Agent 节点模块

平台已支持宿主机 Agent 回连、领任务、回传执行结果和日志摘录。这个设计非常重要，因为它决定了平台未来不只是一个“集中页面”，而是具备继续向内网探针、分布式采集和端云协同扩展的能力基础。

5.4 告警事件模块

系统已经完成真实的 monitor_alert 事件生成，不再只是页面提示。平台支持严重级别、状态流转、详情查看、问题摘要和对象联动，能够从 /alerts 直接跳转到 /monitors 的目标和运行记录，实现从“问题发现”到“问题回溯”的闭环。

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

系统当前已经具备基于日志摘录和运行上下文的初步分析能力，支持：

• 最近日志归并
• 模板提取
• 问题分类
• 严重级别判定
• 可能原因与建议动作输出

目前这一能力主要基于本地规则和模板归类实现，但它已经在逻辑上重构了值守流程：原本需要人自己去判断“这些日志是不是一类问题、该先查哪里”，现在平台已经可以先完成第一轮收敛与解释。

5.6 报告与留痕模块

系统支持执行记录、截图证据、巡检报告、监测详情和告警联动回溯。它的价值不仅在于“生成文档”，更在于把一次次执行、一次次异常和一次次处置过程沉淀为可回看的过程资产。

六、当前 MVP 已完成成果

项目当前已经完成一个可运行、可演示、可验证的 MVP，而不是纯概念方案。

6.1 已经真实跑通的能力

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

6.2 当前仍属于 MVP 阶段的部分

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

6.3 典型闭环示例

以当前已经跑通的 Java 服务监测场景为例，系统可以完成以下闭环：

1. Agent 在目标机侧完成 Java 进程识别和日志摘录。
2. 平台将运行结果与日志片段关联到具体监测记录。
3. 分析层从日志中识别数据库通信异常等问题模式。
4. 系统将结果升级为告警事件，而不是停留在一条普通运行记录。
5. 运维人员可以从告警事件直接回到对应目标、监测记录和证据详情。

这说明平台当前已经具备一个简易但真实的“监测 -> 分析 -> 告警 -> 回溯”闭环。

七、项目 AI 属性与创新点

7.1 AI 不只是输出摘要，而是重构处理逻辑

参赛要求强调“作品应基于 AI 重构交互或逻辑，而非简单功能叠加或套壳”。本项目对此的回应是：AI 的角色不是给传统后台加一段文字解释，而是参与重构异常处理逻辑本身。

传统模式下，工作逻辑是：

1. 人去访问页面。
2. 人看到异常。
3. 人去查服务状态。
4. 人去看日志。
5. 人自己判断是否同类问题。
6. 人再写出结论和建议。

本项目希望将这条逻辑重构为：

1. 系统自动执行页面巡检或服务监测。
2. 系统自动沉淀运行记录与证据。
3. 系统自动归并日志模式与问题类型。
4. 系统自动升级为告警事件对象。
5. 系统给出第一轮问题摘要、可能原因和建议动作。

因此，AI 在本项目中的价值体现为“改变问题被组织和被处理的方式”，而不仅仅是输出一段自然语言。

7.2 Agent 协同执行让智能能力真正落地

如果没有 Agent，这个平台只能停留在中心侧页面和少量远程调用能力上；而引入 Agent 之后，平台具备了把执行能力放到现场节点、把分析能力收拢到中枢平台的条件。这样一来，AI 能力就不是悬浮在页面上的“解释器”，而是建立在真实执行链和现场数据采集基础上的增强层。

7.3 事件化设计是逻辑重构的关键

本项目当前一个重要创新点，是把运行结果、异常日志和监测问题从“记录”升级为“事件”。这个变化看似简单，实际上重构了运维交互方式：

• 记录只适合被查看。
• 事件适合被跟踪、被联动、被沉淀、被再次分析。

这意味着平台正在从“结果展示系统”向“问题处理系统”过渡。

7.4 渐进式 AI 路线而非概念先行

项目没有把全部能力建立在大模型之上，而是先以规则分析、模板归类和真实执行链路把 MVP 跑通，再逐步接入更强的 AI 能力。这种路线更加务实，也更符合真实业务系统从可用到智能的演进规律。

7.5 面向政企场景的可落地设计

项目从一开始就考虑本地部署、Nginx 代理访问、数据库切换、Agent 回连执行和后续安全扩展等实际要求，这使得它与很多停留在云端体验层的 AI 项目不同，更有可能落入真实场景并继续打磨。

八、技术实现说明

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 对现有保障工作的直接价值

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

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

它的直接价值主要体现在三点：

1. 减少高频重复劳动。
2. 缩短异常从发现到初步定位的时间。
3. 提升异常证据和处理过程的可追溯性。

9.2 产品化扩展前景

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

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

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

十、后续演进路线

10.1 短期目标

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

10.2 中期目标

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

10.3 长期目标

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

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

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

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

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

相较于“功能拼盘式”的系统建设方式，本项目更强调逻辑重构：不是把巡检、监测、日志、告警摆在同一个后台里，而是让这些信息在系统内部自动形成问题对象、事件链路和分析上下文。

十二、结语

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

从当前阶段看，项目已经完成了简易 MVP 的关键闭环；从后续空间看，项目又具备沿着端云协同、日志智能分析和大模型归因方向继续增强的清晰路径。更重要的是，它不是对传统运维工具的简单叠加，而是在尝试用 Agent 协同执行、事件化归集和 AI 分析增强，重构从异常发现到初步定位的工作逻辑。作为参赛项目，它既有真实落地基础，也符合“基于 AI 重构交互或逻辑”的方向要求，适合用于当前阶段的报名展示和后续深化推进。