PG 之父 Stonebraker 发震撼论文 Chronos : 给 Agent 时代数据库打"分支补丁"

如果有人告诉你:给 PG、DuckDB、SQLite、Qdrant 都加上"分支能力",不需要改任何一行引擎源码,OLTP 性能 slowdown 只有 1.18-1.75×,MCTS-style 的 agent 探索加速 16.7×,跨存储 merge 永远不会出现 partial state,而且这套东西已经在线服务 CERN 物理实验的 AI agent 知识管理——这看起来像营销话术对吧?

但这篇 9 月 14 日刚挂上 arXiv 的 Chronos: Efficient Bolt-on Branching Across Data Stores for Stateful Agentic Applications(arXiv:2609.14889),作者列表里的 Michael Stonebraker + Samuel Madden + Lei Cao,把上面所有断言都验证了一遍,还塞进了 MIT CSAIL 的 Bolt-on 架构哲学。

Stonebraker 2026 年还在写 DB 论文,这本身就是信号——这位 80 岁的"Postgres 之父"已经把目光转向 AI agentic 时代最缺的那一块拼图:跨数据存储的版本化分支。Doltgres 在 Git-style 上做了 5 年还没解决 agent 多分支并发, Branch-aware Qdrant 在向量层做了 N×10.7 的延迟爆炸,而 Chronos 用一个巧到令人发指的 half-open interval 表示,把所有问题压成"加一个谓词"。

下文我会先讲 Chronos 用 interval 怎么把"分支"做轻,再讲跨 5 个 store 的实验数据怎么把它变成可落地的工程——这套东西对 Powermem / 自己的混合召回 / agent 工作流是不是 Game-Changer。

为什么是这篇

论文一句话总结:Chronos 是一个 bolt-on 跨异构数据存储的轻量级版本化层,核心是用 half-open integer interval 给每个 branch 分配子区间、给每个 record version 打 visibility tag,实现"快分支 / 高效合并 / 跨存储原子发布"。实现覆盖 PostgreSQL、SQLite、DuckDB、Qdrant、ChronosFS,无需修改任何引擎。

人气指标:arXiv 2609.14889v1,9 月 14 日提交(发布不足 5 天,引用数尚为 0,这是新论文常态)。但论文署名里有 5 位 MIT CSAIL / 阿里达摩院 / Shared Enterprise Data 的工程团队,加上 CERN 已经在用,这是已经过工业级验证的工作,不是"实验室玩具"。

为什么不是 COMPASS 或 DualSQL:本周另一个 28 分候选是 Argonne × U Chicago 的 COMPASS(arXiv:2609.13452,分布式向量搜索 + 科学知识图谱),知识图谱社区发现 + 13-18% corpus recall + 7.9× HPC 吞吐,数字极漂亮。但它解决的是"怎么放向量"。Chronos 解决的是"agent 跨多 store 怎么保持状态一致性"。

要讲 Chronos,得先讲它在解决什么——AI agentic 工作流里的"跨存储状态分支"问题。

论文图 1 画了一幅"企业 agentic 平台"的真实场景:

• 共享企业数据横跨三个 store:源文件(FS)+ 关系记录(PG)+ 向量索引(Qdrant)
• 多个团队/工程师继承共享数据做各种实验:Support、SRE、Engineering 各自 fork 出 Fix A、Fix B、Follow-up、Incident Investigation
• 每个 fix 修改源文件、改 provenance 记录、还要重建向量索引——这三个 store 的"分支视图"必须一致

现在的做法是什么?手工协调。论文直接点破:

"Existing systems require manual cross-store coordination, trade fork cost against query overhead, and can expose inconsistent state during a partially visible merge."

如果用 Git + Doltgres + Branch-aware Qdrant 拼,会有三个问题:

1. 跨 store 协调靠应用代码——任何一处对不上,merge 后 Qdrant 里就可能引用一个还没在 FS 上 visible 的文档
2. Fork 慢——Doltgres 要 content-addressed 重写,PG-clone-Btrfs 要整库 copy-on-write,MCTS 跑 1000 个分支直接 OOM
3. 合并可能 partial——每个 store 独立 commit,失败/中断时只合并了一半

Chronos 的核心论断是:这一切问题,根因不是"分支太难",是 "分支表示"没用对。

方法拆解:用 half-open interval 干掉版本表

Chronos 的核心数据结构只用一个东西:half-open integer interval [low, high)。这是论文最天才的一笔。

1. 分支 → 区间

每个 branch 拥有一个区间 [l, h),root branch 是 [0, max_int),子 branch 拿父区间的子区间。

root = [0, MAX)
   ├─ fix_A = [0, 500M)
   ├─ fix_B = [500M, 1B)
   │   └─ follow_up = [500M, 750M)
   └─ incident = [1B, 1.5B)

