企业官网建设流程全解析

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 机制

# 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 招

# 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 成本优化

延伸阅读

• Codex CLI 官方文档
• codex-plugin-cc GitHub
• Git Worktree 文档