完整Agent状态栈：内存、文件与Serverless数据库持久化

关键要点

• 无服务器数据库可扩展至零，并按使用量计费，匹配突发性代理流量。
• AI应用需要四个持久化层：内存、文件、操作状态和检索数据。
• 评估引擎而非标签。连接行为和冷启动最为重要。
• 碎片化堆栈累积。一个引擎消除系统边界和一致性错误。

无服务器数据库是一种完全托管的数据库，可根据需求自动扩展计算和存储，无需预置服务器或容量规划，且仅按实际使用计费，空闲时可扩展到零。提供商负责基础设施；你负责数据。

该定义涵盖了该类别。但并未涵盖2026年大多数团队实际面临的问题：AI应用不仅需要数据库，还需要为整个状态栈提供持久化，包括代理记忆、生成的文件、操作数据和检索索引。通用云数据库解决一层问题，其余留给胶水代码。

本指南面向从演示转向生产的软件架构师、平台工程师和AI构建者。目标是解释什么是无服务器数据库，为什么该模型特别适合AI工作负载，以及如何根据完整的代理状态栈（内存、文件、SQL状态和向量检索）评估数据库，而不是孤立地针对单一工作负载。

什么是无服务器数据库，为什么它现在很重要？

无服务器数据库完全抽象了机器。你无需选择实例大小、预置副本或预测容量。你连接、读取和写入；平台在后台分配计算资源，并按你的消费量收费。

定义该类别的核心特征包括：

• 托管运维：修补、复制、故障转移和备份是提供商的工作。
• 弹性计算：容量随负载扩展和收缩，无需人工干预。
• 扩展到零：空闲期间计算挂起，因此你不再为沉默付费。
• 基于使用的经济性：计费跟踪请求、存储和计算消耗，而非预留容量。

现代无服务器架构通常将计算与存储解耦：数据存放在持久的共享存储层中，而无状态计算节点按需启动。这种分离使得弹性扩展和扩展到零成为可能，而不会危及数据本身。

这个概念现在更重要，因为AI原生和事件驱动应用正好具有无服务器设计的流量特征：不可预测的突发、长时间空闲以及没有可靠的基线可供预置。为100倍峰值然后休眠的工作负载预留固定容量，是云账单出错的原因。

为什么该术语仍被误解

“无服务器”并不意味着无需服务器。服务器存在；只是你从未见过。该术语描述的是运营契约，而非架构图：提供商拥有基础设施决策，你仅通过数据库协议交互。团队有时会认为“无服务器”意味着有限、玩具级系统。并非如此。分布式SQL数据库可以以无服务器方式运行；部署模型和引擎能力是独立的问题。

为什么无服务器数据库适合AI状态的现实

AI应用产生了特定的持久化问题，首先是流量形状。代理工作负载是突发性的：用户启动任务，代理在几秒内分支为数十个工具调用，然后静默数小时。开发环境整夜闲置，测试时爆炸。预置数据库迫使你全天候为峰值付费；无服务器持久化只为突发付费，其余不收费。

问题的另一半是什么需要持久化。称之为AI状态：AI应用或代理必须保留的结构化操作数据，以在会话间保持有用和一致。包括对话历史、用户偏好、工具输出、中间结果、任务状态和租户元数据。

以下是状态未正确持久化时的崩溃方式。支持代理解决客户的运输问题，将上下文保存在提示窗口和本地缓存中。会话结束，容器回收，缓存消失。客户第二天回来，代理将其视为陌生人，重新询问已回答的问题。没有崩溃，但产品失败了，因为状态驻留在临时层而不是持久的数据库中。

会话状态、工具输出和内存不是一回事

这三者经常被混淆。会话状态是实时交互的工作上下文：代理当前正在做什么。工具输出是代理所做的事情的记录：API响应、查询结果和值得审计的文件操作。内存是应该在会话间存续的内容：提炼的偏好、摘要和事实。它们具有不同的生命周期、访问模式和一致性要求。将它们视为一个整体是大多数原型犯的第一个架构错误。

为什么突发性代理工作负载奖励弹性持久化

单个代理任务可以在短时间内触发数十次读取和写入：获取内存、记录工具调用、更新任务状态、写入结果。乘以并发用户，负载曲线看起来就像地震仪。弹性计算吸收峰值；扩展到零吸收静默。无服务器经济几乎与代理的实际行为一一对应。

完整代理状态栈中应该包含什么？

当团队为AI应用规划持久化时，他们通常计划一两层，然后在生产中发现其他层。完整的代理状态栈有四个：

表1：智能体状态栈的四层及每层范围不足时会出现的问题。

