15000千字，实况记录企业AI数据库的需求都讨论了什么---赛博赶海

https://www.xiaoyuzhoufm.com/episode/69c631d644523328b245245c?s=eyJ1IjogIjY5YTk5YWY5MjU0ZmJjYTQ3MGJjZjkxNCJ9

周一我把我去杭州的参加什么是可信数据库的问题，列了一下，我这边凭着记忆，以及一些我当时的记录，组织的当时三人行的记录，如果有什么遗失的内容，或者不全面的，还请，明浩老师，戴涛老师指正，内容太多了。

这是一场关于AI、数据库以及企业落地实践的播客录制（节目名为《赛博赶海》）。以下是按照谈话顺序整理的各方发言内容：

明浩： 欢迎来到赛博赶海，专注于探讨AI与数据库交汇处的前沿思想与创新动态。哈喽，大家好，我是明浩，赛博赶海的主播。对，然后今天非常有幸邀请到两位嘉宾聊一聊现在这个时间点，可能很热门的一个话题。

当然，我觉得今天的节目，可能跟大家最近一段时间频繁听到的很多节目的切入角度，有不太一样的角度。我们可能更多会集中在偏数据这一层面，去解读最近一段时间AI行业最热的话题，关于agent跟龙虾的这个议题，

然后要不我们今天先请两位嘉宾做个简单的自我介绍。

刘华阳： OK, 好的。我先做一个自我介绍，我姓刘啊，刘华阳。然后是一家企业的数据库架构师，也是这家企业的数据库部门的负责人。然后，特别有幸能参加这档栏目。

戴涛： 大家好，我是戴涛，目前在Oceanbase 负责AI相关的解决方案。

明浩： 听到两位老师的这个背景，大家应该知道，我们可能会集中在探讨。AI智能范围，今年尤其是二六年初，这个时间点突然带来的新一波浪潮所引发的对于数据的讨论。那先问几个这个小问题，比如说两位老师都养自己的这个openClaw，或者说在过程中遇到的比较有意思的事情，无论是你们的，还是你们听到，还是你们朋友都可以。

刘华阳： OK, 好的，那我先来哈，嗯，作为这个企业里面的一个，作为服务数据库的一个一个部门或者是一个机构。嗯，其实我们对这个openClaw这个产品是有一些看法的啊，我们先不说养不养，它就是在这个整体的openclaw的这个设计当中，在企业的落地里边，我们觉得可能会有一些问题。

嗯，对，尤其是在数据上，所以今天会聊这个问题，我们也会做一些延展，主要是数据库，其实还是要说到老本行啊，数据库，三句话离不开数据库，无论是AI还是agent，我们都是要有数据的。当然没有数据的话是不能做这些事情的，那么现在openclaw的一个最大的争议的地方就是它对使用数据的范畴与安全性的一些问题，

这是我们可能待会儿要深入去说。其实我们特别想的是说，现在养龙虾的人都是个人，他不是企业，我们为什么会很少听到某某大企业去集体养龙这个事情，因为openclaw在数据端，尤其数据库这个方面，他可能有很多的问题。

因为它是个开源的软件是的。所以说就是我作为一个企业的数据库负责人，我特别想这个跟我们的戴老师去今天多多沟通一下，多多学习一下，就是您觉得就是openclaw这一部分，比如说在数据库端。如果我们企业想去真正的应用这个部分，那企业应该怎么去做？

戴涛： 这几年其实每一年的年头，都会有些新东西。对的，你像咱们二三年初就出Chatgpt，对吧？基本上他是二二年底开始的，二三年春节大家讨论比较多嘛。对，然后呢，去年呢是做什么DCC出现的，今年呢就是说龙虾就是变得非常非常火。就刚才其实像那个刘老师谈的有一点啊，

龙虾呢，它的一开始，本质上有个问题，他是个人助理，他不是面向企业端，所以，你会发现他很短时间之内github上星标数很高，他有点梦幻中的，数字贾维斯的概念，你说句话他就帮你干活，对吧？但其实这个贾维斯，是偏个人的企业这侧呢。我们现在很多客户已经在跟了，他们跟的时候会很谨慎。比如说他们会发现，比如龙虾是个人助理，企业要做东西是啥呢？

企业真正想要的是“数字员工”，核心需求是将员工的经验沉淀下来，在一定范围内提升效率，甚至利用 AI 规模化后完成过去无法实现的任务。但这与目前 OpenClaw 这种偏向个人的特性并不完全一致，因此在企业端落地面临很多挑战。

首先是安全性问题。有客户提出，OpenClaw 这种工具在稳定性与隐私上存在风险。比如我上周见的一位大厂客户，他们测试某款 Agent 时问：“你能不能告诉我某些敏感信息？” 结果 AI “啪”地一下直接截屏，把不该展示的数据全倒出来了。

相比之下，蚂蚁集团推出的“数字医生”这类 B 端产品就好很多。针对同样的问题，它会识别出这是个“激励/诱导性问题”，并受到安全防护栏（Guardrails）的限制拒绝回答。这就是 C 端工具直接部署到企业环境时，极易引发的业务安全风险。

第二个挑战是权限接入。在个人电脑上运行 OpenClaw 很简单，权限完全由个人控制；但在企业级环境，每家公司少则几十套、多则上千套系统，权限怎么开放？即使不谈系统接口，单单开放一个 IP 权限或电脑控制权，在企业内网都是红线。

