Codex 主对话编排多个独立子对话：不是 Subagent 的多任务工作流

文章目录

• 1 -> 前言
• 2 -> 先说结论
• 3 -> 先把术语分清楚
• • 3.1 -> 主对话
  • 3.2 -> 独立子对话
  • 3.3 -> Fork 对话
  • 3.4 -> Side conversation
  • 3.5 -> Subagent
  • 3.6 -> Worktree
• 4 -> 独立任务与 Subagent 到底有什么不同
• 5 -> 为什么要建立主对话控制面
• • 5.1 -> 把“同时运行”变成“有边界地并行”
  • 5.2 -> 保护主上下文
  • 5.3 -> 让工作拥有可恢复性
  • 5.4 -> 将不同风险放进不同权限边界
• 6 -> 主对话编排的三层结构
• • 6.1 -> 第一层：控制面
  • 6.2 -> 第二层：任务面
  • 6.3 -> 第三层：证据与结果面
  • 6.4 -> 控制面需要维护的“三本账”
• 7 -> 从零搭建一个主对话控制台
• • 7.1 -> 第一步：先定义总目标，而不是先创建任务
  • 7.2 -> 第二步：绘制依赖关系
  • 7.3 -> 第三步：选择 Create 还是 Fork
  • 7.4 -> 第四步：选择 Local 还是 Worktree
  • 7.5 -> 第五步：派发完整任务包
  • 7.6 -> 第五步补充：建立上下文同步协议
  • 7.7 -> 第六步：观察，而不是反复打断
  • 7.8 -> 第七步：纠偏时发送增量信息
  • 7.9 -> 第八步：收口和归档
  • 7.10 -> 第九步：给结果标注可信度
• 8 -> 生命周期：从创建到归档
• 9 -> 可以直接使用的主对话提示词
• • 9.1 -> 初始化主控台
  • 9.2 -> 创建独立任务
  • 9.3 -> 检查进度
  • 9.4 -> 发送纠偏消息
  • 9.5 -> 最终收口
• 10 -> 案例一：用多个独立任务完成一篇深度文章
• 11 -> 案例二：同一代码仓库的并行开发
• 12 -> 最容易失败的九种方式
• • 12.1 -> 假设上下文会自动同步
  • 12.2 -> 给所有任务同一个宽泛目标
  • 12.3 -> 多个任务修改同一文件集合
  • 12.4 -> 主对话变成摘要搬运工
  • 12.5 -> 任务粒度过小
  • 12.6 -> 任务粒度过大
  • 12.7 -> 只看结论，不看证据
  • 12.8 -> 并发超过人的验收能力
  • 12.9 -> 把任务完成等同于项目完成
• 13 -> 注意力与用量如何控制
• 14 -> 三种可落地的编排模式
• • 14.1 -> 轻量模式：一主两支
  • 14.2 -> 中等模式：一主四线
  • 14.3 -> 重型模式：阶段化任务组合
• 15 -> 什么时候不应该使用
• 16 -> 启动清单与验收清单
• • 16.1 -> 启动前
  • 16.2 -> 运行中
  • 16.3 -> 收口时
• 17 -> 真正要建立的是任务操作系统

1 -> 前言

本文讨论一种 Codex 多任务工作方式：把一个独立、可持续对话设为“主控台”，再由它创建、分叉、观察和续写多个彼此独立的 Codex 任务。这里说的“子对话”只是为了便于理解，它们不是 subagent，而是用户可见、可单独打开、可以继续工作和长期保留的一等任务。

2 -> 先说结论

如果只是让 Codex 在一个任务内部并行查资料、跑测试或分析日志，subagent 通常已经够用。但如果你希望几条工作线各自拥有完整上下文、独立生命周期和清晰成果，并且需要在几小时甚至几天后继续推进，那么更适合使用“一个主对话编排多个独立任务”的方式。

这套方法的重点不是多开几个聊天窗口，而是建立一层明确的控制关系：

人
└── 主对话：维护目标、拆分任务、分配边界、检查证据、做出取舍
├── 独立任务 A：资料研究
├── 独立任务 B：方案设计
├── 独立任务 C：实现或制作
└── 独立任务 D：验证与反方检查

