文章目录1 - 前言2 - 先说结论3 - 先把术语分清楚3.1 - 主对话3.2 - 独立子对话3.3 - Fork 对话3.4 - Side conversation3.5 - Subagent3.6 - Worktree4 - 独立任务与 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 还是 Fork7.4 - 第四步选择 Local 还是 Worktree7.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 conversationSide conversation 是不打断主任务上下文的临时旁路适合快速追问一个局部概念。它通常不适合承担长期项目、持续状态管理和多阶段交付。如果问题十分钟后就可以关闭用 side conversation 很轻便如果它明天还要继续、需要自己的文件和验收记录就应该建立独立任务。3.5 - SubagentSubagent 是由当前任务内部委派出去的代理工作线程。官方文档描述的典型机制是主代理生成若干专门代理让它们并行探索、测试或分析然后收集结果并在当前任务中形成综合回复。它适合短周期、边界明确、结果主要服务于当前任务的工作。例如一个代理扫描安全风险一个代理检查测试缺口一个代理分析日志主代理等待结果并给出统一结论。这和本文的独立任务模式不同。独立任务是用户任务空间中的长期工作单元subagent 则是当前任务为完成自身目标而启动的内部委派单元。3.6 - WorktreeWorktree 不是对话类型而是文件隔离环境。官方文档将其定位为让同一 Git 项目中的多个独立任务在不同检出目录中并行工作避免直接干扰本地工作区或彼此覆盖文件。一个独立任务可以是只读研究任务不需要 Worktree也可以是写代码任务此时通常应该分配独立 Worktree。对话隔离解决的是上下文问题Worktree 隔离解决的是文件和 Git 状态问题两者不能互相替代。4 - 独立任务与 Subagent 到底有什么不同比较维度独立任务对话SubagentSide conversation生命周期可长期保存之后继续通常服务于当前主任务临时、短暂用户可见性任务列表中的独立项目作为主任务中的代理线程展示当前任务的旁路上下文自己维护必须显式传递接收主代理委派的上下文依附当前任务背景控制方式可读取状态、发送后续消息、重命名和归档主代理负责委派、等待和汇总用户快速提问后返回结果回流不自动需要主对话主动读取或要求回报通常自动回到主任务回到当前会话体验文件环境可选择 Local、Worktree 或其他可用环境继承或受主任务环境约束通常不承担独立写入工作适合时长几十分钟到数天以上几分钟到一轮复杂任务几十秒到几分钟适合目标可独立验收的完整工作线主任务内部的并行子问题不值得污染主上下文的小问题人的角色管理任务组合与关键决策主要验收主任务综合结果获取一个即时答案判断标准可以非常简单如果一项工作值得在侧边栏拥有自己的名字、上下文、状态和后续行动它更像独立任务如果它只需要为当前主任务返回一份材料它更像 subagent。5 - 为什么要建立主对话控制面同时打开多个任务并不自动产生并行效率。没有主控关系时多对话很容易变成四份重复研究、四种互相矛盾的口径以及四个都在等待用户补背景的问题。主对话的价值主要体现在四个方面。5.1 - 把“同时运行”变成“有边界地并行”并行成立的前提是工作线相对独立。主对话需要先识别依赖关系哪些任务现在就能开始哪些任务必须等待上游结论哪些任务只读哪些任务会改文件哪些任务可以失败而不影响全局哪些结果必须统一口径后才能继续。如果任务 B 的输入完全依赖任务 A 的结论就不应该为了“看起来并发”而同时启动。真正有效的编排是让独立部分并行让依赖部分按阶段串行。5.2 - 保护主上下文一个复杂项目会产生大量搜索记录、测试日志、失败尝试和临时假设。全部堆进一个对话会让真正重要的决策被中间噪声淹没。独立任务可以承载细节主对话只保留已确认事实仍待验证的假设关键证据路径已作出的决定及其理由下一步需要人的判断。这样做不是为了缩短所有输出而是为了让主上下文始终保持可决策状态。5.3 - 让工作拥有可恢复性独立任务有自己的历史。即使主对话正在处理别的事情也可以稍后回到某条工作线继续推进。只要任务包和状态回执完整项目不需要依赖某个人记住所有细节。5.4 - 将不同风险放进不同权限边界资料研究可以只读方案比较可以禁止改文件实现任务可以进入独立 Worktree外部发送、生产发布和不可逆操作则继续保留人工确认。这比让一个拥有广泛权限的任务包办所有工作更容易审计也更容易在出现偏差时止损。6 - 主对话编排的三层结构6.1 - 第一层控制面控制面就是主对话。它保存项目宪章和任务登记表并决定任务的创建、暂停、续写和结束。一份最小任务登记表可以长这样任务目标环境写入范围当前状态下一决策点A查清官方能力边界只读无进行中来源是否充分B形成三种方案独立任务无已完成选择方案C实现确认方案Worktreesrc/feature/**等待等方案确认D验证结果独立环境测试文件未启动等实现完成这里最重要的不是表格形式而是主对话必须知道每条线的目标、状态、权限和依赖。6.2 - 第二层任务面任务面由多个独立对话组成。每个任务只解决一个边界清楚的问题并拥有自己的任务包。好的独立任务应该满足单独完成也能产生可用价值成功标准不依赖模糊的主观感觉输入和输出接口清楚写入范围能够排他地分配即使失败也能说明失败在哪里以及下一步需要什么。6.3 - 第三层证据与结果面独立任务的最终回复不应只是“完成了”。它需要返回可被主对话检查的结构化回执包括状态完成、部分完成、阻塞或需要决策结论最重要的三到五点证据文件、链接、测试结果或可复现步骤变更改了哪些文件或生成了哪些产物风险还有什么没有验证建议主对话下一步应该做什么。主对话根据这些材料做整合而不是根据一句“我已经完成”直接宣布项目结束。6.4 - 控制面需要维护的“三本账”主对话想要长期稳定地协调多个独立任务不能只依赖聊天记忆。最少要维护三类结构化信息。第一本是决策账。它记录已经由人确认或由证据确定的结论包括决定时间、决定内容、采用理由、被放弃的方案以及什么条件变化时需要重新讨论。决策账解决的是“为什么今天不能重新走回已经否定的老路”。如果只留下最终选择而没有理由几天后新的任务很容易把旧方案重新包装一遍团队又要重复争论。第二本是任务账。它就是前面的任务登记表但还要记录任务输入版本、最近一次状态时间、当前阻塞、写入范围和负责人。任务账解决的是“谁正在做什么、依据哪一版背景、离完成还差什么”。当任务输出与主对话预期不一致时先检查它收到的任务包版本而不是立即认定任务执行错误。第三本是产物账。它记录每个有效产物的位置、用途、生成任务、验证状态和替代关系。产物可以是代码分支、报告、测试记录、图片、数据表或决策摘要。产物账解决的是“哪个文件才是最新可信版本”。没有产物账时多个任务经常分别生成名称相似的文件主对话最后只能靠修改时间猜测应该采用哪一个。这三本账不一定真的要做成三张表。小项目可以直接放在主对话的一个持续更新区块里长期项目则可以沉淀为项目文档。关键是让状态来自可检查的记录而不是依赖主对话在长上下文中“应该还记得”。7 - 从零搭建一个主对话控制台7.1 - 第一步先定义总目标而不是先创建任务主对话最开始应当写清总目标最终要交付什么。 成功标准怎样判断结果真的可用。 共同背景所有任务都必须知道的事实。 固定约束不能改变的范围、规范和权限。 人工门禁哪些动作必须由人确认。 最终负责人谁决定采纳、合并、发布或对外发送。如果总目标还没有说清创建更多任务只会更快地产生分歧。7.2 - 第二步绘制依赖关系把工作分成三类可以立即并行的任务必须等待上游结果的任务需要人判断后才能开始的任务。一个常见顺序是阶段一并行研究事实、风险和备选方案 阶段二主对话综合提交人确认方向 阶段三在隔离环境中实现或制作 阶段四独立验证、修正和最终验收7.3 - 第三步选择 Create 还是 Fork使用新建独立任务的情况需要干净上下文工作与主对话历史关系较弱希望严格控制输入避免继承无关讨论需要从一个标准任务包开始。使用 Fork 的情况两条路线必须共享已经形成的长背景希望从同一个稳定决策点分别探索方案 A 和 B保留来源历史比重新整理任务包更经济。即使使用 Fork也建议在第一条消息中写明新任务的独立目标和停止条件。共享历史不等于共享未来方向。7.4 - 第四步选择 Local 还是 Worktree只读分析通常不需要独立 Worktree。涉及写代码、改配置或生成可能重名的文件时应优先考虑隔离。场景推荐环境只读搜索、资料研究当前项目或 projectless 独立任务只读代码审查当前项目只读权限单一写任务、没有其他并行修改Local 可用但仍需检查工作区多个并行代码任务每个任务使用独立 Worktree需要最后在常用 IDE 验证Worktree 完成后 Handoff 到 Local7.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 - 真正要建立的是任务操作系统“一个主对话控制几个子对话”听起来像一个界面技巧但它背后改变的是工作组织方式。过去我们往往把一个项目塞进一个长对话期待它从理解背景一路做到最终交付。新的方式是把项目拆成多个拥有清晰输入输出的独立任务再用一个主对话维护共同目标、状态和决策。这带来三个变化人从逐步盯执行转向设计任务边界和验收结果Codex 从单线程助手变成多个可恢复任务组成的工作组合上下文从聊天历史变成可以显式传递、更新和审计的任务资产。但不要误解这种能力。多个任务不会自动形成一个可靠系统。真正决定质量的仍然是任务是否拆得合理、上下文是否完整、写入是否隔离、证据是否充分以及人有没有在关键节点做出判断。最值得记住的一句话是独立任务负责把工作向前推进主对话负责让所有推进仍然指向同一个目标人负责最终的判断和责任。感谢各位大佬支持互三啦
Codex 主对话编排多个独立子对话：不是 Subagent 的多任务工作流
发布时间：2026/7/19 14:34:35
文章目录1 - 前言2 - 先说结论3 - 先把术语分清楚3.1 - 主对话3.2 - 独立子对话3.3 - Fork 对话3.4 - Side conversation3.5 - Subagent3.6 - Worktree4 - 独立任务与 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 还是 Fork7.4 - 第四步选择 Local 还是 Worktree7.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 conversationSide conversation 是不打断主任务上下文的临时旁路适合快速追问一个局部概念。它通常不适合承担长期项目、持续状态管理和多阶段交付。如果问题十分钟后就可以关闭用 side conversation 很轻便如果它明天还要继续、需要自己的文件和验收记录就应该建立独立任务。3.5 - SubagentSubagent 是由当前任务内部委派出去的代理工作线程。官方文档描述的典型机制是主代理生成若干专门代理让它们并行探索、测试或分析然后收集结果并在当前任务中形成综合回复。它适合短周期、边界明确、结果主要服务于当前任务的工作。例如一个代理扫描安全风险一个代理检查测试缺口一个代理分析日志主代理等待结果并给出统一结论。这和本文的独立任务模式不同。独立任务是用户任务空间中的长期工作单元subagent 则是当前任务为完成自身目标而启动的内部委派单元。3.6 - WorktreeWorktree 不是对话类型而是文件隔离环境。官方文档将其定位为让同一 Git 项目中的多个独立任务在不同检出目录中并行工作避免直接干扰本地工作区或彼此覆盖文件。一个独立任务可以是只读研究任务不需要 Worktree也可以是写代码任务此时通常应该分配独立 Worktree。对话隔离解决的是上下文问题Worktree 隔离解决的是文件和 Git 状态问题两者不能互相替代。4 - 独立任务与 Subagent 到底有什么不同比较维度独立任务对话SubagentSide conversation生命周期可长期保存之后继续通常服务于当前主任务临时、短暂用户可见性任务列表中的独立项目作为主任务中的代理线程展示当前任务的旁路上下文自己维护必须显式传递接收主代理委派的上下文依附当前任务背景控制方式可读取状态、发送后续消息、重命名和归档主代理负责委派、等待和汇总用户快速提问后返回结果回流不自动需要主对话主动读取或要求回报通常自动回到主任务回到当前会话体验文件环境可选择 Local、Worktree 或其他可用环境继承或受主任务环境约束通常不承担独立写入工作适合时长几十分钟到数天以上几分钟到一轮复杂任务几十秒到几分钟适合目标可独立验收的完整工作线主任务内部的并行子问题不值得污染主上下文的小问题人的角色管理任务组合与关键决策主要验收主任务综合结果获取一个即时答案判断标准可以非常简单如果一项工作值得在侧边栏拥有自己的名字、上下文、状态和后续行动它更像独立任务如果它只需要为当前主任务返回一份材料它更像 subagent。5 - 为什么要建立主对话控制面同时打开多个任务并不自动产生并行效率。没有主控关系时多对话很容易变成四份重复研究、四种互相矛盾的口径以及四个都在等待用户补背景的问题。主对话的价值主要体现在四个方面。5.1 - 把“同时运行”变成“有边界地并行”并行成立的前提是工作线相对独立。主对话需要先识别依赖关系哪些任务现在就能开始哪些任务必须等待上游结论哪些任务只读哪些任务会改文件哪些任务可以失败而不影响全局哪些结果必须统一口径后才能继续。如果任务 B 的输入完全依赖任务 A 的结论就不应该为了“看起来并发”而同时启动。真正有效的编排是让独立部分并行让依赖部分按阶段串行。5.2 - 保护主上下文一个复杂项目会产生大量搜索记录、测试日志、失败尝试和临时假设。全部堆进一个对话会让真正重要的决策被中间噪声淹没。独立任务可以承载细节主对话只保留已确认事实仍待验证的假设关键证据路径已作出的决定及其理由下一步需要人的判断。这样做不是为了缩短所有输出而是为了让主上下文始终保持可决策状态。5.3 - 让工作拥有可恢复性独立任务有自己的历史。即使主对话正在处理别的事情也可以稍后回到某条工作线继续推进。只要任务包和状态回执完整项目不需要依赖某个人记住所有细节。5.4 - 将不同风险放进不同权限边界资料研究可以只读方案比较可以禁止改文件实现任务可以进入独立 Worktree外部发送、生产发布和不可逆操作则继续保留人工确认。这比让一个拥有广泛权限的任务包办所有工作更容易审计也更容易在出现偏差时止损。6 - 主对话编排的三层结构6.1 - 第一层控制面控制面就是主对话。它保存项目宪章和任务登记表并决定任务的创建、暂停、续写和结束。一份最小任务登记表可以长这样任务目标环境写入范围当前状态下一决策点A查清官方能力边界只读无进行中来源是否充分B形成三种方案独立任务无已完成选择方案C实现确认方案Worktreesrc/feature/**等待等方案确认D验证结果独立环境测试文件未启动等实现完成这里最重要的不是表格形式而是主对话必须知道每条线的目标、状态、权限和依赖。6.2 - 第二层任务面任务面由多个独立对话组成。每个任务只解决一个边界清楚的问题并拥有自己的任务包。好的独立任务应该满足单独完成也能产生可用价值成功标准不依赖模糊的主观感觉输入和输出接口清楚写入范围能够排他地分配即使失败也能说明失败在哪里以及下一步需要什么。6.3 - 第三层证据与结果面独立任务的最终回复不应只是“完成了”。它需要返回可被主对话检查的结构化回执包括状态完成、部分完成、阻塞或需要决策结论最重要的三到五点证据文件、链接、测试结果或可复现步骤变更改了哪些文件或生成了哪些产物风险还有什么没有验证建议主对话下一步应该做什么。主对话根据这些材料做整合而不是根据一句“我已经完成”直接宣布项目结束。6.4 - 控制面需要维护的“三本账”主对话想要长期稳定地协调多个独立任务不能只依赖聊天记忆。最少要维护三类结构化信息。第一本是决策账。它记录已经由人确认或由证据确定的结论包括决定时间、决定内容、采用理由、被放弃的方案以及什么条件变化时需要重新讨论。决策账解决的是“为什么今天不能重新走回已经否定的老路”。如果只留下最终选择而没有理由几天后新的任务很容易把旧方案重新包装一遍团队又要重复争论。第二本是任务账。它就是前面的任务登记表但还要记录任务输入版本、最近一次状态时间、当前阻塞、写入范围和负责人。任务账解决的是“谁正在做什么、依据哪一版背景、离完成还差什么”。当任务输出与主对话预期不一致时先检查它收到的任务包版本而不是立即认定任务执行错误。第三本是产物账。它记录每个有效产物的位置、用途、生成任务、验证状态和替代关系。产物可以是代码分支、报告、测试记录、图片、数据表或决策摘要。产物账解决的是“哪个文件才是最新可信版本”。没有产物账时多个任务经常分别生成名称相似的文件主对话最后只能靠修改时间猜测应该采用哪一个。这三本账不一定真的要做成三张表。小项目可以直接放在主对话的一个持续更新区块里长期项目则可以沉淀为项目文档。关键是让状态来自可检查的记录而不是依赖主对话在长上下文中“应该还记得”。7 - 从零搭建一个主对话控制台7.1 - 第一步先定义总目标而不是先创建任务主对话最开始应当写清总目标最终要交付什么。 成功标准怎样判断结果真的可用。 共同背景所有任务都必须知道的事实。 固定约束不能改变的范围、规范和权限。 人工门禁哪些动作必须由人确认。 最终负责人谁决定采纳、合并、发布或对外发送。如果总目标还没有说清创建更多任务只会更快地产生分歧。7.2 - 第二步绘制依赖关系把工作分成三类可以立即并行的任务必须等待上游结果的任务需要人判断后才能开始的任务。一个常见顺序是阶段一并行研究事实、风险和备选方案 阶段二主对话综合提交人确认方向 阶段三在隔离环境中实现或制作 阶段四独立验证、修正和最终验收7.3 - 第三步选择 Create 还是 Fork使用新建独立任务的情况需要干净上下文工作与主对话历史关系较弱希望严格控制输入避免继承无关讨论需要从一个标准任务包开始。使用 Fork 的情况两条路线必须共享已经形成的长背景希望从同一个稳定决策点分别探索方案 A 和 B保留来源历史比重新整理任务包更经济。即使使用 Fork也建议在第一条消息中写明新任务的独立目标和停止条件。共享历史不等于共享未来方向。7.4 - 第四步选择 Local 还是 Worktree只读分析通常不需要独立 Worktree。涉及写代码、改配置或生成可能重名的文件时应优先考虑隔离。场景推荐环境只读搜索、资料研究当前项目或 projectless 独立任务只读代码审查当前项目只读权限单一写任务、没有其他并行修改Local 可用但仍需检查工作区多个并行代码任务每个任务使用独立 Worktree需要最后在常用 IDE 验证Worktree 完成后 Handoff 到 Local7.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 - 真正要建立的是任务操作系统“一个主对话控制几个子对话”听起来像一个界面技巧但它背后改变的是工作组织方式。过去我们往往把一个项目塞进一个长对话期待它从理解背景一路做到最终交付。新的方式是把项目拆成多个拥有清晰输入输出的独立任务再用一个主对话维护共同目标、状态和决策。这带来三个变化人从逐步盯执行转向设计任务边界和验收结果Codex 从单线程助手变成多个可恢复任务组成的工作组合上下文从聊天历史变成可以显式传递、更新和审计的任务资产。但不要误解这种能力。多个任务不会自动形成一个可靠系统。真正决定质量的仍然是任务是否拆得合理、上下文是否完整、写入是否隔离、证据是否充分以及人有没有在关键节点做出判断。最值得记住的一句话是独立任务负责把工作向前推进主对话负责让所有推进仍然指向同一个目标人负责最终的判断和责任。感谢各位大佬支持互三啦
