会话记忆与持久记忆：架构指南
如果您正在设计一个 AI 系统，问题不在于您是否需要记忆，而在于需要哪种类型的记忆。会话记忆和持久记忆服务于不同的目的，操作于不同的层次，并需要不同的基础设施。本页面清晰地解释了这两者。
记忆问题
许多 AI 应用仅使用会话记忆——当前对话的上下文窗口。这适用于一次性查询，但每当用户返回时期待连续性、代理恢复长任务或系统需要应用之前运行的经验时，它都会失败。会话记忆提供的内容与生产应用实际需要之间的差距就是持久记忆存在的地方。
MemoryLake 的不同之处
持久记忆可以在会话之间无限期存活
—MemoryLake 将记忆存储在模型外部，并按需检索。没有过期，没有上下文窗口限制，关闭会话时不会重置。记忆在数天、数月和数年中累积。
针对不同持久性需求的类型分类
—并非所有持久记忆都是相同的。MemoryLake 区分背景（静态身份）、事实（版本化声明）、事件（时间线）、对话（会话历史）、反思（行为模式）和技能（可重用工作流）。每种类型都有适当的存储语义。
毫秒级检索，准确率为 94.03%
—持久记忆只有在正确的时间检索到正确的信息时才有用。MemoryLake 的 #1 LoCoMo 基准结果意味着系统可靠地呈现相关记忆，而不仅仅是最近的记忆。
永久免费 · 无需信用卡
工作原理
- 连接——通过 REST API、Python SDK 或 MCP 将 MemoryLake 集成到您的 AI 应用中。会话记忆继续在模型的上下文窗口内运行。
- 结构——在会话结束时（或在重要事件期间），将相关信息写入适当的 MemoryLake 记忆类型。会话结束；记忆不会。
- 重用——在下一个会话开始时，检索相关的持久记忆，并选择性地注入到上下文中。模型以累积的知识开始，而不是空白状态。
会话记忆与持久记忆
| Characteristic | Session Memory | Persistent Memory (MemoryLake) |
|---|---|---|
| Lifespan | Ends when the session closes | Survives indefinitely across sessions |
| Storage location | Inside the model's context window | External memory layer, retrieved on demand |
| Capacity | Limited by context window token count | Scales to 1B+ complex documents in production |
| Cross-session access | Not available | Available to any authorized session or agent |
| Structure | Unstructured text in context | Six typed categories with defined semantics |
| Conflict detection | None — latest input wins | Automatic conflict detection and versioning for Facts |
| Retrieval accuracy | N/A (all context is present) | 94.03% LoCoMo benchmark accuracy |
| Cost at scale | Grows with context length per call | Retrieved selectively; context stays lean |
| Compliance and audit | None by default | Versioned, source-attributed, GDPR/SOC 2 compliant |
适用于
此比较对开发者和架构师在设计 AI 记忆基础设施时非常有用——无论是面向用户的产品、内部工具还是代理系统。如果您的应用涉及同一用户或同一代理跨多个会话，持久记忆应包含在您的架构中。
在你自己的账号上跑通这个场景
Brindlewood Payments 的编码 agent 在提示里只保留会话最近 6 步，其余由 MemoryRouter 从 MemoryLake 挂载。过往 6 场会话定下了团队约定；今天早上开发者在前三条消息里改了其中三条（数据库端口、测试命令、评审人），随后 agent 快速执行 22 步任务。同一场会话跑三种写法：会话结束时才写入记忆、每一步发生时就写入、每一步写入且只有在 MemoryLake 已持有后才移出窗口。7 次运行里，会话结束才写的方式在改动滑出窗口后被问到的 28 个问题上全部答了旧值（端口 5433、`make test-ledger`、原评审人）；边说边写答对 20/28，取决于抽取能否赶在窗口滑走之前；记忆持有后才移出窗口答对 28/28，prompt tokens 最多是边说边写的 1.75 倍。
你会看到
- 三条对照各有自己的项目和
boundary；6 场过往会话以会话形式写入，开跑前逐值核对每份记忆里的约定 - 每一步在后台用
conv msg append追加；8 个检查点由memorylake router chat --boundary作答，按 答对 / 旧值 / 没有记录 / 编造 判分 - 每个检查点用
fact list --query显示当时各份记忆里是哪个值；监视器记录每条改动何时说出、何时滑出窗口、何时进入记忆 - 修法是在
conv cook-status报告会话已写入前把这一步留在提示里；facts与ask "<问题>"查看会后的记忆，另有本地 Web 界面
需要: 一个 MemoryLake API key · memorylake CLI · Python 3.9+
运行
git clone https://github.com/memorylake-ai/memorylake-usecases.git cd memorylake-usecases/session-gap-memory export MEMORYLAKE_BASE_URL=https://app.memorylake.cn/openapi/memorylake export MEMORYLAKE_API_KEY=sk-… python3 demo.py # or: python3 web/server.py
看它跑起来 · 真实录制，未剪辑
相关场景
常见问题
会话记忆是否足够？
会话记忆是否足够？
对于单轮应用——一次性查询工具、文档摘要工具、代码格式化工具——会话记忆是足够的。对于任何需要连续性、个性化或累积知识的应用，持久记忆是必要的。
MemoryLake 能否替代上下文窗口？
MemoryLake 能否替代上下文窗口？
不能——而且不应该。会话记忆（上下文窗口）和持久记忆是协同工作的。上下文窗口保存的是立即相关的内容；MemoryLake 保存的是在所有先前会话中学到的内容，并选择性地呈现正确的部分。
MemoryLake 如何决定从持久记忆中呈现什么？
MemoryLake 如何决定从持久记忆中呈现什么？
您通过记忆类型和语义意图查询 MemoryLake。检索层根据与当前会话上下文的相关性对结果进行排名，并返回最适用的记忆项——而不是存储的所有内容的转储。