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

AI 的成本正在迅速下降。GPT-4 级别的能力在 2023 年初大约每百万 token 花费 $30；如今同样的运行成本不到 $1，而且一些提供商正将成本压到 $0.10 以下。纵观各项基准，推理价格每年下降 9 倍到 900 倍，中位数降幅接近 50 倍。即便是前沿模型也在每一代变得大幅便宜，开源模型紧随其后。而关键在于，即便“诺贝尔奖级别的天才级”智能尚未到来，足以胜任绝大多数知识工作的智能今天已经存在，并且每个月都在变得更便宜。按照这个速度，我们很快将进入近乎免费智能的时代——这种智能对于日常知识工作而言绰绰有余。

披露：本文是由Aditya G. Parameswaran——加州大学伯克利分校 EECS 副教授、EPIC Data Lab 联合主任——与其合作者共同主导的一篇观点文章。它既是部分领域综述，也是部分观点阐述，下文讨论的若干研究方向（包括智能体推测、结构化记忆，以及从零合成定制数据系统）均借鉴了作者自身正在进行的工作。

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

面向智能体的数据系统。智能体很快将成为数据系统的主导工作负载——每收到一个终端用户请求，就会有一群智能体被启动来响应。鉴于智能体与人类——或代表人类行事的应用——在特性上存在差异，我们应当如何为这类智能体用户重新设计数据系统？

智能体自身的数据系统。随着智能体开始承担大部分知识工作，就需要一种新的底层基座，让成千上万个智能体能够在长时间运行的任务中管理状态、进行协调并达成共识，以及处理故障。能够可靠且高效地运行和管理智能体集群的数据系统，究竟是什么样子？

由智能体构建的数据系统。智能体正迅速变得有能力一次性合成完整的数据系统——这意味着我们可以为每一种新的工作负载重建定制系统。验证这类系统是否符合预期行为是一项挑战。要让智能体合成出我们真正能够信任的数据系统，需要具备哪些条件？

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

接下来，我们将逐一更详细地讨论这三点，然后探讨数据系统与智能体相互交织的未来，尤其是在这三大挑战交汇之处。

面向智能体的数据系统

智能体查询数据库时的行为既不像人，也不像 BI 工具。它执行的是我们所称的智能体式推测：一股高并发、异构的工作流，涵盖 schema 探查、列式探索、先部分后完整的查询构建。当多个智能体各自探索假设空间的不同部分时，每个用户请求都可能对应 1000 条独立的 SQL 查询。如今，用户可以提出“高层级”的数据任务，例如根因分析——比如“为什么今年伯克利的咖啡销量下降了”——或探索性队列分析——比如“哪些用户群体最可能在下个季度流失”——每一个都涉及由潜在 join、聚合和过滤条件组合而成的组合空间。

重新设计数据系统，以更有效地支持智能体式推测

这些智能体发出的请求有各种优化机会。例如，在一个 text-to-SQL 基准测试中，多个智能体各自尝试每项任务，只有 10-20% 的子计划是彼此不同的。因此，80-90% 的子查询在做重复的工作。同样的实验显示，随着智能体尝试次数增加，任务成功率显著上升——所以这种冗余实际上是有帮助的。但从数据系统的角度看，这是被浪费的工作。

一个以智能体为先的数据系统可以利用这些特性，帮助智能体更快取得进展。它可以复用重叠子计划之间的结果，借鉴已有数十年历史的多查询优化和共享扫描文献中的思路。或者，数据系统可以尝试满意化，返回对智能体推进而言足够好的近似答案，借助the AQP 文献中的研究成果——或者将最终算子或中间算子的结果以流式方式输出，帮助智能体判断是否有必要或有助于查看其余结果。

这里的另一个机会是彻底重新思考查询接口：与其让智能体一次只发出一个 SQL 查询，不如让它们发出一批查询，每个查询都有自己的近似要求。由于枚举指数级搜索空间（如上述根因分析或群组分析示例）并不是对智能体推理能力的良好利用，也许数据系统应当支持更高层的原语，而不是要求智能体逐一显式列出每个 SQL 查询。这里的一个思路是借鉴DBT 风格的 Jinja 宏，为智能体提供基于循环的原语来与数据系统交互。

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

这里最后一个机会是，不要再把数据系统视为查询的被动执行者；数据系统可以是主动的，因为它们对数据和系统特性拥有比智能体先验知识更多的把握——它们可以引导智能体走向不同方向，为相关查询提供结果，还能提供性能层面的反馈（例如，与其执行一个昂贵的查询，系统可以先向智能体提供一个延迟估计）。我们之所以现在能做到这一点而过去不能，是因为智能体可以接受任何形式的文本反馈，而不期待严格的 SQL 查询结果。事实上，数据系统还可以提前为智能体准备好物化视图和虚拟视图，作为上下文的一部分提供给智能体，因为这可能比让智能体自行编写或使用它们更便宜或更有效。

智能体的数据系统

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

首先，在记忆方面，目前的普遍看法是文件就是你所需要的一切；智能体将内容写入非结构化的 markdown（MD）文件，随后可以用 grep 搜索，或通过基于嵌入向量的检索来查找。事实上，许多人认为持续学习的解决方案就是让智能体大量摄取内容（例如整个代码库、slack、公司 wiki 等），然后将其所学写入 MD 文件，再按需选择性地检索。确实，文件系统、bash 脚本和 MD 文件对智能体而言现在重要，将来也依然重要。然而，在规模化之后，当智能体承担绝大多数知识工作时，这种方法将不再有效。

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

