智能免费了，然后呢？——数据系统的“为代理”、“由代理”与“代理自建”

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

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

披露：本文是由Aditya G. Parameswaran——加州大学伯克利分校 EECS 副教授、EPIC 数据实验室联合主任——与他的合作者共同主导的一篇观点文章。它既是领域概览，也是前瞻展望，下文讨论的多个研究方向（包括代理推测、结构化记忆、从零合成定制数据系统等）均来自作者们正在进行中的工作。

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

为代理而生的数据系统（Data Systems For Agents）。 代理将很快成为数据系统上的主要工作负载——针对每个最终用户请求，都会有成群的代理被快速创建。考虑到代理与人类（或代表人类操作的应用程序）在特性上的差异，我们应该如何为这类代理用户重新设计数据系统？

由代理组成的数据系统（Data Systems Of Agents）。 当代理开始承担大部分知识工作时，需要一个新的基础设施，让数千个代理在长期运行的任务中管理状态、相互协调并达成共识，同时应对故障。能够可靠、高效地运行和管理代理群的数据系统应该是什么样子？

由代理构建的数据系统（Data Systems By Agents）。 代理正迅速具备一次性合成完整数据系统的能力——这意味着我们可以为每个新工作负载重新构建定制系统。验证此类系统是否符合预期行为是一个挑战。如何才能让代理合成我们可以真正信赖的数据系统？

数据系统的为代理、由代理、代理自建

接下来，我们将逐一深入讨论，然后探讨数据系统与代理交织的未来，尤其是这三个挑战相互交叠之时。

为代理而生的数据系统

查询数据库的代理，其行为不同于人类或 BI 工具。它会执行我们所谓的代理推测：一种高容量、异质的工作流，涵盖模式内省、列式探索、部分查询再到完整查询的构建。由于多个代理各自探索假设空间的不同部分，每个用户请求可能产生数千条独立的 SQL 查询。如今，用户可以提出“高层次”数据任务，例如根本原因分析——“为什么伯克利今年的咖啡销售额下降了”——或探索性队列分析——“下一季度哪些用户群体最有可能流失”——每个任务都涉及连接、聚合和过滤组合的指数级空间。

重新设计数据系统以更有效地支持代理推测

这些代理发出的请求有多种优化机会。例如，在一个多个代理同时尝试相同任务的 Text-to-SQL 基准测试中，只有 10-20% 的子计划是彼此不同的。这意味着 80-90% 的子查询都在做重复工作。同一实验表明，任务成功率会随着代理尝试次数的增加而显著提高——因此这种冗余实际上是有益的。但从数据系统的角度来看，这是被浪费的算力。

一个以代理为先的数据系统可以利用这些特性，帮助代理更快地取得进展。它可以跨重叠子计划重用结果，借鉴数十年前关于多查询优化和共享扫描的文献思路。或者，数据系统可以尝试_满意即可_，返回足以让代理做出进展的近似答案，利用来自近似查询处理（AQP）文献的思想——或者将最终或中间算子的结果流式输出，帮助代理决定是否需要看到剩余部分。

此处的另一个机会是彻底重新考虑查询接口：代理不必一次只发一条 SQL 查询，而是可以发出一批查询，每个查询带有各自的近似要求。既然枚举指数级搜索空间（如上述根本原因分析或队列分析示例）并非对代理推理能力的有效使用，也许数据系统应该支持更高层次的原语，而不是要求代理显式地列出每条 SQL 查询。一个思路是借鉴 DBT 风格的 Jinja 宏，为代理提供基于循环的原语与数据系统交互。

一群干劲十足的代理大军，准备不知疲倦地完成你的数据任务

最后一个机会是，不要将数据系统视为被动的查询执行器；数据系统可以是主动的，因为它们对数据和系统特性的理解比代理更深，而代理可能缺乏这些先验知识——它们可以引导代理走向不同方向，提供相关查询的结果，并给出性能层面的反馈（例如，系统可以在执行昂贵查询之前，先给代理一个延迟估算）。我们如今能够做到这一点，是因为代理可以接受任何形式的文本反馈，而不期望严格的 SQL 查询结果。实际上，数据系统还可以提前为代理准备物化视图和虚拟视图，作为上下文的一部分提供给代理，这可能比让代理自行编写或使用这些视图更便宜、更有效。

