智能体记忆解决方案

概述

本页汇总所有记忆解决方案——开源库、托管云服务与专业平台——并将其映射至参考 Thoughtworks Radar 方法论改编的技术雷达。每个解决方案从五个维度进行评估：研究背书、行业采用度、GitHub 社区信号、生产就绪度以及开源可用性。

雷达的四个环级：

技术雷达

为避免标签拥挤，解决方案分两张图呈现。两图共享同一 x 轴（环级位置：谨慎 → 采纳），y 轴各有不同，详见各图标注。

阅读方法： - 右侧（x > 0.5）= 试用或采纳——生产就绪，推荐评估 - 左侧（x < 0.5）= 评估或谨慎——早期阶段或适用范围较窄 - 象限标签表示环级位置与该图 y 轴维度的组合

图一——开源及源码可见解决方案

Y 轴：单一存储层（下）→ 全栈记忆抽象（上）

图二——托管及专有解决方案

Y 轴：初创 / 细分市场（下）→ 企业级超大规模云厂商（上）

🟢 采纳

以下解决方案已证明具备生产就绪性，社区采用度高，且明确适合智能体记忆场景。

Mem0

类型：开源记忆层（Apache 2.0）+ 托管云 API
支持的记忆类型：语义记忆、情景记忆
GitHub：mem0ai/mem0 — 约 54K stars，1400 万次下载
融资：2400 万美元 A 轮（2025 年）

目前采用率最高的专用智能体记忆库。Mem0 自动从对话中提取用户偏好与事实，存储至向量 + 图谱混合存储，并在后续交互中检索相关记忆。API 调用量从 2025 年 Q1 的 3500 万次增长至 Q3 的 1.86 亿次，表明其在生产环境的渗透率持续走强。

推荐采纳的理由：在专用记忆领域社区规模最大，框架无关（兼容 LangChain、LangGraph、CrewAI 及自定义智能体），支持通过矛盾消解实现自改进记忆，文档完善，持续维护。

最适用场景：个性化用例——用户偏好追踪、跨会话连续性、面向用户的智能体。

局限：以语义记忆 / 情景记忆为主，程序记忆需独立处理。托管 API 引入厂商依赖。

Graphiti（by Zep）

类型：开源时序知识图谱框架（Apache 2.0）
支持的记忆类型：语义记忆（关系型）、情景记忆（时序型）
GitHub：getzep/graphiti — 约 25K stars

Graphiti 是 Zep 记忆平台背后的开源引擎。它从智能体交互中实时构建双时序知识图谱——不仅记录什么是真实的，还追踪何时成立以及何时发生变化。这使其在需要推理随时间演变的事实的智能体场景中具有独特优势。

推荐采纳的理由：关系型与时序推理能力最强。双时序数据模型（有效时间 + 事务时间）是真正的差异化特性。社区规模大且活跃，框架无关。

最适用场景：需要追踪事实演变的智能体——CRM 智能体、研究智能体、长时间运行的自主智能体。

局限：运维复杂度高于纯向量方案，需要图数据库（Neo4j 或兼容产品）。Zep 托管平台（封装了 Graphiti）的社区版支持政策有所调整。

AWS AgentCore Memory

类型：全托管云服务（AWS）
支持的记忆类型：工作记忆（会话）、语义记忆、情景记忆
文档：AWS AgentCore Memory

AWS AgentCore Memory 于 2025 年 AWS Summit NYC 发布，是一项全托管服务，彻底消除了 AWS 上构建智能体时的记忆基础设施管理负担。同时支持短期会话记忆与长期记忆，保留期可配置（1–365 天），并与 Bedrock Agents、Strands 及更广泛的 AWS 生态原生集成。

推荐采纳的理由：AWS 原生团队零运维。企业级 SLA、IAM 集成、合规覆盖，无需管理任何基础设施。

最适用场景：已深耕 AWS 的企业团队，希望获得托管记忆能力而无需自建、自运维向量 / 图谱基础设施。

局限：AWS 锁定，无法迁移至其他云或自托管环境。大规模使用时需评估定价。

🔵 试用

以下解决方案值得在可承受一定风险的项目中使用。增长势头良好，已有真实的生产使用案例，但尚未成为默认之选。

Cognee（topoteretes）

类型：开源知识图谱记忆引擎（Apache 2.0）+ 托管云
支持的记忆类型：工作记忆（会话记忆）、语义记忆（知识图谱 + 向量嵌入）、情景记忆（交互轨迹）、程序记忆（派生关系与本体）
GitHub：topoteretes/cognee — 约 12K stars
文档：cognee.ai · docs.cognee.ai
融资：750 万美元种子轮（2025 年）

Cognee 将智能体记忆构建为知识图谱，而非扁平向量库。其 ECL 流水线（提取 Extract → 认知化 Cognify → 加载 Load）可从 38 个以上数据源摄取数据，自动提取实体与关系、生成本体，并将结果以图谱形式存储，同时附带协同嵌入的向量表示。这使智能体能够进行多跳推理——回答"这些事实之间有什么关联？"——而非仅回答"什么内容最相似？"——这是扁平 RAG 无法实现的。记忆分为两层：会话记忆（当前交互的短期工作上下文）和永久记忆（跨会话持久存在并持续优化的耐久知识图谱）。

已通过 GitHub Secure Open Source Program 认证。流水线运行量从约 2000 次增长至超过 100 万次（2025 年内增长 500 倍），服务于 70 个以上生产公司，包括拜耳（科学研究工作流）。已被收录于 Microsoft AI Agents for Beginners 课程。

推荐试用的理由：12K stars、750 万美元种子融资、70 个以上生产公司、单年 500 倍流水线增长，使 Cognee 跻身试用环前列，逐步逼近采纳环。知识图谱 + 向量混合方案提供比纯向量方案更丰富的关系推理能力。38 个以上数据源连接器与自动本体生成显著降低了集成工作量。Apache 2.0 授权搭配托管云选项，部署灵活性充分。

最适用场景：需要关系型 / 多跳记忆的智能体——研究智能体、文档理解工作流、知识密集型企业智能体。尤其适用于记忆需要表达事实之间如何关联，而不仅仅是检索相似文本的场景。

局限：知识图谱构建比扁平向量嵌入计算成本更高。ECL 流水线在摄取时引入额外延迟。对于简单的单会话对话记忆，Mem0 或 Honcho 是更轻量的替代方案。

Letta（前身为 MemGPT）

类型：开源有状态智能体运行时（Apache 2.0）
支持的记忆类型：工作记忆（虚拟上下文）、语义记忆、情景记忆
GitHub：letta-ai/letta — 约 21K stars

