被测的是什么
ParticleDB 是工作流平台 Orkes 自研的数据库，用 Rust 从零写成，面向 AI 智能体和应用负载：一个引擎里有事务型 SQL、键值存储、向量搜索、实时分析和名为 Particles 的用户自定义函数，对外兼容 Postgres 和 Redis 协议，宣称「Full ACID」。Orkes 2026 年春天对它做了大规模重构，并在官网软发布新版本，随后委托数据库一致性测试机构 Jepsen 做独立测试。10 月 31 日，Jepsen 创办人 Kyle Kingsbury 发布了分析报告；研究由 Orkes 出资，按 Jepsen 的伦理政策进行。由于 Jepsen 拿到的版本不含复制功能，报告只覆盖单节点行为。
测出了什么
Jepsen 在 1.1.4 到 1.1.18.11.rc-22 之间的版本里报告了 96 个问题，大多只需一个节点、一个客户端、不注入任何故障就能复现。报告列举的例子包括：
WHERE 4 = 5返回了主键为 5 的行，WHERE TRUE却匹配不到任何行；- 非空和唯一约束不起作用，主键可以重复、可以为空；
- 已删除的表会以错乱的形式重新出现，字符串有时变成 8 位整数，整列数据会无故消失；
- 对零行生效的 UPDATE 会凭空造出读不到、删不掉的行；
- 每种事务与预写日志模式下，几乎所有 Jepsen 能检测的事务异常都出现过。
到测试结束时的 1.1.18.11.rc-22，除 10 个问题外其余看似已解决，但默认的 occ 事务模式在正常运行中仍会丢失已提交的写入；新的 serializable 模式明显更安全，可在进程被杀掉时仍出现内部异常和 Lost Update（更新丢失）。2026 年 5 月至 7 月下载页提供的 1.1.4 到 1.1.18.11.rc-18 都存在严重安全问题，Jepsen 判断用过这些版本的用户很可能丢失或损坏过数据，建议用户停止继续部署、尽快迁移到其他数据库。官网首页曾称 ParticleDB 有 TLA+「形式化证明」，但合作期间 Jepsen 拿不到任何 TLA+ 规格；测试结束后，Orkes 把文档里这些事务模式改称「实验性」，Jepsen 认为这一说法难以成立。
报告里的「大模型取舍」
这份报告引起讨论的是第 4.5 节。Kingsbury 写道，大模型让小团队能在极短时间内写出规模和复杂度惊人的软件和文档，几名 Orkes 工程师借助大模型做出了一个相当复杂的数据库系统；但代价也很明显：质量受损，大模型工具一再声称缺陷已经修好，实际并没有；以往合作中 Orkes 工程师能详细解释自家 Conductor 平台缺陷的成因，这次却几乎解释不了 ParticleDB 任何一个问题的来龙去脉，新构建「凭空出现」、没有变更日志。他认为，大模型正在削弱人们对文档、软件和背后组织的信任，过去判断一个系统是否成熟的信号如今更容易被伪造。
Orkes 方面认为，问题主要源于春季的重构，自己和仍在用旧版 1.0.0 的客户大概率未受影响；Jepsen 粗测 1.0.0 时也未见多数严重错误。Orkes 称随后发布的 1.1.19-rc.13 已解决报告中的剩余问题，但该版本未经 Jepsen 测试。对用 AI 加速开发基础软件的团队，这份报告给出的建议很朴素：为每个功能写出至少能失败的示例测试，并在每次发布前真正跑一遍。