Codex与DeepSeek harness记忆系统

记忆系统，从命名的角度来理解，“记忆”就是如何“记”下，如何回”忆”，以及如何遗忘。

以下是我对Codex以及DeepSeek harness记忆系统的一些理解，若有不对，望指正。

Codex 的思路更像“记忆编译器”：把历史 Session 自动提炼成可复用知识，再分层检索。

DeepSeek Harness 的思路更像“记忆基础设施/操作系统”：先把 Session、持久化、压缩、检索、指令注入都做成独立插件能力，至于“什么值得记住、如何长期整理”交给插件。

而且这里有个非常重要的时间点：截至 2026 年 9 月，Codex 已经有原生的跨 Session Memories Pipeline；DeepSeek Harness 官方本体还没有同等级的自动长期记忆整理器。DeepSeek 社区这几天已经出现dsh-memory等插件补这一层。

一、先把“记忆”这个词拆开

很多 Agent 项目一说 Memory，就直接：

历史聊天 ↓ Embedding ↓ Vector DB ↓ TopK ↓ 塞 Prompt

其实这是把至少4 种完全不同的东西混到了一起。

可以分为：

① Working Memory 当前上下文窗口 ↓ ② Episodic Memory 过去某次 Session 发生过什么 ↓ ③ Semantic / Procedural Memory 从很多 Session 中总结出来的规律、经验、工作流 ↓ ④ Instruction / Policy Memory 用户明确规定“以后必须怎么做”

举例：

用户：这个项目 Python 环境是 .conda

如果只是今天这次会话知道：

→ Working Memory

如果历史 Session 里曾经讨论过：

→ Episodic Memory

如果系统总结成：

这个仓库默认使用.conda，执行测试前先确认环境。

→ Semantic/Procedural Memory

如果用户明确写：

AGENTS.md: 任何修改前必须运行 pytest。

→ Instruction / Policy

Codex 和 DeepSeek Harness 最值得学习的地方，就是都没有简单把这些东西混成一个“memory vector database”。

二、Codex：核心思想是“把历史经验编译成知识”

现在 Codex GitHub 里已经有一个非常完整的：

codex-rs/memories/

架构明确分为：

read/ write/

也就是：

Memory Write Path 和 Memory Read Path 分离。

(GitHub)

整个流程可以理解成：

历史 Rollout / Session │ ▼ ┌─────────────────────┐ │ Phase 1 │ │ Session Extraction │ │ 每个会话单独提炼 │ └─────────┬───────────┘ │ ▼ raw_memory rollout_summary rollout_slug │ ▼ SQLite │ ▼ ┌─────────────────────┐ │ Phase 2 │ │ Global Consolidation│ │ 跨 Session 整理 │ └─────────┬───────────┘ │ ▼ ~/.codex/memories/ │ ├── memory_summary.md ├── MEMORY.md ├── skills/ └── rollout_summaries/

这其实非常漂亮。

三、Codex Phase 1：不是“总结聊天”，而是“提取未来有价值的信息”

Codex 的第一阶段会扫描近期符合条件的 rollout，然后单独交给模型分析。

输出结构明确包括：

{ "raw_memory": "...", "rollout_summary": "...", "rollout_slug": "..." }

同时会：

• 限制每次启动处理多少 Session；

• 多 Session 并发提取；

• DB lease 防止多个 worker 重复工作；

• 失败有 backoff；

• 对生成的记忆做 secret redaction。(GitHub)

最值得注意的是它对“什么值得记”的定义。

Codex 的 Memory Writer 明确强调：

高价值记忆不是“有用的信息都存下来”，而是应该改变未来 Agent 默认行为的信息。

典型包括：

• 稳定的用户偏好；

• 反复被用户纠正的地方；

• 高价值的排障经验；

• 能显著减少未来探索成本的路径/命令；

• 某项目真实信息存在哪里；

• 什么信号出现时应该切换策略。

而且它提出一个很有意思的目标：

