Database for AI Agents: 5 Evaluation Criteria

AI 代理数据库：5 个评估标准 | Databricks 博客

跳至主要内容

数据 + AI 基础

AI 代理数据库：5 个评估标准

了解评估 AI 代理数据库的 5 个标准 —— 分支隔离、无服务器扩展、混合搜索、ACID 保证和统一访问。

作者：Databricks 员工

摘要

• AI 代理需要支持跨多种内存类型进行持续并发读写操作的数据库 —— 而不是传统应用使用的逐个请求模式。

• 五个标准定义了生产就绪的代理数据库：按代理分支隔离、零计算扩展、单次查询混合搜索、并发下的 ACID 保证，以及无 ETL 延迟的统一平台。

• Databricks 的 Lakebase 符合每个标准，并通过 Superhuman 和 easyJet 的实际验证。

评估 AI 代理数据库的五个标准是分支隔离、无服务器扩展、混合搜索、ACID 保证和统一平台访问。这些标准共同帮助开发人员和数据团队判断数据库是否能支持代理从原型到生产环境的过渡，并开始处理并发任务、实时运营数据和持久化状态。

AI 代理数据库是一种专为存储代理完成多步骤和多会话任务所需状态、内存、工具结果和运营数据而设计的系统。与服务于传统应用的数据库不同，它需要支持重复读写、并发代理活动、跨不同类型内存的检索，以及对实时运营数据的访问。

AI 代理的兴起使这些需求变得更加重要。当开发人员运行代码代理、客户支持代理或多租户平台时，代理的作用不再局限于信息检索。它们会写入状态、恢复任务、协调工具调用，并根据变化的运营数据采取行动。当数据团队将代理部署到生产环境时，数据库的限制可能导致内存过时、写入冲突、延迟和不必要的计算成本。

为什么 AI 代理数据库不是同一个问题

一个生产就绪的代理需要记住自己已经完成的操作，在中断后继续任务，并在行动前获取正确的上下文。如果搭配错误的数据库，这些记忆可能会变得过时、不完整或不一致。

生产环境中的代理依赖四层内存来实现这一点：

• 短期记忆：当前交互期间可用的上下文工作内存，包括最近消息、检索信息和工具结果。

• 事件记忆：过去的交互记录，使代理能够回忆早期对话、用户偏好和已完成任务。

• 程序记忆：指导任务执行的工作流程、工具定义和指令，无论它们是存储在外部还是内置在模型中。

• 运营状态：任务的实时状态，包括已完成和待处理步骤、工具输出以及后续恢复工作的检查点。

这比典型应用的工作负载更复杂，典型应用会向数据库发送查询然后继续执行。大多数生产数据库是运营数据库，也称为在线事务处理（OLTP）系统，它们围绕相同的逐个请求模式构建。代理的工作方式不同。在一个任务中，它会连续执行读写操作，没有人为暂停，而数百个其他代理同时也在执行相同的操作。

评估任何AI代理工作负载数据库的5个标准

在为AI代理选择数据库时，有多个标准需要考虑，但以下五个标准无论选择哪家供应商（托管或自托管）都值得评估。

每个代理的分支：使用真实数据进行安全测试

仅使用合成数据测试代理，就像用少量格式完美的客户账户测试支持系统。它可能表现得完全符合预期，但真实账户总是更加混乱。数据团队最终会遇到缺失字段、记录不一致、旧数据和测试用例中从未包含的边缘情况。

因此，我们建议将对真实数据的隔离测试作为数据库评估标准之一。目标是让代理在接近生产环境的状态下运行，但又不能让它修改生产数据。实现这种隔离的一种方法是零拷贝分支，它允许开发人员创建一个独立环境，而无需维护数据库的第二个完整副本。

Lakebase Projects通过让开发人员从生产数据创建分支而无需复制底层数据，专门设计用于处理这种隔离式开发和测试。对TB级规模的生产数据库进行分支操作仅需约1秒，且在分支与父分支发生分歧前不会产生额外存储成本。

扩展至零：无服务器定价如何改变代理经济模式

每年有27%的云支出被浪费，而闲置和利用率低的计算资源始终是造成浪费的最大原因。代理数据库是这一问题的典型案例。大多数代理不会持续运行，它们会唤醒、执行任务、写入结果，然后在下一次请求到来前保持静默。全天候支付专用计算资源意味着要为每个代理数据库的闲置计算问题付费。

