基于开源 Jifa 打造 AI 智能诊断助手：让 Heap Dump、GC 和线程问题交给 AI 分析-育师

基于开源 Jifa 打造 AI 智能诊断助手：让 Heap Dump、GC 和线程问题交给 AI 分析

在 Java 生产环境中，Heap Dump、GC 日志和 Thread Dump 往往是定位问题最重要的证据，但传统分析需要工程师熟悉大量命令、指标和对象引用关系。

我基于开源项目 Eclipse Jifa 做了一套增强：让 Jifa 不仅能够分析文件，还能够通过 MCP 和 AI Agent，帮助用户直接回答“是否存在内存泄漏”“哪个线程被阻塞”“GC 为什么频繁”等生产问题。

欢迎大家体验、提出建议，也欢迎给项目点一个 Star：

GitHub - 01o00o10/jifa-ai-mcp: 🔬 Online Heap Dump, GC Log, Thread Dump & JFR File Analyzer，AI-MCP · GitHub

这次主要改了什么？

首先，将原有 Java 模块从 Gradle 迁移到了 Maven，保留了原项目的分析能力和构建行为，包括 MAT、OSGi、HPROF Hook 以及本地 MAT 依赖装配。

其次，新增了独立的 MCP 模块。MCP 可以动态暴露 Jifa 已注册的 Heap Dump、GC Log、Thread Dump 和 JFR 分析 API，AI 不需要猜测文件内容，而是可以调用真实的分析工具获取证据。

另外，前端新增了悬浮式 AI 诊断助手。用户选择一个分析文件后，可以直接提问；不同文件拥有独立会话，刷新页面后仍可以恢复之前的对话。

当前支持配置 DeepSeek、Qwen 以及其他 OpenAI 兼容模型，并支持运行时修改模型、Base URL、API Key 和 MCP 地址。

它是一个什么样的 AI Agent？

这里不是简单地把用户问题转发给大模型，而是实现了一个面向 Jifa 分析场景的轻量 AI Agent：

```text
用户问题
↓
读取当前文件的 Jifa 初始分析证据
↓
AI Agent 将当前文件类型对应的分析 API 注册为工具
↓
大模型判断下一步是否需要调用工具
↓
MCP / Jifa 执行真实分析
↓
工具结果返回给 Agent
↓
继续分析，或生成最终诊断结论
```

其中，大模型负责推理和决策；Agent 负责上下文管理、工具调用、循环控制、结果汇总和会话保存；Jifa 和 MCP 负责真正执行文件分析。

底层实现原理

1. 先获取事实，再让 AI 推理

当用户选择 Heap Dump 并提问“分析疑似内存泄漏”时，服务端首先调用 Jifa 的分析 API，获取 Leak Suspects、对象占用、引用链等真实数据，然后把这些结果作为证据交给模型。

这样可以避免 AI 仅凭问题描述臆测结论。

2. MCP 将 Jifa 分析能力转换成 AI 工具

MCP 服务启动后，会读取 Jifa 的 `ApiService.supportedApis()`，动态生成工具列表。例如：

```text
heap-dump.overview
heap-dump.histogram
heap-dump.outboundOfObject
gc-log.diagnose
thread-dump.deadlock
```

模型需要更多证据时，Agent 会调用对应工具，MCP 再将参数转换为 Jifa API 所需的 `Path`、枚举和分页参数，最后复用原有分析执行链路。

3. Agent 会控制工具调用循环

实际使用中，模型有时会反复请求同一个工具。为避免无限循环，Agent 做了几层保护：

- 使用“工具名 + 参数”识别重复调用。
- 相同工具和参数只执行一次。
- 单个工具结果和总证据都有大小限制。
- 单次请求最多进行 8 轮工具决策。
- 检测到重复调用或达到预算后，创建一个干净的无工具上下文，强制生成最终诊断。

这也是解决部分 DeepSeek 模型输出 DSML、`data:` 或工具协议文本的关键：最终总结不再复用原来的工具调用轨迹。

4. 会话保存在分析机器

项目没有引入 Redis。AI 会话以 JSON 文件的形式保存在实际执行分析的机器上：

```text
${jifa.storage-path}/ai-sessions/{sessionId}.json
```

在 Master/Worker 模式下，AI 请求会被路由到文件所属 Worker，会话文件和分析缓存保持在同一台分析机器上。前端则使用浏览器 `localStorage` 保存展示记录，因此刷新页面后仍能恢复当前文件的会话。

从 Heap Dump 到最终诊断

以疑似内存泄漏为例，完整链路大致如下：

```text
上传 java_pid.hprof
↓
Jifa 保存文件并建立分析上下文
↓
AI Agent 获取 Leak Suspects / Histogram 初始证据
↓
模型发现 ArrayList 保留大量对象
↓
Agent 调用 outboundOfObject 等引用分析工具
↓
MCP 复用 MAT / OSGi 分析能力
↓
模型综合 retained size、引用链和栈信息
↓
输出：结论、证据、风险等级和处理建议
```

最终结果仍然以 Jifa 分析数据为基础，AI 主要负责把底层分析结果转换成更容易理解、更适合生产排障的结论。