Optimize for future user time saved, not just future agent time saved.

也就是说，不是：

“Agent 下次能少调用两个工具就存。”

而是：

“这条信息以后能不能让用户少解释一次、少纠正一次、少重新排查一次？”

(GitHub)

这个设计我认为非常值得做 Agent 的人学习。

四、Codex Phase 2：Memory 不是追加日志，而是“持续重构的知识库”

这是 Codex Memory 最值得学习的地方。

很多人的长期记忆是：

memory.md - 用户喜欢 Python - 用户喜欢 pytest - 用户项目是 xxx - 今天发现 xxx - 明天发现 xxx - 后天发现 xxx ...

最终一定会变成垃圾场。

Codex 不这样做。

它有第二阶段：

Global Consolidation

把第一阶段提取出来的大量原始记忆再次整理。

并且不是简单 append，而是：

ADD UPDATE MERGE DELETE

它甚至把：

~/.codex/memories/

本身做成一个Git-backed workspace。

每次 consolidation 前产生：

phase2_workspace_diff.md

让整理 Agent 看：

+ 新出现的信息 - 已经消失的信息 ~ 被修改的信息

然后增量维护：

MEMORY.md memory_summary.md skills/

(GitHub)

所以它本质上不是：

Chat → Summary

而是：

Chat → Evidence → Candidate Memory → Consolidated Knowledge

这和数据库思想非常像。

五、Codex 的“遗忘”设计也很重要

Memory 最大的问题从来都不是：

怎么记住？

而是：

怎么不记错？怎么删掉过期信息？

例如：

以前：

Python 3.11

后来项目升级：

Python 3.12

最差的 Memory 系统会变成：

Python 3.11 Python 3.12

以后模型随机信一个。

Codex Phase 2 会根据新的 evidence 和 workspace diff 对旧 Memory：

删除 重写 合并 降级

它选取 Phase-1 Memory 时还会考虑：

usage_count last_usage generated_at max_unused_days

也就是：

高频 + 最近被使用 ↓ 优先参与 Consolidation 长期没人使用 ↓ 逐渐退出 active memory

(GitHub)

这已经很像“记忆代谢”了。

六、Codex Read Path：最聪明的是“渐进式披露”

如果积累半年 Memory：

100 KB 500 KB 10 MB

难道每次全部塞 Prompt？

显然不行。

所以 Codex 做的是：

小、密集 memory_summary.md │ ▼ MEMORY.md │ ┌───────┴────────┐ ▼ ▼ skills/ rollout_summaries/ │ ▼ 原始证据

这是一个general → specific的结构。(GitHub)

其中：

L0：memory_summary.md

非常短。

作用：

路由。

不是把所有细节告诉 Agent，而是：

这个项目以前做过什么？ 有哪些主题？ 去哪里找？

它会被放进请求上下文。

L1：MEMORY.md

相当于：

长期记忆 handbook / searchable registry

Agent 根据关键词去搜索。

L2：skills/

如果某个历史经验已经形成稳定流程：

如何执行 release 如何排查某类 bug 如何跑特定测试

就可以提升成：

SKILL.md scripts/ examples/ templates/

这一步特别有意思：

记忆可以从“事实”晋升为“能力”。

L3：rollout_summaries

如果 Agent 需要：

当时到底发生了什么？ 具体错误是什么？ 为什么做那个决定？

才继续进入历史 Session summary。

所以一次普通任务不是：

读取所有记忆

而是：

memory_summary ↓ 发现相关主题 ↓ grep MEMORY.md ↓ 必要才打开 1~2 个详细文件

Codex 甚至明确建议：

memory quick pass 最好控制在大约 4–6 次搜索操作内。

(GitHub)

这就是典型的：

Progressive Disclosure

和 RAG 非常像。

七、所以 Codex Memory 本质上很像一个“分层 Cache + RAG”

可以把你以前学的 RAG 串起来。

传统 RAG