独立任务输出阶段性结果
↓
主对话读取摘要、继续追问、纠偏和收口
↓
人完成关键判断、批准外部动作或决定最终采纳

主对话不是拥有神奇权限的“总智能体”。它只是一段被赋予编排职责的独立对话。它能控制到什么程度，取决于当前 Codex 客户端是否开放了创建任务、分叉任务、读取任务和发送后续消息等能力。即使这些能力都可用，不同任务之间也不会自动共享上下文、文件变化和最新决策。

因此，这套工作流真正依赖的不是“多对话”三个字，而是四个基础条件：

3 -> 先把术语分清楚

Codex 中存在几个看起来相近、实际控制关系不同的概念。混用这些概念，是多任务工作流最常见的起点错误。

3.1 -> 主对话

主对话是用户选定的协调中心。它负责保存项目级目标、不可违反的限制、已确认决策、任务登记表和最终验收标准。

主对话一般不承担所有细节工作。它应该把注意力放在以下问题上：

• 当前真正要解决的是什么；
• 哪些工作可以独立推进；
• 每条工作线可以读什么、可以改什么；
• 哪些结论已经确认，哪些仍是假设；
• 哪些结果有证据，哪些只是看起来合理；
• 什么情况下继续、暂停、返工或结束。

“主”描述的是职责，而不是模型等级。一个主对话如果没有清晰任务表、没有状态检查、也不核验结果，它只是一个信息中转站，不是真正的控制面。

3.2 -> 独立子对话

本文所谓“独立子对话”，在产品语义上更接近独立 task 或 thread。它们可以由主对话新建，也可以从一个已有任务分叉而来。

它们通常具有这些特征：

• 在任务列表中单独存在；
• 有自己的上下文和消息历史；
• 可以独立继续发送后续指令；
• 可以单独重命名、固定或归档；
• 可以绑定同一个项目，也可以运行在独立 Worktree；
• 不会因为主对话结束就自动消失；
• 不会自动把全部中间过程汇报给主对话。

这里的“子”只表达它在本次工作流中接受主对话协调，不代表产品层面存在永久父子从属关系。

3.3 -> Fork 对话

Fork 是从一个既有任务分出一条新的探索路线。它适合这样的场景：两条路线需要共享已经形成的背景，但接下来要分别验证不同假设。

需要注意两个边界：

• Fork 复制的是已经完成的对话历史；
• 如果来源任务仍在运行，当前未完成的一轮和未完成回复不会被复制。

因此，不要在主对话刚发出复杂任务、尚未形成完整结论时立刻分叉，然后假设新任务已经知道所有最新信息。更稳妥的方式是先让主对话形成一份“当前决策快照”，再从这个稳定节点分叉。

3.4 -> Side conversation

Side conversation 是不打断主任务上下文的临时旁路，适合快速追问一个局部概念。它通常不适合承担长期项目、持续状态管理和多阶段交付。

如果问题十分钟后就可以关闭，用 side conversation 很轻便；如果它明天还要继续、需要自己的文件和验收记录，就应该建立独立任务。

3.5 -> Subagent

Subagent 是由当前任务内部委派出去的代理工作线程。官方文档描述的典型机制是：主代理生成若干专门代理，让它们并行探索、测试或分析，然后收集结果并在当前任务中形成综合回复。

它适合短周期、边界明确、结果主要服务于当前任务的工作。例如：

• 一个代理扫描安全风险；
• 一个代理检查测试缺口；
• 一个代理分析日志；
• 主代理等待结果并给出统一结论。

这和本文的独立任务模式不同。独立任务是用户任务空间中的长期工作单元；subagent 则是当前任务为完成自身目标而启动的内部委派单元。

3.6 -> Worktree

Worktree 不是对话类型，而是文件隔离环境。官方文档将其定位为：让同一 Git 项目中的多个独立任务在不同检出目录中并行工作，避免直接干扰本地工作区或彼此覆盖文件。

一个独立任务可以是只读研究任务，不需要 Worktree；也可以是写代码任务，此时通常应该分配独立 Worktree。对话隔离解决的是上下文问题，Worktree 隔离解决的是文件和 Git 状态问题，两者不能互相替代。

4 -> 独立任务与 Subagent 到底有什么不同

判断标准可以非常简单：

