用数据库分支演练智能体写入

企业里的 AI Agent 为什么常常只能查数据，不能改数据？作者给出的解释很实际：一旦写错，团队还没想清楚怎么隔离影响、核对结果和追究过程，于是干脆关掉写权限。

Lakebase 吸引作者的地方，是把数据库分支和行级变更记录放进了同一套平台。Agent 可以先在分支里演练，团队根据实际改动做判断，再单独执行批准后的操作。不过，作者只实测了 Neon 的分支部分，完整的 Lakebase 流程仍需验证。

给 Agent 一份生产数据，为什么不用复制整库

数据库分支采用写时复制（copy-on-write）。新分支先指向父分支已有的数据版本，之后的修改才单独记录，不需要创建时搬运整库。

按原文的描述，2TB 数据库和 10GB 数据库都能在数秒内建立分支；在 500GB 数据库里修改 50MB，分支新增存储大约对应这 50MB。这里讨论的是分支存储增量，不能据此认定计算和运行成本也可以忽略。

它解决的是共享 staging 数据库里的老问题：你的测试失败，原因可能是别人尚未完成的迁移。给每次 Agent 任务独立分支，起点可以一致，后续写入互不干扰。

Databricks 在 2025 年 5 月以约 10 亿美元收购 Neon。原文援引 Ali Ghodsi 当时的说法，Neon 上约 80% 的新建数据库由 Agent 创建。这个数字描述的是 Neon 的使用情况，不能直接推成整个行业的比例。

这套技术后来成为 Lakebase。按原文时间线，它于 2026 年 1 月 22 日在 AWS 正式可用，公告博客发表于 2 月，Azure 则在 3 月上线。配置包括 Postgres 17、内置 pgvector、分支和时间点恢复；每分支存储从正式发布时的 8TB 增至 16TB，缩容到零后，下一次查询可在数百毫秒内唤醒。

但作者关注的重点，是它如何连接企业已经治理好的数据。

怎样看清 Agent 究竟改了哪些行

Lakebase 提供两个方向的数据通路。

Synced tables 把 Unity Catalog 表同步到 Postgres，让应用以低于 10ms 的延迟读取受治理的数据，并使用完整的 ACID 事务能力。它有三种模式：snapshot 做一次性复制，triggered 按计划刷新，continuous 持续同步，间隔下限为 15 秒。

边界也很具体：官方强烈建议把同步表当成只读表；triggered 和 continuous 同步只支持增量式的 schema 变更；每张同步表最多占用 16 个连接，而实例连接上限为 1,000。同步表铺得多，连接容量就需要提前算。

反方向是 Change Data Feed。按表开启后，它从 Postgres 预写日志（WAL）读取 insert、update、delete，约每 15 秒批量写入 Unity Catalog 管理的 Delta 表。目标表名为 lb_<table_name>_history，附带五个字段：

_pg_change_type、_pg_lsn、_pg_xid、_timestamp 和 _sort_by。

其中，_pg_change_type 的取值包括 insert、delete、update_preimage、update_postimage。一次更新会留下修改前、修改后两行记录，可以结合事务 ID 和日志序列号理解变更顺序。

核对写入结果时，数据库留下的行记录比 Agent 的自述更直接。

Agent trace 能解释执行过程，却不能替代数据结果。自己写审计表和触发器，需要额外维护；语句日志则需要继续还原实际影响。Change Data Feed 的价值，是把行级变化变成同一治理目录下可用 SQL 查询的表。

它仍处于 preview，需要源表设置 REPLICA IDENTITY FULL，不支持分区表，也不记录 DDL。两条通路里都出现了约 15 秒这个数字，但原文没有给出完整往返延迟的实测，不能把它当成端到端承诺。

分支不能合并，为什么仍然有用

Lakebase 没有把子分支变更推回父分支的内置 merge 或 promote 操作。Neon 也刻意不自动合并已经分叉的数据库：两个分支都插入 id 4 时，系统无法仅凭数据判断哪一个才符合业务意图。

所以，数据库分支不能照搬 Git 功能分支的工作习惯。

Schema 变更需要整理成迁移脚本，再用 Flyway、Liquibase 或 Alembic 应用到父库。数据修改则要通过正常应用写入路径，或针对任务编写的脚本处理。Lakebase 的 Schema diff 可以在子分支的 Parent branch 区域展示 DDL 对比，但不会合并，也不会替你完成迁移。

作者在 Neon 上做过一次具体实验。他编写的 multirun 把同一任务并行执行 N 次，每次分配独立的 git worktree，以及从同一个预置父库建立的数据库分支。

那次实验有 10 个 Agent，耗时 50 分 10 秒，共 930 轮交互，触及 143 个文件。约 30MB 的父库建立分支用了 1.38 秒，模型 token 按标价计算约 32 美元。

十个 Agent 都设计了 teams 表、成员关联表，以及 assets 上的外键，却在业务规则上分叉：

• 删除团队时，5 个选择 SET NULL，5 个选择 CASCADE。
• 成员关联表中，5 个使用复合主键，5 个使用代理主键。
• 团队引用有 8 个允许为空，2 个要求必填并做回填。

10 次运行不能证明稳定的选择比例，却足以暴露任务描述里的歧义。删除团队之后，资产应该保留还是一起删除？这需要产品规则，无法只靠模型补全。

作者比较差异后删除了全部 10 个分支，没有合并任何一个。他需要的是决策依据。

由此形成的流程是：先在分支演练，再根据差异或变更记录批准，最后通过独立操作重放已批准的修改。分支完成任务后就可以销毁。

我的判断

我认同作者把写权限拆成「演练、判断、重放」三个步骤。它把一个难以回答的问题，即「敢不敢让 Agent 改生产」，变成了几个能分别验收的工程环节。

但这篇的证据有明确边界。作者跑通的是 Neon 分支实验，没有启动 Lakebase 工作区，也没有实测 Synced tables 与 Change Data Feed 的完整组合。因此，产品能力描述和亲手验证的结果需要分开看。

分支隔离的是数据库状态，批准的是具体业务变更。

邮件、外部 API、对象存储文件仍可能产生真实影响，需要另行隔离。生产形态的数据也可能包含敏感信息，连接分支不等于获得了任意读取资格。Change Data Feed 记录哪些行发生变化，却不回答谁批准了操作、Agent 读过什么、哪个 prompt 触发了任务。

重放同样有前提。演练期间生产数据可能继续变化，批准时正确的修改，执行时未必仍然成立。原文没有展开并发冲突和业务前置条件如何检查，这部分需要团队自行设计。

与共享 staging、审计触发器和语句日志相比，这套方案的吸引力是隔离与记录更接近基础设施能力。但作者没有提供维护成本、吞吐量或费用的对照测试。是否值得采用，仍取决于团队是否已有 Databricks 数据治理体系，以及写入任务的实际复杂度。

能拿来做什么

• 给现有 AI 编程任务增加数据库分支，让涉及 schema 或数据修改的运行拥有独立起点，并在任务结束后清理分支，减少共享测试库互相污染。
• 在执行涉及外键、删除策略和数据回填的任务前，把 SET NULL、CASCADE、是否允许为空写成明确验收条件，减少模型自行决定业务规则的空间。
• 审查 Agent 的数据库修改时，同时查看 schema 差异和受影响的数据行；已经使用 Lakebase 的团队，可以评估 Change Data Feed 的 preview 限制是否适合当前任务。
• 将批准后的 schema 修改整理成迁移，将数据修改交给有明确权限和前置检查的应用路径或任务脚本执行，不把分支当成可以直接合并回生产的成果。