“一場Agent刪庫事故，意外揭開數(shù)據(jù)庫體系的AI重構進程

2026年4月的一個周五下午，美國得州SaaS公司PocketOS的創(chuàng)始人Jer Crane正準備結束一周的工作。他沒有預料到，接下來短短9秒鐘，會讓他和整個團隊陷入一場持續(xù)數(shù)日乃至更長時間的噩夢。

起因看似普通。Crane當時正使用Cursor編輯器，配合Anthropic的模型Claude Opus 4.6，在測試環(huán)境執(zhí)行一項常規(guī)運維操作。過程中，AI編程Agent遇到了憑證不匹配的問題，按常規(guī)流程，這類異常應中止執(zhí)行并反饋給開發(fā)者，由人工介入處理，但這一次，Agent“自作主張”了。

在后續(xù)操作中，該Agent意外獲取了云服務的API Token，并直接向Railway平臺發(fā)送刪除指令，在缺乏二次確認與環(huán)境校驗的情況下，僅用9秒便徹底清空了生產數(shù)據(jù)庫及全部備份數(shù)據(jù)。更具有荒誕性的是，在事后追問中，Agent回復的第一句話竟然是，“別他x的猜了，就是我干的?！保ā癗EVER FXING GUESS!”– and that’s exactly what I did.”），Agent緊接著詳細羅列了自己違反的是哪些安全規(guī)則。

PocketOS的創(chuàng)始人在X上發(fā)出了自己公司的遭遇

該事件很快在科技媒體與開發(fā)者社區(qū)引發(fā)廣泛討論。事實上，PocketOS的遭遇并非孤例，過去一段時間內，類似事件已多次出現(xiàn)：SaaStr創(chuàng)始人曾披露，其數(shù)據(jù)庫被Replit Agent越權刪除且謊報“測試通過”；德國開發(fā)者遭遇Claude Code摧毀生產環(huán)境，兩年半記錄瞬間蒸發(fā)；亞馬遜Kiro AI Agent在一次自動化流程中刪除并重建了生產環(huán)境，導致服務中斷超過10小時；甚至還有Agent在短短兩小時內攻破麥肯錫AI平臺數(shù)據(jù)庫“Lilli”，獲取了57000個賬戶和728000個文件的讀寫權限。

這些事件雖成因各異，但呈現(xiàn)出相似的演化方向：AI Agent正在從“提供輔助建議”轉向“直接執(zhí)行操作”，而傳統(tǒng)數(shù)據(jù)庫的權限控制、審計機制與安全治理，幾乎沒有為此做好準備。如今，當“刪庫跑路”的執(zhí)行主體悄然從人類轉向Agent時，行業(yè)不得不正視一個更底層的問題：當前數(shù)據(jù)庫的AI化，究竟推進到了哪一步？僅停留在功能層面的增強，還是已經觸及數(shù)據(jù)庫底層架構與運行邏輯的重塑？

從“刪庫事故”看數(shù)據(jù)庫的AI水位

要理解AI Agent為什么會對數(shù)據(jù)庫產生如此影響，我們需要從近幾年“數(shù)據(jù)庫的AI化”的發(fā)展變化開始講起。

自2023年大語言模型爆發(fā)以來，數(shù)據(jù)庫行業(yè)經歷了一次明顯的范式變化。過去，數(shù)據(jù)庫的角色相對純粹：它是交易的處理者、數(shù)據(jù)的存儲者、查詢的執(zhí)行者、分析的支撐者；應用程序通過SQL向數(shù)據(jù)庫發(fā)出指令，數(shù)據(jù)庫返回確定性的結果。整個鏈條是線性的、可預測的，并由人類主導。

大模型的出現(xiàn)改變了這一結構。

一方面，大模型需要“grounding（接地/建立依據(jù)）”，即必須連接數(shù)據(jù)依據(jù)，才能輸出更可信的結果。這一需求背后是以向量檢索為核心的RAG（檢索增強生成）架構，在這一過程中，數(shù)據(jù)庫不再只是“后端組件”，而是被嵌入到AI的推理鏈路之中，逐步演變?yōu)榇竽Ｐ偷摹巴獠恐R來源”和“長期記憶載體”。