如果一项工作值得在侧边栏拥有自己的名字、上下文、状态和后续行动，它更像独立任务；如果它只需要为当前主任务返回一份材料，它更像 subagent。

5 -> 为什么要建立主对话控制面

同时打开多个任务并不自动产生并行效率。没有主控关系时，多对话很容易变成四份重复研究、四种互相矛盾的口径，以及四个都在等待用户补背景的问题。

主对话的价值主要体现在四个方面。

5.1 -> 把“同时运行”变成“有边界地并行”

并行成立的前提是工作线相对独立。主对话需要先识别依赖关系：

• 哪些任务现在就能开始；
• 哪些任务必须等待上游结论；
• 哪些任务只读，哪些任务会改文件；
• 哪些任务可以失败而不影响全局；
• 哪些结果必须统一口径后才能继续。

如果任务 B 的输入完全依赖任务 A 的结论，就不应该为了“看起来并发”而同时启动。真正有效的编排，是让独立部分并行，让依赖部分按阶段串行。

5.2 -> 保护主上下文

一个复杂项目会产生大量搜索记录、测试日志、失败尝试和临时假设。全部堆进一个对话，会让真正重要的决策被中间噪声淹没。

独立任务可以承载细节，主对话只保留：

• 已确认事实；
• 仍待验证的假设；
• 关键证据路径；
• 已作出的决定及其理由；
• 下一步需要人的判断。

这样做不是为了缩短所有输出，而是为了让主上下文始终保持可决策状态。

5.3 -> 让工作拥有可恢复性

独立任务有自己的历史。即使主对话正在处理别的事情，也可以稍后回到某条工作线继续推进。只要任务包和状态回执完整，项目不需要依赖某个人记住所有细节。

5.4 -> 将不同风险放进不同权限边界

资料研究可以只读；方案比较可以禁止改文件；实现任务可以进入独立 Worktree；外部发送、生产发布和不可逆操作则继续保留人工确认。

这比让一个拥有广泛权限的任务包办所有工作更容易审计，也更容易在出现偏差时止损。

6 -> 主对话编排的三层结构

6.1 -> 第一层：控制面

控制面就是主对话。它保存项目宪章和任务登记表，并决定任务的创建、暂停、续写和结束。

一份最小任务登记表可以长这样：

这里最重要的不是表格形式，而是主对话必须知道每条线的目标、状态、权限和依赖。

6.2 -> 第二层：任务面

任务面由多个独立对话组成。每个任务只解决一个边界清楚的问题，并拥有自己的任务包。

好的独立任务应该满足：

• 单独完成也能产生可用价值；
• 成功标准不依赖模糊的主观感觉；
• 输入和输出接口清楚；
• 写入范围能够排他地分配；
• 即使失败，也能说明失败在哪里以及下一步需要什么。

6.3 -> 第三层：证据与结果面

独立任务的最终回复不应只是“完成了”。它需要返回可被主对话检查的结构化回执，包括：

• 状态：完成、部分完成、阻塞或需要决策；
• 结论：最重要的三到五点；
• 证据：文件、链接、测试结果或可复现步骤；
• 变更：改了哪些文件或生成了哪些产物；
• 风险：还有什么没有验证；
• 建议：主对话下一步应该做什么。

主对话根据这些材料做整合，而不是根据一句“我已经完成”直接宣布项目结束。

6.4 -> 控制面需要维护的“三本账”

主对话想要长期稳定地协调多个独立任务，不能只依赖聊天记忆。最少要维护三类结构化信息。

第一本是决策账。它记录已经由人确认或由证据确定的结论，包括决定时间、决定内容、采用理由、被放弃的方案，以及什么条件变化时需要重新讨论。决策账解决的是“为什么今天不能重新走回已经否定的老路”。如果只留下最终选择而没有理由，几天后新的任务很容易把旧方案重新包装一遍，团队又要重复争论。

第二本是任务账。它就是前面的任务登记表，但还要记录任务输入版本、最近一次状态时间、当前阻塞、写入范围和负责人。任务账解决的是“谁正在做什么、依据哪一版背景、离完成还差什么”。当任务输出与主对话预期不一致时，先检查它收到的任务包版本，而不是立即认定任务执行错误。

