“智能体时代”数据团队需采用云优先、成本可见、灵活架构。成功团队已实践租户隔离、在线更改和对象存储。智能体是新用户，需默认隔离、在线更改、放置配额及生命周期自动化，以支持大规模运营。
译自：4 Data Architecture Decisions That Make or Break Agentic Systems
作者：Max Liu
在上一次软件即服务（SaaS）平台规模化浪潮中蓬勃发展的数据团队，并非那些盲目追逐炒作的团队。他们是那些做出了一些明智决策的团队：他们采用了云优先的运营模式，使成本和容量可视化，并选择了能够快速适应不断变化条件的架构。
事实证明，这些正是 智能体时代 现在所要求的实践。
如果你审视数据团队如何管理他们的 AI转型，一个清晰的模式便会浮现：那些对性能和支出有牢固控制的团队，在支持智能体方面最为轻松。他们已经实践了租户隔离。他们已经在工作时间进行在线更改。他们已经在使用 对象存储-支持的恢复。智能体所需的一切，他们都已在做。他们只是将已经实践的相同原则应用于一种新型用户。
让我们从这个前提开始：智能体是你的新用户。我们将探讨它们与其他用户有何不同，以及如何最好地支持它们。在此过程中，我们将讨论影响 大规模运营能力 的四个架构因素。最后，我们将提供一份清单，你可以用它来评估你当前平台对智能体驱动工作负载的适用性。
智能体是你的新“用户”
大多数数据平台是为人类和需求相对稳定、可预测的服务而构建的。而智能体系统则截然不同。它们会启动短期应用程序、运行实验、触发迁移、分支出新的数据集，然后将其全部销毁——通常是并行且不可预测的。
我们亲眼见证了像 Manus 这样的公司。它提供了一个通用型智能体AI平台，其“广泛研究”智能体群每天会启动数千个短期工作负载。它不再管理单个庞大的数据库，而是在幕后编排数百万个微小、临时的分支状环境。
在大规模应用中，智能体所需的并非一个庞大、不断增长的数据库。它实际上是数百万个微小、隔离的数据库或分支，它们不断地产生和消失。一旦你接受这个前提，智能体架构的四个要求便自然而然地浮现出来：
- 默认隔离： 每个租户或每个智能体的边界可防止实验成为所有人的问题。
- 工作时间在线更改： 模式和索引必须在服务水平目标 (SLO) 内，以 p95/p99 的延迟进行调整。
- 放置和配额： 热数据需要靠近低延迟计算；冷数据可以存储在廉价存储中；嘈杂的租户需要被隔离。
- 生命周期自动化： 你需要能够在几秒钟内创建和淘汰环境，并保持干净的元数据卫生和成本归属。
以下是支持你的智能体用户需求的四个架构选择。
1. 两种对可伸缩性至关重要的分离
智能体可以快速吞噬共享资源。为了防止这种情况发生，请将计算与存储分离，以便你可以在不移动数据的情况下增加查询容量。然后将计算与计算分离，为在线事务处理 (OLTP)、分析和维护提供各自的通道和 SLO。
将计算与存储分离
将无状态的 SQL/计算引擎连接到持久、共享的对象存储，可以让你：
- 弹性扩展： 增减查询容量，无需进行高风险的数据复制或周末迁移。
- 可预测恢复： 新节点可以从存储中拉取状态并预热缓存，然后开始服务，而不会使对等节点过载。
- 快速克隆： 写时复制分支可以快速从元数据构建，而不是完整的物理复制。
需要验证什么：
- 你能在几分钟内添加计算节点而不重新平衡数据吗？
- 新节点是从对象存储而不是从对等节点中获取数据吗？
- 克隆和分支是增量且空间高效的吗？
将计算与计算分离
当数千个智能体同时分支数据、构建索引和发送查询时，SQL 前端、分析读取器、后台维护（压缩、回填）、备份/恢复和控制平面需要独立扩展和管理，以保持其平稳运行。
需要验证什么：
- 你能独立于 OLTP 流量限制回填速率吗？
- 分析扫描是否拥有自己的资源和保障措施？
- 你能在不影响另一个平面的情况下对一个平面执行版本升级吗？
2. 让成本可见（且可操作）
传统数据平台通常在 20% 到 25% 的 CPU 利用率下空闲运行，同时保留额外的余量以备“不时之需”。这对于人类用户来说尚可接受；但在智能体启动数千个短期工作负载的环境中，这是站不住脚的。解决方案是让每次查询的成本可见——例如，通过请求单位 (RU) 核算——呈现在工程师已经关注的同一界面中。
这样，工程师就知道哪些查询需要优化以及预期可节省多少成本。产品和财务部门可以设定与实际工作相符的预算和上限，而平台团队可以根据实际支出而非直觉来推荐改进。
需要验证什么：
- 你能将成本归因于租户、应用程序和查询摘要吗？
- 你能自动执行预算和上限吗？
- 你是否有与延迟和成本回归测试相关的“前五摘要”循环？
3. 将对象存储视为主干
对于智能体架构而言，使用对象存储（S3/Google Cloud Storage/Azure Blob）作为数据主干并非可选。它通过从共享对象存储中拉取数据并在本地缓存热数据以实现超低延迟，从而实现上下文感知扩展，确保数据库始终在当下保持适当的规模。在横向扩展或恢复期间，新的计算应该从持久存储中拉取状态，而不是从对等节点复制。备份和长期快照也应该存储在那里。
优势：
- 可预测的扩展和恢复： 在增长或故障转移期间，减少跨节点抖动。
- 分层经济性： 你可以推断并进行预算的热/温/冷数据路径。
- 快速数据库分支： 数据库克隆变为指针操作加上对象存储语义。
需要验证什么：
- 备份、快照和分支元数据默认存储在对象存储中吗？
- 新节点在故障后开始提供服务需要多长时间？
- 你能自动垃圾回收废弃的分支和对象吗？
4. 将在线更改视为一流能力
当智能体成为你的用户时，变化是持续不断的。模式演进、索引、数据移动和升级都必须在线进行，并对正在发生的一切有清晰的可见性。
在实践中，这看起来是这样的：
- 三阶段模式更改（准备 → 重组 → 提交），采用多版本并发控制，以便在回填运行时读/写操作能继续进行。
- 尊重 p95/p99 预算的速率限制维护。
- 具有自动领导者选举且无维护窗口的滚动升级。
需要验证什么：
- 你能在高峰期向热表添加索引，并使 p95/p99 保持在 SLO 范围内吗？
- 元数据锁是短暂且可预测的吗？
- 你的管道中是否内置了预检、中止阈值和回滚计划？
需避免的反模式
所以这些是你应该尝试做的事情。以下是一些应该避免的事情。
- 分片复杂性： 应用程序级别的分片看起来很简单，直到你永远拥有路由、重新平衡、故障转移和跨分片连接的责任。
- 一个大池： 将所有计算视为可互换会导致“吵闹的邻居”事件和尾部延迟峰值。
- 不可见的支出： 实例级别的计费隐藏了每查询的浪费；请记住，你无法管理你看不到的东西。
- 对等复制依赖： 依赖繁忙邻居的恢复和横向扩展过程在压力下容易崩溃。
最低限度评估清单
使用以下清单来比较适用于智能体工作负载的平台：
- 数据库预置： 你每分钟可以创建多少个隔离的数据库、模式和分支？它们是如何被跟踪和淘汰的？
- 两种分离： 在实际负载下检查计算/存储独立性和计算/计算独立性。
- 成本模型： 工程师能多好地按租户/应用程序监控每次查询的成本？存在哪些上限以及如何强制执行？
- 对象存储： 演示从对象存储中获取数据以进行节点加入和恢复。测量到服务的时间。
- 在线更改： 测试在高峰期添加索引的能力；检查 p95/p99、错误率和中止阈值。
- 故障演练： 关闭一个领导者或可用区 (AZ)；观察选举、客户端重试和尾部延迟。
- 元数据卫生： 证明废弃的分支和对象无需人工干预即可被垃圾回收。
智能体系统不需要全新的基础设施方法。适用于智能体的正确架构，就是适用于任何大规模现代用例的正确架构。但智能体是一个强制性因素。
数据团队没有奢侈到可以继续使用扩展缓慢、难以管理的单体平台。智能体将使那些旧架构不堪重负。但正如最成功的数据团队所发现的那样，如果你使用上述方法设计，注重灵活性、可见性和性能，即使你的“用户”数量达数百万——而且其中大多数不是人类——你也能更快地交付，并减少周末的紧急状况。
