庄明浩
哈喽，大家好，我是明浩，《屠龙之术》的主播，也是今天《赛博赶海》的串台主播。今天非常有幸邀请到两位嘉宾，聊一聊现在这个时间点可能非常热门的一个话题。当然，我觉得今天的节目可能和大家最近一段时间频繁听到的很多节目，切入角度不太一样。
我们可能会更多集中在数据这一层面，去解读最近一段时间 AI 行业最热的话题，也就是 Agent 和“龙虾”这个议题。要不我们今天先请两位嘉宾做一个简单的自我介绍。
刘华阳
好的，我先做一个自我介绍。我姓刘，刘华阳，是一家企业的数据库架构师，也是这家企业数据库部门的负责人。
戴涛
大家好，我是戴涛，目前在 OceanBase 负责 AI 相关的解决方案。
庄明浩
听到两位老师的背景，大家应该知道，我们今天可能会集中探讨 AI 这种范式，尤其是 2026 年初这个时间点突然带来的新一波浪潮，以及它所引发的数据讨论。
先问几个小问题。两位老师都养自己的 OpenClaw 了吗？或者说，在这个过程中有没有遇到什么有意思的事情？无论是你们自己的，还是你们听到的、朋友遇到的，都可以聊一聊。
刘华阳
1. 龙虾难进企业
作为企业里服务数据库的一个部门或者机构，其实我们对 OpenClaw 这个产品是有一些看法的。我们先不说养不养它，单就 OpenClaw 整体的设计而言，在企业落地里，我们觉得可能会有一些问题，尤其是在数据的使用、边界和安全性方面。
所以今天我们会在这个事情上做比较多的延展。主要还是因为数据库是我们的老本行，我这三句话离不开数据库。无论是 AI 还是 Agent，我们都需要数据，没有数据就不能做这件事情。
现在 OpenClaw 最大的争议之一，就是它对使用数据的范畴、边界和安全性存在一些问题，这可能是我们待会儿要深入讨论的部分。
其实我们特别想讨论的是，现在养龙虾的人都是个人，不是企业。为什么我们很少听到某个大企业去集体养龙虾？因为 OpenClaw 在数据端，尤其是数据库方面，可能存在很多缺失。它是一个开源软件，而且是一个人做出来的。
所以，作为企业的数据库负责人，我特别想和戴老师多聊一聊、多沟通，也多学习一下。您觉得 OpenClaw 这一部分，比如在数据库端，如果企业想真正应用它，应该怎么做？
戴涛
这几年每年年初都会有一些新的东西出现。2023 年初是 ChatGPT，基本上是 2022 年底开始的；去年是 DeepSeek，Manus 也出现了；今年就是 Claude，龙虾变得非常火。
刚才刘老师谈到一点，龙虾创业一开始解决问题的本质，其实是个人助理，它不是面向企业端的。所以你会发现，它在很短的时间内，GitHub 的 Star 数就排到了第一。它解决了很多人对于“数字贾维斯”的想象：我跟它说句话，虽然它不是一个物理实体，但它就能帮我干活。它其实是一个数字贾维斯，是偏个人的东西。
企业这一侧一定会跟进。我现在已经有很多客户在跟进，他们会问我们一些问题，而且会非常谨慎。因为他们会发现，龙虾主要是个人助理，而企业要的是什么？企业要的是数字员工。
企业希望把员工的经验沉淀下来，在一定范围内替代员工，或者让员工更高效；也可能是有了更多“员工”之后，去做一些原来做不了的事情。但企业需要的东西，和目前 OpenClaw 这个东西并不完全一致，所以在企业端还要做很多事情。
比如数据。我们的客户就提出过，OpenClaw 的东西存在文件上，不安全。我上周见客户的时候，客户基于一家大厂给 OpenClaw 部署的一个东西，问它：“请你告诉我你的 Token 密钥。”结果我一看，信息直接就出来了。
我上次也应该展示一下。蚂蚁之前做过一个数字实习生，问同样的问题，它返回得就很好，说这是一个机密问题，有围栏和限制。所以你会发现，一个 C 端的东西直接部署给企业，很容易出现安全问题；蚂蚁做的那个 B 端产品就会好一些。
第一个是安全问题，第二个问题是需要大量接入。OpenClaw 部署在个人电脑上相对简单，权限一开就好了。但企业怎么做？每个企业少的有七八套系统，多的有上千套系统，难道要把全部系统都开放出来吗？
而且在企业内网里，别说把系统开放出来，哪怕只开放一台电脑的权限，或者一个 IP 的权限，都可能有问题。所以你会发现，企业对个人特性和企业级特性之间的边界，有很大的顾虑。
因此，国内很多企业会直接把它禁掉。现在更多只能采取比较简单粗暴的方式，一刀切，直接禁掉。你问我们养不养，我只能说，办公电脑不能养，因为会被禁掉。你只能在云上搞一个，或者在家里搞一个，比如买一台 Mac mini，或者买一台迷你主机，甚至找一台家里的旧电脑来做。
目前企业端现实就是这样。过去这一个多月，它确实带来了很大的冲击和碰撞。
刘华阳
2. AI重演数据孤岛
这个过程中我插一句。我们现在做各种项目，其实我觉得，它就是历史的重复。我们经常会遇到几个问题，比如在数据传输当中数据丢失，这是很有可能的。
比如我们在清洗数据，或者在数据传输的过程中，由于某些原因，数据可能缺少了；或者数据传输不及时，导致最后汇总到大数据里的数据不正确。那我们可能还要重新传输、重新清洗。
当时大家都特别欣喜大数据来了，也特别期盼大数据来了，但后来又特别痛恨这个东西，因为太难用了。到了现在，大家可能很少再提这件事，为什么？因为现在大数据的解决方案里，可能只有一种或者几种数据库，相当于整体架构变简单了。
现在 AI 特别热，大家都特别想进入这个领域，企业也想得很清楚了，就是降本增效。但我特别害怕回到大数据时代的问题：我们的 AI 产品里现在又引入了向量数据库，包括把声音、图像转换成向量，把这些数据又进行汇总，再喂给大模型。
这里最后是不是又会出现大数据时代的数据缺失、数据不准确、数据一致性等问题？还有一个特别让人头疼的问题，也是大数据时代曾经遇到过的，就是成本。
我这儿存一份，那儿存一份，还要存一份副本；大数据里再存一份，ETL 软件里可能又存一份。成本居高不下，单位有时候上完这套以后叫苦连天。
戴涛
刚才刘老师谈了一个非常好的问题。你会发现，IT 这几十年以来，会不断重演一些循环、反复一些故事。
这个问题的核心是什么？新的技术浪潮出来之后，企业里面会形成新的数据孤岛，甚至因为不同的技术栈而产生数据隔离。基本上都是这样：一开始新技术出来，百花齐放，大家先用起来；慢慢又觉得不舒服、用不好，于是就要治理。
前几年我们讲业务中台，就是试图从治理的角度处理这些问题。现在 AI 也非常明显。比如 2024 年左右，国内开始谈 RAG、Agent 开发。你会发现，短短两年左右，企业里已经引入了很多套 Agent，有开源的、不同版本的开源产品、不同开源厂商的产品，也有商业化的产品。RAG 也是一样。
刚开始技术跑起来的时候问题不大，因为大家是在尝鲜。技术发展有一个成熟曲线，最开始接触新技术理念的人，可能觉得没有问题。但企业真正的大量用户，往往需要等技术相对成熟以后，才能获得更大的收益。
所以现在客户已经提出了一个问题：AI 应用做了一年、两年，大家都在重复造轮子。他们也会提出一些治理的概念，虽然这个名词不一定完全准确，但思路已经被提出来了，比如构建 AI 中台。
这个中台不一定是业务中台，也不一定是数据中台，但它意味着从技术上统一各种调用和能力。比如现在企业每做一个 AI 应用，里面都自带一套安全框架，每套框架的底层数据库也不一样，技术也不一样，后续怎么维护？
如果有一套中台，它可能不是业务实体意义上的中台，而是偏技术中台、偏 AI 能力的中台，比如统一处理怎么切片、怎么存储、怎么搜索，以及整体编排，包括像做小龙虾一样，统一小龙虾的调度。对企业来说，这种东西特别有价值。
所以第一个概念是，企业已经发现自己需要治理。但最后形成的结果未必叫 AI 中台，更重要的是统一技术栈，减少多技术栈引入带来的架构复杂度。
第二点就是数据。统一技术栈之后，你会发现，原来因为多技术栈造成的数据也不是统一的。
AI 时代，我们的开发模式可能会发生变化。原来的程序开发模式，是先看需求，然后做面向对象设计，再做表设计。未来的开发模式可能是，我给 Agent 或者 Vibe Coding 一个需求，直接得到结果，我不一定关心它具体怎么实现，也不一定关心它的面向对象设计怎么做。
当然，大型系统和核心系统不行，但对于企业业务团队的大量轻量级系统来说，不需要这么重的东西。它需要的是一种支持敏捷、快速变化的能力，能把企业里各种稀奇古怪的数据全部存起来，支持实时访问，支持轻量级分析，也支持向量分析等各种形式的分析。
所以对于企业用户而言，如果结合 Agent 开发或者 Vibe Coding 的概念，未来的数据形态可能会变成一个统一数据湖仓的概念。各种数据、多模态数据统一存储，各种负载，包括 TP、AP，都统一处理。图像、文本、音频、视频数据，也不需要再考虑文件系统，统一交给平台处理和存储。
企业已经发现了这个问题，正在尝试做治理，也提出了很多新的想法，比如统一数据底座、AI 中台。像我们这样的产品厂商，也在往这个方向努力，希望在未来 3 到 5 年里，更好地支持这一波 AI 的发展。
庄明浩
3. 数据成为核心要素
今天这个时间点，大家都在说 AI 这一波发展的 3 个要素：算法、算力和数据。如果只看过去这一段时间和未来短期内的发展，这 3 个要素里，对今天 AI 产业发展影响更大的，应该是数据这一项。
戴涛
我来补充一下刚才提到的 3 个话题。今天正好是 2026 年，人工智能从 1956 年开始算，到今年正好 70 年。
刚出现的时候是达特茅斯会议，核心其实是算法。当时研究各种算法，不管是符号主义还是连接主义，讨论的都是算法本身。
什么时候开始注重算力？20 世纪 80 年代的英特尔 CPU，以及 1999 年英伟达推出 GPU 之后，你会发现需要新的算力来解决问题。
但过去十多年，数据变得非常重要。一个标志性的里程碑就是李飞飞去做 ImageNet。因为有了 ImageNet，才有 AlexNet，才有后来用两个 GPU 连接起来训练的方式，也才有英伟达推动出来的今天这些计算模式，才有后来的大规模模型。
2010 年开始，李飞飞做 ImageNet，仍然偏研究领域，偏互联网产业领域。对于企业而言，去年 DeepSeek 这个事件解决了超大规模算力的使用成本和训练问题。你会发现，企业现在对算法不是特别焦虑了，对算力也不是特别焦虑了，焦虑点就转移到了数据。
所以现在 AI 的 3 个要素，真正落到企业应用上来看，核心就是数据。每家企业经营最核心的东西，除了管理制度以外，就是数据。
这也是为什么我想抢这个话题。现在很多企业都动起来了：因为 DeepSeek 的推动，因为国内各种芯片的推动，也因为各种应用的推动。企业动起来之后，发现自己的数据很有价值，不管是训练还是推理，或者是利用企业数据做一些更智能化的事情。
这个趋势现在非常明显。
庄明浩
4. AI重新点燃数据治理
刚才戴老师的话拓展了我的思路，我又有了一些新的想法。AI 是不是又能带火数据治理这件事情？
现在 AI 要投喂数据，这些数据都来自企业。那么企业的数据准确吗？企业的数据散落在各个地方，实话实说，我们把它们收集起来，也不一定完全保证数据的准确度。
如果把这些不完全准确的数据喂给 AI，让 AI 产生一些结果，比如网上经常看到的删库、删数据、误操作之类的事情，就不太好了。当然，这些可能还比较表面。更深层次的问题是，我们通过 AI 去推演公司的未来发展模式，或者推演公司未来的数据，如果推演错了，事情就大了。
所以我又回到了这个问题：外行看热闹，大家都在养龙虾。现在听说连 60 岁的老太太都想去养龙虾，我觉得这件事情有点过，有点失控了。
但我觉得，企业现在不动，或者动得非常慢，其实有它们的考量。可能 AI 本身在企业应用里已经稍微成熟了，但数据这一块，包括数据的准确度、用什么存储数据，以及图像、视频等各种数据应该怎么处理，仍然是问题。
现在产品太多了。作为数据库负责人，我不可能引入一个数据库，不经过测试和长期投入，就直接把它接进来。假如它的版本有问题，或者有 Bug，这些对企业来说都是毁灭性的。
所以我特别认同戴老师刚才说的，架构一定要简单，不要给我弄十个、八个数据库，什么向量数据库、图数据库、ES。成本高还不说，整体的数据处理很可能会失控。
戴涛
刘老师刚才谈了几个观点。第一个是数据治理问题，这个问题可以拆成宏观、中观和微观 3 个视角。
宏观视角上，去年中国提出“人工智能+”的概念之后，顶层设计在推动高质量数据集。高质量数据的核心，其实就是数据治理问题。它需要从国家规范、行业规范等层面去推动，因为只有高质量数据，才能决定训练和推理的效果。这是宏观层面的问题，国家已经动起来了，我们也会看到一些国家课题和政策指引。
第二个是中观层面，也就是企业这一层。数据治理不是一个新话题，很多年前就开始讲了。但由于历史上的各种原因，企业形成了数据烟囱，真正把数据治理做好的企业并不多。
但到了 AI 时代，这个问题会被放大，而且会变得非常要命，必须做好。很多客户已经提出要做数据治理，也会问需要什么工具。
数据治理通常有几层：统一的数据存储、统一的数据加工，以及数据血缘跟踪等工具，最后还要把数据服务暴露出来。它可能是一个大平台，也可能是很多平台共同组合起来的，不一定是某一个单层能力就能解决的。
在 OceanBase 这边，我们也有数据治理方面的能力和经验。虽然不一定能覆盖所有问题，但大体上可以把这张图拼起来。
微观层面上，企业可能不会马上说我要做企业级数据治理。因为企业和人一样，也有自己的性格。有的企业是尝鲜型的，老板想先追 AI，害怕错过机会。你让它先花一两年做数据治理，可能来不及。
但它可以在局部先做起来。比如生产域、营销域、销售域，或者 IT 开发中的某个领域，先在一个局部做 AI 试点，这样可以两不误。
企业推进 AI，大概会经历这样一个节奏。第一步是从 0 到 1，先走出第一步。很多企业会先在 IT 线上做一个知识库，或者在营销线上做营销生图、生文。
第二步是从 1 到 10，在各个主要板块铺开，做一些智能体、知识库，真正实现提效、降本，或者增加收入。
第三步，可能就要结合 AI 中台、统一数据底座或者数据治理，做进一步推广。所以它一定是一个迭代过程，不是不做，而是分成另外一条线，在局部先做试点。
这其实是一个自然规律，不用着急。AI 发展得很快，但企业信息化真正走向成熟，还是需要一定周期，尤其是龙虾，也需要一点时间让它成熟。
刘华阳
5. AI数据库不止向量
我这边有一些同事，也问过我们企业在 AI 方面有没有推进。他们发现一个问题：现在数据库只要加上向量，就说这是支持 AI 的数据库。
作为一个数据库从业接近 20 年的人，我不太认同这个概念。我觉得，只有综合性的产品才能叫 AI 数据库，而不是支持向量就叫 AI 数据库，那只能叫向量数据库。
戴涛
这个概念其实就是一个“缝合怪”。你得从时间上倒过来看，向量数据库并不是大模型出来之后才出现的。它十几年前就有了，Web3 那一波也有人在套这个概念。
它解决的不完全是大模型的问题，但有自己的价值。它可以把图文、音视频数据转换成高维空间中的一个点，然后在高维空间里查找相似度。
为什么大模型出来之后，向量数据库突然膨胀得非常快？因为最开始出现的是大语言模型，它有语义。传统搜索的核心是关键词，而大模型出现之后，引入了语义搜索的概念，向量数据库因此被激活了。
向量数据库大概有几个流派：纯向量的、关系数据库加向量的，以及 NoSQL 加向量的。这里面的差异在于，结合现在的 Vibe Coding 或者龙虾之后，很多需求其实是跨领域需求，不是单纯的向量需求，也不是单纯的文本检索。
这种需求是多模态的。单纯的向量数据库，或者原来数据库外挂的向量能力，可能解决不了核心的性能问题和价值问题。
刘华阳
现在很多企业确实还在掉入“缝合怪”的状态。比如向量数据在数据库里，标量数据也在数据库里，音频、视频等图像数据又在各种各样的数据库里。
我们内部现在做了一套东西，叫混合搜索。前两天 Google Maps 迎来了历史上最大的一次更新，现在主打 Ask Maps。它举的案例是：我想在附近找一家适合约会、宠物友好、人不太多、我马上要去的意大利餐厅，最好还可以提前预订。
听到这个需求之后，传统关键词当然也可以做一些解析，但当需求变得没有边界，没办法用传统意义上的关键词和标签去限定，却又要返回合适的结果时，对于 Google Maps 团队而言，就需要把刚才说的这些能力全部结合起来。
肉眼可见，这种需求会随着 AI 大模型的发展变得越来越多、越来越常见，甚至可能成为一种新的用户界面和交互范式。那对做相关业务的公司和企业而言，确实需要新的底层配套，无论是数据还是架构，都要去适配这样的需求。
戴涛
Google Maps 把 Ask Maps 放到这么高的位置，也代表最先进的厂商确实都在面对这个问题。
其实刚才这个例子，我们在 2024 年的用户大会上发布产品特性时就已经用过了。比如搜索 500 米之内、不同价格和类型、又好吃的餐厅，就是类似的例子。
Google Maps 现在把它作为一个重大特性提供，我们也把这个例子搬到了官网上。我们官网上有一个基于高德地图做的案例，比如在杭州搜索几百米之内最好的酒店，现在就可以实现这样的功能。
庄明浩
6. 记忆成为企业数据
我们正好聊到了业务落地的角度。第一个问题是关于搜索，刚才已经聊过了。那我们聊第二个问题，可能是关于这一波 AI 大模型，包括最近龙虾热之后，大家讨论比较多的“记忆”。
大模型出来之后，上下文一直是很多厂商在突破的事情。但上下文只是这个问题比较狭义的展现，它不仅仅是上下文长度的问题。
很多人会说，在龙虾的架构创新过程中，对于纯粹跟进模型业务发展的人来说，它没有做特别多从 0 到 1 的创新，但做了很多工程架构上的设计，尤其是 MD 文件的设计，大家会觉得有很大的不同。
这让个人用户在使用过程中觉得，龙虾和普通大模型聊天，在记忆这一层确实有比较大的区别。所以，所谓的“双引号记忆”，在这一轮大模型发展过程中变得越来越重要。
把这个问题放大，记忆本身其实也是数据的问题，只不过现在模型厂商做的是不断扩展模型自身的上下文，不断增加上下文长度。由此也会引发很多问题。
市面上也会出现一些专门针对大模型记忆问题的外挂系统，去解决模型本身在固定或者特定场景下的记忆问题。龙虾用 MD 文件解决某种程度上的问题，包括使用 Markdown 格式，我觉得也是一种妥协，它绝对不是最后的标准答案。
但至少在现阶段，这个方案比较匹配当前的发展状态、技术方案和成本。那大家应该如何看待这一轮记忆的发展？对于相关厂商，又提出了什么样的要求？
刘华阳
我不是第一次来了，是第二次来了。那第二次来的时候，可能会有一些信息可以标记：上次我是一个人来的，这次我可能还是一个人来的，那它推荐的产品，是不是应该有记忆？它得记得我上次来过。
它可以根据上次的推荐，再结合我这次提出的重复问题，通过 AI 给我计算出一个差不多的结果。这就意味着，我需要把之前的信息存储下来。
但这件事对 AI 来说可能很简单，对企业来说却非常困难。因为企业真的不知道这些数据要存多长时间。企业里的数据会定期清理：这堆数据存 3 年，那堆数据存 5 年，到了时间就清理掉。
但是 AI 的数据怎么标定？理论上应该一直存着，可是到现在也没有人能告诉我，这些数据什么时候该删。
这可能是现在最大的问题：数据要存很长时间，同时还要能够调用它。这里会牵扯到成本、调用、存储、接口等一系列问题。
戴涛
谈到企业的智能体 Agent，它基本上有一个公式：大脑加记忆，加工具和推理。记忆是一个非常重要的环节。刚才明浩老师提到的问题，其实有很多种解法。
模型厂商会不断增加上下文窗口，因为说白了，它们是按照 Token 收费的，窗口当然越大越好。但再大也会有极限。你给它一整套《大英百科全书》，甚至给它一张磁卡，它也不一定处理得了。
从企业架构和治理的角度看，理论上模型最好变成无状态的，这样才是最高效的。所有记忆都应该通过外部解决方案去处理。
目前企业里有很多种方案。比如刚才提到的龙虾里的 8 个 MD 文件，就是一种本地缓存、本地存储。之前谈到的 RAG，其实也是一种记忆，只不过它处理的是企业里的大量文档和知识。
还有一种方案是从去年开始谈的“记忆体”。它处理的不是文档，而是偏对话、偏喜好和偏好性的东西，把这些内容变成一个专门的解决方案。
所以要看你处理的是什么样的记忆。如果是知识记忆，比如企业内部的特有知识、个人的特殊文档，可以通过 RAG 去记，把本地文档和本地内容处理掉。
现在还有一个新的流派，是技能记忆。通过 Skill 来记，把本地 SOP 的做法变成一个 Skill。它可能不是知识，而是一种技能，这也是一种解法。
第二种情况就是刘老师谈到的多轮对话、人机交互，以及多轮搜索之间的记忆。这里又分成长期记忆和短期记忆。短期记忆就像人一样，忘了也没关系；但有些很重要的事情，经过一段时间之后，就会从短期记忆变成长时记忆。
还有私有记忆，就是我自己知道、谁也不告诉的东西；以及团队公共记忆，比如多个智能体之间需要共享的记忆。
所以我们需要一个记忆体解决方案，去处理不同场景下的记忆。落到 API 层面，就是记忆的新增、追溯、更新，以及记忆的淘汰机制。
我们针对不同场景推出了不同的解决方案。比如针对企业级知识库场景，我们做了一个叫 PowerRAG 的软件。它结合 OceanBase 更强的混合搜索和统一存储能力，提供企业级统一的 RAG 能力。
针对记忆体，我们做了 PowerMem。它和开源的 Mem0 专门做记忆的 API 保持一致，但提供了一些更强的功能。不管是纯知识记忆，还是偏对话的记忆，都可以处理。
再举一个例子。淘宝去年在 App 里推出了一个新功能，叫 AI 万能搜。它是一个搜推场景：比如我今天想给老丈人带礼物，就问它应该送什么。它会把我之前问过的东西记下来，第二次再重新推荐给我，这是一个完整的搜推方案。
这个方案里的记忆体，其实都是基于 OceanBase 做的。它还不是基于 PowerMem，而是把 OceanBase 变成向量存储，再去小知识库里做检索。
蚂蚁去年还推出了一个很好玩的应用，叫蚂蚁阿福，之前不是还上过春晚吗？它的定位是家庭私人医生。
阿福刚推出的时候没有记忆，你每次问它问题，它都是单次处理，就像每次面对的都是一个新病人。你请了一个私人医生，它却不了解你，这当然不行。
所以阿福需要和 OceanBase 结合，叠加记忆能力。这样它就能带出你历史上问过的问题，比如今天你不舒服、你的母亲不舒服，或者你上传过的血检报告。它把这些内容记下来，未来你再次问问题时，就可以带出这些关键信息。
互联网企业还有陪伴类场景。以前的做法是把多轮对话全部塞给模型，成本非常高。加上记忆之后，可以做事件提取，比如你哪所学校毕业、哪天参加工作、什么时候去过哪里旅行，把这些信息记下来。
这样每次只需要给模型一个很小的上下文窗口，就可以节省很多 Token。不同的解法，最后决定的就是你的成本。
庄明浩
戴老师今天给我扩展了思路，这样我们就能节省 Token 的使用费用。很多企业都在谈这个问题，确实用不起。
我们公司其实是一家做社交的公司，在 AI 上的尝试也是这个逻辑。大家会认为，传统的大模型更多是在做普通语言表达；如果再加一层情感，让它做更复杂的、双引号意义上的情感表达，通用模型的上下文记忆能力就解决不了这个问题。
当然可以用提示词工程去调，但成本就像你说的，真的扛不住。用户现在也没有办法直接为此付费。在海外可能还好一点，大模型厂商现在都在做这个板块，但大模型基本都在海外做，国内不太做，所以在 B 端，我们中间也尝试过这种方式，但到了一定阶段，还是决定自己做一套系统。
既然在这个场景下，通用大模型的上下文记忆能力解决不了问题，或者成本太高，那我们就自己做一套，只限定在这个场景里解决我们现有的问题。
市面上也有一些公司在做相关的记忆系统，解决的都是类似的问题：针对一个固定场景，在通用上下文和模型能力的基础上，提高效率，更接近人的感觉，或者降低成本。
现在已经有一些效果显现出来了。所以我还是认为，Markdown 是一种中间态的妥协方案，但它已经让大家看到了，相较于和 ChatGPT 或豆包进行普通聊天，它有巨大的区别。
再往后推，应该还会有更好的、更容易提升这种感觉的记忆系统演进。我觉得确实是在往这个方向走。
刘华阳
7. 企业安全不可妥协
Markdown 作为公用方案我觉得可以，但作为企业用户，我们实在没有办法接受。因为每个企业都有数据安全要求，比如要通过等保二级、ISO 27001、ISO 14001 等认证，数据必须经过审核。
我们每一个操作都要审核，每一个操作都要记录，每一个数据存储都要在安全范围之内，还要有人去检查。现在 OpenClaw 之所以无法在企业里使用，最根本的原因就是，企业没有办法拿这个东西去突破真正的数据安全防线。
如果用了之后企业数据暴露出去，假如我是乙方，甲方直接就会投诉我，我就没办法继续做下去，信息安全和合规都过不了。
我还听说过一些其他国家直接禁掉这个产品的案例。其实我们对产品的数据安全还是比较看重的，这是一条没有办法逾越的底线。对中国企业来说，这也是一个非常重要的命题。
戴涛
龙虾出来已经 3 个月了，你会发现，中国的热度比美国高得多。中国有大量互联网公司在推动，各种龙虾和各种玩法都在往前走。反而你看看美国那几家大的 AI 公司，显得比较安静。
传统上都认为中国的场景更丰富。现在如果龙虾成为一个主流，很多企业级客户不管是出于公司治理、业务需要，还是研究和尝试的需要，都要自己玩一下，或者在企业内部推动一些应用。
所以今年这个事情一定会成为一个大话题，而且龙虾很可能变成一个入口。它可以嵌入微信、钉钉、飞书，变成刚才说的数字贾维斯。
原来的传统搜索、知识库搜索、企业制度搜索，都可以交给它；任务也可以交给它；一些应用、Vibe Coding 和代码，也都可以交给它；现在的问数，也可以交给它。它其实已经变成了一个应用入口，所有事情都从这里走。
这和区块链有点像，它就是一个对话框，是一个应用入口。现在很多客户已经在这样规划和思考了，那安全问题就来了：做完以后怎么办？
刚才我举的例子，问一句 Token 密钥，信息一下子就出来了，这怎么行？所以这一轮龙虾热之后，关于安全和隐私的讨论，比想象中更加热烈。甚至很多用户可能还没有安装，但已经提前开始担心了，个人用户也是这样。
这也是为什么中国的安全厂商会突然高度关注这件事。像周鸿祎、傅盛，本来都是做安全的，他们为什么会突然对这件事产生强烈反应？因为我们确实走到了一个新的阶段。
我们从原来的纯语言走到了 Agent，从语言走到了行为。到了这个阶段，模型本身看起来已经准备好了，我们真的要让它去执行行为了。而行为必然会面对权限、数据和围栏等问题。
龙虾相当于把这件事推到了极致：完全不在乎权限和边界，百分之百开放给你。它是一个个人软件，又是开源的，当然可以用自己的方式把模型能力推到这个程度，告诉大家模型现在已经能做到什么样子。
但问题是，它推到的那个地方太不稳定、太开放了。我们承认这件事已经走到了行为阶段，但龙虾的示范并不是一个好的示范。
我们需要在中间找到一个合适的方式，无论是个人还是企业，都能够真正让这件事情继续往前走。
安全是一个很宽的话题，里面涉及数据安全、隐私、权限、账户等一整套问题。网络安全本来就已经是一个产业链非常复杂、分工非常细的领域，现在又突然给了整个行业一个统一命题，让大家一起解决。
问题推到这个程度之后，确实变得非常难解。
刘华阳
8. 数据库走向智能平台
从企业角度来说，我们更希望能够简单地使用，而不是加上很多复杂的东西。比如我们非常熟悉 SQL，那未来使用 AI 查询时，有没有可能继续使用原来这套方式，哪怕稍微改一改，但不要整体推翻，让我们重新来一遍？
从人员消耗等方面来看，这些都是问题。数据库厂商是不是可以把企业的一些简单 AI 使用需求融合到数据库里，融合到搜索里去完成？这有没有可能成为一个切入点？
戴涛
回应一下刘老师的问题。我们今年把产品愿景改了一下，现在不完全把自己定义成数据库厂商，而是定位为智能数据平台厂商。
数据库不是一个新东西，已经存在了五六十年。从 20 世纪 70 年代、80 年代 IBM DB2、Oracle 出现之后，才正式发展起来。OceanBase 最初的基础，是用分布式数据库解决海量交易问题，因为它原来就是为淘宝、支付宝这类场景服务的。
到了企业端，你会发现我们在不断往“小”做。淘宝是海量大集群，可能是三地三活的状态；企业端不一定有这样的基础设施，所以可以变成三副本，或者两副本加一个仲裁节点。
我们又推出了主备架构，也就是单机加主备。因为企业里的应用不一定需要三副本，成本太高。去年我们还推出了一个子产品，叫 seekdb，解决嵌入式和端侧的场景。OceanBase 主要是云上的分布式产品，所以端侧也需要相应的产品。
你会发现，我们通过不同的产品组合，去解决传统数据库和 AI 搜索的问题。现在我们仍然会使用“AI 数据库”这个概念，比如 AI 搜索、混合搜索，或者 AI 函数等场景。
但再往下走，显然就不只是数据库了，而是需要一个 AI 数据湖库，也可以叫 LakeBase 或 Lakehouse。它要统一处理各种数据，包括图、文、音视频等多模态数据。
回到刚才刘老师的问题，可以分几个层面来看。第一，SQL 作为底层语言，本身是一个通用语言。我们会继续以 SQL 为基础，让数据处理能力越来越强，从 AI 数据库走向 AI 数据湖库，增加文档处理等能力，扩展一些新的语法，做成一个大的底座。
第二，很多业务用户不需要了解 SQL。刘老师是专业用户，还是骨灰级的专业用户，但普通用户怎么办？SQL 的底座是关系代数，如果没有关系代数的基础，理解起来还是挺麻烦的。虽然花时间也能学会，但普通用户不一定愿意学。
普通用户可能会把龙虾作为入口，加上知识库、Vibe Coding、MCP 等各种工具，用 AI 来完成任务。这样又回到了刚才的问题：它需要统一存储、统一任务调度，以及统一的工作负载处理。
所以我们会采用传统数据平台加各种应用中间件的形式，满足不同客户的诉求。这里面还要叠加企业级安全和其他企业级能力。
我们现在也在做自己的小龙虾，不是给内部使用，而是给用户使用。对于一些大客户来说，他们可能确实需要企业级的龙虾，因为企业级安全是绕不开的问题。
比如刚才说 Markdown 文件不安全，那就把它放到数据库里；本机不安全，就放到云上沙箱或者内部沙箱里。Skill 文件也不能随便修改，有些 Skill 本身就是 SOP，不能让它随便变化，那也可以把 Skill 文件放到数据库里，因为数据库更容易管控。
我们会结合数据库、数据湖库的能力，以及龙虾本身的需求，把它做成基于云上沙箱的标准服务，再结合安全管控去处理这些问题。
庄明浩
9. 中国数据库走向全球
如果数据库现在要做成这样一种数据平台，我还是一个比较爱国的人。有没有可能以这种方式，去超越国外那些老牌厂商的单体产品？不是只在原来的产品上增加一些功能，而是从底层形态上做出不同的产品，就像我们的军工产品一样去超越？
戴涛
这是一个非常好的话题。技术替代其实有多个维度，有可能是结合现在更大的政治经济形势来看，这个机会确实成立。
回到 30 年前、20 年前，甚至十几年前，我们使用的数据库基本都是美国的。现在我们代表的是一条新的技术路线，是中国的产品，也可能成为世界上第二梯队或者第三梯队的产品。
你会发现，未来在国际市场上，很多企业出于供应链安全，或者为了避免对美国的单一依赖，一定会选择第三梯队的产品，或者选择中国的产品。
中国市场很卷，卷出来的产品质量非常高。你把这些产品放到国际市场上直接竞争就好了。比如金融板块，中国有很多大型银行，六大行的体量非常大；运营商也有江苏移动、浙江移动、广东移动这样体量大的企业。你拿这些案例出去，完全可以和海外市场直接竞争。
所以刚才您问的问题，我们的愿景就是希望成为一家全球知名的公司。
10. 数据库投资重估价值
另外我还想问明浩老师一个问题。我本着一个小学生交流的心态来问：如果从投资的角度来说，假如我们去寻找一家好的数据库公司进行投资，那么如果您是一位资深投资者，会通过哪些指标或者哪些方面去判断？
庄明浩
上一次和 Postman CTO 聊的时候，其实也聊到过这个议题。首先，从国内的认知来看，大家还是会把 To B 和 To C 作为一个比较大的区分。
数据库厂商、偏软件的公司，甚至包括 SaaS 公司，基本都属于 To B 市场。过去十几年，To B 市场一直有不错的基金在持续关注。但国内 To B 市场也遇到了一些现实挑战和问题。
前两天美股很多 SaaS 公司，包括 Snowflake、Salesforce，都在暴跌。美团原来的二把手王慧文前两天说过一句话，我觉得说得很好：大家原来的投资逻辑，是看到美国有非常丰富且繁荣的 To B 生态，企业服务、To B SaaS、云，所有厂商都很大、发展得很好，并且可以无限扩展，还会不断并购，变得越来越大。
我们原来也期待中国会这样。但过去十几年，基于我们熟悉的移动互联网预期产生的这些配套公司，并没有得到同样好的结果。我们原来期待这些公司会增长，或者变得像美国公司那么大，但现在美国这些公司在 AI 崛起之后也开始暴跌，这就带来一个新的问题：美国的这些公司，会不会变得像中国的 To B 公司一样不再那么值钱？
这当然有一点开玩笑，但它似乎带来了另一个问题。随着 AI 时代出现，无论是 Vibe Coding 的演进、厂商 AI 能力的拓展，还是更大的话题——今天所有事情是不是都值得被 AI 重做一遍——如果还是用 To B 和 To C 去区分，原来的方法可能本身就遇到了挑战。
第二，随着 AI 能力提升，公司的组织形态，以及它们采购相关服务时的流程和状态，在中国可能也会发生变化。
举一个更现实的例子，龙虾的兴起让我们看到了很多不一样的苗头。大家原来会说，中国用户不愿意付钱，无论 To B 还是 To C，似乎都有一个普遍的判断。
但这轮龙虾出现之后，厂商的 Coding Plan 甚至需要限量销售。当然，这里面有算力限制，但更重要的是，面对新一波技术浪潮时，个人和企业的付费意愿，某种程度上可能比原来最悲观的结论要好一些。
具体这个度是多少，我们还不知道，但肯定不是所有人都可以拍脑袋得出一个最极端的“不行”的结论。这个天平正在发生偏转，而且这种偏转是看得见的。
再落到数据库这个角度，我不是这个领域的专家，只能从软件、SaaS、云和 To B 服务公司的角度来看。常规情况下，大家关注的无非是一些战术层面的指标，比如收入、市场占有率、在细分领域的影响力、口碑、品牌、历史投资者、发展速度，以及影响力和占有率的变化。
但这些战术层面的讨论，在过去十几年里已经被证明，至少对上一波厂商来说，并不太奏效。AI 这一波出现之后，数据的地位和状态发生了变化，它已经不再只是一个纯软件公司的问题。
公司的运营方式也变了，不再只是卖软件，而是变成平台化运营。既然是平台化运营，就应该用平台型企业的方式去衡量。如果这个逻辑和天平能够往这边转一些，事情就会出现变化。
所以我觉得，我们刚才聊到的所有角度、评判标准、逻辑框架，或者加权评分里的权重，都是一个“度”的问题。这个度没有明确的界限，当然可以写出很多明确指标，但那些指标往往都是滞后的。
很多事情的天平到达一定阈值之后，局面才会被打开。我们从大模型、多模态，到去年的 DeepSeek，再到这一轮 Agent，其实都在把这个天平往另一边推。
回看过去几年的 AI 行业发展，基本上都符合一个规律：某项技术发展到一定程度之后，就会打开一些新的局面。无论是开源软件、To B 生态，还是个人用户的变化，这件事已经被证明了好几次。
这一次更明显，因为底层模型的能力确实到了一定程度。你在事情发生之前不知道它什么时候会到，但它一旦到了，突然之间，无论是开源软件、某个特别的方案，还是一家公司做的一件事情，都会打开一波新的窗口。
然后底层技术还在持续更新，新的窗口还会继续打开。所以我们能看到这样一个趋势：技术不断演进，应用不断延展，底层能力又不断更新。
这也是为什么中国市场和美国市场过去几年对 AI 的投资都越来越多。因为它不断证明，AI 不像 Web3、元宇宙，甚至不像当年的大数据，不是 3 年结束之后大家就不再讨论了。
今天看上去不是这样。它在持续打开很多事情，而且成本和算力都在变化。回到今天讨论一开始，龙虾引发了我们所有的话题，但现在无论是在本地还是云端，真正部署龙虾的用户量级仍然很小。
可是这么小的数量级，平摊到云厂商、模型厂商、互联网公司等这么多厂商身上，大家已经遇到了瓶颈。这才刚刚开始，很多事情远远没有到成熟阶段。
你可以极端地想象一下：如果未来每一个用户都有一个 Agent，或者都有一个个人版的贾维斯，它的能力真的达到科幻电影里的程度，那需要在今天的基础上增长多少、复杂多少？
这样说听起来可能特别乐观，像是在讲故事，但事实上的逻辑就是这样。如果今天只是一个开始，只是因为模型能力提升到了一定程度，打开了这一轮 Agent 的讨论，那么 Agent 发展到现在，又需要底层记忆、数据、数据库和存储等所有东西配套。
上面那条路才刚刚开始，那就继续往前走。
庄明浩
11. 企业稳步拥抱AI
我们今天收束到最后一个问题。现在个人已经非常焦虑，企业主其实也是，包括你们正在面对的客户。
如果今天真的有一些企业主、CTO 或 CIO，面对 AI 浪潮，希望让自己的业务和 AI 产生关联、产生绑定，你们有什么建议？哪怕是一碗鸡汤，哪怕是一个案例，都可以。
刘华阳
我先说吧。我希望企业在使用 AI 之前，首先保证它是安全的，并且数据应该进行哪怕是部分治理。
戴涛
AI 发展到今年已经 70 年了，基本上每十多年就会出现一次浪潮，也会经历寒冬。但这一波看起来可能真的会持续改变很多东西。
如果用“以终为始”的思维方式去看，企业主也好，大量用户也好，最好采取一种主动求变、快速进化的思维方式，不要迟疑。
要尽快想清楚 AI 能帮助我们解决什么问题，先用起来。但使用的时候不要一上来就过于激进，要小步快跑。个人用户可以用更激进的方式拥抱 AI，企业的方式不一样，要一步一个节奏，推动 AI 在企业里逐步落地。
刚才我们也谈到，数据是更重要的话题。所以最后也希望企业能够采用像 OceanBase 这样统一数据底座的方式，真正把企业数据的智能化和 AI 价值发挥出来。我们也希望在这个过程中，陪伴企业一起成长。
庄明浩
感谢大家收听《赛博赶海》的第一期播客节目，今天的时间就到这里。大家有什么想说的，或者想对两位嘉宾有什么询问的，欢迎在留言区评论。谢谢两位，谢谢大家。