效率工具 | Worktrunk:5 个 AI 助手并行改代码,不打架

★简括｜你如果开始同时开几个 AI 编程助手干活，迟早撞上同一个坑：两个 agent 在同一个目录里 checkout、commit，第二个把第一个的分支状态搅得稀碎。Worktrunk 就是给这个场景做的——git worktree 的一层壳，把创建、切换、查看、合并、清理各压成一条命令。我实测了几个数：Windows 安装包 17.4MB，解压后两个 exe 各 23MB，wt list 在 5 个 worktree 上跑 313 毫秒；删一个已合并的分支，原生要两条命令，它一条。这篇讲三件事：为什么并行必须用 worktree、它把哪些重复动作省掉了、我在 Windows 上撞到的那个坑。约 7 分钟。

先交代我为什么碰它。这几天我的 pi 同时开几个会话复现论文、改脚本，每个都在 git add / commit。问题出在它们共享同一个工作目录：一个切了分支，另一个正在写的文件就被带走了。

git 早就给了标准答案，你可能也用过：worktree。一个仓库能挂多个工作目录，每个 agent 占一个，共享同一份 .git。谁都不会踩到谁。

但原生命令用起来别扭。我拿一个空仓库做对照，建分支加工作目录：

# 原生：两条命令，状态还得另查git worktree add -b feat ../repo.featcd ../repo.feat# wt：一条，装好 shell 集成后连 cd 都省了wt switch --create feat

单看这一步，差别其实不大。真正的差距在「看状态」和「收尾」。

01 看状态：原生给你路径，wt 给你一张表

git worktree list只吐三样：路径、commit、分支名。哪个目录有没提交的改动、哪个落后主分支、哪个 agent 干完活忘了清，全看不出来，得再开git branch、git status 挨个查。

wt list 一张表全给：

图里我把终端符号换成了英文单词（原文是几个专用字形，截图里太小），列的含义照原样：Status 区分正常、目录已删、已合并可清理；Dirty 是未提交改动数；Behind 是落后主分支的提交数。五个 agent 谁卡住了，确实一眼定位。

02 收尾：这是它最值钱的一步

agent 干完活，常见动作是直接把目录删了。这时候原生 git 还当它存在：

$ git worktree list.../demo-wt-b  7257ed6 [feat-b] prunable

prunable 不会自己消失，你还得再跑git worktree prune。wt list 直接把这行标成 gone，不骗你说它还在。

删一个已合并的分支，原生要两步：

git worktree remove ../repo.feat && git branch -d feat

wt remove feat -y一条命令：删工作目录加删已合并分支。我在 demo 仓库里完整跑了一遍，确实一步到位。

03 一条命令跑遍所有 worktree，但 Windows 上有坑

wt step for-each 是它冲着并行 agent 设计的功能：所有 worktree 依次跑同一条命令。我第一版这么写：

wt step for-each -- 'git rev-parse --abbrev-ref HEAD'

四个 worktree 全报 program not found。原因是它不走 shell，整串被当成一个可执行文件名。去掉引号、逐参数给才对：

wt step for-each -- git rev-parse --abbrev-ref HEAD

这次输出正常：master、feat-d、feat-e、feat-f 四个分支各跑一次，之前那个「目录已删」的 worktree 自动跳过，最后给一句Completed in 4 worktrees。省下的不只是四次 cd，还有「哪些该跳过」这个判断。

04 数据口径

两条要提醒你：

协议是自定义的（API 标 NOASSERTION），商用前看一眼自动切目录要装 shell 集成：wt config shell install

05 我这次没测的

merge 的冲突处理、hooks 模板变量、wt step commit 的 LLM 提交信息、CI 状态列、wt step tether的进程树回收，这些我都没跑。它们才是它「AI 并行工作流」的招牌，你别当成我验证过的结论。

一句话：并行跑的 agent 超过两个，worktree 就是刚需，而 wt 把刚需的日常动作压到了最短——尤其是收尾那一步，省的是「记得清理」这件事本身。