前端 · 2026年3月28日

Supermemory实测:给AI加一块”硬盘”,20K Star的记忆引擎到底能记住多少

做AI产品的人都遇到过同一个问题:用户跟AI聊了半小时,关掉窗口再打开,AI把所有事都忘了。

你可以用RAG塞文档,用System Prompt塞用户画像,但这些都是手动维护的”假记忆”。用户说”我上次提到的那个项目”,AI一脸茫然。这个问题在Agent场景下更严重——Agent需要跨多轮对话积累上下文,而不是每次从零开始。

Supermemory这个项目最近在GitHub上涨到了近20K Star,号称”AI时代的记忆API”,在LongMemEval、LoCoMo、ConvoMem三个记忆评测榜单上都排第一。拿来试了一下,记录整个过程。

这东西解决什么问题

传统方案做AI记忆,路径大概是这样:

方案 做法 问题
System Prompt硬编码 把用户信息写死在prompt里 不会自动更新,prompt越来越长
RAG检索 把对话存向量库,查询时召回 只能找到”相关文本”,不理解语义变化
手动维护用户画像 自己写逻辑提取用户信息 工作量大,难处理矛盾和时间变化

Supermemory的思路不太一样。它不只是存对话然后检索,而是会自动从对话里提取事实,构建一个语义知识图谱,处理信息更新和矛盾。比如用户三月说”我在用React”,六月说”我们迁移到Vue了”,它能理解后者覆盖了前者。

核心能力三块:

  • Memory API — 自动从对话提取事实,构建用户知识图谱
  • User Profile — 自动维护用户画像,分静态信息和动态信息
  • Super RAG — 在记忆基础上做语义检索,支持文件、图片、视频

安装和配置

SDK支持TypeScript和Python,注册拿API Key就能用:

npm install supermemory
export SUPERMEMORY_API_KEY="你的key"

console.supermemory.ai注册,点API Keys → Create API Key生成一个。

实战:给聊天机器人加记忆

场景很简单:一个客服Bot,用户聊过的东西下次不用再说。

第一步:存对话

每轮对话结束后,把内容存进去:

import Supermemory from "supermemory";

const client = new Supermemory();
const USER_ID = "user_12345";

// 一轮对话结束后,存入记忆
const conversation = [
  { role: "user", content: "我们公司用的是Next.js 15,部署在Vercel上" },
  { role: "assistant", content: "了解,Next.js 15配合Vercel部署是个很常见的方案..." },
  { role: "user", content: "最近在考虑把状态管理从Redux迁移到Zustand" },
  { role: "assistant", content: "Zustand确实更轻量..." },
];

await client.add({
  content: conversation.map((m) => `${m.role}: ${m.content}`).join("\n"),
  containerTag: USER_ID,
});

containerTag就是用户标识,所有记忆按这个分组。

第二步:下次对话时召回记忆

用户再来的时候,先拿记忆和画像:

const query = "我之前说的那个状态管理迁移,有什么需要注意的吗";

const profile = await client.profile({
  containerTag: USER_ID,
  q: query,
});

// 静态画像:长期不变的信息
console.log("静态信息:", profile.profile.static);
// → ["用户公司使用Next.js 15", "部署平台为Vercel"]

// 动态画像:近期活跃的上下文
console.log("动态信息:", profile.profile.dynamic);
// → ["正在考虑从Redux迁移到Zustand"]

// 相关记忆:跟当前问题最相关的历史片段
console.log("相关记忆:", profile.searchResults.results);

拿到这些之后,拼到System Prompt里喂给LLM:

const context = `用户背景:
${profile.profile.static.join("\n")}

近期动态:
${profile.profile.dynamic.join("\n")}

相关对话记忆:
${profile.searchResults.results.map((r) => r.memory).join("\n")}`;

const messages = [
  { role: "system", content: `你是技术助手。以下是该用户的背景信息:\n${context}` },
  { role: "user", content: query },
];

// 丢给你的LLM
const response = await llm.chat({ messages });

整个流程就是:对话结束→存记忆→下次对话→取记忆→拼prompt。SDK帮你处理了中间所有脏活。

Python也一样

Python的SDK接口几乎一模一样:

from supermemory import Supermemory

client = Supermemory()
USER_ID = "user_12345"

# 存记忆
client.add(
    content="user: 我在做一个电商项目,用的Taro跨端框架\nassistant: Taro是个不错的选择...",
    container_tag=USER_ID,
)

