Codex与DeepSeek harness记忆系统

记忆系统从命名的角度来理解“记忆”就是如何“记”下如何回”忆”以及如何遗忘。以下是我对Codex以及DeepSeek harness记忆系统的一些理解若有不对望指正。Codex 的思路更像“记忆编译器”把历史 Session 自动提炼成可复用知识再分层检索。DeepSeek Harness 的思路更像“记忆基础设施/操作系统”先把 Session、持久化、压缩、检索、指令注入都做成独立插件能力至于“什么值得记住、如何长期整理”交给插件。而且这里有个非常重要的时间点截至 2026 年 9 月Codex 已经有原生的跨 Session Memories PipelineDeepSeek 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 / PolicyCodex 和 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 2Memory 不是追加日志而是“持续重构的知识库”这是 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最聪明的是“渐进式披露”如果积累半年 Memory100 KB 500 KB 10 MB难道每次全部塞 Prompt显然不行。所以 Codex 做的是小、密集 memory_summary.md │ ▼ MEMORY.md │ ┌───────┴────────┐ ▼ ▼ skills/ rollout_summaries/ │ ▼ 原始证据这是一个general → specific的结构。(GitHub)其中L0memory_summary.md非常短。作用路由。不是把所有细节告诉 Agent而是这个项目以前做过什么 有哪些主题 去哪里找它会被放进请求上下文。L1MEMORY.md相当于长期记忆 handbook / searchable registryAgent 根据关键词去搜索。L2skills/如果某个历史经验已经形成稳定流程如何执行 release 如何排查某类 bug 如何跑特定测试就可以提升成SKILL.md scripts/ examples/ templates/这一步特别有意思记忆可以从“事实”晋升为“能力”。L3rollout_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 串起来。传统 RAGQuery ↓ Embedding ↓ Vector DB ↓ TopK chunks ↓ LLMCodex 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 historyMemory 不应该偷偷提升成 Policy。这是一个很成熟的设计思想。九、DeepSeek Harness 则走了另一条路DeepSeek Harness 的核心 slogan 就是Everything is a Plugin.官方 architecture 明确说模型 adapter、tool registry、session log、agent loop 本身都是插件。没有一个“神圣不可替换的核心模块”。(GitHub)所以它处理 Memory 的思维不是“我给你做一个完整 Memory 产品。”而是先建立这些 primitiveSession Persistence Compaction Session Query Session Reference Agent Instructions Storage然后让 Memory 成为这些能力的组合。十、DeepSeek Harness 第一块Event-Sourced Session这是我觉得 DSH 最漂亮的设计之一。它规定Session append-only SessionEvent logSession 是整个历史唯一 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(...)三个地方都有状态。一旦 crashmessages 更新了 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 ManagementDSH 还专门把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 readfiltersrelationship tracingSQLite 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 ≠ policyHarness 提供 mechanismSession 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 CodeMarkdown memory progressive disclosureCodexsession consolidation最后形成Global MEMORY Workspace MEMORY 详细 Markdown并且不要求单独的 Vector DB。(GitHub)这其实说明 DeepSeek Harness 的路线官方 Harness 提供 Memory 的“乐高积木”社区负责组装不同 Memory 产品。十八、把 Codex 和 DeepSeek Harness 放一起就非常清楚了维度CodexDeepSeek Harness核心思想自动把历史经验提炼成长期知识提供可组合 Memory primitivesSessionRollout/historyEvent-sourced Session长期 Memory官方原生支持当前主要靠插件Memory extractionPhase 1 自动提取Memory 插件自行决定ConsolidationPhase 2 自动整理Memory 插件自行决定原始证据rolloutappend-only Session events检索MEMORY summary rolloutsession-query / FTS / pluginsContext 压缩有 compaction独立 compaction seamInstructionsAGENTS.mdAGENTS/CLAUDE/local overlaysMemory storageDB Markdown Git workspace可插拔 JSONL/SQLite/storage/plugin遗忘usage/recency diff cleanup由 Memory plugin 决定Progressive disclosure原生 Memory Read PathHarness 提供实现它的能力哲学opinionated Memory productunopinionated Memory platform十九、用一个特别容易记住的比喻如果把人的大脑类比成电脑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 条Session History 和 Long-term Memory 分开。历史是 evidenceMemory 是 interpretation。Instructions 和 Learned Memory 分开。用户明确规定的规则不能和模型自己总结的经验拥有同等 authority。Write Path 和 Read Path 分开。怎么产生记忆和怎么找记忆是两个独立问题。不要同步整理全部 Memory。Codex 把提取/整理放后台就是为了不阻塞主 Agent。Progressive Disclosure而不是全塞上下文。Summary → index → detail → raw evidence。Memory 必须有 provenance 和 forgetting。没有来源、时间、作用域、更新机制的 Memory时间长了迟早污染 Agent。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 ↓ SkillCodex 最有价值的是“经验如何逐层蒸馏成能力”DeepSeek Harness 最有价值的是“原始事实、派生状态、存储、检索、压缩之间如何彻底解耦”。源码入口可以直接看这几个Codex Memories Pipelinehttps://github.com/openai/codex/tree/main/codex-rs/memories?utm_sourcechatgpt.comCodex Memory Consolidation Prompthttps://github.com/openai/codex/blob/main/codex-rs/memories/write/templates/memories/consolidation.md?utm_sourcechatgpt.comDeepSeek Harnesshttps://github.com/deepseek-ai/deepseek-harness?utm_sourcechatgpt.comDeepSeek Harness Session Architecturehttps://github.com/deepseek-ai/deepseek-harness/blob/master/docs/subsystems/session.md?utm_sourcechatgpt.comDeepSeek Harness Agent Instructionshttps://github.com/deepseek-ai/deepseek-harness/tree/master/packages/context/agent-instructions?utm_sourcechatgpt.com