最近 OpenClaw 很火，很多人都在装。
但我发现，真正让很多人上头的，不只是它能接模型、跑 Agent、做自动化，而是另一个更关键的点：

它看起来像“有记忆”。

很多人第一次接触这类 Agent 时，都会有一种很强烈的错觉：

• 它记得我之前说过什么
• 它知道社区里的黑话
• 它好像越来越懂我的上下文
• 它甚至像是“养熟了”

但如果你真的去拆它的实现思路，你会发现：

所谓“记忆”，本质上并不是把所有东西都塞进 Prompt。
真正能落地的记忆系统，一般都是 “外部存储 + 动态召回 + 热度淘汰 + 上下文注入” 这套组合拳。

刚好我看到一个很有意思的 Demo：
它表面上是一个 AI Text2SQL 社区帖子推荐系统，但实际上，里面已经把 Agent 记忆系统最核心的几个设计点都暴露出来了。

今天就借这个 Demo，讲清楚一件事：

OpenClaw 这类 AI Agent 的记忆，到底应该怎么实现。

顺便也说一下，为什么到了真正跑业务的时候，一个稳定、便宜、并发够的模型接入层，比如 vsllm.com，会比“单纯把 Agent 装起来”更重要。

---

一、AI Agent 的“记忆”不是记在脑子里，而是记在外面

先看这个 Demo 的核心结构，你会发现它非常典型：

前端做了什么？

• 提供一个搜索框
• 用户输入自然语言
• 调用大模型把自然语言翻译成 SQL
• 然后本地数据库执行 SQL，返回帖子结果

数据层做了什么？

它不是让模型直接“瞎想”，而是先把帖子都塞进了一个结构化表：

• id
• title
• content
• category
• views
• replies

然后交给 AlaSQL 在前端做查询。

模型层做了什么？

模型真正负责的，其实只有一件事：

把人话翻译成数据库可执行规则。

这件事特别重要。

因为它说明了一个 AI 系统设计的底层原则：

LLM 不应该承担所有状态和所有知识。
LLM 更适合做“理解、翻译、决策”，而不是做长期存储。

这就是很多人第一次做 Agent 时最容易踩的坑：

• 什么都往 Prompt 里塞
• 希望模型“自己记住”
• 每次都把所有历史上下文全喂进去

结果就是：

• 越来越贵
• 越来越慢
• 越来越容易答非所问

---

二、这个 Demo 真正有价值的地方，不是 Text2SQL，而是它已经隐含了“记忆系统”的骨架

很多人看到这段代码，只会觉得这是一个“AI 搜帖子”的小玩具。
但如果你再往后看，你会发现作者后面已经把记忆系统的关键点讲出来了：

1）黑话不能写死

社区里的词是会变的。

比如今天大家说：

• 龙虾 = OpenClaw
• 大狗哥 = 某个核心人物
• 哈基米 = 某种特定模型的说法

但这些词并不是永远有效的。
如果你把它们永久写死在 Prompt 里，过一阵子就会出问题。

---

2）记忆必须“新陈代谢”

作者给出的思路非常像工业界里常见的 Memory 设计：

建一张表，比如 slang_dict：

• 黑话
• 真实含义
• 热度分
• 最后活跃时间

这其实已经不是“提示词工程”了，
而是非常标准的 外部长期记忆（Long-term Memory）。

---

3）检索时只注入“活着的记忆”

真正聪明的做法，不是把整个黑话库塞给模型，而是只拿：

• 最近 30 天活跃过的
• 热度最高的前 20～30 个
• 当前问题最相关的那一小部分

这一步本质上就是：

Memory Retrieval（记忆召回）

也就是说，Agent 不是“全部都记得”，
而是“到了要用的时候，才把最该想起来的东西想起来”。

这就像人脑一样。
你不是随时背着一本 500 页词典在说话，
而是在需要的时候，快速想起几个关键概念。

---

三、所以 OpenClaw 这类 Agent 的“记忆系统”，正确实现方式到底是什么？

如果把这套 Demo 抽象一下，其实已经很接近一个完整的 Agent 记忆架构了。

我更愿意把它拆成四层。

---

第一层：短期记忆（Session Memory）

这是最容易理解的一层。

