企业官网建设流程全解析

Prometheus 是一个基于知识图谱驱动（Knowledge-Graph-Driven）的 AI Agent 平台，通过多智能体协同与 LangGraph 状态机，自动完成 Bug 检测、复现、修复与验证的完整流水线。本文将拆解 Prometheus Bug 修复流水线内幕，带你读懂 Detect-Reproduce-Repair-Verify（DRRV）四步全流程：它不是"猜"出修复方案，而是靠可执行的测试来"推理 + 验证"，这也是它能在 SWE-bench 等基准上名列前茅的关键。

📌 上图为 Prometheus 官方架构图：统一的 Unified Knowledge Graph 位于中心，Classification Agent、Reproduction Agent、Context Retrieval Agent、Patch Generation & Validation Agent 围绕 LangGraph 状态机协作，所有测试都在 Docker 容器中隔离执行。

一、什么是 DRRV：为什么"能验证"才是关键

很多 AI 修 Bug 工具（单 Agent 一次性推理）的短板是：生成补丁后缺乏闭环验证，修没修好全靠"感觉"。Prometheus 的 DRRV 流水线补上了这四块拼图：

整条流水线的入口是 prometheus/lang_graph/graphs/issue_graph.py，它把四类 Issue（bug / feature / question / documentation）路由到各自的处理子图；而 Bug 主线的编排逻辑集中在 prometheus/lang_graph/subgraphs/issue_bug_subgraph.py。

二、Detect 检测：分类 Agent 如何精准识别问题

当请求中issue_type == "auto"时，issue_classification_subgraph.py 会执行三步：

1. 构造初始消息：把 Issue 标题、正文、评论组装成上下文；
2. 知识图谱检索：通过 Context Retrieval 子图从 Neo4j 图谱中取回相关代码与文档片段，让分类"有据可依"而不是纯靠文字猜测；
3. LLM 分类：由IssueClassifierNode输出 bug / feature / question / documentation 四类之一，并路由到对应子图。

这一步的意义在于：只有被判定为 Bug 的 Issue 才会进入昂贵的"复现 + 修复"流水线，成本控制从路由阶段就开始了。

三、Reproduce 复现：先让 Bug"现身"，再谈修复

复现子图 bug_reproduction_subgraph.py 是整条流水线最体现"工程师思维"的环节——它模仿人类调试：先写一个能暴露 Bug 的测试，再运行它。

内部流程（共 10 步）：

• 生成初始系统消息（IssueBugReproductionContextMessageNode）
• 从知识图谱检索 Bug 相关上下文（ContextRetrievalSubgraphNode）
• LLM 编写复现测试补丁（BugReproducingWriteNode，可调用工具读写文件）
• 按需编辑相关文件（BugReproducingFileNode）
• 生成 Git diff 得到bug_reproducing_patch
• 把改动同步进 Docker 容器（UpdateContainerNode）
• 在容器中执行测试命令（BugReproducingExecuteNode）
• 结构化节点判定是否复现成功（BugReproducingStructuredNode→reproduced_bug布尔值）
• 未复现则进入重试循环：重置消息 →GitResetNode回滚仓库 → 回到"写补丁"节点，带着上一轮的失败反馈重写

这种"写测试 → 跑测试 → 判结果 → 回滚重试"的闭环，让复现过程具备自纠错能力，而不是单次生成一锤定音。复现成功后，产出的复现测试文件、命令和补丁会作为后续验证的"判分标准"。

四、Repair 修复：根因分析 + 多候选补丁生成

一旦reproduced_bug = true，流程进入已验证 Bug 子图 issue_verified_bug_subgraph.py，对应 DRRV 中的 Repair 阶段：

1. 上下文构建：围绕修复目标重新检索知识图谱（bug_fix_query/bug_fix_context）；
2. 语义根因分析：IssueBugAnalyzerNode用强推理 LLM 分析 Bug 根因、生成修复假设，可调用工具深入查证；
3. 生成代码编辑：EditNode产出修复改动，GitDiffNode转成edit_patch并回滚工作区，保持仓库干净；
4. 多候选补丁：按number_of_candidate_patch参数生成多个候选补丁（官方实现中会取一半以控制成本），逐个送入验证；
5. 最优补丁选择：FinalPatchSelectionNode由 LLM 在所有"复现测试通过"的候选中挑出最优的一个。

关键设计：修复不是一次通过就结束。验证失败的日志（reproducing_test_fail_log、existing_test_fail_log）会回传到根因分析节点，形成"分析 → 改代码 → 验证 → 带错误信息再分析"的迭代环。

五、Verify 验证：Docker 隔离下的多层测试

验证子图 bug_fix_verification_subgraph.py 执行"双补丁叠加 + 容器内跑分"：

• 双补丁叠加：先GitApplyPatchNode应用修复补丁edit_patch，再叠加复现补丁reproduced_bug_patch（即把当初暴露 Bug 的测试也带上）；
• 容器同步：UpdateContainerNode将代码推入 Docker 沙箱，保证验证环境与宿主机完全隔离；
• 执行判分：BugFixVerifyNode运行复现命令，BugFixVerifyStructuredNode输出是否通过。

此外还有两道可选验证关卡：

• 回归测试：bug_get_regression_tests_subgraph.py 先从图谱中选出与 Bug 相关的回归测试集合，再运行确认"没修坏别的功能"；
• 存量测试：run_existing_tests_subgraph.py 运行项目现有测试套件。

最终流水线输出（见 issue_bug_subgraph.py 的invoke返回值）包含：edit_patch（最终修复补丁）、passed_reproducing_test/passed_regression_test/passed_existing_test（三级测试结果）以及issue_response（面向用户的回复总结）。

六、成绩单：DRRV 闭环带来的实测收益

在 SWE-bench Lite 上，仅用 Deepseek-V3 驱动的 Prometheus 就达到28.67% Pass@1，与 GPT-4 系 Agent 系统处于同一梯队——这正是"复现 + 验证"闭环的价值：模型能力之外，工程化流水线本身就在贡献成功率。

据官方 News（见 README.md），Prometheus 在启用 GPT-5 的 SWE-bench 排行榜中取得过 TOP 5 乃至 TOP 1 的成绩。对普通用户来说，结论很简单："能复现、能验证"的修复流水线，比"一次生成"的补丁工具更可信。

七、延伸阅读与动手

• 多智能体架构总览：docs/Multi-Agent-Architecture.md
• GitHub Issue 调试指南：docs/GitHub-Issue-Debug-Guide.md
• 上下文检索子图：prometheus/lang_graph/subgraphs/context_retrieval_subgraph.py
• 知识图谱构建：prometheus/graph/knowledge_graph.py

想亲自跑一遍 DRRV 流水线？克隆仓库后按 README.md 的 Quick Start 配置.env（复制自 example.env）、生成 JWT 密钥并执行docker-compose up --build，即可通过http://localhost:9002/docs提交 Issue 处理请求。观察edit_patch与三级测试结果的返回，你就完整体验了一次 Detect → Reproduce → Repair → Verify 的全过程。