sparqlite 是一个 Rust 写的 SQLite 可加载扩展，让 SQLite 在进程内直接跑 SPARQL 1.1，RDF 四元组就存在普通表里。它值得看的地方有两个：本地做图查询可以少一个数据库服务；以及它把长跑 Agent 到底交付了什么这个问题摊到了台面上。
关键事实
| 项目 | 内容 |
|---|---|
| 回答的问题 | sparqlite：把 SPARQL 1.1 塞进 SQLite 的 Rust 扩展，顺手暴露了长跑 Agent 的真问题 |
| 简答 | sparqlite 是一个 Rust 写的 SQLite 可加载扩展，把 RDF 四元组存进普通表并在进程内执行 SPARQL 1.1，count 模式比翻译成 SQL 快 3.5 倍，通过 636/639 项 W3C 测试。它同时是一次 12 小时无人值守 Agent 任务的产物。 |
| 阅读时长 | ~3 分钟 |
| 最后更新 | 2026-10-22 |
它到底做了什么
按作者西蒙·威利森的说明，这个扩展把 RDF 四元组存进普通 SQLite 表，查询和更新都在 SQLite 进程内原生执行，不走先翻译成 SQL 那条路。实现上用整数编码的 term、覆盖索引、基于代价的查询规划器、批量 join，还有一个可选的、直接读 SQLite B 树的读取器（原文）。
数字很具体：count 模式比 SQL 翻译快 3.5 倍，返回完整结果集快 2.8 倍，通过 636/639 项适用的 W3C 评测用例，另加数百万次差分模糊对比。
要注意这是作者在自己工作负载上的自测。它足以说明架构不是玩具，但不足以承诺你的查询也能拿到同样的倍数。真要用，拿你自己的三元组模式压一遍，别拿示例数据集下结论。
真正新鲜的部分：它是怎么被写出来的
扩展本身是扎实的工程，但更值得琢磨的是生产过程。作者把这件事描述为一次用 Ultracode 模式跑 Claude Code for web 的实验——Agent 会自己生成 JavaScript 来调度一组子 Agent。他的第一条指令里还有个手机输入造成的错字：本来想写直接命中这些行，打成了直接删掉这些行。
这条指令让 Agent 连续跑了 12 个多小时。第二天他去看进度，发现 Rust crate 数量远超预期，于是补了一条指令：每个 crate 都要有 README；再写一份 tutorial，讲清楚怎么安装扩展、怎么在 SQLite CLI 里用、顺带教 SPARQL；并且配一个脚本，把教程要用的真实感示例数据灌进库里。
Agent 也照做了。结果就是一个完整的、跑在 SQLite 里的 Rust SPARQL 实现，附带文档，起因是随手一试。
作者自己的评价才是重点
原文难得地诚实：这件事感觉像是下一阶段的 vibe coding，产出根本不可能逐行 review，光是跟着文档走一遍就已经是相当大的工作量。他最后的问题是——如果这是随手做出来的、自己又不打算花时间去搞懂它能干什么，那它到底值多少？
这个问题适用于所有长跑 Agent 任务。产出的体量不等于产出的价值。一个跑了 12 小时、堆出几十个 crate 的 Agent，会在任何人验证之前就很像一个完成品。
在本地跑 Agent 的人能拿走什么
- 先定审的范围，再定跑的规模。 开一个多小时级的任务之前，先想清楚事后你真正会看什么。如果答案是全都看，任务就太大了；如果答案是测试和对外接口，那就让 Agent 先把这两样写出来。
- 一定要文档和可运行样例。 作者只补了一条指令，交付物就从没人看得完的源码变成陌生人能评估的东西。这条指令很便宜，回报很高。
- 能本地跑的就别上服务。 可加载扩展这种形态适合桌面工具，因为没有服务要部署、没有端口要开、没有独立凭据要管。如果你的 Agent 栈本来就依赖 SQLite，把图查询放进同一个进程，就少一个会坏的环节。
如果你要的是操作整台电脑而不是写代码的 Agent，那是另一类工具：可以下载 MOOGH，直接对着你已经在用的应用和文件干活。
结论
sparqlite 是一个可信的 SQLite 版 SPARQL 1.1 引擎：性能数字有具体口径，W3C 一致性接近完整，而且是一次无人值守 Agent 任务的产物。需要在关系数据旁边做图查询、又不想多起一个服务的人，可以试。关心 Agent 生成的代码要花多少成本才能拥有的人，更该读原文——作者那点不适感，才是这里最可迁移的结论。
相关阅读：