Letta 不仅是一个记忆库——它是一个围绕操作系统启发的记忆管理机制构建的完整智能体运行时。运行在 Letta 上的智能体像操作系统管理 RAM 那样管理自身的上下文窗口，通过显式记忆函数（core_memory_append、archival_memory_search）在活跃上下文与归档存储之间移动数据。由 UC Berkeley 的 MemGPT 研究团队创立。

推荐试用的理由：理论基础最为扎实（MemGPT 论文，UC Berkeley）。操作系统启发的模型是工作记忆管理最具原则性的方案。开发活跃，生态持续扩展。

最适用场景：需要智能体自主管理记忆内容的自主长时运行智能体，以及研究与实验性部署。

局限：比插件式记忆库复杂度更高。需要采用 Letta 运行时，而非仅在现有智能体上附加记忆。框架无关性不如 Mem0。

Vertex AI Memory Bank（Google Cloud）

类型：全托管云服务（Google Cloud）
支持的记忆类型：语义记忆（用户偏好、长期事实）
文档：Vertex AI Agent Engine Memory Bank

Google 为构建于 Vertex AI Agent Engine 上的智能体提供的托管记忆服务。可从用户对话中动态生成长期记忆，按用户范围隔离并跨会话访问。专为在 Google Cloud 生态内实现规模化个性化而设计。

推荐试用的理由：与 ADK、Gemini 及 Vertex AI Agent Engine 原生集成，提供 Google Cloud SLA 的托管服务，适合已部署于 GCP 的团队。

最适用场景：在 Vertex AI / ADK 上构建个性化智能体的 GCP 原生团队。

局限：GCP 锁定，灵活性不及开源替代方案。Memory Bank 聚焦于语义 / 个性化记忆，并非通用记忆解决方案。

Oracle AI Agent Memory（统一智能体记忆核心）

类型：基于 Oracle AI Database 的托管记忆层（专有）
支持的记忆类型：工作记忆（短期线程）、语义记忆、情景记忆
文档：oracle.com/database/ai-agent-memory
SDK：PyPI 上的 oracleagentmemory

Oracle 的企业级记忆解决方案，于 2026 年 4 月发布。统一智能体记忆核心构建于 Oracle AI Database 之上，为所有四类记忆需求提供统一的受治理底层：带摘要与上下文卡片的短期对话线程、支持向量搜索的长期持久记忆、基于 LLM 的自动记忆提取，以及面向多租户生产部署的用户 / 智能体隔离。

核心差异化在于 Oracle AI Database 的融合引擎——混合检索将 Oracle Text（词汇检索）、向量相似度、元数据过滤器与 GRAPH_TABLE（关系感知图查询）合并至单一查询中，从而无需拼接独立的向量库、图数据库与关系型数据库。

推荐试用的理由：企业级治理故事强劲——ACID 事务、行级安全与合规控制，这是专用记忆初创公司难以比拟的。框架无关的 Python SDK，对已运行 Oracle 基础设施的团队具有可信度。然而该产品非常新（2026 年 4 月），目前尚无独立社区信号。

最适用场景：拥有现有 Oracle Database 投资且需要符合合规要求（金融服务、医疗、受监管行业）的受治理、多租户智能体记忆的企业团队。

局限：需要 Oracle AI Database，无法迁移至其他基础设施。无开源选项，无独立 GitHub 社区信号。非常早期——截至 2026 年 5 月可参考的生产案例研究有限。

Azure AI Foundry Memory

类型：全托管云服务（Microsoft Azure）
支持的记忆类型：工作记忆（会话状态）、语义记忆
文档：Azure AI Foundry

Microsoft 在 Azure AI Foundry 中提供的托管状态与记忆层。为构建于 Azure OpenAI 和 Semantic Kernel 框架上的智能体提供企业级会话状态管理与跨会话记忆。

推荐试用的理由：与 Azure OpenAI、Semantic Kernel 及 Azure 企业合规控制原生集成，适合 Microsoft 技术栈的企业客户。

最适用场景：拥有现有 Microsoft AI 投资的 Azure 企业团队。

局限：Azure 锁定，与 Microsoft AI 技术栈紧耦合，社区可见度不及开源替代方案。

Anthropic Claude Managed Agents — Memory

类型：Claude Managed Agents 内的全托管记忆功能（Anthropic）
支持的记忆类型：工作记忆（挂载的 memory-store 文件系统）、语义记忆、情景记忆、程序性记忆（经 Dreaming 精炼）
文档：Using agent memory — Claude API Docs

Anthropic 为构建在 Claude Managed Agents 上的智能体提供的第一方记忆层，自 2026 年 4 月 23 日起公开测试。记忆存储（memory store） 是一个工作区范围的文本文档集合，以目录（/mnt/memory/）形式挂载到智能体容器内，用普通文件工具而非独立记忆 API 进行读写。每次改动都会生成不可变、可审计的版本（保留 30 天）。配套的 Dreaming 功能（研究预览）在会话之间运行，对记忆去重、消解冲突并加以整合——这是 Anthropic 对反思/整合（Reflection/Consolidation）长期记忆策略的生产级实现。试点客户 Harvey 报告称，在法律起草工作流中结合使用 Memory + Dreaming + Outcomes 闭环后，任务完成率提升约 6 倍。完整架构、API 与最佳实践记录在专门的 Claude Managed Agents 页面。

推荐试用的理由：背靠 Anthropic 自有基础设施与模型路线图，采用文件系统原生设计，避免自创一套专用的记忆查询语言。Dreaming 整合闭环是一种有差异化、以研究为基础的记忆精炼方式，为其他超大规模云厂商的记忆产品所不具备。真实生产证据（Harvey）进一步强化了信号。之所以停留在试用而非采纳，是因为 Memory 与多智能体编排仍处公开测试，Dreaming 仍是需申请开通的研究预览，且该平台明确不适用于零数据保留（Zero Data Retention）或 HIPAA BAA 覆盖。

最适用场景：已在 Claude Managed Agents 上构建、希望把记忆、自评（Outcomes）与多智能体编排作为同一托管运行框架一部分，而非外接独立记忆厂商的团队。

局限：Anthropic/Claude 锁定——无法移植到其他模型厂商。文件系统挂载的记忆默认可读写，若不可信内容进入存储会带来提示词注入风险（Anthropic 建议参考资料用 read_only）。单文件大小上限 100 kB。Dreaming 需单独申请测试。

Salesforce Agentic Memory（Agentforce）