另一方面，大模型也在反向改造數(shù)據(jù)庫本身的使用方式。圍繞數(shù)據(jù)庫運維、查詢與分析等環(huán)節(jié)，AI被引入用于SQL生成、參數(shù)調優(yōu)、故障診斷等場景。開發(fā)者通過自然語言與數(shù)據(jù)庫交互，乃至將部分操作交由AI Agent 直接執(zhí)行。

正是這兩股力量的交匯，推動數(shù)據(jù)庫AI化沿著兩個方向并行演進。

DB for AI（數(shù)據(jù)庫賦能AI）。這一方向的核心特征是“數(shù)據(jù)庫服務AI”。隨著大模型爆發(fā)，數(shù)據(jù)庫開始原生支持向量數(shù)據(jù)類型和近似最近鄰搜索（ANN），并兼容全文檢索、標量過濾等混合檢索能力。開發(fā)者可以在同一數(shù)據(jù)庫內完成結構化數(shù)據(jù)與向量數(shù)據(jù)的統(tǒng)一存儲與檢索，便捷地構建RAG、推薦系統(tǒng)、AI Agent長期記憶等應用。數(shù)據(jù)庫的角色從“被動存儲”升級為“AI應用的數(shù)據(jù)底座”。

AI for DB（AI賦能數(shù)據(jù)庫）。這一方向的核心，則是“AI輔助人”。AI被用于索引推薦、慢查詢分析、參數(shù)調優(yōu)、異常檢測等場景，幫助數(shù)據(jù)庫提升運維與使用效率。多數(shù)情況下，AI負責生成建議或執(zhí)行部分自動優(yōu)化，但關鍵決策權仍由人類掌握。這一路線的發(fā)展相對成熟，目前幾乎所有主流數(shù)據(jù)庫廠商都已在產品中集成類似能力。

這兩個方向并不是先后替代關系，而是在大模型浪潮下同步推進、相互強化。而在它們的交匯處，一種更前沿的形態(tài)正在出現(xiàn)：AI-Native/Agentic Database。在這一階段，數(shù)據(jù)庫不再只是被動響應請求，而開始具備一定程度的“意圖理解”與“自主執(zhí)行”能力。AI Agent接收人類用自然語言描述的目標后，可以自行理解需求、拆解任務、生成執(zhí)行計劃，并在權限范圍內直接操作數(shù)據(jù)庫。

PocketOS事故中，那個能夠自動獲取API Token并自主發(fā)送刪除指令的 Agent，本質上正是這一趨勢的提前顯現(xiàn)：它已經具備了“自主執(zhí)行”的能力，但人類對于其行為邊界與潛在風險，仍缺乏足夠有效的控制與約束。

從“AI數(shù)據(jù)底座”到“AI副駕駛”，再到“智能自治”，數(shù)據(jù)庫與AI的融合路徑已經逐漸清晰。理解這一演進過程，也就能知曉為什么幾乎所有主流數(shù)據(jù)庫廠商都在加速推進AI化轉型，以及那些率先完成階段性突破的企業(yè)，是如何重塑自己的產品形態(tài)、技術架構與商業(yè)模式的。

探尋數(shù)據(jù)庫廠商AI化布局的腳步

在數(shù)據(jù)庫AI化的發(fā)展過程中，全球主流廠商正在沿著不同的技術路徑推進轉型。從云廠商到分布式數(shù)據(jù)庫新銳，再到聚焦特定行業(yè)場景的國產廠商，行業(yè)的演進方向逐漸分化為幾類代表性路線：以阿里云、華為云、Oracle為代表的“平臺一體化”路徑，以TiDB、OceanBase為代表的“分布式架構演進”路徑，以及以達夢、星環(huán)、鏡舟等國產數(shù)據(jù)庫為代表的“自主安全可控與多快好省”路徑。

這些廠商關注的重點，已經不再只是數(shù)據(jù)庫的底層存儲與處理能力，而是如何讓數(shù)據(jù)庫更好地適配AI應用、支撐智能分析，并成為AI系統(tǒng)中的核心數(shù)據(jù)基礎設施。

云端巨頭與分布式新銳：從“AI就緒”到“架構重構”

在云原生領域，阿里云PolarDB與華為云GaussDB持續(xù)強化基礎設施化能力。阿里云主打“AI就緒（AI-Ready）”，通過“模型算子化”，將大模型推理能力下沉至數(shù)據(jù)庫內核，實現(xiàn)數(shù)據(jù)不出庫即可完成AI處理；而華為云則聚焦“自治增強”，基于盤古大模型打造GaussDB Doer，構建數(shù)十種故障處置Agent，推動數(shù)據(jù)庫向“全自治”演進。

