感觉编码代理擅长找代码，但不擅长理解项目
摘要
讨论了一个观察：编码代理虽能有效定位代码，但难以深入理解项目，比如组件关系和项目风格。作者介绍了 RepoWise，一个提供仓库级信号（如依赖图和Git历史）的工具来解决这些问题。
最近一直在摆弄编码代理，但总有些东西让我困扰。找代码似乎不再是难事了，理解项目反而更难。我经常看到这样的情况：
• 重新打开他们已经探索过的文件
• 忽略组件之间的关系
• 做出能工作但不符项目风格的修改
• 反复重新发现模式
我原本以为更大的上下文窗口能解决这个问题，但现在不太确定了。我开始用 RepoWise 进行实验，主要围绕仓库级信号，如依赖图、Git历史和架构上下文。GitHub 仓库在评论中。好奇其他构建代理的人是否看到同样的问题，还是我找错了方向。
相似文章
为什么编码代理程序会反复重新打开它们应该已经理解的文件？
作者观察到，编码代理程序通常无法对大型代码库保持持久的理解，导致冗余读取和模式不匹配。他们介绍 RepoWise，这是一个实验性工具，利用仓库信号（如依赖关系和提交历史记录）来解决这个问题。
编码代理在启动项目时是否比修复实际代码库要好得多？
观察发现，编码代理在新项目上表现出色，但在现有代码库中常常遇到困难，因为需要最小化更改并理解隐藏的依赖关系，这限制了它们的有效性。
在实际仓库中运行编码代理：代理写完代码后哪些环节会出问题？
本文讨论了工程团队在采用AI编码代理时面临的实际挑战，如任务安全性、上下文检索、输出审查和协调，并提出了一个用于评估的准备度模型。
@NainsiDwiv50980: AI 智能体变得更聪明了，但理解代码库的方式却没变。大多数仍然逐个文件地爬取仓库……
SocratiCode 是一个完全开源的代码库智能引擎，它利用语义搜索、依赖关系图、影响分析和共享索引帮助 AI 导航仓库，无需供应商锁定。
SWE-Explore：编码代理仓库探索能力基准测试
SWE-Explore 引入了一个基准测试，用于评估编码代理的仓库探索能力，要求在行预算内返回相关代码区域的排序列表。实验表明，基于代理的探索优于传统检索，而行级覆盖仍然是关键区分因素。