Know Before Fix: QA-Driven Repository Knowledge Acquisition for Software Issue Resolution

• 关联论文：2607.11111
• 作者：Tom
• 更新：2026-07-20

一句话结论

ACQUIRE 提出在 LLM coding agent 真正开始修复代码之前，先用"问答对"方式系统地获取仓库知识，将知识获取与 patch 生成解耦，在 SWE-bench Verified 上将 Pass@1 提升最高 4.4 个百分点，同时大幅降低无效探索成本。

解决什么真问题

LLM-based coding agents 在 SWE-bench 等代码修复任务上取得了显著进展，但一类关键失败始终未能解决：因仓库理解不足导致的事实性错误（factual errors）。

具体来说，当一个 issue 描述（如"登录功能在 Safari 浏览器上报错"）被交给 Agent 时，issue 文本本身并不包含所需的仓库内部知识： - 模块间的依赖关系 - 隐式的 API 合约 - 数据流细节 - 跨越模块边界的故障溯源

Agent 因此退化为"基于关键词的浅层定位"，生成的 patch 违反隐式 API 合约，在错误的位置修 bug。更糟糕的是：这些知识不足的失败尝试，消耗了超过 4 倍的 token 成本和近 2 倍的执行步数，却一无所获。

⚠️ 存疑：「4 倍 token 成本 / 2 倍执行步数」原文未明确是否在 abstract 中给出，亦未注明具体实验条件，数字来源需进一步确认。

现有方法的根本缺陷：pre-repair repository exploration 以 issue 关键词驱动，没有主动识别 Agent 的知识缺口，探索到的是"issue 提到的东西在哪里"，而不是"Agent 修复这个 issue 真正需要知道什么"。

核心方法

ACQUIRE 的核心洞察：人类开发者面对陌生代码库时，不会直接上手修 bug，而是先花时间理解代码。ACQUIRE 将这个行为模式显式化为两阶段框架：

Stage 1: Questioner-Answerer 协作获取结构化仓库知识

Issue → Questioner → 目标性问题序列 → Answerer → 证据支撑的回答 → QA 对

Questioner 的职责是根据 issue 描述和当前已知的知识状态，主动识别"Agent 不知道但修复需要知道的东西"。关键在于识别知识缺口（knowledge gaps），而非简单地列出 issue 相关代码。

Questioner 提出的问题类型包括： - 依赖关系问题："这个函数 X 被哪些模块调用？" - 合约问题："函数 Y 的输入有什么隐式假设？" - 数据流问题："这个变量从哪来，中间经过哪些转换？" - 历史问题："这段代码上次修改的原因是什么？"（需要 git 历史）

Answerer 的职责是通过自主探索仓库来回答这些问题。Answerer 有工具使用能力（读文件、搜索代码、执行命令），但其回答必须： 1. 基于证据（evidence-grounded）：每个回答要引用具体的代码位置 2. 结构化输出：将回答组织成 QA 对，供后续使用

Stage 2: Resolver 基于 QA 知识生成 Patch

QA 知识 + Issue 描述 → Resolver → informed patch

Resolver 接收的是经过结构化整理的仓库知识，而非原始的、可能不精确的仓库上下文。QA 知识将 Agent 的隐式知识缺口转化为显式的、可验证的陈述。

关键机制：知识获取与 Patch 生成解耦（decoupling）。

整体流程图

Issue 描述
    ↓
[Stage 1: QA 获取]
    Questioner ──→ 目标性问题
         ↓
    Answerer ──→ 证据支撑的 QA 对（结构化）
         ↓
[Stage 2: Patch 生成]
    Resolver ──→ Informed Patch

与此前方法的本质区别

方法	探索驱动	知识缺口处理	上下文质量
传统 pre-repair 方法	Issue 关键词驱动	未识别	不精确、不完整
ACQUIRE	知识缺口驱动	显式识别并转化为 QA	结构化、证据支撑

关键实验与数据

• SWE-bench Verified：ACQUIRE 在代表性 pre-repair 方法上持续胜出，Pass@1 提升最高 +4.4 个百分点[校注：具体对比的 baseline 名称与原始数值原文未披露]
• 额外成本：4.4pp 提升对应的额外时间和 token 成本是"moderate"（适中），论文特别强调"modest additional cost and time"
• 失败模式改善：知识缺口显式化后，Agent 不再在不理解仓库的情况下盲目尝试 patch，减少了"高成本零产出"的失败案例

⚠️ 存疑：表格中「传统方法」的具体名称（如 RepoMind、SWE-agent 等）未在 abstract 中点名，无法精确对标；「several SWE-bench Verified 代表性方法」的清单建议联系作者获取。

亮点与局限

亮点

