...民有、民治、民享的政府... ——亚伯拉罕·林肯，葛底斯堡演说（1863年）

AI的成本正在迅速下降。2023年初，GPT-4级别的能力每百万token大约需要30美元；如今同样的成本已降至1美元以下，部分供应商甚至将价格压至0.10美元以下。从多个基准测试来看，推理价格每年下降9倍到900倍不等，中位数约为50倍。即使是前沿模型，每一代的价格也在大幅下降，开源模型紧随其后。关键在于，尽管“诺贝尔奖得主级天才智能”尚未到来，但足以胜任绝大多数知识工作的智能已经存在，并且价格逐月降低。按照这个速度，我们很快将进入近乎免费的智能时代——这种智能足以满足日常知识工作的需求。

披露声明：本文是由加州大学伯克利分校EECS副教授、EPIC数据实验室联合主任Aditya G. Parameswaran与他的合作者共同撰写的观点文章。它既是行业全景调查，也是个人观点，下文讨论的几个研究方向（包括智能体推测、结构化记忆以及从零开始合成定制数据系统）均基于作者们正在进行的工作。

那么，这个近乎免费的智能新时代对数据系统意味着什么？我们相信，接近零的推理成本将带来三个新的挑战——也是机遇：

面向智能体的数据系统。智能体很快将成为数据系统的主要工作负载——每个终端用户请求都会触发大量智能体集群。考虑到智能体与人类（或代表人类执行任务的应用程序）在特性上的差异，我们应如何为这类智能体用户重新设计数据系统？

由智能体构成的数据系统。随着智能体开始承担大部分知识工作，我们需要一种新的底层基础设施，让数千个智能体能够管理长期运行任务的状态、协调并达成共识、以及处理故障。能够可靠且高效地运行和管理智能体集群的数据系统应该是什么样子？

由智能体构建的数据系统。智能体正迅速变得能够一次性合成整个数据系统——这意味着我们可以为每个新工作负载重构定制化系统。如何验证此类系统符合预期行为是一个挑战。要让智能体构建出我们真正可以信赖的数据系统，需要做哪些工作？

面向智能体、属于智能体、以及由智能体构建的数据系统

接下来，我们将逐一详细讨论以上三个方面，随后探讨数据系统与智能体相互交织的未来——尤其当这三重挑战相互叠加时。

面向智能体的数据系统

智能体查询数据库的行为不同于人类或 BI 工具。它会执行我们所谓的“智能体推测性操作”：一个高容量、异构的工作流，涵盖模式内省、列式探索、部分查询以及完整查询的构造。当多个智能体各自探索假设空间的不同部分时，每个用户请求可能对应数千条独立的 SQL 查询。此时，用户可以下达“高层级”的数据任务，例如根因分析——比如“为什么今年伯克利的咖啡销售额下降了”——或者探索性群体分析——比如“下个季度哪些用户群体最可能流失”——每个任务都涉及潜在的连接、聚合和筛选组合的排列空间。

为更有效地支持智能体推测性操作而重新设计的数据系统

来自这些智能体的请求有多种优化机会。例如，在一个文本转 SQL 基准测试中，当多个智能体各自尝试同一任务时，只有 10-20% 的子计划是互不相同的。也就是说，80-90% 的子查询执行了重复工作。同一实验表明，随着智能体尝试次数的增加，任务成功率显著提升——因此这种冗余实际上是有帮助的。但从数据系统的角度来看，这属于浪费工作。

一个以智能体为先的数据系统可以利用这些特性来帮助智能体更快地取得进展。它可以跨重叠的子计划复用结果，借鉴数十年前关于多查询优化和共享扫描的文献中的思路。或者，数据系统可以尝试满足要求，返回足以让智能体取得进展的近似答案，利用近似查询处理（AQP）文献中的研究成果——或者流式传输最终或中间操作符的结果，以帮助智能体判断查看剩余部分是否有必要或有帮助。

另一个机遇是完全重新思考查询接口：智能体不再一次只发出单个SQL查询，而是可以发出一批查询，每个查询都有自己的近似要求。由于枚举指数级搜索空间（如上述根因分析或分组分析示例）并非智能体推理能力的最佳用途，也许数据系统应该支持更高级的原语，而不是要求智能体显式列出每个SQL查询。一个思路是借鉴DBT风格的Jinja宏，为智能体提供基于循环的原语，以便与数据系统交互。

一支咖啡因加持的智能体大军，随时准备不知疲倦地完成你的数据任务

最后一个机遇是停止将数据系统视为被动的查询执行者；数据系统可以是主动的，因为它们对数据和系统特性有更深入的了解，而智能体可能事先不具备这些了解——它们可以引导智能体走向不同方向，提供相关查询的结果，并给出性能层面的反馈（例如，系统可以先向智能体提供延迟估算，而不是直接执行昂贵的查询）。我们现在能够做到这一点而过去不能的原因是，智能体可以接受任何形式的文本反馈，而不期望严格的SQL查询结果。事实上，数据系统还可以提前为智能体准备物化视图和虚拟视图，作为上下文的一部分提供给智能体，因为这可能比让智能体编写或使用这些视图更便宜或更有效。

