复杂任务常常会出现一个诱人的想法：既然有两种都说得通的方案，不如都试一遍。但“另开一条路线”可能指完全不同的事情：复制当前对话，从同一个提交创建另一条开发历史，或者干脆准备一个互不干扰的工作目录。

Codex 的派生、Git 分支和 Git worktree 都带有“从这里分开”的意味，却分别作用于任务上下文、提交历史和文件现场。混用这些概念，轻则让人找不到改动究竟落在哪里，重则会让两个任务同时修改同一个目录，以为已经隔离，实际上只是各自聊得很投入。

Codex Fork 分的是任务路线，Git branch 分的是提交历史，Git worktree 分的是文件现场。

先问：究竟想把什么分开

判断该用哪一种工具之前，可以先把“分叉”拆成三个问题：

工具被分开的对象它不会自动提供什么最适合的需求
Codex Fork对话历史、任务上下文与后续路线新分支、新目录、文件隔离从当前理解出发，继续探索另一种思路
Git branch提交历史中的可移动引用第二个工作目录、并行文件现场保存一条准备提交、审查和合并的开发路线
Git worktree工作目录、HEAD 与 index方案判断、对话分叉、自动进入主线同时检出多个现场，让任务互不改写对方的文件

它们不是三选一的竞品，而是三个可以叠加的层次。一次探索可以先派生任务，值得落地的路线再进入独立 worktree，最终通过 branch、commit 和 PR 留下可审查的工程历史。

Codex Fork：复制的是任务路线

按照 OpenAI 当前的 Codex Developer Commands 文档，/fork 会把当前本地任务复制为一个新的本地任务。新任务继承此前的对话背景，却拥有独立的后续记录，因此适合从同一个分析点继续尝试不同方向：

/fork

例如，一个故障既可能通过最小修复解决，也可能暴露出更深的模块边界问题。主任务可以保留已经确认的事实，派生任务则专门推演重构路线。两边不必反复撤销彼此的结论，也不会把“先按 A 做”和“还是改成 B”挤进同一条对话时间线。

但 Fork 只解决上下文分流。新任务仍可能指向同一个本地项目目录；如果两边都开始写文件，它们看到和修改的可能仍是同一份工作树。

派生对话不会为文件自动建立隔离层。它让两条路线分别思考，却不保证两条路线能够安全地同时施工。

因此，只比较设计、审阅方案或继续追问时，Fork 已经足够；一旦两条路线都要修改代码，就需要进一步处理文件现场。

Git branch：保存的是一条历史

Git 分支本质上是指向某个提交的可移动引用。创建并切换分支后，新的 commit 会沿着这条引用继续向前：

git switch -c feature/minimal-fix

它回答的是“这组提交属于哪条开发路线”。分支可以推送到远端、创建 PR、接受 CI 和 review，最后决定是否合并到主线。相比对话中的尝试，它把结果变成可比较、可回退、可追踪的工程记录。

不过，在同一个工作目录里切换分支，文件现场也会随之切换。你可以先做方案 A，再切到方案 B，却不能指望一个目录同时稳定承载两边的依赖、构建产物和未提交修改。

分支负责结果属于哪条历史，不负责你在哪里工作。

这也是 branch 与 worktree 最容易混淆的地方：branch 是历史引用，worktree 才是让那条历史出现在某个具体目录中的检出现场。

Git worktree：隔离的是文件现场

Git 官方将 worktree 定义为同一仓库关联的多个工作树。一个仓库可以有主 worktree，也可以有多个 linked worktree；每个目录拥有自己的文件、HEAD 和 index，同时共享对象数据库、refs 等仓库元数据。

用命令行创建一条独立现场，可以写成：

git worktree add ../project-refactor -b feature/refactor main

这会从 main 建立 feature/refactor 分支，并把它检出到相邻目录。原目录可以继续做当前工作，新目录则能够独立安装依赖、修改文件和运行测试。

worktree 不是另一份互不相干的仓库克隆，而是同一个 Git 仓库连接的另一处工作现场。

共享仓库元数据带来效率，也带来一条明确限制：同一个本地分支通常不能同时被两个 worktree 检出。Git 需要确保一个可移动分支引用只有一个权威工作现场，否则两个目录都可能尝试推进同一个 HEAD。

Codex App 怎样管理 worktree

OpenAI 当前的 Codex Worktrees 文档说明，桌面端可以在创建任务时选择 Local 或 Worktree。前者直接使用当前项目目录，后者基于所选起始分支创建一个由 Codex 管理的隔离现场。

这里有几个容易忽略的细节：

  • Codex 托管的 worktree 默认从所选分支当前的 HEAD 开始；
  • 新现场通常处于 detached HEAD，而不是自动占用一条正式分支；
  • 确认成果值得保留后，可以在 worktree 中创建分支并继续 commit、push 和 PR；
  • 也可以通过 Handoff 把任务和改动移回 Local，再用熟悉的本地环境检查；
  • worktree 中不会凭空出现未被 Git 跟踪的依赖和配置，必要的忽略文件需要通过环境设置或 .worktreeinclude 明确处理。

