传统数据库架构解决 OLTP 扩展问题时，各自押注在不同的卸荷方式：Exadata 把查询下推到存储层，Azure SQL Hyperscale 用共享块服务器，Aurora 把日志应用卸载到分布式存储节点。新出现的架构则把数据放在对象存储，前面加一层缓存。但这些方案都绕不开一个三角约束——scale（扩展）、latency（延迟）、isolation（隔离）——至少牺牲其中一项，有时甚至牺牲两项。

在代理（agent）时代，这些妥协不再可接受。代理工作负载是动态生成的，无法提前审查，必须与关键业务系统物理隔离；它需要亚毫秒级的 I/O 延迟，需要完整数据库引擎、索引和混合检索能力；它还会突然要求单个数据库在几秒内扩展到 1000 个计算节点，然后可能在一分钟内结束。因此，一个真正的 agentic 数据库架构必须同时满足三个原则：按设计隔离（物理分离数据路径，但实时数据访问可达亚秒级新鲜度）、亚毫秒基线 I/O（冷缓存未命中也不能掉到毫秒级之外）、代理级弹性（秒级启动、数千节点、短时爆发、自动归零）。

AlloyDB 的新架构声称是首个同时满足这三个原则的系统。底层存储采用 Colossus，Google 的 exabyte 级分布式存储系统，单集群可扩展到上万台机器，直接提供亚毫秒读取延迟，聚合吞吐可达 15 TB/s、单数据库 2000 万 QPS。代理数据路径通过独立的 Colossus 分段与生产完全隔离。网络层由 Jupiter 支撑，单一 fabric 连接超过 10 万台服务器，二分带宽 13 Pbps。计算层是微VM 隔离的 AlloyDB 节点池，Agent 通过 MCP 接入，节点秒级创建、按秒计费，生产集群保持专用预置不变。

为什么现有架构做不到？文章逐一拆解了三种主流范式。独立副本（shared-nothing）能隔离、延迟也达标，但扩展一个副本要重新灌入数百 GB 到 TB 级数据，耗时数小时，与代理的秒级爆发完全错配。共享存储服务器能快速加计算节点，但所有副本和主实例共享同一批存储服务器，代理 I/O 直接与生产争抢，且存储带宽固定，加节点只会加速饱和。对象存储加共享块服务器则依赖热缓存，缓存未命中会落到对象存储，延迟高达几十毫秒；同时块服务器仍是共享资源，不隔离也无法随突发横向扩展。作者还实测了一个这类商业服务：扩展到 8 个副本时，吞吐提升不到 2 倍，在 4 个副本处开始下降，而主数据库吞吐暴跌 75% 以上。

AlloyDB 的实测结果则完全不同。在大于 DRAM 的数据集上做并发索引查找，从 1 个代理节点扩到 10 个，吞吐从 3.9K QPS 线性增长到 41K QPS；继续扩到 1000 个节点，性能仍近线性。整个过程中，生产主集群 零可测影响。聚合吞吐放大了 773 倍，达到 300 万 QPS，在 Colossus 上驱动了 超过 800 万 IOPS。另一个基准中，2100 个代理节点并发全表扫描，聚合吞吐超过 1 Tbps。

这套架构的核心逻辑是“分享数据，不分享其他”。代理可以直接读取生产实时数据，使用完整的 PostgreSQL 引擎——点查、索引遍历、向量、全文、空间搜索、列式扫描和 lakehouse 联邦查询——但计算、网络、存储路径全部独立。Google 花了二十多年构建 Colossus、Jupiter 和弹性的计算基础设施来支撑搜索、YouTube、Gmail，现在把同一套基础放到了数据库前面。对任何想用 AI 代理处理实时业务数据、又不想让代理拖垮生产库的团队来说，这篇文章给出了一个具体的架构方向和可验证的实测数据。