长期记忆与会话同步 —— 如何让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
- WhatsApp:
- 跨端一致：同一用户在 iOS 和 Web 上使用相同 key，共享记忆
这使得用户从手机切换到电脑时，AI 仍知道“你刚才在查服务器日志”。
二、持久化存储：.jsonl 格式的工程智慧
会话不存入数据库，而是以 JSONL（JSON Lines）格式写入文件：
sessions/
└── wa:+1234567890.jsonl
为何选择 JSONL？
文件内容示例
{"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 采用双阈值增量同步：
触发条件（满足任一即同步）
- 字节数阈值：累计未保存消息 > 16 KB
- 消息数阈值：累计 > 10 条新消息
- 空闲超时：5 分钟无新消息，自动 flush
- 进程退出：
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实时拉取
流程示例
- 用户在 WhatsApp 发送消息 → 网关写入
wa:+123...jsonl - 用户打开 Web UI → 调用
chat.history(sessionKey="wa:+123...") - 网关读取同一文件，返回完整历史
记忆位于服务端，客户端只是窗口。
七、性能与扩展：应对海量会话
随着用户增长，sessions/ 目录可能包含数万个文件。OpenClaw 通过以下方式优化：
1. 懒加载
- 仅当某
sessionKey被访问时，才加载其.jsonl - 内存中缓存最近 100 个活跃会话
2. 分片存储（未来）
- 计划按哈希分目录：
sessions/a/b/ab123...jsonl - 防止单目录 inode 耗尽
3. 归档压缩
- 冷会话自动 gzip 压缩，节省磁盘
- 读取时透明解压
结语：记忆是信任的基石
让 AI “记住你”，不仅是技术挑战，更是建立人机信任的关键一步。OpenClaw 的长期记忆系统，没有追求无限存储或复杂图谱，而是聚焦于：
- 可靠性（不丢消息）
- 一致性（跨端同步）
- 可控性（用户可管理）
- 安全性（默认隐私优先）
这使得它既能用于个人自动化中枢，也能满足企业对数据主权的要求。
在下一篇中，我们将转向执行层，解析
exec.ts如何安全地让 AI 操作操作系统。
下一篇预告：
第 10 篇：exec.ts 上篇 —— 安全执行 Shell 命令的三层隔离模型
您的 AI 助手，从此由您定义。若感兴趣可以浏览本书其他章节内容：
浙公网安备 33010602011771号