我正在构建一个数据库，让每个 AI 智能体都先写入自己的分支。正在寻找志同道合的人一起打造。

一个拥有生产环境 CRM 写入权限的智能体，删掉了我们所有的潜在客户列表。它需要写入权限才能完成工作，所以“改成只读”并不能解决问题。于是，我正在构建一个数据库，让每个智能体都有自己的分支：整个数据库的一份私有副本，不到一毫秒就能准备好。智能体可以在其中自由读写。之后，你能逐行查看它到底改了什么，包括修改前后的值，再决定是合并还是丢弃。我问过一些正在运行智能体的人，需要什么条件，他们才会信任这样的系统。他们的回答塑造了其中的大部分设计：- 合并按行进行三方比较。如果生产环境修改了智能体也修改过的某一行，整个合并就不会执行。- 数据库会记录智能体读取过什么。如果这些数据在智能体工作期间发生了变化，合并就会被暂缓，因为智能体做决策时依据的事实已经不复存在。- 你可以编写 SQL 检查，在合并过程中针对合并结果运行。这样就能发现那些单独看都没问题、放在一起却出错的修改。- 规则决定哪些修改可以自动合并：最多影响多少行、禁止删除、哪些表或列始终需要人工审核。限制按整个运行过程累计，因此，把删除拆成多个小操作也无法绕过限制。- 分支中排队等待发送的邮件和 Webhook，只有在分支合并后才会触发。- 永远不采信智能体自己声称的内容。数据库负责记录，人负责制定规则。它使用 Postgres 协议，因此 psql 和常规驱动都能使用。坦诚说一下现状：它能运行，已经公开，但除了我，还没有人用真正的智能体测试过它。我正在独自开发，希望找到：智能体会写入真实数据（CRM、订单、工单）的人，愿意和我一起试用，告诉我哪里会出问题。想参与数据库引擎开发的 Rust 开发者：合并审核、Postgres 兼容性、追踪哪些读取操作读过发生变化的字段。觉得这个思路不对的人。我也想听听你们的意见。欢迎评论或私信。按版规，代码仓库和两分钟演示放在评论区。