本文不讲代码, 尽量以非专业术语的方式说清相关事实
引言
openclaw的全球爆火, 创始人都没想到, 程序员也没想到, 非程序员也没想到. 怎么突然就github star超过linux了, 虽然一部分归功于自媒体的宣传, 但是这个项目自身肯定也是有一定价值的.
我应该是第一批vibe coding的人了, 我也是从gpt-3.5-turbo开始知道生成式模型的, 比很多大能晚, 但是比大部分普通人还是早的, 应该算是一个早期玩家, 我能找到的自己最早的blog是这篇:
哈哈, 后来写了openai-billing-query, 虽然只有128个star, 但是对于当时只了解一点html css js的我是个奇妙的初体验.
言归正传
智能体的概念不是从openclaw开始的, 从ai模型开始涌现开始, 人们就想着适用场景. 单纯的对话并不能产生颠覆性价值.
openclaw现在被很多人熟知就是因为它能做很多事, 比如改文件, 操作应用, 在mac上使用applescript来调用apple提醒, apple日历, apple email等等.
其实这都是小手段, claude code也会, 包括浏览器操控也是, 那也是基于已有技术的.
接入聊天软件这种, 也都是小儿科, 从gpt-3.5-turbo时代就能了.
你要说computer use功能, 虽然现在部分模型原生支持, 但是openclaw并没有使用它们, 所以openclaw用低质模型也能跑.
openclaw最颠覆的, 我个人觉得, 或者说大家比较公认的, 是把RAG记忆系统和上面那些结合起来.
这不是简单的上下文窗口堆积，而是一个精心设计的、分层的、可持久化的记忆架构。
为什么记忆系统对于智能体来说这么重要
claude code能做很多事, 写代码, 改文件, 排查服务器故障, 调用脚本, 但是它没记忆. 所以有一个全局CLAUDE.md, 每个项目需要/init一个子CLAUDE.md, 这对于之前的编程工具来说已经是极大创新了, 让cursor直接跑了好多用户. 为什么claude code没达到openclaw这样全民皆知? 除了偏向编程, 记忆系统也许就是那个不能直接看到的原因.
先说个题外话, 或许有人会想, 如果模型上下文足够长, 是不是记忆系统就没必要了.
至少目前来说, 这是不可能的, 原因有下:
- 刚发布的
gpt-5.4有1050k的上下文, 很长了吧, 实际在80-105k左右的时候, 幻觉就很严重了, 我的自行测试与体验, 再强的模型内部上下文召回也没用, 这是硬性问题 - 除了幻觉, 使用成本也要考虑, 全球能源紧张, 算力紧张, 上下文自由遥遥无期
记忆系统的作用
记忆让openclaw可以像一个虚拟人.
- 它知道它是谁, 它叫什么, 它的办事风格.
- 它知道你是谁, 你和某人的关系, 你的工作, 你的爱好, 你的倾向.
- 它在一件事做错并被纠正后, 下次可以减少犯错的几率.
- 它可以固化某一段记忆, 比如你只需要告诉它"帮我把这个文章发到xxx平台, xxx论坛", 它就直接帮你发好, 不需要每次都给它发送方式, api接口, api密钥等等.
这才是openclaw能火的根本原因. 它开始不仅能做, 还能学.
探索openclaw默认记忆系统布局
openclaw默认采用RAG 双轨记忆模型. 并且没有使用以前对于ai常用的Milvus, Pinecone那种向量数据库.
- 本地优先, 优先考虑隐私保护, 高度透明和用户掌控权.
- 文件优先, markdown是唯一事实来源, 这不仅方便加入到上下文, 还方便了用户可以手动修改, 随时更正.
- sqlite本地引擎, sqlite是个本地数据库, 大部分应用, 手机内部都是这个数据库, 比如微信, qq等等, 我们平常开发软件也会很常用. openclaw采用
sqlite(结合vec扩展)来构建极度轻量的rag引擎, 它把markdown文档chunking(切块), 生成embedding(向量嵌入), 然后存在本地sqlite进行快速检索, 这样 索引+详情的架构, 可以综合速度和质量, 并且本地sqlite也保证了隐私. - 混合检索, 融合了语义向量和关键词匹配(BM25), 即根据意思, 也根据单次, 很好的平衡了召回率和精确度
- ai自主调用记忆, 上面的历史记录和索引, 虽然架构很好了, 但是长期对话对于上下文来说还是过长, 所以openclaw将系统封装成
memory_search和memory_get, 一个搜, 一个读, ai根据我们对话, 自主判断要"回想"哪些记忆. - 智能缓存和增量同步, 我们已有的记忆要缓存, 新的记忆要更改, 总不能每次全部清空记忆去新增. 所以openclaw只对memory的文件里新增部分进行重新embedding, 配合防抖, 降低了embedding模型的使用成本和系统cpu资源
- 向量模型, 支持本地和云端, 自动降级.
- **记忆文件分成 短期工作记忆(memory/2026-03-06.md)和长期精炼记忆(MEMORY.md和SOUL.md, USER.md等等)
- 支持多Agent路由, 不同渠道可以使用不同的记忆空间
- 通过分层信任&沙盒隔离&选择性遗忘来抵抗提示注入与污染
通过以上模型, 把复杂的技术藏在了基本的markdown文件下, 即有长期记忆, 又考虑到了隐私和成本问题.
从配置上简单说明 memory的n种方式
默认的 memory-core + memorySearch
这套起效的关键点在于:
- 需要配置memorySearch模型
- **需要让心跳任务把对话里的重要信息记录到当天
- 定期整理前天记录里的长期事实和记忆, 人物偏好等, 提取到长期记忆文件
memory-lancedb插件+lancedb向量数据库
这套起效的关键点在于:
- 需要手动配置合适的
chunk - 默认是3条记忆召回和记忆全部内容
根据我几天的实践, 400刀左右消耗, 我感觉不合适. 原因如下:
- 乱召回, 由于只是基础的
recall算法, 导致我问一个:请继续, 会召回300字左右的: 论坛配置, 我的编程偏好, 我老婆的人物关系......污染上下文, 让ai回答的更不准, 上下文长了幻觉重了后, 突然就不知道要怎么回复了. - 消耗大, 乱召回带来的上下文额外增大(单个对话输入18w tokens), embedding花费等, 导致成本很高
成本高效果还不好, 我建议别试了.
其他我未测试的外置记忆系统
- Graphiti 时序知识图谱, 对于时间会有很强感知, 比如昨天, 三天前, 上周, 它能准确提供对应记忆
- VecLite , 超轻量, 比sqlite+embedding还轻, 可能适合树莓派那种设备
如果想测试, 可以考虑在主openclaw设备外额外添加一个测试效果. 因为切换记忆系统会影响已存记忆, 一般需要清空重建向量数据库
图片表示配置方法
仅供参考.
结语
今天周日, 昨晚调整记忆一直通宵弄到早上10点, 研究文档, 研究逻辑, 中午才睡, 下午4点起床敲了这么多字, 基于本人的浅薄认知. 希望能给诸位提供点参考意义.