原型对这些层范围不足是有原因的：演示不需要它们。单会话智能体配上单个用户，可以把一切保持在上下文和临时目录中。只有会话增多、用户回归、有人问“上周二智能体为什么那样做？”时，这些缺口才会显现。

用于偏好、摘要和连续性的记忆

记忆是用户感受最直接的层。它很少是原始转录，而是提炼后的：“喜欢简洁的回答”，“在柏林时区工作”，“最近三个项目涉及计费服务”。好的记忆设计将这些存储为结构化、可查询、有来源的记录，而不是不断增长、附加到每次提示的文本文件。

用于智能体工作流的文件和工件

编程智能体生成代码仓库。研究智能体生成报告。自动化智能体生成电子表格和配置。这些工件是实际工作成果，需要持久、版本化的存储，并与应用其余部分使用相同的身份和租户模型关联，而不是孤立的、与生成数据无关的对象存储桶。

用于活动应用逻辑的结构化状态和检索数据

运行状态是正确性所在：哪些任务在运行、哪些工具调用成功、哪个租户拥有哪条记录。这是事务性领域：智能体重复执行支付或中途丢失任务，是生产事故，而非怪癖。检索数据与之并列：使记忆和文档能按含义搜索的向量嵌入，理想情况下不脱离同一引擎。

AI应用应如何随时间持久化记忆、文件和状态？

组织原则是区分热上下文与持久存储。热上下文是当前模型窗口内能容纳的内容，对每个请求临时组装。持久存储是应用所有不能丢失的东西：聊天记录、用户偏好、摘要、工具调用历史、生成文件、工作流定义、租户元数据，以及排列这些的所有时间戳。上下文窗口是缓存；数据库是真相。

不同类型的状态也有不同的检索模式。偏好是按用户ID精确查找。记忆搜索是语义的：“我们对这个客户的部署了解多少？”任务状态是事务性的读-修改-写。文件通过引用流式访问。错误不在于认识到这些差异，而在于让每种模式各自独立系统，直到架构成为五个互相矛盾的存储联合体。

工作上下文与持久状态

提示中的一切应能从数据库重建。如果失去上下文窗口就永久丢失信息，那信息就放错了地方。这一规则能在原型期捕获大多数持久化缺陷，使其不进入生产。

可搜索记忆与精确事务数据

语义搜索找到相关记忆；但绝不应是回答“这笔支付成功了吗？”的机制。精确状态需要具有事务一致性的精确查询。将一切路由到向量存储的架构最终会近似本应确定的事实。一个AI智能体记忆数据库需要对同一数据同时具备两种检索模式。

为什么文件需要自己的持久化策略

文件体积大、版本化、按引用访问而非查询。务实模式是在数据库中存储文件元数据、所有权和血缘（与运行状态一起事务性地存储），而内容则存放在为对象而建的存储中。关键是两者保持关联：无法追踪到创建它的任务和租户的文件是责任，不是工件。

什么成就智能体应用的最佳无服务器数据库？

没有单一赢家；诚实的答案是按工作负载加权的评估标准集合。对于智能体应用，六个标准反复出现：

• 连接模型：智能体打开许多短连接；数据库需要承受这种模式，而无需连接池辅助项目。
• 冷启动特征：挂起计算唤醒有多快，第一个查询会付出可见代价吗？
• 结构化状态支持：完整SQL和ACID事务，还是保障较弱的文档模型？
• 向量支持：原生向量类型和索引，还是迫使引入第二系统的附加组件？
• 治理：应用变为多用户时的租户隔离、访问控制和审计能力。
• 生态兼容性：它是否说着你的ORM、框架和智能体SDK已经理解的协议？

正确的权重取决于应用。对于没有事务逻辑的单用户工具，轻量文档存储可能就够。一旦应用需要SQL一致性、多租户隔离或带元数据过滤的检索，标准就提高了。

连接行为比多数团队预期的更重要

无服务器函数和智能体运行时造成连接风暴：突发期间数百个瞬态客户端同时连接。为固定长连接池设计的数据库先在这里倒下。优先评估连接多路复用；这是团队在生产中发现的失败模式，而非演示中。

Moonshot AI团队在Kimi智能体平台展示了曲线末端的情况。每个租户站点都有自己的数据库，这使得引擎的连接和唤醒行为与产品体验无法区分。团队报告称，在单个TiDB集群上运行数千万个并发租户站点，且预配时间低于一秒，数据基础设施成本降低了一个数量级，同时对代理来说更重要的是：无需回收、无休眠暂停、无会话中断。从代理的视角来看，数据库始终就在那里。