类型：Agentforce 内受治理的记忆层（专有，Salesforce）
支持的记忆类型：工作记忆（会话范围上下文）、语义记忆（持久化档案图谱）、情景记忆（跨渠道交互历史）
文档：How Agentic Memory Enables Reliable AI Agents Across Enterprise Users — Salesforce Engineering Blog

Salesforce 为 Agentforce 智能体打造的企业级记忆核心，旨在服务数百万并发企业用户而不退化为嘈杂或陈旧的上下文。短期记忆始终锚定在活跃会话上；长期记忆则关联到一张持久的档案图谱（profile graph），跨会话、跨通信渠道（聊天、邮件、语音）长存。Salesforce 工程团队把准确性问题视为治理问题：写入校验门（Write Validation Gate） 作为一套真值维护系统，将新事实与既有核心事实比对，拒绝与之矛盾的写入；而读取过滤（Read Filtering） 路径在检索时强制执行访问范围与时效相关性。置信度评分与混合语义校验让系统能够表达不确定性（例如 CRM 记录与对话信号之间的冲突），而非断言虚假的确定性。一个相关但更狭窄的能力 Agentforce Variables（2025 年 4 月）为开发者提供结构化的短期记忆，用于单次会话内的确定性动作调用。

推荐试用的理由：写入/读取门架构与置信度评分的档案图谱，是比多数专用记忆初创公司公开设计更为严格受治理的方案；鉴于 Agentforce 既有的 CRM 装机量，Salesforce「数百万企业用户」的规模主张可信。之所以停留在试用而非采纳，是因为它是内建的平台能力而非可独立采用的产品——没有独立 SDK、没有 GitHub 存在，Agentforce 平台之外也没有公开 API 参考。

最适用场景：已标准化采用 Salesforce/Agentforce、需要受治理且便于审计、与既有 CRM 身份和档案数据挂钩的记忆的企业，尤其是当记录系统与实时对话之间的冲突信号需要被调和而非被静默覆盖时。

局限：完全专有且仅限 Agentforce——无法在 Salesforce 平台之外使用，不支持自托管，无开源组件。无独立的 GitHub 或社区信号可供评估。架构细节通过工程博客而非正式文档或基准测试披露。

Supermemory

类型：开源记忆引擎（MIT）+ 托管云 API
支持的记忆类型：语义记忆、情景记忆
GitHub：supermemoryai/supermemory — 约 9K+ stars
文档：supermemory.ai

专为 AI 时代构建的高速、可扩展记忆 API。Supermemory 提供语义记忆存储与检索，召回延迟低于 300ms，并内置记忆路由器代理（Memory Router，透明地坐落于应用与 LLM 提供商之间注入上下文）、MCP 服务器支持，以及用于摄取文档与外部数据源的连接器（可与对话历史并用）。声称在 LoCoMo 与 ConvoMem 基准测试中排名第一，LongMemEval 准确率达 85.4%。托管 API 每月处理超过 1000 亿 Token。

推荐试用的理由：基准测试表现强劲，Memory Router 模式（零代码上下文注入）是差异化特性。社区持续增长，可在 Cloudflare Workers（基于 Durable Objects）上自托管。不过，其主要形态是托管 API——自托管需要 Cloudflare 基础设施，企业治理能力不及 Mem0 或云提供商方案。

最适用场景：希望获得经基准验证的语义 / 情景记忆、同时最小化集成代码量的团队。尤其适合希望在不修改智能体代码的前提下实现透明上下文注入的场景（Memory Router 模式）。

局限：自托管依赖 Cloudflare。企业级治理（多租户、合规控制）成熟度不及云提供商方案。社区规模小于 Mem0 或 Graphiti。

Redis Agent Memory Server

类型：开源记忆服务器（MIT）
支持的记忆类型：工作记忆（会话）、语义记忆、情景记忆
GitHub：redis/agent-memory-server
文档：redis.github.io/agent-memory-server

Redis 官方智能体记忆项目。提供两个独立的记忆层：工作记忆（会话范围的对话上下文，自动管理 Token 上限）和长期记忆（持久存储，支持语义、关键词及混合检索）。记忆可自动从工作层晋升至长期存储。同时暴露 REST API 和 MCP 服务器接口，并提供 Python 与 TypeScript SDK，支持命名空间实现多租户隔离。

推荐试用的理由：Redis 已是无处不在的基础设施——已运行 Redis 的团队无需引入新数据存储即可获得智能体记忆能力。MCP + REST 双接口覆盖智能体与传统集成两种模式。官方 Redis 项目，持续维护。不过相比 Mem0 或 Graphiti，该项目相对较新，社区信号较为有限。

最适用场景：已运行 Redis 且希望在不引入新依赖的情况下添加智能体记忆的团队。同时也是在单一系统中同时需要低延迟会话状态（工作记忆）与持久语义搜索的强力选择。

局限：需要 Redis Stack（向量搜索模块）。项目较新，生产案例研究有限。无托管云方案，仅支持自托管。

Hindsight（Vectorize）

类型：开源记忆库（MIT）+ 托管云平台
支持的记忆类型：语义记忆（世界事实）、情景记忆（经历）、概念记忆（心智模型）
GitHub：vectorize-io/hindsight — 约 14.4K stars
文档：vectorize.io

Hindsight 采用仿生学方法组织智能体记忆，将知识分为三个仿照人类认知建模的结构：世界层（关于用户与实体的持久性事实信念）、经历存储（情景事件记录）和心智模型（影响推理的概念框架）。其 LLM 包装器支持两行代码集成——直接置于现有智能体前端，无需重构代码库。在 LongMemEval 上报告 SOTA 表现。已通过 Hindsight Cloud（托管）或自托管方式被财富 500 强企业及 AI 初创公司采用。

推荐试用的理由：14.4K stars 及可信的企业采用使其成为 Mem0 和 Graphiti 之外验证度较高的开源记忆库之一。三层仿生模型覆盖语义记忆、情景记忆，以及大多数竞品所不具备的独立概念层。MIT 授权搭配托管云选项，灵活性充分。

最适用场景：需要跨三类知识类型进行类人召回的智能体。尤其在概念推理（心智模型更新）与原始事实检索同等重要时效果突出。

局限：Vectorize.io 是主要背书方——社区广度不及 Mem0 或 Graphiti。托管云为非自托管团队引入厂商依赖。

LanceDB

类型：开源嵌入式向量数据库，用作智能体记忆存储底层（Apache 2.0）+ 托管云（LanceDB Cloud）
支持的记忆类型：语义记忆（向量相似度）、情景记忆（元数据过滤的事件检索）、工作记忆（通过会话范围表实现）
GitHub：lancedb/lancedb — 约 8.8K stars
文档：lancedb.com · docs.lancedb.com

