面向 AI Agents 的高性能数据基座：架构和工程实践

随着大模型快速发展，以 AI Agents 驱动的新一代 AI 原生应用快速发展，取得巨大成功。AI 原生应用以大模型为基础，通过各类 Agents 和应用数据交互，智能地完成各类任务。AI Agents 驱动的应用开发迭代迅速，同时维护多种模态的数据，不同模态数据的访问模式和流量差别巨大，这些特点给底层数据平台提出了新的挑战。未来 AI Agents 驱动的原生应用需要怎样的数据基座？

在 InfoQ 举办的 QCon 全球软件开发大会（北京站）上，晨章数据创始人、首席架构师陈亮带来了题为《 面向 AI Agents 的高性能数据基座：架构和工程实践 》的演讲，分享了关于 AI 时代数据基座架构的思考，如何通过该架构解决 AI 原生应用的数据挑战，以及在云计算、新硬件环境下实现高性能数据基座的工程实践。 

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

AI Agent 驱动的 AI 原生应用 

今天，AI Agent 正在引领整个软件范式的变革。在 AI 时代之前，我们讨论的是 SaaS，彼时软件作为工具实际上是构建了一个工作流程，在这个工作流程中帮助人来完成某些工作。而 SaaS 变成 AI 驱动后就会发生范式变化，软件变得更加智能，变成了智能体，可以执行非常复杂的任务，甚至可以有一定的自我演化和改进的能力。从这个角度来说，它不再是个帮助人的软件工具，它自己就变成一个智能体，可以直接提供一个服务。

在 SaaS 时代，SaaS 软件会有工作流，用户会提供一个输入，工作流帮助用户完成某些任务。工作流中间会收集很多数据，很多状态，这些状态会记录在某个数据库里，很多时候它是结构化数据。这里有一个显著的特性，就是第一个数据是由这个软件生成出来的，或者我们认为说数据是软件的一个排放。所以在这样的一个架构下，大家对数据会有一些比较简化的期待。

第一个数据的格式往往是软件开发人员定义的。因为这是我写的软件，所以我想定义这个数据有什么属性，大概以什么格式，到底是个表格还是个图，这个是我开发者来定义的。同时数据也是在软件的运行过程中不断收集的，意味着我的数据量是随着我的软件规模和用户互动慢慢在增长，总的来说是可控的。

当然随着软件越来越复杂，收集数据越来越多，最终数据的格式可能会变得更加复杂，我需要更加智能的分析，但这个过程是一个相对缓慢的过程，这个过程是随着我的软件越来越流行，用户量越来越大而发展的。可能很多软件并没有爆款，它对数据的需求也就并没有那么高。

在 Agent 时代会有什么变化？首先在 Agent 场景中，它的工作流就不再是工作流，开发更多关注在 Agent 的编排上，我们可能会有很多个 Agent。当然核心是大模型，我们怎么用大模型去驱动不同的 Agent？这里有一个很不一样的点，就是说在今天我们刚开始开发应用时就需要有数据，数据可能来自知识库，可能来自外部的某些结构化数据，这个数据实际是作为 Agent 的燃料，就像汽车冷启动需要燃料一样。大模型更多像一个驱动引擎，因为大模型只能提供一些比较通识性的东西，我要去实现一些非常领域特定的任务实际是有困难的，所以我需要很多数据，而且是行业的数据。但这个数据是外部来的，所以数据的格式、数据的规模可能不是我所能完全掌控的。

AI 与用户不断交互还会产生更多数据，同样它会生成底层的数据。我们接触了很多 Agent 开发的项目，我发现它们在第一天的时候就考虑数据的反哺，换句话说我不但要收集数据，还要用数据丰富我的知识库。最终我提供的就是一个服务，用户看到的是一个整体的服务，它不再是帮助人的工具，这时它自己可能就变成了一个智能体。

举一个具体的例子，这是一个金融的场景。

这里有 4 个 Agent，有一个 Agent 主要负责市场分析，一个 Agent 要关注风控，等等。从数据的视角来看，在这个 App 里我们可能需要很多种不同的数据库。我可能需要有用户的信息，用户的信息一般是存在表格里的。我可能会有财报，往往是一种半结构化的数据，里面可能有一些结构化的东西可以抽出来。如果外部的知识库很大，包括很多日志，它可能也是要放入 Mongo 的。

Pinecone 和 Elastic 大家比较熟悉，因为在大模型时代你的文本是很重要的事情。当我们提到文本搜索时，实际上向量和全文往往是要一起做的，同时可能还要搭配一个 Ranker。当然可能还会有知识库，有些知识库是通过图来表示的，因为用户有不断的反馈的时候，这个时候你的 Agent 往往需要一些对话的信息，而且延时要求很短，所以我需要一些基于内存的数据库。

