伦敦大学，瑞典皇家理工学院等发布了一个名为Prometheus的AI系统。
它通过将代码库变成一张巨大的知识图谱，解决了跨越9种编程语言的真实GitHub问题。
它不再局限于特定语言或预设的测试环境，而是像一个经验丰富的软件工程师团队，直接面对真实、复杂且多语言的开源项目。
这一切都源于一个简单而强大的理念：要让AI真正理解代码，就必须让它看到整个项目的全貌，而不仅仅是零散的文件。
Prometheus用一张图谱理解整个代码世界
软件工程自动化的探索从未停止。
从早期集成开发环境（IDE）的代码补全，到静态代码分析工具，再到Facebook的自动bug修复系统SapFix和微软的IntelliCode，每一步都让机器更懂代码。
大型语言模型的出现，更是将这一进程推向了高潮。
GitHub Copilot让AI辅助编码成为日常，而SWE-bench基准测试的建立，则为衡量AI解决真实世界软件工程问题的能力提供了一把标尺。
像SWE-agent这样的先行者在SWE-bench上取得了不错的成绩，但它们普遍存在两个绕不开的限制。
第一个限制是语言单一。
它们几乎都专注于Python，因为SWE-bench最初就是一个纯Python的测试集。
这些方法能否推广到Java，C++或JavaScript等其他语言的代码库，一直是个未知数。
第二个限制是依赖温室。
先前的方法严重依赖SWE-bench为每个问题预先构建好的Docker容器。这意味着AI智能体无需亲自搭建环境或复现问题，直接在一个准备好的、无菌的环境里开始工作。
这在真实世界中是不现实的，自动化项目构建和问题复现，本身就是解决问题的第一步，也是最棘手的一步。
Prometheus的诞生，就是为了打破这两个限制。
它提出了一种全新的范式：将整个代码存储库，无论其结构多复杂，使用了多少种编程语言，都统一转换成一张知识图谱。
这张图谱就像是整个项目的一幅高清大脑地图。
它由三种核心的神经元（节点）构成。
文件节点（FileNode），代表项目中的每一个文件和目录。它们是地图上的基本地标，定义了项目的骨架结构。每个节点都记录着自己的唯一ID，相对路径和基本名称。
抽象语法树节点（ASTNode），这是理解代码语法的关键。通过Tree-sitter这个强大的多语言解析器，Prometheus能将源代码文件解析成一棵棵语法树。树上的每个节点，比如一个函数定义，一个变量声明，或一个if语句，都成为一个AST节点。它记录了代码的起止行号，具体的代码文本，以及它的语法类型。
文本节点（TextNode），负责处理非结构化的信息，比如Markdown文档或者纯文本文件里的说明。这些内容被切分成文本块，成为知识图谱中的文本节点，保留了项目的文档和注释信息。
这些神经元之间通过五种不同类型的突触（边）连接起来，共同描绘出代码库内部错综复杂的关系网络。
HAS_FILE边（黑色），连接目录和它包含的文件或子目录，维持了项目的文件层级结构。
HAS_AST边（紫色），将一个文件节点与其对应的抽象语法树的根节点连接起来，表明这是这个文件的代码结构。
PARENT_OF边（灰色），在抽象语法树内部，连接父节点和子节点，精确描绘了代码的句法层次，比如一个类定义包含了哪些方法定义。
HAS_TEXT边（蓝色），将文件节点（通常是文档）与其包含的文本块连接起来。
NEXT_CHUNK边（橙色），将连续的文本块按顺序连接，保证了文档内容的连贯性。
通过这种方式，文件结构，代码句法和自然语言文档被无缝地集成到一张异构图中。
这张图谱随后被持久化存储在Neo4j图数据库中。Neo4j的灵活性和高效的查询能力，让AI智能体能够对这个巨大的代码大脑进行快速、结构化的查询和推理。
Prometheus的设计巧妙之处在于，它只关注通用的关系，如包含，父子关系等，而不涉及特定语言的语法，比如Java的extends或implements。
这使得它天然具备了跨语言的能力。
五个智能体协同作战，像个专家团队
构建了知识图谱这个大脑之后，Prometheus派遣出一个由五个智能体组成的精英团队来解决实际问题。这个团队的工作流程，高度模拟了一个高效的人类开发团队。
团队的核心是上下文检索智能体（Context Retrieval Agent）。
它就像团队里的首席研究员或图书管理员，负责在庞大的知识图谱中精准地检索信息。其他智能体需要任何关于代码，文档或项目结构的信息，都会向它求助。
它的工作分为三步：检索，选择和精炼。
当接到一个查询时，比如找到与用户认证相关的代码，它会利用Neo4j的Cypher查询语言在知识图谱中进行结构化搜索。它能按文件名查找，按AST模式匹配（例如，找到所有名为login的函数），或者在文档中搜索关键词。
检索到的所有相关代码和文档片段会进入选择阶段。在这里，大型语言模型会评估每个片段与当前任务的相关性以及令牌效率，进行排序和过滤。
如果LLM认为当前的信息还不足以解决问题，就会进入精炼阶段。它会分析还缺少哪些信息，并触发新一轮的查询。这个检索-选择-精炼的循环会一直迭代，直到收集到足够精确和全面的上下文。
有了这个强大的信息中枢，其他四个智能体便可以各司其职，高效协作。
当一个GitHub问题报告被提交给Prometheus时，首先登场的是问题分类智能体（Issue Classification Agent）。
它像团队的分诊台，通过分析问题的描述文本，将其归类为错误（Bug），功能请求（Feature），文档问题（Documentation）或是一般性提问（Question）。
它会查询知识图谱，寻找错误模式，匹配现有功能，检查文档覆盖范围，只有被标记为错误的问题，才会进入下一环节。
接下来是错误复现智能体（Issue Verification Agent）。
这是团队中的侦探，它的任务是验证这个报告的错误是否真的存在，以及能否被稳定复现。这是之前AI智能体普遍缺失的关键能力。它会自动检测项目的构建系统（是Maven，Gradle还是npm？），并尝试运行相关的测试用例。
如果标准方法不行，它会利用LLM推理生成自定义的构建和测试命令，并在一个隔离的Docker容器中执行，确保环境纯净。
如果失败，它会分析日志，调整策略，反复尝试，直到成功复现错误或达到重试上限。这个过程中的所有日志，命令和受影响的文件都会被详细记录下来，作为后续修复的依据。
一旦错误被成功复现，补丁生成智能体（Patch Generation Agent）便开始工作。
它是团队里的外科医生。它会根据问题描述，复现日志和上下文检索智能体提供的信息，推理出错误的根本原因。然后，它直接在源代码中提出修改建议，生成一个修复补丁。
补丁生成后，它会立即运行构建和测试命令，确保这个补丁确实解决了问题，并且没有引入新的错误（即回归测试）。最终，一个Git格式的差异文件（diff）会被生成，清晰地记录了所有的代码改动。
补丁验证智能体（Patch Verification Agent）是团队的质量保证工程师。
它的职责只有一个：用最初复现错误的方法，再次验证应用了新补丁的代码。它会在一个全新的容器化环境中，严格执行复现命令。只有当所有相关的测试都顺利通过，没有任何错误或失败时，这个问题才被确认为已解决。
最后出场的是问题响应智能体（Response Generation Agent），团队的沟通专家。
它的工作是根据原始问题，生成的补丁和验证结果，撰写一份专业且友好的评论，发布到GitHub的原始问题页面。这份响应会清晰地解释系统对错误的理解，为修复它所做的具体更改，并确认修复已通过测试。它会保持开源社区的沟通语调，并且不会透露自己是一个AI。
这五个智能体，在统一知识图谱的支持下，构成了一个完整的，端到端的自动化问题解决流水线。
它在真实世界的表现令人信服
Prometheus的能力需要通过严格的实验来验证。研究团队设计了五个核心问题来评估它。
在与现有代码智能体的有效性比较中，Prometheus在SWE-bench Lite这个包含300个Python问题的精选基准测试上进行了评估。
实验结果显示，Prometheus使用成本相对较低的DeepSeek-V3模型，实现了28.67%的pass@1成功率（即一次性成功解决问题的比例）。
这个成绩超过了多个使用更昂贵GPT-4模型的基线系统，如CodeR（28.33%）和AutoCodeRover（19%），也超过了使用GPT-4o的Agentless（27.33%）。
虽然略低于同样使用顶级模型GPT-4o的AutoCodeRover（30.67%）和RepoGraph（29.7%），但考虑到模型成本的巨大差异（GPT-4o比DeepSeek-V3贵9到36倍），Prometheus的性价比极高。
更重要的是，Prometheus展现了其独特的解决问题的能力。在与三个基于GPT-4o的顶尖系统比较时，有42个问题是大家都能解决的。但Prometheus独立解决了10个其他三个系统都未能解决的问题。
一个典型的例子来自著名的Web框架Django。当一个子语言代码（如de-at，奥地利德语）被用作默认语言时，系统会错误地报警，即便其基础语言（de，德语）在支持列表中。这是因为Django应该能自动回退到基础语言。
其他系统，如Agentless，错误地修改了一个不相关的配置文件，因为它没能理解检查逻辑的真正位置。
Prometheus通过其知识图谱，精准定位到了验证逻辑所在的文件和AST节点，生成了与人类专家提交的黄金补丁在语义上完全等价的正确修复。
在多语言支持方面，Prometheus在SWE-bench Multilingual基准测试上接受了挑战。这个测试集包含来自9种编程语言的300个任务。
结果显示，Prometheus在全部七种参与评估的语言中都成功解决了问题，总体解决率为13.7%。其中在Java项目上表现最好，解决了34.9%的问题。
这是第一个在SWE-bench Multilingual排行榜上提交结果的系统，证明了其知识图谱架构在跨语言任务上的有效性。
为了检验在真实世界问题上的泛化能力，研究团队将Prometheus直接应用于两个流行的大型开源项目：LangChain和Open Hands。
这不再是有标准答案的基准测试，而是社区里正在发生的，悬而未决的真实问题。
在评估的八个真实GitHub问题中，Prometheus成功为其中的四个生成了有效的修复补丁，成功率达到50%。
解决的问题类型多种多样，包括模式生成，命令行工具的迭代限制，Docker权限错误和API速率限制。
这证明了Prometheus不仅能处理受控环境中的问题，也能在复杂的真实项目中发挥作用。所有成功的补丁都已被提交到相应的GitHub问题讨论中。这是现有代码智能体中，第一个公开报告在SWE-bench之外的真实问题上进行评估的工作。
在可扩展性方面，Prometheus同样表现出色。以SWE-bench Lite中的11个Python项目为例，最大的Django项目生成了超过9000个文件节点和22万个AST节点，而Sympy项目则生成了超过63万个AST节点。
这些数字对于Neo4j社区版来说只是小菜一碟，它能够可靠地支持数亿级别的节点和关系，包括超过1亿个AST节点和1000万个文件。这意味着Prometheus完全有能力处理当今世界上绝大多数大型软件项目的知识图谱构建和存储。
最后，在成本方面，Prometheus同样具有吸引力。使用DeepSeek-V3模型，解决一个SWE-bench Lite问题的平均API成本仅为0.23美元，在更复杂的SWE-bench Multilingual上也仅为0.38美元。
还是中国模型香啊！
低廉的成本使其成为学术研究和工业应用中一个非常可行的选择。
更令人振奋的是，在2025年9月，Prometheus团队将其V1.2版本与更先进的GPT-5模型结合，向难度更高的SWE-bench Verified排行榜提交了结果。
最终，PrometheusV1.2 + GPT-5取得了71.20%的问题解决率，在500个问题中解决了356个。这一成绩使其跻身排行榜的顶尖行列，尤其在scikit-learn（90.62%）和pydata/xarray（81.82%）等项目上表现极为出色，进一步证明了其架构的强大潜力和可扩展性。
任何人都能部署和使用这个系统
Prometheus不仅是一个停留在论文里的概念，它已经完全开源，任何开发者都可以部署和使用。
部署前需要准备好Docker，Docker Compose，Python 3.11以上版本以及大型语言模型的API密钥。
安装过程非常直接。
首先，克隆项目的代码仓库。
复制然后，配置环境变量，主要是填入你的API密钥。
复制生成用于身份验证的JWT密钥。
复制创建一个工作目录。
复制最后，启动所有服务。
复制服务启动后，就可以通过API接口（http://localhost:9002/v1.2）或者交互式文档（http://localhost:9002/docs）来使用Prometheus了。
对于本地开发，也可以通过pip安装依赖并直接运行开发服务器，方便进行调试和二次开发。
Prometheus代表了自动化软件工程领域的一次重要飞跃。它通过统一知识图谱和多智能体协作的创新架构，成功地解决了先前方法在多语言支持和真实世界问题复现上的两大核心痛点。
像Prometheus这种，将整个代码库视为一个整体，构建其语义网络，并在此基础上进行推理和修复，这或许是AI编程的未来新方向。
免费体验： https://euni.ai/