1. 问题定义精准：明确指出 coding agent 的核心瓶颈不是推理能力不足，而是仓库理解不足导致的事实性错误，并用数据量化了这个问题的代价（4× token，2× step）[校注：数字具体实验条件未披露]
2. 类比人类行为：Questioner-Answerer 的设计直接对应有经验开发者的行为模式——先理解再动手，这个类比很有说服力
3. decoupling 原则：知识获取和 patch 生成分离，使两个阶段都可以独立优化，也避免了边修边看、反复无效探索的问题
4. evidence-grounded 回答：Answerer 回答必须引用代码证据，这防止了"幻觉式回答"污染 patch 生成阶段

局限

1. Questioner 的能力天花板：Questioner 本质上也是一个 LLM，其识别"知识缺口"的能力受限于自身的代码理解水平；如果 Questioner 也"不知道自己不知道什么"，QA 质量就会打折扣
2. Answerer 的自主探索成本：Answerer 需要真正读代码、搜索代码来回答问题，这本身也是有成本的；虽然比直接修复失败成本低，但并非免费
3. 跨仓库泛化：SWE-bench 的仓库相对结构化，真实世界代码库可能更杂乱，QA 框架的有效性依赖于仓库结构是否支持"通过探索获取知识"
4. QA 知识的表示与利用：结构化 QA 如何被 Resolver 高效利用，Resolver 是直接读取还是额外训练？原文未深入讨论

对工程落地的启发

1. "先理解再动手"是 professional-grade coding agent 的必备能力：当前很多 coding agent 产品直接让 LLM 根据 issue 生成 patch，但如果 Agent 本身对仓库缺乏理解，patch 质量必然受限；ACQUIRE 证明了这个问题的工程可行性
2. 知识缺口识别是关键：与其给 Agent 更多上下文（这会让 context 膨胀），不如先让 Agent 知道自己缺什么，再针对性地获取知识；这和 RAG 领域的 query decomposition 思路有异曲同工之处
3. 工具使用能力的分级：ACQUIRE 中 Answerer 需要自主探索，Resolver 只需要生成 patch；这意味着 Agent 的工具能力可以按角色分配，有的负责探索理解，有的负责生成执行
4. 对代码库质量的要求：ACQUIRE 的有效性依赖于仓库可以被"探索"——结构清晰、有工具支持（git history、代码索引等）；混乱的代码库会制约 Answerer 的表现

与同方向工作的关系

工作	核心思想	与 ACQUIRE 的关系
SWE-agent	Agent 自主探索仓库解决 SWE-bench	探索方式不同，ACQUIRE 是目标性 QA 驱动，SWE-agent 更开放
LingmaAgent	基于关键词的结构化总结 pre-repair	ACQUIRE 的"对照组"，关键词驱动效果不如知识缺口驱动
Devin	端到端 AI 软件工程师	Devin 包含了 planning + execution，ACQUIRE 的 decoupling 对 Devin 类系统有参考价值
Self-debug	Agent 自我验证 patch	互补关系：ACQUIRE 改进 patch 生成前的上下文，Self-debug 改进 patch 后的验证

ACQUIRE 的核心贡献在于：重新定义 coding agent 的 pre-repair 阶段——从"关键词搜索上下文"升级为"主动识别知识缺口并系统获取知识"，这更接近人类开发者的工作方式。

适合谁读

• Coding Agent 开发者：正在构建代码修复、代码审查类 Agent 的工程师，ACQUIRE 提供了一个可操作的"先理解再动手"框架
• Software Engineering + LLM 研究者：关注 LLM 在真实代码库场景下为何失败、怎么改进的同行
• RAG / Knowledge Retrieval 研究者：ACQUIRE 本质上是一个面向代码库的 specialized RAG，只是获取方式不是简单的向量检索，而是目标性问答
• SWE-bench 刷榜选手：如果你在做 SWE-bench 实验，ACQUIRE 的 QA-driven 策略可以直接作为改进 baseline 的思路

---

📌 原文未明确的信息：Questioner 和 Answerer 的具体模型选择、QA 知识的具体表示格式（是文本、图还是结构化数据？）、Resolver 的具体实现（是否需要额外微调？）、Questioner 的识别准确性上限。

工程落地与核查（Jay）

1. 事实核查摘要

声明	核查结果	风险等级
「Pass@1 提升最高 +4.4 pp」	abstract 直接声称，但对比 baseline 名称未披露	⚠️ 中（数字来源可信，baseline 不明）
「4× token 成本 / 2× 执行步数」	abstract 可能提及，但实验条件（具体 baseline 方法、仓库规模）未披露	⚠️ 中（量级可信，精确值待考）
「Questioner-Answerer decoupling」	框架性描述，无具体实现数字	✅ 方法可信
「SWE-bench Verified 持续胜出」	abstract 声称但对比方法清单未披露	⚠️ 中
Questioner/Answerer 具体模型选择	原文未披露[校注：无法评估 LLM 能力天花板影响]
QA 知识表示格式（文本/图/结构化）	原文未披露[校注：影响 Resolver 实现路径]
代码与权重	abstract 未声明开源[校注：需联系作者确认是否公开]

2. 工程复现路径与关键坑

