先知晓再修复：面向软件问题解决的QA驱动的仓库知识获取

TL;DR ACQUIRE 框架将知识获取与补丁生成解耦，通过 QA 主动填补仓库理解空白，在 SWE-bench Verified 上 Pass@1 提升最多 4.4 个百分点，显著减少事实错误。

问题

问题背景

基于 LLM 的编码代理在自动化的软件缺陷修复上取得了显著进展，但在面对不熟悉的代码仓库时，常因对仓库结构和逻辑理解不足而生成事实错误的补丁，这一问题在 SWE-bench 等基准中广泛暴露，成为限制修复成功率的关键瓶颈。

现有方法局限

近期工作尝试通过修复前的仓库探索（pre-repair exploration）来补充上下文，例如 SWE-agent 或 OpenDevin 等框架会在生成补丁前浏览文件、搜索符号。然而，这些策略普遍是修复驱动（fix-driven）的，即直接根据问题描述盲目搜索可能相关的代码片段，并未显式诊断代理当前的知识缺口。这种“先广撒网再挑选”的思路带来两个后果：

1. 探索范围的粒度过粗，经常引入大量无关或不精确的上下文，不仅浪费 token 预算，还易干扰模型判断；
2. 即使获得了相关代码片段，代理仍可能缺乏对模块交互、数据流或设计意图的深层理解，导致补丁看似合理却在边界条件下失败。

技术挑战与重要性

软件仓库蕴含的知识是隐式、分布式且高度结构化的：一个缺陷修复可能涉及多个文件的接口契约、历史变更的意图，以及非平凡的控制流/数据流关系。将这种隐式知识主动转化为可验证的显式事实，而非被动地拼接文本片段，是自动化修复质的提升所必须突破的难点。业界对可靠、少误导的自动化修复需求强烈，因为即使微小的成功率提升，也能在大型代码库的持续集成中节省大量人工审查开销。

行业类比

这一挑战类似 AI 代码审查工具：只有先准确理解变更的上下文与设计约束，才能给出有价值的建议，否则只是模式匹配的表层检查。

核心洞察

• **将知识获取与修复解耦，通过 QA 机制把隐式知识缺口转化为显式、事实可靠的理解。** 现有的 pre-repair 方法采用“先探索后修复”的思路，但其探索过程由最终修复目标驱动，并未显式识别模型自身的知识盲区，导致收集到的代码上下文往往不精确或冗余。ACQUIRE 的独特之处在于引入类似开发者的“先理解再动手”范式：在修复前专门设置一个 **Questioner-Answerer 协作阶段**，Questioner 主动发问锁定缺失信息，Answerer 基于代码证据回答，最终产出的结构化 QA 知识直接传递给 Resolver。这种显式缺口定位避免了传统预测览中盲目遍历文件的低效，使后续修复选用的上下文更具针对性，从而大幅降低事实性错误。
• **QA 驱动的知识获取将代码探索过程从“一次性猜测”转变为可分解、可并行的证据推理。** 与 SWE-Agent 等依赖单次工具调用或 AutoCodeRover 预设探索策略不同，ACQUIRE 的 Answerer 通过自主探索（如搜索、阅读相关代码）为每个问题生成有根据的答案，且多个 QA 对可并行获取。这种设计不仅提高了吞吐量，还使知识获取过程具有可审计性：每次回答都附带代码证据链，便于定位幻觉来源。实验表明，该机制在 **SWE-bench Verified** 上 Pass@1 提升达 4.4 个百分点，且额外耗时和成本可控，证明了显式知识构建比隐式上下文注入更适用于复杂软件任务的修复。

方法

ACQUIRE 采用两阶段解耦架构，将软件问题修复中的知识获取与补丁生成明确分离，模拟资深开发者先理解再修复的模式。

输入与处理流程

• 输入：软件仓库快照与待解决 issue 描述。
• 整体链路：仓库 + issue → 第一阶段(知识获取) → 结构化 QA → 第二阶段(修复) → 补丁。

第一阶段：Question-Driven Knowledge Acquisition

该阶段的核心是将隐式知识缺口显式化为事实可靠的 QA 对，由两个角色协作完成：

• Questioner（提问者）：基于仓库上下文和 issue 信息，识别修复所需的知识断点，生成一系列针对性强的问题，覆盖代码结构、依赖关系、历史变更等关键维度。
• Answerer（回答者）：对每个问题进行自主仓库探索，通过检索文件、分析调用链、回溯 commit 记录等手段收集证据，给出有根有据的答案。答案包含明确的代码引用或文档依据，确保事实可靠性。
• 并行执行：多个 QA 对可并发处理，提升效率。

第二阶段：Knowledge-Informed Repair

Resolver（修复者） 以第一阶段产出的结构化 QA 知识作为上下文，结合 issue 描述生成修复补丁。该阶段不再进行额外仓库探索，而是直接利用已验证的明确知识，从而减少幻觉并加速推理。

与同类方法的差异

现有预修复探索方法多为修复驱动——在补丁生成过程中无差别探索仓库，未主动识别知识缺口，导致获取的上下文常偏泛化或无关。ACQUIRE 通过 QA 驱动将缺口定位与证据收集解耦，使知识获取更具针对性，事实准确性显著提升，进而使 Pass@1 指标在 SWE-bench Verified 上相对代表性方法提升最高 4.4 个百分点。

实验

实验设计

在 SWE-bench Verified 数据集上评估 ACQUIRE 框架的自动软件缺陷修复能力。以 Pass@1 为核心指标，对比多类修复前探索方法（fix-driven exploration），如基于检索增强生成（RAG）和盲目的代码库遍历。同时通过消融实验验证 QA 分解、类别引导提问 等设计的作用，并分析额外计算成本与时间开销。

