seekdb D0：讓AI Agent零門檻擁有自己的數(shù)據(jù)庫

Agent 應(yīng)用正在爆發(fā)，可以寫代碼、做分析、搭應(yīng)用——但它做不了一件事：注冊一個數(shù)據(jù)庫賬號。

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

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

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

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

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

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

傳統(tǒng)數(shù)據(jù)庫為什么對 Agent 不友好

要理解 seekdb D0 在解決什么問題，我們得先看看現(xiàn)有數(shù)據(jù)庫服務(wù)對 Agent 有多不友好。

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

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

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

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

最后是文檔與接口的割裂。傳統(tǒng)數(shù)據(jù)庫的文檔是為人類編寫的——PDF、HTML、視頻教程。Agent 無法直接「閱讀」這些內(nèi)容并轉(zhuǎn)化為操作。它需要的是結(jié)構(gòu)化的、可直接調(diào)用的接口描述。

這些問題的本質(zhì)是：傳統(tǒng)數(shù)據(jù)庫是為「人機交互」設(shè)計的，而不是為「機機交互」設(shè)計的。seekdb D0 要做的，就是把這個設(shè)計假設(shè)翻過來。

一個 URL 解決所有問題

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

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

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

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

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

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

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

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

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

零門檻是怎么落地的

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

在這個架構(gòu)上，對外暴露四個關(guān)鍵接口：

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

SKILL.md：服務(wù)自描述

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

Fork Instance = 毫秒級分叉

對 Agent 來說，這意味著可以在毫秒內(nèi)把一份完整的數(shù)據(jù)庫狀態(tài)交給下一個環(huán)節(jié)，而不需要mysqldump再導入。

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

裝在「小樣」里的三件事

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

MySQL 兼容：接上就能用

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

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

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

AI Search：一張表，三種搜索

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

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

seekdb 把這些能力統(tǒng)一到單一系統(tǒng)中。

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

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

純關(guān)鍵詞，中文直接上 IK 分詞器：

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

兩者都要？混合搜索一次出結(jié)果，boost調(diào)權(quán)重：

SET @params = '{    "query": { "query_string": { "fields": ["content"], "query": "向量數(shù)據(jù)庫", "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));

單一查詢、單一事務(wù)、單一結(jié)果集。這不僅簡化了應(yīng)用代碼，更重要的是保證了數(shù)據(jù)一致性——你不需要擔心向量庫和關(guān)系庫之間的同步延遲。

讓我用一個具體場景來說明這種統(tǒng)一的價值。假設(shè)你在構(gòu)建一個智能客服系統(tǒng)的 RAG 模塊，用戶問：「上海徐匯區(qū)附近有哪些關(guān)于退款政策的文檔？」

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

在傳統(tǒng)架構(gòu)中，這需要三次不同系統(tǒng)的查詢，然后在應(yīng)用層做結(jié)果合并和排序。而在 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 中可用。

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

Branch：給 Agent 一個安全的沙箱

最后是安全的數(shù)據(jù)操作空間。

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

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

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

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

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 上隨便折騰，主表穩(wěn)如狗。Diff 之后人工確認，再 Merge 回去——既給了 Agent 充分的自主空間，又保留了人在關(guān)鍵節(jié)點介入的能力。

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

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

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

Branch 的幾個實用場景

數(shù)據(jù)分支在 AI 開發(fā)中有幾個特別有價值的應(yīng)用場景，這里展開說說。

Prompt 工程的 A/B 測試

假設(shè)你在優(yōu)化 RAG 系統(tǒng)的檢索策略，有兩個候選方案：方案 A 使用純向量檢索，方案 B 使用向量 + 全文混合檢索。

傳統(tǒng)做法是準備兩套測試數(shù)據(jù)集，或者順序執(zhí)行測試。使用 seekdb 的分支能力，你可以快速創(chuàng)建兩個并行測試環(huán)境：

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

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

Agent 工具鏈的安全沙箱

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

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

快速回滾與數(shù)據(jù)快照

AI 應(yīng)用經(jīng)常需要進行數(shù)據(jù)修正——比如更新知識庫、調(diào)整向量嵌入、修改元數(shù)據(jù)。傳統(tǒng)方案需要手動備份或依賴復雜的事務(wù)管理。

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

為什么 Fork 可以這么快？

seekdb 的數(shù)據(jù)分支能力基于 LSM-Tree 存儲引擎的天然優(yōu)勢。

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

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

seekdbD0 的定位與邊界

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

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

seekdb D0 最適合的場景

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

• Demo 演示與教程，為技術(shù)分享、客戶演示準備臨時環(huán)境；

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

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

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

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

如果需要生產(chǎn)級部署，可以部署開源 seekdb 或使用 OceanBase 云服務(wù)。

如果你正在做 Agent 應(yīng)用，想快速驗證一個想法，可以現(xiàn)在就試試：

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 上拉源碼直接跑，完整能力不受限制

• 聯(lián)系 OceanBase 團隊：如果你的場景需要云服務(wù)、更大規(guī)模或定制化支持，我們愿意一起探索更多可能性

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

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

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