Prometheus
基于Neo4j知识图谱的多Agent系统，让LLM真正「理解」代码结构再做自主修复
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
基于Neo4j知识图谱的多Agent系统，让LLM真正「理解」代码结构再做自主修复
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一下这个场景：凌晨两点，你接手了一个陌生的十万行代码库，需要在毫无上下文的情况下定位一个间歇性崩溃的 bug。传统方式是通读代码、搜日志、靠经验猜测——往往耗时数小时。而 Prometheus 给出了一个截然不同的答案：让 AI Agent 先「画」出代码的知识图谱，再基于这张图「思考」问题出在哪里，而不是盲目猜测。
这正是 Prometheus（普罗米修斯）项目的核心使命。它不只是一个自动修复 Bug 的工具，而是一套基于知识图谱的代码库智能推理框架——通过将代码结构、AST 语法树、文档注释全部抽象为图数据库中的节点与边，让 AI Agent 能够像人类专家一样，沿着依赖链路「追溯」问题根源。
随着 AI 编程工具（Claude Code、Cursor、Copilot）的普及，一个核心矛盾愈发突出：这些工具在单文件、简单任务上表现出色，但面对大型代码库时往往力不从心。 原因在于，传统的 AI 编程助手依赖的是「上下文窗口」——将尽可能多的代码塞进提示词，期待 AI 自己「理解」其中的关联。但代码不是文本，文件之间的 import 依赖、函数调用链路、类的继承关系形成了复杂的网络，任何一个环节的遗漏都可能导致 AI 生成错误的修改。
Prometheus 团队敏锐地捕捉到了这个问题。2025 年，其研究团队发表了同名 arXiv 论文（arXiv:2507.19942），系统性地提出了 Repository-Level Problem Solving（仓库级问题求解） 框架，核心思路是：先用知识图谱将代码库的结构化信息「固化」下来，再让 Agent 在图上做推理，而不是在原始文本上做检索。同年 11 月，Prometheus 在 SWE-bench 自动化软件工程评测中拿下 GPT-5 赛道 TOP 5 和 TOP 1 的成绩——这是业内最具权威性的 AI 代码修复能力基准测试。
图1：Prometheus 系统架构图，展示了知识图谱构建 → 多 Agent 协同 → 验证反馈的完整链路
Prometheus 的技术栈选择非常明确：Python 3.11+ / FastAPI / Neo4j 图数据库 / LangGraph 状态机 / LangChain 生态。这一组合并非随意堆砌，而是经过仔细权衡的结果。
项目使用 Neo4j 图数据库 作为代码知识表示的核心载体。Neo4j 是业界最成熟的原生图数据库，其 Cypher 查询语言天然适合表达代码中的「谁调用谁」「谁继承谁」「谁引用谁」关系。在 docker-compose.yml 中，Neo4j 被配置为使用 6GB 初始堆内存、最大 12GB，可处理中大型代码库的图构建任务。
知识图谱的构建管道由 prometheus/neo4j/ 和 prometheus/graph/ 模块负责。从 pyproject.toml 的依赖可以看出，项目使用 tree-sitter 作为代码解析引擎——tree-sitter 是 GitHub 开源的增量解析库，能够将任意编程语言的源代码解析为 AST（抽象语法树），并支持增量更新（只重解析变化的部分）。有了 AST，再经过 chunking 和 embedding 处理，最终将函数、类、import 关系映射为图中的节点和边。
图谱构建支持多个可配置参数：
PROMETHEUS_KNOWLEDGE_GRAPH_CHUNK_SIZE：知识块大小（默认 5000 tokens），控制每个图节点的语义粒度PROMETHEUS_KNOWLEDGE_GRAPH_CHUNK_OVERLAP：块间重叠（默认 500），防止跨块信息丢失PROMETHEUS_KNOWLEDGE_GRAPH_MAX_AST_DEPTH：AST 最大深度（默认 1），控制依赖追踪的层数这些参数通过 example.env 暴露给用户，说明项目对可配置性有较高的要求。
Prometheus 的核心推理逻辑运行在 LangGraph 状态机之上。LangGraph 是 LangChain 团队开发的「有向图结构化 Agent」框架，与 LangChain 的 Chain 不同，LangGraph 允许你在状态机上定义多个节点（Agent）和边（状态转换逻辑），实现更复杂的工作流控制。
从 README 透露的架构信息来看，Prometheus 包含以下几类协作 Agent：
这四类 Agent 通过 LangGraph 的状态图串联工作，数据以 JSON 状态对象在各节点之间流转。LangGraph 的 checkpoint 功能（项目依赖 langgraph-checkpoint-postgres）还支持在任意节点保存和恢复工作状态，方便长时间运行的任务断点续传。
Prometheus 并没有绑定某一家的 LLM API。依赖中可以看到：
langchain-anthropic：Anthropic Claude 系列langchain-openai：OpenAI GPT 系列langchain-google-genai：Google Gemini 系列litellm：统一的 LLM 抽象层，支持 OpenAI 兼容格式的任意后端（包括本地部署的 Ollama）通过 PROMETHEUS_ADVANCED_MODEL 和 PROMETHEUS_BASE_MODEL 两个环境变量，用户可以分别配置高级推理模型和基础任务模型，实现按任务复杂度分配资源。PROMETHEUS_BASE_MODEL_TEMPERATURE=0.5 说明项目对输出确定性有一定要求但也保留创造性空间。
项目的主入口是 prometheus.app.main:app（FastAPI 应用），监听端口 9002。FastAPI 本身支持自动 OpenAPI 文档生成、异步请求处理、Pydantic 数据校验等现代 Python Web 开发特性。项目还引入了 JWT 认证（pyjwt）和 CORS 配置，支持接入外部身份提供商和跨域 Web 前端。认证默认关闭（PROMETHEUS_ENABLE_AUTHENTICATION），本地开发可直接通过 example.env 中的配置启用。
LangGraph 的状态通过 langgraph-checkpoint-postgres 持久化到 PostgreSQL，而非存放在内存或临时文件。这意味着即使服务重启，Agent 的中间推理状态也不会丢失——对于需要数小时才能完成的复杂修复任务来说，这个设计至关重要。PostgreSQL 的选型也暗示了项目对数据一致性和事务支持有较高要求。
Prometheus 的部署体验是它相比同类研究项目最大的优势之一。项目提供了完整的 Dockerfile + docker-compose.yml，真正实现了一键启动。
docker-compose 定义了三项服务：
| 服务 | 镜像 | 用途 | 资源需求 |
|---|---|---|---|
neo4j | 官方 neo4j 镜像 | 代码知识图谱存储 | 6-12GB RAM |
postgres | postgres:16 | LangGraph 状态持久化 | 1GB RAM |
prometheus | 本地构建 | 主应用（FastAPI + Agent 逻辑） | 2-4GB RAM |
主应用 Dockerfile 基于 python:3.11-slim，安装了 Docker CLI（用于在容器内操作 Docker，即 Docker-in-Docker），并通过 pip install .[test] 安装所有依赖。容器间通过 prometheus_network 桥接网络互通，Neo4j 的 bolt 端口 7687 和 PostgreSQL 的 5432 对主服务可见。
实际部署步骤：
git clone 仓库cp example.env .env 并填入 API Keydocker-compose up -dhttp://localhost:9002（FastAPI 自动生成 Swagger 文档）主要前置依赖： 需要 Docker 和 Docker Compose（容器内嵌 Docker CLI 所以无需宿主机 Docker socket）；需要提供至少一个 LLM API Key（OpenAI/Anthropic/Gemini 任一）；16GB RAM 机器可流畅运行。
不支持快速部署的情况： 如果没有 Docker，则需要手动安装 Python 3.11+、Neo4j 5.x、PostgreSQL 16，并逐个配置环境变量——门槛较高。Kubernetes manifest 未提供，大规模生产部署需要自行编写。
用户提交一个 Bug Issue（如「用户登出后 Token 未清除导致会话劫持」），Prometheus 的处理链路如下：
localStorage.clear() 调用，生成 patch整个过程完全自主执行，无需人工介入。
用户可以用自然语言询问：「这个代码库中用户认证模块是如何处理密码重置的？」
检索 Agent 会先在图谱中找到 PasswordResetHandler 类及其所有邻居节点（调用的函数、引用的类、被继承的父类），再结合 AST 解析得到的参数类型和返回值，最终生成一段带有源码引用的结构化回答。这比直接让 LLM 在原始代码上「大海捞针」要高效和准确得多。
对于新加入项目的开发者，Prometheus 可以一键生成整个代码库的知识图谱可视化。Neo4j Browser 本身提供了 Cypher 查询和图可视化能力，结合 Prometheus 的 chunking 策略，可以按模块、按依赖深度、按文件大小等多种维度展示代码结构。
Prometheus 作为一个 2025 年的前沿研究项目，仍有几处值得关注的局限性：
1. 知识图谱构建成本高。 将大型代码库（如 Linux Kernel、Flutter）完整建图需要消耗大量 LLM API 调用和计算资源，且 chunking 策略对最终推理质量影响显著——选择不当可能导致关键依赖关系被切断。用户需要根据实际代码库特征反复调参。
2. Docker-in-Docker 的安全与资源开销。 复现 Agent 在容器内运行 Docker 命令来启动被测应用，这意味着 Prometheus 容器必须以 privileged 模式运行或挂载宿主机的 Docker socket——这在多租户环境下存在安全风险。单用户本地部署问题不大，但在共享服务器上需要谨慎。
3. 对 SWE-bench 以外的场景泛化能力有待验证。 Prometheus 在 SWE-bench 上表现出色，但 SWE-bench 的数据集（主流开源项目 + 真实 GitHub Issue）有其局限性。对于非英语 Issue、企业内部代码库、特殊领域语言（如 Verilog、TLA+），表现可能打折扣。
4. Neo4j 运维复杂度。 Neo4j 作为图数据库虽然功能强大，但其运维（备份恢复、集群配置、监控）比普通 SQL 数据库复杂一个量级。对于只想快速试用的用户来说，额外维护一个图数据库服务是一笔不低的开销。
Prometheus 的出现代表了 AI+软件工程领域的一个新方向：从「让 AI 生成代码」进化到「让 AI 先理解代码，再做决策」。知识图谱的引入提供了一种结构化的中间表示，使得 AI 的推理过程不再是黑箱——你可以通过查询图谱看到 Agent 的思考路径，发现它在哪个环节「走偏了」。
从更宏观的视角看，Prometheus 所在的「Code Agent」赛道正在快速升温。2025 年，围绕自主代码修复、代码审查自动化、代码库问答的产品和研究大量涌现——Devin、SWE-agent、Claude Code Agent Mode、GitHub Copilot Workspace 都在尝试解决类似问题。Prometheus 的差异化在于：它把知识图谱作为一等公民，而非仅仅用作检索增强。这种「先建图、再推理」的范式，可能成为未来代码库级别 AI 工具的标准架构。
项目已发表学术论文（arXiv:2507.19942），作者来自多所高校和研究机构，有较强的学术背书。加上 Apache 2.0 许可证（非 README 中显示的 GPL-3.0，实际仓库 license 文件为 Apache 2.0），商业使用友好。
git clone https://github.com/EuniAI/Prometheus.git
cd Prometheus
cp example.env .env
# 编辑 .env，填入 ANTHROPIC_API_KEY 或 OPENAI_API_KEY
docker-compose up -d
# 访问 http://localhost:9002/docs 查看 Swagger API 文档
图2：Prometheus 项目 Logo，来自 docs/static/images/icon.jpg