所以你会发现，企业对于“个人特性”与“企业边界”的模糊有着极大的顾虑。国内很多企业现在的做法很激进，就是直接一刀切地禁掉。刚才你问我“养不养龙虾（OpenClaw）”，现实是办公电脑上根本不能养，因为被公司屏蔽了。很多人只能在云端，或者家里弄个 Mac mini 或其他迷你主机来跑这个东西。过去这一个多月，这种“新工具冲击”与“企业旧体制”之间的碰撞非常剧烈。

刘华阳： 我这有一个问题，想来请教二位老师，现在在企业部署AI是不是一个历史重复，比如说像我们之前的公司，我之前同事的那些公司，他们在做一些大数据的项目里面就发生一些很有意思的问题。那么数据库可能是mysql、PG、oracle, 这些数据库在不同的项目里面运转，当然可能还有mongodb，这些数据的类型，数据存储的方式，以及数据本身，针对项目的重要性都是不同的。

“咱们做大数据项目，核心就是跟数据打交道，尤其是数据传输。以前经常碰着几个扎心的问题 数据容易丢。 比如在数据清洗或者传输过程中，稍微出点岔子，数据就缺一块儿。时效性差导致结果不对。 数据传慢了，最后汇总出来的报表或结果就是错的，还得回过头去重新传、重新洗。 大数据刚火那几年，大家是先‘狂欢’后‘受罪’，最后简直是‘恨之入骨’，因为太难用了！好在现在架构简化了，数据库种类收敛了，这些问题才慢慢淡出视野。但我现在特别担心的就是：现在的 AI 热潮，会不会是在重演大数据的老问题？

企业都想靠 AI 降本增效，可咱们现在的架构里又塞进了一堆新东西，比如矢量数据库。咱们得把声音、图像转成向量，存到像 Pinecone（原来的‘拼靠’）这种产品里。然后还要搞 RAG（检索增强生成，原来的‘RD’），最后再喂给大模型。

这链路一长，我不禁想问：当初大数据踩过的那些坑，是不是又要来一遍？ 比如数据缺失、数据不准确、向量空间的一致性问题，还有最让人头疼的——成本问题。

这种‘架构复杂化’带来的隐患，其实是我现在最顾虑的。”

戴涛： 刚才刘老师问了一个非常好的问题啊，其实这个问题你发现it这几十年以来啊，就是会不断重演一循环反复一些故事，刚才刘老师问的问题的核心点在于什么呢？新的这个技术浪潮出来之后。企业里面会形成新的一些数据库的，然后是不有不同的技术栈，

不都数据隔离嘛，是吧，核心其实是这个问题。每当新技术浪潮出现，企业内部就会涌现出各种新的数据库和技术栈，随之而来的就是严重的“数据孤岛”。回顾过去，新技术刚冒头时总是“百花齐放”，但很快大家就会发现由于缺乏规范，“用不好、不舒服”，于是必然进入“治理阶段”。

比如像前几年，像我们有些名词嘛，像业务中台的概念从自己的角度上去处理一个问题，现在AI的话说也是非常非常明显，我举个例子，大概从 2024 年开始，国内大规模谈论 Agent（AI 智能体） 开发。仅仅两年时间，企业内部就引入了无数套方案：开源的、商业化的、各种不同版本的框架。 在技术初期，大家为了尝鲜，跑通几个场景问题不大。但根据“技术成熟度曲线”，真正的企业级受众需要等技术相对成熟、能产生实际收益后才会大规模接入。

对吧？AI现在1-2年大家也都触摸了，他们也会提出一些治理的概念。虽然这个这个名词不完全正确，但是把有些思路给抛出来，比如说他们提出来要构建AI中台。

这个中台不一定是管业务的，它更像是一个“技术底座”。它的价值就在于：能不能把底层的能力调用给统一了？比如怎么切片（Chunking）、怎么统一向量存储、怎么搜索、怎么做逻辑编排，甚至包括现在最火的“龙虾（OpenClaw）”**，能不能也实现统一调度？ 说白了，就是要把技术栈收拢，别让架构变得太复杂。

以前咱们做开发是“老三样”：看需求、定架构、设计表结构。 但现在如果你用 Agent 开发，或者是那种 One-Coding（一键生成代码）模式，逻辑全变了。我直接给 Agent 下个需求，它“啪”一下把结果给我，我根本不需要关心后台那个“冰箱”或者“汽车”的对象是怎么定义的，也不用去死磕表结构。

虽然核心大系统现在还离不开传统模式，但对于那些需要快速迭代的业务，这种“敏捷模式”简直是降维打击。那这种模式需要什么样的数据库支持呢？它得能“吞下”所有稀奇古怪的数据。以后企业的数据形态，其实就是一个“多模态统一底座”的概念。 管它是图像、文本还是音视频，用户不需要再操心什么文件系统、什么 TP/AP（事务处理/分析处理）或者向量数据的区别。 你就统一交给我处理就完了。 我帮你入库，我帮你分析。这样一来，开发者就彻底从复杂的底层管理里解放出来了。

明浩： 嗯。那么问题出来了，在今天这个时间点，大家都说发展三个要素，算法，算率跟数据。那似乎在这个时间点，如果我们只看过去这一段时间跟未来短期内来说，这三个要素里面给你影响更大的应该是数据类型。

