多开并行：线程、派生、工作树与 Subagents 调度指南

Codex 最大的优势是"多开"，但多开之前得先会"调度"：什么时候留在当前线程、什么时候开新对话、什么时候派生、什么时候用工作树、什么时候派 Subagents——选错了，轻则返工，重则几个 Agent 互相打架。

这课三源合一：@thinkszyg 的线程调度指南给"五选一口诀"和完整实操案例；OpenAI 官方文档给 subagent 的权威配置手册；@php_martin 的《Codex 全攻略 2026》给"串行任务"调度哲学和 6 个并行项目实战。

以下来自 @thinkszyg（只讲桌面版 App）。背下这句口诀：

• 同一个问题还在推进 → 继续当前线程
• 想试另一条路线、但要继承前面的判断 → 派生
• 怕把当前项目改乱 → 新工作树
• 想让 Codex 忘掉前面的判断、重新看 → 新对话
• 信息太多、要分头查证 → Subagents

当前线程（@thinkszyg）：像"持续工作的任务现场"——里面有你已经做过的判断、执行过的命令、失败过的尝试。任务指令记四个关键词：目标、上下文、限制、完成标准。线程太长时，先让它总结"已确认的事实 / 已排除的原因 / 下一步最小验证动作"，不要扩大范围。

新对话：同一项目换个"新脑子"——能读项目文件，但不继承之前的讨论。适用两种情况：全新任务；或主线程判断已经固化，需要干净的第二意见（提示词里写"不要参考任何历史结论"）。

派生到本地：继承上下文，但没有文件隔离——还是在当前目录干活。适合"同一问题换条路线、但改动不大"。大改就别派生了，直接上工作树。

新工作树（@thinkszyg）：同一 Git 仓库的独立工作目录。Codex 去"隔壁房间"折腾：方案好就看 diff 合回来，不行就整个丢掉，主目录毫发无损。

坑：新目录可能缺 node_modules、.env、没提交的临时文件，导致跑不起来。解法是用 Local environments 配置初始化命令（如 npm install、npm run build）和常用按钮（dev / test / lint / typecheck）。

Handoff：把线程在 Local 和 Worktree 之间"搬家"——把后台做的实验拿回当前目录验证。注意：.gitignore 忽略的文件不会自动跟过来。

@thinkszyg 的核心忠告：Subagents 先只读不写。主 Agent 负责判断和取舍，Subagents 负责探索、测试、分诊、审查。错误用法是把它们当多个程序员同时写代码——会互相打架。

正确示例：4 个 Subagent 分查前端请求流 / 后端查询 / 缓存策略 / 测试覆盖，每人输出结论 + 证据文件 + 风险等级 + 建议下一步，最后由主 Agent 定夺。

AGENTS.md 的用法：它是给新对话和工作树留的"项目地图"（项目说明 / 常用命令 / 工作规则 /完成标准）。@thinkszyg 提醒：越长越容易失效，只在 Codex 重复犯同一个错误时再补规则。

以下来自 @thinkszyg 的端到端实战——"搜索页卡顿"问题，三线分工一次看懂：

• ① 当前线程只读排查 → 输出 3 个可能原因 + 文件证据。
• ② 同线程做最小保守修复（防抖 + 去重，不碰数据库）。
• ③ 派生到新工作树试完整的性能优化方案。
• ④ Subagents 只读审查（安全 / 测试 / 可维护性三视角）。
• ⑤ 看 diff 决定合并哪部分。

这就是三线分工模型：主线保守修复 + 工作树大胆实验 + Subagents 只读审查。

最容易翻车的 6 个判断（@thinkszyg）：① 同一个问题反复开新对话（丢上下文）；② 大改放在 Local 做（没隔离）；③ 把派生当安全沙盒；④ Subagents 同时写代码；⑤ Worktree 跑不起来怪 Codex（其实是缺初始化）；⑥ 没有完成标准（永远"再改改"）。

以下来自 OpenAI 官方文档（learn.chatgpt.com），是 subagent 机制的权威参考。

为什么需要 subagent：即使上下文窗口很大，主聊天（放需求、约束、决策）被探索笔记、测试日志、堆栈、命令输出淹没后会变得不可靠——官方称之为 context pollution（上下文污染） 和 context rot（上下文腐烂）。subagent 把噪声工作搬离主线程，只返回摘要，不返回原始中间输出。

适用边界：从读密集型任务（探索、测试、分类、摘要）开始并行；写密集型并行要谨慎，多 agent 同时改代码会冲突、增加协调开销。

成本提醒：每个 subagent 都做自己的模型 + 工具调用，subagent 工作流比单 agent 跑法消耗更多 token。

模型选型（官方）：

