Data Agent Ready Database：下一代企业数仓架构设计

2025 年，数据库进入 AI Ready 时代——向量检索、AI 函数从新鲜特性变成行业标配。2026 年，新的趋势正在形成：Data Agent Ready。

随着 Cursor、Claude Code 等编程 Agent 的兴起，以及数据分析 Agent 的普及，越来越多的数据库操作开始由 AI 接管。但企业环境与个人实验截然不同：Data Agent 面对的是海量数据和复杂的业务逻辑。当数据库的使用者从"人"变成"Agent"，数据库的设计理念也需要相应进化。

OpenAI 在其 Inside OpenAI's in-house data agent 一文中分享了他们的实践经验：管理 600 PB 数据、70,000 个数据集时，"光是找到正确的表，就可能是分析工作中最耗时的部分"。他们的核心洞察是：Context is everything——没有充足的上下文，即使最强大的模型也会产生错误结果。

从 Data Agent 的视角出发，理想的数据库架构应当具备以下核心特质。

统一存储与语义感知

企业数据往往分散在多个系统中：订单存储在 OLTP 数据库，日志存储在 Elasticsearch，空间数据存储在 GIS 系统，向量数据存储在专用向量库，文件则存放在对象存储。这种数据割裂给 Data Agent 带来极大的复杂性——仅仅是定位正确的数据表，就可能消耗大量时间。

首要任务是实现数据统一。

以对象存储（如 S3）为底层基础，通过统一接口管理结构化、半结构化和非结构化数据。Data Agent 仅需一个 SQL 入口，即可访问所有数据资源。

但仅有访问能力还不够。Data Agent 不仅需要找到数据，更需要理解数据的含义——字段的业务语义、表之间的血缘关系、数据的更新周期和适用范围。缺乏这些上下文，即使是最强大的模型也可能产生错误结果。

因此，数据库需要提供丰富的元数据层：包括 Schema 信息、表血缘（Lineage）、字段注释、历史查询模式等，使 Data Agent 在执行查询前就能建立对数据的深度理解。同时支持运行时 Schema 校验，确保推理基于最新的真实数据状态。

即时 Schema Evolution

传统数据库的 Schema 变更是一项昂贵的操作。为大表添加字段可能需要长时间锁表并重写数据。然而，Data Agent 在数据探索和自动化处理过程中，频繁调整 Schema 是常态。

Schema 变更必须做到即时生效。

通过元数据版本控制（Schema Versioning），字段的增删仅修改元信息，不触动底层数据文件。利用读时解析技术自动处理版本兼容，无论数据量大小，Schema 变更都能瞬间完成。这使 Data Agent 能够快速迭代数据模型，无需顾虑变更成本。

零开销 Git-like 分支

将生产库的写权限直接交给 Data Agent 存在显著的安全风险。一旦 Agent 产生"幻觉"而误删或修改数据，后果将难以挽回。

解决方案是像管理代码一样管理数据：引入分支机制。

基于 Zero-Copy Snapshot 技术，创建分支仅需生成一个逻辑指针，成本极低且不占用额外存储。Data Agent 的所有探索性操作都在独立的

dev

feature

main

透明性同样重要。Data Agent 的每一步操作都应当可追溯——执行了什么查询、修改了哪些数据、基于什么假设做出决策。这种透明性使人类可以随时审查 Agent 的推理过程，验证结果正确性，并在必要时进行干预。

-- 创建开发分支
ALTER TABLE orders CREATE BRANCH dev;

-- Data Agent 在分支上进行探索，不影响生产环境
SELECT * FROM orders/dev;

-- 支持从历史时间点创建分支
ALTER TABLE orders CREATE BRANCH feature_branch
  AT (TIMESTAMP => '2026-01-27 10:00:00');

完善的事务性

Data Agent 的数据操作通常不止单条 SQL。一个典型的工作流可能包括：从源表读取数据、执行转换计算、写入中间表、更新目标表——涉及多张表的协同操作。

如果中间某一步失败，而之前的步骤已经生效，数据就会陷入不一致状态。

因此，多语句事务支持是必需的。

将多个操作封装在事务中，要么全部成功提交，要么全部回滚。这种原子性保障使 Data Agent 无需担心中途失败导致的数据污染。

更进一步，Agent 可以利用事务的回滚能力实现自我纠错——遇到错误时自动回滚并调整策略重试。配合记忆系统，将每次纠错的经验保存下来，在后续操作中避免重复犯错。

UDF Sandbox

Data Agent 的能力不仅在于查询数据，更在于处理数据。调用 LLM API、运行复杂的 Python 逻辑、完成数据清洗和分析建模——这些都是高频需求。

通过内置 UDF Sandbox，数据库可以直接满足这些需求。

这种设计带来三个核心优势：

• 代码下推执行：将 AI 生成的 Python 代码推送到数据所在位置执行，消除大规模数据搬运的网络开销。
• 故障隔离：UDF 在独立沙箱中运行，即使代码异常也不影响数据库主进程的稳定性。
• 版本管理：对 UDF 代码进行版本控制，确保计算逻辑可追溯、可复现，便于 A/B 测试和迭代优化。

极致稳定性

人类用户的查询模式通常有规律可循，DBA 可以据此进行针对性优化。但 Data Agent 的请求模式完全不可预测，查询复杂度跨度极大，同时追求极致的执行速度。

这种"无规律、高并发、求极速"的负载特性，对数据库稳定性提出了更高要求。传统数仓在面对异常负载时，常见的应对方式是调整参数或重启服务。但在企业级海量数据场景下，重启一次可能意味着数小时的服务中断。

必须实现零调参的稳定性：

• 自适应资源管理：根据负载动态调整内存和计算资源，避免 OOM 导致的进程崩溃
• 查询熔断与降级：对资源消耗异常的查询进行智能熔断，保护整体服务可用性
• 热配置更新：关键参数支持在线调整，无需停机

稳定性是 Data Agent 实现 7x24 小时持续运行的基础保障。

Databend 的演进

Databend 作为完全基于对象存储构建的云原生数仓，正在朝着这个方向演进：

• 统一存储与语义感知：原生 Parquet 支持，统一存储结构化、半结构化、向量和时空数据。内置 Audit Trail 系统提供完整的 query_history、access_history 等历史查询记录，帮助 Agent 理解表的使用情况和数据含义。
• 即时 Schema Evolution：Rust 存储引擎实现完整的元数据版本控制，Add/Drop Column 即时生效。
• 零开销分支：Zero-Copy Snapshot 技术支持轻量级 Branching 和 Tag 管理，每个操作可追溯、可审计。
• 完善的事务支持：ACID 多语句事务，确保多步操作的原子性和一致性。
• UDF Sandbox（开发中）：沙箱化 Python UDF，安全隔离，按需自动伸缩。
• 极致稳定性：Multi-Cluster 架构支持根据负载自动 Scale In/Out，开箱即用，无需参数调优。