戴涛： 然后而且这我还我还提一下吧，就刚你说三个因素，今天正好今今天是二六年，对吧，AI出来正好是五六年出来，到到今年正好是70年。 最开始（50-60年代），大家痴迷的是算法。不管是符号主义还是连接主义，全世界都在研究怎么让逻辑跑通。到了 80-90 年代，大家发现算法跑不动，是因为算力跟不上。英特尔 CPU、英伟达 GPU 陆续登场，解决了“算得慢”的问题。这十来年： 数据成了里程碑。李飞飞搞出了 ImageNet，有了高质量的数据集，大家才发现原来两个 GPU 连在一起能跑出这么惊人的模型。 到了 2026 年的今天，情况又变了。去年的 DCC（分布式计算集群解决方案） 普及后，超海量算力的成本大幅下降，训练也不再是高不可攀的事儿。 现在，大家对算法不焦虑了，对算力也不那么愁了，真正的焦点回到了“数据”上。 对于企业来说，核心资产除了管理制度，就是压箱底的数据。现在由于 DCC 和国产芯片的推动，企业都想动起来，不管是做私有化训练还是推理自动化，需求非常旺盛。

刘华阳： 我再插一句，刚才戴老师的话让我又有一些新的想法了。这个之前我真的是没有啊， 我在想AI是不是又能带火数据治理这么一个事情，现在AI要投喂数据，那么数据都是从企业来的，这些数据是准确的吗？

我们企业的数据散落在各种地方，说实话，咱们现在把这些数据划拉到一起，谁也不敢百分之百打包票说这数据就是准的。

你想啊，你要是把这些‘半吊子’准的数据喂给 AI，它吐出来的结果能信吗？网上那些 AI 误删数据、瞎操作的案例，其实还只是皮毛。更吓人的是什么？是深度决策。万一公司拿 AI 去推演未来的经营模式或者财务数据，结果因为底座数据是错的，推演出来一个南辕北辙的方向，那这事儿可就闹大了，对企业来说简直是灭顶之灾。

现在这世道，真的是‘外行看热闹’。大家都在那儿热火朝天地‘养龙虾’（OpenClaw），听说连 60 岁的老太太都想弄一个。我觉得这气氛现在有点儿失控了。

可你看企业这边，为什么大家看起来‘按兵不动’或者走得特别稳？其实咱们是有考量的。AI 的算法层可能已经差不多了，但数据这一块儿，底子还是虚的。

尤其是现在产品太多、太乱了。作为一个数据库的负责人，我绝对不可能随随便便就引入一个新库。你要知道，数据库这东西必须经过长期的测试和投入，万一版本有个 Bug，或者稳定性过不去，那对公司来说就是毁灭性的。

所以，我特别认同戴老师说的——架构必须简单！ 别跟我整那些虚的，一会儿弄个矢量库，一会儿整套图数据库，再挂个 ES，弄得十个八个的。先不说这成本得烧多少钱，光是这数据处理的链路一长，最后这数据质量肯定得彻底失控。”

戴涛： 基本上是是这样的，刘老师谈了几个观点，其实是数据治理的问题，这个问题我再给你拆拆开看一下，其实它分成宏观中观跟微观的视角。宏观视角呢，你会发现，其实去年中国提出“互联网+”的概念之后，我们的顶层设计就开始推动高质量数据建设。高质量数据的核心就是数据治理问题，要从国家规范、行业标准这些方面去推动。因为只有数据质量高，训练和推理才会好嘛。所以这是宏观的问题，国家已经动起来了，我们也能看到一些国家课题和党的指引。

第二就属于是中观就是企业这边。其实数据治理这个话题不是新话题，很多年前就有人在讲。但因为历史原因，数据一直有各种问题，真正把它做好的人不多。但现在在企业里，这个问题就很要命，必须得做好，压力也很大。很多客户都在提要做数据治理，需要一些工具，比如统一的数据加工和存储、血缘跟踪、数据服务暴露等等。通常是一个大平台，很多工具组合在一起。企业在中观层面可能没法单靠某一个环节解决问题，但像我们这边，其实有一些数据治理的能力和经验，可以把这个拼图拼起来。

然后我说在微观层面上，就是企业内部的具体做法。很多企业可能不会马上全面推数据治理，因为企业也像人一样，有性格。有的老板喜欢尝鲜，怕错过机会，就先追AI。这时候可能没法先花一两年搞数据治理，而是先在某个局部，比如生产域、营销域、销售域，或者IT开发上，先做一些试点。这样两条线并行：一边推进数据治理，一边在局部做AI应用。我们发现企业推AI一般有个节奏：先从0到1，走第一步，比如搞个知识库、营销视图之类的。走到第一步之后，再从1到10，逐步在各个板块铺开，搞自媒体、知识库、提效、降本增收的东西。第三步就是收回来，结合AI中台、数据底座，做更深的融合。这一定是一个迭代的过程，是自然规律。虽然AI发展很快，但企业信息化真正成熟还是需要周期，需要时间去沉淀。虽然AI说发展很快，但是我觉得伴随这个发展，它的企业信息化真正成熟的是有点周期的，特别看说是龙虾的对吧，我在得说是需要点时间啊，让他成熟。