智能体的数据系统

之前，我们重点关注智能体如何与数据系统交互。现在，我们来考虑智能体持续工作所需的其他一切：它们在哪里运行、如何记忆、如何相互协调，以及如何处理彼此的故障。这个智能体基础层与驱动原始智能的推理堆栈是分开的。然而，推理堆栈本身正通过 API（例如来自 OpenAI 或 Anthropic）被抽象化，或者对于开源权重模型而言，通过隐藏底层细节的服务框架来实现。到目前为止，智能体基础层一直通过像 Claude Code 和 Codex 这样的工具集，配合各种存储和检索记忆的机制来管理。

首先，在记忆方面，当前的主流观点是：有文件就够了；智能体写入非结构化 Markdown（MD）文件，然后可以通过 grep 或基于嵌入向量的检索来搜索这些文件。事实上，许多人认为，持续学习的解决方案就是让智能体消费大量内容（例如整个代码库、Slack 消息、公司维基等），然后将学习成果写入 MD 文件，再根据需要选择性检索。确实，文件系统、bash 脚本和 MD 文件现在以及将来对智能体都仍然重要。然而，在大规模场景下——当智能体承担绝大部分知识工作时——这种方法将不再有效。

鉴于上下文窗口有限，把所有可能相关的 MD 文件片段都检索出来塞进上下文中，最终会崩溃。即使上下文窗口不断增长，不把所有信息都放入上下文也有延迟方面的好处——而且在许多情况下，例如当知识工作涉及与大型数据库或代码库交互时，将所有相关数据序列化后放入上下文也是不可行的。

数据系统：多智能体集群的基础层

可以使用知识图谱表示，但知识图谱与基于非结构化MD的记忆存在相同局限——它们都缺乏结构化检索能力。真正需要的是能跨多个相关属性（或维度）仅检索与任务相关的记忆。例如，调试不稳定测试的智能体应能仅提取标记了相关模块、语言、框架和故障模式的记忆，而非基于关键词或嵌入向量相似度进行检索。另一个独立问题是实际应检索什么内容；包含错误的原始智能体轨迹用处不大，因为会让智能体重复相同错误——我们期望检索到的记忆具有纠错性。

我们近期探索了一种相关的结构化记忆概念，将记忆按多种属性组织，每个属性可设为 * 表示通用适用，或设为待匹配的取值列表。对数据智能体而言，维度可包含列和表、操作类型，以及最终的自由文本纠错指令。这样我们就可以纳入仅适用于特定操作类型的记忆（例如“执行日期时间操作时，使用财年而非日历年约定”），或仅适用于特定表的记忆（例如“查询产品名称时，优先使用 product_cleaned 列而非 product 列”）。一个未解问题是如何定义应用特定的结构化记忆——也有人称之为记忆的世界模型。我们认为这类似为每个应用定义一套模式（schema），或许智能体本身也能随时间帮助我们定义并优化它。

一种可能的结构化知识存储与检索方式 [来源: 此处]

结构化记忆对进化框架同样有用，可有效管理搜索空间。事实上，存储、组织和挖掘大量单智能体及多智能体轨迹，能帮助未来智能体大幅提升效率——有望通过基于结构化记忆的机制实现有效的递归自我改进。

另一个挑战是，当大量智能体同时执行变换时，如何支持对共享内存的并发编辑以及一般的并发编辑。尽管已有一些在多版本支持和写时复制语义方面的有益尝试，但尚不清楚当数千个智能体同时尝试编辑共享状态时，这些技术是否足够。例如，当智能体根据用户请求尝试各种可能的事务时，绝大多数这些事务的效果都需要回滚——只有那个“正确”的事务的结果得以保留。这里，支持“恰好一次”语义的工作与之相关，基于 CRDT 和操作转换的底层技术也同样相关。对于诸如记忆这类模糊机制的更新，我们或许可以在一致性上做出牺牲，以追求延迟上的完美正确性。虽然智能体可以通过语义推理来补偿或回滚其行为，并最终完成大多数任务，但主要的挑战在于它们在过程中彼此妨碍的程度。需要避免的一个重要故障模式是“活锁”——即无休止的补偿操作阻碍了任何有意义的进展。

除了共享状态之外，在试图支持一支智能体大军时还会出现其他问题，包括当智能体失败时该如何处理、智能体之间应如何相互通信（直接通信还是通过中间共享状态），以及应如何应对掉队智能体。在支持持久化多智能体执行方面已经有一些进展，比如 Temporal，但这类解决方案能否在数千个智能体的大规模场景中应用，仍有待观察。在通信方面，我们需要能让智能体彼此协商的机制。想象四个开发智能体试图就一个共享模式达成共识，它们的目标各不相同但又有重叠。在人类环境中，这需要反复讨论和妥协；而对于智能体集群，我们必须定义出能让它们收敛到一个能反映各自委托人根本目标的设计上的机制。或者，如果所有智能体都需要访问某个有限资源，那么通信也同样是必要的。这究竟是通过集中式协调实现最佳，还是需要采用去中心化方法，仍有待观察。

