现在用 AI Agent 写代码已经不算新鲜事了但真正要把多个 AI Agent 同时扔进同一个仓库并行干活场景就会变得相当棘手。我最近在整理团队这套并行工作流时发现一个非常顺手的工具叫 Worktrunk它把 Git Worktree 的管理能力封装成一个专门面向 AI Agent 场景的 CLI恰好解决了分支冲突、目录隔离和状态管理这些让人头疼的问题。简单说它能帮你在本地同时管理多个互相隔离的工作目录每个目录对应一条独立分支供不同的 AI Agent 去并行开发最后再统一同步、合并、清理。对于同时在用 Codex CLI、Claude Code 这类 Agent 工具做多任务开发的团队来说这个思路很值得借鉴。这篇文章我就以自己实际搭过的并行 Agent 工作流为例说清楚 Worktrunk 到底解决了什么、它是怎么设计的以及踩过了哪些坑。1. 并行 AI Agent 工作流的痛点与 Worktrunk 定位1.1 AI Agent 编程到底在什么场景下需要并行先说场景。很多团队用 AI Agent 开发通常不是只派一个任务而是一批任务同时进行。比如我最近手里就同时开着三个任务一个让 Agent 重构用户模块的数据库查询逻辑一个让 Agent 新增导出报表的接口还有一个专门去修历史遗留的测试失败。在理想状态下三个 Agent 各自独立推进、互不干扰最后把成果合并回主干效率会非常高。但如果你真把多个 Agent 放在同一个工作目录里跑麻烦马上就来了。Agent 本身并不理解你的 git 分支状态它只会机械地改文件、跑命令、提交代码。假设 Agent A 在改用户模块的时候Agent B 也在同一个仓库工作B 很容易把 A 尚未提交的半成品改动也当成自己的基线然后在提交时把这些文件一起带上。我最早用最笨的办法每个任务开一个分支手动切换目录或者切换分支来操作结果 Agent 在旧分支上生成的改动用 checkout 切走之后经常找不到或者错误地把改动带到了新分支上。那种感觉就像两个人在同一张纸上各自画画彼此都能看到对方笔迹根本没法专注。所以核心问题不是 Agent 本身不好用而是缺少一层“工作区隔离”。并行 AI Agent 工作流真正需要的是每个 Agent 拥有独立的代码目录、独立的分支、独立的环境状态互不污染同时这个目录又必须和仓库保持底层联动让代码历史和对象库是共享的不能每开一个 Agent 就 clone 一份完整仓库。这两个需求放在一起Git Worktree 几乎就是天然答案。1.2 Git Worktree 为什么是解决冲突的关键Git Worktree 是 Git 自带的功能原理非常朴素同一个仓库可以拥有多个工作树目录每个工作树在某个时刻绑定一个分支彼此独立。你可以在 /repo/main 上跑主分支同时通过git worktree add创建 /repo/task-a 和 /repo/task-b它们分别检出新分支。底层共享同一份 .git 对象库不会重复下载历史也不会复制整个仓库内容磁盘占用增量很小。用起来之后并行开发的体验会完全变样。Agent A 在 /repo/task-a 里提交代码Agent B 在 /repo/task-b 里提交代码两边文件系统完全隔离互相看不到未提交的修改。各自的构建缓存、依赖目录也可以独立保留A 装了什么包不会影响 B。最让我满意的一点是所有 worktree 都在同一个本地仓库里所以从任何一个目录执行 git log、git diff、git branch 都能看到完整历史不用来回切路径。有人可能会问这和直接 clone 多个仓库有什么区别区别在于对象库共享。clone 多份仓库意味着每个目录都要维护远程跟踪、都要重新拉取全部历史而 worktree 是一份 .git 元数据加多份工作目录分支切换、对象查询、增量拉取都很快。更关键的是最后合并回主分支时因为它们都源于同一个仓库对象库分支间的 merge 和 rebase 操作可以在本地直接完成不需要 push 到远程再拉回来绕一圈。1.3 为什么手动管理 worktree 还不够既然 Git Worktree 这么好用为什么还需要 Worktrunk 这种额外封装如果你只开一两个 worktree原生命令确实够用。但一旦你像我一样同时跑四五个 Agent 任务手动管理 worktree 的痛点就会集中爆发。首先是命令碎片化。创建一个 worktree 要git worktree add查看状态要用git worktree list清理失效文件要git worktree prune删除 worktree 还要先确认分支状态。这些命令本身不难难的是把它们组合成一个完整流程。每个 Agent 任务通常要经历创建、绑定分支、同步主干、提交、推送、合并、清理这几个阶段每走一步都要手工操作一个不留神就漏掉了 rebase。其次是状态不透明。原生 git 只会告诉你有哪些 worktree 目录不会告诉你这个 worktree 对应用户故事里的哪个任务、当前分支有没有提交、有没有未推送的 commit、上次同步主分支是什么时候。Agent 任务一多我经常要挨个目录跑 git status 才能搞清楚谁干到哪了非常浪费时间。Worktrunk 做的事就是把这一堆分散的 git 操作和状态检查收拢成一个面向任务的 CLI。它不改变 Git Worktree 底层的机制而是加了一层“任务级抽象”你创建的不只是一个 worktree而是一个再带上任务编号、分支名、目录路径、同步状态的工作单元。用一条命令能列出所有并行工作区一条命令完成同步和推送一条命令安全清理已合并的任务。对我这种每天要和多个 Agent 打交道的开发者来说这个抽象层带来的提升非常明显。2. 设计思路Worktrunk 是怎么把复杂流程藏起来的2.1 为什么选择 CLI 而不是 GUI站在工具选型的角度Worktrunk 选择 CLI 而不是 GUI我认为是必然的。原因很直接AI Agent 工作流本身就构建在终端之上。无论 Codex CLI 还是 Claude Code它们都是命令行工具Agent 想要操作项目必须先能理解命令、执行命令、解析命令输出。如果 Worktrunk 做成图形界面Agent 根本没法直接调用它。CLI 的另一个优势是脚本友好。我日常会把 Worktrunk 命令写进 shell 脚本、Makefile甚至接进 CI。比如每天早上我会跑一条组合命令把所有的 worktree 全部 sync 一遍这样即使某个 Agent 干到一半卡住了它的分支也始终基于最新的 main最后合并不至于冲突得面目全非。GUI 工具没法这么轻量地嵌入到这种自动化的流程里。CLI 也方便输出结构化数据。Worktrunk 的 list 或者 status 命令可以输出 JSON 格式这样下游无论是 jq、Python 脚本还是 CI 系统都能很方便地解析每个 worktree 的状态。我在本地写了一个小脚本用 worktrunk 的 JSON 输出自动生成一个“并行任务看板”哪个任务干净、哪个有未推送提交、哪个已经合并完成了一眼就能扫出来。这种玩法是 GUI 工具很难提供的。2.2 数据模型与目录约定Worktrunk 的底层模块怎么划分我虽然没有读过 Worktrunk 源码但从用下来的行为来推断它的底层应该维护了一个 worktree 注册表可能是一个 JSON 或 TOML 配置文件记录每个工作区的元数据。一条典型记录会包含 task id、分支名、目录路径、基准分支、创建时间、上次同步时间、当前状态是否干净。这样不管当前 shell 在哪个目录下worktrunk 都能定位到全量的工作区信息。目录约定也很重要。Worktrunk 默认会把所有 worktree 统一放到一个规划好的根目录下比如 ~/worktrunks/项目名/任务ID避免每个 worktree 散落在不同地方。这个设计看起来简单但实际用起来非常省心。以前我手动 add worktree 时目录路径经常随手写时间一长自己都忘了哪个目录对应哪个分支现在直接按任务编号找目录不需要任何记忆成本。在命令设计上我的使用习惯大致是这样init 用来初始化某个仓库create 创建新的任务工作区list 查看全量状态sync 把某个工作区同步到最新主干merge 把分支合并回目标分支destroy 清理已经工作完成的分支。每个命令都尽可能只做一件事并且默认带保护机制。这条设计路径和大多数成熟的开发者工具是一脉相承的简单命令、显式状态、可组合流程。2.3 同步与合并策略的关键取舍多个 Agent 并行开发最核心的策略问题是怎么处理主干分支的演进。假设三个 Agent 都基于 main 分支拉出自己的开发分支运行一段时间后main 上可能已经被合并了 hotfix 或者别的任务代码。这时每个 Agent 的分支都落后于 main。如果放任不管几个任务最后的合并冲突会非常惨烈。Worktrunk 在 sync 时一般会采用 rebase 策略也就是先把主干的最新提交拉下来然后把当前分支的提交“重新播放”到主干最新提交之上。这样做的原因是多个基于同源分支并行开发的场景里rebase 能保持一条线性历史到了最后合并阶段冲突会在一开始就暴露出来而不是攒到集中 merge 时一次性爆发。相比之下merge 虽然保留的语义更丰富但在频繁同步的开发分支上会引入大量合并提交可读性会差很多。合并回主分支的时候我反而建议保留一些痕迹。比如本地用git merge --no-ff把功能分支合并回 main会生成一个明确的合并提交方便回溯“这个改动对应的是哪个 Agent 任务”。Worktrunk 在 merge 环节会做类似的事情它会帮你执行 merge、提交、推送并且在完成后提示是否清理这个 worktree。这套组合策略用下来非常顺手同步用 rebase 保持清晰合并且用 merge commit 保留上下文。2.4 安全设计防止误删未推送分支做并行工作流管理工具有一个地方必须设计得非常谨慎那就是删除和清理。一个开了 5 个 worktree 的人某个时间点想收拾一下空间如果工具不做任何校验一条 force 命令可能就把某个分支上还未来得及推送的提交全部删掉这种损失很惨重而且很难恢复。Worktrunk 在 destroy 前会检查两件事第一当前分支有没有未提交的改动第二当前分支有没有落后于或者领先于远程的提交。如果检测到脏分支或者未推送的提交它会拒绝清理并明确提示你先处理状态。只有当你显式加 force 参数时它才会强制删除。这个保护机制很关键尤其是在多个 Agent 并行工作时有些任务你以为结束了实际上 Agent 可能刚刚产生了新的提交还没推上去。我个人的建议是在团队协作中不要轻易使用 destroy 的 force 选项。所有清理动作最好是经过 code review 或至少看一眼分支状态之后再进行。Worktrunk 这种“默认校验、显式打破”的方式正好适合这种需要谨慎清理的场景。3. 实操用 Worktrunk 搭建一套并行 Agent 工作区3.1 安装与环境准备我是在 macOS 上开始用 Worktrunk 的安装方式和大多数 Go/Rust 生态的工具类似可以用包管理器直接安装也可以通过一条安装脚本搞定。Windows 环境下也有对应的二进制包我团队里有同事在 WSL 里跑得也挺顺畅。安装完之后先确认版本号能正常输出。在正式使用前建议把本机 Git 版本升级到 2.30 以上最好用 2.40 之后的版本因为 worktree 相关的锁机制和分支跟踪在旧版本上有一些小毛病升级以后省得踩坑。另外如果你打算让 Agent 帮你大量提交代码建议在全局 git config 里设置好 user.name 和 user.email否则多个 worktree 里提交时很容易因为缺少身份信息而报错再去挨个补配置很烦。我习惯先准备一个统一的 worktree 根目录比如 ~/worktrunks然后为每个项目在其下建子目录。这样所有并行任务都集中在同一个地方磁盘清理和备份都比较方便。如果你的项目已经存在于本地直接在项目根目录执行 worktrunk init 即可它会读取当前 git 仓库信息并生成配置。3.2 创建多个隔离的 Agent 工作区初始化完成后就是创建具体的工作区。以一个用户服务项目为例我通常会这样为任务开新目录worktrunk create \ --name user-refactor \ --branch feat/user-refactor \ --base main \ --path ~/worktrunks/user-service/user-refactor这条命令的作用是基于 main 拉出一个新分支 feat/user-refactor并且在 ~/worktrunks/user-service/user-refactor 目录下创建一个新的 worktree。创建完成后这个目录就是一个独立的开发环境和主工作区互不干扰。如果我们并行跑三个任务就再创建两条类似的命令换成不同的任务名、分支名和路径。创建好之后用 worktrunk list 可以看到全部工作区的状态包括目录路径、当前分支、有没有未提交改动、当前是否已同步。这个聚合视图就是我前面说的“任务看板”的基础。有一点需要注意创建 worktree 后新的分支默认是从 base 分支当前位置生成的。我一般都会确保 base 分支已经 fetch 到最新也就是先git fetch origin git pull --rebase一下主分支再创建 worktree。如果 base 分支太老后面 Agent 改完再同步冲突概率会高很多。3.3 绑定 Agent 任务并启动并行任务worktree 创建好之后真正的 AI Agent 工作流就开始了。我这里说“绑定”其实就是把 Agent 的工作目录指向对应 worktree。比如用 Codex CLI 跑用户模块重构任务就进到对应 worktree 目录再启动 Codexcd ~/worktrunks/user-service/user-refactor codex 重构用户模块的数据库查询逻辑保持接口不变同时另一个终端里可以进到 report-export 的 worktree启动另一个 Agent 让它去写导出报表接口。两个 Agent 的文件修改范围完全隔离提交时也只会提交各自 worktree 内的改动不会再出现互相污染的情况。这里有个非常关键的经验不要在创建 worktree 之后直接把整个仓库路径传给 Agent一定要使用 worktree 的具体子目录路径。有些 Agent 支持 --workdir 参数可以显式指定工作目录有些则依赖当前 shell 的路径。无论哪种方式都要确保 Agent 的启动路径确实在目标 worktree 里否则它可能在主工作区里面乱改文件隔离就白做了。启动多个 Agent 并行跑之后我通常会每个一段时间跑一次 worktrunk list看看哪个 worktree 状态变脏了、哪个已经提交了。如果发现某个 Agent 长时间没有提交我会去那个目录里看一眼日志判断它是卡住了还是在思考避免机器空转浪费额度。3.4 同步代码、验证与合并回主分支Agent 完成了代码修改并提交到本地分支后事情还没完。下一步是把工作区分支同步到最新的 main然后把改动推送到远程。这个环节我用 Worktrunk 的 sync 命令来完成worktrunk sync --name user-refactor这条命令做的事情本质上是 git fetch 远程的 main然后把当前分支 rebase 到最新的 main 上。如果 rebase 过程中出现冲突Worktrunk 会停下来告诉你哪些文件冲突需要手动解决。我会在这种时候打开冲突文件看一下通常 Agent 修改的代码和 main 上其他任务的改动会有少量重叠人工处理几分钟就能搞定。同步完成后就该跑一遍验证。我一般会在 worktree 目录里执行项目的测试和 lint确保 Agent 的改动没有破坏已有功能。这个步骤一定不能省因为 Agent 生成的代码经常在逻辑上看着没问题但一跑测试就会暴露出边界情况。验证通过后把分支推送到远程git push origin feat/user-refactor最后是合并回主分支。如果团队有 code review 流程我建议先推送到远程然后发起 Pull Request而不是本地直接合并。PR 的好处是能让另一个开发者看到 Agent 的全部改动人机协作的质量会高很多。如果只是个人项目或者内部工具用 Worktrunk 的 merge 命令直接合并回 main 也可以commit message 里带上任务编号就行。3.5 清理与回收分支合并回 main 并推送成功之后本地那个 worktree 就不再需要了。这时候用 destroy 命令清理worktrunk destroy --name user-refactor因为前面提到 Worktrunk 默认带保护校验如果 worktree 分支上还有未被合并的提交它会拒绝删除并给出警告。确认一切都已合并、推送这个命令才会真正执行 git worktree remove 和分支删除。清理完之后用 worktrunk list 再看一眼确认工作区已经释放磁盘空间也回来了。有时候 Agent 会在 worktree 里留下一些未跟踪的临时文件比如日志、缓存、临时脚本。这种情况下 destroy 会提示你先清理这些文件或者手动确认强制删除。我个人的习惯是先看一遍有什么文件再删因为 Agent 偶尔会留下一些有价值的中间产物比如它生成的 migration 脚本或者调试用的测试文件处理完再删除会更稳妥。4. 配置、参数与团队协作的实战经验4.1 常用配置项与典型配置Worktrunk 的配置逻辑并不复杂但合理配置能省掉很多重复操作。我比较关注的配置项主要有几块这里用一张表说明配置项作用我的推荐值workspace_rootworktree 的根目录~/worktrunks/项目名base_branch所有任务分支的基准分支mainsync_strategy同步策略rebase 或 mergerebasecleanup_on_merge合并后是否自动清理 worktreetruerequire_clean_state清理前是否要求工作区干净true一个典型的配置文件大概长这样[worktrunk] workspace_root ~/worktrunks/user-service base_branch main sync_strategy rebase cleanup_on_merge true require_clean_state true [project] name user-service remote originsync_strategy 是我会认真选的一个选项。前面说过并行开发时我推荐 rebase但如果你更习惯保留演化的完整历史也可以设置成 merge。我用了几个项目之后还是觉得 rebase 更省心尤其是在 Agent 并行场景下主线变更很快用 rebase 能及时把冲突摊平到每一个任务分支上而不是攒到最后一次性爆发。另一个值得研究的是 require_clean_state。如果你开的 Agent 任务很多工作区里经常会有 Agent 留下的未提交临时文件开着这个选项会让 destroy 经常提醒你先清理。我一开始觉得麻烦后来反而觉得这个提醒很有价值它逼着你定期审视每个 worktree 的状态不会让垃圾文件一直堆积。4.2 分支命名与任务编号规范并行 Agent 任务一旦多起来分支命名如果不规范很快就分不清谁是谁。我这里有个强制规范格式是类型/任务编号-简短描述比如 fix/TASK-102-login-error、feat/TASK-105-export-report。类型一般取 feat、fix、refactor、chore 这几个常用前缀任务编号和你在项目管理工具里的任务 ID 一一对应。这样做有几个明显好处。第一看到分支名就知道这个 worktree 在做什么任务不需要再去翻 Agent 的对话记录。第二Agent 提交代码时我一般会让它在 commit message 里也带上任务编号这样后续追溯时git log 里每一条提交都能直接关联到需求上下文。第三合并或者清理时分支命名规范的目录可以按任务编号自动排序配合 worktrunk list 看起来非常整齐。我在配置里会再额外加一条分支名里面不要带空格、斜杠以外的特殊字符尤其不要让 Agent 自己生成分支名。Agent 起名字的能力忽高忽低有时候会生成一串无意义的字符不如我们在创建 worktree 的时候就把名字定死这样可维护性高得多。4.3 与 CI 集成做并行任务的自动检查Worktrunk 作为 CLI天然适合进 CI。一个很实用的场景是每天晚上定时对所有正在进行的 worktree 分支跑一次同步和测试这样第二天早上我打开电脑就能看到哪些分支同步失败哪些测试挂了。把这个逻辑写成一个简单的流水线脚本就能实现。CI 脚本里通常会这样用worktrunk list --json | jq -r .[].workdir | while read dir; do cd $dir npm test || echo Tests failed in $dir done用 jq 解析 worktrunk 输出的 JSON拿到每个 worktree 的目录然后逐一执行测试。这种方式比手动挨个进目录跑测试要高效得多尤其是在同时有七八个分支任务的时候一次 CI 运行就能把全部任务状态汇总出来。如果团队用 GitHub Action 或 GitLab CI也可以在 MR/PR 触发时用 worktrunk 创建一个临时的 worktree 来跑集成测试。这样做的好处是测试环境完全干净不会污染主工作区而且一次 MR 可以用多个并行 worktree 测试不同场景隔离性特别好。4.4 团队协作的几种姿势Worktrunk 不一定必须搭配 AI Agent 才能用。即使团队里有人不用 AI 编程也可以把它当作统一的 worktree 管理工具。最典型的做法是每个开发者本地用 Worktrunk 为每个需求开一个独立 worktree开发完合并回主分支再清理这样大家共用一个仓库时本地目录不会被别人的分支搞得乱七八糟。另外我建议团队在 README 里写清楚 worktree 目录的约定。比如统一使用 ~/worktrunks/项目名/任务ID 作为根目录。这样团队成员之间临时要看某个任务的分支时不用问“你那个任务是在哪个目录下开的”只要看任务编号就能直接找到路径。对多人协作来说路径即状态省掉很多沟通成本。如果团队对 AI Agent 的使用比较激进还可以给每个 Agent 分配一个独立的 worktree让 agent 的核心代码目录固定。这样即便 Agent 中途崩了、任务被中断另一个开发者可以直接进到对应目录接着干git 历史和工作区状态都保留在原地交接成本非常低。5. 常见问题与实战心得5.1 常见问题速查表用 Worktrunk 管理并行 worktree 的过程中我遇到过的典型问题基本都能归类到下面这张表里问题现象排查思路解决办法worktree add 报错“already checked out”目标分支已被另一个 worktree 占用换分支或先清理占用该分支的 worktreesync 时 rebase 冲突看不懂冲突文件多且杂用 git status 查看冲突文件配合 IDE 的 merge 工具逐步解决Agent 把自己改动提交到了主工作区启动 Agent 时没有指定 worktree 子目录确认 Agent 的 workdir 指向具体的 worktree 目录destroy 提示目录包含修改文件worktree 内有未提交或未跟踪文件先 commit 或 stash确认无用后再 force 删除git push 被拒绝远程有更新本地分支落后于远程跟踪分支先执行 worktrunk sync再重新 pushCI 里找不到 worktree 路径脚本里用了相对路径在 CI 中始终使用绝对路径定位 worktree这里面最典型的其实是 Agent 提交错目录的问题。这个 bug 不容易发现因为 Agent 的能力越来越强它完全有能力在别的目录里修改文件并提交。所以我的建议是在启动 Agent 后跑一条 git rev-parse --show-toplevel 来确认当前所在仓库根目录确认它确实指向目标 worktree。5.2 踩坑记录与避坑指南第一个坑是 build 目录引起的磁盘爆炸。多个 worktree 各自构建前端项目时每个目录下都会有 node_modules 和 dist 目录如果项目依赖很重五六个 worktree 就能吃掉几十 GB 磁盘。后来我把依赖目录设置成共享缓存或者干脆用 pnpm 这类硬链接友好的包管理器才把体积控制住。如果你用 npm 做大型项目这个问题影响会特别明显。第二个坑是多个 Agent 同时改依赖锁文件。 package-lock.json、go.sum 这类文件经常是并发修改的重灾区因为不同 Agent 在安装不同包时都会改动锁文件。这个冲突一旦出现解决起来很烦因为 lock 文件的 diff 基本没法手改。我现在会在任务分配阶段明确同一时间只允许一个 Agent 动依赖文件其他任务只改业务代码。第三个坑跟 git worktree 的底层机制有关。worktree 目录里不要手动去改 .git/worktrees/ /gitdir 这类元数据文件一旦改错整个 worktree 就废了而且排查起来非常痛苦。Worktrunk 的配置和状态管理已经足够用尽量使用工具命令而不是手动改底层文件。第四个坑是嵌套 git 仓库。有些 Agent 会在 worktree 目录里初始化一个新的 git 仓库比如它自己 clone 了一个子项目进去。这会导致外层仓库把内层仓库当成 submodule 或者 untracked 目录状态非常混乱。遇到这种情况我会先让 Agent 不要嵌套 clone如果确实需要第三方代码用包管理的方式引入而不是把仓库 clone 进 worktree。5.3 我的使用建议体验过一段时间 Worktrunk 之后我对并行 AI Agent 工作流的建议可以浓缩成几条很实在的结论。第一建议从两三个 Agent 并行开始起步不要一上来就开七八个。并行任务越多分支冲突、磁盘占用、状态管理的复杂度会指数级上升。先跑通两三个把 Worktrunk 的配置和团队规范定下来再逐步加任务。第二不要让“同步”变成日抛操作。每个 Agent 任务开始前和进行中都应该定期运行 worktrunk sync。最怕的是让 Agent 闷头干了很久不跟主分支同步最后一合并冲突全挤回来处理成本高得离谱。我通常每小时至少同步一次如果 Agent 跑得特别快就缩短到每完成一个子任务就同步一次。第三Agent 的提交信息尽量规整。可以要求 Agent 在 commit message 里带上任务编号也可以在 worktree 创建时自动把任务编号注入到分支名里。这样即便 Agent 的代码质量偶有波动你在追溯变更时也不会大海捞针。最后别忘了定期清理。合并完的分支和 worktree 该删就删不要留着攒垃圾。Worktrunk 的 destroy 保护机制已经帮你挡掉了误删风险不用担心清理过度。保持工作区干净不仅是为了磁盘空间更是为了让 worktrunk list 的输出一眼扫过去就能看清当前真正活跃的任务。说实话从手动切分支到用 Worktrunk 管理并行 worktree我觉得最大的变化不是省了多少条命令而是终于敢放心地把多个任务同时交给 AI Agent 去跑了。以前我总是提心吊胆怕它们在同一个仓库里互相踩现在每个 Agent 一个独立目录git 层天然隔离同步后再合并每一步都有清晰的状态可查。如果你也在并行跑 AI Agent 写代码我建议你先找一个简单的两任务场景试一下跑通一次之后你很快就会发现 Worktrunk 解决的不只是命令简化而是整套并行开发流程的安全感。