如果你用若干个并发智能体加 SQLite 搭过智能体系统,八成碰到过 GapDB 要解决的那类问题。
做智能体应用,光有个简单的数据存储不够。智能体还需要一个地方来协调。
一个智能体认领任务。另一个评审。再一个改它的状态。智能体重启、重试、消失、过阵子回来,有时还基于已经过期的信息行动。
到这一步,数据库就得能同时存下状态和权威。
这个任务谁认领了?这条记录自我上次读之后改过没有?我还被允许更新它吗?那次写入真的落盘了吗?我不在的这段时间发生了什么?
所以我开始搭 GapDB。
Spec Kitty 的 Robert Douglass 好心收养了该项目,所以它够格算一次正式的 Spec Kitty 发布。
https://github.com/spec-kitty/gapdb
一个小巧的协调 API
GapDB 是一个小的、智能体原生的本地数据存储,围着智能体系统真正需要的协调原语建成。
它的 API 刻意保持极小:Get、Put、PutIfAbsent、CompareAndSwap、DeleteIfRevision、AtomicBatch、ScanPrefix 和 Watch。
没有 SQL,没有 join,没有查询规划器,也没打算变成通用数据库。
状态、修订与持久性
每次成功提交都拿到一个修订号。于是智能体实际上可以说:
"做这个改动,但前提是世界还是我观测到的那个世界。"
如果期间另一个智能体改了这条记录,过期操作直接失败。
持久性也是显式的。一次写入可以被记为 memory 或 durable,取决于这个状态是用完即弃,还是代表某种要紧的东西,比如租约、评审决定或工作流权威。
一种刻意的小架构
内部,GapDB 刻意保持简单:一个 owner 进程,一张内存权威映射,一个串行化的单一写入器,一条 append-only WAL,带校验和的快照,外加 Unix-domain 套接字。
目标不是到处取代 SQLite。
不如说,我搭它是为了给一个越来越常见的场景提供一个小而灵活的协调层:多个自主智能体共享本地状态,又需要足够的结构,免得互相踩爪子。
留有喘息空间,而无需为了一个相对聚焦的问题引入整个数据库宇宙。
这就是 GapDB。
随你用,随你玩,随你拆。它以宽松的 MIT 许可证发布。
去吧,孩子们,造点酷的东西,做完了拿给我看!