OpenClaw 为什么慢？
为什么烧 Token？

🔴 核心原因
Memory 没管理好
AGENT RUNTIME MEMORY ARCHITECTURE · 2026

先看结论

Token 消耗对比
旧模式 / OpenClaw
30k
tokens / 100轮对话
✗ 完整历史全量传入
✗ 工具输出堆入 context
✗ 无压缩，无过滤
Memory 优化后
1k
tokens / 100轮对话
✓ 结构化 Memory 提取
✓ Session 压缩摘要
✓ 按需 Retrieval
压缩比 30x

旧范式：Chat History

用户消息
↓
完整 Chat History
↓
LLM
⚠ 问题链
  • 所有历史直接传入
  • → Token 爆炸
  • → 上下文混乱
  • → 成本不可控
  • → 长期会话不可扩展
100 轮 ≈ 30,000 tokens

OpenClaw 的症结

为什么比御三家慢、比御三家贵？
🔴 OpenClaw 现状
  • ✗ 工具输出直接进 history
  • ✗ 所有轮次全量传入
  • ✗ 没有 Memory 提取机制
  • ✗ 没有 Context 压缩
  • ✗ 按需读文件 = 无限堆积
📊 实际影响
一次代码任务
读 5 个文件 × 300行
= 1500 行进 context

10 次工具调用
= context 超过 15k tokens

响应变慢，成本飙升

御三家怎么做的

Claude Code · Codex CLI · Gemini CLI
Claude Code Codex CLI Gemini CLI
Long-term Memory ⚠ 有限 ⚠ 有限 ✗ 几乎没有
Workspace Memory ✓ 强 ✓ 强 △ 弱
Session 压缩 ✓ 自动 △ 部分 △ 部分
按需 Retrieval ✓ ✓ ✗
Tool Output 处理 ✓ 摘要化 △ ✗ 全量
共同策略： 不把完整 history 传入 LLM，而是传 Persona + Memory + Session Summary + Recent Turns

Claude Code Memory 架构

用户消息
↓
Instructions (CLAUDE.md)
↓
Workspace Retrieval（按需）
↓
Session Summary（压缩历史）
↓
LLM
✓ 关键机制
  • → CLAUDE.md 持久化指令
  • → 文件按需读取，不堆积
  • → 长对话自动压缩摘要
  • → 只传 recent turns
  • → Tool output 不进 history
核心： Workspace = 文件系统 Memory

Codex CLI Memory 架构

用户消息
↓
Instructions 文件
↓
Repo Retrieval（语义搜索）
↓
Recent Messages（有限窗口）
↓
LLM
⚡ 特点
  • → Repo 文件 = 主要 Memory
  • → 按 intent 语义检索文件
  • → 固定窗口 recent messages
  • → 没有长期用户 Memory
弱点： Session 间无持久 Memory，全靠文件系统

Gemini CLI Memory 架构

用户消息
↓
Instructions（基础）
↓
Session Context（全量？）
↓
LLM（长 context 窗口）
⚠ 现状
  • ✗ 几乎没有 long-term memory
  • ✗ 依赖 Gemini 超长 context
  • △ 没有主动 Memory 提取
  • △ 没有结构化 Retrieval
策略： 用模型的长 context 代替 Memory 管理

业内 SOTA：Agent Memory Pipeline

2026 主流架构：WRITE → MANAGE → READ
①
用户消息
→
②
Memory Retrieval
语义搜索
Top-K 召回
→
③
Context Assembly
Persona
Memory
Summary
Recent Turns
→
④
LLM
→
⑤
Memory Extraction
自动提取事实
写入 Memory Store
核心： Tool Output → External Storage（S3/DB），Context 只放 Summary

Memory 的两种哲学

像计算机，还是像人类？
💻 计算机范式
KV Lookup · Cache · Memory Hierarchy
L1 Cache Working Context（当前 turns）
↑ 更快 · 更贵
RAM Session Memory（摘要）
↓ 更慢 · 更便宜
Disk Long-term Memory（SQL/Vector）
精确 · O(1) 查找 · 结构化 · 可预测
代表：Mem0 · Redis KV · Vector DB · OpenViking
🧠 人类范式
Relation · Graph · Associative
A 认识 B  →  B 投资了 C
C 竞争对手是 D  →  D 收购了 E
节点
实体（人/事件/概念）
边
关系（动词/语义连接）
模糊 · 联想 · 上下文感知 · 可演化
代表：Graphiti · Letta · ReMe

主流框架对比

Mem0
Production Ready💻 计算机
  • 自动 Memory 提取
  • SQL + Vector KV
  • 精确召回，最成熟
Letta (MemGPT)
Agent OS🧠 人类
  • Agent 自管理 Memory
  • 层级化 Archive
  • 长期任务能力强
Graphiti
Graph Memory🧠 人类
  • 知识图谱，关系推理
  • A→B→C 链路追踪
  • 最接近人类联想
OpenViking
Filesystem OS💻 计算机
  • Memory = 文件系统
  • 目录 = Cache 层级
  • Human readable
ReMe
Research🧠 人类
  • 情节/语义/任务
  • 三维 Memory 组织
  • 模拟人类记忆结构
OpenClaw
待优化💻 半残
  • 文件系统 Memory
  • ✗ 无自动提取
  • ✗ 无 Context 压缩

三层 Memory 结构

正确的 Agent Memory 分层
🧠
① Long-term Memory
用户画像 · 偏好 · 重要事件 · 长期知识 → SQL + Vector DB
📋
② Session Memory
当前任务 · Session 摘要 · Agent 计划 → 压缩历史，非全量
⚡
③ Working Context（真正进入 LLM）
Persona + 检索 Memory + Session 摘要 + Recent Turns → 1000-4000 tokens

Memory ≠ History

🗑
History
  • 可丢弃
  • 随时间无限增长
  • 大多数内容无用
  • 直接传入 = 浪费
💎
Memory
  • 结构化知识
  • 经提取和筛选
  • 按需检索注入
  • 每条都有价值
History 是原材料 → 提炼 → Memory 是精华

OpenClaw 需要的改造

❌ 当前
  • 全量 history 进 context
  • 工具输出堆入 history
  • 无 Memory 提取
  • 无 Context 压缩
  • 读一次文件 = 永久占用 context
✅ 需要
  • → Memory Extraction 模块
  • → Tool Output → External Storage
  • → Context 自动压缩摘要
  • → 按需 Memory Retrieval
  • → 三层 Memory 架构
30k tokens → 1k tokens 压缩 30x，提速 10x+