TL;DR： 简单来说：小改动用串行，独立任务走并行，大功能上 SDD。选对模式，效率能差好几倍。

一、为什么需要理解调度模式

用 Codex 干活，最常碰到的场景是什么？大概率是这种：“我给了它三件事，结果它一件一件慢慢做，做到第二件就把第一件忘了。” 或者 “这个功能涉及六个文件，它改到一半，上下文窗口就爆了。”

这些问题，归根结底，都是调度模式选错了源头。

Codex 本质上是一个 agent，它的上下文窗口有限，串行处理是默认行为。当你需要它处理多个任务或完成一个复杂功能时，主动选择调度模式，才是效率的关键。

这篇文章会覆盖三种模式：串行（默认）、并行（dispatching parallel agents）、SDD（subagent-driven development）。每种模式都会给出具体的使用方法和完整示例，看完就能上手。

二、三种模式速览

决策流程图

三、串行模式（默认）

3.1 什么是串行模式

串行模式是 Codex 的默认行为：你给它任务，它按顺序一件一件做。所有操作共享同一个上下文窗口。

你什么都不用做，正常说话就是串行模式。

3.2 适用场景

• 任务之间有先后依赖（先查代码，再改代码，再跑测试）
• 单一功能开发，改动范围小（1-3 个文件）
• 探索性工作（不确定要做什么，需要边看边做）
• 简单的批量操作（重命名文件、批量添加注释）

3.3 使用方法

直接说，不需要任何特殊语法：

帮我把 src/tools/send_message.py 中的 print() 全部替换成 logging.info()

读一下 src/mcp_server.py，找到处理超时的那个函数，把超时时间从 30s 改成 60s

先跑一遍 ruff check src/，然后把所有 lint 报错修掉

3.4 完整示例

场景： 重构 send_message.py，提取公共方法。

你的指令：

帮我重构 src/tools/send_message.py：
1. 把重复的 HTTP 请求逻辑提取成 _make_request() 方法
2. 给所有公开函数加上类型注解
3. 跑一遍 pytest 确保没改坏

Codex 的执行过程：

Step 1: 读取 src/tools/send_message.py，分析代码结构
Step 2: 识别重复的 HTTP 请求逻辑
Step 3: 提取 _make_request() 方法
Step 4: 替换原有重复代码
Step 5: 添加类型注解
Step 6: 运行 pytest 验证

所有步骤在同一个上下文中完成，Codex 能看到每一步的结果。

3.5 串行的局限

四、并行模式（重点）

4.1 核心机制

并行模式的核心机制说起来其实不复杂：Controller 作为 coordinator，同时派发多个 subagent，每个 subagent 处理一个独立的任务域。它们在同一个时间窗口内并发执行，最后由 Controller 统一整合所有结果。

4.2 并行的硬性条件

不是所有任务都能并行，得同时满足以下几个条件：

简单判断法： 如果你能把每个任务分配给不同的人在不同电脑上做，那就能并行。

4.3 触发方式

方式一：显式标注"并行"

并行处理以下任务：
1. 重构 src/tools/send_message.py，提取公共方法
2. 给 src/tools/get_contacts.py 补全单元测试（覆盖率 > 80%）
3. 更新 README.md 中的 API 文档部分

方式二：用自然语言描述独立性

有三件事要做，它们互不影响，你看着并行搞：
- send_message.py 的性能优化
- get_contacts.py 的测试补全
- 文档更新

方式三：让 Controller 自己判断

帮我做这几件事：
1. xxx
2. xxx
3. xxx

如果你不加"并行"，Controller 默认串行执行。但如果你列出的任务明显独立（改不同文件），Controller 可能会主动提议并行，问你一句"这几个任务互不影响，要并行处理吗？"

4.4 完整示例

场景： 项目需要做三件独立的事。

你的指令：

并行处理：
1. src/tools/send_message.py：把 print() 替换成 logging，统一日志格式
2. tests/test_get_contacts.py：补全缺失的边界测试用例
3. docs/api.md：根据当前代码更新 API 文档

Codex 的内部调度过程：

