seekdb：AI Agent 时代的状态存储引擎

在 AI Agent 的工作流里，有一个被长期忽视却至关重要的挑战：Agent 的"记忆"该怎么存、怎么查？ 每次 Agent 执行动作时产生观测数据（observations），需要立即写入存储；下一秒，同一个 Agent 又要根据这些记忆做出下一个决策。这种"边写边读、持续并发"的访问模式，和传统数据库面向批量写入或定期查询的设计完全不同。

seekdb 正是为解决这个场景而生的数据库引擎——由蚂蚁集团旗下 OceanBase 团队开源，专门面向 AI Agent 工作流打造，被称为"AI 原生状态存储"（AI-native state store）。它于 2025 年正式发布，在 GitHub 上迅速积累了近 2700 颗星，成为 Agent 基础设施领域的热门项目。

背景：从 OceanBase 到 Agent 专用存储

OceanBase 最初是蚂蚁集团为支撑双十一等海量交易场景研发的分布式数据库，已在支付宝、淘宝、滴滴、小米等生产环境中稳定运行多年。其核心 SQL 引擎经过十年以上的工程打磨，具备完整的 ACID 事务能力、MySQL 协议兼容性和成熟的优化器。

然而，随着大模型和 AI Agent 技术的兴起，团队发现 Agent 工作流的存储需求与OLTP场景存在显著差异：Agent 需要持续写入向量数据、需要毫秒级的相似性检索、需要为每一次"实验"创建隔离的沙盒环境——这些都不是传统数据库的强项。

于是，OceanBase 团队在 OceanBase 内核基础上，针对 Agent 场景做了深度定制，衍生出了 seekdb 这个独立项目。它保留了 OceanBase 成熟 SQL 引擎和 MySQL 协议兼容性，同时引入了专为 Agent 设计的新特性：异步索引管道、两级 HNSW 向量索引、写时复制（COW）沙盒机制，以及混合搜索能力。

核心特性：三个维度重塑 Agent 存储

1. 流式写入 + 即时检索：异步双层 HNSW 架构

传统向量数据库在持续写入时面临一个根本矛盾：索引构建是 CPU 密集型操作，会阻塞写入线程，导致 P99 延迟急剧上升——在高并发写入 + 即时查询的 Agent 场景下，这个矛盾尤为突出。

seekdb 的解决方案是异步双层 HNSW 索引管道。写入路径（Change Stream）将 DML 操作与索引构建完全解耦：数据提交后立即返回，不等待索引构建完成。与此同时，异步消费者从 redo log 中读取变更，实时更新增量 HNSW 索引层（Delta HNSW）。查询时，同时命中 Delta 层和快照层（Snapshot HNSW），用细粒度读锁保护并发访问。

官方 benchmark 数据印证了这条路径的有效性：在持续写入 + 并发检索的混合负载下，seekdb 达到 1,523 QPS，P99 延迟仅 21.7ms，分别是 Milvus 的 10.7 倍和 Elasticsearch 的 3.2 倍。更关键的是，随着并发数增加，seekdb 的 P99 抖动幅度约为 1.1 倍，而 Milvus/ES 的抖动高达约 10 倍——这对 Agent 的确定性体验至关重要。

2. COW 沙盒：让 Agent 大胆探索、安全回滚

AI Agent 在执行任务时，往往需要"试错"——尝试不同的工具调用序列，观察哪种方案效果更好。传统做法是在应用层维护快照或使用版本控制系统，操作繁琐且粒度粗糙。

seekdb 借助内核级写时复制（Copy-on-Write） 机制，提供了数据库级别的沙盒能力：

-- 毫秒级快照整个数据库，无数据复制
FORK DATABASE agent_state TO agent_sandbox_42;

-- Agent 在隔离沙盒中自由实验
USE agent_sandbox_42;
INSERT INTO memory (session_id, embedding, content) VALUES (...);

-- 接受实验结果（支持策略：FAIL / THEIRS / OURS）
MERGE TABLE agent_sandbox_42.memory INTO agent_state.memory STRATEGY THEIRS;
-- 或者直接丢弃，干净利落
DROP DATABASE agent_sandbox_42;

FORK DATABASE 在秒级完成快照，不复制任何实际数据——利用文件系统 COW 机制实现零成本分支。Agent 可以在沙盒中任意写入、查询甚至破坏表结构，最终通过 MERGE TABLE 将有效工作合并回主线，或者直接 DROP DATABASE 丢弃一切。这是传统数据库无法提供的内核级 Agent 编程范式。

3. 混合搜索：一条 SQL 完成向量 + 全文 + 标量联合检索

大多数 RAG（检索增强生成）系统需要拼接多个步骤：用向量数据库做语义检索，用全文搜索引擎做关键词匹配，最后在应用层合并结果。这带来了 N+1 查询问题、结果排名不一致和维护复杂度。

seekdb 在 SQL 执行引擎层面打通了三种检索模式：

SELECT id, title, l2_distance(emb, '[0.12,0.34,...]') AS dist
FROM docs
WHERE MATCH(content) AGAINST('quarterly report')  -- 全文检索
  AND author_id = 42                               -- 标量过滤
  AND created_at > '2026-01-01'
ORDER BY dist APPROXIMATE LIMIT 10;               -- 向量近似搜索

向量相似度、全文关键词匹配、标量条件过滤，在一条 SQL 内完成优化器级别的执行计划下推（push-down），避免了应用层拼接，查询延迟从"多系统串行调用"降至"单引擎内联执行"。

技术架构：C++ 内核 + Python SDK 的双层设计