LanceDB 是基于 Lance 列式格式（Rust）构建的嵌入式、无服务器向量数据库。与大多数需要单独运行服务器的向量库不同，LanceDB 在进程内运行，无需部署任何基础设施。它将向量、元数据与多模态数据（文本、图像、点云）统一存储，支持混合检索（向量相似度 + BM25 全文检索 + 基于 DuckDB 的 SQL 过滤）、自动版本控制（Git 风格分支）及零拷贝读取。它与 LangChain、LlamaIndex 及其他智能体框架原生集成，作为语义记忆与情景记忆的持久化层。

针对专用智能体记忆场景，社区构建的 memory-lancedb-pro 插件（约 4.4K stars）在 LanceDB 基础上封装了交叉编码器重排序、多范围隔离（用户 / 会话 / 全局）及管理 CLI，提供完整的记忆抽象层，主要面向 OpenClaw 智能体。

推荐试用的理由：生产就绪的向量库，具备强大的生态采用（LangChain、LlamaIndex）、零服务器嵌入式部署以及大多数专用记忆方案无法匹敌的多模态支持。memory-lancedb-pro 插件将其扩展为一流的智能体记忆层。合并 GitHub 信号（约 8.8K 核心 + 约 4.4K 插件）反映了真实的市场牵引力。

最适用场景：希望获得轻量级嵌入式记忆底层且无需单独服务器的团队——本地优先的智能体部署、边缘 / 设备端智能体，或任何启动专用向量数据库成本过高的项目。也是通过 memory-lancedb-pro 面向 OpenClaw 智能体栈的自然选择。

局限：LanceDB 本身是存储层，而非完整的记忆抽象——不提供开箱即用的自动记忆提取、矛盾消解或跨会话个性化。这些功能需要用更高层框架进行封装（memory-lancedb-pro、LangMem 或自定义代码）。memory-lancedb-pro 插件目前仅针对 OpenClaw。

Honcho（Plastic Labs）

类型：开源记忆服务器（AGPL-3.0）+ 托管云 API
支持的记忆类型：工作记忆（会话 / 消息历史）、语义记忆（对等方表示）、情景记忆（事件日志）
GitHub：plastic-labs/honcho — 约 3.6K stars
文档：api.honcho.dev

Honcho 围绕以对等方为中心的记忆模型构建——它不将记忆视为扁平键值或向量存储，而是围绕智能体与交互对象之间的关系来组织上下文。每位用户都是一个"对等方"，拥有存储的消息历史、会话上下文和自然语言洞察查询（例如"这位用户在 Python 方面有什么偏好？"）。FastAPI 后端支持自托管或通过托管云访问，作为其他智能体框架可调用的记忆中间件层，而非取代它们。

推荐试用的理由：以对等方为中心的架构是差异化模型，非常契合个性化与关系感知型智能体。生产就绪，提供托管云，社区增长合理，采用 MIT 兼容方式（自托管使用 AGPL，云端使用托管 API 条款）。框架无关。

最适用场景：对理解个体用户或利益相关方质量是核心价值驱动力的对话型智能体——辅导智能体、客户关系智能体、个人助手。

局限：AGPL-3.0 授权要求在以服务形式部署时开放衍生作品，可能不适合闭源商业产品。社区规模小于 Mem0 或 Graphiti。以语义 / 情景记忆为主，程序记忆需在外部处理。

ByteRover（Campfire）

类型：源码可见记忆层（Elastic License 2.0）+ 托管云平台
支持的记忆类型：工作记忆（层次化上下文树）、语义记忆（精选项目知识）、情景记忆（工具调用与交互日志）
GitHub：campfirein/byterover-cli — 约 4.6K stars
文档：byterover.dev

ByteRover（前身为 Cipher）是一个针对编码智能体优化的便携式记忆层。其核心设计选择是用层次化上下文树取代向量数据库——知识按项目范围分层组织，通过模糊文本搜索结合 LLM 驱动的相关性排序进行检索。默认在本地运行，无需任何外部依赖；ByteRover Cloud 支持团队级记忆共享。在 LoCoMo 排行榜上声称达到 92.2%，在代码感知检索任务中优于大多数通用记忆方案。

推荐试用的理由：编码智能体记忆场景基准信号最强。层次化树方案在避免嵌入 / 向量基础设施成本的同时，在代码与项目知识上实现了高检索精度。同时支持本地与云端部署，生产就绪。4.6K stars 表明社区有实质性牵引力。

最适用场景：编码智能体、开发者工具及 IDE 集成智能体，尤其是记忆域为结构化项目知识而非开放式对话历史的场景。特别适合通过 ByteRover Cloud 进行团队共享上下文的需求。

局限：Elastic License 2.0 是源码可见授权，而非真正的开源——未经 Campfire 单独授权的商业使用可能受到限制。设计针对代码 / 项目知识优化，不适合通用对话记忆场景。项目较新，编码智能体以外的案例研究有限。

🟡 评估

值得关注和持续跟进的解决方案。尚未经过规模化验证，或适用范围过窄，暂不作一般性推荐。

OpenViking（Volcano Engine / ByteDance）

类型：开源上下文数据库 / 层次化文件系统记忆（Apache 2.0）
支持的记忆类型：工作记忆（会话）、语义记忆、情景记忆、程序记忆（技能）
GitHub：volcengine/OpenViking — 约 15K+ stars（2026 年 1 月发布）
文档：openviking.ai

OpenViking 是 ByteDance Volcano Engine 推出的上下文数据库，用统一的文件系统范式取代碎片化的向量库。每条上下文——记忆、资源和技能——都像目录树中的文件一样存储和寻址。写入时，每条内容自动处理为三个粒度层级：L0（单句摘要，< 100 Token）、L1（含结构与用法的概览，< 2K Token）、L2（按需通过 URI 加载的完整内容）。检索通过向量相似度定位目标目录，再递归进入子目录——层次化下钻，而非扁平近邻搜索。这一架构正是与 OpenClaw 智能体配合使用时输入 Token 消耗减少 80% 以上的根本原因（任务完成率也从 35.65% 提升至 52.08%）。

推荐评估的理由：早期基准结果令人印象深刻，社区增长迅速（不到五个月即达 15K+ stars），表明有真实的市场兴趣。ByteDance/Volcano Engine 是可信的工程背书方。文件系统框架将记忆和技能统一于同一底层——范围比雷达中任何其他工具都更广泛。然而，该项目不足六个月，独立生产案例研究有限，主要参考实现面向 OpenClaw 智能体栈。