智能体驱动数据系统

最后，如果智能确实可以近乎免费获得，那么我们就可以利用这种智能从头合成全新的数据系统。实际上，在许多场景中，通用数据系统可能有些大材小用，因为它们必须支持每一种模式、查询和硬件目标。针对给定工作负载，近期包括 Bespoke OLAP 和 GenDB 在内的研究已经表明，可以通过智能体流水线在几分钟到几小时内、以几美元的成本完整地合成一个专用于该工作负载的分析引擎。这些引擎是一次性的：当工作负载发生变化时，可以直接重新生成它们。类似地，我们的研究也表明可以针对工作负载，从头合成自定义的键值存储系统。事实上，像 Kiro 这样的现代 IDE 已将系统开发的规格说明提升为一等公民。

智能体可以从头合成自定义数据系统

然而，主要问题在于，规格说明通常是不完善的，无法覆盖所有边界情况。当下的AI智能体会利用缺失的规格说明，通过奖励篡改的方式来获得较高的性能指标。在我们自研的键值存储工作中，我们发现缓解这一问题的一种方法是引入辅助验证型AI智能体，让它们尝试生成能够捕捉到边界情况被利用的测试用例，从而实质上扩展了规格说明。另一种方法是同时生成一个系统及其正确性证明，我们在这方面已经取得了一些初步成功，但仍需做更多工作来巩固这一方法。此外，究竟什么才是向人类征求系统规格说明的最佳方式——能否采用迭代式、人在回路的做法，而非一次性且不完整的做法——仍有待观察。事实上，即使是手动编写的软件，人类撰写的规格说明也是不完整的，因此可以预见，未来更加对齐的AI智能体在设计决策时将展现出更好的判断力。

一种可能的数据系统合成流程 [来源链接]

这里涉及的其他问题还包括：测试是否从一个成熟的系统（例如Postgres）出发，移除某些组件/功能，能够带来更高的性能或更多的用户信任。另外，是否存在机会让设计变得可组合，由多个经过验证的组件构成，并根据工作负载进行混合搭配？例如，也许工作负载的变化还不足以需要更新存储层，但查询优化器可能需要修改。一个或许更可行的方案是，将AI智能体与证明系统结合起来，针对与形式化证明相关的代码关键部分进行优化，而不是对整个系统都这样做。

最后一个机会是摆脱传统的数据系统架构——那种具有清晰定义接口（例如解析器、查询优化器、存储管理器等）的堆栈，这些接口过去主要由单一人类团队负责管理。取而代之的是，AI 智能体可以找到将这些组件“融合”在一起的新方式，从而可能发现新的优化机会。AI 智能体还可以填补功能上的空白，使现有系统更加功能完备，或达到与其他竞争系统相同的功能水平——或者类似地，根据功能请求或问题（也许由其他 AI 智能体提交！）不断改进开源系统。在这样做的同时，优先保证正确性、长期可维护性和人类可解释性将是一个挑战。

展望更远的未来

在近乎免费智能的时代，数据系统比以往任何时候都更加重要。随着 AI 智能体承担起知识工作的主体，数据系统的工作负载将发生变化，它们运行所需的底层基础设施必须被构建出来，而且它们还将越来越多地参与到自身的设计中。这些转变中的每一个都开辟了一个令人兴奋的新研究议程。

数据系统与 AI 智能体的共同演进

放眼更远的未来，AI 智能体与数据系统之间的界限可能会开始模糊。例如，AI 智能体可以设计它们自身运行所依赖的数据系统，既定义接口，也定义底层的系统组件。接口和内部结构都可以由 AI 智能体以递归自我改进的方式随时间演进。还有一个机会是将数据系统重新构想为所有相关状态的全局真理来源：包括原始数据、记忆和协调状态，从而进一步消弭 AI 智能体查询的数据与 AI 智能体活动产生的数据之间的区别。最后，数据系统本身可能融入 AI 智能体组件，从根本上从被动的计算引擎演变为智能、主动、自我优化的架构。未来会怎样很难预测。我们正迎来一场激动人心的旅程！

致谢

本文所述的观点及正在推进的工作，是EPIC数据实验室、数据系统与基础研究组以及伯克利AI系统社区众多优秀合作者共同研究与深入讨论的成果。感谢各位！

本文的BibTex引用格式如下：

@misc{intelligence-is-free-blog,
  title={Intelligence is Free, Now What? Data Systems for, of, and by Agents},
  author={Aditya G. Parameswaran and Shubham Agarwal and Kerem Akillioglu and Shreya Shankar
          and Sepanta Zeighami and Rishabh Iyer and Matei Zaharia and Alvin Cheung
          and Natacha Crooks and Joseph Gonzalez and Joseph Hellerstein and Ion Stoica},
  howpublished={\url{https://bair.berkeley.edu/blog/2026/07/07/intelligence-is-free-now-what/}},
  year={2026}
}