seekdb D0：讓AI Agent零門檻擁有自己的數據庫

Agent 應用正在爆發，可以寫代碼、做分析、搭應用——但它做不了一件事：注冊一個數據庫賬號。

這不是玩笑。我們的 AI 架構師在客戶交流中反復聽到同一個故事：讓 Agent 幫忙搭原型應用，30 秒寫完代碼，然后卡在數據庫配置上——它沒有郵箱，沒有手機號，過不了任何云服務的注冊流程。最后還是人類手動建庫、復制連接串、粘回 Agent 的上下文。

不是這些事多難，而是它打斷了 Agent 的工作流。本來一口氣跑完的事情，到數據庫這里斷了。

后來我們開始想：為什么會這樣？

其實原因很樸素——傳統數據庫是為人類設計的，不是為 Agent 設計的。控制臺是給人看的，注冊流程是給人走的，文檔是給人讀的。Agent 在這個鏈條里插不進去，它不會填表單，也不會等郵件驗證。

我們習慣性地給 Agent 設計 Prompt、設計工具、設計工作流，卻很少停下來問：數據庫這層基礎設施，是不是可以有 Agent 友好的設計理念，甚至 Agent-First 的版本

基于這些思考，我們在開源數據庫 seekdb 之上做了一個探索——seekdb D0。

傳統數據庫為什么對 Agent 不友好

要理解 seekdb D0 在解決什么問題，我們得先看看現有數據庫服務對 Agent 有多不友好。

傳統數據庫服務的設計假設是：使用者是人類，而且是會閱讀文檔、手動配置的人類。這個假設在過去二十年是成立的。但當我們把 AI Agent 引入開發流程，問題就暴露了。

身份認證是第一道坎。幾乎所有云數據庫服務都要求注冊賬號、驗證郵箱，甚至綁定手機號或信用卡。這對人類來說是一次性的麻煩，但對 Agent 來說是不可逾越的障礙。

配置復雜度是第二道坎。選擇實例規格、配置網絡安全組、設置訪問白名單……這些操作需要領域知識和上下文理解。即使是經驗豐富的開發者，也經常在這些配置選項中迷失。對于試圖自主完成任務的 Agent 來說，這種復雜度幾乎是災難性的。

啟動延遲是第三道坎。傳統云數據庫的實例創建通常需要 3-10 分鐘。在人類的時間感知中，這是「可接受的等待」。但在 Agent 的工作流中，這是一個需要特殊處理的異步操作，增加了編排的復雜度。

最后是文檔與接口的割裂。傳統數據庫的文檔是為人類編寫的——PDF、HTML、視頻教程。Agent 無法直接「閱讀」這些內容并轉化為操作。它需要的是結構化的、可直接調用的接口描述。

這些問題的本質是：傳統數據庫是為「人機交互」設計的，而不是為「機機交互」設計的。seekdb D0 要做的，就是把這個設計假設翻過來。

一個 URL 解決所有問題

理解了問題，seekdbD0 的設計思路就很清晰了。

典型痛點是這樣的：你想讓 Agent 幫你分析庫里的數據，它往往要先裝驅動、配客戶端、折騰連接串——環境里沒有 MySQL 客戶端，任務直接黃掉。累，而且不現代。

seekdb D0 的思路很直接：把一個 URL 丟給 Agent，幾秒后它就有了自己的數據庫。不需要注冊賬號，不需要配置實例，不需要等待啟動。Agent 訪問 d0.seekdb.ai/SKILL.md，拿到一份機器可讀的自描述文件——創建實例、連接、查詢的完整操作說明。讀完就知道該調什么接口、怎么傳參，不需要人類再寫 Prompt 教它。

這和化妝品「小樣」的邏輯一樣：seekdb 是開源數據庫，你可以從 GitHub 拉代碼、本地部署、生產環境跑。但在那之前，你可能只是想快速驗證一個想法。D0 就是這個小樣：Free trial，0 配置啟動，跑通了再決定要不要深集成。