[Controller] 分析任务依赖关系：
  - Task 1 改 src/tools/send_message.py
  - Task 2 改 tests/test_get_contacts.py
  - Task 3 改 docs/api.md
  → 三个文件无交集，可以并行

[Controller] 同时派发 3 个 subagent：
  ┌─ Subagent A: "重构 send_message.py 日志"
  ├─ Subagent B: "补全 get_contacts 测试"
  └─ Subagent C: "更新 API 文档"

[Subagent A] 完成：替换了 12 处 print → logging，添加了统一 formatter
[Subagent B] 完成：新增 8 个测试用例，覆盖率 78% → 89%
[Subagent C] 完成：更新了 3 个 API 的参数说明，添加了示例

[Controller] 整合检查：
  - git diff --name-only：确认没有文件被多个 agent 同时修改 ✓
  - 运行 pytest：全部通过 ✓
  - 运行 ruff check：无新增 lint 错误 ✓

结果： 三个任务在约等于一个任务的时间内完成。

4.5 并行的常见错误

错误 1：任务边界模糊

并行处理：
1. 重构 src/tools/ 下所有模块
2. 给 src/tools/ 添加单元测试

问题：两个任务都涉及 src/tools/，改同一批文件会冲突。

修正：

并行处理：
1. 重构 src/tools/send_message.py（只改这个文件）
2. 给 src/tools/get_contacts.py 添加单元测试（只改测试文件）

错误 2：隐藏依赖

并行处理：
1. 修改 config.yaml 中的数据库连接配置
2. 更新所有读取 config.yaml 的模块

问题：Task 2 依赖 Task 1 改了什么配置。

修正：先做 Task 1，再做 Task 2（串行）。

错误 3：粒度太细

并行处理：
1. 把第 23 行的变量名改成 request_timeout
2. 把第 45 行的变量名改成 max_retries

问题：改同一个文件，而且粒度太细没必要开 subagent。

修正：直接串行，一个 apply_patch 就搞定。

4.6 并行的最佳实践

4.7 工具级并行（自动）

除了任务级并行，还有一种更轻量的并行：工具调用级并行。这是Controller默认就做的，不需要你操心。

比如你让它读 5 个文件，它不会一个一个读，而是 5 个 cat 同时发出。你让它跑 3 个搜索，3 个 rg 同时发出。

# 它会自动并行执行这些操作：
读取 src/tools/send_message.py    ┐
读取 src/tools/get_contacts.py    ├─ 同时发出，同时返回
读取 src/tools/create_group.py   ┘

这种并行对你来说是透明的，不需要特别操作。

五、SDD 模式（重点）

5.1 什么是 SDD

SDD（Subagent-Driven Development）是 Codex 的重量级开发模式。它不是简单的"帮我写代码"，而是一套完整的开发流程管理系统。

核心思想是：Controller 扮演项目经理的角色，把功能拆成多个 task，每个 task 派一个 implementer subagent 去实现，做完再派一个 reviewer subagent 来审查，有问题打回修复，最后做全分支 review。

5.2 SDD 的五个角色

5.3 SDD 的完整流程（六步）

Step 1：写 Plan

Controller 把你的需求拆成独立 task，每个 task 写清楚：

• 做什么（具体要求）
• 验收标准（怎么算做完）
• 涉及的文件
• 依赖关系

Plan 写到文件中（如 docs/plans/feature-plan.md），作为后续所有 subagent 的需求来源。

Step 2：创建隔离工作区

建一个 git worktree + feature branch，所有改动在隔离分支上做，不污染 main。

Step 3：逐 Task 派发

对每个 task，controller 执行：

1. task-brief 脚本提取 task 描述 → brief 文件
2. 派发 implementer subagent（附 brief 路径 + 上下文）
3. implementer 实现代码、写测试、提交
4. implementer 写 report → report 文件
5. review-package 脚本生成 diff 文件
6. 派发 reviewer subagent（附 brief + report + diff）
7. reviewer 通过 → 标记 task 完成
8. reviewer 发现问题 → 派发 fix subagent → 重新 review

Step 4：全分支 Review

