开发者实践：智能体生成 SQL 之后，NineData 如何把风险管住

智能体进入研发流程后，SQL 生成会变得更高频、更碎片化，也更依赖上下文判断。真正影响生产稳定性的，往往不是语法是否正确，而是权限是否越界、风险是否提前拦截、变更是否可回退、执行是否可审计。NineData 的实践把这些控制点前移到平台链路中。

IMG_256

本次分享的核心观点是：智能体的关键挑战，已经不再是“能否生成 SQL”，而是“能否在生产环境中被可信地接入、被精细地约束、被持续地审计，并在安全边界内参与诊断与闭环处理”。

随着大模型、Agent Framework、AI Coding 和智能体逐步进入企业研发与运维体系，数据访问主体正在从“人”扩展到“人和 Agent 并存”。这意味着企业必须把数据管理从传统的人工经验模式，升级为一套面向人和 Agent 的统一工程控制体系。只有这样，企业级Agent 才能真正从演示能力走向生产能力。

一、企业数据管理进入新阶段

Agentic AI时代，为什么数据治理变得更重要。

根本原因在于，企业数据架构和研发模式正在同时发生变化，数据管理不再只是单机、单云、单关系型数据库场景下的局部优化，而是面向多云、多源、多模态、多角色、多链路的整体治理问题。

IMG_257

从业务侧看，这种变化主要来自三股力量：

• 国产化升级持续深入：数据库从单一主数据库逐步演进为多种数据库组合，迁移、适配和长期运维复杂度同步上升；

• 全球化与云化加速并行：混合云、多云、跨地域部署成为常态，数据管理对象显著分散；

• Agent 成为新的数据消费端：数据库、数仓、通用数据和文件数据不再只服务于研发、测试、运维和业务人员，也开始面向 ChatDBA、ChatPilot、第三方 Agent、自动化流程和各类智能执行体开放。

• 这类变化带来的直接结果是：数据库访问链路更长、变更频率更高、结构调整更频繁、底层数据流动更复杂。

如果数据管理仍然停留在传统工具分散、权限离散、审核依赖人工经验的阶段，那么智能体一旦进入生产环境，就会迅速暴露出安全与稳定性风险。

IMG_258

演讲中对传统开发与 Agent 开发模式做了非常清晰的对比。和传统模式相比，Agent 驱动的数据开发具有几个明显特征：

• 意图驱动替代手工编写：数据库操作从显式代码逻辑，转向自然语言意图驱动；

• 变更节奏显著加快：SQL、Schema 和测试数据的生成更加高频、更加碎片化；

• 结构实验性增强：动态生成 Schema 与实验性表结构调整更常见；

• 访问边界变得更模糊：权限不再只绑定到固定人员和固定应用账号，也开始与 Agent 的执行上下文相关。

这意味着智能体的落地，已经不是“给数据库加一个问答界面”那么简单，而是要同时解决访问边界、SQL 准入、变更控制、敏感数据保护、复制一致性、审计追踪和闭环修复等一整套问题。

二、NineData 的核心能力

要解决上述问题，单点工具叠加并不能形成有效答案。

NineData 在本次演讲中虽然聚焦数据库 Agent，但产品实践真正要解决的，是所有访问数据的智能体如何在统一平台内被安全接入、被精细授权、被持续审计。

IMG_259

从产品能力结构来看，NineData 的核心能力主要由三部分组成。

第一部分是数据开发和数据库 DevOps。这一层承接数据库设计、开发、审核、变更、发布、导入导出、性能优化、安全审计等工程流程，是数据库生产活动的统一治理入口。

第二部分是数据复制与数据一致性保障。可以解决复杂数据环境中的迁移、同步、集成、容灾、多活以及结构/数据一致性校验问题，是跨云、跨地域、跨数据库类型数据流动的基础设施。

第三部分是 ChatDBA 基于数据库 DevOps 安全访问能力构建的企业级数据管理 Agent。整合 SQL 审核、安全控制、策略判断与审计机制，为 Agent 访问生产数据提供安全可控的智能入口，并支撑开发 Copilot、NL2SQL、性能诊断和知识问答等场景。

因此，ChatDBA 不是外挂在数据库之上的问答助手，而是 NineData 将数据库 DevOps、数据复制与统一数据安全访问层纳入同一平台，形成一套适合 Agent 时代的数据管理体系。

