本文转载自公众号新智元。
全网都在养龙虾，但龙虾最大的痛点不是不够聪明，而是「失忆」。TiDB 联合创始人兼 CTO 黄东旭一周前发布了 mem9.ai —— 一个免注册、开箱即用的永续记忆服务，一经发布直接引爆开发者社区。
2026 年最火的不是某个大模型，是一只龙虾。
OpenClaw —— 这个从奥地利程序员 Peter Steinberger 的一个周末实验中诞生的项目，短短三个月 GitHub 星标破 16 万，一周涌入 200 万人次访客，腾讯云为它在深圳大厦摆出「龙虾安装站」，深圳龙岗区甚至出了专项扶持政策。
全民养虾的狂热背后，一个致命的问题正在困扰着每一个虾农——
你的龙虾，是个金鱼脑。
龙虾的「失忆」有多可怕？
重度养虾用户一定经历过这些场景：
上下文突然压缩 —— 正在一个复杂任务里连续推进，突然上下文一压缩（Compact），龙虾像刚睡醒一样问你：「我们刚刚在做什么来着？」——更恐怖的是，这种事根本不会提前打招呼。
记忆无法持久 —— 越聊越有感情，越用越离不开，但心里总有一根弦：万一哪次更新把记忆搞挂了怎么办？想象一下和你聊了大半年的龙虾突然什么都不记得了。
多虾协作困难 —— 你有多只龙虾分工协作，但它们之间的记忆完全隔离，关键信息没法同步，又懒得重新养一遍。
这不是个例。OpenClaw 的记忆系统——基于本地 MEMORY.md 文件和 JSONL 日志——本质上是「预算管理」，不是真正的记忆系统。Compaction 负责裁剪上下文防止 token 爆炸，但裁剪、压缩、写记忆、召回，其实是完全不同层面的事。
「Compaction 这个东西，本质是预算管理，不该兼职扮演完整的记忆系统。」
—— 黄东旭
不是 TiDB 找到了这个问题，是这个问题找上了 TiDB
mem9 的诞生，其实源于一个意外。
据 TiDB 产研资深副总裁唐刘（@siddontang）披露，三月初 TiDB 团队拜访客户，本来是去聊数据库的。但每一场对话，最后都拐到了同一个地方：OpenClaw。
有些公司已经从 CEO 到基层员工全员养虾。而几乎每个人都在抱怨同一件事：
「我的龙虾聊着聊着就失忆了。讨论的所有内容——全没了。」
唐刘在博客中写道：当听到每个客户都有这个痛点时，他们其实很意外——这个问题不新鲜，难道没人解决过吗？
于是在动手之前，团队把市面上所有号称解决 OpenClaw 记忆问题的方案全部试了一遍。结论是：没有一个是开箱即用的。
每个产品都要求用户注册账号、生成 API Token、手动编辑 OpenClaw 配置文件来添加 Token。对工程师来说这不算什么，但对那个只想让龙虾好好干活的 CEO、对那个不知道 JSON 文件是什么的市场负责人来说——这就是劝退。
于是 TiDB 团队决定自己干。设计目标只有一个：零注册，一句话安装。
数据库大佬亲自下场，一个周末写出 mem9
3 月 8 日，一篇标题极其直白的文章在开发者社区炸开了——《脑子是个好东西：最好的龙虾记忆方案：mem9》。
作者是黄东旭（dongxu），微信公众号「我世界的源代码」。如果你不认识他——他是 TiDB 的联合创始人兼 CTO，全球最知名的开源分布式数据库项目的核心缔造者之一。
这次他没有做 PPT、没有写白皮书，而是直接撸了一个产品：mem9.ai。
核心设计理念
mem9 的核心理念简单到极致：给龙虾一个「云端永续记忆」。
和市面上其他记忆方案不同，mem9 的设计哲学带着浓烈的数据库工程师思维：
🔒 一虾一库，一虾一密，完全无状态依赖。
每个龙虾的数据独立存储、独立加密，不用担心数据安全问题。这不是做一个大杂烩的共享记忆池，而是给每个 Agent 开了一个独立的数据库实例。
⚡ 免注册，开箱即用
基于 Skill 机制无缝接入，用户只需要把一句话发给龙虾，就完成安装。没有注册流程，没有 API Key 配置，没有繁琐的 onboard 步骤。
💾 天然支持备份和迁移
换设备、换机器，记忆跟着走。再也不用担心本地文件丢失导致龙虾「死亡」。
🔍 向量+全文混合检索
后台使用向量检索和关键词检索双通道召回，确保记忆的语义相关性和精确匹配同时到位。
Install
安装方式简单得令人发指——把这段话发给你的龙虾就行：
请阅读 mem9.ai/SKILL.md 并按照说明安装和配置 mem9 以用于 OpenClaw，安装完成后告诉我你能做什么🦞
就这样，没了。
「记忆可视化」：mem9 今日上线个人记忆空间
就在本文发稿前，mem9 又放了一个大招——「个人记忆空间」（Memory Space）正式上线。
打开 mem9.ai/your-memory，输入你的 Space ID（即 API Key，安装时自动生成的私钥，如果你忘了也可以直接问你的龙虾），你就能看到你的龙虾记住了什么。
这是一个真正的「记忆仪表盘」——不是模糊的「它大概记得」，而是白纸黑字列出每一条被持久化的记忆。
它的逻辑极其简单：
第一，自动沉淀。你和龙虾的每次对话，重要信息会自动被提取并存入记忆空间。
第二，主动指定。你也可以直接告诉龙虾「记住这个」，它会把你指定的内容写入永久记忆。
第三，完全透明。Dashboard 会完整展示所有已保存的记忆条目——你的龙虾记住了什么，打开页面一目了然。
这个设计背后的哲学和 OpenClaw 原生记忆系统形成了鲜明对比。OpenClaw 的 MEMORY.md 是一个黑箱——你知道龙虾「大概记得一些东西」，但具体记了什么、丢了什么，你心里没数。
而 mem9 的 Memory Space 让记忆变成了一个可查看、可审计、可控的资产——你的 Agent 记住了什么，从此不再是一个「感觉」，而是一个「事实」。
评论区炸了：就像换不同的手机，使用同一个记录永存的微信
文章发布后，评论区的画风非常真实：
📍 湖北：太牛了，用了 mem9，龙虾就不依赖某一个设备和终端了。就像换不同的手机，使用同一个记录永存的微信。
📍 上海：永续记忆意味着 memory 越来越大吧，另外我觉得很多场景下，多个虾是需要共享文档来协作的，不知道你是怎么考虑的。——作者回复：有考虑的。
📍 上海：太好了，今天因为 memory search 报错导致记忆读不到把 mem9 禁用了。我发现小龙虾还有个问题就是不知道该记什么。特别是 session 中断之后，它完全记不住之前聊过的内容。
📍 浙江：如何评测 mem9 的有效性？好奇对比一下 supermemory 等产品效果呢？
📍 上海：被我看出来是致敬 plan9 了——作者回复：后续还有更多 9。
还有人直接问：mem9 是完全开源的吗？
作者甩出了 GitHub 链接：github.com/mem9-ai/mem…
技术硬核：为什么 ContextEngine 是关键拐点？
如果说第一篇文章是产品发布，第二篇才是真正的技术深水区。
黄东旭拆解了 OpenClaw 3.8 版本的一个重大更新：「ContextEngine 插件接口」的开放。这不是一个普通的 hook，而是一整套上下文生命周期管理接口。
之前，OpenClaw 的上下文管理是黑盒——什么时候压缩、哪些信息保留、子 Agent 怎么继承记忆，全部硬编码在 core 里。插件能做的只是「旁边补一层 recall」。
ContextEngine 把这些能力全部打开了：
| bootstrap | session 启动时，先恢复什么 |
| assemble | 这一轮 prompt 到底该带什么 |
| afterTurn / ingest | 这一轮结束后，什么该提炼成长期信息 |
| compact | token 紧张时，该压什么、转什么、丢什么 |
| prepareSubagentSpawn | 子 Agent 之间的记忆继承和隔离 |
这意味着 mem9 可以直接参与甚至主导龙虾的整条上下文生命周期——不再是「外挂 memory backend」，而是成为龙虾的**「第二大脑」**。
有趣的是，这个时间节点卡得刚刚好。据唐刘透露，mem9 上线后没多久，OpenClaw 就发布了支持 ContextEngine 的新版本——一个专门为外部记忆服务商设计的官方接口框架。
「我们的时机纯属巧合，但完美。」
mem9 从此不再是绕过 OpenClaw 的 workaround，而是与其官方架构深度配合的原生方案。
黄东旭总结了三个关键收益：
-
记忆处理更及时
—— 不用等 compact 才被动抢救
-
上下文装配更精准
—— 按需带记忆而非全塞进去
-
多 Agent 协作终于有了合理边界
—— 记忆继承、隔离、回流都有正式接口
为什么只有 TiDB 能撑住这件事？
看到这里你可能会问：Agent 记忆看起来不复杂，谁都能做吧？
唐刘在 X 博客中正面回应了这个问题。他坦言，AI 时代造软件确实变容易了，mem9 本身大部分代码都是「vibe coded」。但能在一个周末就上线，靠的不是 AI，是 TiDB Cloud。
原因有三：
第一，「一虾一库」对数据库平台的要求极其苛刻。
mem9 给每个 OpenClaw 都开了一个独立的数据库实例——不是共享数据库加行级隔离，而是真正的独立实例。这意味着如果 mem9 达到 100 万用户，就是 100 万个数据库实例。
在任何传统数据库服务上，这个数量级的成本和管理复杂度都是天文数字。而 TiDB Cloud 的实例可以在空闲时缩容到接近零成本，按需弹性伸缩——这是目前极少数能在这个密度下运行的数据库平台。
第二，记忆不只是「存」，更是「找」。
你可以把记忆扔进 S3，便宜又能扩容。但记忆的核心不是存储，而是检索、召回和关联。
一个 Agent 的记忆系统需要同时具备：向量搜索（语义召回）、全文检索（关键词召回）、分析查询（模式识别）、ACID 事务（多 Agent 共享记忆空间时的一致性保证）。
这不是对象存储能搞定的事。这是一个数据库的活。而且随着记忆按周、按月、按年累积，数据量没有上限——传统单机数据库迟早会撞墙。你需要一个从第一天就具备水平扩展能力的方案。
第三，把上面两个需求叠在一起，选项只剩一个。
对每个 Agent 的记忆来说：需要一个同时支持向量搜索、全文检索和分析查询的多模态分布式数据库。
对 mem9 整体服务来说：需要一个能以极低成本供应和管理百万级实例的数据库平台。
「没有 TiDB Cloud，我们两个需求都满足不了——更别说同时满足。」
—— 唐刘
其实不只是 mem9。在整个 AI Agent 生态中，TiDB 正在成为越来越多 AI 公司的底层选择。
🏢 Manus AI
2026 年全球最受关注的 AI Agent 创业公司之一，其多 Agent 协作系统在生产环境完全使用 TiDB 承载所有业务请求，包括并发任务状态管理、实时决策分析，以及每个 Agent 独立的数据库。
为什么这些公司选 TiDB？
因为 Agent 对数据库的需求极其「变态」——同时需要高速写入（对话流、工具调用日志）和复杂分析（跨会话检索、关系推理），需要弹性伸缩（负载波动极端剧烈），需要向量和关系混合查询，需要数百万级别的租户隔离，需要 Schema 灵活演进。
纯关系型数据库搞不定向量检索，纯向量库搞不定复杂关系查询和事务，NoSQL 缺乏 ACID 保证。而 TiDB 是目前极少数同时具备 MySQL 兼容性、分布式 HTAP 架构和原生向量检索能力的开源数据库，刚好把这些需求全 cover 了。
「对于记忆，是否一定是 Local-first 我是存疑的，毕竟云端记忆的体验一定是更好的。」
—— 黄东旭
这句话背后的潜台词是：记忆的未来在云端，而云端记忆需要一个足够强的数据库来承载。
这个数据库，就是 TiDB。
当 16 万星标的龙虾们开始需要「永续记忆」的时候，真正的战场不在模型层，不在框架层，而在数据层。
mem9 只是开始。
黄东旭说了：「后续还有更多 9。」
参考资料
-
黄东旭, 《脑子是个好东西：最好的龙虾记忆方案：mem9》, 我世界的源代码, 2026.3.8
-
黄东旭, 《解析 OpenClaw 26.3.8 大更新及 mem9 如何利用新 ContextEngine 接口实现全周期记忆管理》, 我世界的源代码, 2026.3.10
-
唐刘, "How We Shipped an Unlimited Memory Service for OpenClaw in 24 Hours", 2026.3
-
GitHub: github.com/mem9-ai/mem…
-
mem9.ai: mem9.ai
-
TiDB Documentation: docs.pingcap.com
