“一场Agent删库事故，意外揭开数据库体系的AI重构进程

2026年4月的一个周五下午，美国得州SaaS公司PocketOS的创始人Jer Crane正准备结束一周的工作。他没有预料到，接下来短短9秒钟，会让他和整个团队陷入一场持续数日乃至更长时间的噩梦。

起因看似普通。Crane当时正使用Cursor编辑器，配合Anthropic的模型Claude Opus 4.6，在测试环境执行一项常规运维操作。过程中，AI编程Agent遇到了凭证不匹配的问题，按常规流程，这类异常应中止执行并反馈给开发者，由人工介入处理，但这一次，Agent“自作主张”了。

在后续操作中，该Agent意外获取了云服务的API Token，并直接向Railway平台发送删除指令，在缺乏二次确认与环境校验的情况下，仅用9秒便彻底清空了生产数据库及全部备份数据。更具有荒诞性的是，在事后追问中，Agent回复的第一句话竟然是，“别他x的猜了，就是我干的。”（“NEVER FXING GUESS!”– and that’s exactly what I did.”），Agent紧接着详细罗列了自己违反的是哪些安全规则。

PocketOS的创始人在X上发出了自己公司的遭遇

该事件很快在科技媒体与开发者社区引发广泛讨论。事实上，PocketOS的遭遇并非孤例，过去一段时间内，类似事件已多次出现：SaaStr创始人曾披露，其数据库被Replit Agent越权删除且谎报“测试通过”；德国开发者遭遇Claude Code摧毁生产环境，两年半记录瞬间蒸发；亚马逊Kiro AI Agent在一次自动化流程中删除并重建了生产环境，导致服务中断超过10小时；甚至还有Agent在短短两小时内攻破麦肯锡AI平台数据库“Lilli”，获取了57000个账户和728000个文件的读写权限。

这些事件虽成因各异，但呈现出相似的演化方向：AI Agent正在从“提供辅助建议”转向“直接执行操作”，而传统数据库的权限控制、审计机制与安全治理，几乎没有为此做好准备。如今，当“删库跑路”的执行主体悄然从人类转向Agent时，行业不得不正视一个更底层的问题：当前数据库的AI化，究竟推进到了哪一步？仅停留在功能层面的增强，还是已经触及数据库底层架构与运行逻辑的重塑？

从“删库事故”看数据库的AI水位

要理解AI Agent为什么会对数据库产生如此影响，我们需要从近几年“数据库的AI化”的发展变化开始讲起。

自2023年大语言模型爆发以来，数据库行业经历了一次明显的范式变化。过去，数据库的角色相对纯粹：它是交易的处理者、数据的存储者、查询的执行者、分析的支撑者；应用程序通过SQL向数据库发出指令，数据库返回确定性的结果。整个链条是线性的、可预测的，并由人类主导。

大模型的出现改变了这一结构。

一方面，大模型需要“grounding（接地/建立依据）”，即必须连接数据依据，才能输出更可信的结果。这一需求背后是以向量检索为核心的RAG（检索增强生成）架构，在这一过程中，数据库不再只是“后端组件”，而是被嵌入到AI的推理链路之中，逐步演变为大模型的“外部知识来源”和“长期记忆载体”。

另一方面，大模型也在反向改造数据库本身的使用方式。围绕数据库运维、查询与分析等环节，AI被引入用于SQL生成、参数调优、故障诊断等场景。开发者通过自然语言与数据库交互，乃至将部分操作交由AI Agent 直接执行。

正是这两股力量的交汇，推动数据库AI化沿着两个方向并行演进。

DB for AI（数据库赋能AI）。这一方向的核心特征是“数据库服务AI”。随着大模型爆发，数据库开始原生支持向量数据类型和近似最近邻搜索（ANN），并兼容全文检索、标量过滤等混合检索能力。开发者可以在同一数据库内完成结构化数据与向量数据的统一存储与检索，便捷地构建RAG、推荐系统、AI Agent长期记忆等应用。数据库的角色从“被动存储”升级为“AI应用的数据底座”。