由代理组成的数据系统

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

首先，在记忆方面，当前的流行观点是文件即所需的一切；代理将内容写入非结构化的 Markdown (MD) 文件，然后可以通过 grep 或基于嵌入的检索来搜索。事实上，许多人认为，持续学习的解决方案就是让代理大量消费（例如整个代码库、Slack、公司 Wiki 等），然后将它们学到的内容写入 MD 文件，再按需选择性检索。的确，文件系统、Bash 脚本和 MD 文件现在且将来仍然对代理很重要。然而，当规模扩大，代理开始承担绝大多数知识工作时，这种方式将不再有效。

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

作为多代理群基础设施的数据系统

可以使用知识图谱表示方法，但知识图谱因其缺乏结构化搜索，会受到与非结构化 MD 记忆相同的限制。我们需要的是能够只检索与任务相关、跨越多个相关属性（或维度）的记忆。例如，一个调试不稳定测试的代理应该能够只拉取标记了相关模块、语言、框架和故障模式的记忆——而不是基于关键词或嵌入相似度来检索。另一个问题是到底应该检索什么；带有错误的原始代理轨迹不太有用，因为它们会诱导代理重复相同的错误——相反，我们想要检索的记忆应该是具有纠正性的。

我们最近探索了一种相关的结构化记忆概念，将记忆按不同属性组织起来，每个属性可以设置为 * 表示普遍适用，或者设为一个待匹配的值列表。对于数据代理，维度可以包括列和表、操作类型，以及最后的开放式自然语言纠正指令。这样，我们就可以包含只适用于特定操作类型的记忆（例如“执行日期-时间操作时，请使用财年而非日历年惯例”），或特定表的记忆（例如“查询产品名称时，优先使用 product_cleaned 列而非 product 列”）。一个开放问题是定义_针对应用的特定结构化记忆_——或其他人所说的记忆的世界模型。我们认为这类似于为每个应用定义一个模式——也许代理本身可以帮助我们随着时间推移来定义和优化它。

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

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

另一个挑战是，当有许多代理执行转换任务时，如何支持对共享记忆以及一般意义上的共享状态进行并发编辑。虽然已经有一些支持多版本化和写时复制语义的有益尝试，但尚不清楚当数千个代理同时尝试编辑共享状态时，这些技术是否足够。例如，当代理响应一个用户请求尝试各种潜在事务时，绝大多数事务的效果需要被回滚——只有那个“正确”事务的结果会被持久化。支持恰好一次语义的相关工作与此相关，基于 CRDT 和操作转换的底层技术也是如此。对于记忆等模糊机制的更新，为了延迟，我们或许可以在一致性上做出妥协，换取完美的正确性。虽然代理可以通过对语义进行推理来补偿或回滚它们的动作，从而最终完成大多数任务，但主要的挑战在于它们在此过程中彼此干扰的程度。需要避免一种重要的故障模式，即一种“活锁”，无休止的补偿动作导致无法取得任何有意义的进展。

除了共享状态，当试图支持一支代理大军时，还出现了其他问题，包括如何

... government of the people, by the people, for the people ...
— Abraham Lincoln, Gettysburg Address (1863)

The cost of AI is dropping rapidly. GPT-4-class capabilities cost roughly $30 per million tokens in early 2023; today the same runs under $1, and some providers are pushing costs below $0.10. Across benchmarks, inference prices have fallen between 9x and 900x per year, with a median decline near 50x. Even frontier models are getting dramatically cheaper each generation, with open-source models following closely behind. And crucially, even if “Nobel-Prize-winning genius-level” intelligence isn’t here yet, the intelligence that suffices for the vast majority of knowledge work is here today, and getting cheaper by the month. At this rate, we are soon entering the era of virtually free intelligence —the kind that is more than enough for everyday knowledge work.