Query ↓ Embedding ↓ Vector DB ↓ TopK chunks ↓ LLM

Codex Memory 更像：

Query ↓ Memory Summary 判断有没有相关历史 ↓ Keyword / 文件导航 ↓ MEMORY.md ↓ 需要的话继续进入 Rollout / Skill ↓ LLM

你会发现：

它没有把“向量数据库”当成长期 Memory 的核心。

因为对于 coding agent 来说：

文件名 项目路径 函数名 错误码 命令 模块名

本身就是非常好的 discriminator。

因此：

Markdown + filesystem + grep/search + structured index

已经能解决大量 Memory Retrieval。

这也是一个很好的反面思考：

Memory ≠ 一定需要 Vector DB。

八、还有一个非常关键的设计：AGENTS.md ≠ Memory

这个经常容易混淆。

Codex 同时存在：

AGENTS.md

以及：

MEMORY.md

两者地位完全不同。

AGENTS.md

属于：

authoritative instruction

即：

用户/项目明确规定应该怎么做。

Codex 会从 repo root → cwd 逐层读取 AGENTS.md，越具体的目录规则作用范围越具体。(GitHub)

例如：

AGENTS.md - 所有 API 必须有 pytest - 不允许修改 migrations/ - Python 必须使用 3.12

这是：

Policy。

MEMORY.md

则是：

learned knowledge

例如：

上次发现运行 integration test 需要先启动 Redis。 某个 timeout 问题最终根因是连接池耗尽。

这是：

Experience。

所以正确关系是：

System / Developer ↓ User Task ↓ AGENTS.md authoritative rules ↓ Memory historical experience ↓ raw history

Memory 不应该偷偷提升成 Policy。

这是一个很成熟的设计思想。

九、DeepSeek Harness 则走了另一条路

DeepSeek Harness 的核心 slogan 就是：

Everything is a Plugin.

官方 architecture 明确说：

模型 adapter、tool registry、session log、agent loop 本身都是插件。

没有一个“神圣不可替换的核心模块”。

(GitHub)

所以它处理 Memory 的思维不是：

“我给你做一个完整 Memory 产品。”

而是先建立这些 primitive：

Session Persistence Compaction Session Query Session Reference Agent Instructions Storage

然后让 Memory 成为这些能力的组合。

十、DeepSeek Harness 第一块：Event-Sourced Session

这是我觉得 DSH 最漂亮的设计之一。

它规定：

Session = append-only SessionEvent log

Session 是整个历史唯一 Source of Truth。

不是维护：

messages[] session_history[] summaries[]

几份互相可能不一致的数据。

而是：

SessionEvent Log │ ├── user/message ├── assistant/message ├── tool/call ├── tool/result ├── turn/start ├── turn/end ... ↓ deriveMessages() ↓ 真正给模型看的 history

官方文档明确：

LLM message history 是从事件日志派生出来的，而不是单独保存一份。

(GitHub)

这个思想叫：

Event Sourcing

十一、这可以直接和数据库 WAL 串起来

假设：

发生一次 Tool Call

传统实现：

messages.push(...) database.update(...) summary.update(...)

三个地方都有状态。

一旦 crash：

messages 更新了 DB 没更新 summary 更新了一半

麻烦了。

Event Sourcing 则：

append: ToolCallEvent ToolResultEvent

其他东西全部：

Event Log ↓ Projection

重新计算。

就像数据库：

WAL ↓ Table State ↓ Index

所以 DSH 的 Session 很适合做长期 Memory 的原始证据层。

十二、DeepSeek 第二块：Persistence 与 Session 分离

Session 本身负责：

“发生了什么”

Persistence 负责：

“怎么把它保存下来”

官方提供：

session-persistence session-persistence-jsonl session-persistence-sqlite

(GitHub)

因此：

Session semantics │ ▼ Persistence seam ┌──┴───┐ ▼ ▼ JSONL SQLite