所有 task 完成后，用 review-package 生成整条分支的 diff，派一个 final reviewer 做全量审查。

Step 5：收尾

用 finishing-a-development-branch 决定是 merge 到 main 还是提 PR。

Step 6：进度追踪

整个过程有一个 .superpowers/sdd/progress.md ledger 文件，记录每个 task 的状态和 commit SHA。即使会话中断、上下文压缩，controller 也能从 ledger 恢复，不会重复做已完成的任务。

5.4 触发方式

方式一：明确说"用 SDD"

用 SDD 做：给 WeChat MCP server 加群聊管理功能，包括建群、拉人、踢人、发群公告。
先写 plan，确认后再执行。

"先写 plan"意味着你想看一下任务拆分是否合理，确认后再让它跑。

方式二：全自动模式

用 SDD 做：给 WeChat MCP server 加群聊管理功能（建群、拉人、踢人、发群公告）。
plan 你自己判断，不用给我确认，直接跑。

这样全程自动执行，只在遇到真正需要你决定的问题才打断你。

方式三：分阶段控制

第一步：用 writing-plans 帮我写一个群聊管理功能的 plan。

看完 plan 后：

第二步：用 SDD 执行这个 plan。

5.5 完整示例

场景： 给 WeChat MCP server 添加好友管理功能。

你的指令：

用 SDD 做：给 WeChat MCP server 加三个好友管理工具：
1. search_contact - 按关键字搜索联系人
2. add_friend - 发送好友请求
3. accept_friend - 接受好友请求

先给我看 plan。

Step 1：Controller 生成的 Plan

# Plan: 好友管理功能

## 全局约束
- Python 3.10+，Ruff 格式化，类型注解
- 每个工具必须有输入校验
- 测试覆盖率 > 80%
- 日志用 logging 模块，不用 print

## Task 1: search_contact 工具
- 创建 src/tools/search_contact.py
- 实现关键字搜索，支持姓名和备注名
- 参数：keyword (str), limit (int, 默认 20)
- 返回：匹配的联系人列表
- 测试：tests/test_search_contact.py
- 验收：正常搜索 + 空结果 + 特殊字符搜索

## Task 2: add_friend 工具
- 创建 src/tools/add_friend.py
- 实现发送好友请求
- 参数：contact_id (str), message (str, 可选)
- 返回：请求状态
- 测试：tests/test_add_friend.py
- 验收：正常发送 + 重复请求 + 无效 ID

## Task 3: accept_friend 工具
- 创建 src/tools/accept_friend.py
- 实现接受好友请求
- 参数：request_id (str)
- 返回：接受状态
- 测试：tests/test_accept_friend.py
- 验收：正常接受 + 已处理请求 + 无效 ID

## Task 4: 注册工具 + 集成测试
- 在 src/mcp_server.py 中注册三个新工具
- 添加集成测试验证工具注册和调用流程

你说 “plan 没问题，开始执行” 后：

Step 2：Controller 创建 worktree

git worktree add ../feature-friend-management -b feat/friend-management

Step 3：逐 Task 执行

======= Task 1: search_contact =======

[Controller] 提取 task brief → .superpowers/sdd/task-1-brief.md
[Controller] 派发 implementer（选标准模型）

  [Implementer] 读取 brief，理解需求
  [Implementer] 写测试（TDD）
  [Implementer] 实现 search_contact 函数
  [Implementer] 跑 pytest: 6/6 通过
  [Implementer] 提交 commit: a1b2c3d
  [Implementer] 写 report → .superpowers/sdd/task-1-report.md
  [Implementer] 状态: DONE

[Controller] review-package → .superpowers/sdd/task-1-review.diff
[Controller] 派发 reviewer

  [Reviewer] 需求符合度: 全部满足
  [Reviewer] 代码质量: 通过
  [Reviewer] 发现: keyword 参数未做长度校验 (Minor)

[Controller] Minor 问题，记录到 ledger，最后统一处理

======= Task 2: add_friend =======

