Agentic AI 架构为何需要数据库，不只是向量存储

关键要点

• 智能体AI架构有五个层次：推理、工具、记忆、状态和护栏。框架处理前两个；你的存储选择处理后三个。
• 向量搜索仅解决语义检索问题。它不提供权威记录、持久的工作流状态或事务性更新。
• 生产级智能体存储的远不止嵌入：结构化事实、执行状态、工具结果和审计日志。
• 分布式SQL在一个系统中统一了这些需求，消除了同步管道，并保持检索的新鲜度。

智能体AI架构是一种系统设计，使AI智能体能够感知上下文、进行推理、调用工具、维护记忆，并在多个步骤中采取行动。它涵盖模型、编排层以及使智能体的工作持久而非一次性的数据基础设施。

大多数团队正确选择了模型和框架，但仍然看到他们的智能体在生产中失败。失败点很少是推理质量，而是数据：崩溃后状态丢失、检索时上下文过时，或者让向量存储承担事务性数据库的工作。这篇博客深入探讨了智能体AI架构的核心层次，解释了仅向量存储在哪些方面失效，并为架构师提供了在选择智能体数据基础时的实用框架。

什么是智能体AI架构？

智能体AI架构是系统的结构，其中AI智能体感知环境、推理目标、使用工具、维护记忆，并在多个步骤中自主行动。与单一提示-响应调用不同，智能体系统在步骤之间保持上下文，并协调触及真实业务系统的操作。

最后一点是架构之所以重要的原因。演示智能体回答问题后即消失。生产智能体更新CRM记录、打开支持工单、检查审批状态，并在第二天从今天中断的地方继续同样的任务。这些步骤中的每一步都读取或写入必须能在进程重启、并发访问和审计中存活的数据。

许多团队错过的转变是：智能体系统既是数据系统，也是模型系统。模型提供推理能力，但周围的架构决定了智能体的工作是否正确、持久和可观测。演示级智能体可以在上下文窗口中保留一切。生产级智能体需要权威记录、工作流状态和检索基础设施，其保障要与任何其他关键业务应用相同。

本文的其余部分将像架构师在评审设计时那样对待智能体AI架构：逐层进行，并明确注意每层数据实际存储的位置。

智能体AI架构的核心层次

对于智能体AI架构，一个有用的心智模型包含五个层次：推理、工具、记忆、状态和护栏。LangGraph、CrewAI和OpenAI Agents SDK等框架为前两个提供脚手架。后三个是大多数生产事故的源头，因为它们依赖于框架无法为你做出的存储决策。

表1：智能体AI架构的五个层次及其存储要求。

推理与规划

推理层将目标分解为步骤并决定下一步做什么。框架处理循环，但计划本身是数据。如果智能体处理一个九步骤的任务，而进程在第六步死亡，计划及其进度需要存在于进程内存之外的地方。否则智能体将从零开始，且任何已完成的非幂等步骤将执行两次。

记忆与检索

记忆分为语义召回（通过相似性找到相关先前上下文）和事实召回（查找精确记录：用户的计划层级、订单ID、先前决策）。向量搜索擅长前者。后者需要带有过滤器和新鲜度保证的结构化查询。生产设计将这两个视为同一问题的两个访问模式，这就是为什么AI智能体记忆与状态架构日益趋向于统一的持久存储，而非拼凑的组件。

行动、编排与护栏

当智能体对真实系统采取行动时，每个工具调用都成为一条记录：调用了什么、输入什么、返回什么、谁批准的。人工参与的审批门、权限检查和审计跟踪都依赖于一致且可查询的写入。无法审计的智能体是无法在受监管环境中部署的。

为什么向量存储不足以支撑智能体AI架构

向量存储不足以支撑智能体AI，因为它只解决一个问题：语义检索。而生产智能体还需要权威记录、持久的工作流状态、并发控制和事务性更新。这些都不是向量索引的构建目标。

这不是对向量数据库的否定，而是范围观察。

向量数据库擅长什么

向量数据库对嵌入进行索引，并能快速回答最近邻查询。对于文档语料库上的检索增强生成（RAG），这正是其用武之地。当问题是“哪些存储的内容与此查询最相似？”时，它们表现出色。比较向量数据库与关系数据库归根结底在于：一个按相似度排序，另一个保证精确记录的正确性。

仅向量堆栈失效之处

考虑一个工作智能体一个下午产生的数据：