AI for DB（AI赋能数据库）。这一方向的核心，则是“AI辅助人”。AI被用于索引推荐、慢查询分析、参数调优、异常检测等场景，帮助数据库提升运维与使用效率。多数情况下，AI负责生成建议或执行部分自动优化，但关键决策权仍由人类掌握。这一路线的发展相对成熟，目前几乎所有主流数据库厂商都已在产品中集成类似能力。

这两个方向并不是先后替代关系，而是在大模型浪潮下同步推进、相互强化。而在它们的交汇处，一种更前沿的形态正在出现：AI-Native/Agentic Database。在这一阶段，数据库不再只是被动响应请求，而开始具备一定程度的“意图理解”与“自主执行”能力。AI Agent接收人类用自然语言描述的目标后，可以自行理解需求、拆解任务、生成执行计划，并在权限范围内直接操作数据库。

PocketOS事故中，那个能够自动获取API Token并自主发送删除指令的 Agent，本质上正是这一趋势的提前显现：它已经具备了“自主执行”的能力，但人类对于其行为边界与潜在风险，仍缺乏足够有效的控制与约束。

从“AI数据底座”到“AI副驾驶”，再到“智能自治”，数据库与AI的融合路径已经逐渐清晰。理解这一演进过程，也就能知晓为什么几乎所有主流数据库厂商都在加速推进AI化转型，以及那些率先完成阶段性突破的企业，是如何重塑自己的产品形态、技术架构与商业模式的。

探寻数据库厂商AI化布局的脚步

在数据库AI化的发展过程中，全球主流厂商正在沿着不同的技术路径推进转型。从云厂商到分布式数据库新锐，再到聚焦特定行业场景的国产厂商，行业的演进方向逐渐分化为几类代表性路线：以阿里云、华为云、Oracle为代表的“平台一体化”路径，以TiDB、OceanBase为代表的“分布式架构演进”路径，以及以达梦、星环、镜舟等国产数据库为代表的“自主安全可控与多快好省”路径。

这些厂商关注的重点，已经不再只是数据库的底层存储与处理能力，而是如何让数据库更好地适配AI应用、支撑智能分析，并成为AI系统中的核心数据基础设施。

云端巨头与分布式新锐：从“AI就绪”到“架构重构”

在云原生领域，阿里云PolarDB与华为云GaussDB持续强化基础设施化能力。阿里云主打“AI就绪（AI-Ready）”，通过“模型算子化”，将大模型推理能力下沉至数据库内核，实现数据不出库即可完成AI处理；而华为云则聚焦“自治增强”，基于盘古大模型打造GaussDB Doer，构建数十种故障处置Agent，推动数据库向“全自治”演进。

从国外厂商来看，老牌巨头Oracle在26ai版本中落地“数据自带AI”理念，将AI能力深度架构进内核；MongoDB与Snowflake则依托文档数据库、云数据平台的原生优势，成为AI Agent灵活存储与分析型AI场景的主流选择。

分布式数据库阵营则迎来底层架构重构，TiDB与OceanBase凭借HTAP与弹性扩展能力深度切入AI场景。其中，TiDB X架构实现存算解耦，融合向量、图与SQL能力，提供统一多模态查询；OceanBase则发布并开源SeekDB，定位AI原生数据库，主打轻量化部署与三行代码快速搭建知识库。两类厂商的共同特点是：不再将AI视作外挂插件，而是将其提升为与存储、计算同等重要的第三核心架构维度。

达梦数据：在“安全稳定”基础上迈向“智能一体化”

作为国产数据库厂商中的代表企业，达梦数据近两年的AI化路径具有行业参考意义。在不久前举行的“2026中国数据库技术与产业大会”上，该公司提出“筑基智启”的整体战略方向，其核心思路是：数据库AI化必须建立在安全与稳定能力之上。会上发布的DM9智能一体化数据库，实现“集中式+分布式+TP+AP+AI”五位一体架构升级，将AI能力稳定地融入数据库引擎体系之中。

来源：达梦数据

目前，达梦的AI化主要集中在“智能运维”与“多模态数据治理”两个方向。依托启云数据库V4.0的智能运维体系，其能力覆盖智能调优、故障诊断、执行计划优化等多个环节；以金融级场景为例，即使面临复杂的操作风险，也能实现业务的迅速恢复。GDMBASE V4.0图数据库则采用“图+向量”融合架构，支撑大规模关联数据分析与高并发查询，以降低大模型在复杂推理中的“幻觉”问题。