刘华阳： 对，是，然后我这边其实，有一些同事就是之前的同事，也问我们企业这个在AI方面有没有推进。然后他们也曾经提到有一些厂商啊，我也不太方便去说哈。他们发现一个问题，现在的数据库只要是加上向量，他们就说是AI支持AI的数据库，我作为一个数据库的从业快20年的这个人，我不太认同这种概念。不是说支持向量就叫向量数据库。我特别想问戴老师，您对这种加上了向量，就说是AI数据库，是什么一种看法？

戴涛： 这个概念呢，其实我觉得就是一个“缝合”的过程。因为你要是从时间上倒序来看，向量数据库并不是因为大模型出来之后才出现的，它其实十几年前就有了。比如在 Web3 那一波的时候，就已经有人在做相关产品。虽然当时解决的问题不完全是大模型的问题，但它有它的价值：它能把高维空间里的数据，转化成一个点，方便在高维空间里做相似度搜索。这就是它的意义。

后来大模型出来之后，需求一下子膨胀得很快。因为最早的大模型是大语言模型嘛，它带来的是语义搜索的能力。而传统搜索是关键词搜索，靠 key 去匹配。但有了语义之后，就引入了“向量检索”的概念，这时候向量数据库就被激活了，正好契合这个场景。 现在向量数据库大概有三个流派，纯向量型，只做向量存储和检索，其他功能不支持或者慢慢补充。这类的根源来自 Facebook 当年开源的 Faiss，很多国内外的纯向量数据库都是基于它迭代出来的。关系型扩展，像 Oracle、Postgres 这种传统关系数据库，在内核里原生加了向量支持，不是外挂，所以性能更好。非关系型扩展，比如 Redis、MongoDB、Elasticsearch，它们本来不是关系数据库，但也加了向量能力，满足不同场景的需求。

这三类的差异在于：纯向量库只管向量，关系型和非关系型数据库则是把向量作为扩展功能。现在的需求其实很复杂，尤其在结合 AI 的场景下，往往是跨领域的，不只是文本检索，还涉及多模态，比如文本要做语义检索，图片要转成向量，但标签数据要用 JSON 存储，还要做文本和向量的联合检索。

刘华阳： 其实说到这儿，我特别想再问一个更深入的问题。这也是我最近一直想不通的地方。我们刚才提到“缝合怪”，我觉得这个说法很有意思。现在很多企业还是掉进了“缝合怪”的状态，但我们其实特别不想再陷进去。

除了把数据存到不同类型的数据库里，这是一个层面的“缝合怪”。在更深层次，其实在数据的过滤和查询上，也有很难搞的问题。比如现在：

向量数据在数据库里，

标量数据也在数据库里，

音频、视频、图像这些数据又在各种不同的库里。

那我在查询的时候，到底应该先从哪儿查起呢？

举个例子：我到了杭州，想找一个特别好吃的馆子。我给了一个条件：在我当前位置的250米范围内，找一个特别好吃的杭州菜馆。你看，这里面的查询模式就非常复杂：

地理数据：要先确定范围。

语义数据：什么叫“好吃”？这就要靠 AI 来评定。

动态位置：我在走动，250米的范围也在不断变化。

这种查询和以前完全不一样。过去我们写个 SQL 语句，比如 =某个值 或者 NOT IN (...)，就能搞定。但现在这种多模态查询，根本没法比。

所以我特别想问：如果我们把这些数据都分散存到不同的产品里，那查询的时候到底该怎么做？哪个应该先查，哪个应该后查？如果顺序不对，比如我先查“杭州最好吃的馆子”，结果出来几万条，但它们都不在我250米范围内，那就等于白查，浪费时间。AI返回的数据可能是空的，或者没用。

那我就想问戴老师：如果我们把这些数据都集中到某一种数据库里，是不是查询会更好做？是不是能自动判断应该先查哪个、后查哪个？有没有这种更高级的状态？

戴涛： 其实可以从两个层面来回答：一个是偏开发的层面，一个是偏架构的层面。

开发层面
就像刘老师刚才说的，现在企业里的很多搜索场景，本质上就是“搜+推”的组合。比如在知识库、智能问答这些场景里，经常会遇到跨多个数据库的查询问题。传统做法是放在应用层里自己写逻辑去处理，比如企业里常见的情况：

需要一个关系型数据库；

需要一个纯向量数据库；

还需要一个全文本数据库。

这样应用程序就要自己去决定查询策略：先查哪个，再查哪个。问题是，代价很大，计算量也很高。一次两次还好，但如果是企业级服务，成本就会迅速增加。

所以关键不是简单把数据放在一起，而是要有一种方式，在软件层帮你定义搜索策略，根据数据的分布自动决定查询顺序。我们内部就做了这样的东西，叫“混合搜索”。

混合搜索的逻辑是：把标量、向量、文本、标签等数据统一存储，但每种数据的索引结构不同。比如：

标量可能用 B+ 树；

向量用 HNSW 图算法；

全文本用倒排索引或 BM25。

如果让开发者自己去判断这些太复杂了。但如果把这些交给优化器来做，就能自动决定执行顺序。比如你写一条 SQL： “搜索 500 米范围内，评分 4.5 分以上，价格 50 元左右，人少安静的咖啡厅。” 这条语句里同时包含了地理数据、标量数据、向量数据。优化器就能自动组合策略，减少开发负担，还能避免出错。