Questioner 的实现 - Questioner 本质是一个「知识缺口识别 LLM」，prompts 工程是核心 - 关键设计：如何让 LLM 知道自己「不知道什么」——建议用 self-reflection + curiosity-driven questioning 组合 - Questioner 的识别准确性直接决定 QA 质量上限，建议在复现时量化 Questioner 的「缺口识别准确率」

Answerer 的工具集 - 至少需要：文件读取、grep 搜索、git log 查历史、AST 解析 - Answerer 自主探索的成本需要单独计量，避免「探索成本超过修复失败成本」的反目标结果 - 推荐用 tree-sitter 或 LSP 做 AST-aware 的代码搜索，提高答案准确性

Resolver 的集成 - QA 知识是「文本形式」还是「结构化形式」决定了 Resolver 的输入格式 - 如果是文本，Resolver 直接拼接 issue + QA context；如果是结构化数据，需要额外设计 prompt 模板 - Resolver 是否需要微调原文未明确，若需要微调则复现成本显著上升

评估指标设计 - Pass@1：在 SWE-bench Verified 上严格评估 - 额外成本指标：token 消耗 / API 调用次数 / wall-clock time 需要在实验设计中埋点 - 失败模式分析：区分「知识不足导致的失败」和「推理能力不足导致的失败」，前者才是 ACQUIRE 能改善的

3. 最小可跑路径（伪代码级）

import subprocess
from pathlib import Path

# Step 1: 准备 SWE-bench Verified 数据集
# 见 https://github.com/princeton-nlp/SWE-bench
# 或直接 pip install swebench

# Step 2: Questioner 实现（核心：知识缺口识别）
SYSTEM_PROMPT = """You are a software engineer who has just read an issue description.
Your task is to identify what you DON'T know yet that would be needed to fix this issue.
Ask targeted questions that expose knowledge gaps about:
- Dependency relationships between modules
- Implicit API contracts
- Data flow through the system
- Recent changes that might have caused the issue

Be curious and specific. Do NOT ask questions whose answers you can infer from the issue alone."""

def identify_knowledge_gaps(issue_text: str, codebase_summary: str) -> list[str]:
    prompt = f"Issue:\n{issue_text}\n\nCodebase context:\n{codebase_summary}\n\n{SYSTEM_PROMPT}"
    questions = llm.generate(prompt, n=5)  # 生成 5 个目标性问题
    return questions

# Step 3: Answerer 实现（证据支撑的问答）
def answer_with_evidence(question: str, codebase_root: Path) -> dict:
    """Answer a question by exploring the codebase with tool use."""
    # 工具：grep, git log, AST parsing
    search_results = grep(codebase_root, extract_key_terms(question))
    relevant_files = identify_relevant_files(search_results)

    answers = []
    for file in relevant_files:
        content = read_file(file)
        evidence = extract_evidence(content, question)
        if evidence:
            answers.append({
                "answer": summarize_evidence(evidence, question),
                "file": str(file),
                "line_refs": evidence.line_numbers,
            })
    return answers

# Step 4: Resolver 生成 patch
def generate_informed_patch(issue: str, qa_knowledge: list[dict]) -> str:
    context = format_qa_as_context(qa_knowledge)
    prompt = f"Issue:\n{issue}\n\nRelevant codebase knowledge:\n{context}\n\nGenerate a patch that fixes this issue."
    return llm.generate(prompt)

# Step 5: 端到端评估
for instance in SWE_BENCH_VERIFIED:
    questions = identify_knowledge_gaps(instance.issue_text, instance.code_summary)
    qa_pairs = [answer_with_evidence(q, instance.codebase) for q in questions]
    patch = generate_informed_patch(instance.issue_text, qa_pairs)
    passed = evaluate_patch(patch, instance.test_suite)
    record_metrics(instance.id, questions, qa_pairs, patch, passed)

4. 核心风险与工程建议

• Questioner 幻觉性「伪缺口」：Questioner 可能生成「看似合理但实际不需要答案」的问题，浪费 Answerer 探索成本；建议加一层「答案可行动性评估」
• Answerer 探索深度 vs. 成本平衡：无限制探索成本极高，建议设置 max_iterations 或 timeout（如每次 QA 对 ≤60 秒）
• SWE-bench 仓库偏简单：真实世界代码库结构更混乱，SWE-bench 上的提升不一定能平移到生产环境；建议在 3-5 个真实内部代码库上做 POC
• 代码开源状态：截至 abstract 发布，ACQUIRE 代码未确认开源；建议发邮件联系第一作者获取复现版本
• Resolver 微调成本：若 Resolver 需要在 QA 数据上微调，则整体复现周期显著延长；建议先用 in-context learning 验证框架有效性，再决定是否微调

5. 关联文件

• 关联主线：coding-agents · SWE-bench · repository-understanding · knowledge-retrieval
• 关联关键词：knowledge-gap · question-answering · code-agent · pre-repair-exploration