CodeAnchor：代码智能体到底需要多少静态结构？
我们研究轻量静态结构如何作为 deterministic anchors，帮助代码智能体更稳定、更可复现地定位代码。论文被 ISSTA 2026 正式接收。
CodeAnchor：代码智能体到底需要多少静态结构？
📄 发表于 ISSTA 2026 | PDF
作者：Zhihao Lin, Mingyi Zhou, Yizhuo Yang, Li Li
Li Li 为通讯作者
一句话概括
代码智能体通常靠 grep / rg 在仓库里找线索，但真实软件依赖调用关系、继承层次和配置依赖等结构。CodeAnchor 研究了轻量静态结构能否作为 deterministic anchors，让 agent 的导航更稳定、更可复现。
问题背景
今天很多 coding agent 的仓库导航方式很朴素：先搜索关键词，再读命中的代码片段，然后继续搜索。这个 grep-first workflow 很快、很通用，也不依赖复杂索引。
问题是，关键词搜索看不到代码真正的结构关系：
- 谁调用了谁；
- 哪些类继承自同一个父类；
- 配置值如何影响执行路径；
- 一个 bug 相关位置和另一个位置之间是否有结构连接。
于是 agent 每次都要靠概率性探索重新发现这些关系，结果就是轨迹不稳定、重复性差，同一个任务多跑几次可能走出完全不同的路径。
CodeAnchor 的想法
我们不试图把 agent 变成一个完整静态分析器，而是给它一些轻量、稳定、可读的结构锚点：把调用、继承、配置等结构事实以 plain-text 注释或标签形式注入到代码上下文里。
这些结构信息不是为了替代 LLM 推理，而是帮助它少走弯路：让它知道“这里和哪些位置结构相关”，从而把随机搜索约束在更合理的范围内。
关键发现
1. Anchoring 确实有效。
轻量调用/继承拓扑可以提升函数级定位效果，并缩短 agent 交互轨迹。
2. 结构信息不是越多越好。
最优粒度和方向性取决于仓库特征。语义过密时会出现收益递减；在 hub-heavy 的项目里，只暴露 inverse links（who-calls-me）有时比同时给 forward edges 更稳。
3. Anchoring 最大的价值是稳定。
静态结构让 agent 更愿意沿着结构链接移动，降低 run-to-run variance，并提升单次运行可靠性。换句话说，它的作用不是简单“让 agent 更聪明”，而是让 agent 的探索更 disciplined、更可复现。
我自己的理解
这篇工作回应了一个 coding agent 里很现实的问题：我们到底要不要给 agent 上复杂图索引？
CodeAnchor 的答案比较克制：不一定需要重型系统，但可以给它足够轻的结构锚点。好的结构信息不一定要覆盖全部程序语义，它只需要在关键时刻把 agent 从纯关键词搜索里拉出来。
正式接收 ISSTA 2026。两篇一起接收，快乐有点超标。