这一点非常关键。因为只有当智能体建立在统一平台之上，它的能力才能和底层工程控制机制绑定在一起；否则，所谓智能化只会变成新的不确定性来源。

三、数据库 DevOps

智能体想要进入生产环境，第一步不是让它“更聪明”，而是先让它和人一样，进入统一、可控、可审计的数据库工程体系。

3.1 面向人和 Agent 的统一数据库管理平台

如果研发、测试、运维、业务人员和各类 Agent 依然分别通过 Navicat、DBeaver、跳板机、驱动直连、脚本调用或云厂商控制台访问数据库，那么企业很难真正建立统一的权限边界和完整的责任链路。

IMG_260

NineData 的数据库 DevOps 方案，本质上是把数据库相关工作从“分散工具行为”升级为“平台化工程流程”。

在这套体系里，数据库设计、查询、变更、审核、审批、版本管理、CI/CD 集成、操作审计和性能治理不再分散在多个系统中，而是统一收敛到一个可治理的平台控制面中。

IMG_261

这种统一入口带来的价值主要体现在四个方面：

• 统一接入：人和 Agent 都通过 NineData 平台访问数据库，避免多工具、多账号、多直连模式带来的治理断层；

• 统一流程：开发、测试、生产相关数据库操作进入同一条工程链路，减少流程割裂；

• 统一规则：权限、审核、审批、脱敏、审计使用同一套平台化规则执行；

• 统一责任：数据库行为可以追溯到具体的自然人、角色、系统账号或 Agent 上下文。

数据库 DevOps 在这里的重要性，不仅在于提升协同效率，更在于为智能体建立统一的执行约束层。

没有这一层，Agent 的 SQL 生成、数据访问与数据操作都只能停留在 DEMO 阶段，无法进入企业真实应用场景。

3.2 面向人和 Agent 的统一安全访问体系

NineData 要解决的，不只是智能体的准入问题，而是所有访问数据的智能体，在企业环境中的安全接入、授权边界、审批链路与全程留痕问题。

因此，演讲中用了较大篇幅讨论数据库安全访问体系的重构问题。

IMG_262

NineData 将这套体系概括为三道核心控制线。

1. 最小权限原则与身份隔离

无论访问主体是研发、运维，还是 ChatDBA 与第三方 Agent，都不应直接持有生产特权账号。

人的身份账号与 Agent 的身份账号必须严格分离，权限应按照环境、数据源、库、表、列、动作类型和有效期进行精细授权，并在使用结束后自动回收。

其目标不是“尽量少授权”这么简单，而是让数据库访问主体始终可识别、可约束、可追责，避免高权限扩散成为系统性风险。

2. 实时拦截与敏感数据保护

Agent 生成的 SQL 可能语法正确，但在业务语义上越权；一条允许执行的查询，也可能在返回结果中暴露敏感数据。

因此，数据库安全控制必须同时覆盖行为层和结果层：

• 对高危 SQL 进行规则检查和实时阻断；

• 对敏感字段进行动态脱敏、过滤或访问限制；

• 对越权访问和异常路径在执行前即进行拦截。

这使智能体的能力边界不再取决于模型“是否足够可靠”，而取决于平台是否能在执行前把风险挡在边界之外。

3. SQL 级全链路审计

要让企业真正接受 Agent，另一个前提是数据库行为必须可追溯。

不仅要有日志，更要能清楚回答：

• 谁发起了这次访问；

• 访问是否由 Agent 生成或代执行；

• SQL 是否经过审核、审批或规则检查；

• 是否涉及敏感数据；

• 执行结果如何，是否影响了生产对象。

这也是为什么 NineData 在数据库治理中始终将 SQL 操作审计、平台操作审计、审批流转和敏感数据访问轨迹统一纳入平台审计体系。

对智能体而言，这种可证明、可回放、可核查的审计能力，是其进入生产环境的信任基础。

3.3 构建 CI/CD 阶段的 SQL 自动化准人审核

Agent时代，数据库开发的另外一个显著变化，SQL 生成的动态随机性与逻辑黑盒，让传统人工审核方案形同虚设。

如果治理动作仍然停留在发布窗口前的人工会审，那么面对高频、碎片化、动态生成的 SQL，企业很快会失去有效控制。

NineData 在演讲中介绍的核心实践，是将 SQL 审核能力嵌入 GitLab 等工程链路，在 MR/PR 和流水线阶段完成数据库风险前置检查。

其关键价值体现在三个层面：

