Berkeley AI Research 讨论近乎免费智能时代的 Agent 数据系统

……民有、民治、民享的政府……
    — Abraham Lincoln，Gettysburg Address (1863)

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

披露：本文是由 Aditya G. Parameswaran 主导的一篇观点文章——他是 UC Berkeley EECS 副教授、EPIC Data Lab 联合主任——并与其合作者共同撰写。本文一部分是领域综述，一部分是观点阐述；下文讨论的若干研究方向（包括 agentic speculation、structured memory，以及从零开始合成定制数据系统）借鉴了作者们自己正在进行的工作。

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

面向 Agent 的数据系统。 Agent 很快将成为数据系统的主导工作负载——每当终端用户发起请求时，都会启动成群的 Agent。鉴于 Agent 与人类——或代表人类行动的应用程序——在特性上的差异，我们应如何为这类 Agentic 用户重新设计数据系统？

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

由 Agent 构建的数据系统。 Agent 正在迅速具备一次性合成整个数据系统的能力——这意味着我们可以为每一种新的工作负载重建定制系统。验证这类系统是否符合预期行为是一项挑战。要让 Agent 合成出我们真正可以信任的数据系统，需要什么？

面向 Agent、由 Agent 组成、由 Agent 构建的数据系统

接下来，我们将更详细地讨论每一项挑战，随后讨论数据系统与 Agent 交织在一起的未来，尤其是在这三项挑战相互交汇之时。

查询数据库的智能体并不像人或 BI 工具那样行动。它会执行我们所谓的 智能体式推测：一种高容量、异构的工作流，涵盖模式内省、列式探索、部分查询制定以及完整查询制定。多个智能体各自探索假设空间的一部分，每个用户请求都可能相当于 1000 多条单独的 SQL 查询。现在，用户可以发出“高层级”的数据任务，例如根因分析——例如，“为什么 Berkeley 的咖啡销量今年下降了”——或探索性队列分析——例如，“哪些用户群体最有可能在下个季度流失”——每项任务都涉及潜在连接、聚合和过滤器组合的组合空间。

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

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

智能体优先的数据系统可以利用这些特性，帮助智能体更快取得进展。它可以在重叠的子计划之间复用结果，借鉴数十年前关于多查询优化和共享扫描的文献中的思想。或者，数据系统可以尝试满足够用，返回足以让智能体继续推进的近似答案，利用来自相关AQP文献的工作——或者流式传输最终或中间算子的结果，帮助智能体判断是否有必要或有帮助看到其余结果。

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

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

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

智能体的数据系统

此前，我们重点关注了智能体如何与数据系统交互。现在，我们来考虑智能体要持续工作所需的其他一切：它们栖身何处、如何记忆、如何彼此协同，以及如何处理彼此的故障。这个智能体基底独立于为原始智能提供动力的推理栈。不过，推理栈本身正通过 API（例如来自 OpenAI 或 Anthropic 的 API）被抽象出来；或者，对于开放权重模型，则通过隐藏低层细节的服务框架来实现抽象。到目前为止，智能体基底一直通过 Claude Code 和 Codex 这样的运行框架来管理，并配合各种机制来存储和检索记忆。

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

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

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

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

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

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

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

另一个挑战是，当有许多智能体在执行转换时，如何支持对共享记忆的并发编辑，以及更一般意义上的并发编辑。尽管已经有一些有益的尝试来支持多版本控制和写时复制语义，但当成千上万个智能体试图同时编辑共享状态时，这些技术是否足够仍不清楚。例如，当智能体为响应用户请求而尝试各种可能的事务时，绝大多数事务的影响都需要被回滚——只有那个“正确”事务的结果得以保留。关于支持 exactly-once 语义的工作与此相关，基于 CRDT 和操作转换的底层技术也同样相关。对于对记忆这类模糊机制的更新，为了降低延迟，我们也许可以在一致性上作出牺牲，以换取完全正确性。虽然智能体可以围绕语义进行推理，以补偿或回滚自身行为，并最终完成大多数任务，但主要挑战在于它们在这一过程中相互干扰的程度。需要避免的一种重要失败模式是一种“活锁”：持续不断的补偿性动作阻止了任何有意义的进展。

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

由代理构建的数据系统

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

代理可以从零开始合成定制数据系统

然而，主要问题在于，规范通常并不完善，也无法覆盖所有边界情况。如今的代理会利用缺失的规范，通过奖励黑客手段获得较高的性能指标。在我们的定制键值存储工作中，我们发现缓解这一问题的一种方法是让辅助验证代理尝试生成测试用例，以捕捉对边界情况的利用，本质上是在扩展规范。另一种方法是同时生成一个系统及其正确性证明；我们在这方面已经取得了一些早期成功，但还需要做更多工作来巩固这种方法。此外，如何最好地征求人类为系统编写的规范仍有待观察——这是否可以通过迭代式、人类参与的方式完成，而不是一次性、不完整地完成。事实上，即便是人工编写的软件，人类编写的规范也并不完整，因此可以预期，未来更加对齐的代理在做设计决策时将越来越能运用更好的判断。

一种可能的数据系统合成流水线 [来自这里]

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

这里的最后一个机会，是摆脱传统数据系统栈中那些界限清晰的接口（例如解析器、查询优化器、存储管理器，……）——它们过去基本上都由单个人类团队负责管理。相反，agents 可以找到新的方式将这些组件“融合”在一起，并可能由此发现新的优化机会。agents 还可以填补功能上的缺口，使现有系统在功能上更加完整，或达到与其他竞争系统的功能对等——或者类似地，响应功能请求或问题持续改进开源系统（这些请求或问题也许由其他 agents 提交！）以一种优先考虑正确性、长期维护和人类可解释性的方式做到这一点，将是一个挑战。

展望更远的未来

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

数据系统与 Agents 的共同演化

再往前看，agents 与数据系统之间的边界很可能会开始变得模糊。例如，agents 可能会设计它们自身运行其上的数据系统，同时定义接口以及底层的系统组件。接口和内部结构都可以由 agents 以递归式自我改进的形式随时间演化。还有一个机会，是将数据系统重新思考为相关状态整体的全局真相来源：包括原始数据、记忆和协调状态，从而进一步抹去 agents 所查询的数据与作为 agentic 活动结果而生成的数据之间的区别。最后，数据系统本身也可能纳入 agentic 组件，从根本上从被动计算引擎演进为智能的、主动的、自优化的架构。很难预测未来会怎样。我们将迎来一段疯狂的旅程！

致谢

本文所描述的观点和正在进行的工作，是与 EPIC Data Lab、Data Systems & Foundations group 以及更广泛的 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}
}