所以在搭建 Agent 应用的第一天，可能就会涉及到很多种数据库了。而外部来的数据规模你是不可管控的，如果规模很大怎么办？这个时候你就得用一个有扩展性的选择。同时从性能要求来说，因为有些业务是和用户要交互的，所以延时要求天生比较严苛，所以我一定会有一个纯内存的东西。

上图展示了今天常见的一个 Agent 的工作流。它一般是一个网络服务，用户会登录进来，登录之后你会有用户的信息，这时你就要访问一些关系型数据库了。

Agent 里有一个很重要的，我们叫 Agent Loop 或者叫一个环。因为交互往往不是一轮的，需要很多人不断迭代。这个 Agent 它自己可能会调大模型，获取一些信息，还会有很多外部调用。外部调用可能来自网络搜索，可能外部有某个计算服务。当然还有一个很重要的方式就是 RAG，可能会有全文知识库的 RAG。

这里还有短期和长期的记忆，有不同的延时需求。短期记忆可能要放在一个基于内存的东西，长期的规模比较大的就放在一个相对持久的数据库里。所以不同的数据都需要自己对应的数据库，而且在应用交互的过程中还会不断生成新的数据。

简单总结一下，互联网时代和 Agent 时代从数据角度来看的第一个区别就是前者的数据是由应用生成的，意味着数据是可控的。但在 AI 时代就不一样了，因为可能会有很多外部的数据进来，这个东西不是你完全可控的，而且规模也可能会很大。另外 AI 时代还会有大量非结构化数据，所以今天几乎所有的数据库都要发展向量的能力，因为搜索变得越来越重要。最后一点就是 Agent 是会互相交互，会跟外部交互的，交互时它是要把内容记录下来，所以数据量很快就会积累起来。

AI 原生应用面临的数据挑战 

从系统的角度来说，AI 时代的这些特点会给数据库管理带来很多挑战。第一个挑战就是我们希望数据库会有多模态。第二个是当我们有很多个数据库，数据的同步和数据一致性总是要考虑的。比如说我们在聊天里可能有短期记忆，最终总是要把它变成长期记忆的，同时应用输出的内容也总要反馈到原来的各种数据模型下，就会有一个数据的环。第三点，应用中不同数据库对性能、规模等属性的要求各不一样。最后就是多系统的运维和管理。今天的 AI 时代我们可以快速开发一个应用，可能 3 个人的团队 6 个月就可以快速搭建 1 个 App，但我要运维 App 反倒变成了一个很大的成本，因为数据要不断积累，这是你的核心价值。

总结来说，AI Agent 驱动的应用在早期就会面临传统大厂才会有的数据挑战，同时数据飞轮在 AI Agent 时代迭代更加迅速，加剧了数据库系统的压力。

多模态数据基座 

在这样的背景下，我们的思考就是我们应该做哪些事情，能不能有一个统一的数据架构来做这样的事情。最终的方向就是多模态的数据基座。

我们的设计目标有三点，第一点就是支持多种数据模态。在 AI 时代，可能一个应用就会面临多模态支持的问题。我们想特别强调两个方面，第一就是我们希望它的 API 是原生兼容的。比如说我有个 Json 的 API，至少应该是跟 Mongo 兼容；我是个 SQL API，应该可以和 MySQL 兼容，这是一个很重要的点。因为开发人员希望我的系统是可扩展的，可迁移的，有的时候我可能想在云上部署，有可能我想在私有化部署，私有化部署甚至还可能有很多限制，所以你用标准的 API 变得非常关键。我当然可以自己定一个 API，但如果让大家来我这边建立 App，未来就会有很大的风险。第二个我想强调的是性能。性能和成本永远是长期的考量，我觉得这可能是最关键的，对系统开发人员来说可能是最重要的点。用户在选择的时候，如果你的系统性能比别人慢，你说我的价值来自多模态，这个论述就变得非常弱了。

第二点设计目标就是动态伸缩，自动管理。这是和今天云原生的趋势是很吻合的。

第三点目标是跨模态访问和一致性。模态之间是有数据的相互同步，同样有一致的访问。我并不希望比如我有 8 个数据库，大家各干各的。数据库之间的壁垒要消融掉，是多模态很重要的点。我并不需要一个中间件或者一个代理，把所有的数据库连接起来，然后统一提供接口，这个意义并没有很大，你没有降低它的管理成本。同时在有些应用里，从长期记忆到短期记忆，从我的结果到抽取回知识库里，很多时候都是跨模态的访问。

在讲多模态数据架构之前，我先简单回顾一下数据库架构的演化历史。