每个 branch 还有一个 frontier f(初始 l+1),代表 read point。

关键洞察:子区间天然编码了父子关系——A1 ⊂ A ⇔ A1 是 A 的后代。不用维护一张 parent_id 表。

2. Record → 带区间的物理版本

每个 logical record 的每个物理版本带 4 个元数据:

[low, high)  visibility interval
deleted      tombstone 位
writer       4-byte writer id(记录版本在哪个 active range 创建)
application_data

read 时一条 predicate 搞定:

visible ⇔ low ≤ f < high AND NOT deleted

这就是 Chronos 的全部 query rewrite:在每个 store 的 shim 层,把这条 predicate 加到 filter,等价于"在当前 branch 视角下只看属于你的 record"。无 join、无 history traversal、无 git-style DAG walk。

3. Fork:零数据拷贝

创建子 branch A1 时:

1. 父 branch frontier f 前进到 f + 1(预留一个 4-byte writer id)
2. A1 分配 [f, h) 的一个子区间
3. 不动任何 record——A1 看到的所有 record 仍带 [old_low, old_high),自然落在 A1 的 frontier 区间内

论文强调:"Forking therefore copies no record data"。这就是为什么 MCTS 风格 1000+ branches 实验能跑——fork 成本 O(1),与已有数据量无关。

4. Write:Copy-on-Write + Interval Split

更新 record 时:

1. 找到与当前 active range w = [f, h) overlap 的物理版本
2. 把 overlap 区间切出来,用新值替换(继承部分保持原值)
3. 维护不变量:任意两个 physical versions 的 visibility interval 不相交
   

图说:5 层结构 — 顶部应用层 → Chronos Core + 元数据 PG → 4 个 shim → 5 个原生 store(免改引擎)→ 底部 6 列关键数字。每个 store 都有专属 shim:PG/DuckDB 走 interval predicate,Qdrant 走 batch upsert,FS 走 row-level copy-on-write。

5. 跨存储原子 Merge

merge 是 Chronos 最值得称道的设计:

1. 三路合并(base / src / dst),计算 change set Δ
2. Staging:对每个参与 store,用 record-level copy-on-write 把 Δ 写入一个新分配的 interval Im——此时这些版本仍不可见
3. Atomic publish:在元数据 PG 事务里,把 merge frontier 原子推进到 Im 的起点
4. Reader 要么看到 merge 前的状态,要么看到完整 merge 后状态——绝不会 partial

实现细节是元数据存在 PG 里(Chronos 要求至少一个事务型 store),各 store 的 shim 只负责把 interval predicate 加到自己的查询里。

跟现有方法的对比

实验 + 数据集

实验在 AWS EC2 c5n.4xlarge(16 vCPU / 40 GiB / Linux 6.17)上跑,评估四个 RQ:

1. 跨 store agent workflow vs 独立 baseline
2. 分支拓扑 + 分支数对性能影响
3. 单 store 开销
4. interval 坐标位宽影响

关键数据集

• BranchBench:5 个不同形态的 OLTP workflow(OLTP / Simulation / MCTS / Failure Reproduction / Schema-Heavy)
• EnterpriseRAG-Bench:基于一个 AI inference 公司内部数据的合成语料,628,082 documents + 10,704,652 indexed chunks,跑 11 个 RAG workflow(vLLM / LiteLLM / Langfuse 代码 issue fix + 团队 onboarding + 跨分支 speculation)
• DEEP vectors(Qdrant 用)

主结果(对照图 6/7/9/10 严格还原)

图说:左面板是 Chronos 加到每个原生 store 上的 slowdown,右面板是 Chronos vs baseline 的加速比。所有数字直接引用 arXiv:2609.14889 原文 Figure 6/7/9/10。

解读:

• 16.7× / 6.0× 是 MCTS workflow 的加速比——意味着 1000 个分支的 agent 探索,从分钟级压到秒级。这是 agent RL 训练 / Tree-of-Thought 推理 / 多策略对比 的直接生产力工具。
• 17.9× @ 32 branches 是 Qdrant 上的惊喜——Branch-aware Qdrant 在分支数增长时延迟爆涨 10.7×(因为它的 filter 是 union of branch metadata),Chronos 用 constant-sized interval predicate(只多一个 low <= f < high 范围谓词)就解决问题。
• 5.60× 加速 over Doltgres+Btrfs+Qdrant 是 EnterpriseRAG 11 个 workflow 的几何均值——这是真实企业级 AI 系统的端到端对比,不是 toy benchmark。
• PostgreSQL OLTP 1.18-1.75× slowdown vs native PG——比 Doltgres 的 5-9× 小一个数量级,且提供 3.4-5.9× 加速 over Doltgres。意思是:用 Chronos 加版本控制,你几乎感受不到性能损失。
• 18.2× over serialization 在 32 concurrent workers 下——Chronos 防止了任何 partial merge 违反,而 baseline 串行化跑到崩溃。

