AI Agent 记忆系统深度对比：Claude Code、OpenClaw、Hermes Agent 的技术路线到底有什么不同

本文基于 Hermes Agent 源码分析、OpenClaw 一手使用体验，以及 Claude Code 公开文档整理。

一、为什么"记忆"是 Agent 的核心问题？

很多人聊 AI Agent，会先关注规划能力、工具调用和自动执行流程。但真正决定一个 Agent 能不能长期工作的，往往是它的"记忆系统"。

它决定了 Agent 能记住什么、忘掉什么，又如何在下一次任务里把之前的信息重新调出来。更直白一点说——任务链一长、上下文一复杂、运行时间一拉长，记忆系统的差异就会迅速暴露出来。

这篇文章把 Claude Code、OpenClaw 和 Hermes Agent 放在一起，从源码和工程实现的角度，看看它们各自在"记忆"这件事上走了哪条路。

二、三种方案速览

三、Claude Code：上下文缓存即记忆

3.1 三层记忆结构

Claude Code 的记忆策略并不是传统意义上的"外部长期存储"，而是一种围绕上下文窗口与缓存复用进行的工程优化。

第一层：上下文缓存（Context Caching）

模型在处理长上下文时，会生成可复用的中间状态（KV cache）。当前缀部分不变时，后续请求可以复用这些缓存，大幅降低延迟和成本。类似于翻书时手指夹着已读过的页——不需要重新读。

第二层：CLAUDE.md 项目记忆

项目根目录的 CLAUDE.md 文件，每次会话启动时自动加载。内容包括项目架构说明、编码规范、常用命令、之前的决策记录。这是一种半自动的记忆——需要用户或 Agent 手动维护。

第三层：会话压缩（Compaction）

当上下文窗口接近上限时，Claude Code 会自动压缩历史对话，生成摘要保留关键信息。有损压缩——细节会丢失，但核心决策和结论得以保留。

3.2 特点

局限：Claude Code 的记忆是项目现场级的——擅长"盯住当前项目"，但不擅长跨项目、跨时间的知识积累。关闭终端窗口，大部分记忆就消失了。

四、OpenClaw：文件即记忆

4.1 核心机制

OpenClaw 走了一条完全不同的路：用文件系统作为底层存储，用 Markdown 作为结构化格式。不依赖向量数据库、不依赖外部服务。

~/.openclaw/workspace/
├── MEMORY.md              ← 长期记忆（跨会话持久化）
├── memory/
│   ├── 2026-05-10.md      ← 每日笔记
│   └── ...
├── AGENTS.md              ← 行为规范
├── SOUL.md                ← 人格定义
└── TOOLS.md               ← 工具配置笔记

4.2 记忆的生命周期

写入：Agent 通过 write / edit 工具直接修改 Markdown 文件。重要信息写入 MEMORY.md，日常细节写入 memory/YYYY-MM-DD.md。

检索：通过 memory_search 语义搜索，或 memory_get 精确读取特定行。

维护：通过 Heartbeat（心跳轮询）定期将每日笔记提炼到 MEMORY.md，清理过时信息。

4.3 独特优势

• 人类可读：直接打开 MEMORY.md 查看 Agent 记住了什么
• 可手动编辑：你可以修改 Agent 的记忆
• 版本控制：Markdown 天然支持 git 追踪记忆演化

局限：文件系统检索能力有限，记忆增长后搜索效率下降。语义搜索依赖嵌入模型配置。记忆质量取决于 Agent 的"写入判断力"。

五、Hermes Agent：插件化多层记忆系统

Hermes Agent 是三者中记忆系统最复杂的——也最值得深入分析。GitHub 仓库 NousResearch/hermes-agent，MIT 协议，由 Nous Research 维护。

5.1 MemoryManager + MemoryProvider 插件架构

# agent/memory_manager.py
class MemoryManager:
    """Orchestrates the built-in provider plus at most one external provider."""
    def __init__(self):
        self._providers: List[MemoryProvider] = []
        self._has_external: bool = False  # 只允许一个外部 provider

关键设计决策：只允许一个外部 provider。原因是防止工具 schema 膨胀和冲突——每个 provider 都会向模型暴露工具函数，两个同时注册会导致工具列表混乱。