这是在评估中值得测试的区别。许多平台都打着无服务器的标签，但很少有平台能为每个租户维持这种行为。当空闲租户被回收或休眠时，唤醒代价恰好落在代理依赖的长尾会话上，而分层的服务级别就变成了分层的用户体验。

结构化数据、向量和检索不应各自分离

当嵌入存储在一个系统中，源记录存储在另一个系统中时，每次写入都成为同步问题。删除的文档残留在索引中；更新的记录返回过时的搜索结果。将用于AI应用的向量搜索与它所描述的结构化数据放在同一引擎中，消除了整类一致性错误，这是选择最佳AI应用向量数据库时的关键标准。用于AI应用的向量搜索与它所描述的结构化数据放在同一引擎中，消除了整类一致性错误，这是选择最佳AI应用向量数据库时的关键标准。最佳AI应用向量数据库。

为什么开放标准降低迁移和锁定风险

一个说标准协议（如通过MySQL wire协议的SQL）的无服务器数据库，可以保持较低的退出成本并拥有庞大的工具生态系统。专有API在价格变化、出现限制或需求超出平台之前都没问题。开放标准将重写转化为迁移。

AI应用的无服务器持久化有哪些权衡？

无服务器持久化并非没有权衡，如实评估这些权衡是做出正确选择的一部分。

反复出现的缺点：冷启动为闲置后的第一个请求增加延迟。连接风暴可能在计算限制之前就触及提供商限制。按使用量计费使得失控的代理在没有护栏的情况下变成失控的账单。提供商配额（请求大小、连接数、存储上限）以预留容量不会的方式限制设计。并且，将文件、向量和SQL状态混合在独立的Serverless产品中，会将这些问题的数量乘以所涉及的系统数。

一个通用的Serverless数据库可以完美适配普通Web工作负载，但可能仍然无法满足代理系统，通常是因为它覆盖了操作状态层，而将内存、文件和检索留给了其他服务。类别标签告诉你计费模式，而不是引擎是否覆盖你的状态栈。

冷启动和唤醒代价

缩放到零意味着空闲后的第一个查询可能需要等待计算资源恢复。对于交互式代理，请根据用户体验预算评估唤醒延迟，并检查平台是否可以为延迟敏感路径保持温暖池。

代理展开操作时的成本控制

一个有缺陷的代理循环可以无限期地每分钟发出数千个查询。按使用量计费使其迅速变得昂贵。支出上限、每租户配额以及监控哪个代理产生了哪种负载是硬性要求，而非可有可无。

跨太多持久化层的操作蔓延

每增加一个持久化系统，就意味着一套新的凭据、一种新的故障模式、一个同步作业以及账单上的一行。对任何单个Serverless产品的权衡分析都应包括它迫使你并行运行的系统。

随着技术栈增长，没有TiDB构建的情况

考虑一个从原型开始的支持代理：一位开发人员，一个用于聊天日志的文档存储，本地磁盘上的文件，以及包含其他所有内容的提示。它运行良好，所以它增长了。记忆需要语义搜索，于是向量数据库加入技术栈。文件需要在部署中幸存，于是对象存储带着跟踪所有权的小型服务出现了。任务状态需要事务，于是关系数据库出现。多租户落地，现在四个系统每个都需要自己的隔离模型。

此时团队维护着一个记忆服务、一个文件层、一个向量存储和一个事务数据库，外加协调它们的胶水代码。每个新功能都涉及多个系统。每个一致性错误都变成分布式系统调查。没有人计划这种架构；它是自然增长的。

大多数团队起步时的拼接式状态栈

上述模式是就地解决每个出现的持久性问题的默认结果。每个单独的选择都是合理的。总和是一个比产品增长更快的操作表面积，以及一个代理的记忆、文件和状态可能悄悄不一致的数据模型。

使用TiDB实现持久代理数据的更简单路径

另一种选择是减少系统边界：在同一个分布式SQL引擎中，使用你的团队已经了解的SQL查询结构化状态、记忆记录、向量索引和文件元数据。租户是一个模型，而不是四个。一致性是事务，而不是同步管道。达到生产环境的架构看起来就像设计文档中的那样。

TiDB如何适配完整的Serverless数据库和AI状态故事

TiDB是一个分布式SQL数据库，兼容MySQL协议，引擎内建向量搜索，并采用可缩放到零的Serverless部署模型。这四个属性直接映射到代理状态栈：用于操作状态的ACID事务、用于记忆和文档检索的向量索引、用于记忆记录和文件元数据的持久结构化存储，以及用于突发性代理流量的弹性Serverless经济性。

