worktree-isolation.mdx 7.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179
  1. ---
  2. title: "Worktree 隔离"
  3. description: "给子 Agent 一个独立的工作空间——用 git worktree 实现文件级隔离"
  4. ---
  5. {/* 本章目标:揭示 worktree 的创建/销毁生命周期、路径命名规则、hook 机制和退出时的安全防护 */}
  6. ## 为什么需要文件级隔离
  7. 多 Agent 并行工作时,共享同一工作目录会导致三类冲突:
  8. 1. **写入冲突**:两个 Agent 同时编辑 `config.ts`,后写的覆盖前写的
  9. 2. **状态干扰**:Agent A 的测试依赖某个环境状态,Agent B 的修改破坏了它
  10. 3. **不可区分**:半完成的修改混在一起,无法分辨哪些是哪个 Agent 的
  11. Git worktree 是 git 原生的解决方案——在同一个仓库中创建多个独立工作目录,每个在自己的分支上。
  12. ## 目录结构与命名规则
  13. Worktree 文件统一存放在仓库根目录下的 `.claude/worktrees/`:
  14. ```
  15. <repo-root>/
  16. ├── .claude/
  17. │ └── worktrees/
  18. │ ├── fix-auth-bug/ # worktree 工作目录
  19. │ │ ├── .git # 指向主仓库的链接文件
  20. │ │ └── src/... # 独立的文件系统视图
  21. │ └── add-dark-mode/ # 另一个 worktree
  22. │ └── ...
  23. ├── src/ # 主工作目录(不受影响)
  24. └── .git/ # 主仓库
  25. ```
  26. 分支命名规则为 `worktree/<slug>`,其中 slug 由 `validateWorktreeSlug()` 校验:每个 `/` 分隔的段只允许字母、数字、`.`、`_`、`-`,总长 ≤64 字符。未指定时使用 plan slug 自动生成。
  27. ## 创建流程:EnterWorktreeTool
  28. `EnterWorktreeTool`(`src/tools/EnterWorktreeTool/EnterWorktreeTool.ts`)的执行链路:
  29. ```
  30. EnterWorktreeTool.call({ name? })
  31. 1. 检查是否已在 worktree 中(防嵌套)
  32. 2. 解析到主仓库根目录(findCanonicalGitRoot)
  33. 如果当前已在 worktree 内,chdir 到主仓库
  34. 3. 生成 slug(用户提供或 plan slug)
  35. 4. createWorktreeForSession(sessionId, slug)
  36. ├── 有 WorktreeCreate hook?
  37. │ └── 执行 hook,返回 hook 指定的路径(支持非 git VCS)
  38. └── 无 hook → git 原生路径:
  39. a. getOrCreateWorktree(repoRoot, slug)
  40. ├── 快速恢复:检查 worktree 目录是否已存在
  41. │ └── 读取 .git 指针文件的 HEAD SHA(无子进程)
  42. └── 新建:
  43. i. mkdir .claude/worktrees/(recursive)
  44. ii. fetch origin/<default-branch>(有缓存则跳过)
  45. iii. git worktree add -b worktree/<slug> <path> <base>
  46. iv. performPostCreationSetup()(sparse checkout 等)
  47. 5. 更新进程状态:
  48. - process.chdir(worktreePath)
  49. - setCwd(worktreePath)
  50. - setOriginalCwd(worktreePath)
  51. - saveWorktreeState(session) → 持久化到项目配置
  52. - clearSystemPromptSections() → 重新计算系统提示中的 cwd 信息
  53. - clearMemoryFileCaches() → 重新加载 worktree 中的 CLAUDE.md
  54. 6. 返回 worktreePath 和 worktreeBranch
  55. ```
  56. ### Hook 优先的架构
  57. `createWorktreeForSession()` 首先检查 `hasWorktreeCreateHook()`——如果用户在 settings.json 中配置了 `WorktreeCreate` hook,系统完全不调用 git,而是执行 hook 命令并将返回的路径作为 worktree 路径。这允许非 git 版本控制系统(如 Pijul、Mercurial)通过 hook 接入。
  58. ### 快速恢复路径
  59. `getOrCreateWorktree()` 有一个关键优化:如果目标路径已存在,直接读取 `.git` 指针文件获取 HEAD SHA(纯文件 I/O,无子进程),跳过整个 `fetch` + `worktree add` 流程。在大仓库中 `fetch` 需要 6-8 秒,这个优化将恢复场景的延迟降到接近 0。
  60. ## 退出流程:ExitWorktreeTool
  61. `ExitWorktreeTool`(`src/tools/ExitWorktreeTool/ExitWorktreeTool.ts`)支持两种退出策略:
  62. ### keep:保留 worktree
  63. ```
  64. keepWorktree()
  65. 1. chdir 回 originalCwd
  66. 2. 清空 currentWorktreeSession
  67. 3. 更新项目配置(activeWorktreeSession = undefined)
  68. 4. worktree 目录和分支保留在磁盘上
  69. ```
  70. 用户可以通过 `cd <worktreePath>` 继续工作,或稍后手动合并。
  71. ### remove:删除 worktree
  72. 有严格的**安全防护**:
  73. ```
  74. validateInput() — 第一道防线
  75. 1. 检查是否在 EnterWorktree 创建的会话中
  76. (手动创建的 worktree 不会被删除)
  77. 2. countWorktreeChanges(worktreePath, originalHeadCommit)
  78. ├── git status --porcelain → 统计未提交文件数
  79. ├── git rev-list --count <originalHead>..HEAD → 统计新提交数
  80. └── 返回 null(git 失败时)→ fail-closed(拒绝删除)
  81. 3. 有未提交文件或新提交?
  82. → 拒绝,要求 discard_changes: true 确认
  83. ```
  84. ```
  85. call() — 实际执行
  86. 1. 重新计数变更(validateInput 和 call 之间可能有新修改)
  87. 2. 如果有 tmux session → killTmuxSession()
  88. 3. cleanupWorktree()
  89. ├── hook-based → 执行 WorktreeRemove hook
  90. └── git-based → git worktree remove --force + git branch -D
  91. 4. restoreSessionToOriginalCwd()
  92. - setCwd(originalCwd)
  93. - setOriginalCwd(originalCwd)
  94. - 如果 projectRoot 是 worktree 时才恢复(防误触)
  95. - 更新 hooks config snapshot
  96. - 清空系统提示和 memory 缓存
  97. ```
  98. ### fail-closed 设计
  99. `countWorktreeChanges()` 在以下情况返回 `null`("未知,假设不安全"):
  100. - `git status` 或 `git rev-list` 退出非零(锁文件、损坏的索引)
  101. - `originalHeadCommit` 未定义(hook-based worktree 没有设置基线 commit)
  102. 返回 `null` 时,`validateInput` 拒绝删除——宁可让用户手动处理,也不冒险丢失工作。
  103. ## 与 Agent 工具的联动
  104. Agent 工具(`AgentTool`)的 `isolation` 参数决定子 Agent 是否在 worktree 中运行:
  105. - `isolation: "worktree"` → 调用 `createWorktreeForSession()`,子 Agent 在独立 worktree 中执行
  106. - 无 isolation → 子 Agent 共享主工作目录
  107. 子 Agent 结束时的处理:
  108. - **成功**:主 Agent 通过 `ExitWorktreeTool(action: "keep")` 保留 worktree,然后手动合并
  109. - **失败/放弃**:主 Agent 通过 `ExitWorktreeTool(action: "remove", discard_changes: true)` 清理
  110. ## Session 状态持久化
  111. `WorktreeSession` 对象通过 `saveCurrentProjectConfig()` 持久化到磁盘,包含:
  112. ```typescript
  113. {
  114. originalCwd: string, // 进入 worktree 前的工作目录
  115. worktreePath: string, // worktree 的绝对路径
  116. worktreeName: string, // slug
  117. worktreeBranch?: string, // 分支名(如 worktree/fix-auth)
  118. originalBranch?: string, // 进入前的分支
  119. originalHeadCommit?: string, // 进入前的 HEAD commit(用于变更统计)
  120. sessionId: string, // 创建此 worktree 的会话 ID
  121. tmuxSessionName?: string, // 关联的 tmux session
  122. hookBased?: boolean, // 是否由 hook 创建
  123. creationDurationMs?: number, // 创建耗时(分析用)
  124. }
  125. ```
  126. 这使得 session 恢复(`--resume`)时能正确还原 worktree 上下文——即使进程重启,`getCurrentWorktreeSession()` 从项目配置中读取状态。
  127. ## Sparse Checkout 优化
  128. 对于大型 monorepo,worktree 支持 `sparsePaths` 配置——只检出特定目录而非整个仓库。这在 210K 文件的仓库中将 worktree 创建时间从数十秒降到几秒。
  129. 配置位于 `getInitialSettings().worktree?.sparsePaths`,在 `performPostCreationSetup()` 中应用。