Disclosure: This post is a perspective led by Aditya G. Parameswaran—an Associate Professor of EECS and co-director of the EPIC Data Lab at UC Berkeley—together with his collaborators. It is part landscape survey and part perspective, and several of the research directions discussed below (including agentic speculation, structured memory, and synthesizing custom data systems from scratch) draw on the authors' own ongoing work.

So, what does this new era of near-free intelligence mean for data systems? We believe three new challenges—and opportunities—stem from near-zero inference costs:

Data Systems For Agents. Agents will soon become the dominant workload for data systems—with swarms of agents spun up in response to each end-user request. Given differences in characteristics between agents and humans—or applications acting on their behalf— how should we redesign data systems for such agentic users?

Data Systems Of Agents. As agents start taking on the bulk of knowledge work, a new substrate is needed for thousands of agents to manage state over long-running tasks, coordinate and reach consensus, and deal with failures. What do data systems that reliably and efficiently run and manage agent swarms look like?

Data Systems By Agents. Agents are rapidly becoming capable of synthesizing entire data systems in one go—meaning we can rebuild custom systems for each new workload. Verifying that such systems match intended behavior is a challenge. What does it take to let agents synthesize data systems we can actually trust?

Data Systems For, Of, and By Agents

Next, we will discuss each in more detail, followed by discussing the intertwined future of data systems and agents, especially as the three challenges intersect.

Data Systems For Agents

An agent querying a database doesn’t behave like a person or a BI tool. It performs what we call agentic speculation: a high-volume, heterogeneous stream of work spanning schema introspection, columnar exploration, partial and then full query formulation. With multiple agents each exploring portions of the hypothesis space, each user request could amount to 1000s of individual SQL queries. Now, users can issue ‘high-level’ data tasks, e.g., root-cause analysis—e.g., ‘why did coffee sales in Berkeley drop this year’—or exploratory cohort analysis—e.g., ‘which user segments are most likely to churn next quarter’—each involving a combinatorial space of potential joins, aggregations, and filter combinations.

Data Systems Redesigned to More Effectively Support Agentic Speculation

The requests from these agents have various opportunities for optimization. For instance, on a text-to-SQL benchmark with multiple agents attempting each task, only 10-20% of the sub-plans are distinct. Thus, 80-90% of sub-queries perform duplicate work. The same experiments show task success rates significantly increasing with more agentic attempts—so the redundancy is actually helpful. But from the data system perspective it’s wasted work.

An agent-first data system can exploit such properties to help agents make progress faster. It can reuse results across overlapping sub-plans, drawing on ideas from decades-old literature on multi-query optimization and shared scans. Or the data system can try to satisfice , returning approximate answers that are good enough for agents to make progress, leveraging work from the AQP literature—or streaming the results of the final or intermediate operators to help agents decide if seeing the rest is necessary or helpful.

Another opportunity here is to rethink the query interface entirely: instead of agents issuing a single SQL query at a time, they could instead issue a batch of queries, each with its own approximation requirements. Since enumerating an exponential search space (as in the root cause or cohort analysis examples above) isn’t a good use of agentic reasoning ability, perhaps data systems should support higher-level primitives rather than requiring agents to list each SQL query explicitly. One idea here is to draw on DBT-style Jinja macros to provide looping-based primitives for agents to interact with data systems.

A Caffeinated Army of Agents Ready to Tirelessly Complete Your Data Tasks

A final opportunity here is to stop thinking of data systems as passive executors of queries; data systems could be proactive, as they possess more grounding in data and system characteristics that agents may lack a priori—they could steer agents in different directions, provide results for related queries, and also provide performance-level feedback (e.g., instead of executing an expensive query, the system could first provide the agent a latency estimate). The reason we can do this now as opposed to the past is that an agent can accept any form of textual feedback and isn’t expecting a strict SQL query result. In fact, the data system could also prepare both materialized and virtual views for an agent in advance, provided to the agent as part of context, as this may be cheaper or more effective than having an agent author or use them.

Data Systems Of Agents

Previously, we focused on how agents interact with data systems. Now, we consider everything else agents need to keep working: where they live, how they remember, how they coordinate with each other, and how they deal with failures of each other. This agentic substrate is separate from the inference stack powering raw intelligence. However, the inference stack itself is being abstracted away through APIs (e.g., from OpenAI or Anthropic), or, for open-weight models, through serving frameworks that hide low-level details. So far, the agentic substrate has been managed through harnesses like Claude Code and Codex, coupled with various mechanisms to store and retrieve memory.

