问题所在
您正在做一款 AI 产品——副驾助手、客服机器人、陪伴类应用。用户理所当然地期待它记得自己,但要自建记忆层就意味着向量数据库、提取管道、去重和冲突处理:好几个月的基础设施投入,而这些并不是您的产品本身。MemoryLake 带来的改变
MemoryLake 就是您的记忆后端。两种接入方式,共享同一个记忆池:
两者写入同一个池:通过 Router 沉淀的记忆可以用 API 搜索到,反之亦然。在中国站请从下面的路径 B(REST API)开始——路径 A 保留在此供您了解与提前设计。
路径 A:Memory Router——改一行 base URL 就有记忆
为每个用户创建一个 Boundary(它把工作空间 + 项目 + Actor 绑定成单一的作用域 id),然后让请求经由网关转发:Memory Router 在 MemoryLake 中国站暂未开放——上面的端点在中国站当前无法调用,如需使用请联系商务了解开放计划。下方的 REST API 路径在中国站已正式可用。
路径 B:REST API——显式的记忆操作
先设计好您的多租户模型——每个租户一个工作空间,每个终端用户一个 Actor,每个知识领域一个项目——再按您自己的业务流程灌入并查询记忆:- 文档:把文件上传到文件库,导入项目,并与事实一并搜索其内容
- 每用户记忆:Actor 事实会跨项目跟随用户,您无需重建身份关联的那套管道
- 溯源:清楚看到一条记忆的来源——面向用户的”你怎么知道这个?“有据可查
- 冲突:以编程方式列出并消解相互矛盾的记忆,而不是继续输出过时的事实
- 遗忘:硬删除一条事实——直接满足 GDPR”被遗忘权”的处理要求
顺带解决模型,无需自建厂商账号
无论选择哪条路径,都可以搭配 Model Router:一个 OpenAI 兼容端点(https://app.memorylake.cn/v1)覆盖主流模型,配额管控、日志与故障转移一应俱全——用的还是您手上那个 sk-… Key。
生产环境设计要点
- 始终按用户划分作用域:每个用户一个 boundary(Router)或一个项目(API),从结构上排除跨用户记忆泄漏。
- 有选择地召回:检索本身已按作用域限定并做了排序,但提示词预算由您掌握——取排名靠前的结果,而不是全部。
- 把记忆呈现给用户:“我对你的了解”(列表 + 溯源)与”忘掉这条”(删除)都应可见可操作。这既建立信任,也简化合规。
- 处理冲突:主动轮询或人工审阅冲突记忆,让您的应用永远不会对同一个用户断言两条互相矛盾的事实。
深入了解
Memory Router
网关架构、BYOK、Boundary 与可观测性。
API 参考
全部端点:项目、文档、记忆、搜索、冲突。