• 一次工具调用返回客户当前的订阅层级。这是一个需要精确存储的事实，而不是嵌入并近似检索。
• 一个任务检查点标记七个步骤中的第四步已完成。如果两个智能体实例并发读写它，你需要事务隔离，而不是最终相似性。
• 一个用户偏好（“合同邮件始终抄送法务”）必须每次都应用，而不是偶然排在前k个结果中才出现。
• 一个审批状态从待处理变为已批准。智能体必须立即看到新值，而不是旧值的陈旧嵌入。
• 审计日志需要有序、可过滤、防篡改的记录以供合规审查。

强制这些通过纯向量设计，你会得到熟悉的失败模式：智能体基于陈旧事实行动、因不同步状态产生重复副作用，以及无法重建智能体实际行为的合规审查。

拆分堆栈仍合理之时

当用例是狭窄的RAG管道、语料库是静态或缓慢变化、且事务数据库已持有操作数据时，独立向量存储是合理的选择。在这种设置中，向量存储是搜索索引而非记录系统，架构保持诚实。问题始于团队将搜索索引提升为智能体的主要记忆和状态层。

生产智能体实际需要存储什么数据

生产智能体存储的远不止嵌入。现实清单包括对话历史、向量嵌入、结构化事实、执行状态、工具调用结果、实体关系和可观测性日志。每种都有不同的访问模式，将它们合并到一个通用的“记忆”桶中是架构出错的方式。

短期记忆和会话上下文

短期记忆是实时会话的工作上下文：最近的轮次、活动任务参数和临时结果。它以低延迟被不断读写，并且会过期。在多租户SaaS产品中，它还必须按租户隔离，这样一位客户的会话上下文永远不会泄漏到另一位客户的检索中。

长期记忆和结构化知识

长期记忆跨会话持久化：用户偏好、习得事实、实体关系和总结历史。这是语义世界和结构化世界交汇之处。支持自动化智能体需要对过去的解决方案进行相似性搜索，并对客户当前的权益进行精确连接。将它们存储在不同系统中意味着永远同步它们；将它们存储在一起意味着一个查询计划可以使用两者。

多步骤工作流的持久状态

工作流状态既非记忆类型。它是进行中工作的事务记录：哪些步骤完成、每个工具返回了什么、什么等待人工批准。一个提供账户的内部运营助手，或一个发放退款的支持智能体，不能将此视为尽力而为的数据。状态写入需要原子性，读取需要反映最新的已提交值，尤其当多个智能体共享工作流时。

如何为智能体AI架构选择合适的数据库

通过六个标准对候选方案评分来选择智能体AI数据库：事务保证、向量搜索旁的元数据过滤、检索时操作数据的新鲜度、读写横向扩展、多租户隔离，以及总操作复杂度。正确答案取决于工作负载形态，而非供应商类别。关于这些标准如何在实际架构中发挥作用的深入探讨，请参阅我们的智能体AI数据架构报告。

现实选项分解如下：

• 单节点关系数据库提供强事务和现在基本的向量支持，但随着智能体流量增长会达到写入上限，分片成为你的问题。
• 专用向量数据库提供出色的相似性搜索，但将状态、事实和事务推到第二个系统上，你必须保持同步。
• 混合架构（关系加向量加缓存）可行但增加了操作表面：更多同步管道、更多一致性缺口、更多故障模式。
• 分布式SQL数据库结合事务保证和横向扩展，当前一代添加了原生向量索引，这为许多智能体工作负载简化了堆栈。

单智能体系统的数据库需求

服务单个工作流的单智能体通常可以从熟悉的带向量扩展的关系数据库开始。早期重要的评估标准是元数据过滤（向量搜索受租户、日期或类型约束）和数据新鲜度，因为即使一个智能体也会因陈旧事实而表现糟糕。

多智能体系统的数据库需求

多智能体系统显著提高了门槛。智能体共享状态、交接任务并并发写入，这使得事务隔离不可谈判。负载也停止可预测：智能体群产生突发、机器速度的读写流量，单个主节点无法吸收。决定此是否可行的架构决策在本指南中深入覆盖，关于扩展AI智能体架构。

为什么分布式SQL适合增长中的智能体工作负载

分布式SQL数据库正是为这种组合而构建的：并发写入下的事务正确性、无需手动分片的水平扩展，以及每个框架都已支持的SQL查询接口。当同一系统还能索引向量并对新鲜数据提供分析查询时，代理的整个数据足迹就都容纳在一个地方。

TiDB在代理式AI架构中的位置

TiDB是一个分布式SQL数据库，为代理式系统提供统一的基础，用于结构化数据、向量搜索、实时分析和强一致状态。对于上述架构，这意味着更少的移动部件和更少的同步接缝，从而避免正确性悄然流失。

内存、状态和检索的统一存储