架构层面
架构问题更要命。现在很多企业一上新系统，就要加一个数据库。你看很多开源平台，后台一堆三叉结构，删了之后还要考虑容器拉起、部署、灾备、备份等等，复杂度非常高。

明浩： 哎正好还说这个问题，就我在准备的时候，正好就就前两天Google map迎来了史上最大一次更新，他现在主打的就是ask maps, 就跟刚才讲的这个案例是一模一样的。他举的案例就是说，比如说我要就这附近找一个适合约会宠物友好人不太多，马上就要去的一个什么样的意大利餐厅，然后最好能提前预定。就是当然，我们听到这个需求之后，你还是可以用传统的关键词态来去解。但似乎就这种就求当它变成一个没有边界，没有办法用传统意义上的说关键词跟他的方式去限定的时候，你还要给他结果，还要返回合适的方式，那似乎对于比如像Google map的团队而言，要做的事情就是刚才你说的所有这些事情。而且你肉眼可见这种趋势会随着A大门推进发展之后，这种需求会越来越多，跟常见，甚至可能成为某种意义上的新的用户的界面的交互的范式对吧，那那当我们都要去面临这样的解决方案的时候，那对于在做相关业务的公司跟企业而言，那似乎就要有一个新的底层的配套，无论数据也好，架构也好，去适配这样的需求，那似乎确实在往这儿走，对吧？

戴涛： 我看那个是Google map什么十十年以来最大的更新，他把这个话题放到这么高的高度，其实也说明了：最先进的一些厂商确实在面临这些问题，并且在解决过程中也有一些思路。比如刚才提到的那个案例，我们在 2024 年的大会上发布产品特性时，就举过类似的例子：搜索 500 米范围内、不同价格、不同类型、而且“好吃”的餐厅。这个场景我们作为一个重大特性来展示，也放到了官网上。

官网上有一个基于高德地图的示例：比如在杭州，几百米范围内找到最好的酒店。这个例子大家一看就明白，这就是业务落地的角度。那业务落地我觉得有两个问题：

第一个是搜索引发的数据问题；

第二个是 AI 大模型带来的“记忆”问题。

关于记忆这块，最近大家讨论很多。大模型出来之后，大家都说上下文结构是很多厂商在突破的点。但上下文只是记忆问题的一个狭义表现。很多人也会说，在这波大模型的架构创新里，像龙虾这样的产品，可能在 0~1 的创新上不算特别多，但在工程架构设计上做了很多工作。尤其是在存储文件（比如 SOD、MD 文件）的设计上，差异很大。这也带来了用户体验上的不同：用龙虾和用普通大模型聊天，确实在“记忆”层面有明显区别。

所谓“记忆”，其实也是数据问题的一种表现。只是现在大模型厂商做的，是不断扩展上下文，把能处理的数字范围加大。但这也带来了很多问题。于是市面上出现了一些专门针对记忆的外挂系统，在特定场景里解决模型的记忆不足。比如龙虾用“社会能力”来解决部分问题，用 Markdown 格式来做记忆管理，这可能是一种妥协方案。它不是最终答案，但在现阶段算是比较匹配的技术选择，兼顾了发展状态、成本和实施难度。

所以问题就在于：大家如何看待记忆的发展？对相关厂商应该提出什么样的要求？

刘华阳： 其实我特别想接着刚才那个话题说哈，比如说我我不是第一次来了，我是第二次来了，那第二次来可能我上次问过这个问题呢，可能有一些这个标记，比如说上次我是一个人来的，可能这次我还是一个人来的。那他推荐的这个这个产品是不是有记忆记忆。

上次我来过，根据他的推荐，再加上这次又提出了类似的问题，我就想通过一些方法算出一个差不多的解决方案。那就是说，我需要把之前的信息存储下来。

但是问题来了：对企业 AI 来说，这可能看起来很简单，但对企业本身却非常困难。因为我真的不知道这些数据要存多久。企业里的数据通常是有周期的，比如这批数据规定存 3 年，那批数据存 5 年，到了时间就清理掉。可是 AI 的数据怎么标定呢？理论上是不是应该一直存在？我到现在都没办法确定什么时候该删掉这些数据，也没有人能告诉我。

这就成了一个最大的问题：一方面数据可能要存很长时间，另一方面还要随时调用。这样就牵扯出很多难题：

成本问题；

调用问题；

存储问题；

接口问题。

戴涛： 其实企业在引入智能体的时候，可以理解成一个公式：大脑 + 记忆 + 工具推理 + 工具执行。其中“记忆”是非常关键的一环。

就像明浩刚才说的，记忆有很多解法。对模型厂商来说，他们倾向于无限扩展上下文窗口，因为这是直接的卖点。但问题是，窗口再大也有极限，你不可能真的把整本百科全书都塞进去。企业从数据治理的角度看，更希望模型是“无状态”的，最高效地推理，而记忆则通过外部解决方案来处理。

目前常见的几种记忆方式：

本地缓存/存储：比如龙虾里的 MD 文件，本质上就是一种本地缓存。

文档型记忆：像 RAG（检索增强生成），把企业内部的大量文档作为知识记忆，随时检索。

