让 AI 并行写代码不难，难的是给每个 agent 分到一个干净数据库

coding agent 并行开发这件事，代码层面的答案已经比较清楚了。Git worktree 给每个 agent 一个独立目录和分支，文件不打架。但往下走一层，数据库还是共享的。

每个 agent 都要读 schema、跑迁移、塞种子数据、执行测试。一个开发库或 staging 库同时被三个 agent 用，结果就是迁移互相覆盖、测试数据互相污染，或者干脆退化成 mock，测的东西跟线上不是一回事。

Databricks 博客作者 Thibaut Gourdel 把这叫被忽略的瓶颈。他们给的方案是 Lakebase 的数据库分支：整个 Postgres 数据库在不到一秒内分出一个完整副本，不管库多大。底层是 copy-on-write，子分支和父分支共享数据页，只有真正产生差异时才占额外存储。空闲分支可以 scale-to-zero，不跑的时候不计计算费。

跟原生 Postgres 比，差距在哪。有网友在评论区指出，普通 Postgres 有 CREATE DATABASE x TEMPLATE parent，但它是把每个文件都复制一遍，而且父库上有任何连接时就会失败。复制慢、会阻塞、不适合给每个 agent 开一份。

Lakebase 的做法在工程上怎么落地，博客给了一条完整链路。

本地并行 agent 用 Git worktree 隔离代码，仓库里加一个 post-checkout hook，新建 worktree 时自动调 Lakebase CLI 建一个数据库分支。agent 在 worktree 里改代码、跑迁移，数据库是它自己的，跟别人没关系。干完活提 PR，worktree 和数据库分支一起回收。

PR 阶段换成 GitHub Actions。PR 一开，CI 创建一个以 PR 编号命名的临时 Lakebase 分支，父分支是生产。迁移工具对着这个分支跑 schema 变更，例子里用的是 Drizzle，然后部署一个 preview 应用指向这个分支的连接串，最后生成 schema diff 贴到 PR 评论里，告诉 reviewer 哪张表、哪个列、哪个索引变了。PR 合并或关掉，分支删除。

有个细节值得注意：数据库分支不像 Git 分支那样合并回去。父分支和子分支可以各自独立变化，合并数据不现实。schema 变更走代码里的迁移文件，由部署流程负责推进到父分支。换句话说，代码合并，数据库靠迁移重放。

除了开发和 PR，分支还能干别的。从生产库某个时间点拉一个分支出来复现 bug，在真实数据上调试，修完就删。上线前建分支跑一遍迁移和测试，确认没问题再推生产。需要真实数据又不想碰敏感信息，可以结合 Unity Catalog 做脱敏。

这东西解决的不是新问题，是老问题被 agent 放大了。以前三五个开发者共用一个开发库，冲突靠自觉和约定。现在 agent 并行跑，速度快、数量多，人为协调跟不上。数据库分支把隔离做成默认选项，每个 agent 一份，用完即弃。

Databricks 的原文和示例仓库在下面，GitHub Actions 的配置可以直接抄。

原文：https://www.databricks.com/blog/lakebase-and-agentic-sdlc-branching-databases-coding-agents

示例仓库：https://github.com/databricks/tmm/tree/main/Lakebase-Agentic-CI