过去十几年，数据库设计的核心假设很简单：用户的查询模式是可预测的。

电商场景，用户搜商品、看详情、下单、查物流——访问路径固定，索引优化有章可循。社交场景，关注、Feed流、点赞——读写比例稳定，分库分表有套路。做了这么多年技术，我对数据库的理解一直建立在这个基础上：搞清楚访问模式，设计好索引，剩下的交给数据库引擎。

但AI Agent正在打破这个假设。

这不是在说向量数据库——那个话题过去两年已经被翻来覆去讲了很多遍。我说的是一个更根本的问题：当Agent开始像一位持续工作的"新员工"一样操作数据库，检索、推理、调用工具、把中间结果写回系统，数据库面对的不再是一次次独立的查询，而是一条条长链路、动态演化、无法预判的任务流。

这套玩法，现有数据库接不住。

Agent不是在"查数据"，它在"用数据库"

传统的数据库访问，不管是人手点出来的SQL，还是应用程序拼出来的ORM查询，本质上都是"一问一答"。请求进来，查询执行，结果返回，连接释放。整个过程毫秒级，最长不过秒级。

Agent的访问模式完全不同。

一个Agent执行任务时，可能先做一次向量检索找到相关上下文，再做一次结构化查询获取精确数据，然后调用外部工具处理，把中间状态写回数据库，接着根据结果调整下一步策略，再发起一轮检索……整个链路可能持续几十秒甚至几分钟，中间涉及多种数据模型和访问方式的混合。

这对数据库意味着什么？

第一，访问模式不再可预测。传统场景里，DBA可以分析慢查询日志，针对性地加索引、调整执行计划。但Agent的访问路径是推理过程动态决定的——同一个Agent，面对不同的输入，可能走出完全不同的数据访问链路。你没办法提前为一条还没出现的路径做优化。

第二，读写边界模糊了。过去我们习惯把读写分离当作基本架构策略：读多写少就上读写分离，读少写多就优化写入链路。但Agent的一次任务里，检索、更新、状态写入交替进行，读写比例在任务生命周期内剧烈波动。传统的读写分离策略在这种场景下可能反而制造瓶颈。

第三，"连接"的概念需要重新审视。传统连接池设计假设每个连接的生命周期很短，用完就还。但Agent可能持有连接贯穿整个任务链路，中间有思考、等待外部响应、工具调用等间歇。如果连接池还是按老思路设置超时和回收策略，要么Agent的连接被误杀，要么池子被Agent占满，正常业务请求拿不到连接。

数据库要管理的不只是数据，还有状态和记忆

这是我觉得大部分人在讨论"AI+数据库"时忽略的一个维度。

向量检索、RAG这些热门话题，本质上还是在"查数据"的范畴内——只是数据类型从结构化变成了向量。但Agent真正改变的是数据库的角色定位：它不只是数据存储，还变成了Agent的"工作台"。

什么意思？Agent在执行任务时，需要把中间状态、推理上下文、工具调用结果、长期记忆都持久化到某个地方。这个地方，在实践中，往往就是数据库。

任务执行到一半崩了怎么办？恢复时需要从数据库读取任务进度和中间状态。Agent需要"记住"之前的交互历史？长期记忆得存在数据库里，还得支持按时间、相关性、重要度等多维度检索。一个多Agent协作场景，不同Agent之间共享上下文？数据库变成了共享状态总线。

这些事情，传统数据库不是完全做不了，但做得很别扭。我们的表结构设计、索引策略、事务模型，都是围绕"数据"设计的，不是围绕"任务状态"设计的。当数据库要同时管理数据和状态两套东西时，可能需要从根本上重新思考数据模型。

弹性不会自然发生

云原生数据库这几年进展不小：存算分离、资源池化、Serverless。但在AI Agent场景下，"资源能拆开"和"弹性真的好用"之间还有很大距离。

Agent的工作负载有一个显著特征：高度不规则的突发。Agent在"思考"时可能很安静，但一旦开始执行，可能瞬间产生密集的向量检索请求。调用外部工具时又静下来了，工具返回后又来一波密集写入。这种"脉冲式"的负载模式，对弹性伸缩的响应速度和粒度提出了极高要求。

更麻烦的是，Agent的状态不能被随便丢弃。传统Web请求，某个节点挂了，用户刷新一下页面重新请求就行。但Agent执行到一半挂了，它的任务进度、上下文状态、工具调用链路如果丢了，整个任务就得从头来。计算资源可以回收，但状态不能丢——这个约束让弹性设计的复杂度直接上了一个台阶。

资源解耦是基础设施的事，但弹性不会因为你用了存算分离就自动出现。它需要观测、预测、决策、执行、反馈形成完整闭环。对Agent场景来说，这个闭环里还得加上状态保护机制——这是传统弹性方案没考虑过的。

Benchmark也得跟着改

当数据库进入生产环境，怎么判断它靠不靠谱？这个问题在Agent时代也需要重新回答。

传统Benchmark以单条查询或事务为评测单元：这个查询延迟多少、那个事务吞吐多少。但Agent的一次任务可能包含几十次不同性质的操作——向量检索、结构化查询、状态更新、工具调用——单条查询快不代表整个任务跑得快。

我觉得至少有三个变化值得关注。

评测单元要从"查询"升级到"任务"。Benchmark应该模拟Agent的完整任务链路，测端到端的完成时间和成功率，而不只是单个操作的性能。

负载要分阶段设计。Agent的记忆在持续增长，访问模式在演变。Benchmark应该覆盖从冷启动到稳定运行、到数据增长后的性能退化、再到突发并发时的恢复能力。

异常要能拆解。当系统表现不好时，Benchmark应该能帮助定位瓶颈在哪个环节——是检索慢了、生成超时了、还是状态写入卡住了——而不是只给一个综合分数。这种归因能力，是系统从"能用"走向"可信赖"的关键。

写在最后

数据库的下一站，不是功能清单上多加几行——"支持向量检索""支持图查询"——这种级别的迭代。它需要的是架构层面的调整：数据表示要适应新的对象类型，资源管理要应对不可预测的负载模式，状态管理要跨越多次查询和工具调用，评测体系要从查询维度升级到任务维度。

这不是一次功能升级，是一次跨层重构。

对做技术的人来说，这个问题值得提前想。不是因为明天就要换数据库，而是因为当Agent开始进入业务系统，它和数据库之间的交互方式会从根本上改变我们对"数据层"的理解。能不能在那个时间点到来之前，把基础打扎实，决定了后面是被动应付还是从容应对。

数据库过去几十年的演进，解决的是"把数据存好、查快"的问题。下一个十年，它要解决的是"帮Agent把活干好"的问题。这是完全不同的命题。