记忆体（Memory Unit）：去年开始流行的概念，把对话式、偏好型的信息单独存储，形成一个记忆体。这样可以处理用户习惯、个性化需求。

技能型记忆：把 SOP 或技能流程固化成记忆，模型调用时就像调用技能一样。

这些记忆方式可以对应不同场景：

知识记忆：企业文档、知识库。

对话记忆：多轮交互、用户偏好。

技能记忆：固定流程、操作 SOP。

私有记忆：个人信息。

团队记忆：多个智能体之间共享的信息。

所以企业需要一种“记忆体解决方案”，来管理不同类型的记忆：短期记忆（临时信息）、长期记忆（关键知识）、私有记忆（个人信息）、团队记忆（共享信息）。同时还要支持 API 级别的操作，比如新增记忆、追溯记忆、更新记忆、淘汰记忆。

我们也针对不同场景推出了不同的方案：

针对知识库场景，做了一个叫 抛转 的企业级软件，结合数据库的搜索能力，统一处理知识检索。

针对记忆体场景，做了一个叫 Memory 的软件，兼容开源的 Memory API，但提供更强的功能，既能处理知识型记忆，也能处理对话型记忆。

举几个例子：

淘宝的 AI 万能搜：它能记住你之前的搜索和场景，比如节日送礼的需求，下次再提醒你。

蚂蚁的“阿福”：定位为家庭私人医生。刚推出时没有记忆，每次问问题都像新病人，体验不好。后来加了记忆功能，能保存你之前的健康信息和报告，再回答时就更贴近你的情况。

陪伴类产品：以前多轮对话都要完整保存，成本很高。现在通过记忆体提取关键信息，比如毕业时间、工作经历、旅行记录，只需要传递小窗口就能维持上下文。

明浩： 今天聊到这儿，其实让我有了新的思路。不同的解法会直接决定成本，戴老师的扩展让我意识到：如果能优化记忆和上下文，就能节省大量 token 的费用。要不然真的用不起，成本太高。

我们公司的现实案例就是这样。我们是一家做社交的公司，在 AI 上的尝试也遵循这个逻辑。大家普遍觉得传统的大模型更多是做普通语言的处理，但如果要加一层“情感”，做更复杂的表达，通用模型就很难解决。你可以用提示词去调，但成本太高，我们也试过，发现根本扛不住。尤其在国内，用户很难直接为这种体验付费，海外可能好一点，但国内基本没人做。

所以我们尝试过一段时间后，最后决定自己做一套系统。逻辑就是：既然通用大模型的上下文记忆能力解决不了，或者成本太高，那就在特定场景里自己做一套专门的解决方案。这样既能提高效率，又能更贴近人的感觉，同时还能降低成本。

现在市面上也有一些公司在做类似的记忆系统，都是针对固定场景，在通用模型的基础上深挖，做出更适合的东西。效果已经开始显现。可以说，这是一种“中间态的妥协”，但它让大家看到了和通用模型（比如 ChatGPT 或豆包）相比的巨大区别。

往后看，应该还会有更好的演进。我们能提前感受到，这种专门为场景定制的记忆系统，会让体验更容易提升，也更符合企业的实际需求。

刘华阳： 其实刚才明浩老师提到的 Markdown 作为通用方案，我觉得对个人用户可能还行，但对企业用户来说就很难接受。原因很简单：每个企业都有严格的数据安全要求。比如我们企业要过 27001、ISO 14000 之类的认证，所有数据都要经过审核，每一步操作都有记录，每一份数据的存储都必须在安全范围内，而且有人会检查。

在这种情况下，像 Openclaw 这样的东西，企业根本没法用。最根本的原因就是它突破不了企业的数据安全防线。如果用了，企业数据暴露了，那作为乙方我们直接会被甲方投诉，项目也没法继续做。这是过不了的关口。听说有些国家甚至直接禁掉了类似的产品，就是因为数据安全问题。对企业来说，这个部分是没有办法逾越的。

所以我特别想请戴老师谈谈：如果企业真的要用 Openclaw，那这些数据到底应该怎么存？怎么保证安全？

明浩： 对中国企业来说，这确实是个非常重要的命题。比如龙虾出来三个月了，你会发现中国这边的讨论比美国还要热烈。很多互联网公司都在尝试各种玩法，而美国的几家大厂反而比较安静。

为什么？因为中国的产品更丰富，大家更愿意去试。但这也带来了新的问题：如果龙虾真的成为一个入口，嵌入到微信、钉钉、飞书里，它就会变成一个数据入口。所有的搜索、知识库、企业制度、定时任务、甚至写代码、问问题，全都通过它走。它就成了一个应用入口。

这时候，安全问题就会被放大。你说企业把所有东西都丢给它，那数据安全怎么保证？这就是第三个必须要解决的问题。

所以我觉得，现在的情况是：模型能力已经 ready，可以从语言走到行为，从聊天走到 agent。但一旦进入行为层面，就必然会遇到权限、数据安全、隐私围栏这些问题。龙虾的做法是极端的，它完全开放，不管安全，这当然会在一部分人群里很受欢迎。但它不是一个适合企业的示范。

我们需要的是一个中间的方式，既能推动技术往前走，又能真正适合企业和个人的使用场景。安全这个话题太大了，涉及数据安全、隐私、权限、账户等等，本来网络安全就是一个庞大的产业链，现在等于给了整个行业一个统一命题，让大家一起解决。问题被推到这个程度之后，你会发现它真的很难解。

