上周参加一个内部技术评审，有人提了一个看起来不太起眼的问题：我们的Agent在执行复杂任务时，数据库连接池经常被打爆，为什么？

排查下来发现原因很直接——Agent在做多步推理时，每一步都可能触发数据库查询。而且它的查询模式完全不符合人类开发者的习惯：没有预编译的SQL模板，没有合理的分页，没有批量查询优化。Agent就像一个不知疲倦的实习生，一条一条地查，一步一步地追，直到把数据拼完整。

这件事让我开始认真想一个问题：当Agent成为数据库的主要使用者，而不是人类开发者时，数据库的设计范式是不是该变了？

传统数据库的隐含假设

过去几十年，数据库的设计和优化都围绕一个核心假设：使用者是人类开发者，通过应用程序发出可预测的查询。

SQL语法是为人类设计的。索引策略是基于已知的查询模式来优化的。连接池的大小是基于人类用户的并发行为来估算的。ORM框架把数据库操作封装成对象方法，本质上也是在替人类开发者降低心智负担。

这整套体系运转得很好——因为人类的行为是可预测的。一个电商系统的商品详情页，99%的情况下会命中那几个固定的查询路径。一个金融产品的持仓页面，查询模式在产品上线那天就已经确定了。

但Agent打破了这个假设。

Agent的访问模式完全不同

Agent使用数据库的方式，和人类开发者完全不同。这不是程度的差异，是本质的差异。

首先，Agent不会写"漂亮"的SQL。人类开发者会精心设计查询，避免N+1问题，合理使用JOIN和子查询。Agent不会。它的思维链是逐步展开的——先查主表获取ID，再用ID查关联表，发现需要补充信息，再查另一张表。一个在人类看来可以用一条SQL解决的需求，Agent可能拆成七八次查询。

其次，Agent的查询模式不可预测。人类开发者的查询路径在代码上线时就基本确定了。Agent的查询路径取决于它当前的推理状态——上一步的结果决定了下一步查什么。这意味着数据库的访问模式从"已知"变成了"动态生成"。

第三，Agent的查询频率呈现极端的脉冲特征。它可能在思考阶段几分钟不发一个请求，然后在执行阶段一秒内发出几十个查询。传统的连接池模型在这种模式下效率极低——空闲时浪费资源，突发时又不够用。

Agentic数据库需要什么

业界已经开始讨论这个方向。阿里云最近提出了"Agentic数据库"的概念，核心观点是：当Agent成为数据库的第一用户，数据库需要提供新的交互范式。

我的理解是，这不是在现有数据库上"加个AI功能"那么简单。需要变化的层次更深。

查询接口需要重新设计。SQL是给人类用的声明式语言。Agent需要的可能是"意图查询"——告诉数据库"我需要这个用户最近三个月的投资偏好变化趋势"，让数据库自己去规划查询路径。这比让Agent生成一堆SQL然后由数据库优化器去兜底，要高效得多。

安全模型需要升级。传统RBAC控制的是"谁能访问什么表"。Agent场景下需要的是"在这个任务上下文中，这个Agent的查询行为是否合理"。一个被授权读取用户画像的Agent，如果它的查询模式暗示它正在尝试反推用户的完整交易历史，数据库应该有能力识别并阻断。

响应格式需要变化。Agent需要的不是"一行行数据"，而是带有上下文的结构化信息。包括数据来源、数据时效性、数据之间的关联关系。传统数据库返回一个结果集就完事了，Agent需要的是"数据包"——能让它直接用于下一步推理的完整上下文。

没那么简单

这个方向听起来很美，但有几个现实问题。

最大的问题是可控性。Agent的自主查询能力越强，出错的风险就越大。一个理解错误的意图描述，可能导致数据库执行一系列不必要的查询，甚至访问到不该碰的数据。在金融业务中，这不是"可能有bug"的问题，是"可能引发合规事故"的问题。

另一个问题是现有系统的迁移成本。全球有数以亿计的应用运行在关系型数据库上，有成熟的SQL生态、ORM框架和运维工具链。你不可能让所有人为了适配Agent而换掉数据库。更现实的路径可能是在现有数据库之上加一层"Agent网关"，做查询翻译、行为审计和安全管控。

还有一个容易被忽略的点：大部分团队还没有Agent大规模访问数据库的真实场景。现在讨论这个问题，对多数人来说可能为时尚早。但方向是确定的——就像五年前讨论Serverless一样，真正爆发的时候，提前想清楚的人会占优势。

金融场景的特殊性

在金融业务中，数据库的访问从来不是纯技术问题。合规、审计、数据隔离，这些要求使得金融数据库的使用方式比普通互联网应用严格得多。

传统做法是在应用层做"保护"——所有数据库访问都通过预定义的接口，应用层负责校验权限、记录审计日志、控制数据范围。但当Agent直接面向数据库时，这层保护就失效了。

我觉得金融场景下的Agentic数据库，至少需要多一层东西：实时查询意图分析。不是等Agent查完了再做审计，而是在查询执行之前就判断这次访问是否符合当前的任务上下文。这个能力，传统的审计日志做不到。

一个开始

"Agentic数据库"这个概念现在还在早期阶段。但有一件事我觉得比较确定：当Agent成为数据的主要消费者，围绕数据的整个基础设施栈都需要调整。数据库不是唯一要变的，但它是最底层的那个。

对大部分团队来说，不需要现在就换数据库。但可以开始想一个问题：你的数据库，准备好迎接一个不是人类的"第一用户"了吗？