智能体时代的数据系统：为智能体、由智能体、由智能体构建

……民有、民治、民享的政府……

——亚伯拉罕·林肯，《葛底斯堡演说》（1863）

AI的成本正飞速下降。2023年初，GPT-4级别的模型每百万token成本约为30美元；如今已降至1美元以下，部分服务商甚至将价格压到0.10美元以内。各类基准测试显示，推理价格每年降幅在9倍到900倍之间，中位数约为50倍。即便是前沿模型，每一代的成本也在大幅降低，开源模型紧随其后。关键在于，即便"诺贝尔奖级天才水平"的智能尚未到来，足以胜任绝大多数知识工作的智能已成为现实，且成本逐月走低。照此趋势，我们很快将进入"近乎免费智能"的时代——这种智能足以支撑日常知识工作的全部需求。

披露声明：本文由阿迪蒂亚·G·帕拉梅斯瓦兰主导撰写。他是加州大学伯克利分校EECS（电子工程与计算机科学）系副教授、EPIC数据实验室联合主任，观点由他与合作者共同提出。本文兼具现状调研与前瞻性分析，下文探讨的若干研究方向（包括智能体推测、结构化记忆、从零构建定制化数据系统等）均基于作者团队正在开展的工作。

那么，"近乎免费智能"的新时代，将给数据系统带来什么？我们认为，接近零成本的推理能力将催生三大全新挑战与机遇：

为智能体打造的数据系统。智能体很快会成为数据系统的核心负载——每收到一个终端用户请求，就会启动一群智能体协同工作。由于智能体与人类（或代表人类的应用）的特性存在差异，

我们该如何重构数据系统，以适配这类智能体用户？

基于智能体构建的数据系统。随着智能体承担起大部分知识工作，我们需要一套全新的底层架构，让数千个智能体能够在长期任务中管理状态、协同达成共识，并处理故障问题。

能够可靠、高效地运行与管理智能体集群的数据系统，应该具备怎样的形态？

由智能体构建的数据系统。智能体正快速具备从零构建完整数据系统的能力——这意味着我们可以针对每一项新负载重新搭建定制化系统。但如何验证这类系统符合预期功能，仍是一大挑战。

要让智能体构建出真正可信的数据系统，我们需要做些什么？

为智能体、基于智能体、由智能体构建的数据系统 *

接下来，我们将详细阐述每个方向，随后探讨数据系统与智能体交织共生的未来，尤其是三大挑战相互交汇的场景。

为智能体打造的数据系统

智能体查询数据库的方式，与人类或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列"）。一个开放性问题是定义特定应用的结构化记忆——也就是其他人所说的记忆世界模型。我们认为这类似于为每个应用定义模式，而智能体或许能随时间推移帮助我们定义并完善它。

结构化知识存储与检索的一种可行方案[来源] *

结构化记忆对进化框架体系有效管理搜索空间也十分有用。实际上，存储、结构化处理并挖掘大量单智能体与多智能体操作记录，能让未来的智能体效率大幅提升——甚至可能通过基于结构化记忆的机制实现有效的递归自我改进。

另一大挑战是，当大量智能体执行转换操作时，如何支持共享记忆的并发编辑及一般意义上的并发编辑。尽管已有一些尝试支持多版本控制与写时复制语义，但当数千个智能体同时编辑共享状态时，这类技术是否足够仍不明确。例如，智能体响应用户请求尝试多种潜在事务时，绝大多数事务的影响需要回滚，只有"正确"的事务结果得以保留。此时，恰好一次语义（exactly-once semantics）的相关研究，以及基于CRDT（冲突-free可复制数据类型）与操作转换的底层技术都具有参考价值。对于记忆等模糊机制的更新，我们或许可以为了延迟性能牺牲严格一致性。虽然智能体可以通过语义推理来补偿或回滚操作，最终完成大部分任务，但核心挑战在于它们在过程中相互干扰的程度。一种需要避免的重要故障模式是"活锁"：无休止的补偿操作导致无法取得任何实质性进展。