First, on the memory front, the current wisdom is that files are all you need; agents write to unstructured markdown (MD) files, which can then be searched using grep, or via embedding-based retrieval. In fact, many argue that the solution to continual learning is having agents consume a lot (e.g., an entire codebase, slack, company wikis, …) and then write their learnings into MD files, which are then retrieved selectively on demand. Indeed, file systems, bash scripting, and MD files are and will still be important for agents. However, at scale, when agents are doing the vast majority of knowledge work, this approach will no longer be effective.

Given limited context windows, retrieving all MD file fragments that may be relevant and stuffing it into the context will break down at some point. Even if context windows continue to grow, there are latency benefits to not put all information into context — and in many cases, e.g., when knowledge work involves interacting with large databases or code bases, it will be infeasible to serialize all relevant data into context.

Data Systems As A Substrate for Multi-Agent Swarms

One could use a knowledge graph representation, but knowledge graphs suffer from the same limitations as unstructured MD-based memory due to their lack of structured search. What one needs is to be able to retrieve only memory that is pertinent to the task, across multiple attributes (or facets) of interest. For example, an agent debugging a flaky test should be able to pull only the memories tagged with the relevant module, language, framework, and failure mode—rather retrieving based on keywords or embedding similarity. A separate issue is what to actually retrieve; raw agent traces with mistakes are not very useful as they will induce agents to repeat the same mistake—instead, we want the retrieved memory to be corrective.

We recently explored a related notion of structured memory, where we organize memory across various attributes, each of which could be set as * to indicate universal applicability, or set as a list of values to be matched. For a data agent, the dimensions could include the columns and tables, type of operation, and finally, open-ended natural-language corrective instructions. So, we could include memory that only applies to a given type of operation (e.g., ‘when performing date-time operations, use fiscal year as opposed to calendar year conventions’), or a given table (e.g., ‘column product_cleaned is preferred over column product when querying on product name’). One open question is defining an application-specific structured memory —or what others have called world models for memory. We believe this is akin to defining a schema for each application—and perhaps agents themselves can help us define and refine it over time.

_One Possible Way To Store and Retrieve Structured Knowledge[From Here] _

Structured memory will be useful also for evolutionary frameworks to effectively manage search spaces. Indeed, storing, structuring, and mining large volumes of single and multi-agent traces can help future agents become much more efficient—potentially enabling effective recursive self-improvement through structured memory-based mechanisms.

Another challenge is to support concurrent edits to shared memory, and concurrent edits in general, when there are many agents performing transformations. While there have been some useful attempts at supporting multiversioning and copy-on-write semantics, it isn’t clear that such techniques will suffice when thousands of agents are attempting to edit shared state at the same time. For instance, when agents are trying various potential transactions in response to a user request, the effects of the vast majority of these transactions need to be rolled back—with only the one ‘correct’ transaction’s result persisting. Work on supporting exactly-once semantics is relevant here, as are underlying techniques based on CRDTs and operational transformation. For updates to fuzzy mechanisms such as memory, we may be able to sacrifice on consistency for perfect correctness in the interest of latency. While agents can reason about semantics to compensate or roll back their actions to eventually finalize most tasks, the primary challenge lies in the degree to which they step on each other’s toes during the process. An important failure mode to be avoided is a form of “livelock,” where incessant compensating actions prevent any meaningful progress.

Beyond shared state, other concerns emerge when trying to support an army of agents, including what to do when agents fail, how agents should communicate with each other (directly or through intermediate shared state), and how we should deal with straggler agents. There have been some developments in supporting durable multi-agent execution, such as Temporal, but it remains to be seen if such solutions will apply at scale across thousands of agents. On the topic of communication, we need mechanisms to enable agents to negotiate with each other. Imagine four developer agents attempting to reach consensus on a shared schema, with distinct but overlapping objectives. In a human setting, this would involve iterative discussion and compromise; for agentic swarms, we must define the mechanisms that allow them to converge on a design that reflects the underlying goals of their respective principals. Or if agents are all requiring access to a limited resource, again communication will be necessary. It remains to be seen if this is best done via centralized coordination, or if a decentralized approach is necessary.