最适用场景：希望实验层次化上下文管理、同时降低 Token 成本并跨会话保留丰富上下文的团队。尤其适合作为多智能体系统的补充，在需要将技能（程序记忆）和资源与对话历史一并进行结构化检索的场景中使用。

局限：非常新（2026 年 1 月）。主要集成为 OpenClaw，更广泛的框架支持仍处于早期开发阶段。无托管云方案，仅支持自托管。ByteDance 自身系统以外的生产证据有限。

agentmemory（rohitg00）

类型：面向编码智能体的开源持久化记忆服务器（Apache 2.0）
支持的记忆类型：工作记忆（会话捕获）、语义记忆（知识图谱）、情景记忆（会话历史、每日日志）
GitHub：rohitg00/agentmemory — 24K+ stars
文档：npm @agentmemory/agentmemory

一个构建在 iii-engine（Worker/Function/Trigger）原语之上的持久化记忆运行时，专为编码智能体而非通用对话记忆打造。一个本地服务器（REST 在 :3111、流式在 :3112、查看器 UI 在 :3113）静默捕获智能体活动——文件编辑、工具调用、决策——将其压缩为可检索的记忆，并在下次会话开始时注入相关上下文。捆绑的 MCP 服务器暴露 53 个工具（在无可达服务器时回退到 7 个本地工具），外加 8 个可调用技能与 7 个参考技能（/recall、/remember、/handoff 等）。12 个生命周期钩子与 Claude Code 原生集成（SessionStart、PreCompact、SubagentStop 等），并对 Codex CLI、GitHub Copilot CLI、Cursor、Gemini CLI、Hermes、OpenClaw 及其他 MCP 客户端提供原生或基于 MCP 的额外集成——全部共享同一个记忆服务器。混合检索将向量嵌入与 BM25 关键词搜索结合；项目报告在内部检索基准上达 95.2%，恢复上下文所需 Token 减少 92%，并有 1400+ 通过的测试支撑。

推荐评估的理由：智能体集成的广度（16+）、MCP 工具面以及混合检索设计确实有实力，npm 包与 CI 信号也表明背后有真实的工程投入。然而该仓库仅有几个月历史（2026 年 2 月创建），其 24K+ 的 star 数增长即便以本雷达的标准看也异常之快——比 OpenViking 本已迅猛的增长还要快——在把 star 数当作可靠采用信号之前值得核实。仅有内部基准（无独立的 LongMemEval/LoCoMo 结果）以及对编码智能体工作流的狭窄聚焦（而非通用对话/个性化记忆），也都支持先观察而非投入。

最适用场景：使用编码智能体（Claude Code、Cursor、Codex CLI、OpenClaw）、希望获得会话到会话连续性与跨工具共享记忆，又不想另起一套向量/图数据库的团队。

局限：项目非常年轻——生产实绩与独立基准验证有限。所报告的增长指标未经独立核实。范围专属于编码智能体，而非通用语义/情景记忆层。需要运行并维护一个基于 iii-engine 的本地服务器。

Cloudflare Agent Memory

类型：托管云服务，私有测试（Cloudflare）
支持的记忆类型：工作记忆（对话抽取）、语义记忆（持久事实）、情景记忆（事件）、程序性记忆（抽取的指令/任务）
文档：developers.cloudflare.com/agent-memory

在 Cloudflare 的 Agents Week（2026 年 4 月 12–17 日）期间发布，目前处于私有测试（候补名单）。Agent Memory 从智能体对话中抽取结构化记忆——事实、事件、指令与任务——而非保留原始逐字记录，然后在推理时只检索并注入相关条目。它被明确定位为对长时运行智能体上下文腐化的修复方案。接入方式是通过任意 Cloudflare Worker 的绑定，或为运行在 Workers 之外的智能体提供 REST API。智能体通过一套基于档案的 ingest/recall/forget API 与记忆交互。Cloudflare 强调数据可移植性——每条记忆均可导出——并且在测试期暂不计费。

推荐评估的理由：Cloudflare 既有的边缘网络与 Workers/Durable Objects 生态（也是本雷达上 Supermemory 自托管选项背后的底座）为该服务提供了可信的基础设施背书，且「抽取而非回放」的设计与 Mem0、Salesforce Agentic Memory 等更成熟竞品所用架构一致。之所以停留在评估而非试用，是因为它仅为私有测试、定价未公开，且尚无公开的生产案例。

最适用场景：已在 Cloudflare Workers 上运行智能体、希望在服务退出私有测试后获得托管记忆而不新增独立向量/图数据库厂商的团队。

局限：私有测试——需候补名单权限。定价未公开。与 Cloudflare 平台耦合（Workers 绑定是主要集成路径）。目前尚无独立的生产证据。

Maximem（Synap + Vity）

类型：托管云记忆平台（专有）
支持的记忆类型：工作记忆（短期会话上下文）、语义记忆（知识图谱 + 向量）、情景记忆（交互轨迹）、组织记忆（共享知识流水线）
GitHub：maximem-ai
文档：maximem.ai · maximem.ai/product

Maximem 在同一平台下推出两款独立产品：

Synap（2026 年 4 月发布）是面向智能体的记忆层。提供持久性短期与长期记忆、检索、评测及组织知识流水线。在 LongMemEval 上以 15ms P50 检索延迟达到 90.2%——是该领域已发布基准组合中最强之一。在发布时即与 LangChain、LlamaIndex、CrewAI、Google ADK、AutoGen、OpenAI Agents SDK、Semantic Kernel、Haystack 和 Pydantic AI 九个框架原生集成。设计上以隐私为先，支持端到端加密。

Vity 是面向高级用户而非开发者的个人记忆保险库。它监听 AI 会话（包括 OpenClaw），将上下文提取至语义图谱（代码决策、架构选择、用户偏好、项目状态），并在每次响应前通过插件注入相关记忆。跨平台支持：可与 ChatGPT、Claude、Gemini、Slack、Telegram、WhatsApp 及 Discord 协同工作。支持 /remember 和 /recall 斜杠命令，以及用于保存代码仓库与文档的书签智能。

推荐评估的理由：最广的框架支持（发布时 9 个集成）与有竞争力的 LongMemEval 分数使 Synap 值得持续关注。然而 Maximem 非常新（2026 年 4 月），没有独立的社区信号或公开的 GitHub stars。两款产品均为完全专有，无自托管选项。Vity 面向终端用户，而非智能体基础设施工程师。建议等待独立采用证据出现后再进行评估。

最适用场景：希望在多个框架中获得托管、隐私优先记忆层而无需自建检索基础设施的团队。Vity 适合希望在多个 AI 工具与通信渠道间实现持久记忆打通的个人从业者。