Ablation:Interval 坐标位宽

Table 3 显示:32 位坐标够撑 14-498 个 branch(看拓扑形状),256 位撑 224 个,1024 位撑到 5.49×10^6 个 branch(bushy 拓扑)。实际部署选 32-64 位就够覆盖大多数 agent 工作流,存储开销约 1.04-1.20×。

这篇文章对 PowerContext 意味着什么

1. 它直接命中"AI 上下文管理"

Powermem 类项目本质是 多 store 的 agent memory system:PG 存元数据 / Qdrant 存向量 / SQLite 存日志 / FS 存文档。每一次"上下文窗口切换"或"记忆图谱生成分支",现在都是手工做 transaction。

Chronos 的 bolt-on 哲学就是这件事的解:不用改任何 store,只在应用层加一层 Chronos,所有 store 自动获得一致的 branch 视图。这等于把 Powermem 的"版本控制层"从 0 到 1 工程化了。

2. 它直接命中"AI 应用 + Harness 稳定性"——Agent 自举方向

在 Harness 设计时反复强调的痛点:Agent 跑多轮多分支时,中间状态怎么管理。Chronos 论文里"Failure Reproduction workflow 创建 10 个 short-lived branches"就是 Harness 测试的标准模式。MCTS 16.7× 加速 直接转化为 Tree-of-Thought / 蒙特卡洛 agent 推理的迭代深度——你可以在同样的时间预算里多跑一两个分支。

3. 它和 Qdrant 的搭配是"立等可取"

已部署 Qdrant(从 memory 推测)+ PostgreSQL。Chronos 的 Qdrant shim 代码:用 batch update API 实现 record-level copy-on-write,把 interval tag 加到 Qdrant 的 payload 里——这是 ~150 行的 Python shim(论文附录里有伪代码)。

实操路径:

1. 克隆 Chronos 仓库(论文没明说是否开源,但 Bolt-on 哲学意味着每部分都可以独立实现)
2. 在已有的 PG / Qdrant 上跑 BranchBench 的 OLTP / Qdrant 部分
3. 看 1.18-1.75× slowdown 是否接受——大概率接受,因为 Doltgres baseline 是 5-9×

4. 边界声明:不要把它当成"通用数据库"

• Schema-heavy workflow 较弱:Chronos 在物理表复制场景比 OrpheusDB 慢(论文承认,因为它对 schema 复制不优化)
• 至少要一个事务型 store: SQLite (ChronosFS backend) 不行——但 PG 是有的
• Controlled Access 假设:每个被 Chronos 管的表都必须经过 shim 层。这意味着新 store 接入需要写 shim,目前 5 个 demo store 是参考实现
• 不解决分布式 consensus:Chronos 的元数据 PG 是单点(可扩展,但需要 PG 自己 scale)

批判性思考

优点:

• interval 表达极其干净——half-open 区间 + frontier 是数学上最简的版本表示
• Bolt-on 哲学正确:不动 store 引擎,只加 shim,意味着可以渐进采纳
• 实验扎实:5 store × 2 benchmark × 5 workflow × 6 baseline × 多个参数,远超学术平均

局限:

• 没开源(论文没附 GitHub 链接,只有 BranchBench / EnterpriseRAG-Bench 的描述),主理人想跑要重新实现
• 单点元数据 PG:Chronos 假设至少一个事务型 store,但如果 metadata store 挂了,所有 branch 视图就崩——没看到任何 replication 设计
• Interval frontier 单调前进:branch 多了 1024 位坐标会耗尽?实际 bush 拓扑 5.49×10^6 branches 够用,但极端 long-running agent 不一定
• CERN 部署细节缺失:论文说"deployed at CERN CMS Computing Operations",但具体服务什么 AI agent、多大规模、跑了多久,没数字——这是营销叙事,需要谨慎对待

复现性:

• BranchBench / EnterpriseRAG-Bench 在论文 §6.1 有完整描述,可复现
• 但具体实现(shim 代码、interval 分配算法、merge 三路合并逻辑)需要参考附录,论文 28 页,主要逻辑在 §3-§5
• 预计单人 2-3 周可复现基础版本(Qdrant + PG + DuckDB shim)

过度拟合风险:

• EnterpriseRAG-Bench 是合成的"AI inference 公司内部数据",真实企业 agent 工作流可能远更复杂——例如混合 OLTP + 长事务 + 多团队协作
• 16.7× 加速是 "MCTS 1000 branch"的极限场景,普通 Git 工作流可能只能看到 2-3× 提升