ACQUIRE — QA-Driven Repository Knowledge Acquisition
ACQUIRE — QA-Driven Repository Knowledge Acquisition
ACQUIRE 的核心判断是：coding agent 的许多失败不是“不会写 patch”，而是没有先把仓库内部知识缺口显式化。传统 pre-repair exploration 往往从 issue 关键词出发找 suspicious files 或 code snippets，但这类上下文并不一定回答“为什么这里相关、接口契约是什么、跨模块依赖是什么”。ACQUIRE 因此把修复拆成两个阶段：先用 Questioner/Answerer 形成仓库证据型 QA，再让 Resolver 基于 QA 生成补丁。
为什么对用户重要
这篇论文直接对应 Hermes / llm-wiki 的一个长期痛点：任务开始时如果只靠问题描述和关键词搜索，agent 很容易找到“看似相关”的上下文，却没有回答真正的知识缺口。对代码修复如此，对 wiki ingest、技术雷达和长程自动化也一样：没有先问出缺口，就会把时间花在错误文件、浅层摘要或重复页面上。
它的耐久价值不在于又一个 SWE-bench 提分，而在于提供了一个可迁移 workflow：先生成可回答的问题，再读取证据并形成结构化 QA，最后才行动。这可以被改造成 Hermes 的任务前置清单、wiki ingest 的深度判断表、以及 coding-agent 的仓库探索模板。
机制 / 一阶原理
ACQUIRE 的一阶原理是把“隐式上下文不足”转为“显式知识缺口”。Questioner 根据 issue 生成互补问题，Answerer 以只读方式探索仓库并给出 evidence-grounded answer，Resolver 再用这些 QA 作为修复上下文。论文把问题类别分成四类：
| 类别 | 问什么 | 避免的失败 |
| Mechanism and Behavior | 功能如何运行、状态如何变化、数据如何流动 | 只改表面症状、不理解根因 |
| Design and Usage | API / 类 / 错误处理 / 设计约定是什么 | 违反隐性接口契约 |
| Locating and Structure | 相关代码在哪里、模块如何依赖 | 搜索空间过大或定位错误 |
| Ecosystem and Standards | 外部库、协议、语言语义要求是什么 | 忽略仓库外部约束 |
这个设计把 context engineering 从“多读一些文件”推进到“按知识缺口组织证据”。它也让轨迹更可审计：失败时可以检查是问题没问对、Answerer 证据不足，还是 Resolver 没使用 QA。
实验信号与置信度
论文在 SWE-bench Verified 上报告：ACQUIRE 在 GPT-5-mini 上 Pass@1 62.2%，相对 Mini-SWE-Agent 58.4% 提升 3.8 个百分点；在 DeepSeek-V3.2 上 Pass@1 70.8%，相对 66.4% 提升 4.4 个百分点。相比 LingmaAgent / SWE-Debate，ACQUIRE 的额外成本和时间更温和。本文标记 confidence: medium，因为今天已读取 arXiv PDF 文本并摘取方法/结果，但尚未运行其开源代码，也未独立复现实验。
和既有 wiki 概念的关系
- 对 Context-Engineering：ACQUIRE 说明上下文质量不只是检索召回率，而是问题驱动的 evidence contract。一个好的 context provider 应能回答“这份上下文填补了哪个知识缺口”。
- 对 Agentic-Coding：它把仓库探索从 patch loop 中前置出来，降低 agent 在修复时边猜边找的风险。
- 对 Agent-Benchmarks：它提示 benchmark 不应只看最终 pass rate，还应评估 question quality、answer grounding、QA usage rate 和知识缺口覆盖。
- 对 Harness-Engineering：Questioner / Answerer / Resolver 是一个可实现的 harness 结构，适合放进复杂任务的前置理解阶段。
对 Hermes / llm-wiki 的可执行启发
- 对复杂代码任务，先生成 4 类问题清单，再读文件；不要直接从 issue 关键词开始 patch。
- 对 wiki deep ingest，深度判断也可用类似四类问题：机制是什么、和已有概念契约是什么、应放在哪里、是否依赖外部标准/项目。
- 每次报告可以把“已回答的知识缺口”和“未回答但影响行动的问题”分开，降低 unsupported completion claim。
- 对 llm-wiki 技术雷达，可把 ACQUIRE 作为候选内容晋升模板：只有能回答核心机制、关系、实践启发和边界条件的材料才晋升正式 source/concept 页。
边界与失败模式
ACQUIRE 的问题模板可能过于固定：不同语言、框架、产品域需要不同知识维度。预先生成 QA 也可能带来 stale context：修复过程中出现新假设时，旧 QA 不一定够用。论文也承认未来可动态请求/刷新知识，但成本会上升。对 Hermes 来说，安全默认应是：先用固定四类问题做低成本前置理解；当执行中出现新证据或矛盾时，再触发动态补问，而不是无限探索。
写入记录
- 2026-07-15 09:02 CST：新增 ACQUIRE 论文的深度入库页，提炼 QA 驱动仓库知识获取机制、实验信号、与 Context/Harness/Agentic Coding 的关系和 Hermes 实践启发。