UC Berkeley 在2025年发表的论文《Supporting Our AI Overlords: Redesigning Data Systems to be Agent-First》，通过Benchmark量化剖析了AI Agent在数据库使用中的负载特征，并提出面向Agent的数据库架构（Agent-First）构想，同时给出了提升SQL查询准确率的关键策略与实证验证。本文将带你深入解读这些研究成果，并展望未来数据库的设计演进方向。
1. 为什么需要 Agent-First 数据库？
传统数据库主要面向人类用户设计，而AI Agent的交互方式与之存在本质差异。Agent需要频繁进行创建、调试和重复查询，其负载特征表现为：即时创建、大量小实例、活跃时长不稳定（实例生命周期维度）以及反复调试、高吞吐、高重复、多样化的 SQL 查询（查询维度）。举例来说，Agent可能需要数十次甚至上百次的SQL尝试才能获得正确结果，且大量查询存在重复性。这些特征已超出传统数据库的优化范围，因此有必要重新设计一种以Agent为中心（Agent-First）的数据库体系。
2. Agent SQL 查询的负载特征（基于 BIRD Text2SQL Benchmark）
论文使用GPT-4o-mini和Qwen2.5-Coder-7B-Instruct两个模型，在后端DuckDB上执行BIRD数据集（12,751个Question-SQL对，95个库，33.4GB），得出以下四个关键结论。这些发现为Agent-First数据库的设计提供了坚实的数据基础。
结论 1：多轮尝试或多 Agent 并发能显著提升成功率，但会大幅提升吞吐量
- 单 Agent 多轮尝试：随着尝试轮次增加，任务成功率逐步提升，5 轮后增长趋势减弱，稳定在 55% 左右。
- 多 Agent 并发：当并发数量增加到 50 时，成功率可达 70% 左右。
这两种策略均会导致请求吞吐量呈现倍级甚至数十倍级增长，对数据库性能提出了更高要求。
结论 2：Agent 有大量重复的 SQL 查询，占比高达 80%~90%
在多 Agent 并行（K=50）场景下分析所有执行计划，结果如下：
- 不同执行计划节点数：unique 节点占比仅 5%~22%。
- 按节点（算子）类型归类：无重复节点（算子类型相同但表达式不同）占比仅 5%~10%。
高比例重复意味着缓存或记忆机制将成为提升性能的关键。
结论 3：Agent 的 SQL 查询类型多样，且大部分时间处于试错阶段
Agent 完成一个数据查询任务通常经历以下 4 类 SQL：
- 探索表（exploring tables）：查询数据库中包含哪些表。
- 探索列（exploring specific columns）：查询指定表中包含哪些列。
- 中间查询（attempting part of the query）：基于前两步构建中间查询。
- 完整查询（attempting entire query）：生成最终 SQL 并执行。
下图展示了 Agent 在任务执行过程中大部分时间都在试错，反复进行探索列和中间查询（红色区域）。
这意味着数据库当前大部分计算资源都消耗在“无效尝试”上。
结论 4：适当的引导可以显著降低无效查询次数
如果 Agent 在执行任务前获得引导（例如告知所需的表和列），结果如下：
- 总 SQL 查询次数降低 18.1%。
- 探索列次数降低 27.7%，中间查询次数降低 36.6%。
论文将满足上述特征的负载称为 Agentic Speculation。传统数据库作为被动的查询执行者已无法高效支撑，需要转变为能与 Agent 主动协作的伙伴——即 Agent-First 数据库。
3. Agent-First 数据库架构畅想
论文提出了一种重构后的数据库架构，如下图所示，它不再是简单修补，而是与 Agent 实现深度融合。
3.1 查询方式重构：Probe 替代传统 SQL
- Agent 与数据库的交互语言不再是纯 SQL，而是 Probe。Probe 除了包含 SQL，还附带一段自然语言描述的背景信息，起到引导作用，可大幅减少试错。
- 背景信息可包含：查询意图、查询阶段（元数据探索 / 数据查询）、查询精度（如 80% 即可）、优先级、终止条件、开放性目标（如“从东西海岸各选两个州，你看着办”）等。
- 数据库内部由 Probe Parser and Interpreter Agent 解析 Probe，并唤醒一个或多个 Sleeper Agents 提供辅助信息和成本建议：
- 提供数据分布全景图，推荐相关表，解释错误原因（如“列名错了，正确的是 California”）
- 给出效率建议（如“先试加州，不要查全美”），甚至建议合并非独立查询。
- 数据库将查询结果与这些建议打包返回，实现从被动应答到主动引导的转变。
3.2 查询优化重构：追求总时间最小化，而非单次精确
优化目标从“最快地给单次查询精确结果”变为“用最小总时间完成本批次及未来批次的 Probes 任务”。优化器不仅要优化当前批次，还要预测未来查询。
- Intra-Probe Optimization（当前批次优化）：
- 近似替代精确：探索阶段降低精度，节省资源。
- 避免“因小失大”：如低精度结果可能引发更多轮查询，需综合判断。
- 动态调整计划：根据系统资源实时调整精度（如从80%降为60%）。
- Inter-Probe Optimizations（多轮批次优化）：
- 基于增量信息剪枝：如果新查询只增加无帮助的列，直接丢弃。
- 提前准备下一批结果：若学习到反复 JOIN 特定表，主动物化缓存。
3.3 数据索引重构：引入 Agent 记忆存储
Agent 的查询类型多样化（元数据探索、点查、批量扫描、全文检索、向量检索等），且存在大量重复。因此需要 Agent 记忆存储，包括：
- 存储知识：元数据（表有哪些列、类型等），加速探索查询。
- 存储经验：过去的查询结果，直接复用，避免重复。
3.4 事务管理重构：数据分支替代 MVCC
Agent 有大量“What-if”探索流程，Neon 数据库统计显示：Agent 创建的数据分支数量是人类创建的 20 倍，执行回滚次数是人类的 50 倍。传统 MVCC 处理的是短暂并行的“现在”，历史是直线；而 Agent 需要创建无数个平行的“未来”，历史是庞大的树状结构。因此 类似 Git 的数据分支机制更适合，可实现快速创建和回滚分支（基于 Copy-on-Write、Redirect-on-Write）。Neon 数据库已在数据分支方面走在前列。
4. 常见问题（FAQ）
- Q：Agent-First 数据库会不会成本太高？
A：是的。在数据库内部署多个 LLM Agent（如 Probe Parser、Sleeper Agents）会显著增加每次查询的成本和延时。例如，Sleeper Agents 需要调用模型进行理解与建议，这比传统 SQL 解析慢得多。论文指出这是主要挑战，但未来随着推理效率提升和硬件进步，成本有望下降。 - Q：Agent-First 数据库何时能落地？
A：目前仍处于架构畅想阶段，许多技术难题（如 Agent 记忆更新策略、高效跨批次优化、成本控制）尚未解决。不过随着今年 AI Agent 的飞速发展，预计未来 1-3 年内会出现实验性产品，Neon、DuckDB 等已有初步探索。 - Q：Agent SQL 查询的“重复率高”具体指什么？
A：指不同 Agent 或同一 Agent 在不同时刻可能执行非常相似的 SQL 语句（如探索同一张表、执行相同结构的中间查询）。论文数据显示超过 80% 的 SQL 节点是重复的，这意味着适当缓存可大幅减少计算开销。
5. 小提示（Building Tips）
- 优先实现缓存与记忆：从“高重复率”特征入手，在数据库内增加结果缓存或物化视图，能以最小代价提升 Agent 查询性能。
- 为 Agent 提供引导接口：若无法立即重构为 Probe，可先提供元数据预提取（如表结构、列注释）接口，让 Agent 减少探索阶段，实验证明可降低总查询次数 18%。
- 数据分支是“What-if”探索的最佳方案：如果系统需要支持大量 Agent 并行调试，尽早引入基于 Copy-on-Write 的快照机制（如 Neon 的 Branch），可避免传统 MVCC 下事务冲突和版本膨胀。
- 监控 Agent 行为，动态优化：通过记录 Agent 的查询模式（如频繁 JOIN 哪些表），自动创建索引或预计算，实现类似 Inter-Probe 优化。
6. 总结
下表归纳了 Agent SQL 查询的负载特征与 Agent-First 数据库所需能力：
| Agent SQL 查询负载特征 | Agent-First 数据库能力 |
|---|---|
| 高吞吐量 | 批量 Probe 处理、跨批查询优化 |
| 高重复率 | 查询优化器主动增加结果缓存、Agent 记忆存储 |
| 多样性 | Agent 记忆存储 |
| 可引导 | Probe 替代 SQL、Sleeper Agents 提供辅助信息和成本建议 |
| 大量 “What-if” 探索 | 数据分支替代 MVCC 事务隔离 |
虽然 Agent-First 数据库在成本和实现上仍面临巨大挑战，但它是顺应 AI Agent 时代发展的必然方向。随着未来推理效率提升和数据库引擎的革新，我们很可能在不久的将来看到真正的 Agent-First 数据库产品。