局限：完全专有——无开源代码，无自托管。截至 2026 年 5 月，非常新，无独立生产案例研究。无公开融资或社区规模数据。厂商存续风险与 RetainDB 类似。

RetainDB

类型：托管云记忆服务（专有）
支持的记忆类型：情景记忆（对话历史）、语义记忆（向量 + BM25 混合检索）
GitHub：不适用（云服务）
文档：retaindb.com

RetainDB 是仅限云端的持久记忆服务，采用增量压缩实现高效对话历史存储，并通过混合检索流水线（向量相似度 + BM25 关键词 + 重排序）实现高精度召回。记忆提取在服务端通过 Claude Sonnet 完成。通过 REST API 与 Hermes Agent 框架及其他智能体运行时集成。定价从每月 20 美元起。

推荐评估的理由：增量压缩 + 混合检索的组合在低成本长期存储方面具有技术亮点，声称具有竞争力的 LongMemEval 表现。然而，截至 2026 年 5 月，无任何开源组件、无公开背书公司、无 GitHub 社区，也无法获得独立验证。厂商存续风险不可忽视。

最适用场景：希望获得完全托管、零基础设施记忆 API 且愿意接受早期阶段专有服务的团队。建议在厂商建立更多透明度和记录之后再进行评估。

局限：仅限云端，无自托管选项。无开源代码，无公开公司主体，无独立社区信号。厂商锁定且无文档化的迁移路径。

LangMem

类型：LangGraph 专用开源记忆库（MIT）
支持的记忆类型：语义记忆、情景记忆、程序记忆
GitHub：langchain-ai/langmem — 约 1.5K stars

LangChain 专为 LangGraph 智能体设计的记忆库。支持三种长期记忆类型（语义、情景、程序），并与 LangGraph 的状态管理原生集成。相对较新（2025 年），社区规模小但持续增长。

推荐评估的理由：唯一明确将程序记忆与语义记忆、情景记忆并列为一等公民的库。对已使用 LangGraph 的团队而言，深度集成是真实的优势。但社区规模小、成熟度早期，在做出承诺前需谨慎对待。

最适用场景：已使用 LangGraph 且希望在不引入独立服务的情况下获得紧密集成记忆的团队。

局限：社区规模小（约 1.5K stars）。与 LangChain/LangGraph 生态紧耦合。实战验证程度不及 Mem0 或 Graphiti。

🔴 谨慎

请谨慎使用。以下解决方案处于早期 / 实验阶段、适用范围过窄，或存在限制通用性的特性。

AgentFS（Turso）

类型：开源 SQLite 支撑的虚拟文件系统（MIT）
支持的记忆类型：工作记忆（文件系统 / 草稿板）、情景记忆（工具日志）
GitHub：tursodatabase/agentfs — 约 2.5K stars

AgentFS 为智能体提供便携式、SQLite 支撑的虚拟文件系统——一种管理文件、键值状态与工具日志的"硬盘"抽象。可作为工作记忆草稿板和情景日志存储使用，但不是通用记忆解决方案。

列为谨慎的理由：自描述为 alpha / 实验阶段。适用范围窄（文件系统抽象，不支持语义或程序记忆）。社区规模小。最好作为完整记忆方案的补充使用，而非替代。

最适用场景：需要结构化文件与日志管理作为主记忆系统补充的智能体。

局限：Alpha 质量。非完整记忆方案——无语义检索、无知识图谱、无跨会话个性化。需要 Turso/libSQL。

MinnsDB

类型：多模态记忆数据库，单个 Rust 二进制（许可证未确认）
支持的记忆类型：语义记忆（时序知识图谱、向量库、断言库）、情景记忆（情景回忆）、工作记忆（结构化/时序表）

MinnsDB 被描述为一个单二进制记忆数据库，融合了时序知识图谱、向量库、BM25 索引、断言库、时序表与结构化记忆，且无外部数据库依赖（内嵌 redb 存储）。每个事实都作为带有效期窗口（valid_from/valid_until）的图边存储；一个 OWL/RDFS 本体层驱动级联失效，因此一条新事实（如「我搬到了纽约」）会自动使与之矛盾及依赖的事实（如「住在伦敦」「周末去大英博物馆」）失效。据称其检索通过倒数排名融合（Reciprocal Rank Fusion）融合七路来源（BM25、节点/边向量相似度、置信度评分的已验证断言、一跳实体解析、DRIFT 社区搜索、情景回忆），并有一个「MinnsDB Connect」组件声称支持 49 个数据源连接器（Slack、Gmail、Jira、Salesforce、GitHub 等）。

列为谨慎的理由：其架构描述（若属实）是本雷达所覆盖中较为精巧的时序图设计之一，在雄心上可与 Graphiti 相比。然而在撰写本文时，除一篇第三方对比文章外，未能找到任何独立的 GitHub 仓库、公司主体、许可证或生产部署——与将 RetainDB 和 Maximem 列入本雷达并加谨慎标记的同一证据缺口。在找到一手来源（仓库、文档站或厂商页面）之前，请将所有架构主张视为未经核实。

最适用场景：目前不推荐采用。待可核实的来源（仓库、官方文档或公司页面）出现后值得再看——其时序级联失效设计对需要追踪随时间变化状态的智能体（CRM、交易管线、个性化）具有相关性。

局限：截至本次评估，未找到经核实的 GitHub 仓库、许可证或厂商主体。所有技术主张均源自单篇第三方清单文章，而非一手文档或基准测试。请将 star 数、性能与连接器主张视为未经核实。

全息记忆（via Nuggets）

类型：开源本地记忆模块（个人项目）
支持的记忆类型：工作记忆（活跃上下文）、语义记忆（全息向量记忆）
GitHub：NeoVertex1/nuggets — 约 200 stars

一个实验性个人 AI 助手模块，使用全息简化表示（HRR，Holographic Reduced Representations）——将事实编码为叠加态的复值向量，支持亚毫秒级召回且无需外部数据库。事实在被召回三次或以上后从临时上下文晋升为永久上下文，模拟人类记忆巩固机制。完全本地运行，无任何外部依赖。

列为谨慎的理由：HRR 方案在学术上具有研究价值，零依赖的本地设计对隐私敏感部署颇具吸引力。然而，这是一个约 200 stars 的早期个人项目，无生产使用记录，且未公开许可证。实现范围窄（不支持情景记忆或程序记忆）。目前状态不适合生产使用。

最适用场景：探索全息 / 神经符号记忆表示的研究性工作，以及零外部依赖为硬性要求的本地原型场景。

