Claude Code vs Codex 记忆：Head-to-Head

本文是两篇已有精读的对照矩阵，不重写原文。 Claude Code 记忆精读：精读: Claude Code 记忆系统 Codex 记忆精读：精读: Codex 记忆系统

调研元信息

项目	值
调研日期	2026-06-22
涉及研究轴	矩阵（B 轴 Coding Agent 对比）
证据等级	`[已有]` 为主，引用两篇精读

一句话定位

Claude Code 和 Codex 代表了两种截然不同的记忆设计哲学——Claude Code 是索引驱动的实时学习系统（文件系统 + LLM 检索），Codex 是AI 驱动的批量整合系统（SQLite + 隔离 consolidation agent）——两者都实现了”让 Agent 跨 session 学习”的目标，但路径完全不同 [已有]。

12 维对照矩阵

维度	Claude Code	Codex
存储模型	文件系统：MEMORY.md（索引）+ topic.md（正文）	SQLite（Phase1）+ 文件系统（Phase2 产物）
写入时机	每次无工具响应后（持续）	session 启动时回顾历史 rollout（批量）
写入执行	forked agent（共享 prompt cache，fire-and-forget）	Phase1: 并行 worker ≤8（reasoning=Low）；Phase2: 隔离沙箱 agent（reasoning=Medium）
读取路径	双阶段：启动时全量索引 + 每 turn Sonnet sideQuery 选 ≤5 文件	memory_summary.md 全量作为 developer instruction 注入
检索算法	LLM 语义匹配（Sonnet 从 200 候选中选）	无检索（全量注入）
遗忘机制	硬截断 MEMORY.md（200 行 / 25KB）+ staleness 标注	隐式淘汰（30 天未被 citation 引用的记忆在 Phase2 中被淘汰）
项目隔离	是（`~/.claude/projects/<hash>/memory/`）	否（`~/.codex/memories/` 全局共享）
内容分类	四类型：user / feedback / project / reference	结构化 JSON：rollout_summary + raw_memory（含 YAML frontmatter）
整合机制	autoDream（≥24h + ≥5 session，去重+优化）	Phase2 consolidation（全局锁 + 6h 冷却，git diff 增量）
安全设计	多层路径安全（sanitize + realpath + 前缀检查 + settings 排除）	沙箱隔离（无网络 / 无 MCP / 无人工审批）
多模型策略	主模型共享 prompt cache；sideQuery 用 Sonnet	Phase1: reasoning=Low；Phase2: reasoning=Medium；consolidation agent 独立
关键常量	索引 200 行 / 25KB；检索 200 文件 × 30 行；每文件 200 行 / 4KB；session 60KB	Phase1 并行 8；rollout 截断 150k token；Phase2 top-256 输入；citation 正反馈

设计哲学对比

Claude Code：文件索引 + LLM 驱动检索

Claude Code 的核心信念是”让 LLM 自己决定读什么“——MEMORY.md 是一个纯文本索引，实际内容分散在独立的 topic.md 文件中。每次用户提问时，Sonnet 读索引和文件 frontmatter，判断哪些记忆与当前对话相关，然后只注入 ≤5 个最相关的文件。这是一个按需检索的模型——永远只给模型看它”需要”的记忆 [已有]。

优势：精准度高——LLM 的语义理解能力远超向量余弦相似度。记忆量再大，模型每次只看 5 个文件（20KB 以内）。

代价：每 turn 需要额外一次 Sonnet 调用（延迟 1-3s，成本不低）。如果 LLM 判断错误（遗漏了相关记忆），没有回退机制。

Codex：AI Pipeline + 全量注入

Codex 的核心信念是”让 AI 离线整合为一份精华“——Phase2 的 consolidation agent 将所有碎片记忆合并为一份结构化的 memory_summary.md，然后每次 session 启动时全量注入。这是一个预处理的模型——在 session 之间花时间整合，session 内不做检索 [已有]。

