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

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

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

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

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

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