2026年最火的不是某个大模型，而是一只龙虾。
OpenClaw——这个源于奥地利程序员Peter Steinberger周末实验的项目，在短短三个月内GitHub星标数突破16万，一周涌入200万人次访客。腾讯云为它在深圳大厦设立了「龙虾安装站」，深圳龙岗区甚至出台了专项扶持政策。
然而，在全民养虾的狂热背后，一个致命的问题正困扰着每一位用户——
你的龙虾，是个金鱼脑。
龙虾的「失忆」有多可怕？
重度用户一定经历过这些场景：
- 正在处理复杂任务时，上下文突然被压缩，龙虾像刚睡醒一样问道：「我们刚刚在做什么来着？」——更令人不安的是，这种情况毫无预警。
- 与龙虾的交互越深入，依赖感越强，但心里总悬着一根弦：万一某次更新导致记忆丢失怎么办？想象一下与你互动了大半年的龙虾突然变得一片空白。
- 当你使用多只龙虾分工协作时，它们之间的记忆完全隔离，关键信息无法同步，重新培养又耗时费力。
这并非个例。OpenClaw当前的记忆系统——基于本地MEMORY.md文件和JSONL日志——本质上是一种「预算管理」机制，而非真正的记忆系统。其压缩功能旨在防止token数量爆炸式增长，但裁剪、压缩、写入记忆和召回，实际上是不同层面的任务。
用黄东旭的话来说：「压缩本质上是一种预算管理，它不应该兼职扮演完整的记忆系统。」
不是TiDB找到了这个问题，是这个问题找上了TiDB
mem9的诞生源于一次意外。
据TiDB产研资深副总裁唐刘（@siddontang）透露，三月初TiDB团队拜访客户，本意是讨论数据库。但几乎每一场对话，最后都转向了同一个话题：OpenClaw。
一些公司已经从CEO到基层员工都在使用OpenClaw。而几乎每个人都在抱怨同一件事：
「我的龙虾聊着聊着就失忆了。讨论过的所有内容——全没了。」
唐刘在博客中写道：当听到每个客户都有这个痛点时，他们感到意外——这个问题并不新鲜，难道之前没有人解决过吗？
于是，在动手之前，团队尝试了市面上所有声称能解决OpenClaw记忆问题的方案。结论是：没有一个是真正开箱即用的。
每个产品都要求用户注册账号、生成API密钥、手动编辑OpenClaw配置文件来添加密钥。对于工程师来说这或许不算什么，但对于只想让龙虾高效工作的CEO，或者不了解JSON文件的市场负责人而言——这足以让人望而却步。
因此，TiDB团队决定自己动手。设计目标只有一个：零注册，一句话安装。
数据库专家亲自下场，一个周末打造出mem9
3月8日，一篇标题直白的文章在开发者社区引发了热议——《脑子是个好东西：最好的龙虾记忆方案：mem9》。
作者是黄东旭（dongxu）。他是TiDB的联合创始人兼CTO，也是全球知名开源分布式数据库项目的核心缔造者之一。
TiDB联合创始人兼CTO黄东旭
这次，他没有制作PPT或撰写白皮书，而是直接开发了一款产品：mem9.ai。
mem9的核心理念极其简洁：为龙虾提供「云端永续记忆」。
与市面上其他方案不同，mem9的设计哲学带有鲜明的数据库工程师思维：
- 一虾一库，一虾一密，完全无状态依赖。 每个龙虾的数据独立存储、独立加密，无需担心数据安全问题。这不是构建一个共享记忆池，而是为每个智能体提供一个独立的数据库实例。
- 免注册，开箱即用。 基于Skill机制无缝接入，用户只需向龙虾发送一句话，即可完成安装。没有注册流程，无需配置API密钥，省去了繁琐的入门步骤。
- 天然支持备份和迁移。 更换设备或机器时，记忆可以随之迁移。再也不用担心因本地文件丢失而导致龙虾「失忆」。
- 向量与全文混合检索。 后台采用向量检索和关键词检索双通道召回，确保记忆的语义相关性和精确匹配都能得到满足。
安装方式简单到令人惊讶——只需将这段话发送给你的龙虾：
请阅读https://mem9.ai/SKILL.md并按照说明安装和配置mem9以用于 OpenClaw，安装完成后告诉我你能做什么🦞
就这样，即可完成。
「记忆可视化」：mem9上线个人记忆空间
就在本文发稿前，mem9又发布了一项重要功能——「个人记忆空间」正式上线。
访问 mem9.ai/your-memory，输入你的Space ID（即安装时自动生成的API密钥，如果忘记可以直接询问你的龙虾），你就能看到你的龙虾记住了什么。这是一个真正的「记忆仪表盘」——不是模糊的感觉，而是清晰列出每一条被持久化的记忆。
其逻辑非常简单：
- 自动沉淀。 你与龙虾的每次对话中，重要信息会被自动提取并存入记忆空间。
- 主动指定。 你也可以直接告诉龙虾「记住这个」，它会将你指定的内容写入永久记忆。
- 完全透明。 仪表盘会完整展示所有已保存的记忆条目——你的龙虾记住了什么，一目了然。
这一设计理念与OpenClaw原生的记忆系统形成了鲜明对比。OpenClaw的MEMORY.md文件像一个黑箱——你只知道龙虾「大概记得一些东西」，但具体记了什么、丢了什么，无从知晓。
而mem9的记忆空间让记忆变成了一项可查看、可审计、可控制的资产——你的智能体记住了什么，从此不再是一种「感觉」，而是一个「事实」。
社区反响热烈
文章发布后，评论区反响热烈：
- 湖北用户： 太棒了，使用mem9后，龙虾就不再依赖于某一特定设备或终端了。就像更换不同的手机，却能使用同一个记录永存的微信。
- 上海用户： 永续记忆意味着记忆库会越来越大吧？另外，我觉得很多场景下，多个龙虾需要共享文档来协作，不知道你们是如何考虑的。——作者回复：已有相关规划。
- 上海用户： 太好了，今天因为memory search报错导致记忆读取失败，我暂时禁用了mem9。我发现小龙虾还有个问题，就是不知道应该记住什么。特别是在会话中断后，它完全记不住之前聊过的内容。
- 浙江用户： 如何评估mem9的有效性？好奇它与supermemory等产品的效果对比。
- 上海用户： 被我看出来是致敬Plan 9了——作者回复：后续还会有更多「9」。
还有人直接询问：mem9是完全开源的么？
作者给出了GitHub链接：https://github.com/mem9-ai/mem9
技术解析：为什么ContextEngine是关键转折点？
如果说第一篇文章是产品发布，那么黄东旭随后发布的第二篇文章则深入了技术层面。
他详细解读了OpenClaw 3.8版本的一个重要更新：开放了「ContextEngine插件接口」。这不仅仅是一个简单的钩子，而是一整套用于管理上下文生命周期的接口。
在此之前，OpenClaw的上下文管理是一个黑盒——何时压缩、保留哪些信息、子智能体如何继承记忆，全部硬编码在核心代码中。插件所能做的只是在「旁边补充一层召回机制」。
ContextEngine开放了以下关键能力：
- bootstrap： 会话启动时，首先恢复哪些信息。
- assemble： 本轮提示中究竟应该包含哪些内容。
- afterTurn / ingest： 本轮交互结束后，哪些内容应该被提炼为长期记忆。
- compact：在Token紧张时，决定压缩、转换或丢弃哪些记忆。
- prepareSubagentSpawn / onSubagentEnded：管理子Agent之间的记忆继承与隔离。
这意味着mem9能够深度参与甚至主导Agent的整个上下文生命周期——它不再是一个“外挂的记忆后端”，而是成为了Agent的“第二大脑”。
值得注意的是，这一方案的推出时机恰到好处。据唐刘透露，mem9上线后不久，OpenClaw就发布了支持ContextEngine的新版本——这是一个专门为外部记忆服务设计的官方接口框架。
“我们的时机纯属巧合，但完美契合。” 自此，mem9不再是一个绕过OpenClaw的临时方案，而是与其官方架构深度集成的原生服务。
黄东旭总结了三个关键收益：记忆处理更及时（无需等待压缩时才被动抢救）、上下文装配更精准（可按需携带记忆而非全部塞入）、多Agent协作终于有了合理边界（记忆的继承、隔离与回流都有了正式接口）。
为什么只有TiDB能支撑这样的服务？
你可能会问：Agent记忆系统看起来并不复杂，谁都可以做吧？
唐刘在其博客中正面回应了这个问题。他坦言，AI时代开发软件确实变容易了，mem9的大部分代码都是快速原型开发的产物。但能在一个周末内上线并运行，依赖的不是AI，而是TiDB Cloud。
原因有三：
第一，“一Agent一实例”对数据库平台的要求极其苛刻。
mem9为每个OpenClaw Agent都创建了一个独立的数据库实例——这不是共享数据库加行级隔离，而是真正的独立实例。这意味着如果mem9拥有100万用户，就需要管理100万个数据库实例。
在任何传统数据库服务上，这个数量级的成本和管理复杂度都是天文数字。而TiDB Cloud的实例可以在空闲时缩容至接近零成本，并实现按需弹性伸缩——这是目前极少数能在此密度下经济高效运行的数据库平台。
第二，记忆的核心不仅是“存”，更是“找”。
你可以将记忆数据存入对象存储，成本低廉且易于扩容。但记忆系统的核心在于检索、召回与关联。
一个Agent的记忆系统需要同时具备：向量搜索（语义召回：“找到与当前上下文相似的记忆”）、全文检索（关键词召回：“我们讨论过Project X的哪些内容？”）、分析查询（模式识别：“总结上周所有的决策”）、ACID事务（保证多Agent共享记忆空间时的一致性）。
这不是对象存储能解决的问题，而是数据库的专长。随着记忆按周、月、年不断累积，数据量没有上限——传统单机数据库迟早会遇到瓶颈。你需要一个从设计之初就具备水平扩展能力的方案。
第三，将上述两个需求叠加，选择变得唯一。
对单个Agent的记忆而言：需要一个同时支持向量搜索、全文检索和分析查询的多模态分布式数据库。
对mem9整体服务而言：需要一个能以极低成本供应和管理百万级独立实例的数据库平台。
唐刘的结论很直接：“没有TiDB Cloud，我们无法满足其中任何一个需求——更不用说同时满足两者。”
事实上，不仅是mem9。在整个AI Agent生态中，TiDB正成为越来越多AI公司的底层选择。
例如，备受关注的AI Agent创业公司Manus AI，其多Agent协作系统在生产环境中完全使用TiDB承载所有业务请求，包括并发任务状态管理、实时决策分析，以及为每个Agent提供独立的数据库支持。
为什么这些公司选择TiDB？
因为Agent对数据库的需求极为复杂——同时需要高速写入（对话流、工具调用日志）和复杂分析（跨会话检索、关系推理），需要应对极端的负载波动并实现弹性伸缩，需要支持向量和关系数据的混合查询，需要实现数百万级别的租户隔离，还需要Schema能够灵活演进。
纯关系型数据库难以处理向量检索，纯向量数据库则难以应对复杂的关系查询和事务，NoSQL数据库又缺乏ACID保证。而TiDB是目前极少数同时具备MySQL兼容性、分布式HTAP架构和原生向量检索能力的开源数据库，恰好全面覆盖了这些需求。
黄东旭本人在相关文章中写道：“对于记忆，是否一定是本地优先（Local-first）我是存疑的，毕竟云端记忆的体验一定会更好。”
这句话的潜台词是：记忆的未来在云端，而云端记忆需要一个足够强大的数据库来承载。
这个数据库，就是TiDB。
当数十万开发者开始为其Agent寻求“永续记忆”时，真正的战场不在模型层，也不在框架层，而在数据层。
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
关注“鲸栖”小程序，掌握最新AI资讯
本文来自网络搜集，不代表鲸林向海立场，如有侵权，联系删除。转载请注明出处：https://www.itsolotime.com/archives/25811
