当数据库的主要用户从人类变成 Agent

过去二十年，我们讨论数据库时默认了一个前提：数据库的主要用户是人类。 所以我们发明了 DBA、容量规划、慢 SQL 优化、实例规格、固定的运维窗口、按月付费的最小实例——这些东西都围绕“人类如何使用数据库”建立。

但当主要用户变成 Agent，一切都要翻新。

不是因为 Agent 更聪明。恰恰相反：它更像一种高频、短命、不可预测、会乱写 SQL、但又极度依赖确定性系统来完成任务的“新物种”。

数据库不再是仓库，而是工作台；不再是后端组件，而是 Agent 的操作底座。

1）一个数字：90% 的数据库不是人建的

最能让人警醒的信号不是技术趋势，而是统计口径：在一些面向开发者的云数据库场景里，新创建的数据库集群中，绝大多数已经不是人类点出来的，而是 Agent 自动创建、自动建表、自动写 SQL、自动跑实验、自动销毁。

这意味着：数据库开始像“可编程资源”一样被调用，像临时容器一样被批量拉起与回收。

当调用者从人变成程序，数据库会遭遇四次“假设崩塌”。

2）Agent 工作负载的四个特征：为什么传统数据库会被打穿

2.1 海量短命实例：从“一个产品一个库”变成“一个会话一个库”

传统世界里，库是长期资产。 Agent 世界里，库更像一次性工作空间：一个会话一个隔离环境，用完即焚。

结果是：实例数会爆炸，而且大多数都是一次性。 如果你仍沿用“最小实例按月付费”的定价习惯，账单会直接把产品逻辑打死——不是贵不贵的问题，而是商业模型根本算不过来。

2.2 数据库成了 Agent 的工作台，不是存储仓库

Agent 做事的流程更像“抓取—结构化—SQL 分析—产出结果”，而不是“把数据存进去就完事”。

决定性差异在于：

• 放在 Markdown/纯文本里，后续分析只能靠模型“泛读”，质量交给幻觉。
• 落到数据库里，SQL 是确定性的，过程可审计、可复现，任务才工程化。

进一步说：当 schema 也由 AI 动态生成，“一个会话一个库/一个隔离单元”就不仅是资源隔离，更是爆炸半径控制：写错了最多毁掉自己这一回合。

2.3 上下文即数据，而且越来越长

复杂 Agent 为了可恢复、可审计、跨会话检索，必须把关键上下文持久化。 而一旦你需要结构化查询、跨任务关联，数据库就会重新成为更优的载体。

问题是：上下文本身开始长得离谱——不仅是文本，还有音频、多模态。 这把很多传统 OLTP 的“舒适区”推到了边界之外。

2.4 流量不可预测，但成本必须可控

人类按作息用系统；Agent 不按。 它可以凌晨三点突然冲一波，也可以沉默几小时。

如果你为这种间歇性活跃长期维持整套计算资源，服务方和客户都会双输。 所以“弹性”不再是锦上添花，而是数据库能否服务 Agent 的前置条件。

3）数据库不再是性能优化项，而是“能不能上线”的前提

在 Agent 密度足够高的产品里，数据库方案不是“将来优化”，而是“今天能不能开放”的闸门。

因为你会遇到一个残酷事实：Demo 可以跑，但一规模化就崩盘——不是技术跑不动，而是成本模型跑不动。

要解决这个问题，思路通常是三层叠加：

1）一个物理集群承载海量逻辑租户：共享基础设施 + 逻辑隔离，而不是一会话一实例。

2）存算分离 + 更极致弹性：让计算尽可能接近按需唤起，甚至允许接近“闲时归零”。

3）承认合理 trade-off：冷启动带来百毫秒级延迟，但在 Agent 场景里往往可接受——因为模型推理本身就是秒级。

但别忘了第四件事：资源控制。海量租户共池，最怕的不是平均负载，而是某个 Agent 把资源打爆拖垮整池。没有清晰的边界，多租就会变成事故放大器。

4）“对象存储 + 元数据库 + 缓存 + 补偿一致性”这条链路，会在 Agent 时代变得不值得

在长上下文场景里，传统做法是：大对象进对象存储，数据库存元数据与索引。

这在纸面上合理，在工程上常常变成一条脆弱链路：一致性要自己补，缓存要自己建，穿透要自己扛，长尾延迟要自己解释。

于是你会得到一套能跑但难维护的系统：组件越来越多，故障面越来越大，迭代速度越来越慢。

Agent 时代有一个更务实的偏好：简化架构，比优化架构更有价值。

如果数据库本身能承载更大的字段、更长的上下文，并且仍保留事务与 SQL 语义，那么把一部分“长上下文”收回数据库，反而是更健康的演进。

这里的关键不只是“能存大”，而是“存大同时不丢掉确定性与查询能力”。否则你省掉的组件，最终会以更复杂的语义补偿回到你身上。

5）一个被低估的老能力：在线 DDL，会在 AI 应用里重新变贵

AI 原生应用的 schema 稳定性远不如传统业务：结构变更频率更高，发布节奏更快。

如果每次改表都要锁表、等停机窗口，研发会被迫“攒改动赶窗口”，质量反而更差。 在线 DDL 这种传统数据库能力，会在 AI 时代重新变成硬通货——它直接决定迭代速度的上限。

6）更深的变化：数据库正在走向“记忆层”的底座

当 Agent 开始跨会话、跨任务、跨设备连续工作，问题就不再是“把数据存下来”，而是：如何把过去的信息，在合适的时候、以合适的形式，重新带回上下文。

数据库能保存偏好、历史决策、项目资料。 但 Agent 还缺一层更“面向工作流”的能力：沉淀、索引、检索、筛选、注入——让恢复状态变得低成本、确定性、可治理。

这不是“数据库不够用了所以加一层”，更像是：把数据库的能力，以更符合 Agent 方式的 API 与机制暴露出来。

结语：当主要用户变成 Agent，数据库要从“系统组件”变成“可编程基底”

Agent 会创建、查询、分支、合并、销毁数据库资源，像使用一个可编程的基底。 数据库不再是被动存储，而是工作台、隔离单元、确定性执行器、成本模型的一部分、以及未来记忆层的地基。

所以这不是一次“兼容新负载”的升级，而是一轮范式转换：

不要试图用旧架构去兼容新用户。要从 Agent 的工作方式出发，重新思考数据库应该是什么样子。