seekdb 的主体代码使用 C++ 编写，基于 OceanBase 成熟的内核，包含完整的 SQL 解析器、优化器、存储引擎和事务管理器。代码组织在清晰的模块化结构中：

• src/observer/ — 主服务进程
• src/sql/ — SQL 引擎（解析、优化、执行）
• src/storage/ — 存储引擎（行存/列存混合）
• src/share/vector_index/ — 两级 HNSW 实现
• src/share/change_stream/ — 异步变更流管道
• src/pl/ — 存储过程语言
• deps/ — 第三方依赖（vsag 向量库等）

在用户侧，官方提供 pyseekdb Python SDK，将数据库操作封装为熟悉的 Python API，同时保留完整的 SQL 访问能力。Agent 开发者可以用 Python 直观地操作数据库：

import pyseekdb
client = pyseekdb.Client(path="./agent_state.db")
memory = client.get_or_create_collection(name="episodic")
for step in agent.run():
    memory.upsert(ids=[step.id], documents=[step.observation])
    relevant = memory.query(query_texts=step.next_query, n_results=5)
    agent.act(relevant)

seekdb 同时支持三种部署模式：嵌入式（单个 .db 文件，零依赖，适合本地开发）、单机服务器（二进制运行，支持网络连接）、OceanBase 分布式集群（生产级高可用），三种模式共享同一个 SQL 接口，只需一行代码切换连接方式。

部署方式：Docker 和 pip 是最简路径

seekdb 提供多条部署路径，适合不同场景：

Docker（推荐快速测试）：

docker run -d --name seekdb -p 2881:2881 -p 2886:2886   -v ./data:/var/lib/oceanbase oceanbase/seekdb:latest

pip（推荐 AI/ML 开发）：

pip install -U pyseekdb

源码编译（生产部署）： 需要 C++ 工具链、CMake 3.20+，，通过 bash build.sh debug --init --make 编译，复杂度较高，官方建议使用 Docker 镜像或预编译包替代。

值得注意的是，源码编译依赖的 deps/ 目录包含大量第三方库（约数 GB），首次编译需要下载和初始化，适合有 C++ 开发经验的团队。

生态集成：无缝融入现有 AI 开发栈

seekdb 的 MySQL 协议兼容性使其能够天然接入主流 AI 开发框架：

框架/工具	集成状态
LangChain	官方 PR 已合并
LlamaIndex	官方 PR 已合并
Dify	官方 PR 已合并
LangGraph	官方 PR 已合并
Coze	官方 PR 已合并
HuggingFace	官方 PR 已合并

对于已在使用 LangChain 或 LlamaIndex 的团队，迁移到 seekdb 的成本极低——只需将向量存储后端替换为 seekdb，即可同时获得全文检索、标量过滤和 SQL 操作能力，而无需引入额外的外部服务。

局限与挑战

seekdb 并非银弹，以下场景需要谨慎评估：

1. 成熟度相对有限 — 作为一个 2025 年新发布的项目，其在大规模生产环境的案例积累不如 Milvus、Qdrant 等成熟向量数据库丰富。尽管 OceanBase 内核有十年以上的生产验证，但 seekdb 特有的 Agent 特性（如 COW 沙盒、两级 HNSW）在生产级别的稳定性仍需更多社区反馈。

2. 嵌入式模式的资源管理 — 嵌入式模式在单个进程内运行，适合轻量场景，但在大规模数据量下缺乏独立资源隔离和水平扩展能力。对于需要处理数亿向量的大规模应用，分布式集群模式是必要的，但这也带来了运维复杂度的提升。

3. 源码编译门槛较高 — 官方推荐的预编译方式（Docker / pip）体验良好，但若需要自定义修改源码，依赖链较复杂，对 C++ 编译环境要求较高，不适合快速实验迭代。

4. 非云原生优先 — 虽然支持 Docker 部署，但官方并未提供 Helm Chart 或 K8s Operator，对于追求云原生自动化的团队，需要自行封装。

行业意义：从向量搜索到 Agent 基础设施

seekdb 的出现反映了 AI 基础设施领域的一个重要趋势：从"让 AI 检索数据"向"让 AI 拥有持久状态和执行上下文"演进。

过去两年，向量数据库解决了语义相似性检索的问题；RAG 系统解决了知识注入的问题。但 Agent 面临的挑战更深层：Agent 需要持续积累经验（长期记忆）、需要在不同策略间分支探索（沙盒）、需要在记忆中进行复杂的多维度查询（混合搜索）。seekdb 将这些需求统一到一个数据库引擎中，提供了一种比"向量数据库 + SQL 数据库 + 版本控制"组合更简洁的解决方案。

随着 AI Agent 从研究走向落地（软件工程 Agent、销售 Agent、医疗 Agent），专门为 Agent 工作流设计的存储基础设施将成为关键环节。seekdb 在这个方向上走在前列，其 COW 沙盒机制尤其具有前瞻性——它提供了一种优雅的"让 AI 放心试错"的计算范式，这可能是未来 Agent 框架的标配能力。

总结

seekdb 是 OceanBase 团队面向 AI Agent 场景推出的专用状态存储引擎，通过异步双层 HNSW 实现流式写入 + 即时检索的兼得，通过内核级 COW 沙盒提供安全的 Agent 探索能力，通过混合 SQL 查询统一向量、全文和标量检索。它既保留了 OceanBase 成熟 SQL 引擎和 MySQL 协议兼容性，又针对 Agent 工作流做了深度定制，是当前 Agent 记忆存储领域值得关注的基础设施选项。