关键发现

ACQUIRE 将 Pass@1 最高提升 4.4 个百分点，且额外的 API 调用成本和时间开销保持在适中水平。QA 驱动机制显式地将隐式知识缺口转化为结构化的事实性问答对，使修复阶段能获得高可靠性证据支撑，从而减少事实性错误。消融实验表明，将复杂问题分解为多个子问题（QA decomposition）优于直接生成修复方案，而按类别引导提问比自由生成问题更有效，前者能更系统地覆盖所需知识。

基线对比解读

与传统 fix-driven 方法（先探索代码再修复）不同，ACQUIRE 解耦知识获取与补丁生成：先由 Questioner 提出针对性问题，Answerer 通过自主仓库探索收集证据并给出答案，最后由 Resolver 利用 QA 记录生成补丁。这模拟了资深开发者“先理解再修改”的工作模式，避免了盲目探索带来的无关上下文干扰，从而显著提升修复准确率。在修复行为分析中，基于 QA 的上下文使 Resolver 更聚焦于问题根源，减少了因上下文误导导致的 pass-to-fail 回归。

行业影响

落地场景

ACQUIRE 的 QA 驱动知识获取 机制，可嵌入任何依赖 LLM 编码智能体 进行自动修 Bug 的 DevOps 流水线。具体应用包括：

• 代码托管平台（如 GitHub、GitLab）的 Issue 自动修复机器人，在生成 Patch 前先对仓库进行结构化问答，降低幻觉导致的错误修复。
• 企业内部代码库维护，当软件缺陷报告产生时，ACQUIRE 辅助新手开发者快速理解历史代码并给出修复建议。
• 低代码/无代码平台的逻辑纠错，当用户配置出错时，系统先通过 QA 获取上下文，再生成修正方案。

商业价值

根据论文，ACQUIRE 在 SWE-bench Verified 上将 Pass@1 最高提升 4.4 个百分点，且额外成本和时间开销可控。这意味着：

• 降低修复返工成本：传统探索式方法常因上下文不精确而生成错误补丁，导致多次重试。ACQUIRE 通过显式知识获取，提高首次修复成功率，直接减少 CI 资源和人工审核成本。
• 加速交付周期：知识获取与补丁生成解耦，可并行处理多个问题，提升整体缺陷解决吞吐量，对 SaaS 厂商的 SLO 保障有直接收益。
• 增强开发者体验：将新手开发者的仓库理解过程自动化，降低入职门槛，并减少因理解不足引入的新缺陷。

与现有产品/工作流的集成

• CI/CD 管道：在 git pull request 触发后，调用 ACQUIRE 阶段生成 QA 文档，再交给现有修复 Agent（如 SWE-Agent、AutoCodeRover）读取，提升其成功率。QA 结果可缓存为仓库元数据，供后续问题复用。
• Issue 管理系统：与 Jira、Linear 等集成，在 Issue 描述后自动追加 ACQUIRE 生成的 事实性问答，帮助人类开发者快速定位问题。
• 模型层兼容：ACQUIRE 框架模型无关，可直接替换底层 LLM 为 GPT-4、Claude 或开源模型，适应不同安全合规需求。

具体落地 Use Case

1. 电商平台双十一大促稳定性：促销期间软件缺陷可能导致交易中断。将 ACQUIRE 集成进应急修复流程，在收到高优 Bug 报告时，自动理解相关订单处理、库存同步等模块逻辑，生成高置信修复补丁，减少人工 on-call 压力。
2. 车载操作系统 OTA 问题修复：当车辆上报软件故障，ACQUIRE 可在云端快速分析对应版本代码库，通过问答厘清状态机转换、传感器依赖关系，确保生成的修复包不引入安全回归。集成于现有 OTA 管道 中，作为补丁生成前的强制验证步骤。

局限

• **多 Agent 协作的复杂性与计算开销**：ACQUIRE 框架引入 Questioner、Answerer、Resolver 三个角色，通过多轮问答与自主探索获取仓库知识。虽然论文声称额外成本与时延“适中”，但这种多 Agent 协作显著增加了 prompt 设计、交互协调的工程复杂度，并带来更多 LLM API 调用，对实际部署时的资源消耗与延迟控制构成挑战。此外，框架中的参数（如 QA 对数量、并行度等）需要针对不同场景调节，增加了调参负担，论文并未探索自动化确定这些超参的机制。
• **数据集与模型的泛化风险**：实验仅在 SWE-bench Verified 上进行评估，该数据集主要由 Python 仓库组成，问题类型与规模存在一定偏向。ACQUIRE 在处理多语言、大型单体或微服务架构仓库时的有效性待验证。同时，论文仅选用了有限的闭源/开源模型，未探讨更轻量或完全本地化模型场景，这限制了结论的推广范围。若仓库结构或问题领域与 SWE-bench 分布差异较大，QA 驱动的知识获取可能无法带来一致增益。
• **Question 质量依赖与误导风险**：ACQUIRE 的核心是 Questioner 生成针对性问题，但问题质量直接影响获取知识的价值与后续修复的准确性。论文通过分类引导提升问题覆盖度，并设计了质量评分机制，但若 Questioner 提出无关、歧义或完全错误的问题，Answerer 仍可能给出表面合理但实质无用的回答，这些低质量 QA 对 Resolver 构成噪声，甚至可能引入新的误解。论文没有给出过滤或纠正误导性问答的强效机制，这在实际任务中可能引发修复回退（pass-to-fail）现象。