Agent 数据栈：为什么每个 AI Agent 都需要自己的数据栈
Agent 数据栈：为什么每个 AI Agent 都需要自己的数据栈
从中心化到分布式 Agent 数据架构的转变
AI agent 需要数据架构发生根本性转变，从 SaaS 时代的中心化数据平台转向分布式模型，即每个 agent 都有自己的沙盒化数据栈。这种转变是必要的，因为 agent 24/7 全天候运行，通常以循环方式运行，产生的查询负载可能会使传统基础设施不堪重负，并且如果直接授予其对生产数据库的访问权限，会引入显著的安全风险。
现代数据栈在 Agent 场景下的失效
传统现代数据栈依赖于中心化系统和 ETL (Extract, Transform, Load) 流水线。由于以下几个原因，这种模型对于 AI agent 时代是不够的：
- 延迟与交付速度： 构建 ETL 流水线可能需要数周或数月，而 AI agent 的用例必须快速交付才能保持竞争力。
- 数据多样性： Agent 需要实时访问广泛的数据源，包括 OLTP 数据库、document DBs 和 message buses，而不仅仅是分析型数据。
- 基础设施负载： Agentic 工作负载产生的负载比人类用户高出几个数量级。Luke Kim 提到最近的 GitHub 故障部分归因于 agentic 用例驱动的大规模增长。
- 安全风险： 直接授予 agent 数据库访问权限是危险的。Kim 提到了一个病毒式传播的事件，其中一个 AI agent 破坏了生产数据，以及 Lovable 发生的一起因后端数据库控制不足而导致的安全事件。
提议的解决方案：Agent 数据栈
为了解决数据可访问性与系统稳定性之间的冲突，提议的架构是为每个 agent 提供其独立的、隔离的数据栈。该栈作为一个安全的、防火墙化的层，位于 agent 与组织的后端数据系统之间。
架构与实现
与其授予 agent 对生产系统的直接网络访问权限，不如让 agent 数据栈作为一个“sidecar”运行，提供一组经过有意配置的、安全的本地数据集合。
该架构的关键能力包括：
- 联邦 SQL 查询： 能够跨多种不同的后端存储进行查询，包括 Parquet, Iceberg, Snowflake, MySQL, MongoDB, 和 Elasticsearch，以及 HTTP APIs, GitHub 数据和文件系统。
- 本地加速： 为了确保一致的性能并防止后端过载，工作数据集会被复制到嵌入式数据库中，例如 DuckDB, SQLite, 或 Arrow。这为 agent 创建了一个快速的本地回环。
- 本地模型服务： 在与数据相同的机器上本地加载并提供模型服务，以尽可能使 agentic 工作流尽可能本地化。
实际应用：SRE Agent 演示
为了演示隔离数据栈的实用性，Kim 展示了一个使用 Open Claw 构建并由 Spice AI 提供支持的 SRE (Site Reliability Engineering) agent。 由于 agent 与生产系统是隔离的，它可以被授予对日志、指标和数据库的广泛访问权限，而不会危及实时环境的稳定性。
事件解决工作流
在演示中，SRE agent 协助解决了一个实时站点故障，通过以下步骤：
- 检测： Agent 接收到了关于订单延迟过高的 Grafana 警报。
- 诊断： Agent 查询了生产数据库、监控日志以及存储在 GitHub 上 Markdown 格式的非结构化故障排除指南 (TSGs)，以确定原因。
- 初步缓解： Agent 建议将订单服务扩展到三个副本，以应对增加的负载。
- 二次故障排除： 当扩展导致错误率上升（由于数据库连接限制）时，agent 分析了数据并识别出了连接池问题。
- 最终解决： Agent 建议将连接池模式从 "session" 更改为 "transaction"，从而成功恢复了服务稳定性。
- 事后分析： Agent 识别出了受故障订单影响的具体客户，为客户沟通提供了必要的数据。
AI 基础设施的技术要点
- 隔离是赋能者： 通过将 agent 与后端系统隔离，组织实际上可以让 agent 更 强大，因为它们可以安全地授予它们访问更广泛生产数据的权限。
- 混合数据访问： 有效的 agent 栈必须结合联邦访问（为了广度）与本地复制（为了速度和安全）。
- 统一接口： Agent 与数据栈的交互方式就像对待标准数据库、搜索引擎或 OpenAI endpoint 一样，简化了 LLM 的工具调用过程。