[Controller] 提取 task brief → .superpowers/sdd/task-2-brief.md
[Controller] 派发 implementer

  [Implementer] 实现 add_friend 函数
  [Implementer] 跑 pytest: 5/5 通过
  [Implementer] 提交 commit: d4e5f6a
  [Implementer] 状态: DONE

[Controller] 派发 reviewer

  [Reviewer] 需求符合度: 不通过
  [Reviewer] 问题: 缺少重复请求检测, spec 要求返回明确状态 (Critical)

[Controller] 派发 fix subagent

  [Fixer] 添加重复请求检测逻辑
  [Fixer] 跑 pytest: 6/6 通过
  [Fixer] 提交 commit: g7h8i9j

[Controller] 重新派发 reviewer

  [Reviewer] 需求符合度: 全部满足
  [Reviewer] 代码质量: 通过

======= Task 3: accept_friend =======
... (类似流程)

======= Task 4: 注册 + 集成测试 =======
... (类似流程)

Step 4：全分支 Review

[Controller] review-package merge-base..HEAD → 全分支 diff
[Controller] 派发 final reviewer（用最强模型）

  [Final Reviewer] 三个工具的代码风格一致 ✓
  [Final Reviewer] 所有输入都有校验 ✓
  [Final Reviewer] Task 1 的 keyword 长度校验 (Minor) → 需要修复
  [Final Reviewer] 集成测试覆盖了主流程 ✓

[Controller] 派发一个 fix subagent 修复所有 minor 问题
[Controller] 重新跑全量测试 ✓

Step 5：收尾

[Controller] 功能开发完成，所有测试通过
[Controller] 选项：
  1. 直接 merge 到 main
  2. 推远程分支，提 PR

Step 6：Ledger 记录

# SDD Progress Ledger

Task 1: complete (commits a1b2c3d, review clean, minor: keyword length)
Task 2: complete (commits d4e5f6a..g7h8i9j, review clean after fix)
Task 3: complete (commits k1l2m3n, review clean)
Task 4: complete (commits o4p5q6r, review clean)
Final review: complete (commits s7t8u9v, minor fix applied)

5.6 SDD 的关键设计决策

为什么 implementer 之间是串行的？

因为多个 task 可能改同一个文件（比如都要在 mcp_server.py 注册工具）。如果并行，后一个 implementer 的改动会覆盖前一个。串行保证每个 implementer 看到的是最新代码。

为什么每个 subagent 上下文隔离？

如果 implementer 共享上下文，做到 Task 3 时它已经被 Task 1 和 Task 2 的大量细节淹没了。隔离上下文意味着每个 subagent 只看到自己需要的信息（brief + 相关代码），效率更高，犯错更少。

为什么要 review 而不是直接信任 implementer？

Implementer 是"球员"，reviewer 是"裁判"。球员自己觉得自己踢得好不算数，需要独立的裁判来判断。而且 reviewer 看到的是 diff 而不是全量代码，更容易发现问题。

5.7 SDD 的 Implementer 状态机

每个 implementer 完成后会汇报四种状态之一：

5.8 SDD 的 Model Selection 策略

不是所有 subagent 都需要用最贵的模型。Controller 会根据任务复杂度选择：

这能显著降低成本，同时保证关键环节的质量。

六、模式选择决策树

拿不准的时候，按这个流程来判断：

速查：什么时候用什么

七、总结与最佳实践

核心原则

1. 默认串行 – 大多数任务串行就够用
2. 独立任务用并行 – 关键词是"并行"或"互不影响"
3. 大功能用 SDD – 关键词是"用 SDD"
4. 文件冲突是最大风险 – 无论哪种模式，确保任务边界不重叠
5. 粒度适中 – 太细没必要拆 subagent，太粗拆不开

成本 vs 质量权衡

串行：低成本，低质量保障 → 适合日常小改动
并行：中成本，低质量保障 → 适合批量独立任务
SDD：高成本，高质量保障 → 适合正式功能开发

话说回来，不是所有任务都需要 SDD。一个改三行代码的 bugfix 用 SDD，那是杀鸡用牛刀。但一个涉及 10 个文件、需要完整测试覆盖的新功能，SDD 的额外成本是值得的。

常见误区