也就是用户当前这轮对话、最近几轮上下文、当前任务目标。

比如：

• 用户刚才让你搜什么
• 现在是在调试 SQL，还是在找福利帖子
• 上一轮说的“龙虾”是 OpenClaw，不是吃的

这部分通常存在：

• 会话上下文
• 最近 N 轮消息
• 当前任务变量

这层记忆的特点是：

• 生命周期短
• 强依赖当前会话
• 过会儿就可以丢掉

OpenClaw 这种本地 Agent 看起来“会接话”，靠的主要就是这一层。

---

第二层：长期记忆（Long-term Memory）

这个 Demo 真正精彩的地方，就是它已经把长期记忆的影子写出来了。

也就是所谓的：

• 社区黑话
• 用户偏好
• 常见映射
• 历史经验
• 高频规则

这些东西不应该塞在 Prompt 里常驻，
而应该进数据库、KV、向量库，或者至少一张结构化表。

比如你完全可以设计这样的表：

memory_slang

• term：黑话
• meaning：含义
• heat_score：热度
• last_active_at：最后活跃时间
• source_post_id：来源帖子
• confidence：置信度

memory_user_pref

• user_id
• favorite_models
• common_tools
• topic_preference
• updated_at

memory_task_history

• task_type
• query_pattern
• generated_sql
• success_rate
• updated_at

你会发现，一旦这样设计之后，
Agent 的“记忆”就不再是玄学，而是标准的数据工程问题了。

---

第三层：记忆召回（Memory Retrieval）

这是最容易被忽略、但其实最关键的一层。

真正决定 Agent 看起来“聪不聪明”的，不是它存了多少记忆，
而是：

它在当前问题下，能不能把最该拿出来的记忆召回出来。

比如用户说：

有没有大佬发福利送 cursor 或者 codex 账号的？

这时候系统真正要做的，不是把 2000 条社区黑话都扔给模型，
而是先筛：

• cursor
• codex
• 福利
• 抽奖
• 社区里相关的近义说法
• 最近热度高的相关帖子标签

然后把这部分“活记忆”注入 Prompt。

这就是为什么很多 Agent 在真实使用里会越来越像“懂行的人”：

不是它真的无所不知，
而是它在当前上下文里，拿到了最相关的外部记忆。

---

第四层：遗忘机制（Forgetting / TTL）

很多人做记忆系统，只想着“怎么记”，不想着“怎么忘”。

但实际上，不会遗忘的 Agent，最后一定会变笨。

这个 Demo 里后面的解释非常到位：

如果黑话字典只进不出，就会发生三件事：

1）Token 爆炸

每次都带一大堆无关黑话，Prompt 越来越长。

2）语义冲突

一个旧词在今天已经变成了新意思，但系统还抱着旧解释不放。

3）注意力稀释

Prompt 太长之后，模型反而抓不到重点。

所以合理的做法一定是：

• 每天衰减热度
• 长期不用的词自动淘汰
• 新词优先级提升
• 同义词竞争时让近期高热词胜出

这一套其实就是 Agent 记忆系统的“新陈代谢”。

说白了：

真正聪明的系统，不是记得最多，而是忘得也很优雅。

---

四、如果你想自己做一个 OpenClaw 风格的记忆系统，最小可行架构可以怎么搭？

如果按工程视角，我建议至少拆成两个 Agent。

---

Agent A：巡逻 Agent（负责采集和更新记忆）

职责：

• 定时巡查新帖子/新消息
• 提取高频黑话、别名、缩写
• 识别“词 -> 含义”的映射关系
• 更新热度分和最后活跃时间
• 对旧词做衰减
• 清理长期不活跃记忆

它干的事情，本质上像一个“社区语义观察员”。

比如今天社区里突然很多人在说：

• 小龙虾
• 哈基米

Agent A 就负责把这些东西不断归档进外部记忆。

---

Agent B：检索/执行 Agent（负责用记忆）

职责：

• 接收用户当前问题
• 从长期记忆中筛选出最相关的部分
• 动态拼成 Prompt
• 调模型生成 SQL / 检索表达式 / 工具调用参数
• 执行后返回结果
• 把成功案例反写回经验库

你会发现，这其实已经很像一个成熟的 Agent 系统了。

而且关键是：

