前两天我在重构一个老项目时，遇到了一个熟悉的困境。

我想尝试一种新的架构方案，但又担心把主分支搞乱。传统的做法是开个新分支，但分支切换需要提交或暂存当前改动，这对于还在探索阶段的代码来说太麻烦了。

我就在想…要是有个地方能让 AI 助手随便折腾，不影响我的工作区，该多好。

没想到，Qwen Code 最新版本刚好加了这样一个新特性。

这个新特性的核心是 Git Worktree 支持，通过两个新工具和一个新参数实现。

一开始我以为就是个普通的 Git 功能封装。但仔细看了实现后，我发现这个设计触及了一个更深层的问题——我们如何在同一个项目中安全地探索多个可能性？

---

这是什么新特性？

简单来说，这个新特性给 Qwen Code 添加了两个新工具和一个参数。

两个新工具

• enter_worktree：进入一个 git worktree（工作树）
• exit_worktree：退出并可选择清理 worktree

一个新参数

• agent 工具的 isolation: 'worktree' 参数

如果你不熟悉 git worktree，可以把它理解为「平行宇宙」。

传统的 Git 分支是在同一个工作区里切换，你需要先提交或暂存改动。而 worktree 允许你在同一个仓库的不同目录中同时检出多个分支，每个目录都是独立的工作区。

这意味着你可以让 AI 助手在一个隔离的 worktree 里随便折腾，你的主工作区完全不受影响。

实验成功了？合并进来。实验失败了？直接删除 worktree，就像什么都没发生过。

---

为什么要做这个？

你可能会问，Git 本来就有 worktree 功能，为什么要专门在 Qwen Code 里封装一层？

这里涉及一个关键的设计决策。

问题一：AI 助手的「沙盒」需求

当 AI 助手帮你写代码时，它可能会创建、修改、删除很多文件。如果这些操作直接在你的主工作区进行，一旦方向错了，清理起来很麻烦。

以前 Qwen Code 只有 Arena 内部的 worktree 支持，用户无法主动使用。这个新特性把 worktree 能力开放给了普通用户。

问题二：并行实验的可能性

想象一下这个场景：你想让 AI 尝试三种不同的方案来解决同一个问题。

传统方式是你得串行执行：等方案 A 做完，回退，再做方案 B。有了 worktree，你可以让三个 agent 同时在不同的 worktree 里工作，最后对比结果。

问题三：脏状态保护

新特性里有一个很有意思的设计：exit_worktree 时会检查是否有未提交的改动。如果有，它会拒绝删除这个 worktree，防止你意外丢失工作成果。

这不是一个简单的功能封装，而是一个完整的安全机制。

---

语言游戏考察

让我们停下来思考一下这里的语言使用。

当我们说「隔离」时，我们在说什么？

1. 文件系统层面的隔离：不同的目录，不同的文件副本
2. Git 层面的隔离：不同的分支，独立的提交历史
3. 语义层面的隔离：不同的实验上下文，互不干扰的思维空间

这三种「隔离」不是同一件事，但它们之间有家族相似。

Qwen Code 的 worktree 支持同时实现了这三层隔离。但这还不够，因为还有一个更深的问题…

「工作区」的语法

在日常语言中，「工作区」意味着你正在工作的地方。但在编程语境下，「工作区」有更复杂的含义：

• 它是代码的物理存储位置
• 它是 Git 追踪的上下文
• 它是你的思维投射到文件系统的映射

当我们让 AI 在一个「隔离的工作区」里工作时，我们实际上是在划定一个语言游戏的边界。在这个边界内，AI 可以自由地修改、删除、创建，而不必担心跨越边界影响到其他游戏。

注意这里的用法：「不必担心」。这不是技术能力的描述，而是心理状态的描述。

worktree 的真正价值，不在于它提供了什么功能，而在于它消除了什么焦虑。

---

核心功能详解

enter_worktree：进入平行宇宙

调用这个工具时，你可以指定一个名称。如果不指定，系统会自动生成一个类似 agent-a1b2c3d 的名字。

工具会返回 worktree 的绝对路径。后续的.file 操作需要使用这个路径。

这里有一个设计细节需要注意：这个新特性没有机械地切换 Config.targetDir，而是让模型自己管理路径。这样做避免了侵入式的配置重构，但也意味着模型需要更小心地处理路径。

exit_worktree：退出与清理

退出时有两种选择：

• action: 'keep'：保留 worktree，方便后续继续工作
• action: 'remove'：删除 worktree 和相关分支

