最近这半年我大部分工作时间都泡在AI编程Agent里。Codex、Claude Code、Trae CLI这些工具轮着试发现一个越来越明显的矛盾工具越好用并行跑的欲望就越强可同一个工作目录里同时开好几个Agent任务几乎必然翻车。你在这边切分支那个Agent正在改还没提交的文件你想看A任务的结果工作区却被B任务的一堆半成品塞满。我最后把解决方案落在了Git Worktree上又在这个基础上整理出了一套面向并行Agent工作流的CLI管理方案——Worktrunk。这篇文章把整个思路、踩过的坑、以及一套可以直接照抄的实操流程都写出来给同样在并行Agent工作流里挣扎的人做个参考。1. 并行AI Agent工作流为什么非用Worktree不可1.1 多Agent并行开发的真实痛点先说个最常见的场景你手上有一堆小任务比如给服务加一个接口、修一个样式bug、重构一个函数。每个任务看起来都不大你懒得开完整流程于是想让Agent自己干。一旦你同时跑两个或多个Agent混乱就开始了。最直接的冲突在文件层面。两个Agent在同一个目录下改代码A刚生成的一个临时文件B可能以为是垃圾直接删了更常见的是依赖状态被互相踩踏——Agent A在跑npm installAgent B同时在修改package.json下一秒A的依赖树就错乱了。Node_modules还好Python的虚拟环境、编译缓存这些更是谁动谁乱。其次是分支切换的成本。同一个工作区从功能A切到功能B你得先把A的改动找个地方存起来stash或者临时commit再切分支等B的依赖装完可能还要处理缓存冲突。手工开发时这个切换成本还能忍Agent跑任务时这个成本会放大好几倍——因为Agent启动一次、读一次仓库、装一次依赖本身就很慢。你切来切去半天就过去了任务进度几乎没动。第三是上下文污染。这一点最隐蔽也最致命。AI Agent的上下文里如果混入了不属于当前任务的文件、调试日志、未完成的半成品代码它的理解和生成质量会肉眼可见地变差。我在实际测试里发现同一个模型在干干净净的仓库里写代码通过率明显更高一旦工作目录里有很多跟当前任务无关的杂乱文件它就开始推理出一些根本不存在的东西幻觉率直线上升。给Agent一个干净的隔离工作区不只是方便是直接关系到输出正确性的。1.2 Git Worktree机制到底解决了什么Git Worktree是Git 2.5就开始支持的功能但很多人没用过。它的核心机制是一个仓库可以有多个工作目录每个工作目录对应一个分支它们共享同一个.git仓库的对象和引用数据库。打个比方仓库的.git目录就像一个中央仓库而多个worktree是多个互不干扰的工作车间。每个车间有自己的桌面工作区文件、自己的图纸HEAD、自己的半成品暂存区index但所有车间共享同一个原材料库objects database。你在车间A干活不会碰到车间B的桌面但两边用的原材料是同一套。这种机制天然适合并行Agent工作流。给Agent A开一个worktree指向feature/login分支给Agent B开另一个worktree指向feature/payment分支两个Agent各自在自己的目录里改代码、跑测试、提交commit互不干扰。它们可以同时跑不需要等对方完成。但这里有个反直觉的约束同一时刻同一个分支只能被一个worktree checkout。原因在于worktree共享的是整个仓库的refs如果两个worktree同时checkout同一个分支git没法保证它们的HEAD和index一致。所以基本操作范式是每个worktree绑定一个独立分支而不是都挂在main上。原生git worktree命令本身是对的可用起来有几个痛点特别折磨人git worktree add的参数太底层。每次要手动想路径、想分支名、想从哪个base拉出来命令一长串很容易写错。缺少任务维度的视图。你看不出哪个worktree对应哪个Agent、对应哪个任务时间一长目录多了就乱。不知道哪个worktree是空闲的、哪个是活跃的。回收清理全靠人肉判断一个不小心git worktree remove还会因为脏文件报错。没有跟AI编码CLI工具的集成。每次创建完worktree还得手动cd进去、启动Agent、记住路径麻烦。把这些痛点总结成一句话Git Worktree本来是把好刀但它只有刀片没有刀柄更没有刀鞘和标签。Worktrunk的出发点是给这把刀配上一套完整的管理壳子让它适配AI Agent的任务化工作流。2. Worktrunk核心设计思路把Worktree当任务单元来管2.1 命令设计理念围绕任务而不是围绕分支Worktrunk的第一个核心决策是把用户操作对象的抽象层级从分支提升到任务。这是它跟原生git worktree最大的不同。原生命令的世界里你关注的是我要基于main创建一个分支feature/aaa然后开一个worktree放在../feat-aaa而Worktrunk的世界里你只需要说我要创建一个任务tk-101基于main功能是登录页重构。剩下的分支名怎么起、目录放哪里、base从哪里拉都由工具统一编排。以我实际使用的标准核心命令大概是这样一组# 初始化目录约定 wtr init # 创建一个任务工作区 wtr task create tk-101 --base main --name login-refactor # 查看所有任务状态 wtr task list # 快速进入某个任务的工作区 wtr go tk-101 # 标记任务完成并合并清理 wtr task done tk-101 # 清理所有已归档任务的残留 wtr prune这套命令最大的好处是心智负担小。Agent跑任务时你不需要记目录在哪、分支叫什么、步骤到哪了只要认任务ID就行。任务变成了整个工作流里的一等公民分支、worktree、目录这些都成了被任务ID牵引的附属细节。从工程角度看围绕任务设计还有一个隐藏优势可观测性更好。因为任务是用户真正关心的单元围绕它去查询状态、定位问题、回收资源都比围绕底层git对象要自然得多。我在用的时候最大的感受就是——终于不用每次先git worktree list然后对着路径猜了。2.2 状态追踪与生命周期管理Worktree管理里最容易被忽视的部分是状态。原生git worktree完全不知道你的worktree在干嘛它只关心有没有被checkout。但一个Agent工作流里worktree是有生命周期的从创建到被Agent使用到提交审查再到合并清理。Worktrunk通过在本地的元数据文件记录每个任务的详细信息我最初的实现是在仓库根目录放一个.wtr/tasks/目录每个任务一个JSON文件大概长这样{ id: tk-101, name: login-refactor, branch: wtr/feature/login-refactor, path: .wtr/workspaces/tk-101, status: running, createdAt: 2026-02-10T14:30:00Z, baseBranch: main, agentLog: .wtr/logs/tk-101.log }状态机我设计成了这样几个阶段pending任务创建完成分支已建好Agent还没启动。runningAgent正在工作区里干活。reviewAgent已经提交代码或开了PR等待审查。merged代码已合并进主干工作区待清理。archived已归档不再出现在默认列表里。有了这套状态wtr task list一眼就能看出哪个任务卡住了、哪个可以清理、哪个还在跑。相比对着git branch和git worktree list猜效率提升是实打实的。我还做了一个细节每个任务创建时会自动生成一个独立的日志文件。Agent跑任务时的输出全部重定向到这个日志里后面排查问题特别方便。你能看到Agent到底做了什么、卡在哪一步、报了什么错而不是对着终端滚动日志干瞪眼。2.3 与主流AI编码工具配合Worktrunk本身不是Agent调度器它只负责管理Agent的工作空间。所以跟Codex、Claude Code这类AI编码CLI工具的配合非常关键。配合的方式其实很简单把这些工具的工作目录显式指向worktree目录。比如codex exec --cd .wtr/workspaces/tk-101 实现登录页表单校验逻辑或者Claude Codecd .wtr/workspaces/tk-102 claude -p 修复支付流程里金额精度问题关键点有三个第一每个Agent必须绑定到自己独立的worktree目录不要让它们共享一个目录。这从物理上保证了隔离性。第二Agent启动时的环境要干净。不要继承你主目录里那些乱七八糟的node_modules、缓存、虚拟环境尽量让Agent在worktree里重新安装依赖。虽然多花一点时间但能避免大量诡异的环境问题幻觉。第三Worktrunk的元数据可以当作Agent任务的记录中心。我在实际用的时候会在agent的提示词里把任务ID和描述带进去让Agent知道自己在干什么、日志该写到哪。这样即使同时跑五六个任务每段工作的归属依然清晰。3. 实操实录从安装到跑通一套并行Agent工作流3.1 安装与初始化Worktrunk的安装本身不复杂。我最初是用Go写的单二进制文件发布时直接给不同平台的预编译包也可以用npm全局安装npm install -g worktrunk装完后需要在目标仓库里初始化cd ~/projects/my-service wtr initwtr init会做几件事检查当前目录是否是合法Git仓库在仓库根目录创建.wtr/结构workspaces、logs、tasks三个子目录写下.gitignore规则把.wtr/排除在版本控制之外。这里有个设计细节值得说一下worktree目录放在仓库内还是仓库外各有利弊。放在仓库内比如.wtr/workspaces/好处是路径短、直观坏处是这些目录会出现在根目录的列表里看着有点乱放在仓库外比如~/.worktrunk/repo-name/task-id好处是仓库目录干净坏处是跟仓库的关联需要靠元数据记住。我最终选择了仓库内的方案但加了.gitignore隔离这样worktree从git的角度是不可见的不会污染主仓库的状态。如果你之前用过git worktree add应该知道worktree目录在被添加时会自动出现在主仓库的git status里这个体验其实是有点怪的。放在.wtr/workspaces/并且ignore掉之后主仓库永远保持干净只有你主动去查任务列表时才会看到那些目录。3.2 创建Agent工作区并绑定任务初始化完成后创建任务工作区就是一条命令wtr task create tk-101 --base main --name login-refactor执行过程大致是这样校验任务ID是否已经存在避免重复。自动生成分支名默认格式是wtr/feature/login-refactor。用git worktree add创建worktree目录是.wtr/workspaces/tk-101。写入任务元数据JSON。输出一段提示告诉你worktree路径、分支名、以及一个可以复制的Agent启动命令示例。创建完之后你就可以直接进入该目录跑Agent了。我个人常用的流程是这样cd .wtr/workspaces/tk-101 codex exec 根据设计文档实现登录页的后端接口记得写单元测试注意一点创建worktree时如果base分支有最新的远端更新wtr task create会自动帮你fetch或rebase对齐。我踩过不少次基于一个过期的main创建分支结果Agent跑出来的代码跟现有代码冲突的坑所以这个自动对齐base的逻辑我觉得非常必要。3.3 切换、同步与清理当任务数量多起来之后最常有用的就是两个命令切换和清理。切换任务工作区我用的命令是wtr go tk-102它做的事是解析任务ID找到对应worktree路径然后cd进去并弹出一个提示告诉你当前分支和上次Agent日志的最后几行。这个小提示很实用相当于你每次回到一个任务现场时它能帮你快速恢复记忆。同步代码这块我设计了一个wtr sync命令wtr sync tk-101它会在指定worktree里执行git fetch、合并base分支的更新并把结果记录到元数据里。为什么不能简单地在worktree里手动跑git merge main因为并行Agent工作流里的同步往往涉及多个worktree逐个手动操作太烦而且容易漏。写成命令后可以一条命令把所有running状态的任务全部同步一遍。清理流程是这样wtr task done tk-101 wtr prunewtr task done会把worktree的改动合并回主干默认用--merge模式自动处理冲突冲突时会停下来提示然后标记状态为merged。wtr prune则负责把所有merged或archived状态的worktree物理删除。这里有个安全措施我强烈建议加上prune默认走--dry-run模式只打印将要清理的列表不真正删除。确认无误后再加--force执行。我自己的习惯是先dry run看一眼再手动review一遍最后再force基本没出过误删的事。4. 常见问题与排查技巧实录4.1 Worktree清理不掉怎么办这是用worktree最经典的问题。你在worktree里跑过Agent之后目录里全是乱七八糟的文件——临时文件、生成的依赖、Agent创建又没删的脚本——然后你想git worktree remove它git会报错fatal: working tree contains modified or untracked files普通人的第一反应是加--forcegit worktree remove --force。这个能删掉但有个隐患如果worktree里有还没提交的改动加force后这些改动就永远消失了。Agent跑的半成品代码可能在里面。所以排查优先级应该是先看worktree里有没有值得保留的改动git -C path status --short如果有未提交代码先commit到该worktree的分支上或者手动复制出来到安全位置。确认无误后再wtr task done走正规清理流程或手动git worktree remove --force。另一个常见情况是worktree目录本身被删了但git的worktree元数据还留着。这时候git worktree list会显示一个不存在的路径git worktree remove也会报错。解法是用git worktree prune让git自动清理失效的元数据。Worktrunk的wtr prune在底层做了类似的事它会先调git worktree prune再清理自己的任务元数据。4.2 分支冲突和共享分支的坑并行Agent工作流里最容易犯的错是让两个Agent在同一个分支上干活。表面上看它们在不同worktree似乎互不影响但它们的分支绑定关系是冲突的——git会禁止第二个worktree在相同分支上checkout。如果真遇到需要在多个worktree之间共享代码的场景比如一个Agent要调用另一个Agent刚写的模块我的建议是短期的共享用git fetch 手动cherry-pick或git merge同步不要让两个worktree同时checkout同一分支。中期的共享把公共代码抽到独立分支然后需要用的Agent通过git merge合并过来。长期的共享直接改成单个Agent串行处理别硬并行。还有一个特别隐蔽的坑git branch -D删除分支时如果这个分支正被某个worktree checkoutgit会拒绝删除并给出提示。很多人在主仓库里看到分支名还在以为是分支删不掉其实是worktree占着。同样如果你用wtr task done合并完代码后发现分支还在先看看是不是有worktree没有清理。4.3 与AI编码CLI配合的几个坑我实际用Codex、Claude Code这类工具时碰到过几个跟worktree强相关的坑这里挨个说。第一个坑是Agent在worktree里执行git命令时偶尔会报dubious ownership错误。原因是worktree目录的owner跟当前用户不一致比如你是用root创建的目录又用普通用户跑Agent。解法是全局配置里加一句git config --global --add safe.directory *注意这个配置加了之后所有git目录都会信任安全性上有取舍最好是把具体路径加进去而不是用通配符。第二个坑是Agent会自动执行git pull或git fetch但worktree因为共享refs如果在多个worktree里同时对同一个remote做fetch偶尔会有锁冲突。表现是Unable to create .../.git/index.lock: File exists。解法很简单锁文件一般是残留删掉就好如果频繁出现说明你的Agent命令里不该加自动fetch逻辑。第三个坑是Agent的日志输出会被项目里的node_modules或Python虚拟环境干扰。有些Agent会在当前目录里搜索文件结果被几万个依赖文件塞满上下文导致响应变慢、质量下降。我的做法是把worktree的目录结构严格控制——依赖目录用.gitignore排除Agent工作目录的上下文尽量精简把项目无关的配置文件都放到上一级目录不让Agent扫描到。第四个坑跟提示词有关。如果你在创建任务时通过Worktrunk生成了一段任务简报一定要让Agent知道它的工作目录在哪、日志写到哪。否则Agent自作主张在工作区外的路径写日志很容易污染别的任务。我目前的做法是在任务描述里固定带上所有中间文件请写入当前目录下的.tmp-worktrunk-hint.md这行字然后Worktrunk在清理时会一并处理掉实测效果还行。5. 一些实操心得与后续扩展方向Worktrunk这套思维和工具我实际用了大概三四周时间最大的感受是并行Agent工作流的核心瓶颈不是Agent模型的聪明程度而是工作区的管理水平。模型再聪明在一个混乱的、塞满无关文件的目录里也会变笨反之只要工作区隔离干净、分支绑定明确、任务状态可查普通模型的产出质量也能稳定维持在一个很不错的水平。几个很实在的心得按重要性排序先戴上任务视角再谈工具。不要总想着我要开一个worktree而是想我要跑一个任务。这个心智转换让我省了大量不必要的纠结——分支名、目录名这些全是细节交给工具就好。清理要勤快。worktree跟分支一样只要不清理就会越堆越多。我自己的节奏是每个任务结束当天就wtr task done加wtr prune绝不让worktree过夜。对Agent的输出保留怀疑验证心态。worktree把结果隔离得很干净但你仍然要在合并进主干前认真审查。我一般会让Agent先提交到自己的分支然后本地跑一遍关键测试再合并。日志是救命稻草。没有日志的并行Agent工作流出了问题你连从哪查都不知道。Worktrunk把每个任务的日志独立记录这个习惯值得在任何Agent工作流里沿用。扩展方向上我目前正在试的是跟仓库管理平台的集成。比如任务完成后一键创建PR或者在wtr task list里直接显示CI状态。另外一个方向是团队协作——多个人各自跑Agent共享同一个仓库的worktree池但通过中央元数据同步任务状态这样能避免两个人无意中创建同一个分支名导致冲突。最后分享一个小技巧如果某个任务卡住了不要急着删先wtr task list看状态再tail -n 50 .wtr/logs/task-id.log看日志一般三分钟内能定位是Agent卡住了、代码跑挂了、还是git锁冲突。这套排查路径我反复用基本靠它就够。
最近这半年我大部分工作时间都泡在AI编程Agent里。Codex、Claude Code、Trae CLI这些工具轮着试发现一个越来越明显的矛盾工具越好用并行跑的欲望就越强可同一个工作目录里同时开好几个Agent任务几乎必然翻车。你在这边切分支那个Agent正在改还没提交的文件你想看A任务的结果工作区却被B任务的一堆半成品塞满。我最后把解决方案落在了Git Worktree上又在这个基础上整理出了一套面向并行Agent工作流的CLI管理方案——Worktrunk。这篇文章把整个思路、踩过的坑、以及一套可以直接照抄的实操流程都写出来给同样在并行Agent工作流里挣扎的人做个参考。1. 并行AI Agent工作流为什么非用Worktree不可1.1 多Agent并行开发的真实痛点先说个最常见的场景你手上有一堆小任务比如给服务加一个接口、修一个样式bug、重构一个函数。每个任务看起来都不大你懒得开完整流程于是想让Agent自己干。一旦你同时跑两个或多个Agent混乱就开始了。最直接的冲突在文件层面。两个Agent在同一个目录下改代码A刚生成的一个临时文件B可能以为是垃圾直接删了更常见的是依赖状态被互相踩踏——Agent A在跑npm installAgent B同时在修改package.json下一秒A的依赖树就错乱了。Node_modules还好Python的虚拟环境、编译缓存这些更是谁动谁乱。其次是分支切换的成本。同一个工作区从功能A切到功能B你得先把A的改动找个地方存起来stash或者临时commit再切分支等B的依赖装完可能还要处理缓存冲突。手工开发时这个切换成本还能忍Agent跑任务时这个成本会放大好几倍——因为Agent启动一次、读一次仓库、装一次依赖本身就很慢。你切来切去半天就过去了任务进度几乎没动。第三是上下文污染。这一点最隐蔽也最致命。AI Agent的上下文里如果混入了不属于当前任务的文件、调试日志、未完成的半成品代码它的理解和生成质量会肉眼可见地变差。我在实际测试里发现同一个模型在干干净净的仓库里写代码通过率明显更高一旦工作目录里有很多跟当前任务无关的杂乱文件它就开始推理出一些根本不存在的东西幻觉率直线上升。给Agent一个干净的隔离工作区不只是方便是直接关系到输出正确性的。1.2 Git Worktree机制到底解决了什么Git Worktree是Git 2.5就开始支持的功能但很多人没用过。它的核心机制是一个仓库可以有多个工作目录每个工作目录对应一个分支它们共享同一个.git仓库的对象和引用数据库。打个比方仓库的.git目录就像一个中央仓库而多个worktree是多个互不干扰的工作车间。每个车间有自己的桌面工作区文件、自己的图纸HEAD、自己的半成品暂存区index但所有车间共享同一个原材料库objects database。你在车间A干活不会碰到车间B的桌面但两边用的原材料是同一套。这种机制天然适合并行Agent工作流。给Agent A开一个worktree指向feature/login分支给Agent B开另一个worktree指向feature/payment分支两个Agent各自在自己的目录里改代码、跑测试、提交commit互不干扰。它们可以同时跑不需要等对方完成。但这里有个反直觉的约束同一时刻同一个分支只能被一个worktree checkout。原因在于worktree共享的是整个仓库的refs如果两个worktree同时checkout同一个分支git没法保证它们的HEAD和index一致。所以基本操作范式是每个worktree绑定一个独立分支而不是都挂在main上。原生git worktree命令本身是对的可用起来有几个痛点特别折磨人git worktree add的参数太底层。每次要手动想路径、想分支名、想从哪个base拉出来命令一长串很容易写错。缺少任务维度的视图。你看不出哪个worktree对应哪个Agent、对应哪个任务时间一长目录多了就乱。不知道哪个worktree是空闲的、哪个是活跃的。回收清理全靠人肉判断一个不小心git worktree remove还会因为脏文件报错。没有跟AI编码CLI工具的集成。每次创建完worktree还得手动cd进去、启动Agent、记住路径麻烦。把这些痛点总结成一句话Git Worktree本来是把好刀但它只有刀片没有刀柄更没有刀鞘和标签。Worktrunk的出发点是给这把刀配上一套完整的管理壳子让它适配AI Agent的任务化工作流。2. Worktrunk核心设计思路把Worktree当任务单元来管2.1 命令设计理念围绕任务而不是围绕分支Worktrunk的第一个核心决策是把用户操作对象的抽象层级从分支提升到任务。这是它跟原生git worktree最大的不同。原生命令的世界里你关注的是我要基于main创建一个分支feature/aaa然后开一个worktree放在../feat-aaa而Worktrunk的世界里你只需要说我要创建一个任务tk-101基于main功能是登录页重构。剩下的分支名怎么起、目录放哪里、base从哪里拉都由工具统一编排。以我实际使用的标准核心命令大概是这样一组# 初始化目录约定 wtr init # 创建一个任务工作区 wtr task create tk-101 --base main --name login-refactor # 查看所有任务状态 wtr task list # 快速进入某个任务的工作区 wtr go tk-101 # 标记任务完成并合并清理 wtr task done tk-101 # 清理所有已归档任务的残留 wtr prune这套命令最大的好处是心智负担小。Agent跑任务时你不需要记目录在哪、分支叫什么、步骤到哪了只要认任务ID就行。任务变成了整个工作流里的一等公民分支、worktree、目录这些都成了被任务ID牵引的附属细节。从工程角度看围绕任务设计还有一个隐藏优势可观测性更好。因为任务是用户真正关心的单元围绕它去查询状态、定位问题、回收资源都比围绕底层git对象要自然得多。我在用的时候最大的感受就是——终于不用每次先git worktree list然后对着路径猜了。2.2 状态追踪与生命周期管理Worktree管理里最容易被忽视的部分是状态。原生git worktree完全不知道你的worktree在干嘛它只关心有没有被checkout。但一个Agent工作流里worktree是有生命周期的从创建到被Agent使用到提交审查再到合并清理。Worktrunk通过在本地的元数据文件记录每个任务的详细信息我最初的实现是在仓库根目录放一个.wtr/tasks/目录每个任务一个JSON文件大概长这样{ id: tk-101, name: login-refactor, branch: wtr/feature/login-refactor, path: .wtr/workspaces/tk-101, status: running, createdAt: 2026-02-10T14:30:00Z, baseBranch: main, agentLog: .wtr/logs/tk-101.log }状态机我设计成了这样几个阶段pending任务创建完成分支已建好Agent还没启动。runningAgent正在工作区里干活。reviewAgent已经提交代码或开了PR等待审查。merged代码已合并进主干工作区待清理。archived已归档不再出现在默认列表里。有了这套状态wtr task list一眼就能看出哪个任务卡住了、哪个可以清理、哪个还在跑。相比对着git branch和git worktree list猜效率提升是实打实的。我还做了一个细节每个任务创建时会自动生成一个独立的日志文件。Agent跑任务时的输出全部重定向到这个日志里后面排查问题特别方便。你能看到Agent到底做了什么、卡在哪一步、报了什么错而不是对着终端滚动日志干瞪眼。2.3 与主流AI编码工具配合Worktrunk本身不是Agent调度器它只负责管理Agent的工作空间。所以跟Codex、Claude Code这类AI编码CLI工具的配合非常关键。配合的方式其实很简单把这些工具的工作目录显式指向worktree目录。比如codex exec --cd .wtr/workspaces/tk-101 实现登录页表单校验逻辑或者Claude Codecd .wtr/workspaces/tk-102 claude -p 修复支付流程里金额精度问题关键点有三个第一每个Agent必须绑定到自己独立的worktree目录不要让它们共享一个目录。这从物理上保证了隔离性。第二Agent启动时的环境要干净。不要继承你主目录里那些乱七八糟的node_modules、缓存、虚拟环境尽量让Agent在worktree里重新安装依赖。虽然多花一点时间但能避免大量诡异的环境问题幻觉。第三Worktrunk的元数据可以当作Agent任务的记录中心。我在实际用的时候会在agent的提示词里把任务ID和描述带进去让Agent知道自己在干什么、日志该写到哪。这样即使同时跑五六个任务每段工作的归属依然清晰。3. 实操实录从安装到跑通一套并行Agent工作流3.1 安装与初始化Worktrunk的安装本身不复杂。我最初是用Go写的单二进制文件发布时直接给不同平台的预编译包也可以用npm全局安装npm install -g worktrunk装完后需要在目标仓库里初始化cd ~/projects/my-service wtr initwtr init会做几件事检查当前目录是否是合法Git仓库在仓库根目录创建.wtr/结构workspaces、logs、tasks三个子目录写下.gitignore规则把.wtr/排除在版本控制之外。这里有个设计细节值得说一下worktree目录放在仓库内还是仓库外各有利弊。放在仓库内比如.wtr/workspaces/好处是路径短、直观坏处是这些目录会出现在根目录的列表里看着有点乱放在仓库外比如~/.worktrunk/repo-name/task-id好处是仓库目录干净坏处是跟仓库的关联需要靠元数据记住。我最终选择了仓库内的方案但加了.gitignore隔离这样worktree从git的角度是不可见的不会污染主仓库的状态。如果你之前用过git worktree add应该知道worktree目录在被添加时会自动出现在主仓库的git status里这个体验其实是有点怪的。放在.wtr/workspaces/并且ignore掉之后主仓库永远保持干净只有你主动去查任务列表时才会看到那些目录。3.2 创建Agent工作区并绑定任务初始化完成后创建任务工作区就是一条命令wtr task create tk-101 --base main --name login-refactor执行过程大致是这样校验任务ID是否已经存在避免重复。自动生成分支名默认格式是wtr/feature/login-refactor。用git worktree add创建worktree目录是.wtr/workspaces/tk-101。写入任务元数据JSON。输出一段提示告诉你worktree路径、分支名、以及一个可以复制的Agent启动命令示例。创建完之后你就可以直接进入该目录跑Agent了。我个人常用的流程是这样cd .wtr/workspaces/tk-101 codex exec 根据设计文档实现登录页的后端接口记得写单元测试注意一点创建worktree时如果base分支有最新的远端更新wtr task create会自动帮你fetch或rebase对齐。我踩过不少次基于一个过期的main创建分支结果Agent跑出来的代码跟现有代码冲突的坑所以这个自动对齐base的逻辑我觉得非常必要。3.3 切换、同步与清理当任务数量多起来之后最常有用的就是两个命令切换和清理。切换任务工作区我用的命令是wtr go tk-102它做的事是解析任务ID找到对应worktree路径然后cd进去并弹出一个提示告诉你当前分支和上次Agent日志的最后几行。这个小提示很实用相当于你每次回到一个任务现场时它能帮你快速恢复记忆。同步代码这块我设计了一个wtr sync命令wtr sync tk-101它会在指定worktree里执行git fetch、合并base分支的更新并把结果记录到元数据里。为什么不能简单地在worktree里手动跑git merge main因为并行Agent工作流里的同步往往涉及多个worktree逐个手动操作太烦而且容易漏。写成命令后可以一条命令把所有running状态的任务全部同步一遍。清理流程是这样wtr task done tk-101 wtr prunewtr task done会把worktree的改动合并回主干默认用--merge模式自动处理冲突冲突时会停下来提示然后标记状态为merged。wtr prune则负责把所有merged或archived状态的worktree物理删除。这里有个安全措施我强烈建议加上prune默认走--dry-run模式只打印将要清理的列表不真正删除。确认无误后再加--force执行。我自己的习惯是先dry run看一眼再手动review一遍最后再force基本没出过误删的事。4. 常见问题与排查技巧实录4.1 Worktree清理不掉怎么办这是用worktree最经典的问题。你在worktree里跑过Agent之后目录里全是乱七八糟的文件——临时文件、生成的依赖、Agent创建又没删的脚本——然后你想git worktree remove它git会报错fatal: working tree contains modified or untracked files普通人的第一反应是加--forcegit worktree remove --force。这个能删掉但有个隐患如果worktree里有还没提交的改动加force后这些改动就永远消失了。Agent跑的半成品代码可能在里面。所以排查优先级应该是先看worktree里有没有值得保留的改动git -C path status --short如果有未提交代码先commit到该worktree的分支上或者手动复制出来到安全位置。确认无误后再wtr task done走正规清理流程或手动git worktree remove --force。另一个常见情况是worktree目录本身被删了但git的worktree元数据还留着。这时候git worktree list会显示一个不存在的路径git worktree remove也会报错。解法是用git worktree prune让git自动清理失效的元数据。Worktrunk的wtr prune在底层做了类似的事它会先调git worktree prune再清理自己的任务元数据。4.2 分支冲突和共享分支的坑并行Agent工作流里最容易犯的错是让两个Agent在同一个分支上干活。表面上看它们在不同worktree似乎互不影响但它们的分支绑定关系是冲突的——git会禁止第二个worktree在相同分支上checkout。如果真遇到需要在多个worktree之间共享代码的场景比如一个Agent要调用另一个Agent刚写的模块我的建议是短期的共享用git fetch 手动cherry-pick或git merge同步不要让两个worktree同时checkout同一分支。中期的共享把公共代码抽到独立分支然后需要用的Agent通过git merge合并过来。长期的共享直接改成单个Agent串行处理别硬并行。还有一个特别隐蔽的坑git branch -D删除分支时如果这个分支正被某个worktree checkoutgit会拒绝删除并给出提示。很多人在主仓库里看到分支名还在以为是分支删不掉其实是worktree占着。同样如果你用wtr task done合并完代码后发现分支还在先看看是不是有worktree没有清理。4.3 与AI编码CLI配合的几个坑我实际用Codex、Claude Code这类工具时碰到过几个跟worktree强相关的坑这里挨个说。第一个坑是Agent在worktree里执行git命令时偶尔会报dubious ownership错误。原因是worktree目录的owner跟当前用户不一致比如你是用root创建的目录又用普通用户跑Agent。解法是全局配置里加一句git config --global --add safe.directory *注意这个配置加了之后所有git目录都会信任安全性上有取舍最好是把具体路径加进去而不是用通配符。第二个坑是Agent会自动执行git pull或git fetch但worktree因为共享refs如果在多个worktree里同时对同一个remote做fetch偶尔会有锁冲突。表现是Unable to create .../.git/index.lock: File exists。解法很简单锁文件一般是残留删掉就好如果频繁出现说明你的Agent命令里不该加自动fetch逻辑。第三个坑是Agent的日志输出会被项目里的node_modules或Python虚拟环境干扰。有些Agent会在当前目录里搜索文件结果被几万个依赖文件塞满上下文导致响应变慢、质量下降。我的做法是把worktree的目录结构严格控制——依赖目录用.gitignore排除Agent工作目录的上下文尽量精简把项目无关的配置文件都放到上一级目录不让Agent扫描到。第四个坑跟提示词有关。如果你在创建任务时通过Worktrunk生成了一段任务简报一定要让Agent知道它的工作目录在哪、日志写到哪。否则Agent自作主张在工作区外的路径写日志很容易污染别的任务。我目前的做法是在任务描述里固定带上所有中间文件请写入当前目录下的.tmp-worktrunk-hint.md这行字然后Worktrunk在清理时会一并处理掉实测效果还行。5. 一些实操心得与后续扩展方向Worktrunk这套思维和工具我实际用了大概三四周时间最大的感受是并行Agent工作流的核心瓶颈不是Agent模型的聪明程度而是工作区的管理水平。模型再聪明在一个混乱的、塞满无关文件的目录里也会变笨反之只要工作区隔离干净、分支绑定明确、任务状态可查普通模型的产出质量也能稳定维持在一个很不错的水平。几个很实在的心得按重要性排序先戴上任务视角再谈工具。不要总想着我要开一个worktree而是想我要跑一个任务。这个心智转换让我省了大量不必要的纠结——分支名、目录名这些全是细节交给工具就好。清理要勤快。worktree跟分支一样只要不清理就会越堆越多。我自己的节奏是每个任务结束当天就wtr task done加wtr prune绝不让worktree过夜。对Agent的输出保留怀疑验证心态。worktree把结果隔离得很干净但你仍然要在合并进主干前认真审查。我一般会让Agent先提交到自己的分支然后本地跑一遍关键测试再合并。日志是救命稻草。没有日志的并行Agent工作流出了问题你连从哪查都不知道。Worktrunk把每个任务的日志独立记录这个习惯值得在任何Agent工作流里沿用。扩展方向上我目前正在试的是跟仓库管理平台的集成。比如任务完成后一键创建PR或者在wtr task list里直接显示CI状态。另外一个方向是团队协作——多个人各自跑Agent共享同一个仓库的worktree池但通过中央元数据同步任务状态这样能避免两个人无意中创建同一个分支名导致冲突。最后分享一个小技巧如果某个任务卡住了不要急着删先wtr task list看状态再tail -n 50 .wtr/logs/task-id.log看日志一般三分钟内能定位是Agent卡住了、代码跑挂了、还是git锁冲突。这套排查路径我反复用基本靠它就够。