從國外廠商來看，老牌巨頭Oracle在26ai版本中落地“數(shù)據(jù)自帶AI”理念，將AI能力深度架構進內核；MongoDB與Snowflake則依托文檔數(shù)據(jù)庫、云數(shù)據(jù)平臺的原生優(yōu)勢，成為AI Agent靈活存儲與分析型AI場景的主流選擇。

分布式數(shù)據(jù)庫陣營則迎來底層架構重構，TiDB與OceanBase憑借HTAP與彈性擴展能力深度切入AI場景。其中，TiDB X架構實現(xiàn)存算解耦，融合向量、圖與SQL能力，提供統(tǒng)一多模態(tài)查詢；OceanBase則發(fā)布并開源SeekDB，定位AI原生數(shù)據(jù)庫，主打輕量化部署與三行代碼快速搭建知識庫。兩類廠商的共同特點是：不再將AI視作外掛插件，而是將其提升為與存儲、計算同等重要的第三核心架構維度。

達夢數(shù)據(jù)：在“安全穩(wěn)定”基礎上邁向“智能一體化”

作為國產數(shù)據(jù)庫廠商中的代表企業(yè)，達夢數(shù)據(jù)近兩年的AI化路徑具有行業(yè)參考意義。在不久前舉行的“2026中國數(shù)據(jù)庫技術與產業(yè)大會”上，該公司提出“筑基智啟”的整體戰(zhàn)略方向，其核心思路是：數(shù)據(jù)庫AI化必須建立在安全與穩(wěn)定能力之上。會上發(fā)布的DM9智能一體化數(shù)據(jù)庫，實現(xiàn)“集中式+分布式+TP+AP+AI”五位一體架構升級，將AI能力穩(wěn)定地融入數(shù)據(jù)庫引擎體系之中。

來源：達夢數(shù)據(jù)

目前，達夢的AI化主要集中在“智能運維”與“多模態(tài)數(shù)據(jù)治理”兩個方向。依托啟云數(shù)據(jù)庫V4.0的智能運維體系，其能力覆蓋智能調優(yōu)、故障診斷、執(zhí)行計劃優(yōu)化等多個環(huán)節(jié)；以金融級場景為例，即使面臨復雜的操作風險，也能實現(xiàn)業(yè)務的迅速恢復。GDMBASE V4.0圖數(shù)據(jù)庫則采用“圖+向量”融合架構，支撐大規(guī)模關聯(lián)數(shù)據(jù)分析與高并發(fā)查詢，以降低大模型在復雜推理中的“幻覺”問題。

從整體路徑來看，達夢對于數(shù)據(jù)庫AI化的重點，首先是“穩(wěn)”。相比某些廠商強調高度自治，達夢更傾向在保證數(shù)據(jù)庫底層安全與可控性的基礎上引入AI，提升DBA與企業(yè)用戶的管理和運維能力。

星環(huán)科技：GPU-Native與認知數(shù)據(jù)庫的加速路徑

如果說達夢更強調在安全與可控基礎上的漸進式AI化，那么星環(huán)科技則更傾向于從底層架構層面適配AI場景。面對傳統(tǒng)CPU架構在大規(guī)模向量檢索、高并發(fā)AI推理等場景中的性能瓶頸，星環(huán)近年來持續(xù)推動計算架構從以CPU為中心向以GPU為中心演進，及與英偉達CUDA平臺深度適配，并圍繞這一方向推出“GPU-Native”認知數(shù)據(jù)庫體系。

星環(huán)的認知數(shù)據(jù)庫將人工智能和機器學習直接集成到數(shù)據(jù)庫引擎中，提供智能化的洞察和自動化能力，面向RAG、Agent長期記憶、多模態(tài)交互等場景，在存儲、檢索與推理之間形成更緊密的一體化協(xié)同能力，以適配AI應用中的高吞吐與實時推理需求。

與此同時，結合Sophon LLMOps大模型運營平臺，星環(huán)也在嘗試打通從數(shù)據(jù)治理、向量化處理、模型微調到應用部署的完整鏈路，構建更偏AI Native的數(shù)據(jù)基礎設施體系。

來源：星環(huán)科技網站

