准备了差不多两个月参加 GSOC 2025，项目是为 HertzBeat 引入 AI Agent 实现 MCP Server，虽然准备了那么久但最终还是落选了，直呼太卷了！卷归卷还是祝贺中选的那位小伙伴。听导师说，中选的是为外国朋友，在最后的提案评分上比我高一些，Google 也不公布中选选手的提案，还想学习一下别人的方案呢。
反正都写了方案，我也将我的方案发布出来记录一下。也许对想要为自己的项目接入 AI 功能的朋友有启发。
1. 个人介绍
我的名字是 bigcyy，目前研一。
当我发现 HertzBeat GSOC-293 这一项目时，我感到无比兴奋，因为它完美契合了我的研究兴趣！我擅长 Java 开发，同时在 Python 和 TypeScript 方面也积累了丰富的经验。自 ChatGPT 发布以来，我一直密切关注 LLM 领域的发展及其实际应用，并积极投身相关的开发与研究。
我对开源充满热情，并渴望深入参与其中。此前，我曾向 SpringAI 提交过一个 PR（等待合并），并成功向 Langchain4j 贡献了一个已合并的 PR。这些开源经历不仅让我收获了宝贵的实践经验，也进一步激发了我对开源社区的热爱和投入。
为了更好地参与 HertzBeat GSoC 相关内容，我已经开始深入阅读 HertzBeat 源码，并积极参与社区。令人激动的是，我最近向 HertzBeat 社区提交了自己的 第一个 PR。尽管这只是一个相对简单的贡献，但对我而言，它意义非凡——标志着我正式迈入 HertzBeat 这个充满活力的开源社区，也坚定了我持续贡献的信心。
2.功能需求分析
在深入分析功能需求后，我总结出 LLM 需要操作的核心对象包括：
- 监控项
- 监控项的各项指标
- 报警数据
因此可围绕这三个操作对象创建 MCP 服务提供给 LLM 使用，下面是一些核心功能的分析：
监控查询：用户可以在聊天界面查询目前已经有的监控项。我们在给出监控项信息的同时需要尽量提供给用户相关联的完整信息。
指标数据查询: 用户可以在聊天界面查询某个监控项的指标情况。同时需要支持指标的图表展示。
报警数据查询: AI代理需要为用户提供报警数据查询功能，用户可以在聊天界面查询报警内容。
监控任务添加: AI代理需要为用户提供新增监控任务的功能，用户可以在聊天界面提供监控任务的信息实现监控任务的添加。
阈值配置: AI代理需要为用户提供报警阈值配置的功能，用户可以在聊天界面提供监控项以及监控指标的阈值信息实现对阈值的配置。
3. 设计方案
3.1. 整体架构设计
3.2. 各组件介绍
3.2.1. 核心 Agent
功能职责：
- 意图识别，解析用户的需求
- 监控系统辅助：通过分析用户的需求，并结合当前支持的 MCP 服务辅助用户。
- 简单聊天
当用户的请求是要查询监控项时（如”现在哪些监控项存在异常？”）：
- 解析查询意图，确定查询对象是监控项，确定查询的条件
- 调用 MCP 服务获取监控项数据
- 分析数据并给用户友好的响应结果
当用户的请求是查询监控项的指标数据时（如“服务器 192.168.1.1 最近一天 CPU 使用情况？”）：
- 由于监控项有哪些指标数据是通过监控项的 YML 决定的，Agent 查询指标数据首先需要获取监控项以及监控项的指标，因此首先需要调用 MCP 服务获取具体的数据然后分析。
- 分析并构建查询条件（指标类型、目标对象、阈值条件、时间范围等参数）
- 指标类型：CPU 使用率
- 阈值条件：>80%
- 时间范围：当前
- 目标对象：所有服务器
- 调用 MCP 服务获取具体指标数据
- 根据需要生成数据可视化（如”服务器192.168.1.1 最近一天 CPU 使用情况用图表展示”）
当用户的请求是查询报警数据时：
- 解析关于报警数据的自然语言查询
- 构建查询条件并调用 MCP 服务获取报警数据
- 分析报警信息
- 向用户展示报警信息与分析结果
当用户的请求是需要配置监控项时（如”我要监控 Web 服务的响应时间”）：
- 目前 HertzBeat 是通过监控模版 YML 确定要监控一个监控项需要提供哪些数据，以及可以监控的指标，因此需要调用 MCP 服务读取 YML 信息
- 分析 YML 并要求用户提供信息。
- 识别用户提供的监控类型、监控目标、监控参数等信息
- 调用 MCP 服务创建新的监控任务
- 返回创建结果
当用户的请求需要配置警报的阈值时（如”当 Web 服务响应时间超过 5 秒时触发警报”）：
- Agent 需要收集警报配置的相关信息
- 阈值名称：由用户指定
- 指标类型：指标类型由监控项的 YML 所定义，Agent 需要让用户进行选择
- 阈值规则：后端采用 JexlEngine 进行解析，Agent 需要解析用户的意图生成表达式
- 关联监控：由用户指定，Agent 解析并关联到现有的监控项
- 告警级别
- 触发次数
- 告警内容等
- 调用 MCP 服务添加警报阈值配置
- 返回配置结果和确认信息
3.2.2. 辅助 LLM 与记忆模块
辅助 LLM 包括对用户的请求进行重写、数据的可视化、SQL 编写等等。这些 LLM 可以是便宜的模型，也可以是专业的模型，以更好的辅助核心 Agent 完成工作。辅助 LLM 的调用我们也封装成 MCP 服务。
记忆模块主要负责 Agent 的记忆管理，主要包括所有的聊天记录以及记忆的持久化。
3.2.3. MCP 服务
MCP 服务是整个 Agent 系统的核心组件，它在任务执行过程中发挥关键作用。核心 Agent 会根据具体任务的需求，动态选择合适的 MCP 服务，以协助自身高效完成任务。MCP 服务的实现主要依托于 HertzBeat 现有的后端接口，以提供稳定且强大的支持。
下面是一些可能需要的 MCP 服务：
| 名称 | 描述 | 输入 | 输出 |
|---|---|---|---|
| 列出所有支持的操作 | 列出所有支持的操作 | 无 | 所有支持的操作列表 |
| 根据过滤条件获取监控项 | 根据查询过滤条件获取监控信息列表，支持多种过滤方式 | • 监控ID列表：可选，按指定监控项ID筛选 • 监控类型：可选，按监控应用类型筛选（如”linux”） • 监控状态：可选，按状态筛选（0=未监控，1=可用，2=已禁用，9=所有） • 主机搜索：可选，支持主机名模糊查询 |
返回监控信息列表，每条记录包含： • 监控项ID • 采集任务ID • 任务名称 • 监控类型 • 目标主机 • 采集间隔 • 任务状态 • 任务标签 • 任务注解 • 描述信息 • 创建/修改信息 • 时间戳 |
| 获取监控项指标信息 | 查询指定监控项的指标 | • 监控项ID：必填，指定查询的监控对象 • 指标名称：必填，指定查询的具体监控指标（如：cpu） |
• 监控项的基本信息 • 监控指标名称 • 最新采集时间戳 • 指标字段列表 • 数据行列表 |
| 获取告警信息 | 查询当前的报警数据 | • 告警状态：可选，筛选特定状态的告警（如”已解决”或”触发中”） • 搜索关键词：可选，用于告警内容的模糊查询 |
告警列表，每条记录包括： • 告警ID • 标签集合 • 注解集合 • 告警内容 • 告警状态 • 触发次数 • 时间信息（开始/激活/结束） • 创建/修改信息 |
| 获取可监控指标 | 查询监控项下可配置的报警指标 | • 监控类型：必填，指定要查询的监控类型名称（如”api”） • 语言类型：可选，指定返回结果的语言（如”zh-CN”） |
层次化的监控指标结构列表，每个节点包含： • 类别 • 属性值 • 显示标签 • 叶子节点标识 • 菜单隐藏标识 • 指标类型：数值型(0)或字符串型(1) • 指标单位 • 子节点列表 |
| 配置警报阈值 | 设置监控项的报警阈值，并校验数据合理性 | • 告警规则名称：必填 • 规则类型：如实时(realtime)或周期性(periodic) • 告警阈值表达式：如”usage>90” • 执行周期：周期性规则的检查间隔(秒) • 告警触发次数：达到指定次数后触发告警 • 标签：键值对形式的标签信息 • 注解：键值对形式的附加信息 • 告警内容模板 |
配置是否成功 |
| 添加监控项目 | 通过对话方式新增监控项 | • 监控基本信息（必填）：监控任务的基础配置 • 监控参数列表（必填）：至少一个参数，每个参数包含： - 参数标识字段（如”port”） - 参数值（如”8080”） - 参数类型（0:数字、1:字符串、2:加密字符串等） • 收集器标识（可选）：指定使用的收集器 |
添加是否成功 |
| 查询监控项表单信息 | 查询新增监控项所需填写的表单字段 | 监控类型名称（如：api、database等） | 参数定义列表，每个参数包含： • 监控应用类型名称 • 参数字段名称/标识符 • 字段类型 • 是否必填 • 参数默认值 • 取值范围/限制 • 可选值列表 • 键值对相关信息 • 参数依赖关系 |
| SQL 执行 | 允许 LLM 生成 SQL 查询数据 | Calcite 能解析的标准 SQL 语句 | SQL 执行结果 |
| 表结构信息获取 | 获取表的结构信息 | 表名称 | 表的定义语句 |
| 获取指标历史信息 | 根据时间范围，获取某个指标的历史信息 | • 监控任务ID：必填，路径参数 • 指标完整路径：必填，格式为”应用.指标类型.指标名称” • 标签过滤：选填，按特定标签筛选数据 • 历史时间范围：选填，默认为6小时 |
历史指标数据，包含： • 监控任务ID • 监控类型 • 监控指标类型 • 监控指标字段 • 监控范围查询数据 |
| 数值比较 | 比较两个指标的大小，解决LLM数学能力弱的问题 | 比较表达式，例如 20MB>10MB | 比较结果（大于、小于、等于） |
3.2.4. 协调器
协调器主要负责上下文的管理。同时维护与前端的连接，以保证在 Agent 多次调用工具过程中的信息输出。
功能职责：
- 管理多轮对话状态（记忆）
- 处理上下文信息传递
- 维持与前端的交互
工作流程：
- 接收用户输入
- 调用 Agent 处理用户请求
- 保存聊天至全局记忆中
- 响应 Agent 的输出
3.3. 组件实现
3.3.1. Tool（工具）
Tool 是系统中的基础构建块，代表 Agent 可调用的功能单元。Tool 类设计为抽象基类，提供了通用的工具属性和方法。
核心功能：
- 定义工具名称、描述和参数规范
- 提供参数验证机制
- 格式化调用参数
- 生成工具模式描述
主要派生类：
- MCPTool：MCP 服务中的工具
3.3.2. ToolCallService（工具调用服务）
ToolCallService 负责工具的管理和执行，作为工具仓库和执行引擎的角色。
核心职责
- 维护可用工具列表
- 判断是否支持特定工具
- 根据名称检索工具
- 执行工具调用并返回结果
- 验证工具参数合法性
主要实现类：
- MCPToolCallService：负责连接 MCP 并调用其服务
3.3.3. Context（上下文）
Context 是系统的状态管理组件，负责存储配置信息、历史记忆和运行时状态。
核心功能：
- 提供上下文标识和时间戳管理
- 支持上下文序列化
- 管理访问时间记录
主要派生类：
- SessionContext：管理整个会话生命周期的上下文，包括记忆存储和会话配置、提供对话历史记录。并支持相关记忆检索以及管理临时记忆清理
- AgentContext：管理 Agent 层面的配置和状态、提供LLM实例访问以及管理工具映射关系
3.3.4. Agent（智能代理）
Agent 是系统的核心智能组件，封装了 LLM 能力和工具调用逻辑，负责理解和处理用户请求。
核心职责：
- 处理用户请求
- 执行工具调用
- 监控查询、指标查询、监控配置、告警阈值配置
3.3.5. Coordinator
Coordinator 是整个系统的中央控制器，管理工作流程和状态转换等。
核心职责：
- 处理用户请求的入口点
- 管理 Agent 响应处理
- 处理工具调用数据
- 维护上下文状态
- 控制迭代次数
- 跟踪聊天进度
工作流程
- 用户请求首先由 Coordinator 接收，并存入记忆
- Coordinator 将请求转发给 Agent
- Agent 分析请求并决定是直接回答还是调用工具
- Agent 响应结果由 Coordinator 存入记忆
- 如需工具调用，Coordinator 调用 Agent ，Agent 通过 ToolCallService 执行相应 Tool
- 工具执行结果由 Coordinator 存入记忆
- 然后工具执行结果交由 Coordinator 返回给 Agent 进行进一步处理
- 直到完成整个任务
4. 可交付成果
通过引入 Agent 增强的智能监控助手，使监控系统更加智能化、人性化。具体收益包括：
- 降低使用门槛：通过自然语言交互，使非技术用户也能轻松操作复杂的监控系统
- 提升效率：用户可以通过简单对话快速查询监控数据、配置监控项和阈值，无需在多个界面间切换
- 增强分析能力：Agent 可以对监控数据进行智能分析，提供更有价值的洞察
- 扩展生态：为 Apache HertzBeat 开辟 AI 赋能的新方向，吸引更多开发者参与
项目完成后，将为 Apache HertzBeat 留下一个完整的 Agent 集成框架，使社区能够持续扩展和改进 AI 能力，并为其他 Apache 项目提供 LLM 集成的参考实现。
除此之外还将为 Apache HertzBeat 社区留下设计文档和用户文档。
5.实施计划
项目预计持续三个月，目标是构建基于 AI 代理的监控系统，并完成 MCP 协议的集成及前端交互设计。我每天可投入 5-8 小时 进行开发，其余时间可能需要处理研究生导师安排的任务和论文的阅读。计划划分为四个阶段，每个阶段都有明确的目标和任务，以确保项目的稳步推进。
第一阶段：基础 Agent 框架搭建与调试（6 月 3 日 - 6 月 29 日）
目标： 搭建并测试核心 Agent，使其能够独立运行，并确保多轮对话的基本可用性。
| 时间 | 任务 |
|---|---|
| 6 月 3 日 - 6 月 8 日 | 实现基础 Agent 功能并实现协调器，测试其运行情况。 |
| 6 月 9 日 - 6 月 15 日 | 继续完善框架，增加记忆模块，确保 Agent 支持多轮对话。 |
| 6 月 16 日 - 6 月 22 日 | 优化 Agent 交互，使整体框架能够正确运行，并确保各组件协同工作。 |
| 6 月 23 日 - 6 月 29 日 | 实现完整的 Agent 机制，调整 Prompt 以提升整体智能性和稳定性。 |
第二阶段：MCP 协议集成与工具开发（6 月 30 日 - 7 月 27 日）
目标： 完成 MCP 协议的对接，开发 MCP 服务器所需的各类工具，使系统能够支持标准化监控与告警配置。
| 时间 | 任务 |
|---|---|
| 6 月 30 日 - 7 月 6 日 | 初步集成 MCP 协议，确保 Agent 能够与 MCP 服务器通信。 |
| 7 月 7 日 - 7 月 13 日 | 开发 MCP 服务器的 监控项查询、指标查询、报警查询 工具。 |
| 7 月 14 日 - 7 月 20 日 | 开发 配置警告阈值、配置监控项 相关工具，支持个性化的监控管理。 |
| 7 月 21 日 - 7 月 27 日 | 开发 SQL 执行、表结构获取 等功能，使 MCP 服务器支持高级查询和可视化分析。 |
第三阶段：前端交互开发与 AI 代理对接（7 月 28 日 - 8 月 17 日）
目标： 设计并开发前端界面，实现前端对 AI 代理的交互支持，并增强可视化功能。
| 时间 | 任务 |
|---|---|
| 7 月 28 日 - 8 月 3 日 | 搭建前端基础框架，完成前端与后端 AI 代理的基本对接。 |
| 8 月 4 日 - 8 月 10 日 | 增加前端 图表渲染支持，提供数据可视化能力。 |
| 8 月 11 日 - 8 月 17 日 | 进一步优化前端，支持 可配置的 MCP 服务，增强用户交互体验。 |
第四阶段：系统联调与最终优化（8 月 18 日 - 9 月 1 日）
目标： 确保前后端系统联调无误，进行全面测试与优化，提交最终成果。
| 时间 | 任务 |
|---|---|
| 8 月 18 日 - 8 月 24 日 | 进行 前后端联调，优化系统性能，并排查潜在问题。 |
| 8 月 25 日 - 9 月 1 日 | 最终测试、完善文档，提交最终成果，并接受导师评估。 |