在理解了记忆机制的通用原理之后，最关键的问题来了：当前主流的开源 Agent，到底是怎么实现记忆的？它们之间有什么本质差异？
本文将四大主流 Agent------OpenClaw、QwenPaw、Hermes Agent、HiClaw------的记忆系统逐层拆解，从存储架构、检索策略、写入机制到核心设计哲学，做一次彻底的横向对比。
一、四大 Agent 一句话定位
| Agent |
定位 |
记忆核心关键词 |
| OpenClaw |
插件化记忆后端，让任何 LLM 都能"记住" |
SQLite + Markdown + 混合检索 + memory-host-sdk |
| Hermes Agent |
与你共同成长的自进化个人智能体 |
四层记忆栈 + Agent 策展 + KEPA 反向传播 + Honcho 建模 |
| QwenPaw |
本地优先的个人助理型"Agent 操作系统" |
每 Agent 独立记忆 + Multi-Agent 协作共享 + 本地模型 |
| HiClaw |
多 Agent 协作系统，Manager-Workers 架构 |
专属 Manager Claw 统筹 + Matrix 实时通信 + 记忆隔离 |
二、记忆架构逐层对比
🧠 2.1 存储架构对比
| 维度 |
OpenClaw |
Hermes Agent |
QwenPaw |
HiClaw |
| 核心存储介质 |
SQLite + Markdown 文件 |
SQLite WAL + FTS5 + MEMORY.md / USER.md |
本地文件系统 + SQLite（AgentScope Runtime） |
每个 Claw 独立存储 |
| 长期记忆文件 |
MEMORY.md（工作区根目录） |
MEMORY.md（2200字符）+ USER.md（1375字符） |
每个 Agent 独立的 memory 目录 |
各 Claw 独立记忆 |
| 短期/会话记忆 |
memory/YYYY-MM-DD.md 每日日志 |
SQLite 原始对话记录（Session Memory） |
Agent 内部 memory（对话历史 + 执行记录） |
Worker Claw 会话记忆 |
| 是否向量化 |
✅ LanceDB（可选扩展） |
❌ 无向量数据库（FTS5 + LLM 摘要） |
✅ 支持（通过 AgentScope Runtime） |
❌ 偏关键词检索 |
| 字符硬限制 |
❌ 无显式限制 |
✅ MEMORY.md ≤2200 chars，USER.md ≤1375 chars |
❌ 无 |
❌ 无 |
🔑 核心差异：OpenClaw 和 QwenPaw 走"向量化"路线，Hermes 故意不用向量库，用 FTS5 + LLM 摘要实现"轻量级语义检索"------这是 Hermes 最独特的设计选择。
🔍 2.2 检索策略对比
| 策略 |
OpenClaw |
Hermes Agent |
QwenPaw |
HiClaw |
| 关键词检索 |
✅ FTS5 / BM25 |
✅ FTS5（SQLite 全文索引） |
✅ 支持 |
✅ 支持 |
| 向量语义检索 |
✅ LanceDB（混合检索，默认 7:3 权重） |
❌ 不使用 |
✅ AgentScope Runtime 内置 |
❌ |
| LLM 摘要检索 |
✅ 检索后 LLM 提炼摘要再注入 |
✅ 核心策略：检索→LLM 摘要→注入 |
✅ Planner 驱动按需检索 |
⚠️ Manager 统筹 |
| 混合检索权重 |
70% 向量 + 30% 关键词 |
无（纯 FTS5 + LLM） |
动态（Runtime 调度） |
N/A |
| 去重策略 |
✅ MMR（最大边际相关性） |
✅ Jaccard 相似度去重 |
✅ Runtime 内置 |
⚠️ 依赖 Manager |
| 时间衰减 |
✅ 指数衰减（半衰期 30 天），常青记忆不衰减 |
✅ 定时提醒 + 字符限制自然控制 |
⚠️ 无显式衰减 |
⚠️ 无 |
| 检索效果对比 | OpenClaw | Hermes Agent | QwenPaw | |-------------|----------|--------------| | 语义理解深度 | ⭐⭐⭐⭐⭐（向量检索） | ⭐⭐⭐（FTS5 + LLM 摘要） | ⭐⭐⭐⭐（向量 + LLM） | | 精确匹配能力 | ⭐⭐⭐⭐（BM25 保留） | ⭐⭐⭐⭐⭐（FTS5 关键词强） | ⭐⭐⭐⭐ | | 部署复杂度 | ⭐⭐⭐（需 LanceDB） | ⭐⭐⭐⭐⭐（零额外依赖） | ⭐⭐⭐ | | 检索成本 | 中（Embedding 计费） | 低（纯 SQLite） | 中 |
✏️ 2.3 记忆写入机制对比
| 机制 |
OpenClaw |
Hermes Agent |
QwenPaw |
HiClaw |
| 写入触发 |
Agent 主动调用 memory_search / 压缩前自动刷新 |
定时提醒（每 120 秒）+ Agent 主动 memory 工具 |
Agent Loop 中每轮 read→write |
Manager 统筹 + Worker 自主 |
| 写入方式 |
LLM 提炼 → 写入 Markdown → SQLite 索引增量更新 |
字符截断 → 写入 MEMORY.md / USER.md → SQLite |
写入 Agent 独立 memory 目录 |
各 Claw 独立写入 |
| 总结/压缩 |
✅ Memory Flush：压缩前触发记忆刷新，LLM 主动提炼持久事实 |
✅ ContextCompressor：五阶段压缩（工具输出裁剪→头部保护→尾部预算→LLM 摘要→flush） |
✅ Runtime 内置压缩 |
⚠️ 依赖 Manager |
| Agent 策展 |
❌ 无（全量记录） |
✅ 核心特色：Agent 自主决定保存什么，不是自动录制一切 |
⚠️ 部分（Skill 驱动） |
⚠️ Manager 统筹 |
| 元记忆/反思 |
❌ 无显式元记忆 |
✅ KEPA 反向传播：失败信号 → 更新提示模板和技能定义 |
⚠️ Planner 隐式反思 |
❌ |
| 双状态管理 |
✅ 快照注入 + 实时落盘 |
✅ MemoryStore 双状态：系统提示快照（冻结）+ 实时状态（工具修改） |
✅ Profile 冻结 + Memory 动态 |
⚠️ Claw 隔离 |
🔄 2.4 记忆生命周期对比
scss
复制代码
┌─────────────────────────────────────────────────────────────────┐
│ OpenClaw 记忆生命周期 │
│ │
│ 会话开始 → 加载 MEMORY.md + 最近2天 daily.md → 注入 System │
│ │ │
│ ▼ │
│ 每轮对话 → messages 追加 → 上下文累积 │
│ │ │
│ ▼ │
│ 上下文压缩 → Memory Flush → LLM 提炼 → 写入 MEMORY.md │
│ │ │
│ ▼ │
│ 会话结束 → session 快照写入 memory/YYYY-MM-DD.md → 索引增量更新 │
│ │ │
│ ▼ │
│ 跨会话 → memory_search() 语义/关键词检索 → 注入上下文 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ Hermes Agent 记忆生命周期 │
│ │
│ 会话开始 → 加载 MEMORY.md + USER.md → 拼接为 System 前缀 │
│ │ │
│ ▼ │
│ 每轮对话 → MemoryStore 双状态：快照不动 + 实时状态落盘 │
│ │ │
│ ▼ │
│ 每 120 秒 → Memory Nudge 提醒 → Agent 判断是否保存 │
│ │ │
│ ▼ │
│ 上下文压缩 → ContextCompressor 五阶段 → flush_memories() │
│ │ │
│ ▼ │
│ 失败/纠错 → KEPA 反向传播 → 更新技能定义 + 提示模板 │
│ │ │
│ ▼ │
│ 跨会话 → session_search (FTS5) → LLM 摘要 → 注入上下文 │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ QwenPaw 记忆生命周期 │
│ │
│ Agent 初始化 → load_agents() → 每个 Agent 加载独立 memory │
│ │ │
│ ▼ │
│ Agent Loop → read memory → Planner 决策 → executor 执行 │
│ │ │ │
│ │ ▼ │
│ │ write back memory │
│ │ │
│ ▼ │
│ Multi-Agent → 消息通信 → 记忆共享（通过消息传递上下文） │
│ │ │
│ ▼ │
│ Mission Mode → 任务拆解 → 子 Agent 执行 → 结果整合 → 记忆沉淀 │
└─────────────────────────────────────────────────────────────────┘
三、核心设计哲学对比（最关键的差异）
| 维度 |
OpenClaw |
Hermes Agent |
QwenPaw |
HiClaw |
| 设计哲学 |
"记忆是可插拔的后端" |
"记忆是 Agent 的核心能力" |
"记忆服务于多 Agent 协作" |
"记忆由 Manager 统筹" |
| 记忆是谁的？ |
LLM 的外部插件 |
Agent 自主策展 |
每个 Agent 独立 |
每个 Claw 独立 |
| 谁决定存什么？ |
LLM（通过记忆工具） |
Agent 自主决定（策展式） |
Planner + Skill |
Manager Claw |
| 谁决定怎么存？ |
统一后端（SQLite + LanceDB） |
四层栈 + 字符硬限制 |
Runtime 统一管理 |
各 Claw 自管 |
| 记忆能进化吗？ |
⚠️ 被动积累 |
✅ KEPA 反向传播 + Honcho 建模 |
✅ Skill 沉淀 |
⚠️ 有限 |
| 可扩展性 |
⭐⭐⭐⭐⭐ memory-host-sdk |
⭐⭐⭐⭐ MemoryProvider 插件 |
⭐⭐⭐⭐ Skill 插件系统 |
⭐⭐⭐ Claw 定制 |
| 数据主权 |
本地（SQLite） |
完全自托管 |
完全本地，支持本地模型 |
自托管 |
| 最大优势 |
生态最开放，任何 LLM 都能用 |
越用越懂你，真正的"自进化" |
多 Agent 协作 + 本地优先 |
分布式协作 + 企业级 |
| 最大局限 |
Agent 不主动策展，噪声多 |
无向量检索，语义召回弱 |
单 Agent 记忆深度有限 |
架构复杂，上手门槛高 |
四、记忆能力详细对比表
| 能力 |
OpenClaw |
Hermes Agent |
QwenPaw |
HiClaw |
| 跨会话记忆 |
✅ MEMORY.md |
✅ MEMORY.md + USER.md |
✅ 独立 memory |
✅ 各 Claw 独立 |
| 语义检索 |
✅✅ LanceDB |
⚠️ FTS5 + LLM 摘要 |
✅ 向量检索 |
❌ |
| 精确检索 |
✅✅ BM25 |
✅✅ FTS5 |
✅ |
✅ |
| 主动总结 |
✅ Memory Flush |
✅ 定时提醒 + KEPA |
✅ Runtime 压缩 |
⚠️ |
| Agent 策展 |
❌ |
✅✅ 核心特色 |
⚠️ |
⚠️ |
| 失败学习 |
❌ |
✅✅ KEPA 反向传播 |
⚠️ |
❌ |
| 用户建模 |
❌ |
✅✅ Honcho 辩证建模 |
⚠️ Profile |
⚠️ |
| 技能沉淀 |
❌ |
✅✅ Skill Memory |
✅ Skill 系统 |
⚠️ |
| 多 Agent 记忆共享 |
❌ |
❌（单 Agent） |
✅✅ 核心能力 |
✅✅ Manager 统筹 |
| 外部程序读写记忆 |
✅ memory-host-sdk |
✅ MemoryProvider 插件 |
⚠️ API |
❌ |
| 本地模型支持 |
✅ |
✅ 200+ 模型 |
✅✅ Ollama/llama.cpp |
⚠️ |
| 字符限制防膨胀 |
❌ |
✅✅ 硬限制 3575 chars |
❌ |
❌ |
| 缓存友好 |
⚠️ |
✅✅ 快照冻结不破坏 system_and_3 |
⚠️ |
⚠️ |
五、记忆写入流程深度对比
OpenClaw 的写入
less
复制代码
Agent 调用 memory 工具
│
▼
LLM 提炼关键信息
│
▼
写入 MEMORY.md（长期）或 memory/YYYY-MM-DD.md（短期）
│
▼
SQLite 索引增量更新：
├── 文件 hash 对比 → 没变就跳过（省钱）
├── chunk 重建 → tokens*4 字符分块
├── embedding 缓存复用 → 避免重复计费
└── id = sha256(source:path:line:chunk.hash:provider.model)
→ ON CONFLICT DO UPDATE
Hermes 的写入
yaml
复制代码
每 120 秒 Memory Nudge 触发
│
▼
Agent 判断：是否有值得保存的内容？
│
├── 是 → 调用 memory 工具 → 字符截断 → 写入 MEMORY.md / USER.md
│ └── 截断规则：MEMORY.md ≤2200 chars，USER.md ≤1375 chars
│
└── 否 → 跳过（只有"忘记保存"的 Agent 才会被提醒）
│
▼
ContextCompressor 触发（上下文达阈值）：
Phase 1: 工具输出裁剪
Phase 2: 头部保护（保留关键指令）
Phase 3: 尾部 token 预算
Phase 4: LLM 摘要
Phase 5: flush_memories() → 用户角色消息注入
│
▼
KEPA 反向传播（仅失败/纠错时）：
失败点定位 → 生成替代提示 → 更新技能定义 → 写入长期记忆
QwenPaw 的写入
arduino
复制代码
Agent Loop 每轮：
┌──────────────────────────────┐
│ read memory → think → act │
│ ↑ │ │
│ └── write back ┘ │
└──────────────────────────────┘
│
▼
Mission Mode（自动任务）：
目标 → 任务拆解 → 子 Agent 执行 → 结果整合 → 记忆沉淀
│
▼
Multi-Agent 协作：
Agent A 完成 → 消息 → Agent B 接收（上下文即记忆传递）
六、检索注入流程深度对比
| 步骤 |
OpenClaw |
Hermes Agent |
QwenPaw |
| 触发时机 |
任务开始前 + 推理中按需 |
会话启动自动加载 + 相似度>0.82 自动注入 |
Agent Loop 每轮 + Planner 按需 |
| 检索工具 |
memory_search(query) |
session_search(query) |
Runtime 内存检索 |
| 检索算法 |
FTS5 + LanceDB 混合（7:3） |
FTS5 全文 → LLM 摘要 |
向量 + 关键词 |
| 注入方式 |
注入 System Prompt |
拼接为 System 前缀（§ 分隔） |
注入 Agent memory 上下文 |
| 注入量控制 |
MMR 去重 + 数量限制 |
字符硬限制 + 摘要压缩 |
Token 预算 |
| 缓存策略 |
✅ embedding 缓存（provider+model+hash） |
✅ 快照冻结不破坏 system_and_3 |
⚠️ Runtime 内置 |
七、实战场景对比：谁更适合什么？
| 场景 |
推荐 Agent |
理由 |
| 个人日常助理，需要跨会话记住偏好 |
⭐⭐⭐⭐⭐ Hermes |
Honcho 用户建模 + 字符限制 + KEPA 进化，真正"越用越懂你" |
| 接入已有 LLM，快速加记忆能力 |
⭐⭐⭐⭐⭐ OpenClaw |
memory-host-sdk 生态最开放，任何 LLM 都能用 |
| 多 Agent 协作完成复杂任务 |
⭐⭐⭐⭐⭐ QwenPaw |
Multi-Agent + 记忆共享 + Mission Mode，协作能力最强 |
| 企业级多 Agent 分布式部署 |
⭐⭐⭐⭐ HiClaw |
Manager-Workers + Matrix 通信，架构最完整 |
| 追求语义检索精度 |
⭐⭐⭐⭐ OpenClaw |
LanceDB 向量检索 + 混合检索，召回质量最高 |
| 追求零依赖、轻量部署 |
⭐⭐⭐⭐⭐ Hermes |
无向量库，纯 SQLite + FTS5，部署最简单 |
| 需要外部程序读写 Agent 记忆 |
⭐⭐⭐⭐⭐ OpenClaw |
memory-host-sdk 独立 SDK，6 个文件搞定 |
| 需要从失败中自动学习 |
⭐⭐⭐⭐⭐ Hermes |
KEPA 反向传播是独家能力，其他三家都没有 |
| 数据完全本地、隐私敏感 |
⭐⭐⭐⭐ QwenPaw / Hermes |
两者都支持 100% 本地部署 + 本地模型 |
八、一张图总结四大 Agent 记忆系统
css
复制代码
记忆能力光谱
语义检索强度 ←──────────────────────────→ 精确检索强度
OpenClaw [████████████░░] 向量+关键词混合，最均衡
QwenPaw [███████████░░░] 向量为主，协作增强
Hermes [██████░░░░░░░░] FTS5+摘要，精确为主
HiClaw [█████░░░░░░░░░] 关键词为主，Manager统筹
记忆进化能力 ←──────────────────────────→ 部署简单度
Hermes [██████████████] KEPA+Honcho，进化最强
OpenClaw[███████████░░░] 记忆刷新，中等进化
QwenPaw [████████░░░░░░] Skill沉淀，协作进化
HiClaw [██████░░░░░░░░] 架构复杂，进化有限
┌──────────────┬──────────────┬──────────────┬──────────────┐
│ OpenClaw │ Hermes │ QwenPaw │ HiClaw │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ 插件化后端 │ 自进化个体 │ Agent OS │ 多Agent协作 │
│ SQLite+MD │ 四层记忆栈 │ 每Agent独立 │ Claw隔离 │
│ LanceDB向量 │ FTS5+LLM摘要 │ 向量+LLM │ 关键词检索 │
│ 全量记录 │ Agent策展 │ Planner驱动 │ Manager统筹 │
│ memory-sdk │ KEPA反向传播 │ Multi-Agent │ Matrix通信 │
│ 生态最开放 │ 越用越懂你 │ 本地优先 │ 企业级架构 │
└──────────────┴──────────────┴──────────────┴──────────────┘
九、核心结论
| 观点 |
说明 |
| OpenClaw 是"记忆基础设施" |
它不追求记忆多智能，但提供了最开放、最标准化的记忆后端，任何项目都可以接入 |
| Hermes 是"记忆原生 Agent" |
记忆不是外挂，而是 Agent 的核心能力。四层栈 + 策展 + KEPA，代表了"Agent 记忆"的最前沿方向 |
| QwenPaw 是"记忆协作平台" |
单 Agent 记忆不是最强，但 Multi-Agent 记忆共享 + Mission Mode 让它在复杂任务场景下无敌 |
| HiClaw 是"记忆企业方案" |
架构最重，但对于需要多 Agent 分布式协作的企业场景，它是最完整的选择 |
🔥 2026 年的趋势判断 ：Hermes 的"Agent 策展 + KEPA 反向传播"代表了 Agent 记忆的未来方向------不是记得越多越好，而是 Agent 自主决定什么值得记、怎么记、怎么用 。OpenClaw 的 memory-host-sdk 生态则代表了另一个方向------记忆标准化、可插拔、跨 Agent 互通。两者融合，才是最优解。
核心公式（更新版）
<math xmlns="http://www.w3.org/1998/Math/MathML"> Agent 能力 = ( 推理能力 × 上下文窗口 ) + 记忆系统质量 × 协作系数 \boxed{\text{Agent 能力} = (\text{推理能力} \times \text{上下文窗口}) + \text{记忆系统质量} \times \text{协作系数}} </math>Agent 能力=(推理能力×上下文窗口)+记忆系统质量×协作系数
| Agent |
记忆质量 |
协作系数 |
综合评估 |
| OpenClaw |
⭐⭐⭐⭐ |
⭐⭐ |
适合单 Agent + 外接 LLM |
| Hermes |
⭐⭐⭐⭐⭐ |
⭐⭐ |
适合个人助理，越用越强 |
| QwenPaw |
⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
适合复杂多步任务 |
| HiClaw |
⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
适合企业多 Agent 部署 |