为什么它和 AI Agent 是绝配

随着 AI 辅助开发（Claude Code、Cursor、OpenAI Codex 等）越来越普及，git worktree 再次受到了关注。

它在 Git 里已经存在很久了，但当多个 Agent 并行工作时，它的威力才真正显现出来。

本文想介绍的内容：

  • git worktree 是什么
  • 为什么它现在重新受到关注
  • 为什么它和 AI Agent 配合得这么好

git worktree 是什么？

git worktree 可以让你从一个仓库创建多个工作目录。

在常规的 Git 开发中，你通常是这样工作的：

my-app/   <- you work in this one directory

切换分支时执行：

git checkout feature-x

同一个 my-app/ 目录里的内容会被替换为 feature-x 的内容。

这种方式存在一些问题：

  • 每次查看其他分支都需要 checkout。
  • 分支内容变化时，构建缓存可能会被破坏。
  • 难以并行工作。

使用 git worktree 之后，结构变成这样：

repo/
worktrees/
  main/
  feature-a/
  feature-b/

每一个都是独立的工作目录。

例如：

git worktree add ../feature-a feature-a

然后你会得到：

project/
feature-a/

你可以在不同的目录里打开不同的分支：

project/    -> main
feature-a/  -> feature-a
feature-b/  -> feature-b

简而言之，git worktree 让你可以同时打开多个分支。

为什么它现在重新受到关注？

原因很简单：

AI Agent 已经开始并行写代码了。

一个常见的模式是：

Agent A -> bug fix
Agent B -> new feature
Agent C -> refactor

如果这一切都发生在同一个工作目录里，问题就来了：

  • checkout 冲突
  • Git 状态损坏
  • 构建缓存损坏

于是大家开始为每个 Agent 分配一个 worktree：

repo/
agent-bugfix/
agent-feature/
agent-refactor/

每个 Agent 都可以独立工作。

为什么 AI Agent 和 git worktree 如此契合

下面说说它们为什么配合得这么好。

1. 每个 Agent 拥有隔离的环境

Agent 会同时处理多个并行任务。

Agent1 -> test fixes
Agent2 -> API changes
Agent3 -> refactor

你可以把它们干净地拆分开：

worktree-test/
worktree-api/
worktree-refactor/

2. 不再有分支切换冲突

Agent 会频繁执行 Git 命令：

git checkout
git commit
git reset

在同一个目录里，这些操作会互相干扰。 有了 worktree，每个 Agent 都可以待在自己的分支上。

3. 缓存更加稳定

这在下面这些环境中尤为重要：

  • Node
  • Rust
  • Go
  • Swift
  • Bazel

频繁切换分支可能会破坏缓存状态（node_modules、target、build 等）。 worktree 可以让每个分支的构建状态保持完整。

4. Agent 扩展非常简单

在编排（orchestration）模式下：

orchestrator
  |- agent1
  |- agent2
  |- agent3

每个 Agent 只需通过 git worktree add 获得自己的 worktree 即可。

于是模型就变成了：

Agent = 专属的 Git 工作目录

AI 时代的开发方式

实际情况大致是这样：

Human
  |
Orchestrator
  |
Multiple AI Agents
  |
git worktree environments

每个 AI Agent 都有自己的沙盒——互不干扰。

总结

git worktree 已经存在很多年了，并不是什么新东西。但在 AI Agent 并行写代码的今天，它变得比以往有用得多。

它们遇到的问题是：多个 Agent、一个仓库、一个工作目录。很快就会出乱子。

而 worktree 干净利落地解决了这个问题。