这和你设计 Tool abstraction / LLM provider abstraction 一模一样：

业务语义与存储介质解耦。

十三、DeepSeek 第三块：Compaction 不是 Memory，而是 Context Management

DSH 还专门把：

compaction

拆成独立 capability。

它的行为：

旧 Conversation History │ ▼ Summary + 最近几轮原文

但是有个非常关键的细节：

Compaction 结果本身也写回 Session log。

这样：

Replay Session

仍然能够知道：

什么时候 compact compact 了哪些 events 产生了什么 summary

而不是偷偷修改历史。

(GitHub)

这又体现 Event Sourcing 思想：

原始事实不可偷偷消失，压缩只是新的事件/Projection。

十四、DeepSeek 第四块：Session Query = 给历史建立检索层

有了很多 Session 后，不能：

每次扫描全部 JSONL。

因此 Harness 有：

session-query session-query-sqlite tool-session-query

提供：

• Session 列表；

• exact read；

• filters；

• relationship tracing；

• SQLite Full-Text Search；

• 模型可调用的 Session Query Tool。

(GitHub)

于是形成：

Session Log │ ┌───────────┴───────────┐ ▼ ▼ Persistence Session Query JSONL/SQLite │ ▼ Agent Search

你会发现：

这已经把一个 Memory 系统需要的“原始历史 + 持久化 + 检索”全部准备好了。

只是还没有决定：

哪些历史应该自动升格成长期知识。

十五、DeepSeek 的 AGENTS 体系也比一般项目更强调“Scope”

DeepSeek Harness 官方有：

agent-instructions

支持：

$DSH_HOME/AGENTS.md repo/ ├── AGENTS.md ├── src/ │ └── AGENTS.md └── ...

甚至兼容：

CLAUDE.md AGENTS.local.md CLAUDE.local.md

(GitHub)

而且这里有个挺高级的细节。

DSH 把这些 workspace instructions：

作为 durable user-role context 写进 Session history。

所以它们：

persist replay compact

都会跟着 Session。

(GitHub)

这和单纯每次：

system_prompt += AGENTS

完全不一样。

因为后者你事后无法确定：

当时那个 Agent 到底看到了哪个版本的 AGENTS.md？

而 DSH durable history 可以复盘。

对于生产 Agent，这一点很重要。

十六、那 DeepSeek Harness 为什么目前没有直接做 Codex 那样的 Memory？

从它整体架构其实很好理解：

DeepSeek Harness 更强调：

mechanism ≠ policy

Harness 提供 mechanism：

Session Storage Query Compaction Instruction injection Plugin system

但是：

什么值得记？ 什么时候整理？ 如何忘记？ 用 Markdown？ SQLite？ Vector DB？ Graph？ Global 还是 Workspace？

这些属于：

Memory Policy

不应该强绑定进 Agent Loop。

截至 9 月初，官方 Discussions 里甚至有人专门提出：

DSH 当前并不会原生自动加载memory//MEMORY.md。

现在原生会自动处理的是 instruction chain 和 Skills，而跨 Session Memory 仍主要由插件实现。(GitHub)

十七、这几天出现的 dsh-memory 正好验证了这个架构

9 月 4 日 DeepSeek Harness Discussions 里有社区项目：

dsh-memory

明确标注：

unofficial community project。

设计目标是：

Claude Code + Codex

它借鉴：

Claude Code

Markdown memory + progressive disclosure

Codex

session consolidation

最后形成：

Global MEMORY + Workspace MEMORY + 详细 Markdown

并且不要求单独的 Vector DB。(GitHub)

这其实说明 DeepSeek Harness 的路线：

官方 Harness 提供 Memory 的“乐高积木”，社区负责组装不同 Memory 产品。

十八、把 Codex 和 DeepSeek Harness 放一起，就非常清楚了

十九、用一个特别容易记住的比喻

如果把人的大脑类比成电脑：

Codex

更像已经帮你装好了：

记忆管理软件

