AI代理疯跑，数据库架构被逼到墙角

AI编码代理一夜之间成了数据库最刁难的用户：一个会话里生成应用、改schema、测好几套实现，然后大部分推倒重来。这不是猎奇，而是数据库架构正在被重新出题的信号。PingCAP、Neo4j、ClickHouse三家几乎同时给出的答案，指向同一个判断——AI负载不缺吞吐量，缺的是『便宜、弹性、可靠的持久状态』。谁先想明白这一点，谁就先拿到下一代的船票。

🤖 Agent会话，把数据库当成了草稿纸

负载的物种变了，评估的标准还停在旧世界。

想象一下现在的AI编码会话：Agent生成一个应用，中途改了三次schema，测试了几种实现，绝大多数在会话结束前就被丢弃。另一个会话则完全不同——它在更新订单，同时查询几个月的历史运营数据。这是PingCAP在一篇讨论Lakebase与TiDB X的文章里描绘的典型场景。

看似两个极端，底层要求却高度一致：需要持久的状态，需要正确的事务，需要快速的访问。但它们还需要一样传统基准测试根本测不出来的东西——用文章的话说，是查询吞吐量无法衡量的能力。

传统互联网负载是一条相对平稳的曲线：schema几个月改一次，QPS有波峰波谷但可预测，容量按峰值规划。Agent负载完全是另一种物种：schema可能在一小时内被推翻三次，计算资源随会话潮汐式起落，写入里混着大量『注定要被丢弃』的临时数据。

产业逻辑很直白：当最大增量用户是机器而不是人，数据库的竞争维度就从『每秒多少查询』变成了『每次试错多少钱、状态恢复有多快』。圈内流传一句半开玩笑的话——过去比谁的TPS高，现在比谁的草稿纸便宜。

🏗️ 存算分离，从PPT口号变成工程刚需

过去讲存算分离是为了省钱，现在是为了活下来。

存算分离在数据圈被讲了快十年，早期多少带点营销色彩。但Agent负载把这件事从『可选项』变成了『必选项』：会话潮汐式的计算需求，意味着计算层必须秒级弹性伸缩；而『持久状态+事务正确性』的要求，意味着状态必须放到共享的、可靠的存储层，不能绑定在某台易失的计算节点上。

有意思的是，这个判断正在成为跨阵营的共识。Databricks推出的Lakebase，把OLTP能力带入湖仓生态；PingCAP的TiDB X也在朝同一个架构方向演进。一家从分析侧往事务侧走，一家从分布式事务侧往弹性架构走，两条路线在『存算分离+共享持久状态』这个点上会师。

这张图是我作为架构师对当前收敛方向的抽象：上层是不同形态的计算引擎，下层收敛到共享存储。对工程团队来说，这意味着几件很实际的事——

第一，成本模型变了。计算按会话弹性计费，存储按实际留存分层，『丢弃的草稿』不应该长期占用昂贵资源。

第二，可靠性边界变了。Agent反复改schema、重建表，元数据操作频率会高出好几个量级，存储层的事务与快照能力比以往任何时候都关键。

第三，选型逻辑变了。过去按TP/AP分库选型，现在同一个Agent会话可能同时触发事务写入和历史分析，HTAP不再是卖点，而是默认要求。

据多位接近厂商的人士观察，今年数据库厂商的路线图讨论里，『AI Agent负载特性』出现的频率，已经超过了传统的『某行业客户案例』。风向的转移，比PPT上的转型宣言诚实得多。

🧠 向量内存账本，二值化的精算术

AI应用最大的隐形账单，往往是嵌入向量的内存。

Neo4j最近的一篇工程文章点破了一个容易被忽视的事实：随着AI应用长大，embedding会迅速成为内存的最大消耗者之一。文档越多、切片越细、embedding模型越丰富，数据库需要检索的向量数据就越大——而检索速度还不能降。

这是RAG应用走向生产后普遍会撞上的墙。做RAG的团队都有体感：第一版用512维float32向量检索几十万文档很轻松；等业务要求更细粒度的chunk、换更大的embedding模型、文档库涨到千万级，内存账单就开始失控。

Neo4j给出的方案是『重打分的二值化向量检索』（rescored binary vector search），核心思路是两段式：先用极低精度的二值表示做粗筛——把原本每个维度32bit的浮点压缩到1bit——在内存里完成大规模快速召回，再用原始精度向量对候选集做精排，保住召回质量。一句话总结：内存里放草稿，精度留给决赛圈。

这和第一节的逻辑是同一枚硬币的两面。AI应用的基础设施账单里，『状态』是大头，而向量是状态里膨胀最快的一块。精算内存，本质上是把『为长尾精度付出全量内存』的粗放模式，改成『分层、分级、按需还原』的精细模式。

对架构师的启示是：不要把向量库当成一个黑盒外挂。embedding的维度选择、chunk粒度、量化策略，应该作为数据建模的一部分提前设计，而不是等内存爆了再回头补救。向量检索的竞争，正在从『算法刷榜』转向『单位内存的检索质量』——这是更工程、也更残酷的战场。

⚡ ClickHouse 26.9，OLAP的细节内卷

大盘架构定调之后，胜负手回到了工程细节。

ClickHouse发布26.9版本，改动清单看似琐碎：条件化的LIMIT边界、append-only物化视图的增量刷新、DISTINCT的磁盘溢写、限时访问令牌、更快的min/max/count查询。但把这几条放在一起看，能看到OLAP引擎演进的三条清晰主线。

三条主线分别是：实时化（增量刷新让物化视图告别『改一行、重算全表』的成本陷阱）；成本工程（磁盘溢写是典型的『用便宜资源换昂贵资源』）；以及最值得注意的——安全。限时令牌这种特性，传统BI时代几乎不会被排进优先级，但在Agent大量自动调用数据接口的今天，短生命周期凭证成了基本卫生条件。

这印证了一个判断：当架构大方向（存算分离、湖仓融合、向量融合）逐渐趋同，数据库厂商的差异化会重新回落到工程细节——一次增量刷新省下多少计算、一次去重少买多少内存、一个过期令牌堵住多大的安全口子。对采购方来说，这意味着选型评估要更抠细节：demo跑得再漂亮，也要问清楚增量刷新的边界条件、溢写的性能拐点、令牌的粒度控制。

数据平台的竞争，正在从『讲大故事』进入『抠小账本』的阶段。这不是坏事——泡沫退潮后，工程能力才是硬通货。

把三组动态放回一张图里看：PingCAP和Lakebase回答的是『Agent的持久状态放哪里』，Neo4j回答的是『向量状态怎么省着放』，ClickHouse回答的是『分析状态怎么又快又安全地算』。三个答案拼起来，就是AI时代的数据库命题——为一种会疯狂试错、海量丢弃、全天候运转的机器用户，重建便宜、弹性、可靠的存储底座。

接下来一年值得盯三个信号：存算分离架构下元数据事务的性能表现、向量量化在实际RAG负载中的召回损失、以及限时凭证这类安全特性何时成为各家标配。谁先把这些从博客文章变成生产默认值，谁就真正接住了AI递过来的这张考卷。