思想领袖

智能体式 AI 进入数据库开发：当 AI 真正能够执行查询时，会发生什么变化

发布于 2026年10月21日

作者

Victor Horlenko, AI创新负责人，Devart

将 Unite.AI 添加到您在 Google 上的首选来源

过去几年里，AI 辅助数据库开发一直遵循一种相当稳妥的模式：开发人员描述需求，AI 生成 SQL，开发人员阅读代码、修改看起来不对的部分，然后决定是否执行。

这种工作流程一直守住了一条重要界限：AI 可以提出操作建议，但是否将其应用到数据库，仍由人来决定。

然而，随着智能体式 AI 的出现，这条界限正开始消失。如今，AI 系统可以检查架构、运行查询、解读结果，并决定接下来采取什么操作。根据最近的一项调查，62% 的组织已经在尝试使用 AI 智能体，另有 23% 的组织表示，已在企业的某个环节扩大智能体系统的应用规模。

因此，数据库团队眼下就有一个亟待回答的架构问题：问题不在于 AI 能否执行 SQL，它当然能。真正的问题是，当助手不再只是提出代码建议，而是开始直接操作数据库时，会带来哪些变化；以及这种自主权应受到多严格的控制。

从建议到行动

一个简单的索引决策就足以说明这种转变为何重要。

智能体发现一个运行缓慢的查询后，会查看数据库架构，判断添加索引可能有所帮助，随即创建索引、重新运行工作负载，并检查结果。

它可能会执行这样一条再普通不过的语句：

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

这条语句本身毫无特别之处。AI 助手也可能提出完全相同的建议。不同之处在于，最终由谁拍板。

使用助手时，开发人员会审查建议、进行测试，并决定是否执行。AI 提供建议，但由人采取行动。若智能体拥有执行权限，系统就能自行作出决定并继续操作，无须等待批准。

如果这个决定正确，工作流程就会更快。但智能体并不总能掌握全貌。它们可能会忽略应用程序依赖关系、业务规则、工作负载模式、维护时段，或其他对负责运行系统的人来说显而易见的背景信息。

因此，智能体作出的决定在技术上可能看起来合情合理，但考虑到它所处环境的具体限制和要求，仍可能并不适合该环境。

随着操作开始串联起来，危险也会增加。一次糟糕的 SELECT 可能只是运行缓慢。一次糟糕的 UPDATE 可能会锁住整张大表，或影响远超预期的行数。某个索引可能只对一个查询有用，却会给其他查询带来额外开销。架构变更也可能破坏智能体不知道依赖该架构的某项功能，因为智能体可能缺乏完整的运维背景信息，也无法测试所有可能的使用场景。

所以，问题不在于智能体无法作出良好的数据库决策，它们往往能够做到。问题在于，一旦团队允许它们根据这些决策采取行动，就需要更明确地界定其权限范围、智能体能够看到哪些背景信息、哪些情况下仍须由人介入，以及谁要对结果负责。

Gartner 预计，到 2027 年底，超过 40% 的智能体式 AI 项目将被取消，原因之一是风险控制不足。对数据库团队而言，教训相当简单：应先建立控制措施，再授予执行权限。

哪些任务可以安全地交由智能体处理？

有些数据库任务比其他任务更适合交由智能体处理。

查询分析就是一个很好的例子。智能体可以检查查询统计信息、提取执行计划、查看索引和表结构，并提出可能的修复方案，而不必更改生产数据。

它可能会发现某个查询反复扫描一张大型 Orders 表：

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

接下来，它可以解释扫描的原因、建议创建索引，并生成 DDL。要发挥作用，它不需要获得执行 CREATE INDEX 的权限。

其他类似任务也一样，例如：

描述执行计划；
找出缺失或多余的索引；
标记 SELECT * 查询或不可搜索谓词；
审查连接和过滤条件下推；
审查依赖关系和架构；
排查 SQL 错误；
优化 SQL 脚本。

实际做法很简单：赋予智能体足够的访问权限，让它能够理解问题，但不要因此自动赋予它更改数据库的权限。广泛的可见范围可能很有用，但广泛的执行权限则是另一回事，需要单独决策。

仍需人工把关的环节

比如，智能体发现一张 AuditLog 包含数亿行数据的表，并决定删除旧记录：

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

SQL 语法完全有效，但这仍可能是一个糟糕透顶的决定。

监管政策或许要求保留数据七年。某个应用程序可能依赖这些记录。也可能需要分批删除，以避免事务日志不断增长。记录或许必须先归档，然后才能删除。

这些要求不一定会体现在数据库架构中。

