作者｜李粒、王黎黎、吴嘉程、鲁超
编辑｜郑玄、Cynthia
你有没有想过一个问题：一次大模型问答只需 15 秒，可为何一个执行了 20 轮思考的 Agent，完成一项任务有时却要半小时乃至数小时，甚至中途直接失败？
答案是：用户在等模型响应，而模型在等 CPU 调度的一系列 Infra 组件。
行业的多份分析显示，当一个 Agent 在执行任务时，核心推理虽然由 GPU 承担，但端到端延迟中，CPU 侧调度的工具调用、数据库读写、任务编排、文件处理、I/O 等待、状态恢复与记忆检索带来的延迟占比，可以高达 50%-90%。
各种 AI Infra 组件中，承载状态的数据库层影响尤为突出。用户在 TiDB Cloud 新创建的数据库实例中，如今有近 90% 由 Agent 直接发起，而不是来自人类工程师。因此任何一次数据库读写失败、延迟抖动、召回不足等问题，都可能引发任务重启、执行失败，甚至将错误结果留存至模型记忆中，污染整条 Agent 链路。
随着模型能力逐步完善、不同厂商之间趋同，AI Infra 的建设，正在成为决定下一阶段 Agent 体验的全新课题。
Agent 时代，当模型不再是唯一的变量，AI Infra 就成了拉开差距的地方。而数据库正在从存储系统，变成承载 Agent 状态的关键基础设施。
01
数据库，
为什么成了 Agent 状态的核心底座
有多少人在用 AI 的时候，会真的打开它的「思考过程」，去观察一个典型的 Agent 是如何执行任务的？
例如，一个复杂任务可能在 30 秒内调用 12 次工具、写入 4 次记忆、检索 8 次向量、回查 3 次状态。在传统架构里，这意味着 12 次跨系统调用、4 次数据同步、8 次向量检索、3 次状态查询——每一次都可能是潜在的失败点。
更麻烦的是，Agent 的错误会被指数级放大。一个人类工程师写错一次代码，影响的是一个服务。一个 Agent 的错误尝试，可能会被写入记忆，影响后续一系列 Agent 行为，甚至影响成千上万个终端用户。
因此 Agent 时代的数据库问题，从来不只是「数据量变大了」。而是数据形态、使用方式、流量特征与系统边界，都与传统应用存在本质差异，状态本身变复杂了。
过去的数据库系统主要处理订单、账户、交易、商品、库存等这类结构化数据，而 Agent 应用的数据类型更为多元和复杂：
它有 Memory（用户偏好、项目背景、长期目标、历史决策）；有 Context（对话历史、工具返回、中间状态、文件摘要）；有 State（Agent 做到哪一步、哪些工具调用成功、下一步从哪里恢复）；有 Vector（语义检索和相似任务召回）；有 Trace（记录工具调用、SQL、API、权限、成本和结果之间的关系）。
各类数据存在强关联特性。例如，当 Agent 需要查询「某用户在对应项目中过往的相似决策」时，不能仅依靠向量检索或单张关系表查询，而要同时理解用户权限、项目 ID、时间范围、任务状态、历史决策和语义相似度。
如果继续沿用「MySQL 存业务状态、Redis 存短期状态、对象存储放文件、向量数据库存放向量数据、日志系统记录追踪信息、数仓做分析」的拼接式老路，Agent 状态就会被拆散在多个系统里，意味着每新增一套系统，都会叠加一次数据同步、多一层权限映射、多一处数据一致性补偿、多一段审计对接的工作量。
在 AI 产品高速迭代、用户飞速增长的情况下，工程团队光是处理不同系统之间的数据同步，就足以拖慢整支团队的节奏。
第二，Agent 特有的「长尾爆量」流量，会击穿传统成本模型。
过去数据库讲多租户，租户往往是企业客户、团队或 Workspace。Agent 场景里，租户粒度会小得多，但总量却可以呈指数级别增长。一个用户就可能创建十个 Agent，一个 Agent 平台也可能很快积累百万、千万，甚至数亿级的逻辑租户。关键的是，这种租户规模虽然接近互联网业务，但流量结构却和传统互联网大相径庭。
过去，无论是双十一还是春晚，用户规模有上限，即便存在流量高峰，但浪涌趋势可预测。Agent 却不一样——它可能因为一次社媒传播突然涌入百万级用户，也可能新增的百万用户里有 99% 都是低频使用者。整体数据呈现出一种极端长尾模式：大量租户长期零 QPS，少数租户突然爆量。
传统的资源分配模式也随之失效。如果给每个 Agent 或每个应用都分配一个独立的数据库实例，即便单实例每月只要十几美元，乘上百万级租户，也会变成一个难以承受的数据库账单；如果反过来把所有租户塞进一个大库，隔离、计量、爆炸半径、Schema 演进和故障定位又会一齐失控。
某种程度上，Agent 时代需要的是一套能承载海量 Agent 状态的数据库底座：上层每个应用看起来「都有自己的数据库」，底层却能做到资源池化、按需调度、成本复用与统一治理。
这种「One Agent, One Sandbox, One Storage, One Database」的范式，正在成为头部模型与 Agent 公司不约而同收敛到的同一架构终点。
第三，记忆从「对话切片」升级为「需要被治理的数据资产」。
当 Agent 真的开始长期服务一个用户，记忆就会逐步显出它的真面目——它不是会话窗口，也不是简单的向量切片，而是一类需要被长期治理、检索、更新和保护的数据资产。
过去很多产品把「记忆」等同于「本地文件 + 对话切片丢进向量库」：哪些信息该记住、哪些信息更重要、哪些信息又需要被覆盖，需要业务方手动维护；什么内容适合什么检索方式，要团队自行摸索；每次数据更新，都要重建一次索引。这种做法在 Demo 阶段尚可，一旦真的长跑，就会迅速变成产品的隐性债务。
一个值得关注的方向，是把「记忆」做成数据库内置的一等公民，让它成为状态底座的一部分。行业里近期出现的 Mem9 这类 Agent Memory 能力，就把记忆从应用层下沉到了数据库一侧——持久记忆零配置、混合检索、跨设备同步，搭配一套 Context Engine，用户不必手动配置记忆规则与召回方式，就能开箱获得权限隔离与可视化审计。
记忆层正在从「应用层的小聪明」，回归到「数据库层的基础能力」。这是 Agent 时代数据库范式重写中，最具代表性的一步。
第四，Agent 的全球化运营会不断抬高对数据库的要求。
AI 产品天然面向全球用户。这意味着数据库面对的不只是存储问题，还包括数据就近访问、跨区域部署、合规分区、企业审计、安全加密和弹性峰谷调度。
用户在不同国家和地区，数据访问不能全部绕回单一区域；不同市场有不同监管要求，数据边界不能事后再补；企业客户还会要求私网连接、加密、权限、审计和运维流程；Agent 流量峰谷不确定，底层资源也必须能快速弹性伸缩。
这些问题叠加，意味着「一个业务库 + 一个缓存 + 一个向量库 + 一套日志系统」的传统拼接式方案，会越用越吃力。
然而，Agent 需要的数据库，既要像应用数据库一样支持事务与状态，又要像向量数据库一样支持语义检索，还要像云原生系统一样支持极端弹性、多租户隔离和全球部署。
可当下这个时代阶段，真的存在这样的产品吗？
02
两个公司，同一个答案
真正先撞上数据库新问题的，有两类用户：一类是大模型，一类是 Agent 平台。
前者的代表是 Kimi ——拥有亿级用户、支持多 Region 部署的自研大模型；后者的代表是某办公 Agent ——新一代的企业级 Agent，能够生成完整可用的应用、执行长期任务、记住用户的偏好与历史经验。
一个从模型走向 Agent，一个从 Agent 一端反推回数据底座。虽然两者业务侧重不同，但它们在底层状态与数据库选型上，几乎不约而同走到了同一条路。——这是一个值得行业留意的信号。
没有人会比一家大模型公司自己更懂 Agent，也没有人比他们更清楚，当 Agent 从测试走向生产时，底层数据库会需要解决哪些潜在的挑战。
以 Kimi K2.6 Agent 为例：用户只需用一句自然语言描述需求，Agent 就会自己完成代码生成、部署、以及后续的持续在线托管，整条链路在分钟量级完成。它和「由 Agent 调用外部部署平台」那类产品不同—— K2.6 端到端拥有整条托管链路，也就意味着，当上百万个用户各自生成一堆 Agent 应用时，所有站点的数据库、状态、事务、访问，都要由 Kimi 自己的这套底座扛下来。这种「Agent 自己造应用」的产品形态，天然把数据库推入过去从未遇到过的极限——一个 Agent 平台，同时需要托管起千万级、乃至更多量级的、由 Agent 生成的独立站点。
Kimi 团队设想与尝试过多种路径。他们积累下的 Agent 场景数据库选型经验，对行业而言，或许是一个值得借鉴的参考。
比如，针对海量用户的多租户问题，有几种选择：
1）给每个应用一个独立的关系型实例。逻辑上最清晰，隔离也非常直接，但当租户规模进入百万级、甚至更高时，物理实例会随着逻辑租户一起线性增长，闲置站点也照样吞掉计算资源，成本曲线完全无法用订阅模型收回。对一个每分钟都在诞生新 Agent 站点的平台来说，这条路从第一天就走不通。
2）用一个大型集中式数据库加多 Schema。前期效率高，但 Kimi 团队评估之后发现，这条路的实际天花板大约就落在「万级租户」这个量级——继续往上加租户，连接数、流控、租户隔离、Schema 演进、扩容和故障半径就会一起劣化，没有一条能扩展到 Agent 平台所需要的规模。
3）走嵌入式轻量方案。它很轻量，但备份、高可用、扩容、审计、跨区域容灾都会变成平台自己的负担。对测试环境友好，然而对要求业务连续性的生产环境，却并不友好。
Kimi 最终选择了阿里云上的 TiDB ( TiDB on Alibaba Cloud ) ——用一套底座，同时承接一家模型公司在高速发展过程中最难同时满足的几件事——把「逻辑上每个 Agent 都有自己的数据库」和「物理上共享一套弹性底座」真正拆开来做。
1）用一层「虚拟数据库」去替换掉传统的「真实实例」：底层由一套跑在对象存储之上的分布式 KV 层承担数据持久化，上层则让每一个 Agent 看到的都是一份完整、独立、随时可用的数据库形态，实例回收、休眠、连接中断等事件不会传导到应用层。
2）把「数据库开通」从 Agent 的交付关键路径上摘掉。据公开信息，TiDB Cloud 通过 Warm Pool 维持一批预初始化好的 Starter 实例，配合 Scale-to-Zero，实现闲时收缩、有载展开，Agent 发起任务时能在秒级内拿到一套可用的数据库。
3）把前端、后端、数据库尽量收敛到同一套技术基座上，让 Agent 在每次生成应用时都能复用一致的脚手架和最佳实践。
这套架构落到最终的账单和体验上，是几组非常具体的结果：
新建站点的数据库开通时间稳定在一秒以内，Agent 不再需要在生成的代码里写重试和轮询逻辑；
闲置站点的持续计算开销被显著压缩，落到数千万 Agent 租户的规模上 , 单个租户身上的成本 - 收入模型，被真正改写了；
单集群横向支撑起数千万级的 Agent 站点，用户任何时候回访，一次点击就能唤醒；
租户之间的爆炸半径、流控、数据隔离——过去在「单库多 Schema」方案里到几万租户就会集中爆发的问题，被留在了架构窗口之外。
对 Kimi 而言，最终选择这套底座的原因，不是任何一个单点指标最优，而是「多租户隔离、统一技术栈、极致弹性」这三件事被同一套系统同时解决——放眼当下的数据库产品，这样的组合并不多见。
某办公 Agent 视角：Agent 平台如何解决「交付」和「成长」两个核心问题
该办公 Agent 在构建一个 AI Agent 平台，目标是让 Agent 真正「替用户完成数字工作」——做数据分析、生成文档、网页研究、操作浏览器、生成图片视频、部署网站、执行定时监控任务。
问题一：Agent 生成的东西「看起来像应用」，但不是一个真正能用的应用——数据无法保存、刷新页面就丢、没有真实业务逻辑、不能多人同时使用。像一间漂亮的样板房，没有水电、门禁、管道，看着像房子，但不能真的住人。
问题二：Agent 每次执行任务都像一个新员工第一天上班——聪明，却没有经验积累，用户的格式偏好、历史决策、试过的工具，下一次任务开始时又要从零讲一遍。
解决这两个问题，需要的并不是更强的模型，而是一套能支撑应用、状态和记忆的数据基础设施。而该办公 Agent 交出了答案：
1）Full Stack Application，让 Agent 生成的不只是漂亮的前端，而是带后端逻辑、数据库和真实业务状态的完整应用；
2）Mem9，让 Agent 拥有可持续、可搜索、可复用的长期记忆，不必每一次都从零开始。
这两类能力的共同地基，正是同一套数据库底座——阿里云上的 TiDB ( TiDB on Alibaba Cloud ) 。前者要求每一个 Agent 生成的应用都有「自己的数据库」形态，底层却能高度池化、按需调度；后者要求把记忆做成数据库内置的一等公民，内置混合检索、跨会话同步、权限隔离与可视化审计。
这两类能力和 Kimi 的答案落在同一处：一套底座——阿里云上的 TiDB。
Full Stack Application 解决「交付问题」；Mem9 解决「成长问题」。
Agent 从一次性工具，走向持续工作的 AI 员工——靠的是同一套数据底座。
共性需求，共同主张
Kimi 和 该办公 Agent 的业务侧重不同，但他们对底层状态和数据库能力的价值主张趋同。
首先，成本，成本，还是成本。针对多租户带来的无规律流量和成本问题，成本模型必须接近真实使用。阿里云上的 TiDB会将计算与存储解耦，数据可以长期保留在低成本存储层，计算按需启动。这样，冷数据不会长期占用计算资源，热数据又能在请求到来时快速拉起。让最终的账单结构更接近「按调用计费」。
第二，需要解决多类型数据带来的系统割裂。阿里云上的 TiDB在架构层做了统一：把 HTAP 一体、分布式事务、向量能力、半结构化与全文检索，把「记忆、检索、事务、分析」尽量收敛到一套引擎里，从根上减少数据搬运和一致性补偿。
第三，需要解决高增长带来的多租户冷热不均的管理问题。逻辑独立和物理独立必须拆开。阿里云上的 TiDB能够支持百万级 Schema Per-Tenant 隔离，对上层 Agent 来说，它拿到的是独立数据库形态；对底层平台来说，资源可以池化、调度和复用。真正实现 One Agent, One Sandbox, One Storage, One Database。
03
Agent 走向生产，
需要云与数据库深度协同
如果只看数据库本身，TiDB 的产品设计已经能解决很多问题。甚至对很多 Agent 应用来说，在早期阶段，拼接式数据库系统也可以勉强使用。
但 Agent 应用一旦进入生产，需要的就不再只是「一个数据库」，而是模型平台、对象存储、日志、网络、安全、数据同步、运维体系和全球区域能力一起工作。因此，阿里云上的 TiDB，体现出了云与数据库深度协同之后的相性价值。
第一，存算分离和极致弹性
只有云上的分布式资源池，才能让计算与存储解耦、让资源按需调度，让「百万级逻辑租户」不等于「百万个物理实例」。
对 Agent 应用来说，这一点尤其重要——它的负载不是稳定线性增长，而是大量长尾租户与少量突发热点并存。底层系统必须能让冷数据低成本保留、让热任务快速拉起、让资源在不同租户之间高效复用。背后离不开阿里云上的对象存储、弹性调度能力和 Serverless 资源模型。
第二，阿里云上的 TiDB，从来不是「单点能力」，而是 AI 全栈能力的一环。
Agent 跑在云上，就意味着我们需要以统一视角来审视模型、数据库、对象存储、日志、安全、网络、区域等等技术要素。
在阿里云体系里，算力侧可以接 PAI、灵骏，模型侧可以调用阿里云百炼等能力；计算与沙箱侧可以用 ACS Agent Sandbox、FC Sandbox；文件侧用 OSS 承接文档、图片、音频、代码包和中间产物；缓存侧可以叠加 Tair Vector；日志侧用 SLS 记录工具调用、错误链路和审计信息；网络侧则有 PrivateLink、VPC 对等连接、IP 白名单等私网能力，以及 CEN 骨干网和全球加速 GA。
Agent 跑在云上的真正价值，是让模型、数据库、对象存储、日志、安全和网络可以被放进同一套工程体系里思考——从模型训练到部署、推理、数据落库、RAG 检索，可以在 VPC 内闭环，避免跨云出口流量费与数据合规的人为切割。
数据库放在云上，不是装上去，而是长进去。
这件事的价值，不仅在于让团队少接几个系统，更能让他们少花时间处理基础设施之间的摩擦，把更多精力留给产品迭代和业务增长。在传统软件时代，团队可以慢慢补齐这些工程能力。但在 Agent 时代，速度本身就是竞争力。
第三，阿里云加速 Agent 产品全球化
对于 Agent 类产品，出海 / 全球化几乎是一门必修课。这其中就包括了如何实现底层数据库区域资源调度和合规。
无论用户在东南亚、欧洲、中东、日本还是北美，阿里云支持「用户就近接入、数据就近合规、模型集中调度」的全球化部署。得益于阿里云在全球范围 32 个公共云地域、105 个可用区，境外覆盖中国香港、新加坡、印尼、马来西亚、法国、德国、英国、阿联酋、日本、韩国、美国、拉美等等关键节点。Agent 出海公司在新市场打开节奏可以从月级压到周级，跨域延迟稳定在毫秒级。
把数据库能力和云上的区域、安全、网络、合规能力放到同一套工程体系里，让全球化扩张不会变成全球各地割裂的系统烟囱。
第四，Agent 时代的数据安全，不再只是数据库自己的事。
对模型公司和 Agent 平台来说 , 最大的不是技术债，而是「数据被谁看见」的债。Agent 时代新增的风险面也比传统应用更复杂——长记忆 = 长曝光、工具调用 = 横向移动、向量泄露 = 语义反推。
与之对应，新一代云上数据库正在把安全做成「内建」而非「外挂」：三层架构隔离（全局控制平面、区域控制平面、数据平面）。
阿里云全链路加密体系：数据传输、内部通信、落地存储全程加密，用户能自主掌管加密密钥，全方位守护数据安全。
阿里云完善的合规能力：在国际范围内通过了 150 多项安全合规认证，如 ISO27001 信息安全管理、ISO27017 云安全管理等全球通用合规认证、ISO42001 人工智能管理认证，以及欧盟、美国、中东、东南亚等区域或国家主流认证等。
阿里云上的 TiDB基于零信任网络规则，配合阿里云私网链路与 IP 白名单等功能，在多租户共用共享基础设施中实现网络、计算、存储三层隔离，保障各租户环境独立安全。叠加 AI 驱动的安全运营与多层审计日志，大幅缩短安全事件的平均响应时间。
在 Agent 时代，数据库的安全不再只是数据库的事，它是云、引擎、应用三方共同签名的承诺。
04
Agentic Database，
是数据库范式的第三次重启
过去几十年，数据库经历过 OLTP、OLAP、HTAP、Cloud Native 等多次演进。在这条路上，行业一直朝着「更快、更便宜、更稳定」这些老命题不断疾驰。
但 Agent 时代提出了新问题：数据不再仅仅是自然人在使用、数据的分布与形态与过往大相径庭，全球化扩展也不再是公司后期才会考虑到的问题，而是 AI 产品从第一天就可能面对的现实。
如果说云原生数据库是数据库范式的第二次重启，那么 Agentic AI Database，大概率会是第三次。
这些问题关系到 Agent 产品能不能从 Demo 走向生产，能不能从个人用户走向企业客户乃至全球，能不能在高速增长时仍然控制成本和风险。每一次数据库切换，对企业来说都是一次基础设施层面的伤筋动骨。如何降低切换的风险与成本，从来都是数据库范式跃迁期的核心议题。
从近期行业的动作看，围绕「 Agent 团队如何在架构窗口期低成本验证新底座」，已经开始出现一些值得留意的尝试。比如：
1、《TiDB × 阿里云 安全合规白皮书》近期已公开提供下载，把数据主权、跨境合规与多租户隔离这些 Agent 团队最容易踩雷的议题，拆成了一份可执行的清单；
2、面向中国模型出海公司、Agent 平台与垂直 AI 应用开放的「Agent Database Starter Program 项目」，提供一定免费额度，由 PingCAP 资深工程师和阿里云产品解决方案架构师陪跑，帮助团队完成架构评估、PoC、压测、迁移建议和上线设计。后续满意即转商用，按实际用量计费。
在速度决定一切的 Agent 时代，选对数据库，从来不只是选一套基础设施，而是为创新预留出真正发生的空间。
* 头图来源：PingCAP
本文为极客公园原创文章，转载请联系极客君微信 geekparkGO
点击文章底部「阅读原文」解锁资源包
极客一问
你如何看待办公 Agent ？