# 取记忆
profile = client.profile(
    container_tag=USER_ID,
    q="之前那个跨端项目进展怎么样",
    threshold=0.7,  # 只返回相关度0.7以上的结果
)

static_info = "\n".join(profile.profile.static)
dynamic_info = "\n".join(profile.profile.dynamic)
memories = "\n".join(r.get("memory", "") for r in profile.search_results.results)

threshold参数挺实用,可以过滤掉不太相关的记忆,避免给LLM塞太多噪音。

跟纯RAG比,区别在哪

用同一组对话测试,对比Supermemory和直接用向量数据库做RAG的效果:

场景 纯RAG(向量检索) Supermemory
用户说”我换工作了” 两份工作信息都召回,LLM困惑 知道新工作覆盖了旧工作
“上次聊的那个” 不知道”上次”是什么时候 有时间线,能定位到最近的对话
用户画像查询 需要自己维护 自动生成,分静态/动态
矛盾信息处理 全部返回,由LLM判断 自动处理更新和覆盖
响应延迟 取决于向量库,通常50-200ms profile接口约50ms

最大的差别是矛盾处理。纯RAG就是个搜索引擎,你存了什么它就返回什么。用户画像变了,旧的新的一起返回,全靠LLM自己判断哪个是最新的。Supermemory在存储层就处理了这个问题。

Connector生态

除了手动存对话,Supermemory还支持直接对接外部数据源:

  • Google Drive / Gmail — 自动同步文档和邮件
  • Notion — 同步知识库
  • OneDrive — 同步文件
  • GitHub — 同步代码仓库

这些Connector支持Webhook实时同步,数据源更新了记忆也跟着更新。对于需要给AI接入企业知识库的场景,省了不少对接工作。

插件支持

Supermemory还提供了现成的插件,直接给现有的AI工具加记忆能力:

  • Claude Code插件 — 让Claude Code记住你的项目上下文
  • OpenCode插件 — 给编码Agent加持久记忆
  • 浏览器扩展 — 浏览网页时自动积累知识

这些插件的代码都开源在GitHub上,本质上就是SDK的封装,可以参考着给自己的工具写一个。

实际踩的坑

1. containerTag的设计很重要

一开始图省事,所有用户共享一个containerTag,结果用户A的信息跑到用户B的记忆里去了。containerTag必须保证用户级隔离,这个不能偷懒。

2. 对话存储的粒度

不要把整个几十轮的长对话一次性塞进去。Supermemory能处理,但效果不如按话题切分后分批存入。实测下来,5-10轮对话为一个单元存储,记忆提取的准确度最高。

3. threshold调优

默认不设threshold会返回所有匹配结果,有些相关度很低的也会混进来。建议从0.7开始调,根据业务场景微调。宁可漏掉一些不太相关的,也不要给LLM塞太多噪音。

4. 冷启动问题

新用户没有任何记忆的时候,profile返回空的。这时候不要硬塞一个空的”用户背景”到prompt里,直接跳过记忆注入,否则LLM会觉得奇怪。

适合什么场景

适合用的:

  • 需要跨会话记忆的聊天产品(客服、AI助手、陪伴类)
  • Agent框架需要长期记忆能力
  • 企业知识库 + AI问答
  • 需要用户画像但不想自己维护的

不太需要的:

  • 一次性问答场景(搜索、翻译)
  • 对数据安全要求极高、不能用第三方服务的
  • 对话很短、不需要跨会话上下文的

跟其他方案的定位对比

方案 定位 适合
Supermemory 记忆即服务,全托管 快速接入,不想自建基础设施
Mem0 开源记忆框架 需要自部署、深度定制
LangChain Memory 框架内置模块 已经在用LangChain的项目
自建向量库+RAG 完全自控 有基础设施团队,需要极致灵活

Supermemory的优势在于开箱即用、Benchmark成绩好、不用管向量库和知识图谱的维护。缺点就是依赖第三方服务,数据不在自己手上。

总结一句

AI记忆这个赛道在2026年明显热起来了。从之前只有”把对话塞向量库”一个路径,到现在有专门的记忆引擎处理知识图谱、矛盾消解、时间线管理,工具链在变得成熟。Supermemory目前做得最完整,SDK也够简洁,适合快速验证”给AI加记忆”这件事到底值不值得做。

项目地址:github.com/supermemoryai/supermemory