不受欢迎的观点：AI 代理并不总是需要向量数据库来存储项目记忆

许多 AI 编码教程似乎遵循相同的模式：希望你的 AI 代理记住项目上下文、编码指南或架构决策？→ 将文档分块 → 生成嵌入 → 存储到向量数据库 → 构建 RAG 管道。对于大型代码库和大量知识集合，这完全合理。但对于许多中小型编码项目，我开始怀疑我们是否添加了过多的基础设施来解决一个相对简单的问题。 我看到的向量数据库用于项目记忆的问题 1. 更难检查 如果代理记住了一个错误的架构决策，这个记忆究竟来自哪里？使用嵌入和检索管道，调试记忆本身可能成为另一个问题。 2. 它增加了一层开发者必须管理的内容 开发者已经有 Git 和文本编辑器。那么，为什么不将 AI 记忆变成开发者可以实际打开、阅读、编辑、比较、审查和提交的东西呢？ 3. 并非每个项目都需要语义检索 如果代理正在处理一个 20-50 个文件的项目，我们真的需要将每段上下文转换为嵌入，然后模型才能使用吗？有时，简单地将相关的项目上下文提供给模型就足够了。 一种不同的方法：将 AI 记忆视为源代码 我一直在试验一种更简单的方法来处理 AI 编码代理：Markdown + Git。这个想法很简单： 平面文件存储：项目记忆以 Markdown 形式存储在 .ai-memory/ 目录中。 人类可读：如果 AI 做出了错误的假设，我可以在 VS Code 中打开文件并直接修复。 Git 可审计：每次记忆更改都成为 Git 历史的一部分。git diff 可以精确显示代理学习或更改的内容。 无额外基础设施：基本情况下不需要数据库、嵌入管道或单独的记忆服务。 我正在探索的原则是： 这并不意味着向量数据库不好或不必要。当信息量或检索需求合理时，它们显然有其用武之地。我更感兴趣的是两种方法之间的界限。在什么情况下，简单的 Git + Markdown 记忆对 AI 代理来说不再足够，而向量数据库/RAG 系统实际上变得必要？