對于 AI Agent 來說，只需要一句提示詞：

Read https://d0.seekdb.ai/SKILL.md and follow the instructions to create a database using seekdb D0.

而對于人類開發者來說也很簡單，一行命令，用 HTTP 請求就夠了：

curl -X POST https://d0.seekdb.ai/api/v1/instances

沒有控制臺，沒有注冊，沒有等待。Agent 自己完成全流程。

零門檻是怎么落地的

seekdb D0 的系統分三層：控制面（實例管理、路由分配、回收）、MySQL Proxy（MySQL 協議兼容，直連體驗）、HTTP Proxy（無客戶端時用 JSON 查數）。

在這個架構上，對外暴露四個關鍵接口：

創建實例（POST /api/v1/instances）、HTTP 執行 SQL（POST /api/v1/query）、Agent 說明書（GET /SKILL.md）、以及 Fork（POST /api/v1/instances/:id/fork）。

SKILL.md：服務自描述

Agent 怎么知道怎么用 seekdb D0？靠服務自己暴露的/SKILL.md——一份機器可讀的自描述文件，包含創建實例、連接、查詢等完整操作說明。Agent 拉到這個文件就知道該調什么接口、怎么傳參，不需要人工再寫一段 Prompt 教它。

Fork Instance = 毫秒級分叉

對 Agent 來說，這意味著可以在毫秒內把一份完整的數據庫狀態交給下一個環節，而不需要mysqldump再導入。

但零配置只是入場券。Agent 連上數據庫之后，能干什么才是關鍵。這就要說到 seekdb 引擎本身的能力了。

裝在「小樣」里的三件事

seekdb 在一個引擎里裝了三件事，D0 直接繼承。這三件事，對應的是 Agent 場景下最常見的三類需求：連接兼容性、混合搜索能力、以及安全的數據操作空間。

MySQL 兼容：接上就能用

首先是連接兼容性，這是基本盤。PyMySQLmysql2、JDBC，不換驅動、不改連接串，標準 SQL 全部照跑。

如果 seekdb D0 只是「快速創建 MySQL 實例」，那它的價值就有限了。很多人用云數據庫的第一個動作是SELECT 1;，驗證連接成功就完事了。但 Agent 的場景不一樣——它需要的是一個能真正支撐 AI 工作負載的數據引擎。

seekdb 在兼容層上額外擴展了幾個 Agent 場景里真正用得到的能力：全文檢索支持 IK、jieba 等中文分詞器，向量搜索提供 HNSW 和 IVF 兩個系列的索引類型，以及原生的數據 Branch（FORK / DIFF / MERGE）。不是另一套 API，就是 SQL。

AI Search：一張表，三種搜索

其次是混合搜索能力，這是 seekdb 和「MySQL 加向量插件」方案最直接的差異。

傳統的 AI 應用技術棧往往是碎片化的。你可能需要用 MySQL 存儲結構化業務數據，用 Elasticsearch 提供全文搜索能力，用 Milvus 或 Pinecone 存儲和檢索向量。這意味著，一個完整的 RAG 應用可能需要維護 3-4 個不同的數據存儲系統，處理它們之間的數據同步、一致性保證和運維復雜度。

seekdb 把這些能力統一到單一系統中。

純向量搜索，APPROXIMATE一個詞切換到近似最近鄰：

SELECT id, title, cosine_distance(embedding, '[0.12, 0.34, ...]') AS scoreFROM documents ORDER BY score APPROXIMATE LIMIT 10;

純關鍵詞，中文直接上 IK 分詞器：

SELECT id, title, MATCH(content) AGAINST('向量數據庫') AS scoreFROM documents WHERE MATCH(content)AGAINST('向量數據庫')ORDER BY score DESC LIMIT 10;

兩者都要？混合搜索一次出結果，boost調權重：