Data Systems By Agents

Finally, if intelligence is effectively free, then we can employ this intelligence to synthesize new data systems from scratch. Indeed, in many settings, general-purpose data systems may be overkill, as they have to support every schema, query, and hardware target. Given a workload, recent work, including Bespoke OLAP and GenDB, has shown that one can use an agentic pipeline to synthesize a complete, workload-specific analytical engine—in minutes to a few hours, at a cost of a few dollars. The engines are disposable: when the workload shifts, one can simply regenerate them. Analogously, our work has shown that one can synthesize custom key-value stores from scratch, targeted to the workload. In fact, modern IDEs, such as Kiro, elevate specifications for systems development to be a first-class citizen.

Agents Can Synthesize Custom Data Systems From Scratch

The main issue, however, is that specifications are typically imperfect, and don’t cover all corner cases. Present-day agents will exploit the missing specifications to reward-hack their way to a high performance metric. In our custom key-value store work, we found that one way to alleviate this is to have auxiliary verification agents trying to generate test cases that catch the exploitation of corner cases, essentially expanding the specification. Yet another approach is to both generate a system and a proof for its correctness together, for which we have found some early success, but more needs to be done to solidify the approach. Further, it remains to be seen what is the best way to solicit human-written specifications for a system—can this be done in an iterative, human-in-the-loop manner, as opposed to a one-shot, incomplete one. Indeed, human-written specifications are incomplete even for manually authored software, so one would expect that future agents that are more aligned will increasingly exercise better judgement when making design decisions.

_One Possible Data System Synthesis Pipeline[From Here] _

Other questions here involve testing whether starting from a mature system (e.g., Postgres) and removing components/functionality can lead to higher performance or more user trust. Separately, is there an opportunity to make the design composable, comprising various verified components that are mixed and matched given a workload? For example, perhaps the workload hasn’t changed enough for the storage layer to be updated, but perhaps the query optimizer requires changes. A perhaps more viable proposition involves employing agents coupled with proof systems to target critical parts of the code associated with formal proofs, rather than doing so for the entire system.

A final opportunity here is to move away from the traditional data systems stack with clearly-defined interfaces (e.g., parser, query optimizer, storage manager, …) — that were each largely the prerogative of a single human team to manage. Instead, agents can find new ways to “blend” these components together, perhaps identifying new optimization opportunities as a result. Agents can also fill in missing gaps in functionality to make existing systems much more feature-complete, or reach feature-parity with other competing systems—or analogously, continuously refining open-source systems in response to feature requests or issues (perhaps filed by other agents!) Doing so in a way that prioritizes correctness, long-term maintenance, and human interpretability will be a challenge.

Looking Further Ahead

In the era of near-free intelligence, data systems matter more than ever. As agents take on the bulk of knowledge work, the workload for data systems will change, the substrate they need to run on will have to be built, and increasingly, they will participate in designing data systems themselves. Each of these shifts opens up a new, exciting research agenda.

Co-Evolution of Data Systems and Agents

Looking further out, the boundaries between agents and data systems will likely start to blur. For instance, agents may design the data systems they themselves run on, defining both the interfaces as well as the system components underneath. Both the interfaces and internals can be evolved over time by agents in a form of recursive self-improvement. There is also an opportunity to rethink data systems as a holistic source of truth for the entirety of relevant state: including raw data, memory, and coordination state, further erasing the distinctions between the data that is being queried by agents and data generated as a result of agentic activity. Finally, data systems may themselves incorporate agentic components, fundamentally evolving from passive computation engines into intelligent, proactive, self-optimizing architectures. It is hard to predict what the future may hold. We’re in for a wild ride!

Acknowledgments

The perspective and ongoing work described in this post are the product of joint research and many discussions with wonderful collaborators at the EPIC Data Lab, Data Systems & Foundations group, and the broader Berkeley AI-Systems community. Thank you all!

BibTex for this post:

@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}
}