2026 DeepSeek Harness 并行改代码：Git worktree 还是独立克隆？

这篇文章适合同时让多个 Agent 修改同一仓库的独立开发者、负责远程 Mac 执行池的平台工程师，以及运行大型构建或客户项目的研发团队。

如果任务只做只读分析，或者所有修改都会严格串行执行，直接复制整个仓库可能增加不必要的维护工作；如果项目之间存在不同凭据、客户数据或权限边界，目录隔离也不能替代安全隔离。

本文将“代码工作区隔离”“进程与构建资源隔离”“身份与数据安全边界”分开讨论，避免把 Git worktree 误当成沙箱。

多个 DeepSeek Harness 会话可以共用一个仓库吗？
可以，但不能让多个会话共用同一个实际工作目录。每个会话都应绑定明确的工作区路径、分支名称和任务责任人；否则，Agent 的 checkout、文件修改、测试修复和构建清理可能互相影响。

DeepSeek Harness 的官方基准说明把独立任务与不同工作区、会话标识绑定在一起。这里的“独立”首先是执行上下文和工作目录的独立，并不代表底层文件系统、Git 对象、依赖缓存或操作系统进程已经自动隔离。具体要求应以 DeepSeek Harness 官方 BENCHMARK 文档 与 官方仓库说明 为准。

Git 官方文档说明，一个仓库可以拥有一个主工作树和多个关联 worktree；关联 worktree 会共享仓库中的一部分内容，但 HEAD、索引等工作区级数据可以分别维护。也就是说，worktree 解决的是“同一仓库同时检出多个分支”的问题，不是完整虚拟机或安全沙箱。可参考 Git worktree 官方手册。(git-scm.com)

选择时不要只问“哪个更省磁盘”，而应先问任务是否共享同一个信任边界。一个临时重构任务通常只需要工作区隔离；一个需要不同依赖和独立密钥的客户任务，则已经超出了 worktree 的职责范围。

对于个人开发者，同时运行两个相互独立的短期编码任务时，Git worktree 往往是更直接的选择。它可以让一个工作区继续进行大范围重构，另一个工作区处理紧急修复，而不必在同一目录中频繁执行 stash、切分支和恢复现场。

一个可靠的绑定关系应至少包含以下字段：

• 会话 ID：标记 DeepSeek Harness 的具体任务；
• 工作区路径：例如 /path/to/worktree-task-a；
• 分支名称：例如 agent/task-a；
• 目标分支：例如 main 或 release；
• 任务类型：代码修改、只读分析、测试修复或构建验证；
• 合并责任：明确由谁审查、谁合并、谁处理冲突。

并行 Agent 修改同一项目时，怎样降低分支冲突？
关键不是把目录名称改得更复杂，而是让每个 Agent 从一开始就拥有独立分支，并禁止两个任务同时修改同一组高频文件。即使两个 worktree 的目录完全不同，如果它们都持续修改同一个路由文件、数据库迁移文件或锁文件，最终仍然会在合并阶段产生冲突。

Git 官方语法可以使用类似下面的方式创建工作区，路径统一替换为实际目录：

git worktree add -b agent/task-a /path/to/worktree-task-a origin/main
git worktree add -b agent/task-b /path/to/worktree-task-b origin/main
git worktree list --porcelain

这里的 -b 用于创建并检出新分支，list --porcelain 更适合平台脚本读取。不要让两个会话共享同一个分支，也不要把“目录不同”当成任务所有权已经定义完成。(git-scm.com)

Git worktree 仍有几个容易被忽略的共享对象：

1. 仓库级配置可能共享。 Git 官方文档说明，默认情况下仓库配置文件由多个 worktree 共享；如果某些配置必须按工作区区分，需要评估 extensions.worktreeConfig 与 config.worktree 的使用方式。
2. 外部构建目录不会自动隔离。 如果构建工具把派生数据写到仓库外的固定目录，多个任务仍可能互相覆盖。
3. 后台进程不会随目录自动消失。 开发服务器、测试监听器、模拟器和文件监控进程可能继续占用端口或锁定文件。
4. 子模块存在额外边界。 Git 官方手册明确提示，多工作树与超级项目、子模块组合时支持并不完整，不能把普通项目的经验直接套到复杂子模块仓库上。(git-scm.com)

因此，Git worktree 适合短期、同依赖、同信任边界的任务；不适合作为长期运行的多个独立开发环境。

团队协作时，目录隔离只能避免一部分文件覆盖，不能替代评审责任。任务创建时应把以下内容写进任务契约，而不是等 Agent 结束后再追问：