无服务器扩展至零模型通过在一段时间内没有活跃连接后暂停计算，并在工作重新开始时恢复计算来解决这一问题。这使成本能够跟踪实际使用情况而非闲置时间。不过启动速度同样重要。如果代理需要等待20或30秒才能唤醒数据库，这在响应用户或等待下一个工具调用时显然不切实际。

Lakebase对Postgres采用这种模型，新查询触发后计算资源可在几百毫秒内恢复。这使启动延迟足够小，能够满足交互式代理工作负载的扩展至零需求。

混合搜索：在一个查询中跨所有四层内存进行检索

单独的向量搜索就像一个只能通过"感觉相似"来浏览的图书管理员，永远无法通过精确的书号定位。让它查找关于数据库架构的文档时表现良好，但让它查找账户ID为48291的记录时却无法可靠定位。语义相似性并不是为精确匹配设计的。

这就是许多依赖向量搜索的检索增强生成（RAG）流水线遇到的差距。混合搜索通过在一个查询中结合向量相似度、关键字匹配和元数据过滤来弥补这一差距，而不是从不同系统中拼接结果。如果将数据拆分到向量索引和关系型存储中，代理需要进行两次调用而非一次。系统可能逐渐不同步，而每个额外的跳转都会增加代理循环无法完全吸收的延迟。为了在紧密的推理周期内保持可用性，检索需要在100毫秒内完成。

Lakebase Search 对同一张 Postgres 表同时执行向量、关键字和元数据查询，这些表中已经存储了业务数据，因此无需担心与第二个系统不同步的问题。其 LTAP 架构确保了数据的实时性，写入性能达到标准 Postgres 的 5 倍。这意味着代理刚刚写入的数据几乎可以立即被检索到。

多代理系统的 ACID 保证

设想两个客服代理同时更新同一份客户记录。一个正在处理账单问题并调整订阅层级，另一个正在记录退款信息。如果没有适当的隔离机制，一个更新可能会覆盖另一个，导致记录状态偏离两个代理的预期。

这正是为什么在评估多代理工作负载的数据库时，事务保证应作为硬性标准。ACID 为开发者提供了四个关键特性：

• 原子性：事务要么完整执行，要么完全不执行。
• 一致性：每次事务前后数据库状态都保持有效。
• 隔离性：并发事务不会以不可预见的方式相互干扰。
• 持久性：提交的写入操作在崩溃或重启后仍能保留。

对于多代理系统，实际问题比 ACID 缩写本身更重要。工具输出能否原子性提交，确保未完成的操作不会被误认为已完成？当两个代理同时更新同一记录时会发生什么？数据库支持哪些隔离级别？代理在重启后能否恢复已提交的状态而不丢失数据？

在比较数据库时，我们建议实际检查其支持的隔离级别和提交语义，而不仅仅是看是否声称“支持事务”。一旦多个代理共享业务数据，这些细节将决定并发操作是否保持可预测性。

统一平台：AI 堆栈中无需 ETL 的业务数据

等待数据管道追上进度的代理正在基于过时数据做决策。当管道运行时，它操作的记录可能早已再次变更。在评估数据库时，应关注其如何紧密连接业务数据与依赖它的分析和 AI 系统。

统一平台通过消除中间的抽取-转换-加载（ETL）流程，使业务写入和分析读取操作在相同数据上进行。代理可以使用实时数据，模型可以利用即时结果而非等待批量任务。数据团队也能在同一平台中维护治理和审计追踪，而非将代理工作负载推送到更难追踪的独立系统。Databricks 的 Unity Catalog 负责在业务数据和分析数据之间强制实施这一治理层。Superhuman 的实践展示了统一平台的效果：将自定义同步管道和缓存层、托管 NoSQL 存储替换为统一平台，使其数据集成周期从近三个月缩短至约两周。

easyJet 在其收入管理系统中采用了类似方法。自迁移到 Lakebase 后，这家航空公司实现了在相同湖仓数据上同步实时预订和定价活动与分析，将超过 100 个 Git 仓库整合为两个，并将应用程序开发周期从 6 至 9 个月缩短至约 4 个月。

Lakebase 将操作数据存储在 Databricks 湖仓中，因此相同的数据可以同时支持事务性工作负载和下游分析，无需单独的 ETL 管道。

报告

企业的智能体 AI 实施指南