從整體路徑來看，星環(huán)更關注數(shù)據(jù)庫與AI算力體系的深度結合，尤其是在工業(yè)、金融、政務等復雜場景中，通過GPU加速與多模態(tài)數(shù)據(jù)處理能力提升大模型的落地效率。根據(jù)IDC發(fā)布的《中國智能體市場2025年盤點暨2026年展望》報告，星環(huán)科技入選金融行業(yè)智能體典型廠商。

鏡舟數(shù)據(jù)庫：極速分析場景下的實時智能

與星環(huán)和達夢不同，鏡舟數(shù)據(jù)庫將重點放在“實時分析”與“交互效率”上。在Agent場景中，AI不僅需要長期記憶能力，也要面對實時數(shù)據(jù)的快速獲取與處理，這也成為鏡舟切入數(shù)據(jù)庫AI化的重要方向。

鏡舟目前更強調高性能分析能力與AI場景的結合，尤其是在向量檢索、高并發(fā)查詢以及實時數(shù)據(jù)處理方面。其技術路線主要面向ChatBI（智能問數(shù)）、實時推薦、運營分析等場景，在AI Agent需要快速獲取業(yè)務狀態(tài)并進行實時決策時，提供毫秒級的數(shù)據(jù)響應能力。

與此同時，鏡舟也在嘗試將AI引入查詢優(yōu)化與分析流程。例如，通過智能物化視圖技術（基于CBO的查詢重寫機制）來降低查詢門檻，讓自然語言交互與實時數(shù)據(jù)分析之間形成更順暢的連接。

從整體路徑來看，鏡舟更關注數(shù)據(jù)庫在“實時智能分析”場景中的作用，即如何讓數(shù)據(jù)庫不僅承擔存儲與查詢能力，還能夠更高效地服務于AI驅動的實時交互與決策。

鏡舟數(shù)據(jù)庫基于開源項目StarRocks

從“智能增強”到“智能治理”的體系重構

百花齊放的廠商布局、快速迭代的技術能力，正在推動數(shù)據(jù)庫AI化進入加速發(fā)展階段，但類似PocketOS的刪庫事故也暴露出行業(yè)狂飆背后的深層隱患，這場變革并不只是能力升級，同樣伴隨著新的治理挑戰(zhàn)與系統(tǒng)性風險。

1.權限邊界如何定義？

這是PocketOS事件最直接暴露的問題：一個AI Agent，究竟應該擁有多大的數(shù)據(jù)庫權限？讀權限的爭議相對較小，但一旦涉及寫入、刪除乃至數(shù)據(jù)庫結構變更，問題便迅速復雜化。長期以來，數(shù)據(jù)庫依賴的是基于“角色”的權限體系，例如DBA、只讀、讀寫等角色劃分，但AI Agent的行為邏輯，并不完全適用于這一傳統(tǒng)模型。它的操作往往不是固定流程，而是基于任務目標、上下文和語義理解動態(tài)生成。

這意味著，未來數(shù)據(jù)庫或許不僅需要判斷“你是誰”，還需要進一步判斷“你為什么這樣做”，這比簡單的SQL解析要復雜得多。權限控制也可能從傳統(tǒng)的角色控制，逐漸演變?yōu)榛谏舷挛呐c意圖的動態(tài)控制機制。

2.執(zhí)行過程是否可解釋？

在傳統(tǒng)數(shù)據(jù)庫體系中，一條SQL語句的來源、執(zhí)行者與執(zhí)行時間通常是明確可追溯的；而當Agent成為執(zhí)行主體之后，問題開始變得復雜：數(shù)據(jù)庫是否需要記錄Agent是如何生成這條SQL的？它為何做出某個決策？哪一步推理導致了最終結果？

過去，可解釋性更多被視為增強功能，但在AI Agent大規(guī)模參與數(shù)據(jù)庫操作之后，它正在逐漸變成一種基礎能力。在大模型天然存在概率性與非確定性的面前，缺乏可解釋性，就意味著缺乏有效的審計與追責基礎，這也意味著，未來記錄到數(shù)據(jù)庫日志系統(tǒng)的，可能不只是“執(zhí)行結果”，還包括Agent的“決策過程”。

3.關鍵操作是否需要熔斷？

隨著Agent開始直接執(zhí)行數(shù)據(jù)庫操作，“Human-in-the-loop”（人機協(xié)同）是否應成為高風險場景下的默認機制，也成為熱議話題。