• 允许修改哪些目录；
• 目标分支是什么；
• 是否允许提交；
• 是否只能生成补丁；
• 测试命令和构建命令是什么；
• 失败时由谁接管；
• 变更最终合并到哪个分支。

不同任务类型对工作区独占程度也不同：

• 代码修改任务： 必须独占工作区，并绑定独立分支；
• 只读分析任务： 可以使用只读克隆或只读 worktree，但仍应避免与正在构建的目录共用派生数据；
• 测试修复任务： 如果会修改测试、快照或基准文件，应使用独立分支；
• 构建验证任务： 即使不改代码，也应隔离构建产物、临时目录和端口；
• 审查任务： 可以读取其他分支的提交，但不应直接在被审查工作区中写入修复。

当两个任务出现同文件高频修改、交叉依赖尚未合并、数据库迁移顺序相互依赖，或者一个任务会重写另一个任务正在生成的接口时，应立即改为串行执行。继续增加 worktree 数量并不能消除逻辑冲突，只会把冲突推迟到合并或测试阶段。

不同工作区能否安全使用同一份依赖下载缓存？
只有在缓存内容是可验证的只读下载缓存、工具本身支持并发访问，并且缓存命中不会把一个任务的构建状态写回另一个任务时，才可以考虑共享。包管理器下载缓存、编译器工具链缓存和容器基础层，通常比构建输出目录更适合共享；但“通常适合”不等于“所有工具都安全”。

以下目录不应因为使用了 worktree 就默认共享：

• build、dist、DerivedData 等构建产物；
• 测试快照、生成代码和覆盖率报告；
• 数据库文件、临时上传目录和本地队列；
• 运行时 socket、PID 文件和日志文件；
• 需要写入凭据、令牌或环境配置的目录。

更稳妥的做法是为每个任务生成任务级路径：

export TASK_ID="task-a"
export BUILD_DIR="/path/to/build/${TASK_ID}"
export TMPDIR="/path/to/tmp/${TASK_ID}"
export PORT="由平台分配的独立端口"

实际端口和路径应由远程 Mac 调度器注入，不能让多个会话默认争用同一个开发服务器端口。依赖缓存可以放在共享位置，但构建产物、临时文件和运行状态应绑定到任务 ID。

如果项目需要不同版本的 Node、Python、Swift 工具链，或者依赖安装过程会修改项目目录中的锁文件，独立克隆通常比 worktree 更容易审计。若还涉及不同 API 密钥、客户数据或私有仓库访问权限，应进一步升级到独立 macOS 账户或独立 Mac。

DeepSeek Harness 未被官方确认会自动创建、绑定和回收 Git worktree，因此平台团队应把这些动作设计成外部编排流程，而不是假设 Harness 会替平台完成。

建议按下面的顺序实施：

1. 创建任务记录。 生成任务 ID，记录项目、提交基线、目标分支、会话 ID、操作者和过期条件。
2. 创建工作区。 使用 git worktree add 或 git clone 创建目录，禁止直接复制一个正在运行的目录作为“快速工作区”。
3. 写入环境映射。 将工作区路径、分支、构建目录、临时目录、端口和凭据引用绑定到同一个任务记录。
4. 启动会话。 启动 DeepSeek Harness 前，先检查当前路径、当前分支和 Git 状态，并把结果写入审计日志。
5. 执行基准任务。 至少验证一次并行修改、一次构建、一次取消和一次清理，确认任务不会写入其他工作区。
6. 结束会话。 先停止后台进程，再记录提交、未提交文件、生成产物和测试结果。
7. 安全回收。 对干净 worktree 使用 git worktree remove /path/to/worktree，然后用 git worktree list --porcelain 检查残留状态。
8. 处理异常。 只有在确认未提交内容已被保存、转交或明确丢弃后，才允许人工使用强制移除。

Git 官方文档明确指出，直接删除工作区目录后，关联的管理信息不会立即等同于完整清理；可以使用 git worktree prune 清理失效记录，但下次应优先使用 git worktree remove。如果工作区被移动，应使用 git worktree repair 修复关联关系，而不是手动猜测 .git 文件应该指向哪里。(git-scm.com)

回收失败时，平台不应直接强制删除。应至少保留以下证据：

• 当前提交和分支；
• git status --short 输出；
• 未提交文件清单；
• 后台进程和端口占用信息；
• 构建日志与测试结果；
• 最后一次会话事件记录。

