DeepSeek Harness 工作树：从创建到验收

让智能体尝试修改代码时，独立的工作目录可以避免打乱你正在编辑的文件。DeepSeek Harness 在 2026 年 10 月 9 日发布的 dsh-v0.2.1-alpha.2 中加入了实验性的 Git Worktrees 插件：创建新分支和工作目录后，调用它的会话会切换到新目录继续工作。

本文依据固定版本的插件指南，安排一个小型验收练习：创建工作树，修改一处文档，检查结果，再返回原目录。这是基于官方文档设计的操作流程，不代表我们已经实测 Harness 桌面版。文中的工具调用示例用于说明智能体如何调用工具，不能直接粘贴到 shell 中执行。

启用插件前，先检查仓库

建议使用临时仓库，或选择一个你清楚当前改动状态的项目。工作树运行时文档要求文件系统所在的执行环境具备 Git 2.45 或更新版本，以及 Node。如果使用远程环境，只检查笔记本上的版本并不够。

先让智能体报告仓库根目录、当前分支、当前提交和简短的 Git 状态。对应的只读 shell 命令如下：

git --version
node --version
git rev-parse --show-toplevel
git branch --show-current
git rev-parse HEAD
git status --short

分支名为空可能表示当前处于 detached HEAD 状态，应如实记录。状态输出非空也不一定是错误，而是说明提交之外还有改动。先判断新任务是否依赖这些改动；如果依赖，就先准备合适的提交，不要指望工作树自动复制过去。

插件不会复制已暂存、未暂存、未跟踪或被忽略的文件。因此，即使原目录可以正常运行，新工作树也可能缺少依赖、本地环境文件或生成产物。

原创示意图：01 是原工作目录，02 是新分支的工作目录。已提交的 README 内容可用，带星号的未提交笔记不会复制。

这张图说明文档规定的复制范围，并非应用截图。两个工作目录共享 Git 管理数据，文件分开并不意味着提交历史彼此独立。

在界面中打开 Plugins → Official → Git Worktrees，开启开关。固定版本的插件指南说明，这个可选插件包在所有随版本提供的配置方案中默认关闭，启用后会同时加载工作树运行时和创建工具。

第一次可以这样提出要求：为一处文档修正创建工作树，展示新目录和起始提交，先等待检查，不要立即编辑。选择尚未使用的分支名，例如 docs-worktree-trial。该名称也会用于相对工作目录，简短且有含义的命名便于后续查找。

创建调用如下：

create_worktree({ name: "docs-worktree-trial", from: "HEAD" })

from 必须能在本地解析。即使托管网站上存在某个远程分支，只要本地仓库缺少对应对象，仍无法以它为起点创建工作树。这个操作不会拉取缺失对象、初始化子模块或安装依赖；重试之前，应先处理真正缺少的前提条件。

调用成功后会返回 path、branch、baseCommit 和 repositoryRoot，请将四项一起记录。子系统文档说明，只有 Git 设置成功后，会话才会切换工作目录。

默认路径位于当前检出目录下的 .agents/worktrees/<name>。如果会话原本就在关联工作树中，新工作树的存放目录也会建在其中。以工具返回的规范化绝对路径为准，不要套用另一会话里记下的路径。

让智能体在当前目录再次检查根目录、分支和提交，并与创建结果对照。一般情况下，文件应符合预期的起始版本。不过文档提醒，仓库本地的替换引用可能影响检出内容，因此还应打开准备修改的文件，不能只看提交标识符。

选择已有 README 的一段文字，只要求补充一项事实说明。首次练习不要从依赖升级或全仓库格式化开始，大量差异会让目录错误更难被发现。

编辑完成后检查当前分支和改动：

git branch --show-current
git status --short
git diff --check
git diff -- README.md

如果修改的是其他文件，请替换为实际文件名。最后一条命令显示未暂存的变化；若智能体已暂存改动，还要检查暂存区差异。git diff --check 没有报错，只能说明未发现它检查的空白字符问题，不能证明文案正确或项目可以构建。

按改动范围执行必要的项目检查，并记录命令、目录和结果。如果只是修改文档，查看渲染后的文字往往比运行无关的测试套件更有帮助。

原创流程图：01 创建，02 核对四个返回字段，03 编辑，04 检查差异，05 返回。退出后目录和分支仍保留。

图中的编号依次表示创建、核对、编辑、检查、退出。保留下来的分支和目录，仍需在之后决定如何合入或清理。

返回时，让智能体调用 working_directory，传入原检出目录的绝对路径。例如，将下面的示例路径替换为之前记录的 repositoryRoot：

working_directory({ cd: "/absolute/path/to/original-checkout" })

再次核对当前目录。退出不会合并改动，也不会删除工作目录或分支。关闭 Git Worktrees 插件同样会保留已创建的工作树，而内置的工作目录工具仍可使用。

先审查差异，再决定如何合入。按项目现有流程提交后，可以选择合并或 cherry-pick。不再需要工作树时，先检查其状态并保存改动，再使用 Git 的常规工作树移除流程。不要一遇到未提交文件，就直接强制删除。

分支名或目标路径已经存在，会导致创建失败。换名字重试前，先检查已有什么，尤其是在取消操作之后：失败过程可能留下部分文件或 Git 记录，错误会提示位置。不断生成新名字，反而容易分不清哪一个目录里存着要保留的改动。

权限错误则要另行处理。已有沙箱策略需要允许写入目标目录和共享的 Git 元数据；插件不会自动扩大权限。先确定被拒绝的是哪个位置，再考虑是否需要调整配置。

此外，检出时会跳过已配置的 clean、smudge 和 process 过滤器，因此 Git LFS 指针或加密数据可能保持仓库中的存储形式。下载真实文件或解密应作为独立操作处理。工作树创建成功，并不意味着运行项目所需的环境已经齐备。

将工具返回的四项信息、审查过的差异和检查结果保存在一起，下次继续时就无需猜测智能体用过哪个目录、从哪个提交开始。关于本次发布的其他变化及 SDK 迁移，可阅读 alpha.2 升级指南。