Lakebase：用数据库分支支持编码智能体

AI 已经改变了软件的构建方式。随着编码智能体承担越来越多的开发工作，开发者正日益转向对它们进行编排。并行运行多个智能体正成为常态，工具链也随之演进，从 skills 和 hooks 到 MCP、子智能体，全都旨在让智能体更安全、更高效。

然而，开发工作流中一个至关重要的部分仍常常被忽视：数据库。

每个并发的智能体都需要编写代码、应用 schema 变更，并针对数据库运行测试。在共享环境（例如传统数据库设置中常见的单一开发或预发布数据库）下，这会产生真正的挑战。智能体可能在 schema 变更上发生冲突，相互干扰，或退而使用无法反映真实数据的 mock。这些本来就是开发者的痛点，而编码智能体让它们进一步加剧。智能体行动更快、并行运行，并需要一个安全的环境，以避免生产数据面临风险或暴露敏感数据。

Lakebase Postgres 架构通过数据库分支解决了这一问题。正如 Git 让你可以分支代码，Lakebase 让你可以在不到一秒内分支整个数据库，无论其规模如何。它使用写时复制（copy-on-write），因此分支共享父分支数据，但只在其发生分叉时消耗额外存储。此外，它们可以缩容至零，这意味着空闲分支不会产生计算成本。当你同时运行多个智能体时，这一点很重要。每个分支都是完全隔离的，允许智能体应用迁移、运行测试，并在完成后弃用该分支。

在本文中，我将通过一个围绕编码智能体构建的 Lakebase 开发循环的端到端工作流，向你展示这在实践中是什么样子。一个示例仓库在此处提供，其中包含 Github Actions 工作流的示例，用于实现以下各节所述内容。

更想亲眼看到它实际运行？观看下方的视频演示。

在深入之前，先说明一下 Databricks 中的环境。使用 Lakebase Postgres 时，一种常见设置是为每个环境（例如 dev、staging 和 prod）使用一个 Databricks 工作区。大多数团队出于安全和合规等各种原因会希望利用工作区，不过也可以使用单个工作区。同样，从已播种数据的数据库而非生产数据库进行分支也很常见，以避免暴露诸如 PII 之类的敏感数据。在本文中，为简单起见，我们将使用单个工作区，但相同的核心概念也适用于多工作区设置，并且同样可以轻松实现。

为并行编码智能体提供安全、隔离的数据库

对传统数据库的主要冲击来自多个编码智能体同时工作。在开发新功能或修复问题时，每个智能体通常需要读取数据库 schema、应用变更、播种数据并运行测试。如果没有隔离，这些智能体可能相互干扰或破坏共享数据库。数据库分支为每个智能体提供了一个隔离环境，使其能够独立工作，而不影响同时运行的其他智能体。

在本地避免代码冲突的一种实用方法是利用 Git worktree。Worktree 为每个智能体提供自己的目录，并检出各自的分支，因此它们之间没有文件级冲突。Git worktree 解决了并行智能体的代码隔离问题。Lakebase 分支解决了另一半：数据库隔离。通过向仓库添加 post-checkout 钩子，每个新的 worktree 都会自动获得自己的数据库分支。一旦开发完成，智能体将打开一个 PR。可以通过仓库指令文件（如 AGENTS.md 或 CLAUDE.md）来引导智能体行为。

以下是一个使用 Claude Code、worktree和 Lakebase 分支进行安全 AI 开发的示例工作流：

• 智能体运行 claude -worktree feature-123
• Git 为 feature-123 分支创建一个 worktree
• 一个 post-checkout 钩子自动触发，创建一个数据库分支
• 现在，智能体拥有自己的代码目录和自己的数据库，完全隔离

当智能体完成后，它将创建 PR。此行为在仓库指令文件中提供。一旦 PR 创建完成，worktree 和数据库分支都可以弃用。与 Git 的一个重要区别是，Lakebase 分支不会合并回主分支。由于父分支和子分支都可以独立变更，协调它们的数据很快就会变得不切实际。相反，schema 变更与应用逻辑一起在代码中跟踪，然后通过使用 Drizzle、Flyway、Liquibase 或 Alembic 等工具的迁移提升到父分支。

在我们的示例中，我们使用 Drizzle。当需要 schema 变更时，智能体会将相应的迁移添加到代码库中。随后，部署自动化会在部署预览应用程序时应用该迁移，并在变更合并到主分支时再次应用。

为每个 Pull Request 提供临时数据库

一旦打开 Pull Request（PR），我们希望在任何内容到达生产环境之前，自动针对真实数据库验证和测试代码。

使用持续集成工具（在此例中为 Github Actions），会为每个 PR 创建一个临时 Lakebase 分支，作为生产分支的子分支。该分支成为该 PR 的数据库环境。可以针对它运行自动化测试，部署预览应用程序，审查者也可以针对真实数据库验证变更。

由于该分支从生产环境开始，因此也可以在变更到达生产环境之前应用并测试 schema 迁移。

一旦该 PR 被批准并合并，功能代码和迁移说明会被提升，临时 Lakebase 分支会被删除。

一个常见的 GitHub Actions 工作流如下所示：

• 针对 main 打开一个 PR
• CI 调用 Lakebase CLI 创建一个类似 pr-123 的分支
• 迁移工具（Drizzle、Alembic 等）针对这个新的专用数据库分支运行
• 部署一个预览应用，指向该分支的连接字符串
• 生成 schema diff，并作为 PR 评论发布，准确显示哪些表、列或索引发生了更改
• 审查者同时验证代码和数据库更改
• 当 PR 被关闭或合并时，CI 会删除该分支

在仓库示例中，我们使用 Databricks Apps 部署应用程序，但这一概念同样适用于任何其他托管平台，例如 Vercel、Netlify、Cloudflare 等。

使用数据库分支进行 Bug 复现、迁移和测试

除了开发任务之外，数据库分支还可以支持若干其他有用的工作流。这些工作流并未在示例仓库中实现，但它们可以成为 Lakebase 开发工作流中有价值的补充。例如，借助数据库分支，你可以从生产环境在某个时间点创建一个隔离分支，通常是在 bug 出现之前不久，并针对真实数据调查问题、安全地复现该 bug，并在修复得到验证后弃用该分支。

分支还可以让 schema 迁移更安全。在生产环境部署更改之前，你可以自动创建一个数据库分支、应用迁移、运行测试，并验证应用程序的行为仍符合预期。一旦迁移得到验证，就可以将同一更改提升到生产环境。

这些工作流之所以强大，是因为它们让开发者能够使用类生产数据或源自生产的数据，例如通过 Unity Catalog 掩码，而不会让实时数据库面临风险。每个分支都是隔离的、临时的，使其成为用于调试、测试和验证的安全环境。

结论

这些模式共同构成了 Lakebase 开发循环：每个 agent 一个分支、每个 PR 一个分支，以及用于生产验证的隔离分支。

对于 Agentic SDLC，数据库分支为使用编码代理的开发团队提供了安全且灵活的基础。亲自尝试分支吧。