局限：约 200 stars，个人维护者，无生产部署案例。适用范围窄——不支持情景记忆、程序记忆或多租户。许可证未明确说明。

AWS 记忆架构指南

来源：AWS Marketplace — Agent Memory Systems (Module 7)

本节提炼自 AWS「Building Agentic Systems on AWS」系列教程中的架构指南，涵盖记忆类型分类、实现模式、合作方向量库、Graph RAG 与治理——全部围绕 AWS 服务和 AWS Marketplace 合作方工具展开。

记忆分类：两个维度

AWS 沿两条相互独立的轴来组织智能体记忆：

将时长 × 范围绘成矩阵，可得到四种象限类型：上下文内的工作记忆、短期会话记忆、长期语义记忆，以及跨智能体共享记忆。

上下文内工作记忆（上下文窗口）

上下文窗口是智能体即时的认知工作区。在 Amazon Bedrock 上，Claude 模型支持 200K token 的上下文窗口（beta 阶段可达 1M），约合 500 页文本。尽管容量慷慨，上下文管理仍然重要，原因有二：成本随上下文中每个 token 增长；模型注意力并不均匀——上下文窗口开头和结尾的内容比中间的内容获得更强的注意力。

四种管理策略：

LangChain 的 ConversationSummaryBufferMemory 实现了混合策略，并与 LangGraph 状态管理集成。

设计原则：按智能体角色定制上下文。代码分析智能体需要代码及其依赖，而非完整对话历史；对话智能体需要历史，而非原始代码文件。

短期会话记忆

LangGraph 通过 checkpointer 抽象实现会话记忆——一个持久化存储，它将整个智能体状态对象（消息历史、任务状态、用户偏好、中间结果）序列化到后端存储，并以代表用户会话的 thread ID 为键。

后端选型：

Redis Cloud 在 ElastiCache 之外增添了若干能力：双活地理复制让会话状态在 AWS 各区域间保持一致；Redis on Flash 通过分层到 NVMe SSD 来扩展内存容量；哈希/有序集合/流等数据结构直接映射到智能体的状态模式（窗口化历史、仅追加的事件日志）。LangGraph 的 Redis checkpointer 在 ElastiCache 与 Redis Cloud 上工作方式完全相同——只需更改连接串。

长期语义记忆与向量库

长期语义记忆无限期持久化，靠语义相似度（而非直接查找）检索，是 RAG 的基石。Amazon Bedrock 提供两种嵌入模型：

• Amazon Titan Text Embeddings v2 —— 1,024 维，针对英文检索优化
• Cohere Embed Multilingual v3 —— 1,024 维，支持 100+ 种语言

向量索引架构：

混合检索将向量（语义）检索与 BM25（关键词）检索结合，通过倒数排名融合（RRF）合并。Weaviate 提供开箱即用的强力混合检索；Amazon Bedrock Knowledge Bases 使用 Amazon OpenSearch Serverless 实现 BM25 + 向量的联合检索。

重排序（Re-ranking）将一个交叉编码器模型用作第二阶段——从向量数据库取回前 20 个候选，重排序为前 5 个再注入上下文。Bedrock Knowledge Bases 支持内建重排序。

向量库选型（AWS Marketplace 合作方）：

MongoDB Atlas：文档 + 向量的统一记忆

MongoDB Atlas 通过把运营数据存储（结构化记录）与向量存储（嵌入）共置于同一文档，消除了两者之间的割裂。一条部署记录既可携带结构化元数据（时间戳、环境、受影响的服务、结果），又可携带其嵌入向量——单条 Atlas 查询即可同时按结构化元数据过滤并按向量相似度检索，无需跨两个系统做联接。

这种统一模型自然契合记忆巩固：巩固后的会话记录作为 Atlas 文档写入，同时带有可查询字段和嵌入向量，从而既支持精确属性查找（"找出用户 X、服务 Y 的所有记录"），也支持语义相似检索（"找出与此事件相似的记录"）。

基于 Neo4j AuraDB 的 Graph RAG

向量检索按含义寻找内容。Graph RAG 在其之上增加结构化/关系型推理——智能体可以回答那些需要遍历实体关系、而不仅仅是找到相似文本的问题。

Graph RAG 检索流水线（对比标准 RAG）：

两种遍历策略：

• 实体优先（Entity-first）：查询锚定到一个具名实体，再从它向外遍历。最适合"哪些服务依赖服务 X？"这类问题。
• 社区优先（Community-first）：预先算出的图聚簇识别出若干社区；检索先找到最相关的社区，再找代表性节点。最适合没有具名锚点的开放式查询。

Neo4j AuraDB（AWS Marketplace）是推荐的后端存储。它提供：节点属性上的原生向量索引（找实体这一步无需另设向量数据库）、Cypher 查询语言（可在一次往返中组合图遍历 + 向量相似度），以及原生 LangChain 集成（Neo4jVector、GraphCypherQAChain）。

当三个条件同时成立时，Graph RAG 才值得它的复杂度：领域中存在对查询很重要的多对多关系；这些关系在自由文本文档中表达得并不好；且智能体经常需要对关系结构进行推理。良好的信号包括：影响半径/级联故障查询、依赖排序、归属链、根因排查。

跨智能体共享记忆

共享记忆让多智能体系统中的智能体通过一个公共存储来协调，而非依赖脆弱的直接消息传递。设计考量：

• 并发：DynamoDB 条件表达式为并发写入提供乐观并发控制；协调状态（不仅是会话状态）需要强一致读。
• 模式：单表 DynamoDB 设计，采用 (workflow_execution_id, record_type) 复合键；每条记录带模式版本号以便平滑演进。
• 访问控制：IAM 条件键将每个智能体角色限定在其被授权的分区键前缀上——分析智能体只能读写 analysis#* 记录，部署智能体则被限制在 deployment#*。这可缩小提示词注入或供应链攻击的影响半径。

记忆即数据资产：治理

记忆基础设施持有敏感数据，必须像对待任何企业数据资产一样治理。

记忆巩固模式

记忆巩固从短暂的会话历史中抽取可持久的知识，避免智能体在之后每次会话中重新发现相同信息。

巩固什么（而非逐轮的原始消息）：明确的用户偏好与约束、跨会话持续存在的环境/配置事实、工作流决策及其理由、已解决的问题及其方案、跨多次工具调用观察到的模式。

巩固步骤使用 Amazon Bedrock 文本生成配合结构化抽取提示词——产出一条 JSON 记录，含用户偏好、配置事实、已解决问题、遗留问题和关键决策等字段。该记录连同将其链接回原始会话的元数据（会话 ID、用户 ID、时间范围、巩固时间戳）一起被摄入 LTM 存储。

