实测：worktrunk v0.81.0 与五个并行 Agent 工作区
一篇实测报告在 arm64 Mac（macOS 26.6.2、git 2.56.0）上测试了 worktrunk v0.81.0。用 worktrunk 创建 5 个 worktree 耗时 0.45 秒，原生 git 为 0.11 秒。用 wt step copy-ignored 复制一个 120MB 的被 gitignore 测试文件耗时 0.02 秒，df 差值为 -32KB；对照的 cp -R 为 0.20 秒并额外占用约 120MB 磁盘。作者将其归因于 APFS 写时复制，并说明只是未观察到明显新增占用，不能推出占用为零字节。用 wt remove -y --foreground 删除带 120MB 依赖的 worktree 耗时 0.09 秒。文中用 wt switch -c -x 搭建了五个工作区，但这只是流程演示，作者并未让智能体真正跑完任务，也未测试冲突处理、rebase、交互式 picker 或由大模型生成 commit message。这些数字是单次手工对照，并非基准测试；120MB 文件由 dd 生成，并非真实的 node_modules 目录。
该报告为并行编程智能体的使用者提供了具体参考：wt list 可在一张表里看到分支、领先/落后与远端状态；wt remove 一步处理 worktree 与分支，且未提交改动不会被直接丢弃，必须显式 --force；生命周期钩子可用于装依赖、起 dev server（带 hash_port 模板，且项目命令首次运行需要审批）；reflink 依赖复制只在 APFS、btrfs、XFS 上生效，ext4 上仍为普通复制。报告也列出了代价：测试环境下创建 worktree 比原生 git 更慢，两个二进制合计约占用 44MB 磁盘。
五个 Agent 工作区，worktrunk 实测
下午三点，最容易上头的事不是写代码，是同时开五个 AI 改一个项目。
五个窗口、五个分支、五次 git worktree add、五次 cd ../repo.feat。真正让人放弃并行的不是模型不够聪明，是目录切来切去。所以我今天装了一个专门管这件事的小工具：worktrunk，截至 11 月 4 日 10,672 star；当天我看到的 GitHub trending 第 3，这个排名事后没法复核。
先说清楚这篇测了什么、没测什么，免得标题比证据走得更远：
- 测了：建 5 个 worktree 的耗时；
copy-ignored复制一个 120MB 测试文件的时间和df差值；5 份普通复制的磁盘占用（df实测 600MB）；remove --foreground删完的耗时（0.09s，43 个文件 / 120MB）；一个pre-starthook 的耗时。 - 没测：五个 AI 真的跑完五个任务、冲突怎么解、rebase 怎么走、reflink 之后写入的块分裂、交互式 picker、LLM 生成 commit message。
所以下文里的「快」「慢」「省」，只对应上面被量过的那几个动作。