第三本是产物账。它记录每个有效产物的位置、用途、生成任务、验证状态和替代关系。产物可以是代码分支、报告、测试记录、图片、数据表或决策摘要。产物账解决的是“哪个文件才是最新可信版本”。没有产物账时，多个任务经常分别生成名称相似的文件，主对话最后只能靠修改时间猜测应该采用哪一个。

这三本账不一定真的要做成三张表。小项目可以直接放在主对话的一个持续更新区块里；长期项目则可以沉淀为项目文档。关键是让状态来自可检查的记录，而不是依赖主对话在长上下文中“应该还记得”。

7 -> 从零搭建一个主对话控制台

7.1 -> 第一步：先定义总目标，而不是先创建任务

主对话最开始应当写清：

总目标：最终要交付什么。
成功标准：怎样判断结果真的可用。
共同背景：所有任务都必须知道的事实。
固定约束：不能改变的范围、规范和权限。
人工门禁：哪些动作必须由人确认。
最终负责人：谁决定采纳、合并、发布或对外发送。

如果总目标还没有说清，创建更多任务只会更快地产生分歧。

7.2 -> 第二步：绘制依赖关系

把工作分成三类：

一个常见顺序是：

阶段一：并行研究事实、风险和备选方案
阶段二：主对话综合，提交人确认方向
阶段三：在隔离环境中实现或制作
阶段四：独立验证、修正和最终验收

7.3 -> 第三步：选择 Create 还是 Fork

使用新建独立任务的情况：

• 需要干净上下文；
• 工作与主对话历史关系较弱；
• 希望严格控制输入，避免继承无关讨论；
• 需要从一个标准任务包开始。

使用 Fork 的情况：

• 两条路线必须共享已经形成的长背景；
• 希望从同一个稳定决策点分别探索方案 A 和 B；
• 保留来源历史比重新整理任务包更经济。

即使使用 Fork，也建议在第一条消息中写明新任务的独立目标和停止条件。共享历史不等于共享未来方向。

7.4 -> 第四步：选择 Local 还是 Worktree

只读分析通常不需要独立 Worktree。涉及写代码、改配置或生成可能重名的文件时，应优先考虑隔离。

7.5 -> 第五步：派发完整任务包

不要只发一句“研究一下方案”。独立任务看不到主对话脑中的隐含背景。任务包应至少包含以下字段：

任务名称：

目标：
这项任务需要回答或完成什么。

背景：
与任务直接相关的已确认事实和决策。

输入：
允许使用的文件、链接、数据或已有结论。

范围：
需要覆盖哪些内容。

不做：
明确排除哪些方向和动作。

权限与写入边界：
只读还是可写；若可写，只允许修改哪些路径。

成功标准：
满足哪些条件才算完成。

验证方式：
需要运行什么检查，或提供什么证据。

输出格式：
结论、证据、变更、风险、建议下一步。

遇到阻塞时：
不要扩大范围，返回阻塞原因和最小决策问题。

7.6 -> 第五步补充：建立上下文同步协议

独立任务之间不存在天然的共享记忆，因此需要提前约定什么信息必须同步、由谁同步、同步以后如何确认。

最实用的做法是把信息分成三类：

• 全局事实：所有任务都必须使用的稳定背景，由主对话统一维护；
• 局部事实：只影响某一条工作线，保留在对应任务中；
• 全局决策：一旦改变就会影响多个任务，必须由主对话向受影响任务逐一发送更新。

同步消息不要只写“方案变了，请按新的做”。它应该包含决策编号、旧口径、新口径、生效范围，以及是否需要重做已经完成的部分。例如：

决策更新 D-04：目标用户从所有中小企业收窄为已有海外销售团队的制造企业。

保持不变：交付形式、时间范围、数据来源要求。
受影响范围：任务 A 的样本筛选，任务 B 的价值主张，任务 C 的案例选择。
需要重做：仅重新检查不符合新目标用户定义的部分；其余证据继续有效。
收到后请先复述影响，再继续执行。

要求任务先复述影响，是一个很小但很有效的动作。它能在任务继续消耗时间以前发现理解偏差，也能帮助主对话确认哪些任务已经切换到最新口径。

7.7 -> 第六步：观察，而不是反复打断

主对话应按决策需求检查状态，不必每几分钟追问一次。适合检查的时点包括：

