TraeWork 的 Worktree：多任务并行时它到底隔离了什么
一、真正卡住你的不是模型，是那一个工作目录
先说一个很多人都遇到过的场景。手头有个项目，早上开了一个任务让智能体做新功能，写到一半，线上冒出一个紧急问题需要立刻改。这时候你有两个选择：要么把新功能的改动先 stash 掉、切分支去修问题、修完再切回来接着写；要么另开一份代码副本。前者的麻烦在于智能体正在这个目录里干活，你在它脚底下切分支，它接下来读到的文件已经不是它以为的那份了；后者的麻烦是副本要重新装依赖、重新配环境。
Git 本身早就有针对这件事的机制。TraeWork 官方文档《工作树》里给 Worktree 下的定义是：「Git 的一项原生机制，允许单个代码仓库同时拥有多个独立的工作目录，每个目录可以检出不同的分支。」也就是说这不是 TraeWork 发明的概念，它是把 Git 已有的能力接到了任务这一层——每个任务一个目录，各自检出各自的分支。
文档对这个功能的定位写得很直白：当你需要在同一个项目中并行处理多个任务、并希望避免代码冲突时使用；它会为每个任务创建一个独立的目录，其中包含专属的文件、依赖项和代码变更，从而确保主工作目录保持整洁且不受干扰。这里值得留意的是「依赖项」三个字——文档把依赖列进了这个独立目录的内容，但依赖是怎么进到这个目录里的（复制、重装，还是别的方式），官方文档没有说明这一点。
二、官方文档写明的用法：在哪儿开、怎么合、怎么清
前置条件与适用范围。 文档单独列了两条，都很短但都是硬的：适用范围是「此功能仅适用于在本地环境中运行的任务」；前置条件是「确保你已在本地安装 Git」。第一条尤其要记住——TraeWork 的文档目录里另有「云端运行环境」一节，而 Worktree 这一节明确把自己限定在本地运行的任务上。
创建。 文档写的是：发起任务前，在对话输入框左下角，将模式设置为「工作树」。任务启动后，智能体会为这个任务自动创建一个专属的工作树分支和对应的工作树目录。注意「发起任务前」这个时间点，模式是任务启动之前定的，不是中途挂上去的。
工作树目录和分支的关系，文档说得很明确：在 TraeWork 中，工作树目录的名称与对应的工作树分支名称一致，格式为 /{worktree_branch_name}。文档给出的分支名示例是 feat-pet-shop-1sfbnt，至于这个名字是怎么生成的、语义部分从哪儿来、后缀按什么规则拼，官方文档没有说明这一点。但「目录名与分支名一致」这条关系是文档明写的，它对你有实际意义：拿到一个目录名就等于拿到了分支名，两边能直接对上，不需要再去猜哪个目录属于哪条分支。
合并。 文档给了两条路径，都从对话框顶部的工作树分支栏进入：
| 方式 | 文档写明的动作 | 冲突怎么处理 |
|---|---|---|
| AI 自动合并 | 在工作树分支栏点击「AI 合并」 | 文档写明 AI 将自动分析代码变更、解决冲突并完成合并 |
| 手动合并 | 在工作树分支栏点击「···」并选择「手动合并」，随后按产品内的指引继续 | 文档写明若出现冲突，需先点击「AI 解决冲突」解决，再继续该流程 |
合并完成后，文档写明对话流底部会出现一条带有「代码已合并」文案的分割线，并且特意提醒了一句：由分割线上方的对话所产生的内容无法回退。这是整节里唯一一处明确写「无法回退」的地方，值得单独记一笔。
磁盘占用与清理。 查看路径是「设置 > 工作树」，在「工作树磁盘占用」区域可以看到所有项目下各个工作树占用的空间。清理的语义文档也交代了：清理工作树会把它对应的本地目录彻底清除以释放磁盘空间，但该任务的对话历史和代码变更记录会被保留；此外你可以选择是否保留这个工作树的 Git 分支。
清理入口文档列了三个：一是在左侧任务栏把鼠标悬停在目标任务上，选择出现的「···」里的「删除工作树」；二是在「设置 > 工作树」的「工作树磁盘占用」区域选中目标后点右下角「清理」；三是在对话框顶部的工作树分支栏点「···」选「删除工作树」，文档补了一句：若代码合并已完成，分支栏将直接显示「删除工作树」按钮。三条路径最后都会弹出同一个确认框，框里有一个「保留工作树分支」的勾选项。
关于这个勾选项，文档还给了一条后路：清理时如果选择保留 Git 分支，系统将只删除本地的工作树目录，分支本身保留；之后你仍然可以去「设置 > 工作树」的「工作树磁盘占用」区域找到并彻底清理该分支。
两个可调的设置项。 在「设置 > 工作树」的「工作树清理」区域，文档列了两条：
- 清理工作树时默认保留分支：启用后，删除工作树时确认弹窗里的「保留工作树分支」会默认勾上。
- 工作树磁盘空间占用提醒：设置一个磁盘空间占用阈值，当所有工作树目录占用的总空间达到该阈值时，系统发出通知提醒你清理。
这两条是本篇最值得你自己去官方文档里对一眼的地方——文档给的路径就是「设置 > 工作树 > 工作树清理」。另外注意第二条的措辞：阈值统计的口径是「所有工作树目录占用的总空间」，不是单个工作树，也不是单个项目。
三、边界：文档写到哪儿为止
这一节是本篇的重点，因为上面那些步骤照着做就是了，真正会咬人的是文档没覆盖的部分。
只管本地任务。 「仅适用于在本地环境中运行的任务」这句话是文档原文。至于跑在云端运行环境里的任务用什么方式做隔离、是否有等价机制，工作树这一节没有说明。
前置条件只列了 Git。 文档明写的前置条件只有一条：本地已安装 Git。项目本身必须已经是一个 Git 仓库、需要什么版本的 Git、非 Git 管理的目录会怎样——官方文档没有说明这些。
模式的切换时机。 文档只写了「发起任务前」把模式设为工作树。任务已经跑起来之后能不能切换成工作树模式、或者从工作树模式切回去，文档里我们没有找到对应说明。
AI 合并的口径。 文档对「AI 合并」的描述是「自动分析代码变更、解决冲突并完成合并」，对「AI 解决冲突」的描述是一个按钮加一次点击。它按什么规则判定该保留哪一侧、合并前会不会让你确认、失败或解不开时会怎样、能不能撤销——这些文档都没有说明。这不是小事：自动解冲突意味着有人替你做了取舍，而这一节同时写着「分割线上方的对话所产生的内容无法回退」。把这两句放在一起看，合并这一步在文档口径下是需要你自己先把变更看一遍的，文档并没有给出「合并后可回退」的承诺。
清理保留的到底是什么。 文档的措辞是：本地目录被「彻底清除」，而「该任务的对话历史和代码变更记录将被保留」。请注意保留的是「记录」，被删的是目录。目录里那些尚未合并、甚至尚未提交的改动，在清理之后还能不能恢复成文件，官方文档没有说明这一点。如果你选了不保留分支，那么这个工作树的分支也一并没了。所以清理这个动作在文档口径下更接近「腾空间」，不要当成归档。
阈值提醒只是提醒。 「工作树磁盘空间占用提醒」文档写明的行为是达到阈值时「发出通知」，没有写会自动清理任何东西。阈值的可选范围、默认值是多少，文档同样没有说明——所以别指望它替你兜底。
数量与并发。 一个项目最多能同时存在多少个工作树、多个工作树里的任务能不能真的同时跑，文档里我们没有找到对应说明。
计费口径。 工作树这一节没有提到任何积分或费用相关的内容。TraeWork 的文档站顶部挂着一条「以积分为核心的计费模式正式上线」的更新提示，具体口径以官方最新公告和定价页为准，本文不做任何换算。
顺带提一句现实：TraeWork 是仍在迭代中的产品，文档站顶部当前挂着那条计费模式上线的更新提示。上面这些菜单名、按钮名和设置项都是我们从当前公开文档里逐条摘的，该产品仍在迭代、功能与计费口径可能变动，一切以官方最新文档与公告为准。
四、什么时候值得开，什么时候不用
值得开的情况，基本都符合「同一个仓库、两条互不相干的改动线」这个形状：
- 一个长任务在做功能，中途需要插一个紧急修复，而你不想在智能体干活的目录里切分支。
- 你想同时让智能体尝试两种实现思路，做完再挑一条合并——两条思路各自一个目录一个分支，互不覆盖。
- 你希望主工作目录始终保持在可运行、可演示的状态。文档对这个功能的定位原话就是「确保你的主工作目录保持整洁且不受干扰」。
不必开的情况同样清楚：
- 任务跑在云端运行环境里。这一节明确只覆盖本地任务。
- 你一次只做一件事，且改动很小。开工作树的代价是多一份目录、多一份磁盘占用，还多一步合并；单线任务里这些都是纯开销。
- 磁盘本来就紧张，又不打算及时清理。文档写明工作树目录是独立目录、包含专属的文件与依赖项，所以它会占本地空间；至于一个工作树大概占多少，官方文档没有说明这一点，需要你自己去「设置 > 工作树」的占用列表里看。
- 你所在的团队对合并有强制流程（比如必须走代码评审）。这种情况下「AI 合并」这条路径能不能用、怎么和现有流程接上，文档没有讲，需要你自己先确认清楚。
最后一句实在话：Worktree 这个功能的价值不在于它「很智能」，而在于它把「一个任务一个目录一条分支」这件事变成了发起任务时的一次模式选择。真正需要你花心思的只有两处——合并前把变更看一遍（因为分割线上方无法回退），以及定期去「设置 > 工作树」清一清（因为提醒只是提醒）。
本文依据 TraeWork 官方文档（docs.trae.cn）于 2026-08-17 的公开内容整理。
我们没有开通付费账号，也没有实际操作过该产品，因此不涉及界面外观、操作手感与生成质量的任何描述。
该产品仍在快速迭代，功能与计费口径随版本变动，文中涉及积分与套餐的表述均为复述官方文档原文，
请以官方最新公告与定价页为准。