ModernRelay/omnigraph

解决什么问题

当一个以上智能体或服务同时操作同一份知识时，难点就从检索变成了协作：谁写了什么、哪个版本才作数、改动能不能先审再合入线上上下文。多数团队用向量库 + 关系库 + 胶水代码硬拼，最后拿到的是没有版本、没有类型约束的一团数据。Omnigraph 的做法是把图本身当作持久共享状态，把分支、合并和类型化本体做成核心能力，而不是事后补丁。

有什么不同

和 Neo4j 这类主流属性图数据库相比，差别不在图模型，而在运维模型：整张图级别的分支、三方合并与时间旅行，Terraform 风格的 cluster plan/cluster apply，以及所有写入路径都在服务端过一遍 Cedar 策略。它还把图遍历、向量 ANN、全文检索和排名融合放进同一个运行时，而常见做法是图库加一个独立向量库，在应用层拼起来。存储刻意选得很朴素：S3 兼容对象存储上的 Lance 文件，数据是开放格式，不会被锁进私有磁盘结构。代价是你得接受对象存储和 Lance 格式的约束，而不是去调优一个专用图引擎。

适合谁

做智能体记忆、公司知识图谱、或 issue 依赖图，且有多智能体和人类并发写入的团队，分支加合并这套模型会真的省事。已经在跑 S3、想要可版本化可审计状态的平台工程团队也合适。只需要单机快速遍历、或者没有对象存储基础设施的团队，应该去看传统图数据库；只想找纯向量检索库的人，继续用专用工具即可。

上手成本

全栈 Rust，提供发布二进制、Homebrew 和 curl 安装脚本。一个 cluster 是实打实的部署：配置包、策略文件、bootstrap、写者所有权转移和认证都要配。对象存储各变体有文档，Azure 需要 admission wrapper 且 writer 标记为 preview。API 处在 0.14，客户端 HTTP 契约与服务器版本强绑定，升级时要留意。项目 MIT 许可且非常年轻，README 在运维层面写得很细，但缺少性能和规模方面的证据。

点评

这是一个全新项目而非成熟项目：诞生 197 天，1,730 stars，只在 Rust 周榜出现过一次，排 #12、单周 +397。Hacker News 上的帖子只有 3 分、0 评论，这波热度更像是榜单带动，而不是大量一线开发者的验证。分支 + 强类型 schema + 开放对象存储的设计思路是自洽的，也确实填了一个协作空隙，但在 0.14 加客户端契约锁版本的阶段，属于早期尝鲜区。如果分支模型正好对上你的工作流，值得做个原型；作为生产环境的上下文存储默认选项，现在还不算稳妥。