长期记忆与会话同步 —— 如何让OpenClaw记住跨天对话

关键词：长期记忆｜会话持久化｜增量同步｜上下文压缩｜跨设备一致性

在传统聊天机器人中，对话一旦关闭，上下文即被遗忘。但人类的交流是连续的——今天讨论的项目，明天可能继续推进；上周提到的偏好，下周仍应被尊重。

OpenClaw 的目标是让 AI 智能体具备类人的记忆能力：不仅能记住单次对话，还能在跨天、跨设备、跨渠道的场景下保持上下文连贯。这依赖于一套精心设计的长期记忆与会话同步机制。

本文将详解：

• 会话如何持久化存储
• 何时触发同步以平衡性能与一致性
• 如何防止记忆膨胀与隐私泄露
• 如何在 WhatsApp、Web、iOS 间共享同一记忆视图

一、会话模型：从瞬时到持久

OpenClaw 将每次交互视为一个 PiSession（Persistent Intelligent Session），其核心属性包括：

interface PiSession {
  sessionKey: string;        // 唯一标识，如 "wa:+1234567890"
  messages: Message[];       // 消息历史（含 AI 思考、工具调用）
  lastAccessed: number;      // 最后活跃时间戳
  memoryEnabled: boolean;    // 是否启用长期记忆
  syncState: SyncState;      // 同步状态（dirty/clean/syncing）
}

sessionKey 的设计哲学

• 全局唯一：格式为 {channel}:{identifier}
  • WhatsApp: wa:+1234567890
  • Telegram: tg:123456789
  • Web UI: web:user_abc123
• 跨端一致：同一用户在 iOS 和 Web 上使用相同 key，共享记忆

 这使得用户从手机切换到电脑时，AI 仍知道“你刚才在查服务器日志”。

二、持久化存储：.jsonl 格式的工程智慧

会话不存入数据库，而是以 JSONL（JSON Lines）格式写入文件：

sessions/
└── wa:+1234567890.jsonl

为何选择 JSONL？

image

文件内容示例

{"role":"user","content":"重启 staging 数据库","timestamp":1710234567}
{"role":"assistant","tool_calls":[{"name":"bash_exec","args":{"cmd":"kubectl..."}}],"timestamp":1710234568}
{"role":"tool","content":"deployment.apps/staging-db restarted","timestamp":1710234569}
{"role":"assistant","content":"数据库已重启！","timestamp":1710234570}

简单即可靠——避免 ORM、事务、迁移等复杂性。

三、同步策略：何时写盘？如何防丢？

频繁写盘影响性能，不写又怕丢失。OpenClaw 采用双阈值增量同步：

触发条件（满足任一即同步）

1. 字节数阈值：累计未保存消息 > 16 KB
2. 消息数阈值：累计 > 10 条新消息
3. 空闲超时：5 分钟无新消息，自动 flush
4. 进程退出：process.on('SIGINT', syncAllSessions)

同步流程

function maybeSyncSession(session: PiSession) {
  if (session.unsyncedBytes > 16384 || session.unsyncedCount > 10) {
    appendToSessionFile(session.sessionKey, session.getUnsyncedMessages());
    session.markSynced();
  }
}

平衡点：既避免每条消息 I/O，又确保崩溃时最多丢失 10 条。

四、长期记忆注入：让历史对话参与 RAG

启用 sessionMemory.enabled: true 后，当前会话的历史消息会被自动纳入 RAG 检索源。

关键设计：

• 仅检索“非工具”消息：过滤掉 bash_exec 的 stdout，保留用户意图
• 时间衰减：越近的消息权重越高（通过 FTS5 的 rank 自然实现）
• 角色保留：区分 user / assistant，防止 AI “自己引用自己”

示例场景

用户今天问：

“上次说的那个部署脚本在哪？”

系统行为：

在 memory-search.ts 中，将当前会话的 .jsonl 文件作为知识源

混合检索命中 3 天前的对话：

user: 能写个自动部署脚本吗？
assistant: 已创建 deploy.sh，路径 /opt/scripts/deploy.sh

AI 回复：

“您上次的部署脚本在 /opt/scripts/deploy.sh，需要我帮您运行吗？”

记忆不是回放，而是主动关联。

五、隐私与安全：记忆不是无限存储

长期记忆带来便利，也带来风险。OpenClaw 实施多重保护：

1. 默认关闭

• sessionMemory.enabled: false（全局）
• 用户需显式在智能体配置中开启

2. 自动过期（可选）

memory:
  sessionRetentionDays: 30  # 30 天后自动清理

3. 敏感信息过滤

工具输出中的 API Key、密码等自动脱敏（见 ws-log.ts）

用户可配置正则过滤器：

sessionFilters:
  - pattern: "\\b[A-Za-z0-9]{30,}\\b"  # 长字符串（疑似密钥）
    replace: "[REDACTED]"

4. 本地优先

• 所有会话文件存储在用户自有服务器
• 不上传至任何第三方云

你的记忆，你做主。

六、跨设备一致性：一个用户，一个记忆视图

当用户同时使用 WhatsApp（手机）和 Web UI（电脑），如何保证记忆同步？

解决方案：中心化会话存储

• 所有客户端连接同一 OpenClaw 网关实例
• 会话文件存储在网关服务器的 sessions/ 目录
• 客户端不存储历史，只通过 ACP 的 chat.history 实时拉取

流程示例

1. 用户在 WhatsApp 发送消息 → 网关写入 wa:+123...jsonl
2. 用户打开 Web UI → 调用 chat.history(sessionKey="wa:+123...")
3. 网关读取同一文件，返回完整历史

记忆位于服务端，客户端只是窗口。

七、性能与扩展：应对海量会话

随着用户增长，sessions/ 目录可能包含数万个文件。OpenClaw 通过以下方式优化：

1. 懒加载

• 仅当某 sessionKey 被访问时，才加载其 .jsonl
• 内存中缓存最近 100 个活跃会话

2. 分片存储（未来）

• 计划按哈希分目录：sessions/a/b/ab123...jsonl
• 防止单目录 inode 耗尽

3. 归档压缩

• 冷会话自动 gzip 压缩，节省磁盘
• 读取时透明解压

结语：记忆是信任的基石

让 AI “记住你”，不仅是技术挑战，更是建立人机信任的关键一步。OpenClaw 的长期记忆系统，没有追求无限存储或复杂图谱，而是聚焦于：

• 可靠性（不丢消息）
• 一致性（跨端同步）
• 可控性（用户可管理）
• 安全性（默认隐私优先）

这使得它既能用于个人自动化中枢，也能满足企业对数据主权的要求。

在下一篇中，我们将转向执行层，解析 exec.ts 如何安全地让 AI 操作操作系统。

下一篇预告： 第 10 篇：exec.ts 上篇 —— 安全执行 Shell 命令的三层隔离模型