detached HEAD 并不表示改动会立刻消失，它只是提醒我们：当前工作尚未绑定到长期分支。真正要进入协作流程时，仍需要创建分支或通过 Handoff 安排后续落点。

Subagents 不是第四种 worktree

Subagents 也会让 Codex 同时走多条线，但它们分的是可并行子任务。主任务把代码探索、测试、日志分析或独立审查交给多个 agent thread，再收回摘要和结论。它们适合减少主线程中的噪声，也能加速彼此独立的读取与分析。

这和 Fork 的区别在于：Fork 产生一条可以独立继续的长期任务路线；subagent 则服务于当前主任务，最终结果仍由主任务汇总。它和 worktree 的区别则更直接：agent thread 并不天然等于独立文件目录。

需求更合适的工具
从当前对话另开一条长期路线Fork
并行检索模块、跑测试、分析日志Subagents
同时修改两套互不干扰的文件独立 worktree
保存并审查最终实现Branch + commit + PR

并行读取可以优先交给 subagents；并行写入则应先把文件所有权或工作目录隔离清楚。

多个 agent 同时写同一个目录，协调成本可能比节省的时间更高。真正需要并行实现时，可以让每条路线拥有独立 worktree，或明确规定每个 agent 只修改互不重叠的文件，并由主任务统一整合。

把几种能力放进同一条流程

如果方案本身还没有想清楚，可以先从 Plan Mode 开始。计划模式负责确认有哪些路线值得比较；Fork、subagents 与 worktree 则在不同层次上把比较真正展开。

flowchart TD
  Task["复杂任务"] --> Plan["Plan Mode\n识别路线与关键取舍"]
  Plan --> Choice{"需要怎样的分流？"}
  Choice -- "长期探索另一种思路" --> Fork["Fork\n复制任务上下文"]
  Choice -- "并行读取与分析" --> Agents["Subagents\n拆分独立子任务"]
  Choice -- "并行修改文件" --> Worktree["Worktree\n隔离工作目录"]
  Fork --> Validate["选出值得落地的路线"]
  Agents --> Validate
  Validate --> Worktree
  Worktree --> Branch["Create branch\n保存提交历史"]
  Branch --> Review["commit / CI / PR / review"]
  Review --> Merge["合并进入主线"]

这条流程不要求每次把所有工具都用一遍。关键是让隔离成本与任务风险相匹配。

只比较思路

如果暂时不改文件，只想比较两种架构或文案方向，派生任务即可。等其中一条路线胜出，再回到单一执行现场。

后台完成一项独立工作

如果任务目标明确，但执行时间较长，可以直接让 Codex 在 worktree 中工作。自己继续使用 Local，完成后再通过 diff、测试和 Handoff 检查结果。

同时验证两种实现

先在计划阶段确定统一验收标准，再为两条实现路线准备不同 worktree。两边使用独立分支和相同测试，最后比较正确性、改动范围、性能与维护成本，而不是只看哪一边先跑通。

最常见的几个误区

把 Fork 当成 Git 分支

任务派生不会自动产生 branch 或 commit。值得保留的实现，仍然要进入 Git 历史。

以为创建分支就能并行执行

分支能保存不同历史，但同一个目录同一时间只能呈现一个检出状态。需要并行文件现场时，应使用 worktree。

在两个 worktree 中占用同一分支

Git 通常会直接拒绝这种操作。准备把工作带回 Local 时，优先使用 Handoff，或者先让原 worktree 切离该分支。

忘记依赖和忽略文件并不会自动齐全

新的 worktree 有被 Git 跟踪的文件，却可能缺少 node_modules、本地数据库、环境变量或构建缓存。应通过可重复的 setup script 准备环境，只把确实需要的忽略文件列入 .worktreeinclude，并继续谨慎处理凭证。

worktree 建得很多，却没有收尾

独立目录会占用磁盘，也会留下分支和管理记录。手动创建的实验现场结束后，可以检查并清理：

git worktree list
git worktree remove ../project-refactor
git worktree prune

删除前应确认重要修改已经提交、推送或另行保存。清理现场不是清理思路；没有进入 Git 历史的成果，依然可能随目录一起消失。

结语

Codex 加入开发流程之后，我们不只需要管理代码状态，也开始管理任务路线与代理协作。Fork 让不同思路不必在同一段上下文里互相拉扯，worktree 让不同实现不必在同一个目录里争夺文件，branch 与 PR 则把最终选择沉淀为可以审查和回溯的工程历史。

先分清要隔离的是思路、子任务、文件现场还是提交历史，再选择对应工具。工具数量不是成熟度；边界清楚，才是。

继续阅读：Codex 计划模式怎么用讨论复杂任务如何在动手前形成方案，AI Agent 的 Skill 是什么则说明重复出现的协作方法如何被沉淀为可复用能力。

参考资料