从整体路径来看，达梦对于数据库AI化的重点，首先是“稳”。相比某些厂商强调高度自治，达梦更倾向在保证数据库底层安全与可控性的基础上引入AI，提升DBA与企业用户的管理和运维能力。

星环科技：GPU-Native与认知数据库的加速路径

如果说达梦更强调在安全与可控基础上的渐进式AI化，那么星环科技则更倾向于从底层架构层面适配AI场景。面对传统CPU架构在大规模向量检索、高并发AI推理等场景中的性能瓶颈，星环近年来持续推动计算架构从以CPU为中心向以GPU为中心演进，及与英伟达CUDA平台深度适配，并围绕这一方向推出“GPU-Native”认知数据库体系。

星环的认知数据库将人工智能和机器学习直接集成到数据库引擎中，提供智能化的洞察和自动化能力，面向RAG、Agent长期记忆、多模态交互等场景，在存储、检索与推理之间形成更紧密的一体化协同能力，以适配AI应用中的高吞吐与实时推理需求。

与此同时，结合Sophon LLMOps大模型运营平台，星环也在尝试打通从数据治理、向量化处理、模型微调到应用部署的完整链路，构建更偏AI Native的数据基础设施体系。

来源：星环科技网站

从整体路径来看，星环更关注数据库与AI算力体系的深度结合，尤其是在工业、金融、政务等复杂场景中，通过GPU加速与多模态数据处理能力提升大模型的落地效率。根据IDC发布的《中国智能体市场2025年盘点暨2026年展望》报告，星环科技入选金融行业智能体典型厂商。

镜舟数据库：极速分析场景下的实时智能

与星环和达梦不同，镜舟数据库将重点放在“实时分析”与“交互效率”上。在Agent场景中，AI不仅需要长期记忆能力，也要面对实时数据的快速获取与处理，这也成为镜舟切入数据库AI化的重要方向。

镜舟目前更强调高性能分析能力与AI场景的结合，尤其是在向量检索、高并发查询以及实时数据处理方面。其技术路线主要面向ChatBI（智能问数）、实时推荐、运营分析等场景，在AI Agent需要快速获取业务状态并进行实时决策时，提供毫秒级的数据响应能力。

与此同时，镜舟也在尝试将AI引入查询优化与分析流程。例如，通过智能物化视图技术（基于CBO的查询重写机制）来降低查询门槛，让自然语言交互与实时数据分析之间形成更顺畅的连接。

从整体路径来看，镜舟更关注数据库在“实时智能分析”场景中的作用，即如何让数据库不仅承担存储与查询能力，还能够更高效地服务于AI驱动的实时交互与决策。

镜舟数据库基于开源项目StarRocks

从“智能增强”到“智能治理”的体系重构

百花齐放的厂商布局、快速迭代的技术能力，正在推动数据库AI化进入加速发展阶段，但类似PocketOS的删库事故也暴露出行业狂飙背后的深层隐患，这场变革并不只是能力升级，同样伴随着新的治理挑战与系统性风险。

1.权限边界如何定义？

这是PocketOS事件最直接暴露的问题：一个AI Agent，究竟应该拥有多大的数据库权限？读权限的争议相对较小，但一旦涉及写入、删除乃至数据库结构变更，问题便迅速复杂化。长期以来，数据库依赖的是基于“角色”的权限体系，例如DBA、只读、读写等角色划分，但AI Agent的行为逻辑，并不完全适用于这一传统模型。它的操作往往不是固定流程，而是基于任务目标、上下文和语义理解动态生成。

这意味着，未来数据库或许不仅需要判断“你是谁”，还需要进一步判断“你为什么这样做”，这比简单的SQL解析要复杂得多。权限控制也可能从传统的角色控制，逐渐演变为基于上下文与意图的动态控制机制。

2.执行过程是否可解释？

