Codex 高级工作流：Subagent、Worktree、多模型路由
上篇你学会了 Codex 的基础用法。这篇讲高级工作流------让 Codex 同时处理多个任务、在隔离环境中安全执行、以及把 Codex 和 Claude Code 桥接起来协同工作。
Subagent：并行任务分解
原理
Codex 的 Subagent 机制和 oh-my-claudecode 的 Team Mode 类似，但更轻量：
主 Codex 实例（Orchestrator）
│
├── Subagent 1 → 独立任务 A → 独立 Worktree → 独立上下文
├── Subagent 2 → 独立任务 B → 独立 Worktree → 独立上下文
└── Subagent 3 → 独立任务 C → 独立 Worktree → 独立上下文
每个 Subagent：
- 有自己的上下文窗口（互不污染）
- 在自己的 Git Worktree 中工作
- 完成后结果 merge 回主分支
- 主 Codex 负责汇总和冲突解决实战：用 Subagent 重构一个模块
> /goal 重构用户模块，同时做三件事：
1. 数据库层从 SQLAlchemy 同步改异步
2. API 层加上统一的错误处理和分页
3. 写完整的集成测试
Codex 自动拆分：
Orchestrator: 分析任务，发现三个子任务互相独立
├── Subagent 1: 负责数据库层改造（models.py, database.py）
│ 模型: gpt-5.3-codex
│ 隔离: Worktree /tmp/codex-subagent-1
│
├── Subagent 2: 负责 API 层改造（routes.py, middleware.py）
│ 模型: gpt-5.3-codex
│ 隔离: Worktree /tmp/codex-subagent-2
│
└── Subagent 3: 负责测试编写（tests/）
模型: codex-mini（测试模板化程度高，用便宜模型即可）
隔离: Worktree /tmp/codex-subagent-3
执行过程：
- 三个 Subagent 同时开始
- Subagent 1 改了 models.py → API 的字段名变了
- Orchestrator 检测到冲突 → 通知 Subagent 2 更新字段引用
- Subagent 2 自动修复 → 继续
- Subagent 3 在另外两个完成后，基于最新代码跑测试
最终：
三个 Worktree 的改动合并到主分支
一个 PR 包含全部改动什么时候用 Subagent
✅ 用 Subagent：
- 3+ 个独立任务可以并行
- 不同任务互不依赖（或依赖关系明确）
- 总改动文件 > 10 个（一个人做太久）
❌ 不用 Subagent：
- 只有一个任务（用普通模式）
- 任务之间有强依赖（串行更可控）
- 改动文件 < 5 个（Subagent 的 overhead 不值得）Git Worktree 隔离并发
为什么需要 Worktree
Codex 和 Claude Code 都有一个共同问题：多个任务同时执行时，文件冲突。
没有 Worktree：
Agent 1 改 models.py → Agent 2 同时改 models.py → 冲突
→ 后保存的覆盖先保存的
→ 或者 git merge 时产生冲突，需要手动解决
有 Worktree：
Agent 1 在 Worktree A 中改 → 改完 → merge 回主分支
Agent 2 在 Worktree B 中改 → 改完 → merge 回主分支
→ 有冲突时 git 正常提示，Agent 自己解决
→ 不会互相覆盖Codex 的 Worktree 机制
bash
# Codex 创建 Subagent 时自动创建 Worktree
# 你也可以手动创建工作隔离的任务
# 列出当前活跃的 Worktree
> /worktree list
# 输出：
# main /home/user/project (主工作区)
# subagent-1 /tmp/codex-wt-abc123 (Subagent 1: 数据库改造)
# subagent-2 /tmp/codex-wt-def456 (Subagent 2: API 改造)每个 Worktree 互不影响，Subagent 之间的文件修改完全隔离。这是多 Agent 并行安全性的基础设施。
/goal 长任务持久化
/goal 是 Codex 最强大的功能之一：你下一个目标，关掉电脑，第二天回来看结果。
/goal 的生命周期
1. 你: > /goal 重构整个支付模块，支持微信支付 + 支付宝
2. Codex:
[生成计划]
- 预计 45 分钟
- 拆分为 12 个子任务
- 3 个 Subagent 并行
开始执行...
3. 你关了电脑去开会
4. Codex 在后台（或下次启动时继续）：
✅ 1/12: 创建支付接口抽象层
✅ 2/12: 实现微信支付
⚠️ 3/12: 实现支付宝 → 遇到沙箱环境问题，跳过
✅ 4/12: 更新订单状态机
...
❌ 12/12: E2E 测试 → 依赖沙箱环境
5. 你回来：
> /status
Codex 输出：
┌─────────────────────────────────────────┐
│ /goal: 重构支付模块 │
│ 进度: 11/12 ✅ | 1 个阻塞 ❌ │
│ 耗时: 38 分钟 │
│ 已完成: 微信支付、订单状态机、退款流程... │
│ 阻塞: 支付宝集成 → 需要沙箱环境凭证 │
│ 下一步: 提供支付宝沙箱 AppID 后继续 │
└─────────────────────────────────────────┘/goal 的持久化能力
/goal 执行中断后能自动恢复，因为它把执行状态持久化到了 .codex/goals/ 目录：
.codex/goals/
├── goal-20260604-refactor-payment/
│ ├── plan.md # 执行计划
│ ├── progress.json # 进度跟踪（哪些完成了、哪些失败了）
│ ├── context.tar.gz # 上下文快照（恢复时用）
│ └── results/ # 中间产出
└── .../goal 的最佳用法
✅ 适合 /goal：
- 明确、可量化结果的任务（"重构 X 模块"、"给所有 API 加测试"）
- 预计时间 > 30 分钟
- 你不需要实时参与决策
- 可以在晚上或周末跑
❌ 不适合 /goal：
- 需要你频繁决策的任务（"设计一个新的架构"）
- 创造性的工作（"给首页设计一个新的交互"）
- 预计时间 < 10 分钟（overhead 不值得）codex-plugin-cc：从 Claude Code 调用 Codex
这是社区开发的一个桥接工具，让 Claude Code 能"雇佣"Codex 做子任务：
codex-plugin-cc 的定位：
你不是在 Claude Code 和 Codex 之间二选一。
你是用 Claude Code 做主控，
把适合 Codex 的任务"外包"给它。
安装：
claude plugin install @community/codex-plugin-cc
使用：
在 Claude Code 中：
👤 "/codex-plan 设计用户权限系统的架构"
Claude Code 调用 Codex 的 /plan 生成计划
→ Codex 返回计划
→ Claude Code 把计划展示给你
→ 你确认后，Claude Code 自己执行协同流水线
┌─────────────────────────────────────────────────────┐
│ Claude Code（主控） │
│ │
│ 收到需求："重构用户认证系统" │
│ │ │
│ ├─→ 调用 Codex /plan │
│ │ 生成详细执行计划（8 个步骤） │
│ │ │
│ ├─→ 步骤 1-3：简单 CRUD 重构 │
│ │ Claude Code 自己快速完成 │
│ │ │
│ ├─→ 步骤 4-6：复杂的安全逻辑 │
│ │ 调用 Codex /goal 外包 │
│ │ "这 3 步涉及 OAuth2.0 流程，让 Codex 来做" │
│ │ │
│ ├─→ 步骤 7-8：测试 + 文档 │
│ │ Claude Code + Skills 完成 │
│ │ │
│ └─→ /review 最终审查全部改动 │
│ │
└─────────────────────────────────────────────────────┘什么时候该外包给 Codex
外包给 Codex 的信号：
├── 任务涉及复杂的条件分支和边界情况
├── 需要严格的"先计划后执行"流程
├── 你担心 Claude Code "太激进"会搞砸
└── 长任务，想挂后台不管
留在 Claude Code 的信号：
├── 快速迭代改 UI（描述→生成→看→改循环）
├── 需要 Skills 加持的任务（code-review、deploy）
└── 任务很简单，外包的 overhead 不值得Read → Plan → Edit → Test → Review 循环
Codex 内置了一套完整的开发循环。理解这个循环是高效使用 Codex 的关键：
┌──────────────────────────────────────────────────┐
│ │
│ Read ──→ Plan ──→ Edit ──→ Test ──→ Review │
│ ↑ │ │
│ └──────────── 发现问题，循环 ───────────┘ │
│ │
└──────────────────────────────────────────────────┘
Read：
不是"等你说需求"，而是 Codex 主动读代码库。
理解现有模式、依赖关系、代码风格。
Codex 读代码的时间通常占整个任务的 20-30%。
这不是浪费------它是在"理解上下文"。
Plan：
/plan 或 /goal 内置的计划阶段。
输出：执行步骤 + 影响范围 + 风险点 + 预估。
计划阶段是 Codex "先想再做"哲学的集中体现。
Edit：
按计划执行代码改动。
每次只改计划中当前步骤的内容（不会跳步或跨步）。
编辑过程中如果发现计划有问题，暂停并询问。
Test：
每完成一步，自动运行相关测试。
如果测试失败 → 自动修复 → 再测 → 直到通过（最多 3 次）。
如果没有测试 → 提示"这一步缺少测试覆盖，要不要我写"。
Review：
全部步骤完成后，自动 /review 审查所有改动。
输出审查报告。
如果有问题 → 回到 Edit 修复。把这个循环变成你的工作习惯
你不需要记住步骤。只需要做三件事：
1. 开始时：给一个清晰的描述
→ Codex 自动走 Read → Plan
2. 执行中：确认计划，让它跑
→ Codex 自动走 Edit → Test
3. 结束时：看一眼 Review 报告
→ Codex 自动走 Review
你的角色从"程序员"变成"验收者"。任务复杂度渐进策略
这是使用 Codex 最重要的心智模型：
不要一次给一个"大任务"。
把大任务拆成小任务，从简单到复杂渐进。
❌ 错误姿势：
> 帮我重构整个后端，从 REST 改成 GraphQL
→ 涉及 50+ 文件
→ /plan 生成的计划会让你眼花缭乱
→ 执行中会有大量你没想到的问题
→ 最后发现改动的范围远远超出预期
✅ 正确姿势：
第一步：
> 分析一下从 REST 到 GraphQL 需要改哪些文件，按影响范围排序
第二步：
> 好，先做最小影响的：给 schema.py 加上 GraphQL types 定义
第三步：
> 验证通过。把 users 模块的 REST 接口改成 GraphQL resolvers
第四步：
> 验证通过。继续 orders 模块...复杂度阶梯
复杂度 1：单文件修改（改一个函数、加一个接口）
→ 直接用 Claude Code 或 Codex 普通模式
→ 不需要 /plan
复杂度 2：2-5 个文件联动（加一个新功能需要改几个文件）
→ Codex /plan → 确认 → 执行
→ 或 Claude Code 分步描述
复杂度 3：5-15 个文件，涉及架构调整
→ Codex /goal
→ 拆成 3-5 个 Subagent 并行
复杂度 4：15+ 个文件，跨模块重构
→ Codex /goal + 分阶段执行
→ 每个阶段验收后再下一阶段
→ 不要想一次全做完Token 成本优化
Codex 的成本构成
每次会话的成本 = 输入 Token + 输出 Token
输入（最花钱）：
├── 系统提示词（Codex 内置，~3000 Token）------ 固定开销
├── AGENTS.md ------ 建议 < 2000 Token
├── MCP Tool 描述 ------ 启用 Tool Search 后降到 ~500 Token
├── 会话上下文 ------ 你说了什么 + AI 读了什么文件
└── 计划文档 ------ (/goal 的 plan.md 会持续在上下文中)
输出（相对便宜）：
├── AI 生成的代码
└── AI 的解释和回复省钱 4 招
bash
# 1. 任务分级用不同模型
简单任务 → codex-mini（成本是 gpt-5.5 的 1/20）
日常编码 → gpt-5.3-codex
复杂架构 → gpt-5.5
# 2. 一个任务一个会话，做完就 /clear
# 不要让多个任务的上下文混在一起，每个都占着 Token
# 3. AGENTS.md 写短一点
# 不是写得越多越好。2000 Token 以内的 AGENTS.md 效果最好
# 4. 用 /compact 或 /clear 清理上下文
# 上下文超过 80% 就要清，别等到满了再处理Codex 两部曲总结
上篇（第 16 篇）：Codex 基础
→ 安装 + /init + 核心命令 + Permission Profiles
→ 模型选择 + Appshots + 与 Claude Code 体验对比
下篇（本篇）：Codex 高级工作流
→ Subagent 并行 + Worktree 隔离
→ /goal 长任务 + codex-plugin-cc 桥接
→ Read→Plan→Edit→Test→Review 循环
→ 复杂度渐进 + Token 成本优化