Codex 里的一次对话就是一个 thread。你手动开一条，让它改一个功能，这是最顺手的用法。真实项目里往往不止一条线在跑，一个 bug 等着修，一个方案还想试试，还有个后台任务在等结果。
全塞进同一个对话，问题就来了。线程各自带着独立上下文，混在一起之后，前面聊过的结论会把后面的判断带偏，比较典型的表现是它写出来的测试总是 100% 通过。线程管理要解决的就是这件事，把几条活拆到各自的线上跑。
一次对话就是一条线程
Thread 是你能看到的那条会话，有自己的历史记录。长期任务，后台运行，关掉之后稍后继续，这几类活都适合挂在一条线程上。你平时手动新建，继续，归档它。桌面端的 Codex 还会通过内置的线程管理工具，主动帮你整理，分叉，移交和跟进。
四个容易混的概念
| 概念 | 是什么 | 什么时候用 |
|---|---|---|
| Thread | 你可见的会话，带独立历史记录 | 长期任务，后台运行，稍后继续 |
| Worktree | Git 工作树，多个并行的代码检出 | 让它在后台改代码，不打扰你当前的工作区 |
| Handoff | 把线程连同 Git 状态搬到另一个位置 | 在本地，工作树或远程主机之间切换 |
| Subagent | 主任务里临时派生的子代理 | 并行分析，审查，验证同一任务的不同面 |
线程是长期的任务线。工作树是并行的代码工作区。移交负责把任务搬到合适的位置。子代理是单次任务里临时叫来的帮手。
让 Codex 自己去整理线程
这组工具来自桌面端，是内置的，不是对外公开的 CLI 命令或接口，命名和可用性会跟着客户端版本变。
| 工具 | 用途 |
|---|---|
| list_threads | 列出最近线程，可按关键词查找 |
| read_thread | 读某个线程的最近状态，摘要和历史片段 |
| send_message_to_thread | 给已有线程发后续指令，让它在后台继续 |
| fork_thread | 从当前或指定线程分叉，可同目录，也可新建工作树 |
| handoff_thread | 把线程及其 Git 状态移交到本机，远程主机或工作树 |
| get_handoff_status | 查询移交流程进度 |
| set_thread_title 等三项 | 重命名，置顶，归档线程 |
| list_projects | 列出可用于创建后台线程的本地或远程项目 |
对 Codex 说一句「帮我归档超过一周的线程」就能用上。它做的事和你手动整理会话没本质区别，只是由它按当前目标判断下一步。
它和 Subagent 不是一回事
两者都能让 Codex 同时处理多个任务线，但层级不同。线程管的是你能看见的会话，可以长期保留。它出现在历史列表里，也能挂上工作树，分支或者 PR。子代理管的是当前任务里临时生成的代理，通常随一次主任务创建，汇总，关闭。它继承主任务的沙盒和审批策略。上下文上的差别也不小，线程是独立的完整历史，子代理只接收主代理传来的任务描述，中间过程不会整段混进主上下文。
上手先立这几条规矩
- 文档驱动开发。新建 docs 文件夹放 PRD 这类项目文档，再用 AGENTS.md 告诉 Codex 先读哪些文件。
- 规范工作行为。用 GUIDE.md 或项目规则写明「应当在独立 Git 分支工作」「提交前必须跑测试」。
- 任命主线程。让主线程承担调度角色，分配工作给其他线程，写提示词，盯运行情况。
- 合理设置检查频率。主线程要看后台进展就约定间隔，比如每 3 分钟一次，频率太高会白耗上下文和 token。
- 记录日志。要求它把工作日志记下来，尤其是文档之外需要它判断的关键决策。
- 定期复盘。翻日志和实际决策，找出卡住或者低效的原因，回头改文档和规则。
配合 /goal 一起用，这套线程管理的能力能发挥得更充分。