立即阅读

AI 代理数据库评估评分卡

对任何候选数据库进行这五个检查，你可以在几分钟内判断出它在哪些方面表现良好、哪些方面存在不足，无论你正在比较的是哪家厂商。

标准

测试内容

最低要求

警示信号

Lakebase 表现

按代理分支

能否在真实生产数据上创建一个隔离分支，而无需进行完整复制？

分支创建在数秒内完成，而非数分钟

需要完整数据库复制，或耗时超过测试周期

分支

可在约一秒内创建千兆字节级数据库，且在分支发散前无存储成本

零规模扩展

在一段时间无活动后，计算资源能否暂停并在恢复时足够快速以保持可用性？

计算资源在一秒内恢复，无需手动唤醒步骤

冷启动耗时 10 秒以上，或空闲数据库仍按全额计费

暂停时自动恢复，恢复时间在数百毫秒内，暂停期间不产生费用

混合搜索

能否在一个查询中结合向量相似性、关键字匹配和结构化过滤？

单个查询，耗时低于 100 毫秒

需要分别调用向量存储和关系型存储，然后手动合并结果

对同一 Postgres 表执行向量、关键字和元数据查询

ACID 保证

两个代理能否同时写入同一记录而不会丢失任一写入？

无写入丢失；并发负载下保持隔离性

静默覆盖，或并发时隔离性下降

标准 Postgres 事务保证，不受并发代理负载影响

统一平台

新写入操作需要多长时间才能供分析使用？

无需 ETL 步骤，或延迟以秒为单位而非小时

需要在数据可查询前设置计划管道

所有写入操作均可在 Databricks 湖仓中直接查询，无需单独管道

如果数据库在这些最低标准中失败超过一项，在大规模运行代理时将构成生产风险，而不仅仅是可后期规避的小问题。

总结

为 AI 代理选择数据库的关键在于工作负载适配性，而非功能列表。本指南中的五个标准为开发人员和数据团队提供了一个实用框架，用于在投入生产前评估任何数据库。如果候选数据库目前无法满足这些要求，随着代理承担更多用户、更多任务和更多并发工作，生产环境中的代理最终将暴露这些差距。

如果你正在评估 AI 代理的数据库，可以探索 Lakebase，了解 Databricks 如何支持事务性工作负载、分支管理、无服务器扩展、混合搜索以及对操作数据的统一访问。

常见问题

AI 代理是否需要数据库？

是的。大多数代理实现除非显式持久化并重新加载，否则不会在调用之间保留短期上下文、事件历史、过程知识或实时任务状态。如果没有数据库支持，代理通常会在会话结束时立即丢失这些上下文，并且无法从中断处继续任务。

向量数据库是否足以支持 AI 代理？

单靠它本身并不够。向量数据库在处理语义检索方面表现优异，但你的代理还需要能够编写和更新操作状态、在并发写入时强制执行事务完整性，并在结构化字段上进行过滤——这些是相似性搜索无法可靠完成的。语义搜索仅覆盖代理所需功能的一部分，而非全部工作负载。

AI代理中RAG的最佳数据库是什么？

没有标准答案。对于AI代理中的RAG，最佳数据库是能够在单个查询中执行混合搜索、保持足够的检索速度以满足代理循环需求，并保持数据更新以避免记忆过时的数据库。

多代理系统如何改变数据库需求？

当多个代理同时向共享数据写入时，事务完整性不再是可选功能。你的数据库需要隔离并发写入，确保一个代理的更新不会无声地覆盖另一个代理的更改，同时需要以原子方式提交工具输出，防止未完成的操作被误判为已完成。

AI代理中OLTP和OLAP的区别是什么？

代理的实时操作、工具输出写入、状态更新和进度检查点属于OLTP工作负载。基于这些数据的报表和模型训练属于OLAP工作负载。代理通常需要同时使用这两种工作负载，且无需在它们之间建立数据管道。这就是为什么本指南的标准侧重于能够同时支持高事务负载的代理操作和下游分析的数据库。

标准PostgreSQL提供了可靠的ACID保证和成熟的生态系统，覆盖了代理所需功能的一部分。但它本身不提供零拷贝分支、可扩展到零的计算能力或统一的操作与分析访问，这些功能依赖于围绕它构建的平台。

订阅获取最新文章

订阅我们的博客，将最新文章直接发送到你的邮箱。

立即订阅

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"