• gpt-5.6：demanding 任务的起点，擅长模糊多步工作（规划、工具使用、验证、跟进大上下文）。
• gpt-5.6-terra：更快更便宜，适合轻量 subagent 工作（探索、读密集扫描、大文件评审）。
• gpt-5.6-luna：快速、范围窄，处理明确、可重复、高并发的工作。

推理强度 model_reasoning_effort：ultra（最深）/ max / xhigh（极 demanding）/ high（复杂逻辑追踪、评审/安全类）/ medium（默认平衡）/ low（简单任务求快）。强度越高越慢、越烧 token。

触发方式：直接指令（"spawn two agents""delegate this work in parallel"），或由 AGENTS.md / skill 触发。好 prompt 要讲清：如何分工、是否等齐所有 agent、返回什么样的摘要。官方示例：

复制Review this branch with parallel subagents. Spawn one subagent for security risks, one for test gaps, and one for maintainability. Wait for all three, then summarize the findings by category with file references.

自定义 agent（TOML 配置）：内置三个——default（通用兜底）、worker（执行/实现/修 bug）、explorer（读密集代码探索）。自定义 agent 是独立 TOML 文件：个人级放 ~/.codex/agents/，项目级放 .codex/agents/；每个文件必须定义 name、description、developer_instructions；可覆盖 model、model_reasoning_effort、sandbox_mode、mcp_servers、skills.config。同名自定义 agent 会覆盖内置的（比如自定义 explorer）。

全局设置 [agents]：agents.enabled（默认 true）、agents.max_concurrent_threads_per_session（并发上限）、agents.default_subagent_model、agents.default_subagent_reasoning_effort。

继承规则：subagent 继承当前沙箱策略和权限模式（委托前先在父 turn 选好 permission mode）；自定义文件里显式设置的 model / model_reasoning_effort 优先。

两个完整官方示例：① PR 评审三分工（pr_explorer 只探索不提修法 + reviewer 专注正确性/安全/缺失测试 + docs_researcher 用 docs MCP 核验 API，并发上限 8）；② 前端集成调试三分工（code_mapper 定位代码路径 + browser_debugger 用 Chrome DevTools MCP http://localhost:3000/mcp 复现并截图抓证据、不改代码 + ui_fixer 做最小改动）。

以下来自 @php_martin《Codex 全攻略 2026》。他的核心观点很扎心："当你的 AI 代理一个任务要跑 1-2 小时，你只能干等——这是 2026 年最贵的浪费。"

解法叫「串行任务」：AI 跑长任务时，你不再干等，而是同时调度 6 个项目并行推进——你负责发提示和调度，AI 们各自干活。这不是多线程，这是"你发完一个提示就切到下一个"。

6 个并行项目实战（@php_martin 端到端）：iOS 应用（Chorus App，Swift + Xcode 模拟器 + Supabase 经 MCP 连数据库）→ Web 落地页（Tally.so 表单收邮箱，Vercel 插件一键部署）→ 投资者 Deck（分叉聊天生成，导出 Canva 精修）→ 发布视频（Remotion 插件，时间线编辑、帧级控制、加 BGM）→ 社交媒体自动化（Typefully API 做成技能，每日自动推文）→ 应用图标（内置图像生成，一次生成 10 个无背景图标选最优）。

高级技巧：Steering（转向）——代理工作时直接插入新指令，不用等它跑完；分叉聊天——右键分叉到本地，基于现有上下文开新任务；迷你窗口——右键聊天独立成窗口，多任务时一眼看到谁跑完了；终端里跑 claude --dangerously-skip-permissions，在 Codex 界面内调用 Claude Code 做设计密集型任务（作者实测美化效果优于 Codex 内置模型）。

技能 vs 插件（最易混淆点，@php_martin 版）：技能 = 可重复使用的工作流包/配方（如"YouTube 转录分析技能"）；插件 = 可安装的扩展单元（如 Google Calendar 插件）。没官方插件的工具，可以让 Codex 写一个包装其 MCP 的技能。创建技能有可复制提示词：让 Codex"研究如何使用某 API 并快速创建一个技能"，把 API 密钥给它，技能会出现在"插件 > 技能"里，新会话用 @技能名 调用。

风险与边界（@php_martin）：只给 Codex 专用项目文件夹"完全访问"权限，并定期备份；技能用到的 API 密钥建议用只读/限制权限的；自动化先手动触发确认再设定时；MCP 服务器添加后要重启 Codex 才生效。

可复用检查清单：建项目文件夹 + 完全访问 → Markdown 任务清单 → 装插件（Google Calendar、Gmail、Remotion、Figma）→ 建技能 → 启动第一个代理任务 → 立刻切第二个（Steering）→ 分叉聊天做衍生任务 → 迷你窗口管理 → 定期检查反馈 → 自动化处理重复工作 → 部署上线。