刘华阳： 其实从我们企业的角度来说，我们更希望 AI 的使用能简单一些，不要搞得太复杂。比如说我们已经非常熟悉 SQL，那未来是不是有可能在用 AI 查询的时候，还是沿用我们现有的方式？哪怕稍微改一改就行，而不是整体推翻，让我们重新来过。

因为如果完全推翻，不光是人员的学习成本高，维护成本也很大。我们更希望数据库厂商能考虑到这一点，把企业一些简单的 AI 使用需求融合到数据库里，融合到 SQL 查询里去做。这样我们就能在熟悉的环境里，直接用 AI 的能力，而不是重新搭一套系统。

有没有这种可能性呢？

戴涛： 我回忆一下刚才老师的题目，其实我们今年也调整了产品愿景。我们不再只定义自己是数据库厂商，而是定位为“智能数据平台厂商”。为什么呢？因为数据库本身不是新东西，六七十年代就有了，IBM 的 DB2 就是典型代表。我们最早的产品基础，其实就是解决海量交易，比如淘宝、支付宝这些场景。

后来到了企业端，我们不断做调整。像淘宝是海量大集群，但企业端没那么多基础设施，所以我们就做了三副本架构，再推出主备架构，满足企业应用的成本要求。去年我们还推了一个子产品 CDB，解决嵌入式和端侧的需求。OB 本身是云产品，以分布式为主，现在我们也在做端侧的版本。通过这些产品组合，我们其实就是在解决传统 AI 搜索的问题。

所以当时我们还叫 AI 数据库，强调混合搜索、AI 函数这些能力。但往下走你会发现，它已经不只是数据库了，而是更像一个智能数据平台。比如说数据湖、Lakehouse，可以统一处理各种数据，包括图文数据。

再回到你刚才问的，SQL（CQ）作为底层语言，它依然是基础。我们会继续以 SQL 为核心，把它做得更强，同时拓展新的语法，支持更多数据类型和场景。对于专业用户，SQL 是必备的；但对普通业务用户来说，SQL 学起来还是有门槛。所以我们在上层会提供一些中间件和工具，比如知识库入口、Web coding、AI 工具，让用户不用直接写 SQL，也能用 AI。

这就回到一个统一平台的概念：统一存储、统一任务调度、统一负载管理，再加上企业级的安全和管控。比如你提到的 Markdown 文件不安全，我们就把它放到数据库里，或者放到云上的沙箱里来管控。Skill 文件也是一样，它本质上是 SOP，不能随便改，我们也把它放到数据库里统一管理。

刘华阳： 对戴老师您刚刚提到了一个问题，让我有了一个怎么说呢，就是对其他数据库的一些一些想法啊，就是您刚刚提到咱们的产品已经改了策略叫数据库平台愿景，愿景有愿景就改，你改了，但是我非常担心，就是现在很多的就是国外的数据库产品，他们的理念还是以数据库单体或者是处理单纯的数据查询为主，就是我我就想这样的企业，如果他不改变，是不是可能就在这一轮的AI的浪潮里边可能就被洗掉了。

戴涛： 我回忆一下刚才老师的题目，其实我们今年也调整了产品愿景。以前我们只定义自己是数据库厂商，现在我们更愿意叫自己“智能数据平台厂商”。为什么呢？因为数据库本身不是新东西，六七十年代就有了，IBM 的 DB2 就是典型代表。我们最早的产品基础，其实就是解决海量交易，比如淘宝、支付宝这些场景。

后来到了企业端，我们不断做调整。像淘宝是海量大集群，但企业端没那么多基础设施，所以我们就做了三副本架构，再推出主备架构，满足企业应用的成本要求。去年我们还推了一个子产品 CDB，解决嵌入式和端侧的需求。OB 本身是云产品，以分布式为主，现在我们也在做端侧的版本。通过这些产品组合，我们其实就是在解决传统 AI 搜索的问题。

所以当时我们还叫 AI 数据库，强调混合搜索、AI 函数这些能力。但往下走你会发现，它已经不只是数据库了，而是更像一个智能数据平台。比如说数据湖、Lakehouse，可以统一处理各种数据，包括图文数据。

再回到你刚才问的，SQL（CQ）作为底层语言，它依然是基础。我们会继续以 SQL 为核心，把它做得更强，同时拓展新的语法，支持更多数据类型和场景。对于专业用户，SQL 是必备的；但对普通业务用户来说，SQL 学起来还是有门槛。所以我们在上层会提供一些中间件和工具，比如知识库入口、Web coding、AI 工具，让用户不用直接写 SQL，也能用 AI。

这就回到一个统一平台的概念：统一存储、统一任务调度、统一负载管理，再加上企业级的安全和管控。比如你提到的 Markdown 文件不安全，我们就把它放到数据库里，或者放到云上的沙箱里来管控。Skill 文件也是一样，它本质上是 SOP，不能随便改，我们也把它放到数据库里统一管理。

所以我们现在的定位就是：结合传统数据库的优势，加上智能数据平台的能力，再叠加企业级的安全和管控，来满足客户的需求。这样既能延续原有的数据库逻辑，又能承载新的 AI 场景。