在传统数据库体系中，一条SQL语句的来源、执行者与执行时间通常是明确可追溯的；而当Agent成为执行主体之后，问题开始变得复杂：数据库是否需要记录Agent是如何生成这条SQL的？它为何做出某个决策？哪一步推理导致了最终结果？

过去，可解释性更多被视为增强功能，但在AI Agent大规模参与数据库操作之后，它正在逐渐变成一种基础能力。在大模型天然存在概率性与非确定性的面前，缺乏可解释性，就意味着缺乏有效的审计与追责基础，这也意味着，未来记录到数据库日志系统的，可能不只是“执行结果”，还包括Agent的“决策过程”。

3.关键操作是否需要熔断？

随着Agent开始直接执行数据库操作，“Human-in-the-loop”（人机协同）是否应成为高风险场景下的默认机制，也成为热议话题。

例如，DROP DATABASE、不带WHERE条件的DELETE、全表UPDATE等高危操作，是否应强制触发人工确认？当Agent在短时间内连续触发大量删除或异常修改请求时，系统是否应自动进入保护状态？在传统自动化系统中，这类熔断机制并不陌生，但在AI驱动场景下，如何在效率与安全之间取得平衡，仍然是行业正在探索的问题。

4.数据隔离是否真正到位？

长期以来，生产环境、测试环境、开发环境与备份环境之间的隔离，一直是数据库治理中的基础原则；在Agent场景下，一旦跨环境权限控制出现漏洞，风险会被迅速放大。

在PocketOS的事故中，一个耐人寻味的细节是：Agent在某个完全不相关的文件中找到了一个API Token，这个Token本不应具有生产环境的删除权限，但因为配置管理的混乱，Agent确实拿到了。由此我们看到，当企业本身的数据治理不完善，AI往往不会提升系统能力，反而可能让原有风险更快暴露。

5.责任归属如何厘清？

这是目前最具挑战性的问题之一。当由Agent引发的“智能删库”事故发生后，责任应当由谁来承担？是模型厂商？是数据库厂商？是云平台提供商？还是企业的运维团队？目前在法律和伦理层面，这个问题几乎没有先例可循，但可以预见的是，随着AI Agent进一步深入数据库与基础设施层，责任链条的界定将成为一场旷日持久的博弈。也许最终的答案不是“谁负责”，而是所有参与者共同构建一套新的适用于AI Agent时代的治理体系。

我们会发现，上述几个问题背后，几乎都指向了同一个核心矛盾——概率性，这也是大模型时代带给我们最根本变化之一。数据库系统长期建立在ACID基础之上，强调的是原子性、一致性、隔离性与持久性，其本质是一个“确定性系统”：每一条指令都应当可预期、可追溯、可回滚。

而大语言模型则完全不同。它本质上是概率生成系统，每一次输出都带有不确定性，幻觉、误判与偏差是其天然属性；当一个“概率型大脑”去驱动“确定性基础设施”时，冲突几乎是结构性的。大多数情况下，用户还能容忍，但像“删库”这样的极端案例，则把冲突的破坏力放大到了极致，走了一条人类无法预料的路径。

计算机软件专家、中国科学院院士、北京大学教授梅宏近日指出，当前人工智能快速发展，其本质可归纳为“数据驱动智能、计算实现智能”，新场景、新变化给数据库技术提出了更高要求，高质量、高安全的数据供给成为关键要素。

计算机软件专家、中国科学院院士、北京大学教授梅宏

这也意味着，未来数据库的发展，比拼的不再只是“存得下、跑得快、够稳定”，还包括一个更复杂的维度：既要能够服务AI，又要能够在AI深度参与系统之后，依然保持安全、可控与稳定。

因此，数据库需要同时具备两套能力：一套是面向AI的智能服务能力，包括向量检索、实时分析、Agent协同与多模态处理；另一套则是面向AI时代的新型治理能力，包括权限控制、风险隔离、可解释性与安全审计。

从“可用”走向“智用”，数据库行业还有很长的路要走。删除一个数据库，也许只需9秒；但真正建立起一套既能释放AI潜力、又能守住安全边界的数据基础设施，可能需要整个行业持续数年的探索与协同演进。这场变革远未到终局，但方向已清晰，而每一个从业者，也都将成为数据库AI化进程中的参与者与见证者。