「每个人都在同时运行多个 Claude Code 智能体。」这是 Anthropic 工程师的原话。但当他们真的把官方推荐的 git 工作树方案搬进大型项目时，却发现花在配置上的时间比写代码还多。

工作树的理想与现实

打开网易新闻 查看精彩图片

Claude Code 内置了工作树支持。一条 claude --worktree feature-auth 命令，就能拿到隔离的代码副本、独立分支、限定范围的会话。再开第二个 claude --worktree bugfix-123，两个智能体互不干扰。

对库文件或命令行工具，这确实好用。但 Trigger.dev 团队运行的是一个大型 TypeScript 单体仓库——PostgreSQL、Redis、ClickHouse、Remix 网页应用、多个内部包。当他们尝试用工作树做并行 Claude Code 会话时，问题接踵而至。

端口冲突是第一个坑。开发服务器跑在 3030 端口，第二个工作树也试图占用 3030。于是你需要为每个工作树分配不同端口、准备不同的环境变量、编写各自的启动脚本。

数据库隔离更麻烦。两个工作树指向同一个 PostgreSQL 实例，智能体 A 执行迁移，智能体 B 的表结构就不同步了。更糟的是两边同时填充测试数据，互相踩坏对方的状态。「解决方案」是给每个工作树单独建库，各自跑在不同端口，各自执行迁移。

共享服务像滚雪球。Redis、ClickHouse、Elasticsearch、S3 兼容存储……应用依赖的每个服务都要复制或隔离一份。Trigger.dev 估算，单个工作树要配齐 PostgreSQL、Redis、ClickHouse 和 Electric 实例才能跑起开发服务器。

磁盘空间消耗惊人。Cursor 论坛有用户报告，自动创建工作树在两个副本上烧掉了 9.82 GB，而原代码库约 2 GB。每个工作树自带 node_modules、构建产物、所有东西。

依赖安装也是负担。每个新工作树都要跑 npm install 或 pnpm install。大型单体仓库里这不是瞬间完成的，原生依赖和构建步骤让等待更长。

最后还有自己跟自己冲突——两个智能体把同一个工具函数往不同方向重构，你得去调解自己没写过的代码里的冲突。

结果是你花时间搭建工作树管理脚本，而不是交付功能。网上已经冒出一堆博客文章，讲解端口分配方案、按工作树划分的 Docker Compose 文件、清理脚本。

另一种思路：GitButler 的虚拟分支

GitButler 采取了根本不同的分支策略。传统模式是一次一个分支（工作树让你每个目录一个分支），GitButler 则允许同一工作目录下同时应用多个分支。

这意味着智能体 A 可以在「feature-auth」虚拟分支上工作，智能体 B 在「bugfix-123」上操作，两者共享同一个 node_modules、同一个数据库实例、同一套开发服务器。没有端口冲突，没有重复的依赖安装，没有磁盘空间爆炸。

虚拟分支的隔离发生在 Git 层面，而非文件系统层面。每个分支的改动被独立追踪，但底层工作目录保持统一。当你准备提交时，可以选择把哪个虚拟分支的改动推送到远程。

对于需要并行跑多个 Claude Code 会话的团队，这省去了整套基础设施编排。不需要为每个智能体维护一套数据库，不需要写脚本分配端口，不需要担心 10 GB 的磁盘占用。

两种方案的权衡

支持工作树的观点很直接：隔离彻底，不会互相干扰，符合 Unix 哲学。每个智能体有完全独立的环境，踩坏什么都只影响自己。

反对者则指出，这种彻底隔离在真实项目中成本过高。现代应用不是纯代码，是代码加数据加服务加配置的复合体。复制整套环境 N 份，等于把 N 倍的运维复杂度塞进开发流程。

GitButler 的反驳是：Git 本身已经提供了足够的隔离机制，问题是我们把文件系统隔离和版本控制隔离混为一谈了。虚拟分支证明，你可以在同一个目录下安全地并行工作，只要 Git 层面的边界清晰。

但虚拟分支也有边界。如果两个智能体真的需要完全不同的依赖版本，或者一个要测 Postgres 14 另一个要测 Postgres 16，共享工作目录就帮不上忙。这时候你仍然需要某种形式的隔离——可能是容器，可能是远程开发环境。

我们的判断

Trigger.dev 的选择揭示了一个被忽视的事实：AI 编程工具的普及正在重塑开发环境的定义。

过去「开发环境」等于「一个开发者的本地机器」。现在它等于「N 个并行智能体共享的资源池」。当 N=1 时，工作树和虚拟分支差别不大。当 N=3、N=5 时，复制成本呈线性甚至超线性增长，而 Git 层面的轻量隔离开始显现优势。

这不是说工作树已死。对于依赖简单、状态少、团队规模小的项目，它仍然直接有效。但对于运行复杂单体仓库、需要频繁并行实验的团队，重新思考隔离的粒度可能比优化工作树脚本更有价值。

更深层的信号是：AI 编程工具正在倒逼版本控制工具进化。Git 的设计假设是人类开发者一次专注一个任务，Claude Code 们打破了这个假设。GitButler 的虚拟分支是一种回应，Git 2.49 引入的「工作树改进」是另一种。这场竞赛才刚刚开始。

Trigger.dev 最终没有回到单线程开发，也没有继续维护臃肿的工作树脚本。他们选择了第三条路——用虚拟分支降低并行成本，把省下的精力放回产品本身。

当 AI 智能体从「偶尔用用」变成「日常并行」，你的开发环境准备好了吗？是继续给每个智能体配一套完整基础设施，还是重新思考「隔离」到底需要在哪一层发生？