• 某个上游结果将解锁其他任务；
• 任务运行时间明显超过预期；
• 需要在人做判断前收集完整证据；
• 子任务主动报告阻塞；
• 项目范围或共同口径发生变化。

状态检查应询问“离完成标准还差什么”，而不是只问“做到哪了”。

主对话还应区分三种等待状态。第一种是正常运行，任务拥有充分输入，尚未到检查点；此时频繁催问只会制造上下文切换。第二种是静默阻塞，任务缺少文件、权限或上游结论，却没有及时提出最小问题；这时主对话需要主动读取状态。第三种是方向漂移，任务持续产生内容，但输出逐渐离开完成标准；这种情况比显式失败更危险，因为它看起来一直在工作。

可以为每个任务设置一个“下一检查条件”，而不是统一设置机械时间间隔。例如：完成来源清单后检查、准备写文件前检查、首次测试失败后检查、需要扩大范围时检查。这样既保留任务自主推进的空间，也能在成本和风险即将上升前让主对话重新介入。

7.8 -> 第七步：纠偏时发送增量信息

给独立任务发送后续消息时，应指出：

• 哪一项判断需要修正；
• 新增了什么事实；
• 原任务包哪些部分仍然有效；
• 输出格式或成功标准是否变化；
• 是否需要重新验证已经完成的部分。

不要每次把整个任务包原样重发，否则任务很难判断哪些内容是新的。

7.9 -> 第八步：收口和归档

任务完成后，主对话应完成四件事：

7.10 -> 第九步：给结果标注可信度

不同任务返回的“结论”并不处在同一证据等级。主对话如果把它们全部当成确定事实，最终汇总会显得非常完整，却可能把假设、推断和验证结果混在一起。

建议至少使用四级标记：

当多个任务对同一个问题给出不同答案时，主对话不应该用多数票决定真伪。更好的做法是比较它们使用的输入、时间范围、定义和证据等级。有些冲突并不是谁错了，而是两个任务回答了略有不同的问题。只有把问题定义对齐以后，结论才具有可比性。

最终文章、方案或代码说明中，也应保留尚未验证的边界。透明地写出“这里仍是假设”，比用流畅语言掩盖不确定性更有价值。

8 -> 生命周期：从创建到归档

一个成熟的任务生命周期可以用七个状态理解：

不要把“输出了一段文字”当作完成状态。完成必须对应事先定义的成功标准。

9 -> 可以直接使用的主对话提示词

9.1 -> 初始化主控台

你是这个项目的主控对话，负责维护总目标、任务边界、状态和最终验收。

请使用多个用户可见、可独立继续的 Codex 任务推进工作，不要使用 subagent 代替这些独立任务。

先不要创建任务。请先：
1. 复述总目标和成功标准；
2. 列出可以并行的工作线和它们之间的依赖；
3. 为每条工作线定义输入、范围、不做事项、权限和输出格式；
4. 指出哪些任务应该新建，哪些适合从当前对话 Fork；
5. 指出哪些写任务需要独立 Worktree；
6. 等我确认任务结构后再创建独立任务。

任何合并、发布、外部发送或不可逆操作都必须等我确认。

9.2 -> 创建独立任务

按照已经确认的任务结构，创建以下三个独立 Codex 任务。它们必须出现在任务列表中并可单独继续，不要用 subagent：

任务 A：只读核对官方事实和来源。
任务 B：形成三种可比较的方案，不修改文件。
任务 C：列出验证方法、失败条件和风险。

请为每个任务发送完整任务包，使用清楚的任务名称。创建完成后，返回任务登记表，包括任务名称、目标、环境、写入范围和当前状态。

如果当前客户端不支持创建独立任务，请明确说明，不要悄悄改用 subagent；改为输出三个可手动复制的新任务提示词。

9.3 -> 检查进度

读取任务 A、B、C 的最近状态和阶段性结论，不要重新执行它们的工作。

请更新任务登记表，并指出：
1. 哪些任务已经满足完成标准；
2. 哪些任务缺少证据；
3. 哪些任务被阻塞；
4. 当前是否存在相互矛盾的结论；
5. 下一步只需要我决定什么。

9.4 -> 发送纠偏消息

