全网爆火的龙虾总失忆？大佬亲自下场手搓解药，终结致命痛点

新智元报道

编辑：YHluck

【新智元导读】全网都在养龙虾，但龙虾最大的痛点不是不够聪明，而是「失忆」。TiDB联合创始人兼CTO黄东旭（dongxu）一周前发布了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，全球最知名的开源分布式数据库项目的核心缔造者之一。

TiDB的联合创始人兼CTO黄东旭

这次他没有做PPT、没有写白皮书，而是直接撸了一个产品：mem9.ai。

mem9的核心理念简单到极致：给龙虾一个「云端永续记忆」。

和市面上其他记忆方案不同，mem9的设计哲学带着浓烈的数据库工程师思维：

一虾一库，一虾一密，完全无状态依赖。每个龙虾的数据独立存储、独立加密，不用担心数据安全问题。这不是做一个大杂烩的共享记忆池，而是给每个Agent开了一个独立的数据库实例。

免注册，开箱即用。基于Skill机制无缝接入，用户只需要把一句话发给龙虾，就完成安装。没有注册流程，没有API Key配置，没有繁琐的onboard步骤。

天然支持备份和迁移。换设备、换机器，记忆跟着走。再也不用担心本地文件丢失导致龙虾「死亡」。

向量+全文混合检索。后台使用向量检索和关键词检索双通道召回，确保记忆的语义相关性和精确匹配同时到位。

安装方式简单得令人发指——把这段话发给你的龙虾就行：

请阅读https://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链接：https://github.com/mem9-ai/mem9

技术硬核：

为什么ContextEngine是关键拐点？

如果说第一篇文章是产品发布，第二篇才是真正的技术深水区。

黄东旭拆解了OpenClaw 3.8版本的一个重大更新：「ContextEngine插件接口」的开放。这不是一个普通的hook，而是一整套上下文生命周期管理接口。

之前，OpenClaw的上下文管理是黑盒——什么时候压缩、哪些信息保留、子Agent怎么继承记忆，全部硬编码在core里。插件能做的只是「旁边补一层recall」。

ContextEngine把这些能力全部打开了：

• bootstrap：session启动时，先恢复什么

• assemble：这一轮prompt到底该带什么

• afterTurn / ingest：这一轮结束后，什么该提炼成长期信息

• compact：token紧张时，该压什么、转什么、丢什么

• prepareSubagentSpawn / onSubagentEnded：子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的记忆系统需要同时具备：向量搜索（语义召回：「找到和当前上下文相似的记忆」）、全文检索（关键词召回：「我们讨论过Project X的什么？」）、分析查询（模式识别：「总结上周所有的决策」）、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: https://github.com/mem9-ai/mem9

mem9.ai: https://mem9.ai

TiDB Documentation: https://docs.pingcap.com