刘华阳： 然后明浩老师，我我还想问您一个问题啊，就是今天我还是本着一个小学生的一个态度，就是就是如果从投资的这种角度来说，假如说咱们去找这个好的数据库公司，那么去投资，那么如果您是一个资深的投资者，那么您。以哪些指标或者是以哪些方面可能去判定，哎我想投试试，或者这个不行，

明浩：从我们企业的角度来看，其实底层的记忆、数据、数据库、存储这些东西都要配套好，才能支撑上层的发展。你会发现，上面那条路才刚刚开始，还得继续往前走。

上次跟 CTO 聊的时候也谈到这个话题。国内大家还是习惯把 ToB 和 ToC 分开看。数据库厂商、软件公司、SaaS 公司基本都算 ToB 市场。过去十几年，这个市场一直有基金在持续关注，但也遇到一些现实挑战。前两天美股很多 SaaS 公司暴跌，像 Salesforce 这些都在跌。美团的王兴也说过一句话：大家原来期待中国的 ToB 市场能像美国一样繁荣，但结果并没有出现。现在反而因为 AI 的崛起，美国的 ToB 公司也开始面临类似的估值压力。

不过这也带来一个新的逻辑：在新能源时代、在 AI 浪潮下，很多事情都值得被重做一遍。原来 ToB 和 ToC 的分法，可能本身就要重新审视。因为 AI 能力的提升，企业的组织形态、采购流程、服务模式都会发生变化。比如龙虾的兴起，就让我们看到了一些新的苗头。过去大家说中国用户不愿意付费，但这轮 AI 浪潮里，个人和企业的付费意愿其实比想象中要好一些，至少没有那么悲观。

再落到数据库这个角度。过去大家看软件、SaaS、云厂商，主要是战术层面的指标：收入、市场占有率、口碑、发展速度等等。但这些指标在过去十几年证明并不完全有效。AI 出现之后，数据的地位和状态已经不只是软件公司能解决的事了。我们愿景也变了，不再只是软件，而是平台化运营。既然是平台，就应该用平台企业的方式去衡量。

所以评判标准和逻辑框架也要调整。很多东西不是明确的指标，而是一个“度”的问题。等到某个阈值被突破，局面就会被打开。过去几年 AI 的发展就是这样：从大模型到多模态，再到 Agent，每一步都是技术到了一定程度之后，打开了新的窗口。开源软件、ToB 生态、个人用户的习惯都因此发生变化。

这也是为什么美国和中国的市场在 AI 投资上都越来越多。它不像 Web3、元宇宙、大数据那样，三年热潮之后就没人提了。AI 是持续在打开新局面的。虽然现在龙虾的用户量还很小，但已经让很多厂商、云公司、互联网公司感受到瓶颈。说明这才刚刚开始，未来如果真的每个用户都有一个 Agent，能力能像科幻电影里那样，那今天的基础还要再复杂、再扩展很多倍。

所以总结下来就是：今天只是开始，因为底层模型能力到了一个新的阶段，才打开了 Agent 的讨论。接下来它会不断延展，不断更新，再打开新的局面。

刘华阳： 说的太好了，明浩老师，我觉得你特别像一个太阳，就是AI来了以后，给我们很多人很多的压力，其实是阴云密布的。您这么一说把整个阴霾给扫平了，我觉得，我们以后肯定会好的。

明浩： 那我们就聊到最后一个问题吧。因为今天两位嘉宾，一位是在企业里做，一位是面对很多企业客户。其实现在不光是个人很焦虑，企业主也一样。大家都在想：在这波 AI 浪潮里，怎么才能让自己的业务跟它产生关联，甚至绑定在一起。

那如果真要给这些企业主、他们的 CEO 或 CIO 一些建议，哪怕是一碗“鸡汤”，或者一个案例，都可以。

刘华阳： 嗯，那我就先说吧。我还是回到最开始提到的问题，我希望我们的 AI 在使用之前，它是安全的，而且数据要有治理，哪怕只是部分治理。这样企业才能放心。

我觉得未来国产的数据公司在这方面是有很大空间的，可操作、可发展、也有向上的潜力。所以我觉得未来是美好的。AI 给数据库公司带来的，不只是挑战，更是希望、机会和新的想法。

所以我对这件事还是挺有信心的。

戴涛： 现在是AI，科技已经发展了七十年了，基本上每十多年就会有一波浪潮，也会有一段寒冬。但这一次看起来，可能真的会持续改变我们很多东西。所以我觉得，如果企业主或者用户要去思考这个问题，最好是保持一种主动求变的心态，要快速进化，不要犹豫。今天就要想清楚：AI 能帮我解决什么问题？然后尽快用起来。

当然，用的时候也不要一上来就太激进。个人用户可以大胆尝试，但企业最好是从小范围开始，一步一步推进，把 AI 落地到具体的业务场景里。而且我们也要看到，数据才是更重要的话题。最后还是希望企业能采用像 OB 这样统一的底座，把数据真正管理好，发挥更大的智能化价值。我们也希望在这个过程中，能陪伴企业一起成长。

明浩： 感谢感谢，感谢大家收听赛博亚海的第一期博客厅，今天在这里，大家有什么想说的或者想讲的，想对两位嘉宾有什么询问的，欢迎大家在留言区评论，感谢感谢。