代理不需要记忆：基于文档的上下文的论点

基于 RAG 的代理记忆的失败

目前大多数 AI 代理的「记忆」插件依赖于一种有缺陷的架构，即基于检索增强生成（RAG）。这种做法通常涉及分析会话记录，生成孤立的「记忆」片段，将它们存储在向量数据库中，并在每个提示中注入最相关的几个片段。

这种架构之所以失败，是因为它将记忆视为相似性搜索的彩票，而不是对项目的结构化理解。其主要技术缺陷包括：

• 缺乏上下文： RAG 片段是孤立的片段；它们丢失了原始对话周围的动机、环境和经验教训。
• 相似性 ≠ 正确性： 基于嵌入的搜索按向量空间中的数学接近度对片段进行排序，而不是根据信息是否最新或准确。
• 过时性： 代码库每天都在演变，但 RAG 记忆通常被视为不可变的真理，导致代理依赖过时的身份验证方法或已弃用的 API。
• 盲点： 代理无法搜索它不知道的内容。如果代理不知道某个特定约束存在，它就不会触发对相关记忆片段的搜索。
• 零可审计性： 向量数据库是黑箱。人类几乎无法审计哪些记忆存在、哪些已过时，或哪些错误片段在悄悄影响代理行为。

从回忆转向文档

与其试图通过回忆来「记住」过去，代理需要一个结构化的操作空间——一个「大脑」——用于记录指令、规范、决策和研究。这将代理循环从 提示 → 构建 → 忘记 的模式转变为更可持续的 提示 → 查阅 → 构建 → 更新 循环。

在基于文档的系统中，代理不依赖后台守护进程来「做梦」或压缩上下文。相反，它在开始任务前阅读相关的 Markdown 文件以获取上下文，并在任务完成后更新这些文件。这确保了「记忆」是一个可读、可更新、可提交到版本控制（Git）并在团队中共享的活文档。

实现：Operator 记忆模型

这一理念的一个实用实现是 Operator Memory，它用基于 Markdown 的大脑取代向量数据库。该系统基于一个简单前提：将重要知识以纯文本形式持久化。在工作前，代理查阅大脑中的相关文档；工作完成后，它会重新审视过时的文档，并在必要时添加新的文档。

社区观点与替代方法

开发人员之间的讨论揭示了管理代理上下文的多种策略，从极端极简主义到复杂的结构化系统不等。

「代码即文档」学派

一些开发人员认为，外部文档是一种「鲁布·戈德堡机器」，最终不可避免地过时。他们认为代码本身才是唯一的真实来源：

"代码就是文档……文档始终是代码的代理，以便那些没有上下文的人可以开始工作。显然，如果阅读代码和阅读文档的成本相同，文档就完全无用。"

结构化工作区策略

其他人发现，使用特定的文件夹结构和专用文件可以有效引导代理：

• 工作台模式： 使用 .workbench 或 internal/ 文件夹（通常被 git 忽略），代理在其中记录临时笔记和项目地图。
• 交接模式： 创建 STATUS.md 或 handoff.md 文件，要求代理在会话开始时阅读并在结束前更新，以确保不同代理会话或不同模型之间的无缝过渡。
• ADRs（架构决策记录）： 使用正式记录决策原因的文件，为代理提供项目的发展轨迹，而不仅仅是最终状态。
• 原则驱动开发： 编写高层次原则（例如，"使用 jq 而不是 Python 进行 JSON 解析"），要求代理遵守，而不是依赖对过去事件的具体记忆。

对基于文档记忆的技术批评

对以文档为先的方法的批评者指出，这可能只是将问题从一种媒介转移到另一种媒介：

• 发现难题： 与 RAG 一样，如果代理不知道信息存在，它可能不知道该打开哪个 Markdown 文件。
• 维护开销： 文档需要主动维护。如果代理没有被严格提示将文档与代码保持一致，文档就会成为混淆的来源。
• 令牌成本： 随着「大脑」的增长，阅读和更新多个大型文档的成本可能激增，甚至超过少数 RAG 片段的成本。

总结表：基于 RAG 的记忆 vs. 基于文档的记忆

特性	基于 RAG 的记忆	基于文档的记忆
存储	向量数据库（嵌入）	纯文本（Markdown）
检索	相似性搜索	显式查阅/索引
可审计性	低（黑箱）	高（人类可读/Git）
真实来源	历史会话记录	当前规范/文档
更新机制	仅追加 / 后台守护进程	主动编辑/更新
上下文	孤立片段	结构化文档