为什么编码代理程序会反复重新打开它们应该已经理解的文件？
摘要
作者观察到，编码代理程序通常无法对大型代码库保持持久的理解，导致冗余读取和模式不匹配。他们介绍 RepoWise，这是一个实验性工具，利用仓库信号（如依赖关系和提交历史记录）来解决这个问题。
我一直在较大的仓库上测试编码代理程序，发现了一些奇怪的现象。即使它们已经探索过代码库，它们仍然会反复执行以下操作：重复读取相同的区域、打开无关的文件、忽略组件之间的关系、做出技术上可行但不符合作业模式的修改。奇怪的是，这并不总是上下文大小的问题。更像是它们对仓库本身缺乏持续的理解。我尝试在 RepoWise 中实现这个想法，主要研究仓库信号，如依赖关系、提交历史记录和经常一起修改的文件等。好奇那些正在构建代理程序的人是否也看到过同样的问题，或者是否已经有更好的处理方法。GitHub 链接在评论中。
相似文章
感觉编码代理擅长找代码，但不擅长理解项目
讨论了一个观察：编码代理虽能有效定位代码，但难以深入理解项目，比如组件关系和项目风格。作者介绍了 RepoWise，一个提供仓库级信号（如依赖图和Git历史）的工具来解决这些问题。
也许编程代理不需要更大的记忆。也许它们需要连续性
文章认为，编程代理需要连续性——即在仓库中保存执行历史和项目状态——而不是简单地拥有更大的记忆或上下文窗口，以避免在会话之间丢失操作线程。
在实际仓库中运行编码代理：代理写完代码后哪些环节会出问题？
本文讨论了工程团队在采用AI编码代理时面临的实际挑战，如任务安全性、上下文检索、输出审查和协调，并提出了一个用于评估的准备度模型。
更大的上下文窗口似乎在解决与理解不同的问题
Repowise 是一个开源工具，它将代码库索引为五个智能层——依赖图、Git 历史、自动生成的文档、架构决策和代码健康——并通过 MCP 工具将这些信息暴露给 AI 编码代理，以提供更准确的上下文并减少工具调用次数。
编码代理在启动项目时是否比修复实际代码库要好得多？
观察发现，编码代理在新项目上表现出色，但在现有代码库中常常遇到困难，因为需要最小化更改并理解隐藏的依赖关系，这限制了它们的有效性。