Agent 记忆系统四家横评：从便利贴到图书馆，再到什么？

之前写了两篇文章，分别拆了 Hermes Agent 和 OpenClaw 的记忆系统。

发出去之后，有人问我，那 Claude Code 和 Codex 呢？

我当时觉得这两个不是同一个赛道的东西。Hermes 和 OpenClaw 是第三方 Agent 框架，记忆系统是核心卖点。Claude Code 和 Codex 是官方 CLI 工具，记忆只是它们众多能力之一。

但后来我仔细想了想，不对。

恰恰因为它们不是「记忆专用」的系统，它们处理记忆的方式反而更有意思。它们没有像 Hermes 那样把记忆做成一个独立工具，也没有像 OpenClaw 那样给记忆加一套睡眠机制。它们把记忆藏在了更底层的地方——文件系统、会话管理、上下文压缩。

这种「不刻意」的设计，反而更接近软件工程的真实常态。

所以今天把四个系统放在一起聊。前半部分拆 Claude Code 和 Codex 的记忆机制，后半部分做四家横评。

Claude Code：把记忆藏进文件系统的每一层

先说一个我一开始没意识到的事。

Claude Code 没有一个叫「memory」的工具。

准确地说，它后来加了一个，叫 auto memory。但在很长一段时间里，Claude Code 的记忆系统就是——文件。

你打开 Claude Code 开始一个新会话，它做的第一件事不是等你说话，而是读文件。读哪些文件？按照一套非常精巧的层级从上往下扫。

CLAUDE.md 层级注入

这是 Claude Code 记忆系统的地基。

你可以在很多地方放一个叫 CLAUDE.md 的文件，Claude Code 启动时会按固定顺序把它们全读进来：