只要仍有未提交产物、客户数据、失败测试日志或未确认的后台进程，就应进入人工接管，而不是自动重试删除。

worktree 能解决版本控制工作区冲突，却不能解决用户身份、凭据和数据信任问题。多个 worktree 仍然可能运行在同一个 macOS 用户账户下，读取同一个钥匙串、环境变量、SSH 配置、云端凭据或共享缓存。

以下情况不应只使用 worktree：

• 两个项目属于不同客户；
• Agent 使用的 API 密钥权限不同；
• 一个任务可以访问生产数据，另一个任务只能访问测试数据；
• 仓库本身包含不同保密等级的代码；
• 任务需要独立的 SSH 身份、签名密钥或私有包源；
• 团队需要在任务结束后明确撤销全部访问权限。

独立克隆可以进一步分开 Git 元数据、仓库级配置和依赖安装状态，但它仍然不等于独立安全环境。如果同一个账户继续共享凭据和文件访问权限，独立克隆只能减少工程干扰，不能形成完整的安全边界。

在远程 Mac 上，较清晰的升级路径是：

• 同客户、同权限、短期任务：一个仓库加多个 worktree；
• 同客户、依赖和构建状态明显不同：独立克隆；
• 不同客户、不同权限或不同密钥：独立 macOS 账户；
• 需要强制数据隔离、独立审计和独立回收：独立 Mac 环境。

如果平台正在规划远程执行池，可以先参考 NUKCLOUD 的远程 Mac 入口，再根据并发任务的持续时间、构建产物大小和凭据隔离要求选择具体交付方式，而不是先按目录数量采购资源。

不要只测试“两个 Agent 能否同时启动”，因为最容易暴露问题的往往是取消、构建和回收阶段。建议使用同一仓库、同一提交基线，依次验证以下任务：

• 并行修改： 两个分支修改不同文件，确认提交和状态互不影响；
• 同文件冲突： 两个分支修改同一文件，确认平台能识别并转为人工合并；
• 并行构建： 两个任务同时生成产物，确认输出目录、日志和临时目录不覆盖；
• 取消任务： 中途停止一个会话，确认后台进程、端口和临时文件都能被发现；
• 安全回收： 分别测试干净工作区、存在未跟踪文件和存在未提交修改的工作区；
• 凭据检查： 确认任务结束后，环境变量、SSH 身份和临时令牌不会被下一任务复用。

可以使用下面的验收清单，作为平台上线前的最低门槛：

• [ ] 每个 DeepSeek Harness 会话都有唯一工作区路径；
• [ ] 每个代码修改任务都有独立分支；
• [ ] 任务记录写明目标分支和合并责任人；
• [ ] 构建目录、临时目录和端口按任务 ID 分配；
• [ ] 共享缓存经过工具文档或实际环境验证；
• [ ] 取消任务后，后台进程和端口能够被列出；
• [ ] 回收前会检查未提交文件和未跟踪文件；
• [ ] 直接删除目录后，会执行 git worktree list 与必要的 prune；
• [ ] 不同权限级别的项目没有共用同一个账户；
• [ ] 回收失败时会保留证据并转人工处理。

Git worktree 的优势是创建路径清晰、分支切换方便，并且适合同一仓库的短期并行修改；它的弱点是共享仓库对象、默认共享部分配置，而且不会自动隔离依赖、端口、构建产物和凭据。

独立克隆的隔离范围更大，适合长期运行、依赖版本不同或构建状态复杂的任务，但需要额外管理仓库更新、磁盘占用、凭据注入和回收记录。独立环境则是处理信任边界的方案，不应仅因为“同时运行多个 Agent”就无条件采用。

与直接在一台 Mac 上反复切分支、共用构建目录和后台进程相比，当前方案容易出现任务状态不可追踪、缓存互相污染、取消后资源残留以及客户凭据难以撤销等问题。若现有 Mac 无法稳定提供独立工作区，或者任务会长期占用构建资源，使用 NUKCLOUD 租赁远程 Mac，通常更适合先交付一个可回收、可审计的并行执行环境；长期稳定重负载、必须连接本地物理设备的项目，则仍应评估自购 Mac 或专用环境。

更稳妥的落地方式，是先用两个可丢弃分支完成一次并行修改、构建、取消和回收测试。若测试暴露出资源隔离或持续运行问题，再阅读 NUKCLOUD 的远程 Mac 方案页面，按任务边界决定采用多个 worktree、独立克隆，还是直接拆分为独立 Mac 环境。