本文要介绍的是 UC Berkeley 2025 年 8 月在 arXiv 上发表的论文《Supporting Our AI Overlords: Redesigning Data Systems to be Agent-First》。论文基于 Benchmark 对 Agent 使用数据库的负载特征进行了量化分析，最终结合这些负载特征，提出了对 Agent-First 数据库的架构以及应具备的能力的畅想。
前言
在《AI Agent 需要什么样的数据库？》一文中，我们总结了 AI Agent 使用数据库的负载特征，以及对应负载下，数据库所应具备的能力：
| 极短的冷启动时长 | |
| 自动弹性伸缩 | |
| 快速 PITR |
其中，即时创建、大量小实例、活跃时长不稳定更多的是数据库实例生命周期维度的负载特征。至于 Agent 使用 SQL 查询的特征是怎样的，文中没做太多分析。
反复调试与 SQL 查询相关，但文中并没有做定量分析，仍无法回答以下问题：
“Agent 需要反复调试多少次才能成功？”
“Agent 查询数据库的 SQL 本身有哪些特征？”
“有多少 SQL 是重复多次查询的？”
“怎样才能帮助 Agent 减少调试的次数？”
弄清楚这些 Agent 使用 SQL 查询的负载特征，有助于我们设计出一个 Agent-First 数据库。
UC Berkeley 的论文《Supporting Our AI Overlords: Redesigning Data Systems to be Agent-First》针对这些问题给出了他们的答案，并提出了他们对 Agent-First 数据库的畅想。
Agent SQL 查询的负载特征
为了弄清楚 Agent 使用 SQL 有哪些特征，论文基于 BIRD Text2SQL benchmark 进行分析，使用了 GPT-4o-mini 和 Qwen2.5-Coder-7B-Instruct 两个模型进行对比，后端数据库为 DuckDB。
BIRD Text2SQL benchmark 包含了 12,751 个 Question-SQL 对，分布在 95 个库中，数据量 33.4GB。测试过程是将自然语言的 Question 发给 Agent，由 Agent 生成 SQL 并查询数据库，最终对比 Agent 生成的 SQL 和答案 SQL 的查询结果和时长。
得到了如下分析结论。
结论 1：单 Agent 多轮尝试或多 Agent 并发尝试有助于提升 SQL 查询正确率
如下所示，单 Agent 随着尝试轮次的增加，任务成功率呈增长趋势，5 轮后增长减弱，稳定在 55% 左右。
采用多个 Agent 并发执行任务，也能提升任务成功率，如下图所示，当并发数增加到 50 时，成功率可达 70% 左右。
不管是单 Agent 多轮尝试，还是多 Agent 并发尝试，都会导致请求吞吐量呈倍级、甚至数十倍级的提升，对数据库的性能提出了更高的要求。
结论 2：Agent 有大量重复的 SQL 查询，占总查询数的 80%~90%
在多 Agent 并行尝试的方案下，取 K=50，观察在 BIRD dataset 下产生的所有执行计划，得到算子的分布如下：
上图从 2 个维度展现了 SQL 的重复程度：
(a) 不同的执行计划的节点数可能不同，在不同规模的执行计划下，unique 节点的占比只有 5%~22%（Prop. 曲线）。
(b) 按照节点（算子）类型归类，无重复节点（算子类型相同，算子中表达式不同）的占比只有 5%~10% （Prop. 曲线）。
大量的重复查询意味着，缓存或者记忆，将会是提升 Agent 访问数据库性能的关键。
结论 3：Agent 的 SQL 查询类型是多样的
给 Agent 一个数据查询的任务，它并不会立刻生成结果查询 SQL，而是会先进行一些探索，比如找到有哪些表、表中有哪些列等。
论文把 Agent 完成一个数据查询任务所执行的 SQL 划分成 4 个类型：
探索表（exploring tables）：查询数据库中都有哪些表。 探索列（exploring specifical columns）：查询指定表中有哪些列。 中间查询（attempting part of the query）：基于前 2 步的信息，构建中间查询，开始尝试查询相关数据。 完整查询（attempting entire query）：根据子查询生成完整的 SQL，并执行查询，得到最终结果。
可以看到，Agent 会先进行粗粒度的元数据查询，然后再是进行从部分到整体的数据查询，直到完成任务。
当然，Agent 不一定会按严格的顺序执行这 4 个类型的 SQL。如上图所示，在任务执行的过程中，Agent 大部分时间里都处于试错阶段，反复探索列和执行中间查询。
结论 4：适当的引导可以有效降低 Agent 完成一项任务的轮次
如果 Agent 在大部分时间里都在试错，就意味着数据库大部分时间里都是在做无用功，浪费资源。
如果给 Agent 适当的引导，比如告诉 Agent完成这项任务所需的表和列有哪些，能否减少这些无用功呢？
论文对此做了对比实验，结果数据如下：
结果显示，适当的引导，可以降低 18.1% 的总 SQL 查询次数！其中，探索列和中间查询降幅最大，分别达到了 27.7% 和 36.6%。
论文把满足上述特征的 Agent 负载，称为 Agentic Speculation。
显然，为人类设计的传统数据库已无法高效支撑 Agentic Speculation，它需要从一个被动的查询执行者，转变为一个能够与 Agent 主动协作的伙伴，也即 Agent-First 数据库。
Agent-First 数据库
论文提出了 Agent-First 数据库的架构畅想，如下图所示：
可以看到，Agent-First 数据库已经不再是对传统数据库的小修小补，而是一种重构，实现了与 Agent 的融合。
查询方式的重构
首先，Agent 与数据库交互的语言，不再是 SQL，而是一批 Probe。
Probe 不仅包含了 SQL，还有附带一段由自然语言描述的背景信息，这主要起到引导作用，有助于减少反复试错。
背景信息可以包含如下内容：
查询意图。阐述本次查询的最终目的，给数据库一个方向性的指导。 查询阶段。元数据探索阶段和数据查询阶段对数据的精度、调度优先级都不一样。 查询精度。比如可以指定查询结果不需要 100% 精确，80% 就好。 优先级。在本批 Probe 中，当前查询的优先级，方便数据库更好地调度。 终止条件。比如，在全表扫描请求中，指定查询终止条件为扫描 80% 数据即可，或查询时长不超过 1ms。 开放性目标。比如，Agent 想了解美国东西海岸的销售差异，可以下达一个开放性指令：请从东西海岸各选两个州，给我生成统计数据，具体选哪几个州，你看着办，选效率最高的就行。这是 SQL 无法实现的功能。
通过背景信息，Probe 极大扩展了 SQL 语义查询的功能。
在数据库侧，库内 Agent 替代传统的 SQL 解析器。
Probe Parser and Interpreter Agent 会解析 Probe，随后提交给后端执行查询；
另外，数据库会按需唤醒一个或多个 Sleeper Agents，它们不负责回答主要问题，而是提供辅助信息和成本建议：
Sleeper Agents 有数据分布的全景图，可以帮助 MSP Agents 更好地理解数据本身。
比如，可以推荐相关表：你查了
orders表，可能你还会需要查customers表。比如，解释查询结果：*你的查询结果为空，原因不是没有相关数据，而是列名
CA错了，正确的列名是California*。Sleeper Agents 还能给出查询效率和成本的建议，帮助 MSP Agents 更高效地进行查询。
比如，本查询全美数据的请求成本太高，要不要先查加州试试？
比如，我发现你在连续独立地查 50 个州的数据，把它们合并成一个批处理请求会快得多。
最终，数据库会将查询结果和这些建议打包返回给 MSP Agents，这就是从被动应答，到主动引导的转变。
查询优化的重构
其次，查询优化器的目标不再是传统数据库那样的“最快地给单次查询一个精确的结果”，而是“用最小的总时间代价，完成本批次以及未来批次的 Probes 查询任务”。查询结果不一定是精确的，只要能够完成 MSP Agents 交代的任务即可。
这意味着查询优化器不能局限于当前批次的优化，还要具备根据历史交互记录和最终目标，预测未来查询的能力。
对于当前批次优化（Intra-Probe Optimization）：
近似替代精确。比如，优化器发现当前处于探索阶段，可以适当降低查询精度，减少资源消耗。
避免“因小便宜吃大亏”。比如，当前查询如果返回一个低精度的结果，很可能引发更多轮的查询，得不偿失。这就需要优化器综合考虑当前数据库自身的状态、系统资源，决定在本轮或下一轮执行精确查询。
动态调整计划。执行计划从静态转变为动态，比如，对于 A 列，最初优化的结果是设置查询精度为 80%，但随着查询的执行，发现系统资源不足，就主动将精度调整为 60%。
对于多轮批次优化（Inter-Probe Optimizations）：
基于增量信息做剪枝，避免做无用功。比如上一批 Probe P 查询了 <用户姓名, 年龄>，本批次 Probe P‘ 又要查询<用户姓名, 年龄, 电话>，优化器会分析新增的信息电话是否对最终目标有帮助，如果没有，则直接丢弃，避免重复查询。提前准备好下一批查询的结果。比如，优化器学习到用户正反复对 users和orders表进行 JOIN 查询，那么可以主动将两表 JOIN 的结果通过物化视图缓存下来，提升下次的查询效率。
数据索引的重构
对传统数据库来说，业务流程往往是固定的。
比如，应用知道哪些列会被经常查询，就可以预先为这些列建立索引，提升随机查询性能。
比如，应用知道自己是 OLAP 的业务，那么就采用列式存储，提升复杂分析查询性能。
但 Agent 的业务流程是动态的，查询类型是多样化的。它可以是对元数据的探索性查询、也可以是精确数据查询；可以是 TP 业务的点查，也可以是 AP 业务的批量扫描；可以是全文检索，也可以是向量检索。
另外，Agent 还会存在大量重复的查询。
所以，光靠传统的索引机制，已经难以高效支撑 Agentic Speculation。
还需要引入 Agent 记忆存储：
存储知识。存储元数据，比如该表有哪些列，每列的类型是什么，提升探索查询阶段的性能。 存储经验。存储过去的查询结果，使得下次查询能够直接复用，避免重复查询。
事务管理的重构
Agent 会存在大量的 “What-if” 式的探索流程。论文里提到，Neon 数据库统计数据显示，Agent 创建的数据分支数量是人类创建的 20 倍、Agent 执行数据回滚的次数是人类的 50 倍。
这决定了 Agent 之间的数据操作需要良好的隔离性，避免相互影响。
传统的 MVCC 事务隔离机制已无法应对这种场景。MVCC 的目的让多个并发事务感觉不到对方的存在，互不干扰。它处理的是短暂的、并行的“现在”。它的所有版本最终都会被清理，历史永远是一条直线，是小而短暂的。
而 Agent 的 “What-if” 是要创建无数个平行的“未来”，它需要同时保留成百上千个数据快照，在每个快照上运行调试，比较结果，然后选择最优的那个“未来”。所以，它的历史是一个庞大的树状结构，是大而长久的。
类似于 Git 的数据分支机制，无疑更适合 Agent 大量的 “What-if” 事务管理。
另外，鉴于 Agent 会频繁地调试数据，快速地创建和回滚分支是必备的能力。可以基于 Copy-on-Write、Redirect-on-Write 等技术实现该能力。
在数据分支的能力上，Neon 数据库走在了业界前列，相关实现细节可参考《AI Agent 需要什么样的数据库？》。
最后
总结 Agent SQL 查询的负载特征以及数据库所需的能力如下：
虽然论文给出了 Agent-First 数据库的架构，但这更多的是一种对未来的畅想，离真正落地，还有很多技术难题要解决。
最突出的问题是，成本高昂。
Agent-First 数据库在库内部署了多个 LLM Agent，每次数据查询都可能涉及多个 Agent 协作，查询成本和时延可能会非常高。
另外，如何处理库内的 Agent 记忆更新、如何实现高效的查询优化策略等等，都是需要更深一步的研究。
不过，随着今年依赖 AI Agent 的飞速发展，这个 Agent-First 数据库也许很快就会出现。
文章配图
可以在 用Keynote画出手绘风格的配图 中找到文章的绘图方法