数据系统作为多智能体集群的基座

人们可以使用知识图谱表示，但知识图谱由于缺乏结构化搜索，会遭遇与基于非结构化 MD 的记忆相同的局限。人们真正需要的是，能够跨多个感兴趣的属性（或维度）只检索与任务相关的记忆。例如，一个正在调试不稳定测试的智能体，应当能够只拉取带有相关模块、语言、框架和失败模式标签的记忆——而不是基于关键词或嵌入向量相似度来检索。另一个独立的问题是究竟该检索什么；带有错误的原始智能体轨迹并不太有用，因为它们会诱导智能体重复同样的错误——相反，我们希望检索到的记忆是具有纠错性的。

我们最近探索了一个相关的概念——结构化记忆，即我们跨各种属性来组织记忆，每个属性都可以设为*以表示普遍适用，或者设为一个待匹配的值列表。对于数据智能体而言，这些维度可以包括列和表、操作类型，最后还有开放式的自然语言纠错指令。因此，我们可以纳入仅适用于某一类操作的记忆（例如“在执行日期时间操作时，使用财年而非日历年惯例”），或者仅适用于某张表的记忆（例如“在按产品名称查询时，优先使用 product_cleaned 列而非 product 列”）。一个悬而未决的问题是定义特定应用的结构化记忆——或者其他人所称的记忆的世界模型。我们认为这类似于为每个应用定义一套 schema——也许智能体本身就能帮助我们随时间推移来定义并完善它。

一种存储和检索结构化知识的可能方式 [从此处开始]

结构化记忆对于演化式 框架有效管理搜索空间也将大有裨益。事实上，存储、结构化并挖掘大量单智能体和多智能体轨迹，可以帮助未来的智能体变得高效得多——有可能通过基于结构化记忆的机制，实现有效的递归式自我改进。

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

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

由智能体构建的数据系统

最后，如果智能实际上是免费的，那么我们就可以利用这种智能从零开始合成新的数据系统。事实上，在许多场景中，通用数据系统可能有些大材小用，因为它们必须支持每一种模式、查询和硬件目标。给定一个工作负载，近期的工作，包括 Bespoke OLAP 和 GenDB，已经表明人们可以使用智能体流水线来合成一个完整的、针对特定工作负载的分析引擎——只需几分钟到几小时，成本仅为几美元。这些引擎是一次性的：当工作负载发生变化时，只需重新生成它们即可。类似地，我们的工作已经表明，人们可以从零开始合成定制的 键值存储，并针对特定工作负载进行优化。事实上，现代 IDE，例如 Kiro，已将系统开发的规格说明提升为一等公民。

智能体可以从零开始合成定制数据系统

然而，主要问题在于规范通常并不完美，无法覆盖所有边界情况。当今的智能体会利用缺失的规范，通过奖励黑客手段来刷出高性能指标。在我们自定义键值存储的工作中，我们发现一种缓解方法是设置辅助验证智能体，尝试生成能够捕获边界情况被利用的测试用例，本质上是在扩展规范。还有一种方法是同时生成系统及其正确性证明，我们在这方面已经取得了一些早期成功，但还需要做更多工作来夯实这一方法。此外，如何最好地征集人类编写的系统规范仍有待探索——能否以迭代式、人在环路中的方式进行，而非一次性、不完整的方式。事实上，即便是人工编写的软件，人类编写的规范也是不完整的，因此可以预期，未来对齐程度更高的智能体在做出设计决策时将越来越多地运用更好的判断力。

一种可能的数据系统合成流水线 [从此处开始]

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

这里的最后一个机会是摆脱传统的、具有明确定义接口的数据系统栈（例如解析器、查询优化器、存储管理器……）——这些接口在很大程度上曾各自是单个人类团队管理的专属领域。取而代之的是，智能体可以找到新的方式将这些组件“融合”在一起，或许因此发现新的优化机会。

智能体还可以填补功能上的缺失，使现有系统功能更加完整，或与其他竞争系统达到功能对等——或者类似地，针对功能请求或问题（也许是由其他智能体提交的！）持续改进开源系统。以优先考虑正确性、长期维护和人类可解释性的方式做到这一点，将是一项挑战。

进一步展望

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

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

放眼更远的未来，智能体与数据系统之间的界限很可能会开始模糊。例如，智能体可能会设计它们自身所运行的数据系统，既定义接口，也定义底层的系统组件。接口和内部结构都可以由智能体以递归自我改进的形式随时间演化。此外，还有一个机会将数据系统重新构想为全部相关状态的统一真相来源：包括原始数据、记忆和协调状态，从而进一步消除智能体所查询的数据与智能体活动所产生的数据之间的区别。

最后，数据系统本身也可能融入智能体组件，从根本上从被动的计算引擎演变为智能的、主动的、自我优化的架构。很难预测未来会怎样。我们将踏上一段狂野之旅！

致谢

本文所述的观点与正在进行的工作，是与 EPIC Data Lab、Data Systems & Foundations 小组以及更广泛的 Berkeley AI-Systems 社区的出色合作者们共同研究并经过多次讨论的成果。感谢各位！

本文的 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}
}