模型本身不用背所有知识。
模型只负责“理解和推理”，
知识和记忆则交给外部系统管理。

这才是成本、性能、可维护性都更平衡的做法。

---

五、为什么很多人把 Agent 做慢了？问题通常不在 Agent，而在模型接入层

写到这里，其实就可以顺手说到一个很现实的问题了。

很多人现在玩 OpenClaw、做 Agent、接自动化的时候，最先关注的是：

• 怎么装
• 怎么接插件
• 怎么写 Prompt
• 怎么做记忆

但真正用久了，大家最后都会卡在同一个地方：

模型接入层到底稳不稳、贵不贵、并发够不够。

尤其一旦你把记忆系统做起来之后，请求量会明显增加：

• 巡逻 Agent 要定时扫帖子
• 检索 Agent 要高频处理用户输入
• 有时候还要做二次重写、二次召回
• 高峰期一多，并发直接上来

这时候，如果你的模型入口：

• 很贵
• 很慢
• 并发低
• 模型池不全

那你的记忆系统再优雅，最后体验也会打折。

---

六、这也是为什么我现在更倾向把 OpenClaw 这类 Agent 接到 vsllm.com 上

我自己现在的思路就是：

OpenClaw / Agent 负责交互和编排，vsllm.com 负责模型接入层。

这样分层之后，整个系统会清晰很多。

1）Agent 负责“记忆和逻辑”

• 记住什么
• 忘掉什么
• 什么时候召回
• 怎么组 Prompt
• 怎么调用工具

2）vsllm.com 负责“模型和通道”

• 用哪个模型
• 走哪条接口
• 如何兼容不同模型
• 怎么兼顾速度、成本和并发

这套搭法的好处是很实际的：

• 你不用把系统复杂度全背在自己身上
• 不用为了换模型重写一堆逻辑
• 可以更自然地试不同模型
• 对高频记忆召回场景更友好

尤其是你这种“巡逻 Agent + 检索 Agent”的结构，
模型调用不是一两次，而是会持续发生的。
这时候一个稳定的统一入口，比单纯“能用某个模型”重要得多。

---

七、一个很容易被忽略的点：记忆系统不是越复杂越好，而是越“可维护”越好

很多人一听“Agent 记忆系统”，就容易脑补得特别复杂：

• 向量数据库
• 图数据库
• 多级缓存
• 自适应检索
• 记忆蒸馏
• 语义时间衰减网络

这些当然都可以做。
但如果你只是做一个社区搜索、论坛助手、信息检索 Agent，其实没必要一上来就上航母。

像这个 Demo 给出的思路，反而很适合做第一版：

• 结构化帖子表
• 黑话字典表
• 热度分
• 最近活跃时间
• 只召回前 20~30 条活跃记忆
• 动态拼 Prompt
• SQL 检索执行

这一套已经能解决 80% 的问题了。

真正厉害的系统，不是堆最多技术名词，
而是每一层都刚好够用。

---

八、最后总结一下：OpenClaw 这类 Agent 的“记忆”，本质上就是一套外部化记忆工程

如果你只记一句话，我希望是这句：

Agent 的记忆，不是把一切都塞给模型，而是把“该记的东西”放到外部系统里，并在正确的时候召回给模型。

从这个 Demo 里，其实已经能很清楚地看到一套标准思路：

• 用结构化数据保存长期知识
• 用热度和时间来决定什么该留下
• 用召回机制决定什么该注入当前上下文
• 用遗忘机制防止系统越来越笨
• 用大模型只做“理解和翻译”，而不是做存储器

这套思路，拿来做 OpenClaw 记忆系统，完全成立。
拿来做社区搜索 Agent、论坛助手、知识库助手，也一样成立。

而如果你真打算把这套东西从 Demo 做成可长期运行的系统，
那我会建议你从一开始就把模型接入层独立出来。

我自己更倾向的做法，就是让 Agent 只管逻辑，让 vsllm.com 这种统一模型入口来处理模型调用。这样你在做记忆、召回、多模型切换、高并发请求时，会轻松很多。

说到底：

记忆系统决定 Agent 聪不聪明。
模型接入层决定这个聪明，能不能稳定、低成本地跑下去。

这两件事，缺一不可。