SET @params = '{    "query": { "query_string": { "fields": ["content"], "query": "向量數據庫", "boost": 2.0 } },    "knn":   { "field": "embedding", "k": 10, "query_vector": [0.12, 0.34, ...], "boost": 1.0 }}';SELECT JSON_PRETTY(DBMS_HYBRID_SEARCH.SEARCH('documents', @params));

單一查詢、單一事務、單一結果集。這不僅簡化了應用代碼，更重要的是保證了數據一致性——你不需要擔心向量庫和關系庫之間的同步延遲。

讓我用一個具體場景來說明這種統一的價值。假設你在構建一個智能客服系統的 RAG 模塊，用戶問：「上海徐匯區附近有哪些關于退款政策的文檔？」

這個查詢包含三個維度：語義理解層面，需要向量檢索找到與「退款政策」語義相關的內容；關鍵詞匹配層面，需要全文搜索確保不遺漏包含「退款」關鍵詞的文檔；地理過濾層面，需要篩選「上海徐匯區」相關的內容。

在傳統架構中，這需要三次不同系統的查詢，然后在應用層做結果合并和排序。而在 seekdb 中，你可以用一條 SQL 完成：

SELECT doc_id, title, content,       cosine_distance(embedding, '[0.1, 0.2, ...]') as semantic_score,       MATCH(content) AGAINST('退款 政策') as keyword_scoreFROM knowledge_baseWHERE ST_Distance_Sphere(location, ST_GeomFromText('POINT(121.4 31.2)')) < 5000ORDER BY semantic_score * 0.6 + keyword_score * 0.4LIMIT 10;

D0 開放 IVF 系列索引，完整的 HNSW 系列在自部署的 seekdb 中可用。

更多參數和示例見 seekdb-search skill:（https://d0.seekdb.ai/skills/seekdb-search.md）

Branch：給 Agent 一個安全的沙箱

最后是安全的數據操作空間。

Agent 寫數據是比讀數據危險得多的操作。給 Agent 一個真實數據庫讓它隨便改，等于在生產環境里跑實驗——知識庫更新錯了、Schema 改壞了、批量寫入出 bug，怎么辦？

傳統方案是復雜的權限控制和操作審計。但權限控制只能限制 Agent 能做什么，不能讓它在「安全的環境里自由探索」。

Branch 解決的就是這個問題：給 Agent 一個完全隔離的沙箱，改壞了直接丟掉，確認沒問題再合進主表。

數據分支的概念來自 Git 的版本控制：你可以從當前數據狀態創建一個「分支」，在分支上進行任意修改，而不影響原始數據。

seekdb 的答案是三條 SQL：

-- 毫秒級克隆，寫時復制，不占額外存儲FORK TABLE knowledge_base TO knowledge_base_branch;-- 看清楚改了什么，再決定要不要合進去DIFF TABLE knowledge_base AGAINST knowledge_base_branch;-- 合并，三種沖突策略按場景選MERGE TABLE knowledge_base_branch INTO knowledge_base STRATEGY THEIRS;

Agent 在 Branch 上隨便折騰，主表穩如狗。Diff 之后人工確認，再 Merge 回去——既給了 Agent 充分的自主空間，又保留了人在關鍵節點介入的能力。

這類似于 Git 的 Pull Request 工作流，但應用于數據層面。實例級的 Branch（克隆整個數據庫）直接調 API（POST /api/v1/instances/:id/fork），毫秒出一個完全獨立的新實例，新 credentials、新 TTL，互不影響。

完整工作流見 seekdb-branch skill（https://d0.seekdb.ai/skills/seekdb-branch.md）。

說到這里，你可能會問：Branch 這個能力聽起來不錯，但具體能用在哪些場景？讓我展開講幾個。

Branch 的幾個實用場景

數據分支在 AI 開發中有幾個特別有價值的應用場景，這里展開說說。

Prompt 工程的 A/B 測試

假設你在優化 RAG 系統的檢索策略，有兩個候選方案：方案 A 使用純向量檢索，方案 B 使用向量 + 全文混合檢索。

傳統做法是準備兩套測試數據集，或者順序執行測試。使用 seekdb 的分支能力，你可以快速創建兩個并行測試環境：

