本文作者 | 羡林 – OceanBase seekdb 研发负责人

全文 2124 字，阅读约需 4 分钟

Agent 的真实负载是 streaming workload——大多数向量数据库不是为它设计的。

如果你正在为 Agent 选向量数据库，大概率参考的是 ann-benchmarks 或者各家官方发的性能对比。那些测试跑的是这样的负载：先批量导入全部数据，建好索引，再做只读查询。

这不是 Agent 的负载，Agent 的真实负载是这样的：

for step in agent.run():     memory.write(step.observation)        # 持续写入     relevant = memory.search(step.query)  # 毫秒后检索

写入和检索同时发生，间隔是毫秒级，而且是并发的。这套负载有个名字——streaming workload。

VectorDBBench 专门为此设计了 StreamingPerformanceCase：固定速率持续写入 + 并发查询，跟生产环境的 Agent 一模一样。

VectorDBBench 由 Zilliz（Milvus 背后的公司）维护，是一个第三方开源 benchmark 框架。我们用它测了 6 款主流向量数据库。

测试条件：Cohere 10M 数据集（768 维），16 vCPU 64 GiB，统一 HNSW 索引参数（M=16 ef_construction=256 ef_search=200），持续写入 500 行/秒。

大多数人看 benchmark 只看 QPS 和串行延迟。但 Agent 在生产环境里不是单线程运行的。真正决定你 SLA 的是并发 P99——以及它在并发加大后涨了多少倍。

看图里“P99 Jitter”那组：

• ES：10.3 倍——串行 P99 只有 5.2ms（比 OceanBase seekdb 快），但并发一开就涨到 53.6ms
• 某向量数据库 A：9.7 倍——串行 15.9ms，并发直接飙到 153.6ms
• OceanBase seekdb：1.1 倍——从 19.7ms 到 21.7ms，几乎不动

这不是参数调优的问题——是架构问题。下一节详细解释。

※ 完整测试脚本和配置：github.com/oceanbase/vdb-streambench，欢迎提 PR 补充更多产品。

向量数据库 A、B、D 在它们擅长的场景（批量导入 + 只读查询）下表现优秀——它们本来就是为那个场景设计的。但 streaming 写入会暴露一个结构性的问题：不断产生新的 segment。查询时需要 fanout 到 N 个 segment 分别做 knn 再合并结果。单线程下勉强可控，并发一上来，N 个 segment × M 个查询线程在 CPU 上互相争抢，P99 就会飙升。

大多数向量数据库的索引段数量会随 streaming 写入膨胀，并发查询的争抢越来越严重。OceanBase seekdb 的索引数量是固定的（永远只有两个），所以不会。

具体来说，OceanBase seekdb 1.3.0 为 streaming 负载设计了两个机制：

第一，写入路径不碰索引。 事务提交后只写 redo log 就返回。一条独立的 Change Stream 管道在后台异步消费 redo log，把向量写入内存中的 delta HNSW 索引。写入和索引构建物理上完全解耦——写入不会被索引构建阻塞。

第二，查询路径固定只走两个索引。OceanBase seekdb 维护一个 delta HNSW（增量层，接收新写入）和一个 snapshot HNSW（主存量层），类似 LSM-Tree 的分层思路。查询时对两个索引各做一次 knn search 再合并结果——不管写入了多少数据，索引数量不膨胀，并发查询不争抢。

我们自己踩过这个坑。图里 OceanBase seekdb 1.2.0 那组——69 QPS、并发 P99 410ms——就是我们在做架构重写之前的成绩。旧版本的写入路径会同步构建索引，跟上面说的传统架构是同一个问题。重写后，同一个产品，22 倍 QPS、19 倍延迟的改善，全部来自这两个机制。

性能讲完了。但做过 Agent 的人都知道，还有一个痛点：Agent 需要试探性地修改数据（改 memory、跑实验、可能写坏表），你需要一个安全的沙箱和回滚机制。

大多数向量数据库没有这个概念。OceanBase seekdb 直接在内核实现了 Copy-on-Write：

-- 秒级快照，不复制数据 FORK DATABASE agent_state TO sandbox_42; 
 -- Agent 在沙箱里随便折腾 USE sandbox_42; INSERT INTO memory(embedding, content)VALUES('[0.1,...]', 'new observation'); 
 -- 试探成功 → merge 回主线 MERGE TABLE sandbox_42.memory INTO agent_state.memory STRATEGY THEIRS; 
 -- 试探失败 → 扔掉，主线不受影响 DROP DATABASE sandbox_42;

这是内核级 COW，不是应用层的 snapshot/restore。fork 秒级完成，不复制数据，每个沙箱是完整可写的数据库（表结构、向量索引、自增列全部正常）。三种冲突策略（FAIL
 / THEIRS
 / OURS
）让你精确控制 Agent 的修改有多少可以被信任。同时支持 FORK DATABASE
 和 FORK TABLE
 两种粒度。

Agent 的检索通常不是纯向量相似度。你可能需要同时过滤作者、时间范围，再加上全文匹配。在OceanBase 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;

向量 + 全文 + 标量过滤在同一个执行计划里下推，不需要客户端拼装多次查询结果。完整 MySQL 协议兼容，LangChain LlamaIndex Dify 任何 MySQL 客户端直接对接。

pip install -U pyseekdb

import pyseekdb 
 client = pyseekdb.Client(path="./agent_state.db") memory = client.get_or_create_collection(name="episodic") 
 # 第一轮：写入 Agent 观察 memory.upsert(     ids=["1", "2", "3"],     documents=[         "user prefers dark mode",         "user speaks English and Chinese",         "user timezone is UTC+8",     ], ) memory.refresh_index() 
 results = memory.query(query_texts="ui preferences?", n_results=1) print(results["documents"]) # -> [['user prefers dark mode']] 
 # 第二轮：写入新观察，刷新索引后立即可查 memory.upsert(ids=["4"], documents=["user saw pricing page 3 times today"]) memory.refresh_index() 
 results = memory.query(query_texts="purchase intent signals", n_results=1) print(results["documents"]) # -> [['user saw pricing page 3 times today']]

无需 server，无需 schema，嵌入式模式在进程内运行。

写入走异步索引管道（和 server 模式相同的架构），需要立即查询时调一次 refresh_index()
 确保索引就绪。切换到 server 或分布式模式只需改一行连接参数。也可以用 Cloud 免安装试用（免注册，免费 7 天，一个 curl）。