MemoryProvider 是抽象基类，定义了完整生命周期：

# agent/memory_provider.py
class MemoryProvider(ABC):
    # 核心生命周期
    def initialize(self, session_id, **kwargs)      # 启动时初始化
    def system_prompt_block(self) -> str             # 注入系统提示
    def prefetch(self, query, *, session_id) -> str  # 每次调用前召回
    def sync_turn(self, user, asst)                  # 每轮对话后持久化
    def get_tool_schemas() -> List[Dict]             # 暴露工具
    def shutdown()                                   # 清理退出

    # 可选钩子
    def on_turn_start(turn, message, **kwargs)       # 每轮开始
    def on_session_end(messages)                     # 会话结束
    def on_session_switch(new_session_id)            # 会话切换
    def on_pre_compress(messages) -> str             # 压缩前提取
    def on_memory_write(action, target, content)     # 记忆写入时
    def on_delegation(task, result, **kwargs)        # 子Agent完成时

5.2 FTS5 会话搜索（跨会话召回）

Hermes Agent 的跨会话记忆不是靠向量数据库，而是靠 SQLite 的 FTS5 全文搜索扩展——搜索过去的会话记录，然后用 LLM 对搜索结果做摘要。

# tools/session_search_tool.py
"""
Flow:
  1. FTS5 search finds matching messages ranked by relevance
  2. Groups by session, takes top N unique sessions (default 3)
  3. Loads each session's conversation, truncates to ~100k chars
  4. Sends to auxiliary model with focused summarization prompt
  5. Returns per-session summaries with metadata
"""

这个设计很精巧：不是把原始对话历史塞进上下文（浪费大量 token），而是让一个辅助模型先消化搜索结果，只返回精炼的摘要。主模型的上下文窗口保持干净。

5.3 Honcho 辩证式用户建模

Hermes Agent 支持通过 Honcho（plugins/memory/honcho/）构建用户的心理模型。Honcho 不只是"记住你说过什么"，而是会随着时间推移，推断你的偏好、习惯和需求。

# plugins/memory/honcho/client.py
"""
Recall modes:
  - "hybrid" (default): context + tools combined
  - "context": inject as system prompt context
  - "tools": expose as callable tools for the model
"""

这是"辩证式"的——它不只是线性地存储对话，而是不断地修正和更新对用户的理解。类似一个越来越了解你的助手。

5.4 流式上下文清洗器

一个容易被忽略但很关键的工程细节：

# agent/memory_manager.py
class StreamingContextScrubber:
    """Stateful scrubber for streaming text that may contain
    split memory-context spans."""

当 Agent 在流式输出时，记忆上下文（<memory-context> 标签）可能跨 chunk 边界。普通的正则匹配会失效，导致记忆内容泄漏给用户。StreamingContextScrubber 用一个小型状态机解决了这个问题。

5.5 定时 Nudge 机制

Hermes Agent 有定时"轻推"机制——周期性地提醒 Agent 持久化重要信息，而不是只在会话结束时才写入。这解决了 OpenClaw 的一个痛点：心跳轮询间隔（约 30 分钟）内的重要决策可能丢失。

5.6 特点

局限：系统复杂度高，理解和调试门槛不低。Honcho 用户建模需要额外外部服务。

六、技术路线深度对比

6.1 记忆的"写入"方式

6.2 记忆的"检索"方式

6.3 记忆的"维护"方式

6.4 一句话总结

• Claude Code：当前上下文怎么更快、更稳地复用？
• OpenClaw：怎么让记忆人类可读、可编辑、可版本控制？
• Hermes Agent：怎么让 Agent 越用越懂你，并且永远不忘记？

七、选型建议

八、融合趋势

真正成熟的 Agent，往往不会只靠一种记忆机制。短期用上下文缓存保速度，中期用文件系统保连续性，长期用 FTS5 搜索和用户建模保深度。三种层次的融合，才是下一阶段 Agent 系统真正值得关注的方向。

• 短期记忆：上下文缓存（Claude Code 的思路）
• 中期记忆：文件系统 / 状态持久化（OpenClaw 的思路）
• 长期记忆：FTS5 搜索 + 用户建模（Hermes Agent 的思路）