分布式系统测试机构 Jepsen 于 2026 年 10 月 31 日发布报告，在工作流编排厂商 Orkes 旗下的 AI 多模数据库 ParticleDB（覆盖 1.1.4 至 1.1.18.11.rc-22 版本）中揪出 96 个漏洞。这款用 Rust 从头编写的数据库试图把事务型 SQL、Redis 键值存储、向量搜索和实时分析塞进同一个底层引擎，曾高调打出完整 ACID、159K TPS 以及比 PostgreSQL 快 1,087 倍的旗号。实测结果却连单机安全底线都没守住，更扯出了整场事故最刺眼的隐情——开发团队重度依赖大语言模型越界生成复杂系统代码与文档，到了排错阶段，人类工程师甚至说不清漏洞的成因与修复逻辑。
这批漏洞的触发门槛低得反常。以往登上 Jepsen 榜单的数据库，大多倒在复杂的跨节点网络分区或磁盘故障注入下；ParticleDB 暴露出的 96 个问题里，有 93 个无需注入任何故障，仅在健康的单节点、单客户端正常读写中就会直接复现：
- 底层数据灾难.直到测试收尾的 1.1.18.11.rc-22 版本，默认的
occ事务模式依然会在正常操作期间弄丢已提交写入；最严格的serializable设置下照样出现内部异常与丢失更新（Lost Update）；预写日志（WAL）损坏会导致部分数据丢失，模拟的错误定向 I/O 则会导致数据完全丢失。 - 基础 SQL 与状态错乱.进程崩溃、死锁、无法删除的半隐形行、被删除的表以扭曲形态复活、字符串自动变成整数，甚至连
WHERE 4 = 5这种基础布尔逻辑判断都会失灵。 - 事后找补与验证盲区.Orkes 工程师 Nikhil Kala 在 10 月 30 日的官方博客中宣称截至 1.1.19（及 1.1.19-rc.13）已解决全部 96 个问题，并悄悄将受测事务模式补标为实验性功能；但 Jepsen 明确指出测试结束时仍有 10 个问题未解决，机构从未对 1.1.18.11.rc-22 之后的版本做过验证，且送测安装包根本不包含其企业云主打的 Raft 多节点复制功能。
消失的 TLA+ 证明与大模型捏造的假文档
一家数据库初创公司敢在官网首页宣称完整 ACID 与秒杀级性能，通常需要极强的工程背书，但 ParticleDB 的安全承诺在细究之下全线失守。官方主页曾高调宣传系统经过 TLA+ 形式化验证，然而在 Jepsen 介入测试的整个合作周期里，Orkes 根本拿不出任何 TLA+ 规范文档。同样自相矛盾的还有隔离级别，官网大字写着 Full ACID，紧挨着的下一行小字却标注着并不具备完全隔离性的快照隔离（Snapshot Isolation）；当客户端通过标准 SQL 发送 SET TRANSACTION ISOLATION LEVEL 指令时，系统要么直接拒绝，要么表面接收却在底层静默忽略，转而由启动时的命令行参数强行接管。
连技术文档本身都混入了生成式 AI 的幻觉。在报告第 4.3 节质量保证中，Jepsen 发现其文档不仅对隔离级别的解释完全错误，甚至在存储过程文档的示例里，凭空捏造了一个属于测试者 Kyle Kingsbury 的假电子邮箱地址。开发团队连基础的人工审校都没做就直接发布，逼得 Jepsen 在报告里直接建议对方聘请人类技术撰稿人重写文档。
至于比 PostgreSQL 快 1,087 倍的性能神话，同样没能扛住实测。Jepsen 在 Debian 13 节点上用 Clojure 编写了差分测试工具，向 ParticleDB 和 PostgreSQL 同时喂入只包含基础数据类型与简单布尔逻辑的随机 SQL。结果不仅基础 SQL 语义对不上，在持续一小时的常规运行中，ParticleDB 的吞吐量持续衰减、中位延迟一路飙升。测试报告公开前后，ParticleDB 修改了基准测试文档，表态在没有可复现结果包的情况下不再沿用对比性性能标题，同时将文档中的默认隔离级别低调改写为较弱的 READ COMMITTED。
兼容了 PostgreSQL 的通信协议，不等于继承了它三十年千锤百炼的事务确定性。
试图吞下 Postgres 与 Redis 的底层撕裂
Orkes 造这颗轮子的初衷并不难理解。其核心产品是工作流编排平台 Conductor，早期底层依赖 Redis 加 PostgreSQL 的组合，为了帮 AI Agent 等高频状态交互场景省去跨库同步的延迟与运维麻烦，团队决定用 Rust 自研一个全能底座。这也是当下 AI 基础设施领域最讨喜的卖点，试图用一个多模引擎把关系表、缓存、向量和 OLAP 全装进去。
但把两套截然不同的存储哲学硬塞进同一个进程，很快就会在持久化和事务边界上产生工程撕裂。即便在 Orkes 紧急修订后的最新架构文档里，这种分裂依然存在。当开发者通过 SQL 接口提交事务时，数据默认走同步持久化；但通过其兼容的 Redis 端点写入键值数据时，系统默认采用异步 KV 持久性。一旦遭遇操作系统崩溃或机房断电，业务端明明已经收到写入成功确认的缓存或状态数据，依然会直接丢失。
人类看不懂代码，波将金村式的软件危机谁来买单
这项揭短的测试并非外部突袭，而是由 Orkes 自己出资聘请 Jepsen 完成的，单看主动送测这一点值得肯定。Orkes 解释称现网生产环境的 Conductor 客户目前运行的仍是功能受限的 1.0.0 版本，本次送测的 1.1.x 属于大重构后的软启动版本。但我依然对官方那句 96 个问题已全部解决的表态持保留态度，原因就藏在报告第 4.5 节的 LLM 权衡分析里。
大语言模型确实帮 Orkes 的小团队越过了能力边界，快速拼凑出一个复杂的数据库系统。到了漏洞修复阶段，反噬开始了。团队使用的 LLM 工具反复声称已修复问题，实际跑起来却根本无效；当 Jepsen 询问具体细节时，开发团队的人类工程师通常无法解释漏洞的成因，也说不清到底是怎么修好的。
独立开发者 Simon Willison 在 2026 年 11 月 1 日的博客中专门摘录了此事，将其与近期流行的氛围编程（Vibe Coding）放在一起审视。用提示词在几天内搓出一个即时战略游戏或前端页面，代码跑不通顶多是画面卡顿，重刷一次就能应付。但底层数据库是所有业务系统的地基，容错率为零。当小团队依赖 AI 生成自己认知范围之外的并发控制与事务内核时，代码库就变成了一个没人能维护的黑盒。
十八世纪俄国大臣波将金为了哄骗女皇，在巡游河道两岸搭起了画着精美窗户的假村庄木板。过去二十年，软件工程界有一套默认的信任潜规则，如果一个系统支持可串行化隔离、存储过程和预写日志，还配有一套详尽的文档，外部架构师通常会默认背后有一支硬核工程团队。如今大语言模型把这套信任机制砸碎了。正如 Kyle Kingsbury 在报告中所警告的，我们过去用来判断系统成熟度的外部信号，现在太容易被伪造了。
古人讲，名不正则言不顺。放到系统工程里，代码不是自己一行行想明白的，出了事就注定找不出病根。这种把核心逻辑外包给大模型的开发模式，实则是把前期开发的智力成本转嫁成了后期排错与下游客户的灾难成本。
对于正在使用 Orkes Conductor 并考虑升级到底层 1.1.x 引擎的企业，以及负责基础设施选型的架构师，切忌在生产环境盲目替换掉成熟的 PostgreSQL 与 Redis 组合。当漂亮的文档、完备的隔离级别参数全都可以由 AI 一键生成时，任何新软件项目都必须被默认视为嫌疑犯。检验 ParticleDB 1.1.19 到底有没有修好，不再看官方博客写了什么，只看三个硬指标：Orkes 能否公开可复现的性能测试包、能否拿出真正的 TLA+ 规范，以及敢不敢把包含 Raft 多节点复制功能的正式版再送回 Jepsen 做一轮暴力黑盒验证。