• 秒级能力注入：基于解耦的 Skill 架构，为 ChatDBA 及各类第三方 Agent 提供快速可调用的 SQL 审核能力；

• 流水线无感嵌入：审核逻辑原生集成至 CI/CD 流程，不额外增加研发负担；

• 全量与差量并行治理：既支持增量 SQL 检查，也支持更深层的业务代码扫描与全量治理。

这一机制把数据库风险处理时机，从“发布前人工检查”提前到了“代码合并前自动体检”。

对于智能体场景来说，这意味着 Agent 的 SQL 输出不再游离于工程体系之外，而是天然进入企业级质量门禁。

3.4 稳定可控的数据库变更发布

完成 SQL 准入并不意味着智能体已经可以安全参与生产。

真正的难点在于，数据库变更发布并不是简单执行一段 SQL，而是要同时保证业务连续性、可回退性、执行窗口可控和风险可审计。

IMG_264

NineData 在数据库变更治理中重点强调三类能力。

第一类是统一入口前置拦截。数据库变更在真正进入生产前，必须先经过规范预检查、风险识别和必要审批，避免人工误操作与 AI 生成 SQL 幻觉直接作用于生产数据库。

第二类是变更前备份与回滚脚本生成。对于结构调整和数据变更，平台在执行前完成结构与数据备份，并为失败场景预生成回滚路径，从而把“可恢复性”前置到发布动作本身。

第三类是面向大表、大数据量和高影响对象的平稳发布能力。在复杂业务场景中，数据库变更是否会锁表、是否会长时间阻塞、是否会引发业务抖动，往往比 SQL 本身更关键。

因此，智能体的价值不在于“它能执行变更”，而在于“它所在的平台能否把变更执行转化为受控、稳定、可恢复的工程过程”。

从这个角度看，数据库变更治理是智能体从“辅助生成”走向“参与执行”的分水岭。

四、ChatDBA 可信安全的数据库智能体

随着各类数据库智能体、ChatPilot、自动化流程等业务 Agent，越来越多在生产环境中持续生成动态 SQL 并访问底层数据，企业对数据访问安全、权限治理和合规审计的要求也在快速提升。

ChatDBA 是 NineData 基于数据库 DevOps 安全访问能力构建的企业级数据管理 Agent。作为数据安全访问与控制的落地实践，ChatDBA 深度整合了 SQL 审核、安全控制、策略判断与任务分发等核心机制，真正做到了“事前精准校验、事中安全执行、事后完整审计”，让 Agent 能够在严密的安全管控下，无缝接入企业的真实数据库工作流。

基于这一高安全性的架构，ChatDBA 打造了数据库开发 Copilot、自然语言问数（NL2SQL）、数据库性能诊断优化以及数据库知识问答等多维数据管理能力。它在大幅提升企业数据管理与运维效率的同时，死守数据访问的安全底线，是企业级安全可控 Agent 的最佳实践，能够真正直面并服务于严苛的生产环境。

IMG_265

从功能结构来看，ChatDBA 主要覆盖三类数据库工作：

• Text2SQL 与开发辅助：库表生成、测试数据生成、智能问数、SQL 开发助手；

• 性能诊断与优化：性能巡检、会话诊断、空间诊断、SQL 诊断优化；

• 知识问答与异常分析：数据库知识问答、私有知识问答、平台知识问答、异常问题诊断。

在 NineData 的方法论中，性能自愈从来不是放任 Agent 自动执行修复动作，而是一个完整的闭环：

• 先通过诊断能力发现问题；

• 再结合数据库专家经验、规则体系与可观测数据进行定位；

• 对需要执行的动作进行权限校验、规则检查和必要审批；

• 在可备份、可回滚、可审计的前提下推进闭环处理。

只有这样，智能体的“自愈”才不是失控自动化，而是建立在可信执行基础之上的闭环治理能力。

五、数据复制与数据一致性保障

在智能体的落地，不只是访问和变更问题。

在大型企业环境中，更大的复杂度往往来自底层数据如何在不同数据库、不同云厂商、不同地域和不同业务系统之间稳定流动。

5.1 典型数据复制场景

IMG_266

演讲中将企业最典型的数据复制场景归纳为四类：

• 数据库国产化升级；

• 数据库迁移；

• 容灾多活；

• 数仓实时集成。

这些场景看似不同，但本质上都要求平台同时解决异构适配、链路稳定、性能可控和一致性校验四类问题。

5.2 数据复制核心能力

