企业官网建设流程全解析

现在用 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 目录，再启动 Codex：

cd ~/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 的配置逻辑并不复杂，但合理配置能省掉很多重复操作。我比较关注的配置项主要有几块，这里用一张表说明：

一个典型的配置文件大概长这样：

[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 = "origin"

sync_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 的过程中，我遇到过的典型问题基本都能归类到下面这张表里：

这里面最典型的其实是 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 解决的不只是命令简化，而是整套并行开发流程的安全感。