向任务 B 发送后续指令：原目标和范围保持不变，但必须补充方案在最坏情况下的失败方式，并用统一指标重新比较三个方案。不要扩大到实现阶段。完成后按原回执格式返回。

发送后更新主任务登记表，不要假设任务已经完成。

9.5 -> 最终收口

汇总所有独立任务的最终回执。只使用有证据支持的结论。

输出：
1. 已确认事实；
2. 已采纳方案及理由；
3. 被拒绝方案及理由；
4. 尚未解决的风险；
5. 验证结果；
6. 需要人工批准的下一步。

不要把多个任务的文字简单拼接；发现冲突时先列出冲突和证据，再提出裁决建议。

10 -> 案例一：用多个独立任务完成一篇深度文章

假设目标是写一篇关于某项新技术的长文。可以这样拆分：

这几个任务可以相对独立地工作，但正文最好仍由一个明确的写作者统一完成。否则不同任务分别写章节，容易出现语气不一致、概念重复和前后定义漂移。

主对话在这里承担编辑部主任的角色：先收事实和反方意见，再确定论点，最后把材料组织成一条完整论证，而不是把五份输出首尾相接。

11 -> 案例二：同一代码仓库的并行开发

代码任务的难点不在对话数量，而在共享可变状态。多个任务如果同时修改同一个本地目录，可能覆盖文件、读到半成品或让测试结果失去归属。

一种更稳妥的阶段安排是：

阶段一：只读并行
任务 A：理解现有机制
任务 B：分析安全和回归风险
任务 C：设计测试与失败用例

阶段二：主对话收敛
合并事实，形成人工确认的实施计划

阶段三：隔离写入
任务 D：在独立 Worktree 实现后端范围
任务 E：在另一个 Worktree 实现前端范围
前提：两者写入文件集合不重叠，接口已经冻结

阶段四：集成验证
按顺序整合变更，在统一环境运行测试和构建
任务 F：只读审查完整变更集和验证结果

必须强调：Worktree 解决的是并行修改互不直接覆盖，不会自动解决设计冲突、接口冲突和最终合并。合并顺序、冲突裁决和生产发布仍然需要明确负责人。

12 -> 最容易失败的九种方式

12.1 -> 假设上下文会自动同步

主对话新确认了一个决策，其他任务并不会自动知道。共同口径变化时，必须向所有受影响任务发送增量更新。

12.2 -> 给所有任务同一个宽泛目标

如果四个任务都收到“研究最佳方案”，它们大概率重复工作。并行任务必须拥有不同问题或不同证据责任。

12.3 -> 多个任务修改同一文件集合

即使使用不同 Worktree，最终也会产生高成本冲突。应提前分配互斥写入范围；无法分离时改为一个实现任务，其他任务只读评审。

12.4 -> 主对话变成摘要搬运工

主对话如果只是把各任务输出复制到一起，就没有发挥控制面价值。它必须检查证据、识别冲突、做出取舍并维护决策记录。

12.5 -> 任务粒度过小

为五分钟能完成的问题创建一个长期独立任务，会让管理成本大于收益。短问题优先直接询问或使用临时旁路。

12.6 -> 任务粒度过大

“完成整个项目”不是有效任务包。任务过大时，独立对话同样会失去边界、长期运行并不断向人索要决策。

12.7 -> 只看结论，不看证据

多个任务一致不代表结论正确，它们可能共享了同一个错误假设。主对话应要求来源、测试结果和反例，而不是用投票代替验证。

12.8 -> 并发超过人的验收能力

任务同时完成后，人的注意力会集中承压。并发数量应由“能否及时判断结果”决定，而不是由系统最多能开多少任务决定。

12.9 -> 把任务完成等同于项目完成

各工作线完成以后，还需要跨任务一致性检查、集成验证和人工采纳。局部完成只是进入收口阶段，不是自动交付。

13 -> 注意力与用量如何控制

多任务模式会增加模型工作量，也会增加人的审阅压力。最有效的节制方式不是一味减少任务，而是提高每个任务的信息密度。

可以采用以下规则：

• 主对话只接收结构化回执，不接收无筛选的全部日志；
• 同一事实只指定一个权威调查任务；
• 任务在等待人决策时主动停止，不继续扩展范围；
• 完成的临时任务及时归档；
• 每轮状态检查只处理能改变下一步的内容；
• 失败任务返回失败证据，不为了“交作业”生成虚假的完整答案；
• 主对话维护最新决策摘要，避免每次重复发送整段历史。