如果选择 remove，系统会先检查是否有未提交的改动。如果有，它会拒绝删除并给出提示：

这个设计体现了「fail closed」的原则：在不确定时，选择更安全的选项。

agent 工具的 isolation 参数

这是最强大的功能。你可以在调用 agent 时指定 isolation: 'worktree'，这样 agent 会在一个临时的 worktree 里执行所有操作。

用户：帮我重构这个模块，试试用策略模式

AI：[调用 agent, isolation: "worktree", prompt: "..."]

系统在后台：
1. 创建临时 worktree (agent-x7y8z9w)
2. 在其中执行重构
3. 如果有改动且成功，保留 worktree
4. 如果没有改动或失败，自动清理

完成后，如果 worktree 里有改动，系统会保留它并在结果中标注：

[worktree preserved: agent-bad55bd (branch worktree-agent-bad55bd)]

如果没有改动，系统会自动清理，不留痕迹。

---

实际使用场景

我用这个功能测试了几个场景，效果出乎意料的好。

场景一：安全的代码实验

用户：帮我把这个函数改成异步的，看看会不会有问题

AI：[调用 agent, isolation: "worktree"]
     在 agent-a1b2c3d worktree 中执行改造
     运行测试...
     
结果：[worktree preserved: agent-a1b2c3d]
      测试通过，worktree 已保留供你审查

我可以切换到那个 worktree 查看改动，如果满意就合并，不满意就删除。主工作区完全不受影响。

场景二：并行方案对比

用户：我想试试三种不同的缓存方案，帮我分别实现

AI：[调用 agent, isolation: "worktree", name: "redis-cache"]
    [调用 agent, isolation: "worktree", name: "memcached"]
    [调用 agent, isolation: "worktree", name: "in-memory"]

结果：三个 worktree 都保留了，你可以对比它们的实现

这在以前是不可能的。现在我可以同时看到三种方案的代码，直观地比较它们的优劣。

场景三：干净的失败

用户：帮我优化这个算法，让它更快

AI：[调用 agent, isolation: "worktree"]
     尝试优化...
     基准测试显示没有提升
     
结果：[worktree auto-cleaned]
      没有实质性改动，worktree 已自动清理

失败的实验不会留下任何痕迹。我的项目目录保持干净，没有一堆废弃的实验分支。

---

让我们回到最初的问题：worktree 解决了什么？

它可以回答这些问题：

• 如何让 AI 助手安全地实验代码？
• 如何在不污染主工作区的前提下探索多个方案？
• 如何自动化地清理失败的实验？

但它不能回答这些问题：

• 如何隔离运行时状态？
• 如何隔离数据库连接？
• 如何隔离外部 API 调用？

这些问题的答案不在 worktree 的能力范围内。

我们可以说 worktree 是文件系统层面的隔离机制。我们不能说它是「完整的沙盒」，因为「沙盒」这个词暗示了更多东西——进程隔离、网络隔离、资源隔离。

当人们说「这个 AI 工具很安全，它有沙盒」时，他们可能在想不同的事情。有些人想的是文件系统隔离，有些人想的是容器化，有些人想的是虚拟机。

这些用法之间有家族相似，但不是同一件事。

混淆产生于我们把它们当作同一件事。

---

写在最后

我用 Qwen Code 的 worktree 功能一周，最大的感受是：它改变了我与 AI 协作的心理模式。

以前让 AI 改代码时，我总有一种隐隐的焦虑——万一它把我的项目搞乱了怎么办？虽然现在有版本控制可以回退，但回退本身也是一种成本。

有了 worktree，这种焦虑消失了。

我知道 AI 在一个隔离的环境里工作，它的改动不会影响我的主工作区。如果实验成功，我可以合并；如果失败，我可以直接删除，就像什么都没发生过。

这种心理安全感，比技术本身更有价值。

1. 工具的价值不在于功能数量，而在于它消除了什么障碍。
2. worktree 消除的障碍是「实验的恐惧」。
3. 当恐惧消失，创造力才会真正释放。
4. 然而，恐惧的根源不只是技术风险，还有对未知的不确定性。
5. 对于不确定性…

…

也许再过几个月，worktree 会成为 AI 编程助手的标配功能。

也许不会。

但至少现在，它给了我一个理由，更大胆地去实验、去探索、去犯错。

因为在平行宇宙里，错误从来都不是终点。

它们只是另一个可能性的起点。