Agent 时代,数据库不再只是存储层。本文梳理了 Legacy DB 如何安全暴露给 Agent、SQL Pattern 代理层的核心设计、以及 Agent Native 数据库的新形态。适合正在做 AI 应用、考虑让 Agent 访问数据的后端和架构同学。
最近在技术社区看到一个讨论：「Agent 时代的数据库该怎么设计？Legacy DB 有哪些方式可以暴露给 Agent 使用？」
这个问题背后的痛点很真实。传统架构里，数据库被后端服务包裹着，读写操作都要走接口层控制。但 Agent 出现后，这条边界开始模糊：Agent 要理解业务状态、生成报表、跑复杂查询，有时还会触发数据变更。继续走传统 API 路径，Agent 的能力会被卡死；直接把数据库开放出去，安全和稳定性又会埋下隐患。
这篇文章把目前主要的三条路线讲清楚：代理层方案、语义查询方案，以及 Agent Native 数据库。看完你会知道什么场景下该选哪一种，以及 Legacy DB 迁移在现实里可走的路径。如果最近正好在做相关的工作，建议先收藏，后面的对比内容和排查清单到真正落地时可以直接拿来用。
结论很简单：Agent 时代的数据库设计，本质就是在表达能力、安全边界和迁移成本之间找平衡。
手头如果有 Legacy DB，别想着一步到位重构。比较现实的做法是加一个代理层，把 schema、字段含义、表关系转成受控的上下文，让 Agent 在安全边界内完成查询选择和参数填充。这个方案的思路不是让 Agent 学会写 SQL，而是让它从预定义的 SQL Pattern 里做选择。
面对全新的 AI Native 场景，可以考虑把数据层重做，比如把数据库抽象成文件系统（AgentFS），或者抽象成任务空间（db9）。这类方案不用兼容 legacy 数据，代价是放弃成熟的 SQL 生态和现有工具链。
到底走哪条路，看两点：Agent 是不是真的要直接访问数据，还是用 MCP 包装过的后端接口就够了；团队能不能扛住数据层重构的成本和风险。
直接让 Agent 去生成 SQL 并执行，听起来挺酷，实际上是一场灾难。Agent 对 schema 的理解并不稳定，生成的 SQL 性能可能极差，还容易触发删除或更新一类的操作，影响范围无法预先判断。
比较靠谱的做法是引入代理层，核心设计有三个关键点：
不要把整个数据库的 schema 一股脑扔给 Agent，而是提炼出「表名+字段含义+表关系+典型查询场景」这样的精简描述。比如 users 表存储用户基础信息，email 字段用来做登录校验，通过 user_id 关联到 orders 表。这个 context 要控制在 Agent 能高效理解的范围内，一般不超过 2000 tokens。
把常见的查询场景抽象成 SQL Pattern，每个 Pattern 是带参数占位符的 SQL 模板。比如「查询用户最近 N 天的订单」就对应 Pattern：SELECT * FROM orders WHERE user_id = ? AND created_at > NOW() - INTERVAL ? DAY。Agent 要做的不是生成 SQL，而是从 Pattern 库里挑出最匹配的模板，然后填充参数。
代理层在执行前要做参数校验、SQL 解析和执行计划预估。如果检测到全表扫描、跨库 JOIN、或者影响行数超过阈值，直接拒绝执行，或者降级成只读查询。所有执行记录都要留存，方便后续追溯 Agent 的行为。
这套方案的好处是迁移成本低、安全可控，迭代也快。Wren AI 就是这么做的，用 Semantic Engine 把 schema 转成 Agent 能读懂的上下文，再用 Apache DataFusion 跑预定义的查询逻辑。
SQL Pattern 这套方案比较适合读多写少、查询场景相对固定的业务。常见的有数据分析、报表生成、业务监控，还有用户画像方面的查询。
但下面这些场景就不太合适:
1. 复杂的多表关联查询
如果 Agent 需要按用户意图动态 JOIN 5 张以上的表，Pattern 的组合爆炸会让维护成本失控。遇到这种情况，要么把业务需求简化，要么考虑引入语义查询层（后面会讲到）。
2. 高频的写操作
如果 Agent 需要频繁写入数据（比如实时更新任务状态），Pattern 方案的审计开销会变成瓶颈。这类场景更适合用专门的状态存储（比如 db9），或者回到传统后端服务的路子上。
3. 动态 Schema 的场景
如果业务 schema 经常变动（比如 SaaS 产品里的自定义字段），Pattern 的维护成本会很高。这时候可以考虑用 JSON Schema 或 ORM 操作协议来替代 SQL Pattern。
要不要用 SQL Pattern，看一个指标就够了:Pattern 覆盖率能否到 80% 以上。如果大部分查询场景都能用预定义的 Pattern 解决，那就值得做；如果要维护几百个模板才能覆盖业务需要，那说明这套方案不适合你的场景。
如果 SQL Pattern 覆盖不了复杂的查询场景，下一个可以考虑的方向是语义查询层。思路是让 Agent 用自然语言描述查询意图，由语义引擎翻译成 SQL 执行。
Wren AI 的 Semantic Engine 走的就是这条路线。它不是简单的 NL2SQL，而是在 schema 之上加了一层语义抽象：把表、字段、关系用业务语言重新描述一遍，Agent 看到的是「用户的最近订单」，而不是「orders 表的 user_id 外键关联」。
这个方案比 SQL Pattern 灵活，但也带来一些新问题：
1. 语义理解的稳定性
自然语言的歧义很难彻底消除。「最近的订单」到底是最近 7 天，还是最近 10 条？「活跃用户」按登录频次算，还是按消费金额算？这些都得在 schema context 里明确定义，否则 Agent 的理解会漂移。
2. 复杂查询的 SQL 生成质量
涉及多层子查询、窗口函数、递归 CTE 的场景，NL2SQL 的生成质量很难保证。实际操作中往往要人工介入调优，或者退回到 Pattern 方案。
3. 执行性能的不可控
语义查询生成的 SQL 可能藏着隐式的全表扫描或笛卡尔积。代理层得做执行计划分析和成本预估，超出阈值的查询要么拒掉，要么降级。
语义查询层适合查询场景灵活、但数据量和复杂度可控的业务。如果你的数据分析需求经常变，团队也有精力维护语义 schema，这条路线可以试试。
除了改造 Legacy DB,另一条路线是重新设计面向 Agent 的数据库形态。有代表性的方案大致分为三类:
1. 文件系统抽象(AgentFS)
把数据库做成文件系统的样子,Agent 用读写文件的方式操作数据。一个文件对应一个数据实体,目录结构对应业务层级。好处是 Agent 天然懂文件操作,不用再学 SQL 或 schema。代价是放弃了事务、索引、关联查询这些数据库的核心能力。适合状态简单、关联少的场景,比如任务管理、文档协作。
2. 任务状态存储(db9)
PingCAP 推出的 db9 是专门给 Agent Workflow 设计的 PostgreSQL 变种。主要改进是强化了状态管理和上下文持久化的能力。Agent 可以把对话状态、任务进度、中间结果直接写进 db9,不用自己处理状态序列化和恢复。db9 同时支持 SQL 查询和文件存储,适合多步骤、有状态的 Agent 任务,比如数据分析流水线、自动化测试框架。
3. 向量数据库 + Graph DB
TiDB 的 AI Solutions Hub 走的就是这条路线。用向量数据库做语义检索和 RAG,用 Graph DB 管理实体关系,再用时序数据库处理 Agent 行为日志。这种方案适合知识密集型的 Agent 应用,比如智能客服、知识库问答、推荐系统。
这三类方案有个共同点:不兼容 Legacy DB。它们适合全新的 AI Native 场景,或者作为 Legacy DB 的补充存储层,而不是替代品。
企业要不要做 DB for Agent，别只盯着技术上是不是新颖，关键看业务上是不是真的需要让 Agent 直接访问数据。判断标准有三个：
1. Agent 是否频繁需要跨多个 API 来组合数据
如果 Agent 每次都要调用 5 个以上接口才能完成一次查询，说明现有 API 的粒度切得太细。这时引入代理层或语义查询层，可以明显降低 Agent 的调用复杂度和 Token 消耗。
2. 是否存在大量临时性、探索性的数据查询需求
典型场景是数据分析和报表生成。用户的查询需求经常变化，传统做法需要不断开发新接口。如果让 Agent 直接基于 SQL Pattern 或语义查询生成结果，开发效率会提升一个数量级。
3. 是否存在多步骤、有状态的 Agent Workflow
如果 Agent 要执行比较复杂的多步骤任务，比如自动化测试、数据清洗流水线，传统做法得自己管理状态的存储和恢复逻辑。这时用 db9 这类面向 Agent 的状态存储，能大幅简化开发。
上面三个问题里有两个答案是「是」，就值得考虑引入 DB for Agent 方案。
落地建议是从只读、低风险的场景开始：
第一阶段：只读分析和报表生成
挑一个非核心业务的数据库，把代理层搭起来，只开放只读查询能力。让 Agent 基于 SQL Pattern 生成报表，看看 Pattern 的覆盖率和查询性能怎么样。
第二阶段：受控的写操作
在代理层加上对写操作的支持，但限制在低风险场景里，比如用户偏好设置、任务状态更新这类。所有写操作都必须经过审计和人工确认。
第三阶段：引入语义查询或者 Agent Native 存储
如果 SQL Pattern 覆盖率不够，可以考虑加一层语义查询。要是有全新的 AI Native 业务，可以试试 db9 或者 AgentFS。
整个演进过程要走增量迭代，别一上来就把现有架构推翻。Legacy DB 和 Agent Native 存储可以长期并存，关键是找到一条清晰的边界。
Agent 操作数据库的安全风险，比传统 API 高一个量级。要建立几层防护：
1. 权限最小化
Agent 只能访问业务必需的表和字段。用数据库的 GRANT 做细粒度权限控制，禁止 Agent 碰 users、payments 这类敏感表。
2. SQL 解析和执行计划校验
代理层执行前先解析 SQL，拒绝带 DELETE、DROP、TRUNCATE 的语句。SELECT 语句要看执行计划，拒绝全表扫描，或影响行数超过阈值的查询。
3. 流量控制和熔断
给 Agent 的查询频率设上限，超过阈值就熔断。单个查询执行时间不能超过 5 秒，超时直接 kill。
4. 审计日志和可观测性
Agent 的所有行为都要记下来：查询意图、选用的 Pattern、实际执行的 SQL、影响行数、执行时间。出问题的时候才能快速判断，到底是 Agent 生成逻辑的问题，还是 Pattern 定义本身的问题。
5. 人工确认机制
高风险操作必须人工确认，比如写核心表、影响行数超过 1000、改 schema。Agent 只生成变更计划，不能直接执行。
这些防护不是一次性建好的，要随着 Agent 能力扩展逐步加强。初期做权限控制和 SQL 解析就够了，后期再补流量控制和审计日志。
最后整理一份决策清单,帮你快速判断该走哪条路线。
选 SQL Pattern 代理层,如果:
选语义查询层,如果:
选 Agent Native 存储,如果:
不要引入 DB for Agent,如果:
技术选型没有银弹。关键在于理解每条路线的边界和代价,再结合业务实际情况判断。要是你觉得这篇内容有帮助,欢迎点个赞。要是你团队里正好有人负责这块,也可以直接转给他看。要是你在线上踩过更难缠的坑,评论区聊聊你遇到的场景,一起探讨。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。