都会把“可见上下文”和“底层存储”分开
模型这一轮看见的材料，通常只是系统存储内容的一小部分、重算后的视图。
- claude code 的 /context 是 API 视图
- codex 用 clone_history().for_prompt()
- letta 用 ContextWindowCalculator 重算窗口
01
共同模式图
虽然名字不同，但大多数系统都在围绕“可见上下文”“短期压缩”“长期记忆”“存储后端”四层转。
共同模式图
先把“看见什么”“压什么”“记住什么”“存到哪”四件事拆开，你看 6 个项目时就不会混。
固定说明
系统提示、人格、规则、工具约束。
当前输入
这一轮用户消息、工具结果、任务状态。
短期压缩
把过长历史压短，保证窗口装得下。
长期记忆
把值得保留的东西存成可召回结果。
检索回注
下一轮需要时再找回来。
持久化后端
文件、数据库、向量库、Git 或 provider backend。
02
反复出现的 5 个规律
这 5 条不是教条，而是从当前 6 个项目里反复能看到的设计倾向。
短期历史和长期记忆通常不是一回事
history 更像记录和压缩底稿，long-term memory 才是跨轮次、跨会话还会被召回的东西。
- codex 把 history.jsonl 和 memories/ 分开
- mem0 的 SQLite messages 不是主记忆
- langmem 的 running_summary 不是长期记忆
summary / compaction 经常是单独的一条链
很多项目都需要压缩，但压缩本身未必会生成长期记忆，它更多是控制窗口大小。
- claude code 的 compact boundary
- hermes-agent 的 ContextCompressor
- letta 的 Summarizer
长期记忆落点高度多样
文件、SQLite、Postgres、向量库、Git repo、BaseStore 都可能是记忆落点，所以不能只看名字猜实现。
- claude code 用文件型 memory
- letta 有 Git-backed memory
- mem0 以向量库为主记忆体
多 agent 会放大边界问题
一旦有 subagent、provider、group conversation 或 thread spawn，谁能看谁的记忆、谁负责回写就会变复杂。
- codex 的 thread_spawn_edges
- hermes-agent 的 provider 并行层
- letta 的 conversation / archive / git 并行路径