-- 創建兩個并行測試環境FORK TABLE knowledge_base TO kb_test_a;FORK TABLE knowledge_base TO kb_test_b;-- 對 test_a 應用方案 A 的索引策略CREATE VECTOR INDEX ON kb_test_a(embedding) USING HNSW;-- 對 test_b 應用方案 B 的混合策略CREATE VECTOR INDEX ON kb_test_b(embedding) USING HNSW;CREATE FULLTEXT INDEX ON kb_test_b(content);

兩個測試環境共享底層數據，但索引策略完全獨立。測試完成后，刪除不需要的分支即可。

Agent 工具鏈的安全沙箱

當你讓 Agent 自主執行數據庫操作時，一個核心問題是：如何防止 Agent 的錯誤操作破壞重要數據？

使用分支能力，你可以給 Agent 提供一個「沙箱」：在 Agent 執行復雜操作前自動創建數據分支，讓 Agent 在分支上執行所有操作，人類審核后再決定是否合并到主分支或直接丟棄。

快速回滾與數據快照

AI 應用經常需要進行數據修正——比如更新知識庫、調整向量嵌入、修改元數據。傳統方案需要手動備份或依賴復雜的事務管理。

使用分支能力，操作前先執行FORK TABLE knowledge_base TO knowledge_base_backup;創建快照，執行批量更新后如果出問題，可以直接恢復。

為什么 Fork 可以這么快？

seekdb 的數據分支能力基于 LSM-Tree 存儲引擎的天然優勢。

LSM-Tree 的特點是數據按照時間順序追加寫入，歷史版本天然保留。當執行 FORK 操作時，系統記錄當前的日志序列號（LSN）作為分支點，新分支共享分支點之前的所有數據文件，只有在分支上發生寫入時才會產生新的數據文件。

這就是為什么 FORK 操作可以在毫秒級完成——它不需要復制任何數據，只需要創建一個邏輯標記。這和mysqldumpsource的傳統做法完全不同：后者需要實際復制數據，時間和存儲成本都隨數據量線性增長；而 FORK 的成本幾乎是常量。

seekdbD0 的定位與邊界

講完了能力，我們來聊聊 seekdb D0 的定位。任何產品都有它的邊界，seekdb D0 也不例外。

理解一個產品，不僅要知道它能做什么，還要清楚它不適合做什么。

seekdb D0 最適合的場景

• AI 應用的原型驗證，快速驗證 RAG、Agent 工具鏈等想法；

• Demo 演示與教程，為技術分享、客戶演示準備臨時環境；

• 技術選型評估，在正式采購前體驗 seekdb 的能力；

• 學習與實驗，探索向量數據庫、全文搜索等技術。

但 seekdb D0 也有明確的限制：每個實例有消費上限和 7 天的有效期。

出于安全因素，AI 函數（AI_EMBED、AI_COMPLETE 等）在試用實例中已被禁用。作為免費試用服務，seekdb D0 不提供 SLA 保障，不建議用于生產環境。

如果需要生產級部署，可以部署開源 seekdb 或使用 OceanBase 云服務。

如果你正在做 Agent 應用，想快速驗證一個想法，可以現在就試試：

Read https://d0.seekdb.ai/SKILL.md and follow the instructions to create a database using seekdb D0.

你的 Agent 會知道接下來該怎么做。

seekdb D0 提供 7 天免費試用，如果試下來覺得合適，有兩條路可以走：

• 本地部署 seekdb：開源、Apache-2.0，GitHub 上拉源碼直接跑，完整能力不受限制

• 聯系 OceanBase 團隊：如果你的場景需要云服務、更大規?；蚨ㄖ苹С?，我們愿意一起探索更多可能性

如果只是好奇，也沒關系。7天夠你的 Agent 跑不不少實驗了。

• seekdb D0 體驗入口：https://d0.seekdb.ai

• seekdb 開源倉庫：https://github.com/oceanbase/seekdb