设计目标是单一基础，而非联邦。代理记忆以带有嵌入的可查询行形式持久化；一条SQL语句即可按租户过滤、与任务历史连接，并按向量相似度排序。文件和工件与同一租户和血缘模型关联。作为AI数据库基础设施，重点不在于TiDB能做所有事情，而在于必须相互一致的AI状态层位于同一个一致性域中。

表2：持久化需求在碎片化堆栈与TiDB中心架构中的解决方式。

这种整合逻辑并不止于数据库。代理处理文件和处理行一样频繁，然而这两个表面通常通过不相关的接口访问：SQL用于状态，对象存储API用于工件，应用代码用于使两者保持一致。TiDB正在构建的方向是单一访问协议，通过一个接口呈现数据库和文件系统，使代理以相同方式处理其状态和工作文件，在相同的租户和血缘模型下。

用于实时状态和持久记忆的分布式无服务器数据库

由于TiDB将计算与存储解耦并同时分布式化，无服务器层可吸收代理突发流量而无需固定容量上限，而存储层在扩展事件中保持状态持久。计算在空闲开发时段挂起，并按需恢复，使其成为动态工作负载的无服务器数据库，并提供免费层起步。

SQL状态、搜索和AI应用增长的单一基础

实际好处随时间显现：原本需要跨越三个系统的功能变成了模式变更。生产证据指向同一方向：Manus在TiDB上运行超过一百万个数据库租户，Kimi的代理平台在单个集群上运行数千万并发租户站点，Atlassian将750多个Postgres集群整合为16个TiDB集群。整合是常态，而非例外。

TiDB如何帮助AI团队从原型转向生产

AI演示与AI产品之间的差距主要是持久化差距。演示容忍状态丢失；产品则不然。早期规划完整代理状态栈（记忆、文件、运行状态、检索）的团队避免了重写，否则重写会在最糟糕的时刻到来，即使用量增长时。

这些决策之下还有一个未决问题：企业AI栈中应有多少是开放的。开放权重模型发布已将其从哲学辩论变成采购问题，而这个问题现在延伸到模型下方的数据层。TiDB的答案是其历史。它是一个开源分布式SQL数据库，使用MySQL协议，这就是为什么它能融入现有工具链而非要求团队采用专有接口。对于可能随时间更换模型的代理框架，开放状态层使持久化决策独立于模型决策。

构建在分布式无服务器数据库上，一个引擎覆盖整个栈意味着需要运维的系统边界更少，架构和计费方面的蔓延更低，以及从原型到受治理的多租户生产的更清晰路径。如果您正在为AI应用评估长期持久化，TiDB Cloud的无服务器层是测试架构与真实工作负载的低摩擦场所。

王帆是TiDB的工程与AI增长副总裁，领导公司AI和无服务器产品组合的团队。他拥有超过16年构建分布式数据系统的经验，并直接与在TiDB上运行代理工作负载的AI原生团队合作。

本指南借鉴了TiDB内部研究、已发布的TiDB客户案例研究以及对当前无服务器数据库架构的分析。引用的产品功能反映了截至2026年8月的TiDB Cloud；读者应在TiDB Cloud文档中确认当前层级详情。

无服务器数据库常见问题

什么是无服务器数据库（简单来说）？

无服务器数据库是由提供商管理所有基础设施的数据库。您无需配置服务器或规划容量。计算随需求自动扩展，空闲时可完全挂起，并且您按实际使用量付费，而非为预留机器付费。

为什么AI应用需要的不只是向量存储？

向量存储处理语义检索，通过含义查找相关内容。但AI应用还需要精确的事务状态（任务状态、租户记录）、带有来源的持久记忆以及文件持久化。向量存储是近似的；生产状态必须精确。

AI应用应在会话之间持久化什么？

聊天日志和摘要、用户偏好、工具调用历史及其输出、生成的文件、任务和工作流状态、租户元数据，以及所有这些之上的检索索引，并带有时间戳，以便事件能够被排序和审计。

什么最适合代理应用的无服务器数据库？

这取决于工作负载形状。评估突发流量下的连接处理、冷启动延迟、对运行状态的SQL和ACID支持、原生向量搜索、租户隔离以及与工具链的协议兼容性，然后根据您应用程序的实际需求权衡这些因素。

无服务器数据库能否处理生产级AI工作负载？

是的，如果底层引擎是生产级的。判断架构，而不是标签：持久性保证、经过测试的规模、治理功能和一致性模型。无服务器描述的是运营和计费合同，而不是能力上限。