Repository Exploration
Repository Exploration
Repository Exploration 是 coding agent 在修改代码前理解仓库、定位相关文件和关键代码行的能力。
为什么重要
在真实仓库里，修复问题的难点往往不是“会不会写一段代码”，而是：issue 对应哪些模块、哪些文件相关、哪些函数或代码行是核心证据、哪些测试能验证行为、哪些上下文只是噪音。
SWE-Explore 把这个能力单独定义成 benchmark，说明它已经成为 coding agent 的核心瓶颈。
衡量指标
- 覆盖率：是否包含关键代码区域。
- 排名：关键区域是否靠前。
- 上下文效率：在有限行数预算内提供多少有用证据。
- downstream repair correlation：探索分数是否能预测后续修复成功率。
2026-07-03 补充：确定性架构图作为探索前置层
| [[enola-deterministic-codebase-architecture-graph | Enola]] 把 repository exploration 中“仓库结构是什么”这部分从 LLM 猜测变成确定性图查询。它不是替代阅读源码，而是让 agent 先知道 modules、symbols、routes、storage、dependencies 和 typed relations，再决定读哪些文件。 |
这补充了 SWE-Explore 的评测视角：好的探索不只是找到关键行，还应该解释关键行在结构图中的位置、依赖路径和影响半径。对真实 refactor，先做 impact analysis / path finding，再 patch，比直接 grep 更接近工程化 workflow。
2026-07-04 补充：graph traversal 让探索从“找文本”变成“走关系”
| [[agent-context-workshop | Agent Context Workshop]] 对本概念的关键补充是：repository exploration 不应只等同于 grep/search。更强的上下文层会把 symbols、types、implementors、dependency edges、blast radius 等关系变成 agent 可调用工具，让 agent 先走结构关系，再决定读哪些源码片段。 |
它的实验也显示，graph 未必大幅提高单次准确率，但能提高重复运行稳定性、关系问题表现和 token efficiency。这说明 repository exploration 的评测也要从“是否找到关键行”扩展到“是否稳定复现同一条结构证据链”。
2026-07-07 补充：从重新探索到查询持久工程记忆
| [[greplica-persistent-coding-agent-memory | Greplica]] 补充了 repository exploration 的另一条路线：不是每次都从 grep/glob/read 重新构建仓库理解，而是把 prior sessions 中的架构决策、失败尝试、gotchas 和 edge cases 变成可查询记忆。它的 planning benchmark 显示，针对高上下文任务，持久记忆可以减少探索工具调用和 token 消耗。 |
对 coding agent 来说，理想探索流程应是：先读取 repo-level instructions 与结构图，再查询持久记忆，最后只对仍不确定的路径做源码阅读。这样探索不再只是“找文本”，而是“复用历史证据 + 补齐当前差异”。
写入记录
- 2026-07-03 09:00 CST：补充 Enola 对确定性仓库结构图和 repository exploration 的启发。
- 2026-07-04 09:00 CST：补充 Agent Context Workshop 对 graph traversal、blast radius、关系证据链和探索稳定性的启发。
- 2026-07-07 09:00 CST：补充 Greplica 对持久工程记忆、减少重复探索和 planning-phase benchmark 的启发。