NineData 数据复制是玖章算术推出的云原生数据同步产品，支持 100+ 主流数据源接入，覆盖 1000+ 种数据复制任务类型，可实现全量、实时双向的同异构数据流转，具备秒级低延迟、断点续传、数据强一致的核心能力，一站式满足企业数据库迁移上云、跨云容灾、异地多活、数仓实时集成等各类数据流动需求。

IMG_267

从产品能力上看，NineData 数据复制覆盖：

• 100+ 数据源支持；

• 1000+ 数据复制通道；

• 500GB+ 全量复制吞吐能力；

• 秒级增量复制延迟。

更重要的是，NineData 并不是只解决“把数据搬过去”，而是同时覆盖：

• 结构复制：列、索引、外键、Check、分区等对象；

• 全量复制：数值、字符、二进制、时间、空间等数据类型；

• 增量复制：DML、DDL 等持续变更对象。

5.3 数据一致性保障

在复杂生产环境中，真正困难的从来不是起一条同步链路，而是长期稳定运行后如何验证结果是否正确。

NineData 数据对比是云原生数据一致性校验工具，支持主流关系型、NoSQL、分析型数据库的同构/异构数据对比，提供全量对比、快速抽样对比、周期性对比等多种模式，可自动定位数据差异并一键生成修复SQL，广泛用于数据迁移、主备同步、备份恢复后的一致性校验场景，保障企业多环境下的数据质量与数据安全。

IMG_268

无论是国产化迁移、双向复制、跨云同步，还是长期 CDC 场景，最终都要保证：

• 结构是否真正一致；

• 数据是否真正一致。

如果底层数据流动体系不稳定、不一致、不可核验，那么任何上层智能体的自动化治理都无法长期成立。

因此，数据复制与一致性保障不仅是核心产品能力，也是智能体进入企业级复杂场景的重要基础。

六、全球化企业、AI 与金融场景的技术实践

演讲最后分享了多个典型客户实践。这些案例的价值，不只是说明 NineData 的能力覆盖面广，更重要的是它们分别对应了几类最复杂、最具代表性的企业生产场景。

IMG_269

安克创新业务覆盖全球 146+ 地区，涉及欧洲、美国、东南亚和中国大陆等多个业务板块。

在这样的全球化场景下，数据库管理的难点并不是单一数据库规模，而是多区域安全合规、多地域数据回流分析、数百实例统一治理和跨地域运维协同同时存在。

NineData 通过在多个区域部署 DevOps、AI 与数据复制能力，帮助其统一管理对应地域的大量数据库实例，满足业务安全合规与统一治理要求。

IMG_270

MiniMax 作为 AI 大模型公司，面临的是多云环境统一接入、向量数据库治理、快速研发迭代与有限 DBA 资源之间的平衡问题。

这一类企业最需要的不是松散的数据库访问工具，而是能支撑多云统一接入、AI 数据开发、数据库标准化治理和高效率协同的统一平台。

IMG_271

杭州银行的典型挑战，在于 Oracle 国产化升级、生产数据向下游应用和分析系统的分发、以及对生产库压力影响的严格控制同时存在。

这类场景要求平台不仅能完成数据库迁移和实时复制，还要具备反向 CDC、全量数据对比、中间归集与下游抽数等能力。NineData 在这里提供的并不是单点复制工具，而是一套覆盖迁移、实时复制、数据对比和生产压力治理的综合方案。

七、总结

在追求可控、确定性的企业级场景中，Agent 的大规模落地，必然依赖数据管理体系的升级。

这种升级至少包含五个层面：

• 统一接入：先收敛人和 Agent 的数据库访问入口；

• 安全边界：用最小权限、脱敏、拦截和审计构建可信受控体系；

• 数据库 DevOps：把 SQL 审核、CI/CD 准入、变更发布、回滚和审计做成默认流程；

• 数据基础设施：用数据复制、数据对比和一致性保障支撑复杂场景；

• 数据库 AI 智能体：让 ChatDBA、Text2SQL、诊断优化等能力建立在上述工程底座之上。

对企业而言，智能体的未来，不会属于“最能生成 SQL 的模型”，而会属于最能在生产环境中被安全使用、被精细约束、被持续验证并稳定交付结果的平台。

只有把数据库 DevOps、安全访问控制、SQL 准入审核、稳定变更发布、数据复制与一致性保障、数据库 AI 智能体统一起来，Agent 才能真正从“可用”走向“可信、受控、自愈”。