AWS 的实务建议：先把会话记忆做对，再投入向量库——会话记忆是最直观可见的能力，也是巩固所依赖的基础。记忆巩固在技术上并不复杂，但在运维上要求很高：每晚的工作流必须可靠运行，抽取提示词需要持续调优，巩固记录的质量也需在数月的生产运行中被持续监控。

框架原生记忆

上面的雷达覆盖的是专用、独立的记忆产品。大多数智能体框架也自带一个内建的记忆子系统——它们是框架特性而非可独立采用的产品，故不在此雷达评级，但对于尚未决定引入专用记忆厂商的团队而言，它们才是现实中的默认选择。

这对雷达为何重要：评估 Mem0、Graphiti、Letta 或上述其他专用方案的团队，通常是在「用框架的原生记忆」与「引入专用记忆层」之间抉择。框架原生选项没有额外基础设施成本，对简单的会话连续性已足够；专用方案则在需要多跳关系推理（Graphiti、Cognee）、跨框架可移植性（Mem0）或生产级治理（云厂商与企业级产品）时，才配得上其在本雷达上的位置。

完整框架介绍见 LangChain、LlamaIndex 与 CrewAI。

雷达汇总表

选型指南

根据你的约束条件缩小候选范围。

雷达评估标准

各解决方案在以下维度进行评估，评级截至 2026 年 5–6 月。

雷达位置定期重新评估。GitHub Stars 数量与采用信号均为评估日期的时间点数据。

参见

• 四种记忆类型
• 长期记忆策略
• 工作记忆管理
• 研究论文
• Claude Managed Agents —— 完整的 Memory + Dreaming + Outcomes 架构
• AWS AgentCore 平台 —— AgentCore Memory 托管服务
• LangChain、LlamaIndex、CrewAI —— 框架原生记忆子系统

参考资料

• AWS Marketplace — Agent Memory Systems (Module 7) — AWS「Building Agentic Systems on AWS」系列；记忆分类（时长 × 范围）、上下文窗口管理策略、向量索引架构（HNSW/IVF/flat）、混合检索 + 重排序、基于 Neo4j 的 Graph RAG、Redis/MongoDB 架构模式、基于 DynamoDB 的跨智能体共享记忆、基于 Bedrock Guardrails 的 PII 治理、记忆巩固模式（定时与阈值触发）

• Mem0 Series A announcement — 采用指标

• Graphiti GitHub — 时序知识图谱框架
• Letta GitHub — 有状态智能体运行时
• AWS AgentCore Memory — AWS Summit NYC 2025 发布公告
• Vertex AI Memory Bank — Google Cloud 文档
• Azure AI Foundry — Microsoft 文档
• Oracle AI Agent Memory — Oracle 产品页
• Oracle Unified Agent Memory Core blog — 技术概述
• Supermemory GitHub — 记忆引擎与 API
• Supermemory benchmarks — LongMemEval、LoCoMo、ConvoMem 结果
• Redis Agent Memory Server — Redis 官方记忆服务器
• Redis Agent Memory Server docs — 架构与 API 参考
• LangMem GitHub — LangChain 记忆库
• AgentFS GitHub — Turso 智能体文件系统
• OpenViking GitHub — Volcano Engine / ByteDance 开源上下文数据库
• OpenViking site — 项目主页与文档
• MarkTechPost: Meet OpenViking — 概述与基准结果
• Red Hat Developer: Deploy OpenViking on OpenShift AI — 部署指南
• Cognee GitHub — 含 ECL 流水线的知识图谱记忆引擎
• Cognee site — 产品概述、70+ 公司案例研究、750 万美元种子轮公告
• Cognee memory architecture blog — ECL 流水线与会话 / 永久记忆模型
• Microsoft AI Agents for Beginners — Agent Memory with Cognee — 教程 Notebook
• LanceDB GitHub — 用作智能体记忆存储底层的嵌入式向量数据库
• LanceDB docs — 架构、混合检索与智能体集成指南
• memory-lancedb-pro GitHub — 面向 OpenClaw 的增强型 LanceDB 记忆插件（含混合检索与重排序）
• LanceDB blog: OpenClaw memory layer — LanceDB 作为智能体记忆底层
• Hindsight GitHub — Vectorize.io 仿生智能体记忆库
• Hindsight blog — 世界 / 经历 / 心智模型架构概述
• Honcho GitHub — Plastic Labs 以对等方为中心的记忆服务器
• Honcho cloud API — 托管记忆服务文档
• ByteRover GitHub — Campfire 层次化上下文树记忆
• ByteRover benchmarks — LoCoMo 92.2% 排行榜结果
• Maximem site — Synap 智能体记忆层与 Vity 个人记忆保险库
• Maximem product page — Synap 与 Vity 产品概述
• Maximem GitHub org — npm 插件与 SDK
• Maximem Synap comparison — Synap vs. Mem0、Zep、Letta、Supermemory、Cognee、Evermind
• RetainDB — 仅限云端的增量压缩记忆 API
• Holographic memory (Nuggets) — 基于 HRR 的本地记忆模块
• Redis Agent Memory context engine docs — Redis 智能体记忆架构参考
• Using agent memory — Claude API Docs — Anthropic Claude Managed Agents Memory 文档
• New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration — Anthropic 官方博客，2026 年 5 月
• How Agentic Memory Enables Reliable AI Agents Across Enterprise Users — Salesforce 工程博客，写/读门与置信度评分
• Breaking the Memory Trilemma: How to Build AI Agents That Actually Remember — Salesforce 博客，记忆架构概述
• Agentforce Variables: A New Way to Structure Agent Memory — Salesforce Developers 博客，结构化短期记忆
• Agents that remember: introducing Agent Memory — Cloudflare 官方博客，2026 年 4 月
• Cloudflare Agent Memory docs — 官方文档
• Cloudflare Announces Agent Memory, a Managed Persistent Memory Service for AI Agents — InfoQ 报道
• agentmemory GitHub — 面向编码智能体、基于 MCP 的持久化记忆服务器
• agentmemory on npm — 包分发
• The 10 Best AI Memory Layers for Agents in 2026 — 第三方对比文章；描述 MinnsDB 的唯一已知来源
• LangGraph memory docs — Checkpointer 与 Store 记忆原语
• LlamaIndex Memory module docs — 对话历史缓冲区与长期记忆块
• CrewAI Memory docs — 统一 Memory 类 API
• Thoughtworks Technology Radar — 雷达方法论参考
• Cognitive Architectures for Language Agents (CoALA) — 记忆类型分类