这正是将数据库工作视为代码生成问题的局限之一。数据库包含技术结构，但围绕这些结构作出的决策，往往是通过技术操作体现出来的业务决策。对于以下操作，也应保持同样的谨慎：

DROP 以及破坏性 ALTER 语句；
生产环境 UPDATE 和 DELETE 运维；
大规模数据迁移；
角色和权限变更；
约束修改；
影响复制或可用性的变更；
部署包含业务逻辑的存储过程。

技术上正确的操作未必就是恰当的操作。因此，不应把人工审批视为对智能体式 AI 的不便限制。对于影响重大的数据库操作，人工审批是架构的一部分。

AI 智能体同样需要遵循最小权限原则

数据库团队应避免的一种捷径，是让智能体使用开发人员已有的凭据。这么做虽然简单，却会让智能体拥有该开发人员现有的所有访问权限。

更安全的做法与管理用户和服务时相同：遵循最小权限原则。Microsoft 建议只授予完成任务所需的权限，并监控特权活动。

例如，性能分析智能体可能需要：

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

它可能不需要：

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

不同的智能体也可以拥有不同的身份。报告智能体可能会获得 SELECT 访问少数几个数据库架构的权限。迁移智能体可能只在开发或预发布环境中工作。生产环境智能体可能只获得范围严格限定的权限，并且在执行操作前仍须经过审批。

OWASP 对 AI 智能体也建议采用同样的基本做法：将读写权限分开，限制工具和资源，并要求对敏感操作进行明确授权。

原则很简单：只授予智能体履行职责所需的权限，而不是启动它的那个人所拥有的权限。

将人工审核纳入工作流程

智能体参与数据库工作的更佳模式，是采用受控的工作流程：

观察 → 分析 → 提议 → 审核 → 执行 → 验证 → 记录

假设某个智能体正在调查一个响应缓慢的 API 端点。它找出背后的 SQL，检查执行计划和表统计信息，发现可能缺少索引，并准备好迁移脚本。

可以先在预发布环境中运行该脚本。智能体会重新运行工作负载、检查结果，然后准备生产环境变更。

然后它就会停下来。

开发人员或数据库管理员会审核迁移，检查依赖关系和业务影响，并在任何变更进入生产环境之前予以批准。

智能体仍然可以承担许多重复性工作。对于影响重大的变更，最终责任仍由人承担。

事务控制措施还能增添一层安全保障。例如，PostgreSQL 的保存点允许回滚事务中的一部分，而不必丢弃此前已完成的所有操作。这有助于控制范围严格限定的自动化变更，但回滚不能替代适当的权限设置和审批。

dbForge AI Assistant 等工具也很适合用于这一环节。它可以利用架构上下文生成并解释 SQL、排查错误、比较 DDL、发现效率低下的索引，以及准备优化脚本，同时让生成的 SQL 保持可见，供开发人员审核。

目标是自动化处理常规工作，同时让重要决策由人来做。

真正的目标是受控的自主性

智能体式 AI 并不意味着只能在“AI 只提供建议”和“AI 直接操作数据库”之间二选一。两者之间还有很大的发挥空间。

团队可以从风险较低的任务开始，例如解释 SQL、审核数据库架构和执行只读检查。之后，再逐步让智能体在开发和预发布环境中承担更多工作。

写入权限应当晚些时候再授予，并对受影响的行数、事务、回滚、监控和审批设定明确限制。生产环境中的完全自主变更应当很少发生。

这也与 Deloitte 的指导意见相似：从风险较低的工作流程和非关键数据入手，让相关人员参与其中，并随着智能体承担更多工作而加强治理。

目标不是实现绝对自主，而是赋予智能体足够的自由来提供帮助，同时不给它超出所需的访问权限。

要点：数据库开发仍需要判断力

AI 智能体可以为数据库工程省去大量重复劳动。它们能够观察工作负载、检查查询、关联数据库模式、执行计划、错误和性能数据，并据此采取行动。

但当 AI 系统能够改变数据库状态时，问题就变了。团队需要为身份、权限、事务边界、审批、可观测性、回滚和审计跟踪制定明确规则。

这也说明，尽管 2025 年有 88% 的组织在使用 AI，只有 7%表示 AI 已在整个组织范围内全面推广。更难的问题是，如何让 AI 足够可靠，能够大规模运行。

数据库开发也正朝着同样的方向发展。最有用的智能体，不是获准执行最多任务的那个，而是其权限范围得到清晰界定和管控的那个。

问题已不再是 AI 能否执行数据库任务，而是我们应该信任它执行哪些任务，以及要对它施加哪些约束。