数据库在很早以前实际上就一台机器，后来数据库演化就分叉了，分成了 OLAP 和 OLTP。到了云时代，之前 OLAP 数据库的无共享架构就不是特别理想，于是就有了新的做法叫存算分离。OLTP 一开始也有无共享架构，但后来它的演化就没那么简单。因为 TP 和 AP 之间有一个很大的不同，AP 里不太在意内存缓存。因为它要不断扫描大量数据，内存肯定放不下，最后总是要扫描磁盘的。可在线的 TP 就不一样了，因为需要毫秒级的延迟，所以内存缓存非常重要，是保证延时最重要的手段。而无共享架构下计算和缓存不在一块，每次访问都要走网络，那么在 Agent 时代这个延迟就很难保证。所以业界提出了 Aurora 的架构，把缓存提上去，计算和缓存在一块，然后下面有个存储，我们叫共享存储架构，这样它的延时可以保证。

我们的思路是，在计算和存储之间会有一个数据的基层，在基层里我最强调的就是缓存，缓存是保证在线数据库延时里最重要的一个事。而且在线数据的所有模态，不管是做向量搜索、全文搜索还是做 graph，最重要的都是缓存，不在缓存里的东西延时是很难有保证的。

我们的数据基座里上面会有计算，下面会有存储。计算引擎是可以换的，什么样的引擎都可以，我们可以和很多开源组件原生兼容。中间我们会有一个数据基层，它抽象出来了在线数据库里最核心的一些功能，其中最重要的就是缓存。同时我们希望能用统一的缓存格式来弥合或消除不同数据模态之间的壁垒，使得数据在统一访问，或者在跨模态访问时可以高效。

另外在我们这里缓存和计算是逻辑解耦，物理耦合的。物理耦合指的是缓存尽量放在机器本地内存上，减少跨网络读取。逻辑解耦是想用它来消除不同模态之间的差别，通过缓存实现和原生系统一样的性能。

提到缓存，大家可能第一反应就是一个传统的哈希表。但因为我们的数据是想支持不同模态的，所以我要努力支持更加复杂的数据结构，这个结构是随着我的模态而变的。所以缓存的设计并不是一个简单的 key 和 value 的映射，我们希望有一个能支持更加复杂数据结构的设计。

总的来说我们会有一个逻辑上的分布式哈希表，它不是简单的 string，是一种复杂的数据结构。

缓存和存储之间还会有互动，当数据做更改之后，缓存会用异步的方式把它存到存储上，实时操作只会更新到日志里，不会触发持久化存储。

最后我们还有一个容错和恢复的协议。

我们这样的融合数据库，希望能通过一个数据基层，在融合缓存上装配各种计算引擎。因为缓存和计算是物理耦合的，所以性能可以做到和原生一样好。同时我的协议也是完全兼容原生的。

这样我就可以支持多种模态，兼容现有标准，同时满足性能需求，并做到统一的运维管理。

面向未来的工程实践 

谈到工程实践，我们先来看看 AI 时代基础设施环境是什么样子的。我们会有云计算、高速网络、高速存储设备，还有 GPU 这样的新型计算设备提供巨大的算力。

过去十年来，CPU 的性能增长了一倍半，而存储性能增长了 11 倍以上，网络性能有 20 倍的增长。按照这个趋势发展，未来我们的存储或数据基座设备会变成 CPU 瓶颈，因为 IOPS 在快速增长，CPU 的增长却很缓慢。所以如果今天我们什么都不做的话，未来 IOPS 这一块我们会看不到任何性能提升，因为 CPU 没有提升。这也就意味着传统数据库系统的性能无法随着 IO 设备的迭代而增长。

针对这个问题我们做了很多事情，比如说我们所有的执行都是协程，比如说我们都是要异步编程，比如说我们每个核心只有一个线程，最后我们希望能采用一些缓存友好的数据结构。这些都是为了降低 CPU 的负载。

我们公司还做了一个试验性的存储，它是一个 k-v 存储，是多读单写的。我们每个查询做一个协程，提交后切换协程。

然后我们做了简单的测试，就是我们有个 16 核的机器，故意把缓存设成了 4GB，就是为了看数据不是全部缓存在内存里是什么表现。

结果发现在同样的 CPU 下，我们的设计可以做到接近理论上线，比 RocksDB 高出很多。

这也就证明传统的数据库架构会遇到 CPU 的瓶颈，出现这种瓶颈时单纯更换 IO 设备是很难有增长的。

总结和展望 

总的来说，我觉得 AI Agent 时代会带来软件范式的变革，软件范式变革必然会让数据管理产生巨大的变化。总结起来就是我们希望有多模态的支持，有原生 API 的支持，有高性能的支持，我们希望扩缩容更加方便，从管理来讲会更加易用。最后结合工程实践，我们在性能方面也有一些新的思考。希望这次的分享能给大家带来启发，谢谢。

嘉宾介绍 

陈亮，北京晨章数据科技有限公司创始人，首席架构师。前微软亚洲研究员首席研究员。数据库领域顶级专家。微软 SQL Server XML 索引发明人和架构师，微软 Cosmos DB 图数据库架构师。曾在 SIGMOD、VLDB、 ICDE 等国际顶级会议上发表多篇学术论文。

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：陈亮，36氪经授权发布。