AI Agent 改变了软件。这是新的软件模式。以前的软件像工具，帮助人做事情。比如，SaaS 软件会建一个工作流程，人输入信息，软件帮你完成。软件在流程里收集数据。这些数据是软件产生的。它们格式通常是结构化的。开发人员决定数据长什么样。数据量也慢慢增加，可以控制。
但是 AI Agent 就不一样了。软件变得很聪明，它自己就能完成复杂任务。它还能自己学习和改进。所以，它不是工具了，它自己就是一个智能服务。
在 Agent 世界里，我们不叫“工作流”，我们叫“Agent 编排”。我们会把很多 Agent 组合起来。核心当然是大模型，它像个大脑。它驱动着不同的 Agent 去工作。
这里有个大不同。我们开发 Agent 应用，一开始就需要数据。这些数据是 Agent 的“燃料”。就像汽车启动需要汽油一样。大模型很聪明，但它知道的是通用知识。如果我想让它完成特定领域任务，它需要很多专业数据。这些数据来自知识库，也来自外部的结构化数据。
而且，这些数据常常来自外部。我们可能控制不了它的格式和规模。用户和 AI Agent 互动，也会产生更多数据。这些数据会反过来丰富知识库。这样，Agent 就会越来越聪明。最终，用户得到的是一个完整的智能服务。
具体看一个金融场景
我们举个例子，一个金融 App。它里面有 4 个 Agent。
- 一个 Agent 负责市场分析。
- 一个 Agent 关注风险控制。
这些 Agent 需要很多不同数据库。
- 用户信息。这些数据通常是表格形式。它们存在关系型数据库里。
- 财报数据。这是半结构化数据。里面有些信息是结构化的，可以提取出来。
- 外部知识库。如果知识库很大，有很多日志。它们可能放在 MongoDB 这样的数据库里。
- 文本搜索。大模型时代，文本搜索很重要。我们会用到向量数据库（比如 Pinecone）和全文搜索引擎（比如 Elastic）。它们通常一起用，可能还要配一个 Ranker 来优化结果。
- 知识图谱。有些知识库用图的形式来表示。
- 对话记忆。用户反馈很多，Agent 需要实时对话。延时要求非常短。所以，需要基于内存的数据库。
所以你看，开发 Agent 应用，第一天可能就得用好几种数据库。而且外部数据规模你无法控制。数据量很大时，你就要选一个能扩展的数据库。有些业务要和用户实时互动，延时要求很高。这时候，你必须用内存数据库。
Agent 的工作流程
现在的 Agent 工作流程是这样的。
- 用户登录一个网络服务。
- 系统访问关系型数据库，获取用户信息。
- Agent 会进入一个循环（Agent Loop）。因为用户交流不是一轮就结束。
- Agent 可能会调大模型，获取信息。
- 它还会调用外部服务，比如网络搜索，或者外部计算服务。
- 它会用 RAG（检索增强生成）技术，从全文知识库里查找信息。
Agent 还有短期记忆和长期记忆。它们对延时要求不同。
- 短期记忆：需要超快响应。放在内存数据库里。
- 长期记忆：数据量大。放在持久化数据库里。
这样，不同的数据都有对应的数据库。而且，应用在互动中，会不断生成新数据。
简单说一下，互联网时代和 Agent 时代，数据管理有很多区别。
- 互联网时代：数据是应用自己生成的。我们可以控制。
- AI 时代：外部数据进来很多。我们常常控制不了。数据规模可能很大。
- AI 时代：有很多非结构化数据。所以，现在几乎所有数据库都在加向量能力。搜索变得非常重要。
- Agent 之间会互动，和外部也会互动。它们需要记录内容。数据量会快速增加。
AI 原生应用面临的数据挑战
AI 时代，数据管理确实很难。系统会遇到很多挑战。
- 多模态数据。 我们希望数据库能处理多种数据。一个应用可能要同时处理好几种数据。
- 数据同步和一致性。 有很多数据库，它们之间的数据怎么保持同步？怎么保证一致？比如，短期记忆的数据最终要变成长期记忆。应用输出的内容也要反馈到知识库里。这形成了一个数据循环。
- 性能和规模。 不同数据库，对性能和规模的要求不一样。有的需要毫秒级延时，有的则没那么快。
- 多系统运维。 现在开发一个 AI 应用很快。三个人六个月可能就能搭好一个 App。但是运维成本很高。因为数据是核心价值，它会不断积累。一个小团队要管理很多种数据库，很麻烦。
总的来说，AI Agent 应用从一开始，就要面对传统大公司才有的数据难题。而且，数据会快速迭代，给数据库系统带来更大压力。
多模态数据基座
面对这些难题，我们思考怎么办。我们需要一个统一的数据架构。它能解决这些问题。我们想做的是一个 多模态数据基座。
我们设计这个基座有三个目标。
- 支持多种数据模态。 一个 AI 应用会遇到多模态数据问题。
- API 要原生兼容。 比如，Json API 应该和 Mongo 兼容。SQL API 应该和 MySQL 兼容。这很重要。开发者希望系统可以扩展，可以迁移。他们有时想在云上部署，有时想在私有环境部署。私有部署可能有很多限制。使用标准 API 很关键。如果我自己定一套 API，开发者来用我的系统，未来会有很大风险。
- 性能。 性能和成本是长期考虑的关键。如果系统比别人慢，就很难说服用户。
- 动态伸缩，自动管理。 这和现在的云原生趋势一致。系统能自动扩容缩容，方便管理。
- 跨模态访问和一致性。 不同模态的数据要能相互同步，访问也要一致。我不希望有很多数据库各自为政。我们要消除数据库之间的壁垒。这不是说用一个中间件把所有数据库连起来。那样并没有降低管理成本。很多应用里，数据会从长期记忆到短期记忆，从结果到知识库。这些都是跨模态访问，要求高效。
数据库架构演化史
在讲多模态基座前，我们先简单回顾下数据库架构。
早期，数据库就是一台机器。后来，数据库分成了 OLAP（分析）和 OLTP（交易）。
云时代，以前 OLAP 数据库的“无共享架构”不好用了。于是有了“存算分离”。
OLTP 一开始也是无共享架构。但它的演化更复杂。因为 OLAP 不太关心内存缓存。它要扫描大量数据，内存放不下。它最终要读磁盘。但是在线的 OLTP 不一样。它需要毫秒级延时。内存缓存非常重要。它是保证延时最关键的。无共享架构下，计算和缓存不在一起。每次访问都要走网络。Agent 时代，这样的延时很难保证。所以，业界提出了 Aurora 架构。它把缓存提上去，让计算和缓存在一起。下面是共享存储。这叫“共享存储架构”。它能保证延时。
我们的思路是这样：计算和存储之间，有一个 数据基层。在这个基层里，缓存 最重要。它是保证在线数据库延时最关键的部分。所有在线数据模态，比如向量搜索、全文搜索、图搜索，都需要缓存。不在缓存里的数据，延时很难保证。
我们这个数据基座，上面是计算层，下面是存储层。计算引擎可以更换，可以兼容很多开源组件。中间是数据基层。它抽象了在线数据库最核心的功能，最重要的就是缓存。我们希望能用 统一的缓存格式。它能消除不同数据模态的壁垒。这样，数据统一访问或跨模态访问时，就能高效。
而且，我们认为缓存和计算是 逻辑解耦，物理耦合 的。物理耦合，就是缓存尽量放在机器本地内存。减少跨网络读取。逻辑解耦，是想用它消除不同模态的差异。通过缓存实现和原生系统一样的性能。
缓存不是简单的哈希表。因为我们要支持不同模态。所以，缓存要支持 更复杂的数据结构。这个结构会随着模态变化。
总的来说，我们有一个 逻辑上的分布式哈希表。它的值不是简单的字符串，是一种复杂的数据结构。
缓存和存储之间会互动。数据修改后，缓存会 异步地 存到存储上。实时操作只会更新到日志里。不会立即写入持久化存储。
我们还有一个 容错和恢复协议。
我们的融合数据库，通过一个数据基层，在融合缓存上装配各种计算引擎。缓存和计算是物理耦合的。所以性能可以做到和原生系统一样好。而且我们的协议完全兼容原生。
这样，我们就能支持多种模态，兼容现有标准。同时满足性能需求。而且做到统一运维管理。
面向未来的工程实践
我们来看看 AI 时代的基础设施。现在有云计算，高速网络，高速存储。还有 GPU 这种新型计算设备，提供很大的算力。
过去十年，CPU 性能增长了一倍半。但是存储性能增长了 11 倍。网络性能增长了 20 倍。按照这个趋势，未来我们的存储或数据基座设备会遇到 CPU 瓶颈。IOPS 增长很快，CPU 增长却很慢。如果我们什么都不做，未来 IOPS 性能就不会提升。因为 CPU 跟不上。这意味着传统数据库系统，性能无法随 IO 设备升级而提升。
针对这个问题，我们做了很多事。
- 我们所有的执行都用 协程。
- 我们都做 异步编程。
- 我们每个核心只有一个线程。
- 我们用缓存友好的数据结构。
这些都是为了 降低 CPU 负载。
我们公司还做了一个试验性的存储。它是一个 k-v 存储，支持 多读单写。我们把每个查询都做成协程。提交后就切换协程。
我们做了一个测试。用一台 16 核机器。故意把缓存设成 4GB。这样看数据没完全缓存在内存时，系统表现如何。
结果发现，在同样的 CPU 下，我们的设计接近理论上限。比 RocksDB 高很多。
这证明了传统数据库架构会遇到 CPU 瓶颈。出现瓶颈时，单纯更换 IO 设备，很难提升性能。
总结和展望
AI Agent 时代会带来软件模式的巨大改变。软件模式变了，数据管理也会跟着变。
总结一下：
- 我们希望能支持 多模态。
- 支持 原生 API。
- 支持 高性能。
- 希望 扩缩容更方便。
- 从管理上讲，希望 更易用。
结合工程实践，我们在性能方面也有了新的思考。希望这些分享能给大家带来启发。
