当信息过载成为常态，如何让AI真正记住你的思考脉络？本文作者从搭建个人AI记忆系统的实战出发，揭示了RULbot系统背后的四层压缩架构与手工补丁智慧。从日志分析到技能沉淀，这套融合了Obsidian、Claude的「土办法」竟与Hermes Agent的设计哲学惊人一致，更提炼出关于记忆透明度、技能进化与概念映射的独到见解——这或许是最硬核的AI产品经理成长笔记。
当我开始给自己搭一套个人 AI 记忆系统时，本意并不是追前沿，而是解决一个很具体的问题：每天吸收了很多信息，但几天以后，我常常忘掉“自己为什么会做这个判断”。3 个月后，当我回头看 Hermes Agent 和 OpenClaw 的记忆设计，才意识到我踩过的那些坑，恰好就是 AI Memory 这条线正在解决的核心问题。
这篇文章不讲模型参数，也不做框架翻译。我想复盘的是：一个非技术出身的产品人，为什么会自己做一套记忆系统；这套系统是怎么跑起来的；以及这段实践最后给了我哪些对 AI 产品更有用的判断。
2026 年 1 月，我开始系统转向 AI 产品。我没有 CS 背景，上份工作是开饮品连锁店，半年前连终端都不会用。
那段时间我有一个很明显的感受：信息越来越多，但判断越来越散。每天都在看课程、案例、工具、行业动态，也在记录自己跟 AI 协作时的踩坑经历。表面上看，我是在“持续输入”；但过一阵子回头看，很多真正重要的东西已经丢了。
我后来发现，我想保存的不是素材本身，而是几类更关键的信息：
普通笔记工具能帮我记事，但很难帮我看见模式；聊天工具能陪我讨论，但跨会话之后上下文就断了。所以我当时给这个问题下了一个很朴素的定义：我不是缺一个记录工具，我是缺一个能持续“记住我自己”的系统。
这套系统后来被我叫作 RULbot。名字不复杂，就是我名字的缩写。
它的底层并不神秘，核心就是把“记录、存储、分析、压缩”这几件事拆开做：
这里最重要的不是“用了什么工具”，而是我后面补上的那层压缩结构。
我一开始只是想先把内容存下来，后来很快发现，如果没有压缩层，越记越乱。于是我把系统拆成了四层：
现在回头看，这其实已经很接近一个最小可用版的 Memory 架构了。短期信息先完整保留，时间一拉长，就不断往上压成更高层的判断。
另一个后来被我证明很有价值的动作，是把“怎么分析日志”这件事写成文档，而不是每次临场发挥。因为一旦方法被写下来，系统保存的不只是内容，还保存了“下次怎么做”。
这套系统搭到第三周时，我遇到一个很现实的问题：Claude 没有跨会话记忆。
今天聊得很深入，明天再开一个新窗口，它还是得重新认识我。最烦的时候，同一段背景我要反复讲两三遍。前面做过的总结，像是没有真正积累下来。
后来我试了一个很笨的补丁：既然模型本身记不住，那我就把阶段性总结先喂给它。
于是我把月度总览和阶段总结文件放进每次对话前的上下文里。严格说，这不是什么技术突破，就是一种非常手工的补丁。但效果比我预期得好得多。它给出的建议开始明显更贴近我的真实状态，而不是那种谁都能套上的通用表达。
那天我在自己的记录里写过一句话：Claude 没有记忆，Obsidian 里的总结文件，就是它的记忆。
后来我回头看，这句话其实已经触到 AI Memory 的核心了：模型不是记忆体，外部文档才是。
4 月初我开始系统看 Hermes Agent 和 OpenClaw 的资料。真正让我有共鸣的，不是某个单点功能，而是它们的设计思路和我这套“土办法”高度同构。
我的系统是每日日志、十日报告、月度总览、人生成长报告，信息一层层往上压。
Hermes 和 OpenClaw 的命名不同，但本质也在解决同一个问题：什么内容该留在当前会话，什么内容应该沉淀为日常记录，什么内容该进入长期记忆，什么内容最后要变成可调用的经验。
这让我后来越来越相信，分层不是“高级玩法”，而是记忆系统能不能真正可用的前提。
我后来越来越依赖 Markdown 文档，不是为了“显得工程化”，而是因为它足够朴素：人能看，能改，能版本管理，也不容易被平台锁死。
OpenClaw 的官方文档里直接写到，模型只会“记住”被写进磁盘的内容，没有隐藏状态。Hermes 也把 memory 和 skill 这类能力建立在外部文件之上。
从产品角度看，这件事很重要。因为用户真正能信任的记忆，通常不是一个看不见的黑盒，而是一个他能回头检查、能手动修正的外部载体。
我最开始只是把日志分析流程写成一个可复用文档，方便后面重复调用。
但 Hermes 给我的启发更明确：真正有价值的，不只是“记住发生过什么”，而是“记住下次怎么做”。前者更像档案，后者才更接近能力。
这也是为什么我后来会把 Skill 理解成记忆的一种高级形态。它保存的不是信息片段，而是做事路径。
我现在自己的做法还比较“轻”，前期更多靠标签和目录结构，后期再叠加总结和语义理解。
但这段实践至少让我确认了一件事：检索从来不是纯语义问题。前期结构如果是乱的，后面再聪明的语义搜索也很难救回来；反过来，如果只有目录和标签，没有语义归纳，很多跨主题的关联也找不出来。
所以我现在更倾向把 Memory 看成一套组合能力：结构化存放 + 逐层压缩 + 按需检索。
很多人谈 Memory，第一反应是让 AI “记住更多东西”。但我自己做完之后最大的体会反而是：容量不是最难的，压缩才是。
因为原始信息一多，如果没有压缩层，后面根本用不起来。把几十天的日志一股脑塞进 context，表面上什么都在，实际上什么重点都没有。
所以我现在会把 Memory 的核心能力理解成一句话：不是保留所有细节，而是保留对后续判断最有用的模式。
这套系统我之所以后来越来越离不开，很重要的原因是：我随时能回头看它到底记了什么，也能手动修改它记错的地方。
这件事放到产品层面，我觉得也是一样的。尤其是跟“人”的长期信息有关时，如果系统只告诉你“我记住了”，却不告诉你“我具体记了什么”，用户其实很难放心。
所以对 AI 产品来说，能被人看见、能被人修正的记忆，往往比“记得更多”更重要。
以前我也会下意识用“能接多少工具”来判断一个 Agent 是否强大。
但做完这套系统以后，我反而越来越觉得，工具更像手脚，Skill 更像方法。工具多，不等于会做事；方法一旦被沉淀下来，下一次遇到类似问题，系统就不会从零开始。
所以如果把 Memory 只理解成“存信息”，其实有点窄。对 Agent 来说，更有价值的记忆，往往是那些已经被验证过、可以复用的做事方式。
如果说前面这些判断更多是在“存”和“找”的层面，那我自己最感兴趣的，其实是再往前一步：系统能不能理解事件之间的结构关系。
我在长期整理日志时，越来越习惯用跨学科概念来理解自己的变化。比如等待中的消耗，更像阻尼振荡；某几个阶段的突然跃迁，更像相变；信噪比提升后，最直接的感受不是“更有收获”，而是“原本能忍受的噪音突然变吵了”。
这些表达对我不是修辞，它们真的会反过来影响我怎么解释一个新事件。
这也是我目前觉得很多 AI Memory 系统还没完全做到的地方：它们已经很擅长存储与检索，但在“概念和概念之间如何建立稳定连接”这件事上，还有很大空间。如果这一层做起来，Memory 才更像理解系统，而不只是资料系统。
做完这套系统以后，我对 AI Memory 的理解其实不是来自论文，而是来自踩坑。
你只要亲手搭一遍，很快就会遇到几个绕不过去的问题。
第一，压缩到底怎么做。十天的东西要压成一页，什么该留、什么该丢，这根本不是机械问题，而是判断问题。
第二，结构到底有多重要。前面分类和命名一旦做乱了，后面再强的检索能力也会受限。
第三，AI 协作是有副作用的。我有一段时间太依赖 AI 帮我整理结构，结果在一些需要临场组织观点的场景里，反而更容易卡住。以前我会自己画思维导图，把乱的东西一点点掰顺；后来很多这类动作被外包了，人是轻松了，但某些能力也确实会变钝。
所以我现在其实不太相信，只靠几张 demo 图或者一篇框架解析，就能真正把 Memory 这件事讲透。你自己搭过一次，很多判断会完全不一样。
我后来发现，我做的很多项目，底层都在做同一件事：把那些平时不容易被注意到、但又真的有用的信息，慢慢变得可见。
日志分析系统是这样，Hermes 这类 Agent Memory 也是这样。
4 月 10 日晚上，我听一个播客，里面反复提到几个词：主体性、认知、context、日记。我当时愣了一下，因为那就是我这几个月每天都在处理的东西。只不过我不是先从概念出发，而是先从自己的问题出发。
我以前做运营助手平台时，先埋头清洗了三年的门店数据，后来才知道那套东西叫 RAG。现在我先搭了一套四层日志压缩系统，后来才知道它和 AI Memory 的思路很像。朋友开玩笑说，我是“干中学”，总是先做了，才知道它在行业里叫什么。
如果你也在做 AI 产品，我会很建议你：别只盯着别人的架构图。先给自己搭一套能用的记忆系统。哪怕前期很笨，哪怕很多步骤还是手工的，只要它真的在帮你理解自己、复盘自己、积累自己，这段实践最后带给你的判断，往往比“看懂一个热门框架”更扎实。
本文由 @汝霖Rynn 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。