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