它会：

昨天发生了什么 ↓ 提取经验 ↓ 整理笔记 ↓ 合并重复 ↓ 删除过期 ↓ 建立索引 ↓ 今天需要的时候按需找

所以：

Codex = Memory Compiler。

DeepSeek Harness

更像给你提供：

硬盘 文件系统 数据库 搜索引擎 日志系统 缓存 Plugin API

但是没有强迫你使用一种“记忆软件”。

所以：

DeepSeek Harness = Memory Operating System / Memory Infrastructure。

二十、这两套设计里，我认为最值得吸收到 Agent 项目里的 7 条原则

如果以后自己设计 Production Agent Memory，我不建议：

所有聊天 → embedding → Milvus

而更建议：

┌──────────────┐ │ Explicit Rule│ │ AGENTS/Policy│ └──────┬───────┘ │ User ↔ Agent │ │ │ ▼ ▼ ┌────────────────────────────────┐ │ Append-only Session │ │ User / Assistant / Tool/Evidence│ └───────────────┬────────────────┘ │ ┌───────┴─────────┐ ▼ ▼ Compaction Async Memory Extractor │ ▼ Candidate Memories │ ▼ Consolidator │ ┌────────────┼────────────┐ ▼ ▼ ▼ Summary MEMORY Skills │ │ │ └──── Progressive Recall ─┘

核心原则只有 7 条：

1. Session History 和 Long-term Memory 分开。历史是 evidence，Memory 是 interpretation。

2. Instructions 和 Learned Memory 分开。用户明确规定的规则，不能和模型自己总结的经验拥有同等 authority。

3. Write Path 和 Read Path 分开。怎么产生记忆和怎么找记忆，是两个独立问题。

4. 不要同步整理全部 Memory。Codex 把提取/整理放后台，就是为了不阻塞主 Agent。

5. Progressive Disclosure，而不是全塞上下文。Summary → index → detail → raw evidence。

6. Memory 必须有 provenance 和 forgetting。没有来源、时间、作用域、更新机制的 Memory，时间长了迟早污染 Agent。

7. Raw Evidence 最好 immutable。这一点尤其值得从 DeepSeek Harness 的 Event Sourcing 学。

最后再把这件事和熟悉的 RAG 串起来

你可以这样建立知识体系：

RAG 解决的是： “外部知识很多，当前 Query 应该取哪部分？” Memory 解决的是： “历史交互很多，哪些应该影响未来？” Event Sourcing 解决的是： “过去真实发生过什么？” Compaction 解决的是： “当前 Session 太长，怎么压缩上下文？” AGENTS / Policy 解决的是： “不管历史如何，Agent 必须遵守什么？” Skills 解决的是： “已经验证成功的经验，能否升级成可复用能力？”

所以一个成熟 Agent 最终其实不是只有一个 Memory 模块，而是：

Evidence ↓ Session ↓ Memory ↓ Knowledge ↓ Skill

Codex 最有价值的是“经验如何逐层蒸馏成能力”；DeepSeek Harness 最有价值的是“原始事实、派生状态、存储、检索、压缩之间如何彻底解耦”。

源码入口可以直接看这几个：

Codex Memories Pipelinehttps://github.com/openai/codex/tree/main/codex-rs/memories?utm_source=chatgpt.com
Codex Memory Consolidation Prompthttps://github.com/openai/codex/blob/main/codex-rs/memories/write/templates/memories/consolidation.md?utm_source=chatgpt.com
DeepSeek Harnesshttps://github.com/deepseek-ai/deepseek-harness?utm_source=chatgpt.com
DeepSeek Harness Session Architecturehttps://github.com/deepseek-ai/deepseek-harness/blob/master/docs/subsystems/session.md?utm_source=chatgpt.com
DeepSeek Harness Agent Instructionshttps://github.com/deepseek-ai/deepseek-harness/tree/master/packages/context/agent-instructions?utm_source=chatgpt.com