AI代理团队 + Git Worktree

AI编程/Vibe Coding 遇到问题需要帮助的，联系微信 ezpoda，免费咨询。

你知道那种感觉吗？当你在与 AI 编码助手聊天时，你会想："如果我能再有三个你在这个项目的不同部分工作就好了。"

我每天都有这种感觉。我会和 Claude Code 一起在登录页面上工作。但在我等待的时候，后端 API 却什么也不做。测试套件？未动过。数据库迁移？仍然只是我笔记中的一个 TODO。

一个 AI 代理。一次一项任务。感觉就像雇佣了世界上最聪明的开发人员——然后让他们在单行文件中做所有事情。

然后我发现了一些改变一切的东西：Agent Teams + Git Worktrees。 突然，我一次一个的 AI 工作流程变成了一个并行工作的完整开发团队。

让我来解释一下。

1、首先，没人谈论的问题

这是 AI 编码助手的一个肮脏的小秘密。每个人都谈论它们有多快。没有人谈论当你尝试同时运行两个时会发生什么。

想象一下。你有两个 AI 代理在同一个项目上工作。代理 A 正在编辑 src/api/auth.ts 来构建登录端点。代理 B 也在编辑 src/api/auth.ts 来添加速率限制。

会发生什么？混乱。代理 A 保存了它的更改。代理 B 保存了它的更改。代理 B 刚刚覆盖了代理 A 所做的一切。数小时的工作——在一毫秒内消失了。

这不是一个虚构的场景。这是当你尝试在同一项目文件夹中运行多个 AI 代理时实际发生的事情。它们会互相踩对方的工作。它们会互相破坏文件。这就像要求两个厨师在同一个小厨房里用一块切菜板做饭。

我以艰难的方式学到了这一点。我失去了整整一个下午的工作，因为两个 Claude Code 会话都在编辑同一个配置文件。谁都不知道另一个存在。

那就是我寻找更好的方法的时候。

2、进入 Git Worktrees: 你 AI 代理的私人办公室

如果你没听说过 git worktrees，别担心。大多数开发人员都没有。但它们即将成为你最好的朋友。

这样想。通常，你的 git 仓库存在于一个文件夹中。每个分支、每个更改、每个文件——都在那一个目录中。当你切换分支时，git 会交换所有文件。这对人类来说工作得很好。但对于 AI 代理？这是一场灾难。

git worktree 就像创建一个单独的项目副本——但更智能。不是克隆整个仓库（这会浪费磁盘空间并创建断开的副本），worktree 共享相同的 git 历史，同时给你一个完全独立的文件集。

所以现在代理 A 在 worktree-A/src/api/auth.ts 中工作。代理 B 在 worktree-B/src/api/auth.ts 中工作。它们正在编辑同一个文件——但在完全独立的副本中。没有冲突。没有覆盖。没有混乱。

每个代理都有自己的私人办公室。它们共享同一栋建筑（git 仓库），但它们永远不会走进对方的房间。

Claude Code 在版本 2.1.49（2026 年 2 月 19 日发布）中刚刚添加了对这个功能的内置支持。这一公告来自 Anthropic 的 Claude Code 团队的 Boris Cherny。这是一个游戏规则改变者。

3、它实际上如何工作（比你想象的更容易）

在 Claude Code 中设置 worktree 简单得令人尴尬。你只需要添加一个标志：

claude --worktree my-feature

就是这样。Claude Code 自动在 .claude/worktrees/my-feature 处创建一个新的 worktree，检出一个名为 worktree-my-feature 的新分支，并开始在该隔离空间中工作。

甚至不想想一个名字？跳过它：

claude --worktree

Claude Code 会为你生成一个随机名字——比如像 bright-running-fox 或 calm-silver-owl 这样有趣的名字。这就像 Docker 容器名称，但是为你的 AI 工作空间。

当你的代理完成其工作时，你得到一个干净的选择。如果代理进行了更改，Claude Code 会问你：保留 worktree 还是删除它？如果没有更改，它会自动清理。没有多余的文件夹乱堆你的项目。

4、现在添加 Agent Teams: 这是魔法发生的地方

Worktree 本身就很棒。但 worktree 与 Claude Code 的 Agent Teams 功能结合使用？这才是真正强大的地方。

Agent Teams 让你启动多个作为协调团队一起工作的 Claude Code 实例。一个会话充当团队领导。其他的队友在他们自己的任务上工作。这是关键部分——每个队友都可以在自己的 worktree 中运行。

想象一下这个设置：

Team Lead (You)
├── Agent A (worktree) → feature/frontend-login → PR #1
├── Agent B (worktree) → feature/backend-auth  → PR #2
└── Agent C (worktree) → feature/test-suite    → PR #3

每个代理都有自己的代码库隔离副本。每个都在自己的分支上工作。每个都创建自己的拉取请求。它们从不接触彼此的文件。

团队领导协调一切。它分配任务、监控进度，甚至可以使用消息在代理之间中继信息。把它想象成一个项目经理，带着三个从不休息的非常快的开发人员。

要启用这个功能，你需要设置一个环境变量：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