企业策略文件（macOS 在 /Library/Application Support/ClaudeCode/，Linux 在 /etc/claude-code/）—— 这个是 IT 管的，你改不了
从文件系统根目录往当前目录走，经过的每一层目录如果有一个 CLAUDE.md，都会被加载
每一层的 CLAUDE.local.md —— 个人版本，自动被 gitignore，不会推到远程
全局用户文件 ~/.claude/CLAUDE.md —— 适用于你所有项目的个人偏好
项目规则 .claude/rules/*.md —— 项目级别的行为约束

所有文件拼接，不覆盖。越靠近当前目录的内容越后读，实际优先级越高。

你品品这个设计。

它不是给 AI 一个统一的「记忆仓库」，而是把记忆嵌入到文件系统本身。项目根目录的 CLAUDE.md 是团队共享的「我们这个项目怎么做事情」，.claude/rules/ 里面按主题分文件，「测试规范」「API 设计原则」「Git 提交风格」，每个文件还可以设定只对特定路径生效。CLAUDE.local.md 是你自己的私货，「我喜欢简洁输出，不要废话」，不会污染团队 repo。

这跟 Hermes 的设计哲学完全不同。

Hermes 的记忆是「一个人的便利贴墙」，所有信息贴在同一个地方。Claude Code 的记忆是「一个组织的文档体系」，不同层级、不同角色、不同作用域，各管各的。

而且有一个细节很讲究：CLAUDE.md 里的 HTML 注释会在注入前被自动剥离，帮你省 token。但代码块里的注释保留。这种对 token 开销的精打细算，贯穿了整个 Claude Code 的设计。

Auto Memory：后来加的那块拼图

很长一段时间，Claude Code 的「记忆」就是 CLAUDE.md。你手动写，它读。跟它聊了三天，换了什么偏好、踩了什么坑，它不会自己记。你得自己打开 CLAUDE.md 加一行。

后来它加了 auto memory。

机制是这样的：Claude Code 在跟你的交互过程中，如果判断某个信息「未来可能有用」，会自动把它写进 ~/.claude/projects/<project>/memory/ 目录。这个目录底下有一个 MEMORY.md 当索引，还有按主题分的文件，比如 debugging.md、api-conventions.md。

每次新会话启动，它会把 MEMORY.md 的前 200 行或 25KB（以先到的为准）加载进来。超过的部分不会被加载——需要的时候通过文件工具按需读取。

这个设计让我想到一个比喻。

CLAUDE.md 像是你贴在冰箱上的家庭公约——谁都能看到，内容稳定。Auto memory 像是你床头的日记本——只有你自己看，每天更新，但翻不翻由你。

有一个我特别喜欢的细节：topic 文件不会在启动时加载。只有当 Claude Code 在工作过程中需要某块知识时，才会主动去读。这意味着记忆的加载是按需的，不浪费 context 窗口。

Hermes 是全量装载——会话开始时把 MEMORY.md 整个塞进 prompt。Claude Code 是分层装载——索引开头部分常驻，详细内容按需拉取。后者更省 token，但多了一轮文件读取的开销。

Context Compaction：被压缩的不仅仅是记忆

这才是 Claude Code 记忆系统里最硬核的部分。

每个会话有 200K token 的上下文窗口。听起来很多，但真跑起复杂任务来——读几十个文件、调一堆工具、每个工具返回大段数据——消耗飞快。

Claude Code 的策略是：当 context 用到大约 95% 的时候，自动触发压缩（compaction）。

压缩不是简单的「把前面的删掉」。它做了一件很暴力但也很有道理的事：

把整个对话历史喂给另一个模型调用
让模型生成一份结构化摘要
用这份摘要替换掉原始对话历史

也就是说，你之前跟它聊的所有细节——你问了什么、它答了什么、中间调了哪些工具、文件改了什么——全部被压缩成一段话。零原始消息保留，全部变成摘要。

这种做法的好处是简单粗暴、节省 token。代价也很明显——正在处理中的数据可能被不可逆地丢失。社区里有不少人在 GitHub Issues 里吐槽过这件事。

但 Claude Code 做了一个很聪明的设计来弥补：压缩之后，它会从磁盘重新注入关键内容。

具体来说，压缩后能活下来的东西：

内容	压缩后
System prompt 和 output style	原封不动，本来就不在消息历史里
项目根目录的 CLAUDE.md	从磁盘重新注入
Auto memory（MEMORY.md）	从磁盘重新注入
没有路径限制的 rules	从磁盘重新注入
有路径限制的 rules	丢了，直到再次读匹配路径的文件
子目录的 CLAUDE.md	丢了，直到再次读该子目录的文件
已调用的 skill	重新注入，但每个 skill 上限 5000 token，总共上限 25000 token

你看，CLAUDE.md 和 auto memory 之所以重要，不只是因为它们是「记忆」，更是因为它们是压缩后唯一能被重新注入的东西。它们是 Claude Code 的「种子文件」——压缩把整棵树砍了，但种子还在，能重新长出来。

这也是为什么 Anthropic 官方建议 CLAUDE.md 每个文件控制在 200 行以内。太长了，每次注入都浪费 token；太短了，压缩后恢复不了足够的上下文。

Subagent 的记忆隔离

Claude Code 有一个 Agent 工具，可以派一个 subagent 去干活。

Subagent 的记忆是完全隔离的。

它看不到主 agent 的对话历史。它看不到其他 subagent 在干什么。它只有一个独立的 200K context 窗口，加上你给它的那段任务描述。

干完活之后，只有最终文本结果返回给主 agent。中间所有的文件读取、工具调用、推理过程，全部留在 subagent 的 context 里，不污染主 agent。

这个设计让我想到一个类比。主 agent 是项目经理，subagent 是外包。你给外包一份需求文档，外包干完给你交一份交付物。外包的中间过程——查了什么资料、试了几种方案、踩了哪些坑——你不需要知道，你也管不了。你只要结果。

但 subagent 有一个很特别的地方：它可以有自己的 auto memory。存在 .claude/agent-memory/<name>/ 下面。这意味着同一个 subagent 被多次调用时，它可以积累自己的经验。

Session 持久化

Claude Code 的每一次会话都被完整保存为 JSONL 文件，存在 ~/.claude/projects/<project>/<session-id>.jsonl。每一行是一个 JSON 对象，代表一条消息、一个工具调用或一段元数据。

你可以用 claude --continue 恢复最近的会话，用 claude --resume 打开会话选择器。

但有一个很关键的局限：压缩后丢失的上下文不会因为 resume 而回来。JSONL 里存的是完整的原始对话，但 resume 时 Claude Code 读取的是已经被压缩过的上下文。原始数据在磁盘上，但模型看不到。

就好像你的日记本还在，但你只能看到最后一页的摘要。

Cron 任务的记忆

Claude Code 有一个 CronCreate 工具，可以定时触发任务。

Durable 类型的 cron 会持久化到 .claude/scheduled_tasks.json，重启后自动恢复。但每次触发都是全新的 context——之前的运行状态不会自动传过来。如果需要跨次运行保持状态，只能把信息写到文件里。

这跟 Hermes 的 cron 不同。Hermes 的 cron 任务可以读自己的持久记忆，知道自己上次干了什么。Claude Code 的 cron 每次都是一张白纸，只能靠 CLAUDE.md 和 auto memory 来恢复上下文。

小结：Claude Code 的记忆哲学

Claude Code 的记忆不是一套独立的「记忆系统」。它是一套基于文件系统的记忆约定。

没有专门的记忆数据库，没有向量检索，没有语义搜索。所有的记忆都是 markdown 文件，存储在文件系统的不同层级，按需加载，压缩后重新注入。

这种设计的好处是透明。每一条记忆你都能打开看到、手动编辑、用 git 管理。坏处是粗糙。没有语义检索，没有自动遗忘机制，没有记忆巩固。200 行 MEMORY.md 加载进来就是全量塞进去，用不用得上都占 token。

Anthropic 的工程师显然做了一个取舍：宁可让记忆系统简单透明，也不要做一个复杂但黑盒的记忆引擎。

这种取舍是有道理的。Claude Code 的定位是程序员的本地 CLI 助手，不是长期陪伴的 AI。程序员自己会用 git、会写文档、会做知识管理。Claude Code 只需要帮他们把手头的活干好，不需要帮他们「记住一切」。

Codex：把记忆做进数据库的重量级选手

OpenAI 的 Codex 走了一条完全不同的路。

如果说 Claude Code 的记忆是「藏在文件系统里的暗线」，那 Codex 的记忆就是「明面上的基础设施」。它有一个专门的数据库、专门的 schema、专门的持久化层，甚至专门的身份认证系统。

从源码的体量就能看出来。Claude Code 的记忆系统大概就是几个文件目录加一套加载约定。Codex 光是 thread-store + agent-graph-store + agent-identity 就有十几个 crate。

Thread：一切的基本单元

在 Codex 里，Thread = 一个 AI 会话。但它比「会话」这个词承载的东西多得多。

每个 Thread 有：

独立的 thread_id
独立的 model 和 reasoning_effort
独立的 cwd（工作目录）和 sandbox 策略
独立的 ed25519 密钥对（后面细说）
独立的 JSONL rollout 文件（完整的对话历史）
独立的 SQLite 行（threads 表里的一行）

Thread 由 ThreadManager 管理。配置里有几个关键参数：

1
2
3

agents.max_threads: 6        // 同时存活的 thread 上限
agents.max_depth: 1          // 子 thread spawn 子 thread 的最大深度
agents.job_max_runtime_seconds: ...  // 单个 thread 最大运行时间

默认最多 6 个 thread 同时跑，层级最多 1 层（主 thread 可以 spawn 子 thread，子 thread 不能再 spawn 孙 thread）。

两套 SQLite 数据库

Codex 用了两个独立的 SQLite 数据库来减少锁竞争：

~/.codex/state_5.sqlite —— 主数据库，存 threads、agent graph、goals、memories
~/.codex/logs_1.sqlite —— 日志数据库

两个库都开了 WAL 模式（Write-Ahead Logging），busy timeout 5 秒，连接池最大 5 个连接。

为什么要两个库？因为 Codex 设计为可以多终端同时跑——你在 VS Code 里跑一个 Codex，终端里跑另一个，它们共享同一个 state_5.sqlite。高并发写入下，单库的锁竞争会非常严重。

threads 表的 schema 比较复杂，有二十多个字段。除了常规的 id、创建时间、更新时间，还有一些很有意思的字段：

rollout_path —— 指向 JSONL 文件，存完整对话历史
agent_nickname / agent_role —— agent 的角色标识
agent_path —— 用于查找子 agent 的规范路径
memory_mode —— 记忆模式状态（默认 "enabled"）
git_sha / git_branch / git_origin_url —— 创建时的 git 状态
sandbox_policy / approval_mode —— 沙箱和审批策略
tokens_used —— token 用量计数
archived / archived_at —— 归档状态

这些字段组合在一起，构成了一个 Thread 的完整画像。你可以把它理解成一张超详细的「病历卡」——不只是「这个病人是谁」，还有「他来的时候是什么状态」「用什么方案治的」「治了多久」「花了多少钱」。

Agent Graph Store：Thread 之间的关系图

这是 Codex 记忆系统最有想象力的设计。

每次主 thread spawn 一个子 thread，Codex 在 thread_spawn_edges 表里记一条边：

CREATE TABLE thread_spawn_edges (
    parent_thread_id   TEXT NOT NULL,
    child_thread_id    TEXT NOT NULL PRIMARY KEY,
    status             TEXT NOT NULL  -- "Open" / "Closed"
);

这张表虽然只有三个字段，但它做的事情非常关键——它记录了整个 agent 拓扑图。

哪个 agent spawn 了哪些子 agent？哪些边还是 Open（活跃）的？哪些已经 Closed？全在这张表里。

而且它支持 BFS 遍历。通过递归 CTE（Common Table Expression），你可以从一个根 thread 出发，找到它所有的后代——子、孙、曾孙——一层一层展开。

-- 递归 CTE，BFS 遍历所有后代
WITH RECURSIVE descendants AS (
    SELECT child_thread_id, 1 AS depth
    FROM thread_spawn_edges
    WHERE parent_thread_id = ?
    UNION ALL
    SELECT e.child_thread_id, d.depth + 1
    FROM thread_spawn_edges e
    JOIN descendants d ON e.parent_thread_id = d.child_thread_id
)
SELECT * FROM descendants ORDER BY depth, child_thread_id;

这意味着 Codex 知道你的整个 multi-agent 关系网络。不只是「谁干了什么」，而是「谁派了谁、谁还在跑、谁已经收了」。

Claude Code 没有这个。Claude Code 的 subagent 是一次性的——干完活就消失，不留痕迹。Codex 的 thread 是持久化的、可遍历的、可恢复的。

你关掉一个子 thread，它不会消失，只是 status 变成 Closed。下次你可以 resume 它，继续之前的对话。

Context Compaction：跟 Claude Code 类似但更粗糙

Codex 也有 context compaction。配置里有 model_auto_compact_token_limit，超过阈值就触发压缩。

基本逻辑跟 Claude Code 一样：把对话历史喂给模型做摘要，用摘要替换原始历史。

但从社区反馈来看，Codex 的压缩做得不如 Claude Code 成熟。有人报告压缩后 Codex 会回复之前的请求（好像压缩把最近的对话搞丢了），有人报告压缩任务永远跑不完，有人报告它根本不触发压缩、直接报错「context window 满了」。

Claude Code 至少有一套精心设计的「压缩后重新注入」机制。Codex 目前看来还没有这么完善。

父子 Thread 的上下文传递

这是理解 Codex 记忆系统的关键。

父子 thread 各有独立的对话历史，不共享 context 窗口。那上下文怎么传？

两条通道。

通道一：显式消息。 父 thread 调 AgentControl.interact 时，在它自己的 history 里就是一个普通的工具调用——发出 tool_call，拿回 tool_result。那段 tool_result 就是子 thread 这一轮的最终回复文本。子 thread 那一堆中间步骤——WebSearch、文件读取、代码分析——完全不进父的 context。

通道二：隐式文件系统。 子 thread 默认继承父的 cwd 和 sandbox。子 thread 写的文件，父 thread 能直接读。这是一条「宽通道」——一份 5000 字的调研报告塞进消息文本会污染父 context，写到文件里然后只回一句「已写到 xxx，核心结论是 yyy」则不会。

两条通道的分工很明确：消息走摘要和决策，文件系统走详细内容。

Agent Identity：每个 Thread 一把私钥

这是 Codex 最「重」的设计。

每个 thread 有一把独立的 ed25519 私钥。调用后端 API 时，thread 用自己的私钥签一段 assertion（agent_runtime_id:task_id:timestamp），服务端验证签名 + JWT 鉴权。

Claude Code 不需要这个——所有 subagent 都在同一个本地进程里，互信。但 Codex 设计为可以跑在云上、跨进程、跨 K8s pod。当你的 multi-agent 分布在不同机器上时，一个 agent 被攻破不能伪装成另一个 agent，就需要独立的身份认证。

这是 Codex 把「同进程 multi-agent」和「分布式 multi-agent」用同一套抽象实现的代价。即使你的 agent 都在同一个进程里，也得走签名流程。

Cross-Session Resume

Codex 可以跨 session 恢复 thread。

恢复时，它从 SQLite 读 thread 行，从 JSONL rollout 文件重放对话历史，从 thread_spawn_edges 表恢复父子关系。整个 agent 拓扑图可以被完整重建。

这是 Codex 跟 Claude Code 的一个根本差异。Claude Code 的会话虽然也有 JSONL 转写，但 resume 时读到的是压缩后的上下文。Codex 的 JSONL rollout 是完整的原始记录，resume 后模型能看到所有历史细节——只要你还没压缩过。

小结：Codex 的记忆哲学

Codex 的记忆是数据库驱动的、图结构的、有身份认证的。

它不是一个简单的文件目录。它是一个完整的状态管理系统——SQLite 做持久化、JSONL 做审计、agent graph 做关系追踪、ed25519 做身份验证。

这种设计的好处是健壮。你知道每个 agent 在哪、在干什么、跟谁有关系。你可以恢复、可以审计、可以分布式部署。坏处是重。90+ crates 的体量，两个 SQLite 库，一套签名鉴权流程，即使你只是一个人在本地跑一个简单任务，这些基础设施也都在。

OpenAI 的定位很清楚：Codex 不只是 CLI 工具，是AI agent runtime。它要能跑在企业的 K8s 集群里给 300 个工程师服务，要能跨 pod 部署，要能审计每一个 agent 的每一步操作。

记忆系统为这个定位服务。不是一个 AI 助手在「记住你」，而是一个企业级平台在「管理状态」。

四家横评：四种记忆哲学

现在把 Hermes、OpenClaw、Claude Code、Codex 放在一起看。

先上一张大表。

架构总览

维度	Hermes	OpenClaw	Claude Code	Codex
核心哲学	便利贴墙	图书馆	层级文件体系	图数据库
存储介质	Markdown 文件	Markdown + SQLite 影子索引	Markdown 文件 + JSONL 转写	SQLite + JSONL rollout
记忆分层	4 层：上下文 / 持久 / 技能 / 会话搜索	3 阶段睡眠 + 短期/工作/长期	CLAUDE.md 层级 + auto memory + session JSONL	Thread + agent graph + rollout
注入方式	全量装载（会话开始时塞 prompt）	按需检索（搜索工具）	分层装载（索引常驻 + 按需加载）	Thread 独立 context + 父子消息传递
检索能力	FTS5 全文检索	Hybrid（向量 + BM25 + MMR + 时间衰减）	无内置检索，靠文件工具按需读取	无内置语义检索，靠 JSONL 重放
压缩策略	50% 触发，4 阶段压缩，压缩前 memory flush	压缩前强制 flush + dreaming 整理	~95% 触发，全量摘要 + 磁盘重新注入	配置化阈值，摘要替换
压缩后恢复	摘要 + 持久记忆（便利贴）	摘要 + dreaming 晋升的记忆	CLAUDE.md + auto memory 从磁盘重新注入	JSONL rollout 完整重放（如果未压缩）
跨会话	持久记忆 + 技能 + 会话搜索	持久记忆 + dreaming + 笔记	auto memory + CLAUDE.md + session resume	Thread 持久化 + agent graph + resume
Multi-Agent	单 agent	多 agent 独立 workspace	Subagent 隔离 + Team 共享 TaskList	Thread graph + spawn 边 + 身份认证
记忆自修改	Agent 可主动改 skill 文件	Dreaming 自动晋升记忆到 MEMORY.md	Auto memory 自主决定存什么	memories 子系统（feature flag 控制）
透明度	高，所有记忆是 markdown	高，markdown + SQLite 可重建	极高，所有文件可 git 管理	中，SQLite 需要专门工具查看
复杂度	低	高	中	极高
定位	个人 AI 助手	长期陪伴 AI 系统	程序员本地 CLI	企业级 AI agent runtime

记忆注入：四种完全不同的策略

记忆怎么「装进」AI 脑子里？这四个系统的做法差异巨大。

Hermes 是「全量装载」。 会话开始时把 MEMORY.md 和 USER.md 整个塞进 system prompt。优点是立刻有上下文，缺点是每次都塞一堆不一定用得到的东西。而且 Hermes 用了「冻结快照」——会话期间记忆文件更新了，但 prompt 里的版本不变。这是为了保 prefix cache，省钱省时间。

OpenClaw 是「按需检索」。 它不把 MEMORY.md 塞进 prompt，而是注入一段纪律：凡是涉及历史信息的，必须先调 memory_search 工具去找。检索结果是带行号的，精确到哪一行。好处是精准，每次只取相关的那几行；代价是多一轮工具调用，慢一些。

Claude Code 是「分层装载」。 MEMORY.md 的前 200 行常驻 prompt，详细内容按需用文件工具读取。CLAUDE.md 层级文件同样常驻。这是一种折中——比 Hermes 精准，比 OpenClaw 快。

Codex 是「独立 context」。 每个 thread 有独立的 context 窗口，父子 thread 之间不共享对话历史。上下文通过显式消息和隐式文件系统传递。这跟前面三个完全不是一个维度——它不是在解决「怎么把记忆塞给一个 AI」，而是在解决「多个 AI 之间怎么传递状态」。

压缩策略：四种对抗遗忘的方式

所有大模型都有 context 窗口限制。记忆迟早要被压缩。压缩前做什么、压缩后怎么恢复，这是区分记忆系统好坏的分水岭。

Hermes 的压缩最有人情味。 50% 触发，压缩前给 agent 一个「记忆刷新」的机会——让它赶紧把重要的东西从即将被丢弃的对话里抢救出来，写进 MEMORY.md。就像一个人知道自己马上要失忆了，疯狂往便利贴上写东西。

OpenClaw 的压缩最像人类。 压缩前不只给 agent 一次机会，而是 runtime 强行插入一个回合——告诉 agent 你只能做一件事：把重要内容写到当天的 memory 文件里。然后这个写入的内容会进入 dreaming 流水线，经过 light sleep、REM sleep、deep sleep 三阶段筛选，有可能最终晋升到长期记忆 MEMORY.md。

Claude Code 的压缩最工程化。 ~95% 触发，全量摘要替换。但压缩后从磁盘重新注入 CLAUDE.md 和 auto memory——这些「种子文件」是压缩后恢复上下文的唯一来源。这种设计的好处是确定性强，坏处是正在处理中的数据可能被不可逆地丢失。

Codex 的压缩目前最粗糙。 配置化的阈值触发，摘要替换。但从社区反馈来看，它的实现还不够稳定。好处是 JSONL rollout 保存了完整的原始记录——即使对话被压缩了，原始数据还在磁盘上。

Multi-Agent 记忆：两种隔离哲学

Hermes 和 OpenClaw 主要面向单 agent 场景（OpenClaw 支持多 agent，但每个 agent 的记忆完全隔离）。Claude Code 和 Codex 则有更丰富的 multi-agent 能力，但哲学完全不同。

Claude Code：委派模式。 Subagent 是一次性的。主 agent 派任务，subagent 干完活返回结果就消失。不持久化，不留痕。但 subagent 可以有自己的 auto memory，积累跨次调用的经验。

Team 模式允许持久化的 teammate，但 Team 本身不跨 session。进程结束，Team 就没了。

Codex：图模式。 每个 thread 是图中长寿的节点。Spawn 关系持久化到 SQLite，可以跨 session 恢复。父子 thread 可以多轮交互，不用每次重讲「我们在聊什么」。每个 thread 有独立的身份（ed25519 私钥），适合分布式部署。

一句话：Claude Code 的 multi-agent 是「项目经理 + 临时外包」，Codex 是「DAG of agents」。

记忆的自修改能力

哪个系统允许 AI 自己修改记忆？

Hermes 最激进。 Agent 可以主动修改 skill 文件，把踩过的坑写进去。这是「学习」——碰壁之后改菜谱。

OpenClaw 最有机。 Agent 不直接改 MEMORY.md，但 dreaming 机制会把反复出现的经验自动晋升到长期记忆。这是「巩固」——反复想起，慢慢沉淀。

Claude Code 最克制。 Auto memory 允许 Claude 自主决定存什么，但它不修改 CLAUDE.md（除非你明确说「add this to CLAUDE.md」）。技能系统是只读的。记忆的写入是有意识的、可审查的。

Codex 最结构化。 有一个 memories 子系统（feature flag 控制），但具体行为还在迭代。Agent graph 和 thread 元数据是系统自动维护的，agent 不直接操作。

哪个适合你？

不是越复杂越好。每个系统对应不同的使用场景。

你的需求是 ……

├── 一个个人 AI 助手帮我处理日常事务
│       → Hermes（轻量、直接、上手快）
│
├── 一个长期陪伴的 AI 系统，记住几个月甚至几年的上下文
│       → OpenClaw（dreaming + hybrid 检索 + 语义搜索）
│
├── 程序员的本地 CLI 助手，帮我写代码
│       → Claude Code（CLAUDE.md 层级 + auto memory + 压缩恢复）
│
├── 企业级 AI agent 平台，给整个团队用
│       → Codex（Thread 持久化 + agent graph + 身份认证 + 审计）
│
├── 需要语义级记忆检索（搜概念，不搜关键词）
│       → OpenClaw（hybrid 检索 + embedding）
│
└── 需要记忆完全透明、可 git 管理
        → Claude Code（所有记忆都是 markdown 文件）

写在最后：AI 的记忆到底应该像什么？

拆完四个系统，我有一个很强的感受。

Hermes 和 OpenClaw 在试图让 AI 的记忆像人。Hermes 用便利贴和日记本做比喻，OpenClaw 直接把神经科学的睡眠巩固机制翻译成了代码。它们的共同假设是：AI 如果要跟人类长期协作，记忆方式应该借鉴人类。

Claude Code 和 Codex 在试图让 AI 的记忆像软件。Claude Code 用文件系统和 git 管理记忆，Codex 用数据库和图结构管理状态。它们的共同假设是：AI 的记忆应该可审计、可恢复、可分布——这是软件工程的标准要求，不是认知科学的模拟。

哪种对？

我觉得都对，但解决的是不同的问题。

如果你要做的是「让一个 AI 跟你建立长期默契」，Hermes 和 OpenClaw 的思路更合适。人类跟人建立默契，靠的就是「你记得我上次说过什么」「你知道我讨厌什么风格」「你在我踩坑之前提醒我」。这些记忆是人格化的、关系化的。

如果你要做的是「让 AI 可靠地执行任务」，Claude Code 和 Codex 的思路更合适。企业不关心 AI 记不记得你上次聊了什么，企业关心的是「这个 agent 上次跑到哪一步了」「哪个 agent spawn 了哪些子 agent」「出问题了能不能追溯到具体某一步」。

但如果你仔细看，这四个系统有一个共同的底层矛盾。

AI 的记忆本质上是在对抗大模型的两个约束：context 窗口有限 + 无状态 API。

每次调用模型都是无状态的。模型不记得上一秒你说了什么，除非你把完整历史塞进去。但 history 越塞越长，迟早超过 context 窗口。于是你必须压缩、摘要、丢弃。

所有四个系统的所有设计——便利贴、图书馆、层级文件、图数据库、压缩前刷新、做梦巩固、种子文件、JSONL 重放——全都是在用不同的工程手段对抗这两个约束。

从这个角度看，记忆系统不是 AI 的「功能」，而是大模型架构局限性的补丁。

如果有一天，模型的 context 窗口大到可以装下你跟它所有的对话历史，或者模型变成了有状态的——这些复杂的记忆系统还需要吗？

也许不需要了。

但那天到来之前，这四个系统给了我们四种不同的补丁方案。有的像便利贴，有的像图书馆，有的像文件系统，有的像数据库。它们都在回答同一个问题：怎么让一个注定会遗忘的存在，表现得好像它记得你。

这本身就是一个很动人的工程问题。

不管你用的是哪个系统，下次你打开 AI、发现它还记得你上次说过什么的时候，你知道这背后有多少精心设计在支撑这种「记得」了吗？

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

Agent 记忆系统四家横评：从便利贴到图书馆，再到什么？

Agent 记忆系统四家横评：从便利贴到图书馆，再到什么？

Claude Code：把记忆藏进文件系统的每一层

CLAUDE.md 层级注入

Auto Memory：后来加的那块拼图

Context Compaction：被压缩的不仅仅是记忆

Subagent 的记忆隔离

Session 持久化

Cron 任务的记忆

小结：Claude Code 的记忆哲学

Codex：把记忆做进数据库的重量级选手

Thread：一切的基本单元

两套 SQLite 数据库

Agent Graph Store：Thread 之间的关系图

Context Compaction：跟 Claude Code 类似但更粗糙

父子 Thread 的上下文传递

Agent Identity：每个 Thread 一把私钥

Cross-Session Resume

小结：Codex 的记忆哲学

四家横评：四种记忆哲学

架构总览

记忆注入：四种完全不同的策略

压缩策略：四种对抗遗忘的方式

Multi-Agent 记忆：两种隔离哲学

记忆的自修改能力

哪个适合你？

写在最后：AI 的记忆到底应该像什么？

Ask Leslie

微信联系