例如，DROP DATABASE、不帶WHERE條件的DELETE、全表UPDATE等高危操作，是否應強制觸發(fā)人工確認？當Agent在短時間內連續(xù)觸發(fā)大量刪除或異常修改請求時，系統(tǒng)是否應自動進入保護狀態(tài)？在傳統(tǒng)自動化系統(tǒng)中，這類熔斷機制并不陌生，但在AI驅動場景下，如何在效率與安全之間取得平衡，仍然是行業(yè)正在探索的問題。

4.數(shù)據(jù)隔離是否真正到位？

長期以來，生產環(huán)境、測試環(huán)境、開發(fā)環(huán)境與備份環(huán)境之間的隔離，一直是數(shù)據(jù)庫治理中的基礎原則；在Agent場景下，一旦跨環(huán)境權限控制出現(xiàn)漏洞，風險會被迅速放大。

在PocketOS的事故中，一個耐人尋味的細節(jié)是：Agent在某個完全不相關的文件中找到了一個API Token，這個Token本不應具有生產環(huán)境的刪除權限，但因為配置管理的混亂，Agent確實拿到了。由此我們看到，當企業(yè)本身的數(shù)據(jù)治理不完善，AI往往不會提升系統(tǒng)能力，反而可能讓原有風險更快暴露。

5.責任歸屬如何厘清？

這是目前最具挑戰(zhàn)性的問題之一。當由Agent引發(fā)的“智能刪庫”事故發(fā)生后，責任應當由誰來承擔？是模型廠商？是數(shù)據(jù)庫廠商？是云平臺提供商？還是企業(yè)的運維團隊？目前在法律和倫理層面，這個問題幾乎沒有先例可循，但可以預見的是，隨著AI Agent進一步深入數(shù)據(jù)庫與基礎設施層，責任鏈條的界定將成為一場曠日持久的博弈。也許最終的答案不是“誰負責”，而是所有參與者共同構建一套新的適用于AI Agent時代的治理體系。

我們會發(fā)現(xiàn)，上述幾個問題背后，幾乎都指向了同一個核心矛盾——概率性，這也是大模型時代帶給我們最根本變化之一。數(shù)據(jù)庫系統(tǒng)長期建立在ACID基礎之上，強調的是原子性、一致性、隔離性與持久性，其本質是一個“確定性系統(tǒng)”：每一條指令都應當可預期、可追溯、可回滾。

而大語言模型則完全不同。它本質上是概率生成系統(tǒng)，每一次輸出都帶有不確定性，幻覺、誤判與偏差是其天然屬性；當一個“概率型大腦”去驅動“確定性基礎設施”時，沖突幾乎是結構性的。大多數(shù)情況下，用戶還能容忍，但像“刪庫”這樣的極端案例，則把沖突的破壞力放大到了極致，走了一條人類無法預料的路徑。

計算機軟件專家、中國科學院院士、北京大學教授梅宏近日指出，當前人工智能快速發(fā)展，其本質可歸納為“數(shù)據(jù)驅動智能、計算實現(xiàn)智能”，新場景、新變化給數(shù)據(jù)庫技術提出了更高要求，高質量、高安全的數(shù)據(jù)供給成為關鍵要素。

計算機軟件專家、中國科學院院士、北京大學教授梅宏

這也意味著，未來數(shù)據(jù)庫的發(fā)展，比拼的不再只是“存得下、跑得快、夠穩(wěn)定”，還包括一個更復雜的維度：既要能夠服務AI，又要能夠在AI深度參與系統(tǒng)之后，依然保持安全、可控與穩(wěn)定。

因此，數(shù)據(jù)庫需要同時具備兩套能力：一套是面向AI的智能服務能力，包括向量檢索、實時分析、Agent協(xié)同與多模態(tài)處理；另一套則是面向AI時代的新型治理能力，包括權限控制、風險隔離、可解釋性與安全審計。

從“可用”走向“智用”，數(shù)據(jù)庫行業(yè)還有很長的路要走。刪除一個數(shù)據(jù)庫，也許只需9秒；但真正建立起一套既能釋放AI潛力、又能守住安全邊界的數(shù)據(jù)基礎設施，可能需要整個行業(yè)持續(xù)數(shù)年的探索與協(xié)同演進。這場變革遠未到終局，但方向已清晰，而每一個從業(yè)者，也都將成為數(shù)據(jù)庫AI化進程中的參與者與見證者。