然后告诉 Claude 你想要什么。比如："创建一个 3 个代理的团队。代理 A 处理 React 登录页面。代理 B 构建身份验证 API。代理 C 编写测试套件。每个代理应该使用自己的 worktree。"

Claude Code 从那里接管一切。它生成队友、分配任务，每个代理都获得自己隔离的工作空间。

对于子代理（会话中更轻量级的助手代理），你也可以通过将此添加到你的任务配置来启用 worktree 隔离：

isolation: "worktree"

这一行告诉子代理："获取你自己的工作空间。不要触摸任何其他人的文件。"

5、当这个组合真正闪耀时

并非每个项目都需要一个 AI 代理团队。但有些场景几乎就是为了这种设置而生的。

同时构建独立模块。 登录页面、API 端点和数据库迁移——三个独立的部分，直到最后才相互依赖。非常适合三个代理并行工作。

使用竞争理论进行调试。 你有一个奇怪的 bug。是内存泄漏？竞争条件？配置问题？启动三个代理，每个调查一个不同的理论。第一个找到答案的获胜。

跨层重构。 你的前端类型需要更新，你的后端模式正在更改，你的测试需要匹配两者。三个代理，三层，开发期间零冲突。

将大更改分解为小 PR。 不是一个让你的代码审查者哭泣的巨大拉取请求，而是将工作分解为三个小 PR。每个代理处理一个部分。你的审查者给你发感谢信而不是辞职信。

一个开发人员将这个概念更进一步。他们运行了 16 个并行的 Claude 代理从头构建基于 Rust 的 C 编译器——一个能够编译 Linux 内核的编译器。它花费了近 2,000 个 Claude Code 会话并产生了 100,000 行代码。这是一个极端的例子，但它展示了当你将并行代理与适当的工作空间隔离结合时可以实现什么。

6、诚实真相：它并不完美

如果我说这个设置没有缺点，我就在撒谎。这里是你需要知道的。

合并冲突仍然会发生——只是稍后。 Worktrees 不会阻止冲突。它们推迟冲突。不是代理实时争夺文件，而是当你合并分支时处理冲突。这要好得多，但这意味着你仍然需要一个计划。

解决方案？在开始之前考虑合并顺序。如果代理 B 的前端代码依赖于代理 A 的后端 API，先合并后端 PR。然后变基前端分支并合并第二个。团队领导应该提前规划这些依赖关系。

代理不会自动共享上下文。 代理 A 可能发现了一些重要的东西——比如奇怪的 API 响应格式——但代理 B 毫不知情。每个代理都存在于自己的上下文窗口中。团队领导需要使用消息在代理之间手动传递关键信息。

更多代理意味着更多 token（和更多成本）。 一个三代理团队使用的 token 大约是单次顺序执行相同工作的会话的 3-4 倍。你在为速度付费。对于小任务，单个代理仍然更高效。将团队方法保留在时间节省证明成本合理的大项目中。

同文件编辑仍然有风险。 如果两个代理编辑同一个文件——即使在单独的 worktrees 中——当你结合它们的工作时你会得到合并冲突。最佳实践是为每个代理分配一个明确的范围。代理 A 获得 frontend/ 文件夹。代理 B 获得 backend/ 文件夹。代理 C 获得 tests/ 文件夹。在文件级别最小化重叠。

7、我现在的工作流程

采用这个设置后，我的日常开发过程如下。

我首先确定 2-3 个独立的工作片段。也许是一个需要 React 组件、API 端点和一些测试的新功能。每个部分都应该是一个代理可以在不需要他人不断输入的情况下处理的东西。

然后我启动启用 Agent Teams 的 Claude Code。我描述总体目标并为每个代理分配它的部分。每个代理获得一个 worktree、一个分支，以及它应该触摸的文件的清晰边界。

当代理工作时，我监控进度。我使用键盘快捷键（Shift+Up/Down 在代理之间切换，Ctrl+T 查看任务列表）检查每个代理。如果代理卡住或发现了其他人需要知道的东西，我会中继信息。

当代理完成时，我按顺序审查拉取请求。首先是后端，然后是前端，然后是测试。每个 PR 都很小且专注，这使得审查很快。我一个接一个地合并它们，根据需要变基。

以前需要我整整一天的整个过程现在大约需要 2-3 小时。不是因为 AI 在做草率的工作——而是因为三个专注的代理并行工作确实比一个代理顺序做所有事情更快。

8、结束语

如果你使用 Agent Teams，Worktrees 几乎是强制性的。

让我直言不讳。在没有 worktree 隔离的情况下在同一目录中运行多个 AI 代理是在自找麻烦。这就像让三个人同时在同一个键盘上打字并希望句子能正确输出。

Worktrees 给每个代理自己的空间。Agent Teams 给每个代理自己的大脑。它们一起将 Claude Code 从单个助手转变为协调的开发团队。

设置只需要大约 30 秒。潜在的时间节省是巨大的。而你会避免的合并冲突？无价。

试一试。在你的下一个功能上从两个代理开始。一个用于实现，一个用于测试。使用 worktrees。感觉一下。

我想你会想知道你以前是如何回到一次一个代理的。

原文链接: Why I Let 4 AI Agents Code My Project at Once — Claude Code + Git worktree— And Nobody's Code Broke…

汇智网翻译整理，转载请标明出处