Databricks提出评估AI Agent数据库的五项标准
Databricks博客提出用分支隔离、缩容至零、混合搜索、ACID保证和统一平台五项标准来评估AI Agent数据库，并给出Lakebase在各项上的具体表现。
AI解读：Databricks这篇博客的核心主张是：给AI Agent挑数据库不能看功能清单，要看它能不能扛住Agent反复读写、并发操作、跨会话恢复任务的工作负载。文章给出五项评估标准：分支隔离、缩容至零、混合搜索、ACID保证、统一平台。
对开发者最直接的提醒是，Agent不是一问一答的普通应用。它在一次任务里连续读和写、没有人工停顿，同时还有其他Agent在做同样的事。数据库跟不上，就会出现记忆过期、写入冲突、延迟和闲置算力浪费。
文章承认这些标准带有Databricks自家Lakebase的对照，但它把每项的“最低门槛”和“危险信号”写出来了，比如分支创建要秒级、计算恢复要亚秒级、检索要低于100毫秒。按这套标准去比对任何候选数据库，比看宣传页更有可操作性。
普通读者不需要马上行动。真正受影响的是正在把Agent从原型推向生产的开发和数据团队，他们需要提前确认所选数据库在并发写入和实时数据可见性上是否过关。
Databricks博客提出，评估一个用于AI Agent的数据库应看五项标准：分支隔离、无服务器缩容至零、混合搜索、ACID保证和统一平台访问。这些标准用来判断数据库能否支撑Agent从原型进入生产，开始处理并发任务、实时运营数据和持久状态。
文章把AI Agent数据库定义为一个用来存储Agent跨多步骤、多会话完成任务所需的状态、记忆、工具结果和运营数据的系统。与支撑传统应用的数据库不同，它需要支持反复读写、并发Agent活动、跨不同类型记忆的检索，并能访问当前运营数据。
文章列举了生产Agent依赖的四层记忆：短期记忆，即当前交互的上下文工作记忆，包括近期消息、检索到的信息和工具结果；情景记忆，即过去交互，让Agent回忆之前的对话、用户偏好和已完成任务；程序记忆，即指导任务如何执行的工作流、工具定义和指令；运营状态，即任务的实时状态，包括已完成和待完成步骤、工具输出以及用于恢复工作的检查点。
文章认为，大多数生产数据库是围绕一次一个请求的模式构建的OLTP系统，而Agent会在单个任务中连续读取和写入，中间没有人工停顿，同时还有数百个其他Agent在做同样的事。
分支隔离：用真实数据测试而不碰生产
文章建议把“在真实数据上做隔离测试”作为一项数据库评估标准。目标是让Agent在类似生产状态的数据上工作，又无法修改生产数据。一种实现方式是零拷贝分支，开发者无需维护第二份完整数据库副本即可创建独立环境。
文章称Lakebase Projects通过让开发者从生产数据创建分支而不复制底层数据来支持这种隔离开发与测试，分支一个TB级生产数据库约需一秒，在分支与父库产生差异前不额外产生存储成本。
缩容至零：无服务器计费改变Agent经济性
文章引用数据称，云支出每年有27%被浪费，闲置和未充分利用的算力一直是最大驱动因素。Agent数据库是典型例子：大多数Agent不持续运行，它们醒来、执行任务、写入结果，然后安静下来等下一次请求。为专用计算全天候付费，等于为每个Agent数据库的闲置算力持续买单。
无服务器缩容至零模式会在无活跃连接一段时间后暂停计算，工作开始时再恢复，让成本跟随实际使用而非闲置时间。但启动速度同样重要，Agent等数据库唤醒20到30秒并不实用。文章称Lakebase对Postgres采用该模式，新查询后计算可在几百毫秒内恢复。
混合搜索：一次查询检索全部四层记忆
文章用图书管理员打比方：只靠向量搜索，就像只能按“感觉相似”浏览、从不能按索书号精确查找。让它找关于数据库架构的文档表现不错，但让它找账号ID为48291的记录，它没有可靠办法命中，语义相似度并不为精确匹配而设计。
文章称许多RAG流水线在只依赖向量搜索时会遇到这个缺口。混合搜索把向量相似度、关键词匹配和元数据过滤合并在一次查询中，而不是从多个系统拼接结果。若把检索拆到向量索引和关系型存储两个系统，Agent要发两次调用，系统可能不同步，每次额外跳转都会增加延迟。文章称检索需要远低于100毫秒才能在紧凑的推理循环中保持可用。
文章称Lakebase Search在运营数据所在的同一批Postgres表上运行向量、关键词和元数据查询，因此不存在第二个可能失步的系统。其LTAP架构让写入性能最高比标准Postgres快5倍，意味着Agent刚写入的内容几乎可以立即被检索到。
ACID保证：多Agent系统下的并发写入
文章设想两个客服Agent同时更新同一条客户记录：一个在解决账单问题并调整订阅层级，另一个在记录退款。没有适当的隔离，一次更新可能覆盖另一次，留下两者都不想要的状态。因此文章把事务保证列为多Agent工作负载的硬性标准。
文章解释ACID的四个属性：原子性，事务要么完整完成要么完全不发生；一致性，数据库在每次事务前后保持有效；隔离性，并发事务不会以意外方式互相干扰；持久性，已提交的写入在崩溃或重启后仍然存在。
文章称对多Agent系统而言，实际问题比缩写更重要：工具输出能否原子提交，使半完成的动作不会被当作完成；两个Agent更新同一记录时会发生什么；数据库支持哪些隔离级别；Agent重启后能否在不丢失已提交状态的情况下恢复。文章建议比较数据库时实际核查其支持的隔离级别和提交语义，而不只是看它是否声称“支持事务”。
统一平台：运营数据进入AI栈而不经ETL
文章称，Agent等流水线追赶时，就是在用过期数据做决策；等流水线跑完，它操作的记录可能又变了。评估数据库时要看它把运营数据与依赖它的分析和AI系统连接得有多紧密。
统一平台让运营写入和分析读取基于同一份数据，中间没有单独的ETL流水线。Agent可以用当前数据工作，模型可以使用实时结果而不必等批处理任务，数据团队也可以在同一平台保留治理和审计轨迹。文章称Unity Catalog在Databricks中为运营数据和分析数据执行这层治理。
文章引用Superhuman的案例：用统一平台替换进入缓存层和托管NoSQL存储的自定义同步流水线后，其数据集成时间从近三个月缩短到约两周。easyJet在收入管理栈中采取类似做法，文章称其迁移到Lakebase后，在同一湖仓数据上同时捕获实时预订和定价活动与分析，把100多个Git仓库整合为两个，应用开发周期从6到9个月缩短到约4周。文章称Lakebase把运营数据保留在Databricks湖仓中，同一份数据可支持事务工作负载和下游分析，无需单独ETL流水线。
评估记分卡与常见问题
文章给出一个记分卡，把五项标准拆成“测什么、最低门槛、危险信号、Lakebase表现”。分支方面：能否在不完整复制的情况下针对真实生产数据创建隔离分支，最低门槛是分支创建以秒计而非分钟，危险信号是需要完整数据库副本或耗时超过测试周期。缩容至零方面：计算能否在无活动后暂停、恢复速度是否可用，最低门槛是计算在一秒内恢复且无需手动唤醒，危险信号是冷启动超过10秒或闲置数据库仍按全价计费。
混合搜索方面：一次查询能否结合向量相似度、关键词匹配和结构化过滤，最低门槛是单次查询低于100毫秒，危险信号是需要分别调用向量存储和关系型存储再手动合并。ACID方面：两个Agent能否同时写同一记录而不丢失任一写入，最低门槛是无丢失写入且并发负载下隔离性成立，危险信号是静默覆盖或并发下隔离性退化。统一平台方面：一次新写入多久后可被分析使用，最低门槛是无ETL步骤或延迟以秒而非小时计，危险信号是需要先经过调度流水线数据才能在别处查询。
文章在问答部分称，AI Agent需要数据库，因为多数Agent实现不会在多次调用间保留短期上下文、情景历史、程序知识或实时任务状态，除非显式持久化并重新加载；没有数据库，会话一结束Agent通常就丢失上下文，无法从中断处继续。向量数据库本身不够，因为它擅长语义检索，但Agent还需要写入和更新运营状态、在并发写入间强制事务完整性、按结构化字段过滤。
文章称RAG没有唯一的最佳数据库，关键是能在一次查询中运行混合搜索、检索足够快、数据足够新。多Agent系统让事务完整性从可选变为必需。文章还区分OLTP和OLAP：Agent的实时动作、写工具输出、更新状态和检查点属于OLTP，报告和模型训练属于OLAP，Agent通常需要两者基于同一份数据且中间没有流水线。关于Postgres，文章称标准Postgres提供可靠的ACID保证和成熟生态，覆盖Agent需求的一部分，但本身不提供零拷贝分支、缩容至零计算或运营与分析统一访问，这些取决于围绕它构建的平台。