一个对话塞不下所有任务：怎样用 Thread、Worktree 和 Subagent 管理 Codex

复杂项目最容易出现的问题，不是 Codex 不会写代码，而是所有事情都被塞进同一个对话：

• 需求分析和实现混在一起；
• 多条方案互相干扰；
• 旧任务约束影响新任务；
• 测试、审查和修复共享同一套判断；
• 上下文越来越长，却越来越难找到重点。

要解决这个问题，需要区分 Thread、Worktree、Handoff 和 Subagent。

四个概念分别解决什么问题

概念	本质	典型用途
Thread	用户可见、可长期保留的任务线	长期项目、后台跟进、稍后继续
Worktree	独立的 Git 代码工作区	并行修改，不影响当前目录
Handoff	移交线程及相关 Git 状态	在本机、远程或 Worktree 之间移动任务
Subagent	单次主任务中的临时协作者	并行分析、审查和验证

可以记成一句话：

Thread 管任务历史，Worktree 隔离代码，Handoff 搬运状态，Subagent 临时分工。

Thread 适合长期任务线

一个 Thread 拥有独立对话历史，可以被继续、归档、置顶或分叉。

它适合承载：

• 一个持续数天的功能开发；
• 一条长期排障线；
• 后台执行的研究任务；
• 需要定期回来跟进的项目；
• 和其他方案保持隔离的探索方向。

当目标已经发生明显变化时，新建或分叉 Thread 通常比继续堆积上下文更清楚。

Worktree 解决代码并行冲突

如果两个任务都要修改同一个 Git 仓库，只分两个 Thread 仍可能在文件系统里互相干扰。

Worktree 提供独立检出：

主工作区：处理当前功能
Worktree A：后台修复测试
Worktree B：尝试另一套重构方案

不同任务线拥有各自文件状态和分支，最后再通过正常 Git review 决定合并哪一部分。

Worktree 不是自动消除冲突，而是把冲突推迟到可见、可审查的合并阶段。

Handoff 解决“任务应该在哪里继续”

有些任务最初在本地分析，后面更适合移到 Worktree 或远程环境；也可能在远程完成后，需要回到本地继续。

Handoff 的目标是把线程和关联状态移动到更合适的位置，而不是重新解释全部背景。

移交前最好留下简洁的交接信息：

• 当前目标；
• 已完成内容；
• 修改过的文件；
• 已运行的验证；
• 仍然存在的阻塞和下一步。

Subagent 适合一次任务中的临时分工

Subagent 不等于新的长期项目。

它通常由主任务临时派生，用于：

• 一个负责读前端，一个负责读后端；
• 一个分析实现，一个专门找风险；
• 一个写修复方案，一个检查测试缺口；
• 多个来源并行检索，最后由主 Agent 汇总。

Subagent 有独立上下文，中间过程不会全部混入主线程。这样可以减少相互暗示，让审查角色更独立。

但 Subagent 会增加模型调用和协调成本。简单任务不需要为了“并行”而并行。

一个适合长期项目的组织方式

1. 先用文档定义项目

准备 PRD、技术方案、验收标准和关键决策记录，并通过 AGENTS.md 告诉 Codex 应该先读哪些文件。

2. 让主线程承担调度

主线程负责维护目标、拆分任务、检查进度和汇总结果，不必亲自完成每一个子问题。

3. 独立修改使用 Worktree

不同功能或实验方案进入不同工作区，避免直接争抢相同文件。

4. 临时分析交给 Subagent

把边界清晰、可独立汇总的任务交给子代理，例如安全审查、测试覆盖和文档一致性检查。

5. 用日志和验证保持可追踪

要求每条任务线记录关键判断、修改文件、验证结果和下一步。不要只依赖对话历史。

常见误区

• 为每个小问题都创建新 Thread，导致历史碎片化；
• 多个 Thread 共用同一目录并同时修改；
• 主线程只负责发任务，却不做最终验收；
• Subagent 的结论未经证据核对就直接合并；
• 高频轮询后台线程，浪费上下文和 token；
• 没有交接摘要，Handoff 后重新探索一遍。

写在最后

多线程管理不是让更多 Agent 同时忙碌，而是让不同目标拥有合适的上下文和工作区。

简单任务留在当前 Thread；长期任务建立独立任务线；并行代码使用 Worktree；一次性的分析和审查交给 Subagent。

当任务、上下文和文件状态各自有清晰边界，Codex 才能真正稳定地处理复杂项目。