Databricks 发布 Lakebase 数据库分支，为编码智能体提供隔离环境

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

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

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

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

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

更想看到实际效果？观看下面的视频演示。

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

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

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

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

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

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

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

在我们的示例中，我们使用 Drizzle。当需要模式更改时，agent 将相应的迁移添加到代码库中。然后部署自动化在部署预览应用程序时应用该迁移，并在更改合并到主分支时再次应用。

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

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

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

由于分支从生产环境开始，模式迁移也可以在更改到达生产环境之前应用和测试。

一旦 PR 被批准并合并，功能代码和迁移指令被提升，临时的 Lakebase 分支被删除。

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

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

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

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

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

分支还可以让模式迁移更安全。在将变更部署到生产环境之前，你可以自动创建一个数据库分支，应用迁移，运行测试，并验证应用行为仍然符合预期。一旦迁移验证通过，就可以将同一变更推广到生产环境。

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

结论

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

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