除了共享状态，支撑大规模智能体集群还面临其他问题，包括智能体故障时的应对机制、智能体间的通信方式（直接通信或通过中间共享状态），以及如何处理滞后智能体。目前已有一些支持持久化多智能体执行的方案，如Temporal，但这类方案能否扩展到数千个智能体的规模仍有待观察。在通信方面，我们需要让智能体能够相互协商的机制。想象四个开发者智能体试图就共享模式达成共识，它们的目标各不相同但存在重叠。在人类场景中，这需要反复讨论与妥协；对于智能体集群，我们必须定义能让它们收敛到反映各自主体核心目标的设计的机制。又如当多个智能体需要访问有限资源时，通信同样必不可少。目前尚不清楚是集中式协调还是去中心化方案更适合这类场景。

由智能体构建的数据系统

最后，既然智能已近乎免费，我们便可利用它从零构建新的数据系统。实际上，在很多场景下，通用数据系统可能性能过剩，因为它们需要支持所有模式、查询与硬件目标。针对特定负载，近期的研究（包括Bespoke OLAP与GenDB）表明，通过智能体流水线可以在数分钟到数小时内，以几美元的成本构建一个完整的、针对特定负载的分析引擎。这类引擎是"一次性"的：当负载变化时，只需重新生成即可。类似地，我们的研究显示，也可以从零构建针对特定负载的定制化键值存储。事实上，现代IDE（如Kiro）已将系统开发的规格说明提升为核心要素。

智能体可从零构建定制化数据系统 *

然而，核心问题在于，规格说明通常并不完善，无法覆盖所有极端场景。当前的智能体往往会利用这些未明确的规格，通过"奖励黑客"行为达到高性能指标。在我们的定制化键值存储研究中，发现一种缓解方法是引入辅助验证智能体，生成测试用例以捕捉针对极端场景的漏洞，本质上是扩展规格说明。另一种方法是同时生成系统及其正确性证明，我们已取得一些初步成果，但仍需更多工作来完善该方案。此外，如何获取高质量的人工撰写规格说明仍有待探索——能否通过迭代式的人机协作方式实现，而非一次性提交不完善的规格？毕竟，即便是人工编写的软件，其规格说明也存在疏漏，因此我们期待未来更对齐人类需求的智能体，在做设计决策时能展现更好的判断力。

数据系统构建流水线的一种可行方案[来源] *

其他问题还包括：从成熟系统（如Postgres）出发，移除部分组件/功能是否能提升性能或增强用户信任？另外，能否让设计具备可组合性，根据负载混合搭配经过验证的组件？例如，当负载变化不足以更新存储层时，可能只需调整查询优化器。一个更可行的思路是，让智能体结合证明系统，针对代码中需要形式化证明的关键部分进行优化，而非对整个系统做全面处理。

最后一个机遇是打破传统数据系统栈的清晰接口划分（如解析器、查询优化器、存储管理器等）——这些接口过去通常由单个团队负责维护。智能体可以探索新的方式将这些组件"融合"，从而发现新的优化机会。它们还能填补现有系统的功能空白，使其更完善，或达到与竞品相当的功能水平；类似地，智能体可以根据功能需求或问题反馈（甚至可能由其他智能体提出）持续优化开源系统。但如何在这个过程中兼顾正确性、长期可维护性与人类可解释性，仍是一大挑战。

展望未来

在近乎免费智能的时代，数据系统的重要性愈发凸显。随着智能体承担起大部分知识工作，数据系统的负载将发生变化，支撑其运行的底层架构需要重新构建，而智能体也将越来越多地参与数据系统的设计。每一项转变都开启了全新且令人兴奋的研究方向。

数据系统与智能体的协同进化 *

展望更远的未来，智能体与数据系统的界限可能会逐渐模糊。例如，智能体可能会自行设计运行所需的数据系统，定义接口及底层组件；接口与内部结构都可由智能体通过递归自我改进不断演化。此外，我们还有机会将数据系统重新定义为所有相关状态的统一可信来源，包括原始数据、记忆与协同状态，进一步消除智能体查询的数据与智能体活动生成的数据之间的界限。最终，数据系统本身可能会融入智能体组件，从被动的计算引擎彻底演化为智能、主动、自我优化的架构。未来充满不确定性，我们即将踏上一段激动人心的旅程！

致谢

本文提出的观点与正在开展的研究，是与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}
}