TiDB将代理的结构化事实、工作流状态、对话历史和向量嵌入存储在一个兼容MySQL的数据库中。单个查询可以按租户过滤、针对当前权限进行联接，并按向量相似度排序，从而消除了在事务存储和搜索索引之间传输数据的管道。设计代理式AI系统架构的团队将获得一个一致性模型，而不是三个。

使用分布式SQL和HTAP实现实时上下文

TiDB的HTAP（混合事务/分析处理）架构在实时事务数据上提供分析查询。对于代理而言，这意味着检索能够反映刚刚发生的事情：几秒前下的订单、工作流中刚批准的请求。记录系统和代理读取的系统之间没有CDC延迟。

企业团队的运维简化

水平扩展性可处理流量不均匀增长的代理集群，而TiDB Cloud上的云原生部署将运维负担从平台团队中解放出来。实际结果是，从原型到生产的路径更短：试点运行的数据库就是企业工作负载扩展的数据库。

评估代理式AI数据架构的检查清单

在架构审查和供应商评估中使用此检查清单。每个“否”都是未来的事故：

• 状态持久性：代理检查点和工具结果在进程崩溃和重启后是否仍然存在？
• 语义检索质量：向量搜索是否支持您需要的嵌入模型和召回率？
• 元数据过滤：相似性搜索能否在单个查询中按租户、时间和记录类型进行约束？
• 新鲜度：检索结果是否反映最新的已提交写入，而不是同步管道的延迟？
• 事务完整性：并发代理能否更新共享状态而不会出现损坏或重复？
• 租户隔离：一个客户的记忆是否可证明对另一个客户的代理不可见？
• 可审计性：您能否按顺序重建代理采取的每个操作，包括输入和输出？
• 可观测性：您能否无需导出到另一个系统即可查询代理行为进行调试？
• 基础设施蔓延：设计需要多少个不同的系统以及它们之间的同步任务？

在能够随代理增长的数据库上构建代理式AI系统

向量搜索是代理式AI架构的必要组成部分，但它只是一种检索模式，而不是数据基础。生产代理需要持久状态、权威事实、事务协调和新鲜上下文，而从一开始就将这些需求视为一等公民的团队可以避免成功试点后随之而来的痛苦的重构平台。

如果您现在正在设计该基础，TiDB值得评估，作为用于代理式AI的分布式SQL数据库，它在一个系统中统一了内存、状态和检索。

Brian Foster是TiDB的全球内容总监。他在技术内容、出版和编辑领导方面拥有超过20年的经验，专注于分布式SQL、云基础设施和软件开发领域的故事讲述和内容创作。

由TiDB AI产品主管Xin Shi审核，以确保技术准确性。

最后更新：2026年8月7日。

本文参考了PingCAP关于TiDB和TiDB Cloud的产品文档、O'Reilly关于代理式AI数据架构的报告，以及Google Cloud、IBM和Neo4j关于代理式系统组件的已发布架构指南。

代理式AI架构常见问题解答

代理式AI架构和RAG架构有什么区别？

RAG（检索增强生成）架构是一种检索模式：获取相关内容，添加提示，生成答案。代理式AI架构是围绕自主代理的完整系统，包括推理、工具、内存、状态和护栏。RAG通常是代理系统内的一个组件，为内存层的检索部分提供动力。

向量数据库能单独处理代理内存吗？

不能。向量数据库处理语义召回，这是代理内存的一部分。代理还需要确切的结构化事实、持久的工作流状态和并发下的事务更新，而相似性搜索这些都不提供。仅向量的内存会产生基于过时或近似信息行动的代理。

什么数据库最适合代理式AI架构？

最佳数据库取决于工作负载：事务保证、带元数据过滤的向量搜索、数据新鲜度、扩展能力和租户隔离是重要的标准。统一选项（如原生支持向量的分布式SQL数据库）可降低同步复杂性；分离堆栈将事务数据库与专用向量存储配对，但代价是持续的同步。

多代理系统需要共享状态吗？

是的。多代理系统通过共享状态进行协调：任务交接、进度检查点以及一个代理产生供另一个代理消费的结果。没有事务一致的共享状态，并发代理会重复工作、相互覆盖，或因任务所有权不明确而陷入死锁。

团队应如何评估代理式AI框架？

评估框架时，要关注编排的易用性：规划循环、工具接口以及多智能体协调模式。然后单独评估数据层，因为框架会将持久化状态、记忆存储和事务安全委托给你附加的任何存储系统。一个框架即使再强大，如果数据层薄弱，在生产环境中依然会失败。

这篇文章《为什么智能体AI架构需要数据库，而不仅仅是向量存储》首次出现在TiDB上。