AI能自己跑SQL了，数据库团队该把权限线划在哪？

　　过去几年，AI在数据库工作里的角色很单一：帮你少打几个字。你描述需求，模型起草SQL，你决定留哪句。工具一年比一年聪明，但工作的形状没变——按下运行键的，始终是人。

　　Agentic AI（智能体式AI）改变的是这个形状。一个智能体可以自己检查表结构、执行查询、读取结果，再决定下一步做什么。摆在数据库团队面前的问题，已经不再是AI能不能写好SQL——它显然能。问题变成了：我们准备把"执行"这个决定交出多少，交出去之后，出了事谁来负责。

　　这让它成为一场关于权限的设计讨论，而不是关于模型的讨论。

　　那个没人设计过的控制环节

　　回头看助手时代，有个细节很扎眼。AI辅助SQL里最有效的安全机制从来不是某个功能，而是一个习惯：人先读输出，再让它碰数据库。就这一步，吸收掉了大部分风险。

　　正因为它是习惯，丢掉的时候也不容易被察觉。给智能体开放执行权限，这一步就直接消失了。第一天什么都不会坏，系统只是同时变得更快、更少被监督。

　　所以"智能体能不能做这件事"是个错误的第一个问题。更该问的是：人类复核这一步，过去到底在替我们挡什么，现在这份保护又落在哪里？

　　同样的SQL，不同的责任人

　　智能体执行的SQL，往往和助手当初建议的一模一样。一个发现慢查询的智能体，可能会建索引、重跑负载、确认收益，动作和开发者做的没有区别。

　　差别不在语句，而在判断归谁。开发者权衡一次变更时，会考虑那些永远不会出现在执行计划里的事：哪些服务依赖这张表、峰值写入负载长什么样、当前是否处于发布冻结期。智能体只看得见它能访问到的东西，而那份视野通常比想象中窄。

　　于是一个技术上合理的决定，对环境来说仍可能是错的。又因为智能体是按序列行动的，小的误判会层层叠加。慢读只是烦人，一次范围松散的更新或一次意料之外的表结构变更，就是事故。

　　数据库里编码着业务决定

　　这正是数据库工作与大多数AI编程工具优化对象的不同之处。应用代码表达逻辑，数据库还承载义务。

　　看一条智能体完全可能提出的清理语句：

　　DELETE FROM AuditLog

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

　　语句合法。但它是否可接受，取决于表结构里根本不记录的事实：监管要求的保留期限、仍有应用在读这些行、删除前必须先归档的要求、需要分批执行的操作需要。

　　把数据库开发纯粹当成代码生成问题，就会漏掉这些。许多数据库操作是穿着技术外衣的业务决定。模型可以掌握技术那一半，却无从知道业务那一半。这不是换个更好的提示词能修好的缺陷，而是一条需要绕开设计的边界。

　　权限是架构问题

　　所以智能体的权限，应该和表结构设计、部署策略放在同一场讨论里，而不是躺在某个周五下午被人随手改掉的配置文件中。几条原则由此而来：

　　把"看"和"做"分开。智能体的大部分价值来自读取：解释执行计划、发现低效索引、审查依赖、诊断错误。广泛的可见性和广泛的执行权是两个不同的决定，应该分开做。

　　智能体是主体，不是代理。让智能体以启动它的开发者身份运行，是最省事的配置，也是最站不住脚的。智能体应该有自己的身份，按职责划定范围，就像服务账号那样。OWASP把相反的模式称为"过度代理"，并将其视为LLM应用的核心风险。

　　人工审批是系统的一部分。对破坏性DDL、生产数据变更、权限变更和大规模迁移来说，复核环节不是拖慢智能体的摩擦，而是承载问责的那个组件。

　　体现这一点的流程大致是：观察 → 分析 → 提议 → 复核 → 执行 → 验证 → 记录。智能体几乎可以做完全部，包括在预发环境测试变更并测量结果。它不做的，是凭自己的判断把高影响变更推上生产。

　　自主权应该分阶段挣得

　　以上都不构成"让智能体永远只读"的理由，它主张的是排序。从解释和分析开始，让智能体在开发和预发环境做变更，之后再引入生产写权限，并对影响行数、事务边界、回滚、监控和审批设定明确限制。完全自主的生产变更，保持罕见。

　　多数组织还处在这条曲线的早期。麦肯锡2025年的AI现状调查显示，在任何单一业务职能中，报告已规模化部署AI智能体的受访者不超过10%。Gartner则预计，到2027年底，超过40%的智能体式AI项目会被取消，风险控制不足是原因之一。成功规模化智能体的团队，很可能是那些先建控制、后给权限的团队。

　　对开发者意味着什么

　　如果智能体接手更多重复性工作，开发者的角色是转移而非缩小。有价值的能力会向这几处移动：

　　像审同事的拉取请求一样严格地审AI提出的变更

　　把隐性上下文显性化，让保留规则、依赖和约束写在智能体或复核者找得到的地方

　　主动定义智能体权限的边界，而不是默认继承

　　对每一次高影响变更的结果负责，不管草稿是谁写的

　　值得采用的工具，是支持这种分工而不是模糊它的那些。dbForge AI Assistant是一个例子：它在dbForge工具内基于数据库元数据而非表数据来生成、解释、优化和排查SQL，并把结果交回开发者复核和执行。

　　值得问的那个问题

　　最有用的数据库智能体，不会是权限最大的那个，而是全团队都清楚它权限边界的那个：它能看见什么、能改什么、以什么身份行动、由谁签字。

　　所以该和团队讨论的不是"要不要让AI跑查询"，而是"哪些查询、在什么约束下、经谁批准"。把这个问题回答清楚的团队，既能拿到智能体的生产力，又不必交出那份让数据库值得信任的判断力。