“它是 Agent Native 时代的第一个爆款产品，它设置了这个时代的产品及格线。”正如黄东旭所言，“龙虾”（OpenClaw）之所以能掀起了全民“养虾”的热潮，从产品角度看，是其强大的工具调用和任务规划能力决定了它旺盛的生命力。
然而，当越来越多开发者试图将“龙虾”从玩具变成生产力工具时，一个让人崩溃的痛点开始集中爆发：“龙虾脑雾”。
你好不容易调教好一个专属 Agent，给它增加了一堆 Skill，但仅仅因为一次对话过长触发了上下文压缩，或者换了一台设备，它突然就“失忆”了。它忘了前天你们讨论过的关键细节，甚至忘了自己是谁。
如果 Agent 无法拥有稳定、可靠的长期记忆，所谓的“数字员工”就永远只能是一个每次都要重新培训的实习生。面对这个痛点，目前的行业主流解法是“打补丁”：用向量数据库做外挂检索。但这真的足够吗？
在本期《极客有约》中，InfoQ 极客传媒总经理兼总编辑王一鹏邀请到了 TiDB 联合创始人兼 CTO 黄东旭。黄东旭是开源分布式数据库 TiDB 项目发起人，专注于分布式系统、数据库内核与云原生架构领域十余年。近年来深入研究 AI 基础设施与 Agent 系统架构，探索大模型时代的数据存储与计算范式变革。他最近更是跨界为“龙虾”开发了一款名为 mem9 的记忆插件。他拒绝了简单的向量检索路线，试图用数据库的底层逻辑和“一虾一库”的硬核架构，重构 Agent 的记忆边界。
这场对话不仅是对“龙虾”记忆痛点的硬核拆解，更是一次关于 AI 时代数据基础设施演进的深度前瞻。在未来的 Agent 版图中，TiDB 正在试图确立其作为“Agent 数据基础设施首选”的全新站位。
代码与“龙虾”：为什么必须自己解决记忆问题？
王一鹏：作为 TiDB 的 CTO，怎么突然跑去给 OpenClaw 写记忆插件？你提到的“龙虾脑雾”具体是个什么坑？
黄东旭： OpenClaw 它设定了 Agent Native 时代爆款产品的一个及格线。我从它诞生第一天起就在深度使用。
Agent 这种产品不像过去的 Chatbot（比如 ChatGPT）。Chatbot 每次开启对话都是一个 New Session，只在当前 Session 范围内聊，这其实是因为大模型上下文窗口的限制，强迫开新 Session 避免失忆。但龙虾没有 Session 的概念，它是一个有序的、无限的对话历史。
这就带来了一个问题：当对话太长，大模型的上下文窗口快满时，它会触发不定时的 Compaction（上下文压缩）。它会对现有的上下文进行高度概括和压缩，变成一段记忆存到文件里。如果你正让龙虾做一件严肃的事，或者聊得正嗨，突然触发了垃圾回收，它的下一句话就不知道你前面在说什么了。这就是我说的“脑雾”。
王一鹏：你刚才提到这个记忆压缩，什么机制决定它会触发压缩？遍历太深，为了节省推理时间吗？
黄东旭： 差不多，我们跟龙虾聊天，它的上下文窗口里不只有对话信息，还有调用后台工具产生的输出。当大模型的上下文窗口快满时，为了让新的信息能进来，它会对现有的上下文进行高度概括和压缩，变成一段记忆存到文件里。
这就相当于你让它精准回忆上一条信息是什么，它可能就忘了，只知道上一段的一句话总结。而且龙虾早期的记忆系统做得很粗糙，就是一堆 Markdown 文件。我当时很担心，如果我的电脑坏了，我的小龙虾是不是就“养死”了？所以我想先做一个云端的记忆备份，做着做着发现，正好可以把记忆的召回也顺便解决了。
王一鹏：现在主流方案是用向量数据库做外挂记忆，为什么你认为这没能彻底解决问题？
黄东旭： 一个理想的记忆系统应该有两部分：一部分是 Context 管理，也就是大模型宝贵的上下文窗口（相当于内存），这部分依赖模型厂商扩大窗口和提升 KV Cache 的召回率；另一部分就是外挂的“小本本”，也就是持久化存储。
过去大家一想到外挂记忆，下意识就觉得是 RAG（检索增强生成）和向量数据库。但我的观点是，向量只是完整外置记忆系统中的一个小 Feature，光有向量是没用的。
向量搜索的原理是把文本和语义变成高维空间中的点，通过距离相近来检索。但它有两个大问题：
第一，它不精准，没有联想和因果关系。比如我搜“数码产品”，它能关联到“苹果手机”，但关联不到“我昨天买了苹果手机”，因为它没有时间顺序和谓词关系。
第二，它无法精准控制。有时候我就是想查“数码产品”这四个字，这时候就需要全文检索；有时候我需要查最近的原始聊天记录，这就需要基于上下文的 Filter。
所以，把记忆问题粗暴地归纳为向量搜索是很奇怪的。就像做饭不能只用菜刀，还得有锅和灶台。一个完整的记忆系统，是由多种数据表征和查询方式组合在一起的。但这里面必须有一个 Unify（统一）的存储作为 Source of Truth（事实来源）。
数据库工程师的解法：“一虾一库”与混合检索
王一鹏：你提出了“一虾一库”的概念，给每个 Agent 单独开一个数据库实例。为什么不能大家共用一个大库？
黄东旭： 首先是灵活性。每个 Agent 对于每个人的每个任务，其记忆的表征和数据组织方式是不一样的。如果大家共用一个基础设施，就相当于强行抹平了 Agent 的灵活性，让它去适应固定的表结构，这是削足适履。给 Agent 一个空白的画布是最简单的。
其次是隐私和安全。你肯定不希望自己最宝贵的记忆和数据跟别人串在一起。自己的龙虾，用自己的数据库、自己的加密，这在心理和物理层面上都更安全。
王一鹏：给每一个虾配一个数据库，是本地部署吗？
黄东旭： 不是在本地部署。OpenClaw 在开发时有一个 Local First 的理念，我是不同意的，我认为一定是云原生的。
Local First 是一个非常 Geek 的想法，它假设用户对电脑里的 CLI 工具非常了解。但它意味着牺牲掉非常多的用户体验，你不可能指望没有计算机背景的人去打开命令行敲代码。如果你真的要提供一个无缝的体验，一定是在云端。所有的状态、记忆备份、高可用我都帮你搞好，你只管聊就好了。所以选择云端是从用户体验角度来说更普适的选择。
王一鹏：听起来成本很高。你提到能把成本降到传统数据库的 1/100，这个事背后的逻辑是什么？
黄东旭： 过去没有这样的基础设施，给每个人配一个 MySQL 或 PostgreSQL 是非常奢侈的。但在最新的架构里，我们解决了这个技术问题。
想做省成本的事，一定要记住一句话：你能多细粒度地拆分你的系统，就能多细粒度地控制你的资源；你能多细粒度地控制资源，就能多大程度地节省成本。
真实世界的 Workload 是高度离散的，你不可能 7x24 小时不停地操作数据库。在我们的新架构里，底层是高度虚拟化和存算分离的。只有真正有流量时，才在计算池里捞一个计算节点服务一下，没有请求时就还回去。
你可以买 100 台机器的一秒钟，干完活马上还回去。就像家里用水表，如果你这一滴水能够用得非常好，你会发现你可以永远免费用水。 这样就能把成本降到传统数据库的 1/100，甚至如果你不用，我都没成本。所以在这种极细颗粒度的情况下，“一虾一库”成本并不高。
王一鹏：你提到记忆召回是混合检索，那在这个架构里，向量检索、全文检索和大模型是如何分工配合的？
黄东旭： 现在的实现是基于 OpenClaw 开放的 Context Engine 接口。核心思想是：我先把你所有的必要信息全存下来，作为 Source of Truth。然后我在后面做多种索引，包括向量索引、全文检索，以及按照时间排序的类似 SQL 的二级索引。
当用户聊天时，我同时查这三种索引，带着时间信息返回给龙虾，让大模型自己去决定。
王一鹏：这样怎么解决实时性问题呢？会不会导致 Agent 响应变慢？
黄东旭： 这是一个很好的问题。其实一个这样的数据库请求，哪怕算上网络的时间，也就是几百毫秒。现在 Agent 最大的性能瓶颈，或者说它在“想半天”的时间，绝大多数都消耗在大模型的推理上。
所以，对于现在的 Agent 数据系统来说，Latency（延迟）根本不是最重要的事情。最重要的是你的召回准确度，以及你能不能提供一个对 Agent 更加友好的 Interface（接口）。
王一鹏：未来的 Roadmap 里，你提到要去接管龙虾的文件系统，这具体是指什么？
黄东旭： 现在有一点点分裂，龙虾本地有一套按日期编排的 Markdown 文件夹，而我这边是高度结构化的 Fact，相当于存了两套。
理想的情况是，用户不需要关心数据库里是怎么处理的，直接把龙虾的文件夹指向我新数据库的文件系统接口。这样做的好处是，从最原始的信息到最结构化的信息全都在云端的数据库里管理。而且你可以很方便地做记忆备份，比如你想跳回到昨天的记忆，直接把文件夹状态拷过来就行了，不需要重新处理数据库。
AI Native 思维：放弃人类中心主义
王一鹏：你还提到了一个“遗忘曲线”的设计，直接把时间差丢给大模型去判断，这和传统写代码算权重的方法很不一样。
黄东旭： 对，这是一个很好的 AI-native 软件思维的例子。
以前开发软件，程序员会看一堆论文，设计一个精妙的遗忘算法。但在这个时代，如果你这么想，第一步就错了。
最好的解决办法是什么？是把你所有能召回的信息拉回来，把记录时间跟现在的时间差做个 Diff（比如这条是一天前，那条是三年前），然后把这个信息丢给大模型，加一句话：“Use your best judgment（用你最好的判断）”。大模型自然知道一天前的信息比三年前的更重要。
王一鹏：把模型作为系统核心，决策过程是黑盒的，这对于习惯了确定性的工程师来说，有点反直觉。你怎么看待这种思维的转变？
黄东旭： 强化学习之父有一篇著名的论文叫《Bitter Lesson》（苦涩的教训）。大概意思是，在人工智能发展过程中，人类脑瓜想出来的所谓精妙算法，长期来看没有一个是 Work 的。
我的观点是：放弃抵抗，放弃人类中心主义。不要去量化，就把它当人。你能想到的它能想到，你想不到的它也能想到，它是可以泛化的，而你自己写死的算法是不能泛化的。在今天这个摸不到边界的智能面前，你必须依赖它的智能去干事。
AI Agent 基础设施：重构与未来定位
王一鹏：从 mem9 往大了看，其实你在做的是 Agent 的基础设施。你觉得我们现在处于 AI Agent 基础设施的什么阶段？
黄东旭： 我们现在正处于一个大的范式级改变的节点。老的一套基础设施基本都会被扔掉，新一代的云服务和软件会完全不一样。
最底层可能还有操作系统和计算资源，但在上面，过去那些分库分表、高性能网关、大数据组件可能都不见了。未来最普遍的模式是：每一个 Agent 自己拥有一台计算机。这台计算机从底到上看起来跟现在的电脑一样，然后成千上万个这样的小房间，在上面构建基础设施和应用。
现在很多公司已经在拿龙虾赚钱了，他们把小龙虾的房间设置成做某件具体事情的房间，封起接口，变成一个小 Box，上面套一层应用 API。底层其实就是一个个被“囚禁”起来的龙虾在干活。所以未来的开发模式完全变了，变成了如何优化这个“牛马工厂”的效率和成本。
王一鹏：作为 TiDB 的掌门人，TiDB 在这张 AI Agent 的版图里，未来会是一个什么样的角色？
黄东旭： 我觉得它是 Agent 最好的“数据伴侣”。我甚至不想说自己只是数据库，因为我一定会做文件系统，不想局限于 SQL。
我最近在做一条新的产品线叫 DB9。它的假设就是未来人手一个 Database Agent。这个 Database 既可以当文件系统，又可以当数据库、搜索引擎、向量库。它跟沙盒环境高度绑定，针对 Agent 场景做了无数优化。
在这个时代，强调传统的性能和数据容量意义不大，更重要的是你能提供多大程度的“Agent 友好”。比如在 DB9 里，我没有设计传统的账号体系，Agent 随时可以像用自来水一样捞起一个库干活，用完还回去。我甚至可以把数据库切一半，像 Google Docs 一样 Share 给另一个 Agent。这些在传统数据库里是没法做的。
王一鹏：这听起来越来越接近云计算的概念了，做资源的弹性调度。TiDB 未来会演变成一家专门为 Agent 服务的新型云计算公司吗？
黄东旭： 我觉得现在已经在这个路上了。甚至我觉得未来应该反过来说，所有云计算的公司都会变成数据公司。
在 Agent 时代，模型本身是通用的智能，计算资源（CPU/GPU 使用时间）也是高度单元化和通用的。未来当每个人自己 5 分钟就能做一个应用时，唯一区分你和我的东西只有存储——我的记忆在这，你的记忆在那。谁掌握了 Data，谁未来才会赢。这是我的核心逻辑。
王一鹏：一虾一库听起来很重，如果 Agent 数量多了，资源开销扛得住吗？成本会不会比共享向量库更高？
黄东旭： 大家可能还是在用传统的观念看待软件系统。我举个例子，你家自己的电脑，能确保每一天、每一个小时 CPU 都是满载的吗？肯定不是。
所以我相当于通过一套调度手段，把你闲置的 CPU 拿出来赚钱，成本自然就降下来了。只要你能把细粒度的资源调度做起来，成本绝对不是问题。
结语
从 OpenClaw 的“脑雾”痛点，到 mem9 插件的“一虾一库”架构，再到对未来“牛马工厂”的构想，黄东旭的分享为我们揭示了 Agent 赛道中一条容易被忽视却至关重要的暗线。
当大模型的能力逐渐趋同，算力成为标准化的水电资源，Agent 之间的差异化竞争将不再仅仅取决于它“有多聪明”，而在于它“记住了什么”。记忆，或者说底层的数据基础设施，正在成为定义 Agent 独特价值的核心壁垒。
在这个范式级改变的节点上，TiDB 正在通过 DB9 等创新尝试，打破传统数据库的边界，向着“Agent 数据基础设施首选”的目标演进。正如黄东旭所言，未来的软件开发模式将发生彻底改变。
在这个新时代里，谁能率先解决好 Agent 的记忆与数据隔离问题，谁就能在下一代 AI 基础设施的版图中占据先机。而对于每一个正在“养虾”的开发者来说，或许是时候重新审视你为 Agent 准备的“大脑”了。