优势：session 内零检索延迟——memory_summary.md 直接注入，不需要额外的 LLM 调用。consolidation agent 有足够的时间和上下文来做高质量整合。

代价：全量注入意味着 token 浪费（不相关的记忆也被注入）。Phase2 有 6h 冷却期——新记忆最快 6h 后才能出现在 summary 中。citation 正反馈循环可能导致”马太效应”——常用记忆越来越强化，不常用的被淘汰。

关键差异解读

差异 1：实时 vs 批量

这是最根本的架构差异。Claude Code 的 extractMemories 在每次响应后 fire-and-forget，记忆几乎实时写入。Codex 的 Phase1 在 session 启动时才处理上一次的 rollout，Phase2 还有 6h 冷却——新学到的知识可能要等到下一个 session 甚至更晚才生效。

影响：在长时间的单 session 工作中，Claude Code 的记忆会持续增长；Codex 只有在 session 结束、下次启动时才会”消化”上次的内容。

差异 2：索引 vs 全量

Claude Code 用 LLM 做实时检索（高成本高精度），Codex 用全量注入（零成本低精度）。这反映了一个基本权衡：精准性 vs 成本。

影响：当记忆量很大时，Claude Code 的索引方式更可扩展——200 个候选文件中选 5 个，成本和被选中内容的大小成正比。Codex 的全量注入在记忆量增长后 token 成本线性增加。但 Codex 通过 Phase2 整合来控制 summary 的大小，变相限制了全量注入的成本。

差异 3：项目隔离 vs 全局共享

Claude Code 按项目隔离记忆（~/.claude/projects/<hash>/memory/），不同项目的记忆不会互相干扰。Codex 的 ~/.codex/memories/ 是全局共享的——所有项目的知识混在一起由 Phase2 统一管理。

影响：Claude Code 在切换项目时”完全失忆”（另一个项目的记忆看不到）。Codex 的跨项目知识可以迁移（”上次在项目 A 学到的 TypeScript 技巧在项目 B 也能用”），但也可能混淆（”项目 A 的数据库配置被错误用在项目 B”）。

差异 4：遗忘策略

Claude Code 的遗忘是硬性的——MEMORY.md 超 200 行就截断，截断后加 WARNING。Codex 的遗忘是柔性的——30 天未被 citation 引用的记忆在 Phase2 的 input selection 中自然被淘汰。

影响：Claude Code 的硬截断可能导致重要但不在前 200 行的记忆”突然消失”。Codex 的 citation 驱动淘汰更温和，但依赖 Agent 主动引用记忆——如果模型不知道某条记忆存在（没在 summary 中），它就无法引用，形成”沉默淘汰”。

与 DB-Agent-Memory 的启示

从两者的对比中可以提炼出 DB-Agent-Memory 的潜在改进方向 [推导]：

学习来源	可借鉴的设计	应用于 DB-Agent-Memory
Claude Code	staleness 标注机制	给 L1/L2 事实加 mtime + 过期警告
Claude Code	四类型分类法	在 L1 提取时标注事实类型
Codex	citation 正反馈	记录 L1/L2 被检索引用的次数
Codex	Phase2 隔离沙箱	L2→L3 蒸馏在隔离环境中运行
两者共同	记忆索引/摘要层	MMD 已有（优于两者），可进一步优化

局限性

不重写两篇精读：本文仅做矩阵对比和哲学解读，具体实现细节请参见原文。
某些对比维度为推导：如”延迟影响”“可扩展性分析”未经实测 [推导]。
两者都在快速迭代：本文基于 2026-06-22 的源码/泄露包状态 [源码]。

证据等级汇总

论点	证据等级
Claude Code 记忆架构全部维度	`[已有]` deep-dive-claude-code-memory.md
Codex 记忆架构全部维度	`[已有]` deep-dive-codex-memory.md
设计哲学对比和差异解读	`[已有]` + `[推导]`
DB-Agent-Memory 改进方向	`[推导]`