并行跑 AI agent 的工具，Windows 上少了一块

装完它，我敲的第一条命令是 `wt --version`。跑起来的不是它，是 Windows Terminal。

这事我得先记下来，因为后面所有的 Windows 体验都和这一条有关：这个工具在 Windows 上叫 git-wt，不叫 wt。

它叫 worktrunk，管 git worktree 的。作者 max-sixty（PRQL 的作者），仓库里写着「快速成为最流行的 git worktree 管理器」，v0.81.0，MIT/Apache-2.0 双协议。

为什么需要它

如果你只在一个分支上写代码，用不上这个工具。

但如果同时开三四个 AI agent 干活，问题就来了：它们共用一个工作目录，改动会互相踩。git 自己的 worktree 功能正好解这个——每个 agent 一个独立目录，但共享同一个 .git 仓库。

问题是 git 原生命令的体验烂。光是「新建一个 worktree」就要把分支名敲三遍：

git worktree add -b feat ../repo.feat，然后 cd ../repo.feat。

worktrunk 把这套压成一条：git-wt switch -c feat。它把 worktree 按分支名寻址，路径由模板生成，所以你脑子里只需要记分支名。

装起来很轻：winget 27.2 秒、46.1 MB（里面是两份 22.78 MB 的二进制，wt.exe 和 git-wt.exe 各一份）。

快了多少，慢了多少

我在一个干净仓库里逐项计时，对照裸 git：

结论有点意外：它在每一步都更慢，但每一步都更省事。建 worktree 1.03 秒对 0.19 秒，list 0.27 秒对 0.04 秒——慢五到七倍。

但把它替换掉的操作算进来就不一样了：删除 worktree 顺带删分支，一条 0.86 秒，裸 git 要敲三条；提交 + 合并 + 清理 worktree + 删分支，一条 4.06 秒，裸 git 得敲五条以上，还容易漏掉最后一步，留下一堆僵尸目录。

`wt list` 那张表也比 `git worktree list` 有用得多——后者只给路径，前者会告诉你每个分支相对 main 领先几个提交、有没有未推送的 commit、有没有改动。它把「我现在有几摊活、各在什么状态」变成了一眼能看懂的东西。

Windows 上少的这一块

这是我最想写的一段。

Worktrunk 有个卖点叫「共享构建缓存」：十个 worktree 都能用上 target/、node_modules/，不用重新 build、也不用复制。README 里那句话后面跟着一个括号——(on APFS, btrfs, and XFS)。

我照着试了。仓库里放了一个 30MB 的被忽略文件，复制到新 worktree：

它自己打印的那行字是关键：Copied 1 file · 30.0 MiB (full copy)。

full copy，不是写时复制。目标 worktree 从 0 MB 涨到 30 MB，两边各持一份。0.20 秒抄完 30MB——速度不是问题，磁盘才是。

换个真实数字算：前端项目 node_modules 两三个 G 很正常，十个并行 worktree 就是 二三十 G。它的「共享缓存」在 Windows 上退化成「复制缓存」，卖点少了一半。

顺带另外两个 Windows 专属的摩擦：

一是 不能自动 cd。`git-wt switch` 会告诉你「Cannot change directory — shell integration not installed」。它支持 PowerShell（会往 profile 写一行），但要交互确认，且要新开终端才生效。

二是它会在失败时明确告诉你怎么办。我用 config shell install powershell --dry-run 看了一眼，它要写的就一行：

if (Get-Command git-wt -ErrorAction SilentlyContinue) { Invoke-Expression (& git-wt config shell init powershell | Out-String) }

加不加由你，不加也能用，只是每次得自己 cd。

它做对的几件事

第一个是 merge。我在 worktree 里改了个文件，一条 git-wt merge master：

自动提交、合并、删掉 worktree、删掉分支，4 秒，一条命令。它甚至会在后台异步清理，不挡你。

第二个是没有 LLM 也能用。它有个「用 LLM 生成 commit message」的功能，但我没配任何 key，它直接降级成 fallback message，还告诉你「想配 LLM 可以怎么配」，然后照常提交。这点比很多「必须配 key 才能启动」的工具体面。

第三个是失败时的信息。它不会甩你一个堆栈，而是给一句人话加一个建议动作——上面那个「Cannot change directory」就同时告诉了你原因和解法。

我的判断

如果你在 macOS 或 Linux 上并行跑多个 agent，这东西基本没有替代品——CoW 共享缓存在那些文件系统上是真的，十个 worktree 只要一份 node_modules，冷启动问题直接消失。

Windows 上就复杂一点。能用，而且比裸 git 顺手，但你要接受两件事：管它叫 git-wt，以及缓存共享退化成真复制。

所以我的用法建议是：Windows 上别指望共享缓存，把 worktree 数量控制在三五个，超过这个数，磁盘和清理成本会开始咬人。真要多开，就用它的 wt step copy-ignored --dry-run 先看清楚会复制多少——它会把体积算给你。

一句话收：这工具本身是好的，问题不在它，在文件系统。同一句「不复制缓存」，在 Mac 上是真的，在 Windows 上是假的，读到括号里那三个文件系统名时，你就知道了。