Supermemory：让用户资料与相关记忆一起进入 AI 应用的上下文

给 AI 应用加上历史记录搜索，还没有完全解决“下一次对话记得用户”的问题。用户偏好短回答、习惯某种语言示例，这些信息可能与今天的问题毫不相似。Supermemory 值得开发者认识的地方，是在按问题检索之外，维护一份可以主动带入对话的用户资料。

你把对话或文档交给它，得到可检索的内容、抽取的记忆和持续更新的资料，再由业务代码将所需上下文交给回答模型。本文依据官方资料介绍这个成熟工具；下文的中文情境用于解释接入方式，未运行服务或评测记忆准确率。

有些事实，不该等搜索碰巧命中

设想一个开发助手：用户早先说过“代码示例用 Python，解释尽量简短”，后来开始讨论数据库迁移。搜索“数据库迁移”时，技术记录很重要，但输出偏好也应在回答前被看见。这两类信息进入上下文的理由不同。

Supermemory 的用户资料文档把资料分为 static 与 dynamic：前者保存较稳定的背景和偏好，后者保存近期活动与临时状态。资料属于对应的 namespace，可以围绕用户、项目等对象组织。应用可以把资料作为回答的基础背景，再搜索与本次问题相关的具体记忆。

这是我会考虑采用它的主要理由：把“这个用户是谁、最近在做什么”与“这道问题需要哪段材料”同时交给应用处理。对于跨会话助手，前者不必每次都依赖一次语义相近的搜索来发现；对于一次性文档问答，这部分能力的价值则小得多。

写入对话之后，真正发生了什么

官方快速入门从一段完整对话开始，以稳定的文档 ID 和 namespace 写入，再加入用于知识检索的文档。服务对输入进行索引、抽取事实并维护资料。资料和搜索负责交付上下文，业务应用仍负责调用回答模型，并决定带入哪些信息。

有一个接入细节比“自动记忆”四个字更影响使用：写入返回 queued，不表示资料已经更新。文档处理与记忆生成有各自的状态；文档可搜索之后，记忆抽取仍可能在等待批处理。如果马上读取资料却为空，不能据此判断写入丢失。

默认的 dynamic 处理模式会将相关内容合批。需要立即推进这条流程时，可以选择 instant，但它仍是异步处理，而且官方说明每个文档会多计一次操作。实际接入应等待相应处理状态完成，而不是在 add 返回后立刻假设资料已就绪。这是采用时需要纳入交互流程与用量预算的条件。

v5 中，资料与搜索分开取

本次核对的 Python SDK 5.0.1面向 v5 API，要求 Python >=3.10。它采用 namespace 优先的调用方式：client.profile(namespace) 读取资料，client.search(namespace, query=...) 搜索本次问题需要的内容。

当前资料文档明确说明，v5 的 profile 调用不带搜索问题。如果两种上下文都需要，应分别调用；不要混用旧版 containerTag 与合并查询示例。对已有 RAG 应用来说，可以保留现有文档回答流程，把资料插入模型调用之前，让输出偏好与近期任务有一个明确的进入位置。

实际入口是开发者控制台：创建 API Key，固定所选 SDK 版本，按官网快速入门写入内容并等待处理完成，再读取资料与搜索结果。云端调用需要账户与相应服务用量，不能把 SDK 安装成功当成服务已免费可用。

选择托管 API 时，也看清本地版是什么

Supermemory 还有可下载的本地服务器，本次核对的正式 Release 为 server-v0.0.9，发布说明包含 v5 API 支持。它与 SDK 的版本号属于两条线，不能混为同一个版本。

不过，“可自托管”并不等于引擎开源。官方本地版说明明确写到服务器源码不在公开仓库，本地二进制受 lite 许可约束，免费范围有 10,000 个已存文档的上限。即使用本地模型处理文本，首次嵌入模型下载及网页摄取仍有各自联网条件；网页入口使用 Firecrawl，并需要对应凭据。

因此，本篇将它归为工具。公开代码与 SDK 的许可不能扩大解释为整个平台开源。希望把跨会话个性化交给专门记忆服务、愿意接受其处理流程和账户条件的开发者，可以继续看这条路线；需要审计和修改完整服务端源码，或只做一次性资料检索的团队，应优先考虑其他方案。