一个实用的并发上限判断是：

如果四个任务同时返回结果后，你无法在合理时间内分别判断它们是否正确，那么真正的瓶颈已经不是 Codex，而是验收带宽。

14 -> 三种可落地的编排模式

14.1 -> 轻量模式：一主两支

适合半天内完成的研究或方案任务。

• 主对话负责问题定义和最终写作；
• 一个独立任务找事实；
• 一个独立任务找反例；
• 全部任务只读，不引入 Worktree。

14.2 -> 中等模式：一主四线

适合跨一天的产品、内容或技术方案。

• 事实、方案、风险、验证四条线独立运行；
• 主对话设置一次中期决策点；
• 确认方向以后只保留一条实现线；
• 其他任务转为审查和证据补充。

14.3 -> 重型模式：阶段化任务组合

适合多文件开发、长期项目或高风险变更。

• 先并行只读调查；
• 人确认计划后再进入写入阶段；
• 写任务使用互相隔离的 Worktree 和排他文件范围；
• 每个阶段都有验证和审查任务；
• 合并、发布、生产凭据和外部发送始终由人批准。

重型模式的关键不是把所有任务都长期保持运行，而是在不同阶段启用不同任务组合。

无论采用哪一种模式，主对话都要识别“需要重新规划”的信号：总目标发生变化、两个以上任务同时报告相同阻塞、原先独立的写入范围开始重叠、关键假设被证伪，或者现有验收标准已经无法判断结果好坏。出现这些信号时，不应继续给每个任务零散补丁，而应暂停受影响工作线，更新总目标、依赖图和任务包版本，再决定哪些任务继续、重开或结束。重新规划不是失败，而是防止多个独立任务在已经失效的方向上同时加速。

15 -> 什么时候不应该使用

以下情况通常不值得采用主对话加多个独立任务：

• 一个任务十几分钟就能完成；
• 所有步骤高度耦合，每一步都依赖上一步的细节；
• 成功标准尚未定义，无法给不同任务分配边界；
• 多条工作线必须持续修改同一个共享状态；
• 没有人有时间检查结果；
• 只是为了追求并发数量，而没有真实的独立问题；
• 客户沟通、生产发布或不可逆操作需要实时人工判断。

在这些场景下，一个聚焦的主任务通常比多个独立任务更可靠。

16 -> 启动清单与验收清单

16.1 -> 启动前

• 总目标可以用一句话说明；
• 成功标准可以验证；
• 已区分并行任务与依赖任务；
• 每项任务都有不同的责任边界；
• 已决定新建还是 Fork；
• 写任务拥有排他的文件范围；
• 需要隔离的任务已经选择 Worktree；
• 人工门禁已经写清楚。

16.2 -> 运行中

• 主对话维护最新任务登记表；
• 共同决策已同步到受影响任务；
• 状态检查围绕完成标准进行；
• 阻塞任务没有擅自扩大范围；
• 并发数量没有超过人的验收能力。

16.3 -> 收口时

• 每个结果都有证据；
• 相互矛盾的结论已经裁决；
• 文件变更和产物清单完整；
• 集成后的整体结果重新验证；
• 未解决风险已经记录；
• 需要长期保留的任务已固定或重命名；
• 已结束任务已经归档；
• 合并、发布和外部动作仍由人决定。

17 -> 真正要建立的是任务操作系统

“一个主对话控制几个子对话”听起来像一个界面技巧，但它背后改变的是工作组织方式。

过去，我们往往把一个项目塞进一个长对话，期待它从理解背景一路做到最终交付。新的方式是把项目拆成多个拥有清晰输入输出的独立任务，再用一个主对话维护共同目标、状态和决策。

这带来三个变化：

但不要误解这种能力。多个任务不会自动形成一个可靠系统。真正决定质量的，仍然是任务是否拆得合理、上下文是否完整、写入是否隔离、证据是否充分，以及人有没有在关键节点做出判断。

最值得记住的一句话是：

独立任务负责把工作向前推进，主对话负责让所有推进仍然指向同一个目标，人负责最终的判断和责任。

感谢各位大佬支持！！！

互三啦！！！