TL;DR： 小活用串行，独立任务用并行，大功能用 SDD。选对模式，效率差 3-5 倍。
一、为什么需要理解调度模式
用 Codex 干活，最常见的问题是：“我给了它三件事，它怎么一件一件做，做到第二件就忘了第一件？” 或者 “这个功能涉及六个文件，它改到一半上下文就爆了。”
这些问题的根源都是调度模式选错了。
Codex 本质上是一个 agent，它的上下文窗口有限，串行处理是默认行为。当你需要它处理多个任务或完成一个复杂功能时，主动选择调度模式是效率的关键。
本文覆盖三种模式：串行（默认）、并行（dispatching parallel agents）、SDD（subagent-driven development），每种都有具体的使用方法和完整示例。
二、三种模式速览
| 维度 |
串行模式 |
并行模式 |
SDD 模式 |
| 适用场景 |
有依赖关系的任务链 |
2+ 个独立任务 |
一个大的多步骤功能 |
| 执行方式 |
顺序执行 |
多个 subagent 同时跑 |
逐 task 串行派发 |
| 上下文 |
共享同一会话 |
每个 agent 隔离 |
每个 subagent 隔离 |
| 质量门禁 |
无额外审查 |
无额外审查 |
每 task 有 reviewer + 最终全量 review |
| 文件冲突风险 |
低（顺序做） |
高（并行改文件） |
低（串行做） |
| 中断恢复 |
依赖会话上下文 |
无 |
ledger 文件支持断点续跑 |
| 成本 |
低 |
中 |
高（implementer + reviewer） |
| 你需要做的 |
直接说 |
标注"并行" |
给需求 + 说"用 SDD" |
决策流程图
三、串行模式（默认）
3.1 什么是串行模式
串行模式是 Codex 的默认行为：你给它任务，它按顺序一件一件做。所有操作共享同一个上下文窗口。
你不需要做任何特殊操作，正常说话就是串行。
3.2 适用场景
- 任务之间有先后依赖（先查代码，再改代码，再跑测试）
- 单一功能开发，改动范围小（1-3 个文件）
- 探索性工作（不确定要做什么，需要边看边做）
- 简单的批量操作（重命名文件、批量添加注释）
3.3 使用方法
直接说，不需要任何特殊语法：
|
1
|
帮我把 src/tools/send_message.py 中的 print() 全部替换成 logging.info()
|
|
1
|
读一下 src/mcp_server.py，找到处理超时的那个函数，把超时时间从 30s 改成 60s
|
|
1
|
先跑一遍 ruff check src/，然后把所有 lint 报错修掉
|
3.4 完整示例
场景： 重构 send_message.py，提取公共方法。
你的指令：
|
1
2
3
4
|
帮我重构 src/tools/send_message.py：
1. 把重复的 HTTP 请求逻辑提取成 _make_request() 方法
2. 给所有公开函数加上类型注解
3. 跑一遍 pytest 确保没改坏
|
Codex 的执行过程：
|
1
2
3
4
5
6
|
Step 1: 读取 src/tools/send_message.py，分析代码结构
Step 2: 识别重复的 HTTP 请求逻辑
Step 3: 提取 _make_request() 方法
Step 4: 替换原有重复代码
Step 5: 添加类型注解
Step 6: 运行 pytest 验证
|
所有步骤在同一个上下文中完成，Codex 能看到每一步的结果。
3.5 串行的局限
| 问题 |
原因 |
影响 |
| 上下文窗口耗尽 |
任务太多，前面的信息被挤出 |
后面的任务"忘了"前面的要求 |
| 效率低 |
顺序执行，无法利用并行能力 |
3 个独立任务花 3 倍时间 |
| 质量无保障 |
没有独立 review 环节 |
做完就算完，容易有遗漏 |
四、并行模式（重点）
4.1 核心机制
并行模式的本质是我（Codex）作为 controller，同时派发多个 subagent，每个 subagent 处理一个独立的任务域。它们在同一个时间窗口内并发执行，我最后整合所有结果。
4.2 并行的硬性条件
不是所有任务都能并行。必须同时满足以下所有条件：
| 条件 |
说明 |
违反后果 |
| 任务之间无数据依赖 |
B 不需要 A 的输出 |
B 拿到过时信息，做出错误修改 |
| 不改同一个文件 |
两个 agent 同时改 file.py |
后提交的覆盖先提交的 |
| 不改同一个配置 |
同时改 pyproject.toml |
合并冲突 |
| 边界清晰 |
每个任务的范围可以一句话描述 |
agent 越界，互相干扰 |
简单判断法： 如果你能把每个任务分配给不同的人在不同电脑上做，那就能并行。
4.3 触发方式
方式一：显式标注"并行"
|
1
2
3
4
|
并行处理以下任务：
1. 重构 src/tools/send_message.py，提取公共方法
2. 给 src/tools/get_contacts.py 补全单元测试（覆盖率 > 80%）
3. 更新 README.md 中的 API 文档部分
|
方式二：用自然语言描述独立性
|
1
2
3
4
|
有三件事要做，它们互不影响，你看着并行搞：
- send_message.py 的性能优化
- get_contacts.py 的测试补全
- 文档更新
|
方式三：让我自己判断
|
1
2
3
4
|
帮我做这几件事：
1. xxx
2. xxx
3. xxx
|
如果你不加"并行"，我默认串行执行。但如果你列出的任务明显独立（改不同文件），我可能会主动提议并行，问你一句"这几个任务互不影响，要并行处理吗？"
4.4 完整示例
场景： 项目需要做三件独立的事。
你的指令：
|
1
2
3
4
|
并行处理：
1. src/tools/send_message.py：把 print() 替换成 logging，统一日志格式
2. tests/test_get_contacts.py：补全缺失的边界测试用例
3. docs/api.md：根据当前代码更新 API 文档
|
Codex 的内部调度过程：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
[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
2
3
|
并行处理：
1. 重构 src/tools/ 下所有模块
2. 给 src/tools/ 添加单元测试
|
问题：两个任务都涉及 src/tools/，改同一批文件会冲突。
修正：
|
1
2
3
|
并行处理：
1. 重构 src/tools/send_message.py（只改这个文件）
2. 给 src/tools/get_contacts.py 添加单元测试（只改测试文件）
|
错误 2：隐藏依赖
|
1
2
3
|
并行处理：
1. 修改 config.yaml 中的数据库连接配置
2. 更新所有读取 config.yaml 的模块
|
问题：Task 2 依赖 Task 1 改了什么配置。
修正：先做 Task 1，再做 Task 2（串行）。
错误 3：粒度太细
|
1
2
3
|
并行处理：
1. 把第 23 行的变量名改成 request_timeout
2. 把第 45 行的变量名改成 max_retries
|
问题：改同一个文件，而且粒度太细没必要开 subagent。
修正：直接串行，一个 apply_patch 就搞定。
4.6 并行的最佳实践
| 实践 |
说明 |
| 每个任务指定文件范围 |
“只改 send_message.py” 比 “优化发送模块” 更安全 |
| 任务数 2-5 个 |
太少没必要并行，太多难以整合 |
| 任务粒度适中 |
一个独立文件/模块/子系统是一个好的粒度 |
| 完成后跑全量测试 |
即使每个 agent 都测过了，整合后也可能有意外 |
| 明确说"并行" |
一个关键词就够，不要让我猜 |
4.7 工具级并行（自动）
除了任务级并行，还有一种更轻量的并行：工具调用级并行。这是我默认就做的，不需要你操心。
比如你让我读 5 个文件，我不会一个一个读，而是 5 个 cat 同时发出。你让我跑 3 个搜索，3 个 rg 同时发出。
|
1
2
3
4
|
# 我会自动并行执行这些操作：
读取 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 的五个角色
| 角色 |
职责 |
由谁扮演 |
| Controller |
拆任务、派 subagent、整合结果、处理冲突 |
Codex 主会话 |
| Implementer |
实现单个 task 的代码、写测试、提交 |
Subagent（隔离上下文） |
| Reviewer |
审查 implementer 的代码，检查需求符合度 + 代码质量 |
Subagent（隔离上下文） |
| Fix Subagent |
修复 reviewer 发现的问题 |
Subagent（隔离上下文） |
| Final Reviewer |
对整条分支做全量审查 |
Subagent（用最强模型） |
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
2
3
4
5
6
7
8
|
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"
|
1
2
|
用 SDD 做：给 WeChat MCP server 加群聊管理功能，包括建群、拉人、踢人、发群公告。
先写 plan，确认后再执行。
|
"先写 plan"意味着你想看一下任务拆分是否合理，确认后再让我跑。
方式二：全自动模式
|
1
2
|
用 SDD 做：给 WeChat MCP server 加群聊管理功能（建群、拉人、踢人、发群公告）。
plan 你自己判断，不用给我确认，直接跑。
|
这样我全程自动执行，只在遇到真正需要你决定的问题才打断你。
方式三：分阶段控制
|
1
|
第一步：用 writing-plans 帮我写一个群聊管理功能的 plan。
|
看完 plan 后：
5.5 完整示例
场景： 给 WeChat MCP server 添加好友管理功能。
你的指令：
|
1
2
3
4
5
6
|
用 SDD 做：给 WeChat MCP server 加三个好友管理工具：
1. search_contact - 按关键字搜索联系人
2. add_friend - 发送好友请求
3. accept_friend - 接受好友请求
先给我看 plan。
|
Step 1：Controller 生成的 Plan
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
# 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
|
1
|
git worktree add ../feature-friend-management -b feat/friend-management
|
Step 3：逐 Task 执行
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
======= 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
|
1
2
3
4
5
6
7
8
9
10
|
[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：收尾
|
1
2
3
4
|
[Controller] 功能开发完成，所有测试通过
[Controller] 选项：
1. 直接 merge 到 main
2. 推远程分支，提 PR
|
Step 6：Ledger 记录
|
1
2
3
4
5
6
7
|
# 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 完成后会汇报四种状态之一：
| 状态 |
含义 |
Controller 的处理 |
| DONE |
全部完成，无疑问 |
直接进 review |
| DONE_WITH_CONCERNS |
完成但有疑虑 |
评估疑虑严重性，决定是进 review 还是先处理 |
| NEEDS_CONTEXT |
缺少信息 |
补充信息，重新派发 |
| BLOCKED |
无法完成 |
换更强的模型 / 拆更小的任务 / 问用户 |
5.8 SDD 的 Model Selection 策略
不是所有 subagent 都需要用最贵的模型。Controller 会根据任务复杂度选择：
| 任务类型 |
推荐模型 |
例子 |
| 机械实现（1-2 个文件，明确 spec） |
快速便宜模型 |
提取公共方法、添加日志 |
| 集成实现（多文件协调） |
标准模型 |
注册工具、连接模块 |
| 架构设计 / 最终 Review |
最强模型 |
全分支审查 |
这能显著降低成本，同时保证关键环节的质量。
六、模式选择决策树
当你不确定用哪个模式时，按这个流程判断：
速查：什么时候用什么
| 你说 |
实际使用的模式 |
| “帮我改一下 xxx” |
串行 |
| “先读代码再改” |
串行 |
| “并行处理这 3 件事” |
并行 |
| “这几件事互不影响，一起搞” |
并行 |
| “用 SDD 做 xxx 功能” |
SDD |
| “先写 plan 再执行” |
SDD（分阶段） |
| “用 writing-plans 写 plan” |
SDD 的第一步 |
七、总结与最佳实践
核心原则
- 默认串行 – 大多数任务串行就够用
- 独立任务用并行 – 关键词是"并行"或"互不影响"
- 大功能用 SDD – 关键词是"用 SDD"
- 文件冲突是最大风险 – 无论哪种模式，确保任务边界不重叠
- 粒度适中 – 太细没必要拆 subagent，太粗拆不开
成本 vs 质量权衡
|
1
2
3
|
串行：低成本，低质量保障 → 适合日常小改动
并行：中成本，低质量保障 → 适合批量独立任务
SDD：高成本，高质量保障 → 适合正式功能开发
|
不是所有任务都需要 SDD。一个改三行代码的 bugfix 用 SDD 是杀鸡用牛刀。但一个涉及 10 个文件、需要完整测试覆盖的新功能，SDD 的额外成本是值得的。
常见误区
| 误区 |
正确做法 |
| 所有任务都串行做 |
独立任务并行，效率翻倍 |
| 所有任务都想并行 |
有依赖的任务并行会出错 |
| 小改动也用 SDD |
SDD 的 overhead 对小任务不划算 |
| SDD 不写 plan 直接执行 |
Plan 是 SDD 的灵魂，没有 plan 的 SDD 就是高级串行 |
| 并行任务改同一批文件 |
确保每个任务的文件范围不重叠 |
