AI-Wiki

定义与身份

Anthropic在本文中是与 OpenAI 并列的另一组主流证据来源，用来反驳一种常见误解：只要做 Agent记忆系统设计，就应该默认把历史信息全部 embedding 进向量数据库。

原文的论证重点不是介绍 Anthropic 公司的产品谱系，而是借其官方工程实践说明：主流 Agent 系统的“记忆”并不等于“统一的向量检索库”，而更接近一套分层、按需、工具化的上下文组织机制。

在原文中的角色职责

在这篇关于向量数据库在Agent记忆中的适用边界的论证里，Anthropic承担了三个角色：

作为官方工程观点来源，提供“记忆不必先向量化一切”的方法论证据。
作为产品实践样本，用 Claude Code 证明跨会话记忆可以建立在文件系统与 Markdown 之上。
作为效果案例来源，用 Memory for Managed Agents 的客户结果说明：不用向量数据库，也可能同时改善准确性、成本与延迟。

官方博客观点：按需取用上下文，而不是预处理全部数据

原文明确引用了 Anthropic 官方工程博客 Effective Context Engineering for AI Agents，并指出其核心观点是 just-in-time 检索。

这里的关键不是先把所有潜在相关资料统一做 embedding、建索引、再做相似度召回，而是：

Agent 不预处理所有相关数据。
Agent 先维护一组轻量级标识符。
真正需要时，再通过工具把相关内容动态加载进当前上下文。

原文列出的轻量级标识符示例包括：

文件路径
存储的查询
网页链接

这套思路的重点是“先组织引用点，再运行时展开内容”，而不是“先把所有原始内容都塞进统一语义库”。这也是即时检索记忆策略在本文中的代表性来源之一。

just-in-time 检索的三个要点

根据原文对 Anthropic 博客的转述，just-in-time 检索至少包含三个不可省略的要点：

1. 轻量标识符

Agent 长期保留的不是完整语料本体，而是能够重新定位信息的轻量引用。这样做的直接好处是：

长期状态更轻；
不需要把所有内容提前灌进上下文；
也不需要为所有材料预先建立统一向量化存储。

2. 外部组织结构

Anthropic 将这种方式类比为人类认知：人不会把整个语料库完整背在脑中，而是依赖外部组织和索引系统来重新找到信息。原文列出的类比包括：

文件系统
收件箱
书签

这说明记忆的关键不只是“存了什么”，而是“是否有稳定的外部组织结构让 Agent 能再次找到它”。从这个角度看，文件树、目录层级、链接集合、本地查询入口，本身都可以是记忆系统的一部分。

3. 动态加载

真正用到信息时，Agent 再借助工具在运行时把内容拉入上下文，而不是把所有可能相关内容长期常驻。

这种设计的边界也很明确：它更适合那些可以通过引用重新获得、并且在当前任务时刻才需要展开的上下文；它不是在说所有历史经验、所有非结构化案例都永远不需要检索系统。原文整体结论仍然是：不同类型的记忆要采用不同策略，只有历史经验和案例这类开放增长、模糊语义查询的内容，才更适合向量检索。

Claude Code：以文件系统和 Markdown 作为跨会话记忆载体

原文给出的更直接证据是 Claude Code。在该语境下，Claude Code 的跨会话记忆方案并不是向量数据库，而是：

把文件系统当作记忆载体；
用 Markdown 文件持久化上下文；
结合一组专门的子 Agent 来维护这些记忆。

原文还强调，这是一套“三层架构”，且“没有向量数据库，没有 RAG”。虽然该段没有继续拆开三层分别是什么，但其论证重点已经非常明确：Anthropic 选择的是可读、可编辑、可被工具直接操作的文件化记忆，而不是默认把记忆抽象成 embedding 检索问题。

这种做法的工程含义包括：

记忆内容对人和 Agent 都可直接查看；
可以利用现成文件系统组织结构管理上下文；
Agent 可通过熟悉的工具链直接读写，而不必额外依赖专门的向量检索基础设施。

Memory for Managed Agents：通过挂载文件提供长期记忆

原文还提到，Anthropic 在 2026 年 4 月发布了 Memory for Managed Agents 功能，用来让 Agent 进行跨会话学习。

该功能在本文中的关键点不是产品命名本身，而是它的长期记忆实现方式：

Memory 直接挂载到文件系统上；
Claude 利用自己已经擅长的 bash 与代码执行能力来操作这些记忆文件。

这意味着 Anthropic 的长期记忆方案并不是把“记忆系统”独立成一个必须通过语义相似度访问的黑盒数据库，而是把它做成 Agent 已有工具能力能够直接处理的外部文件资源。

从本文论证角度看，这一点非常重要，因为它进一步支持了一个判断：主流 Agent 记忆设计可以优先依赖文件、结构、工具和运行时加载，而不是默认依赖向量数据库。

原文保留的客户结果

原文保留了 Anthropic 官方公布的 Rakuten 客户结果，指标包括：

错误率降低 97%
成本降低 27%
延迟降低 34%

这些数据在文中的作用，是证明“非向量数据库式记忆”并不只是理念层面的工程偏好，而是在真实 Agent 工作负载中能够带来可量化改进。

细节与边界

不是说 Anthropic 反对一切检索

原文并没有把 Anthropic 的观点解释成“永远不要检索”或“所有场景都不该用向量数据库”。更准确的理解是：Anthropic 反对把所有记忆问题先验地统一成向量化问题。

不是说所有记忆都应写成 Markdown

Claude Code 与 Memory for Managed Agents 说明的是 Anthropic 在其代表性 Agent 产品中的实现偏好：文件系统、Markdown、挂载文件、工具访问。它证明这条路线可行，但不等于所有 Agent 都必须照搬同一介质。本文要保留的重点，是“文件化、结构化、按需加载”的原则。

与向量数据库的关系是“有边界地使用”

结合原文全文，Anthropic 被拿来支持的不是“向量数据库无用论”，而是以下边界判断：

对稳定事实、可覆盖更新的信息，不应优先用模糊语义匹配。
对可以依赖外部组织结构重新定位的信息，可以采用 just-in-time 运行时加载。
对开放增长、非结构化、需要相似案例召回的历史经验，向量检索仍然有其位置。

与本文主题的关系

在这篇文章中，Anthropic的重要性不在于公司背景，而在于它提供了与 OpenAI 相互印证的主流实践：

Agent 记忆不是单一模块，而是分层系统；
长期记忆不必默认做全量 embedding；
可通过文件系统、结构化组织和工具调用来实现跨会话记忆；
只有特定类型的记忆才真正适合交给 向量数据库在Agent记忆中的适用边界|向量数据库。

Anthropic