1. 从「能对话」到「能干活」：Codex 进阶能力全景与统一 Key 接入场景
很多人用 Codex 停留在「问一句、答一句」的阶段，代码能生成，但每次都要重新交代项目规范、手动复制粘贴、改完还得自己敲 git 命令。真正把 Codex 用成工程流工具的人，靠的不是更长的提示词，而是把技能（Skills）、MCP、派生（Derive）、分叉（Fork）、Git 集成、钩子（Hooks）、子智能体（Subagent）这几块能力串起来，让 AI 在一个可复用、可回溯、可并行的环境里持续产出。
这套玩法有个前提：所有环节都得走同一条 API 通道。Codex 的 auth.json 里如果还指向默认 endpoint，技能调用、MCP 工具请求、子智能体并行任务会各自走不同的鉴权路径，轻则额度分散，重则某个环节直接 401。我实测下来，把 endpoint 和 auth.json 统一改到 TaoToken，用一把 Key 串起全部能力，配置一次后面基本不用再动。
这篇面向已经跑通基础对话、想搭可复用工程流的开发者。我会按「先接通道、再逐项配能力、最后串 workflow」的顺序写，每个能力都给可复制的配置片段和验证动作。你不需要一次全上，挑当前最痛的环节先接，跑通一个再加下一个。
核心检索词先交代清楚：Codex 进阶玩法指的是在基础对话之上，通过 Skills 固化工作流、通过 MCP 扩展外部工具、通过 Derive/Fork 管理代码分支、通过 Hooks 做触发式自动化、通过 Subagent 并行拆任务，并用统一 API Key 把这些环节的模型调用收敛到一条通道。适合谁？适合已经在用 Codex 写代码、但每次都要重复交代规范、手动管分支、改完手动提交的开发者。
先说清楚一个容易混的点：Codex 里的「工作树（Work Tree）」就是你当前打开的那个项目目录，Codex 只读写这个目录里的文件，切换工作树等于切换项目。所有修改、历史、技能、配置都绑定当前工作树。派生和分叉都是围绕工作树做文章——派生是开一条新对话思路，分叉是给当前工作树拍一个可回溯的快照。这两个概念后面会反复用到，先记住区别。
2. TaoToken 前置：把 endpoint 与 auth.json 改到统一通道
在配任何进阶能力之前，先把 Codex 的模型调用通道接好。这一步不做，后面 Skills 里写的规则、MCP 拉的外部数据、Subagent 并行跑的任务，都会因为鉴权不一致而时好时坏。
Codex 的配置文件通常在用户目录下的.codex/里，核心是auth.json和config.toml。auth.json 管鉴权，config.toml 管模型和 endpoint。你要做的是把这两处的 Base URL 和 Key 都指向 TaoToken。
先拿 Key。打开 https://taotoken.net/api-keys ，登录后在控制台创建一把 API Key，复制出来。这把 Key 后面会同时用于 Codex 主对话、Skills 触发的模型调用、MCP 工具请求和 Subagent 任务，所以别用临时 Key，建一把长期有效的。
拿到 Key 后改 auth.json。路径一般是~/.codex/auth.json（Windows 是C:\Users\你的用户名\.codex\auth.json）。原始内容大概长这样：
{ "OPENAI_API_KEY": "sk-xxxxxxxxxxxxxxxx" }改成：
{ "OPENAI_API_KEY": "你在TaoToken创建的Key" }注意这里字段名保持OPENAI_API_KEY不变，Codex 读的就是这个字段，改的是值。别自作主张改成TAOTOKEN_API_KEY，Codex 不认。
接着改 config.toml，路径~/.codex/config.toml。关键是model_provider和base_url两处：
model = "gpt-5-codex" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" wire_api = "responses"base_url填https://taotoken.net/api，不要带末尾斜杠，也不要加 UTM 参数。wire_api按你用的模型选，Codex 系模型用responses，普通对话模型用chat。Model ID 填你实际要用的，比如gpt-5-codex或claude-sonnet-4-5，具体可用列表在 https://taotoken.net/doc 查。
三件套对齐检查：Base URL =https://taotoken.net/api，Key = 你刚创建的那把，Model ID = config.toml 里model字段的值。这三处任何一处不一致，后面都会出问题。
改完存盘，重启 Codex。验证方式很简单，在 Codex 里发一句「你好，确认一下当前模型」，能正常回就说明通道通了。如果报 401，先回去查 Key 有没有复制全、有没有多余空格；如果报 model not found，查 Model ID 拼写。
这一步做完，你的 Codex 所有模型调用都走 TaoToken 了。接下来配的 Skills、MCP、Hooks、Subagent，只要它们内部调模型，都会复用这条通道，不用每个能力单独配 Key。这就是「统一 Key」的价值——一处配置，全链路生效。
3. 可复制配置：Skills、MCP、Hooks 与 Subagent 的落地片段
通道接好后，逐项配能力。这一节给的都是可直接复制的片段，路径和原文一致，你照着建文件就行。
3.1 Skills：把工作流固化成可复用技能
Skills 存放在项目目录下的.codex/skills/。比如你的项目在/project/main，就建/project/main/.codex/skills/。每个技能一个.md文件，文件名就是技能名。
建一个vue3-component.md：
# 技能：生成 Vue3 组件 规则： - 必须用 script setup - 必须定义 props 并标注类型 - 必须带注释 - 样式用 scoped - 组件名用 PascalCase 输出：一个完整单文件组件用的时候直接在 Codex 里说「使用技能 vue3-component 生成一个用户卡片组件」，Codex 会读这个文件并按规则生成。你写一次规则，以后一句话调用，不用每次重复交代。
官方支持的技能类型包括代码规范、项目架构规则、接口开发模板、数据库建模模板、自动化流程、代码审查标准。你可以按项目需要建多个，比如api-template.md、db-model.md、review-standard.md。GitHub 上也有不少现成的 skill 可以拿来改，搜 codex skills 能找到。
3.2 MCP：给 Codex 接外部工具
MCP 是 Codex 的插件系统，让 AI 能调外部工具——读网页、连数据库、读 Figma 设计稿、调 API。配置位置在.codex/mcp.json（部分版本是config.toml里的[mcp_servers]段）。
以接一个数据库 MCP 为例，mcp.json写法：
{ "mcpServers": { "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres"], "env": { "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb" } } } }配好后 Codex 就能读你的数据库表结构、生成 CRUD 代码。注意别把生产库直连进去，用本地或测试库。MCP 让 Codex 不只写代码，还能读外部数据，相当于给它装上眼睛和手脚。
3.3 Hooks：触发式自动化
Hooks 是事件触发的自动化脚本，配置在.codex/hooks/。支持的触发点包括生成代码前、生成代码后、保存文件前、派生前/后、分叉前/后。
建一个post-generate.sh，让代码生成后自动格式化：
#!/bin/bash # 代码生成后自动格式化 npx prettier --write "src/**/*.{ts,tsx,vue}" npx eslint --fix "src/**/*.{ts,tsx,vue}"在 hooks 配置里绑定到「生成代码后」事件。这样每次 Codex 生成完代码，自动跑格式化和 lint，你不用手动敲。其他常见用法：保存后自动跑 lint、派生后自动装依赖、修改后自动跑测试。
3.4 Subagent：并行拆任务
Subagent 是 Codex 里的独立对话页面，由主 Agent 自动创建，每个子智能体有独立上下文、独立文件操作环境，可以并行干活。你在 Codex 里看到的主窗口下面那些名字（比如 Singer、Dirac、Bacon、Dewey），每一个就是一个 subagent。
它和普通「新开页面」的区别：普通新开页面是空白的，没有历史上下文；Subagent 是带着你之前的代码、历史、项目环境一起过去的，相当于从当前对话分叉出去一个独立版本，可以单独改代码、单独跑命令、单独生成文件，不影响主对话。
用法上，你给主 Agent 一个整体需求，比如「重构用户模块，前端改组件、后端改接口、补单元测试」，主 Agent 会拆成三个子任务，分别派给三个 Subagent 并行跑。一个改前端、一个写接口、一个写测试，同步推进，不用排队等 AI 跑完一个再开下一个。上下文隔离的好处是主对话不会被细碎代码日志堆满。
3.5 派生与分叉：代码分支管理
派生（Derive）有两个选项，区别很关键。
派到本地：沿用当前打开的本地文件夹和原有 Git 工作区，不新建独立目录。新分支对话里 AI 改的代码会直接写进你现在磁盘里的文件。适合只想基于旧消息开一条新思路、继续在当前目录迭代的场景。风险是如果之前轮次改过文件系统，新分支内容可能和当前磁盘文件不一致。
派到新工作树：基于 Git 的 worktree 功能，创建一个全新、物理隔离的独立代码文件夹，共享同一个 Git 仓库版本库，但文件目录完全分开。AI 后续所有操作都在新目录里，完全不干扰原项目。适合并行做两套独立方案、做高风险实验性修改。默认会在 codex 的 worktree 里复制新建一个和刚才完全一样的环境。
对比一下：
| 维度 | 派到本地 | 派到新工作树 |
|---|---|---|
| 代码目录 | 沿用当前已有目录 | 新建独立隔离目录 |
| 原文件安全性 | 后续改动直接影响原文件 | 原文件完全不受影响 |
| 并行开发 | 不能同时看新旧两套代码 | 可同时打开两个目录并行推进 |
| 冲突风险 | 存在和当前磁盘文件不一致的风险 | 几乎无文件冲突风险 |
举个例子：你在/project/main做开发，想基于 3 轮前的消息换思路。选派到本地，新对话改的代码直接写进/project/main；选派到新工作树，会自动生成/project/new-fork新文件夹，新对话所有改动都在新文件夹里，原来的 main 纹丝不动。
分叉（Fork）是给当前工作树创建一个可回溯的版本快照，不是 Git 分叉，是 Codex 内部快照。用法：右键工作树 → Fork，改崩了 → 切回旧分叉。相当于手动版本控制，改代码前先分叉，改错了能一键切回去。
3.6 Git 集成
Codex 原生支持 Git，你不用手动敲命令。直接说「提交代码」「撤销修改」「切换分支」「合并分支」「查看改动」，Codex 会自动执行 git add、git commit、git push、git diff、git checkout、git merge。
最强的是 AI 帮你写 commit 信息：你说「提交本次修改，生成清晰的 commit 信息」，Codex 会读 diff 生成描述。最安全的是自动检查冲突：Codex 会告诉你哪里冲突、帮你解决、不会乱覆盖代码。
4. 验证请求与成功结果：逐项确认能力生效
配完不等于生效，每一项都要验证。这一节给验证动作和预期结果。
先验证统一通道。在 Codex 里发「你好，确认当前模型」，正常回复说明 auth.json 和 config.toml 生效。如果这一步就失败，后面不用往下走，先回去查 §2 的三件套。
验证 Skills。在 Codex 里说「使用技能 vue3-component 生成一个用户卡片组件」，预期结果是生成的组件用 script setup、有 props 类型标注、有注释、样式 scoped。如果生成结果不符合规则，检查.codex/skills/vue3-component.md路径对不对、文件名和调用名是否一致。
验证 MCP。配好 postgres MCP 后，说「读一下 users 表结构，生成对应的 CRUD 接口」。预期结果是 Codex 能列出表字段并生成接口代码。如果报连接失败，检查 DATABASE_URL 和 MCP server 是否装好。
验证 Hooks。改一个文件触发「生成代码后」事件，预期结果是 prettier 和 eslint 自动跑了。可以故意写一段格式乱的代码，看保存后是否被自动格式化。没触发就检查 hooks 脚本有没有执行权限（chmod +x）。
验证 Subagent。给主 Agent 一个多任务需求，比如「前端加个登录页、后端加登录接口、补登录测试」，预期结果是主对话下出现多个子智能体名字，各自并行跑，主对话不被细碎日志刷屏。如果只出现一个，说明任务没被拆，需求描述再具体点。
验证派生。基于一条旧消息选派到新工作树，预期结果是生成一个新的独立目录，原目录文件不变。去文件系统里确认新目录存在、内容独立。
验证分叉。右键工作树 Fork，改点代码，再切回旧分叉，预期结果是代码回到分叉时的状态。
验证 Git。改点代码说「提交本次修改，生成 commit 信息」，预期结果是 Codex 自动 add、commit，并生成描述性 commit message。用git log确认。
全部验证通过，你的 Codex 进阶能力就串起来了。任何一项失败，先看 §5 的排障。
5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth
配这套东西最容易卡在几个固定报错上，逐个说。
401 Unauthorized。最常见。原因通常是 auth.json 里 Key 没复制全、有多余空格、或者 Key 已失效。排查：打开~/.codex/auth.json，确认OPENAI_API_KEY的值和你从 https://taotoken.net/api-keys 复制的一致，前后无空格。如果 Key 是刚建的，等几秒再试。还不行就重新建一把 Key 换上去。
local proxy failed / connection refused。Codex 启动时连不上 endpoint。检查 config.toml 里base_url是不是https://taotoken.net/api，有没有多写斜杠或路径。确认网络能访问这个地址。如果用了本地代理工具，确认它没拦截这个域名。
reading choices / choices field missing。模型返回格式和 Codex 预期的不一致。多半是wire_api配错了。Codex 系模型用responses，普通对话模型用chat。改 config.toml 里wire_api的值，重启 Codex。
OAuth / authentication failed。Codex 尝试走 OAuth 流程但没配好。这套配置走的是 API Key 鉴权，不需要 OAuth。检查 auth.json 里是不是混进了 OAuth 相关字段，清掉只留OPENAI_API_KEY。如果 Codex 版本默认走 OAuth，在 config.toml 里显式指定model_provider为你的自定义 provider。
Skills 不生效。检查.codex/skills/路径是不是在当前工作树根目录下，文件名和调用名是否一致，文件内容格式对不对（要有# 技能：xxx标题）。切换工作树后技能不跟随，因为技能绑定当前工作树。
MCP 连不上。检查mcp.json里 command 和 args 是否正确，MCP server 是否装了（npx -y @modelcontextprotocol/server-postgres能跑通）。env 里的连接串对不对。别连生产库。
Hooks 不触发。检查脚本有没有执行权限，事件绑定名对不对，脚本路径是不是绝对路径。可以在脚本开头加echo "hook triggered" >> /tmp/hook.log确认有没有被调用。
Subagent 不并行。任务描述太笼统，主 Agent 没拆。把需求拆成明确的多个子任务，比如「任务1：改前端组件；任务2：写后端接口；任务3：补测试」，主 Agent 更容易分派。
派生后文件冲突。选派到本地时，如果之前轮次改过文件系统，新分支可能和磁盘不一致。这种情况改用派到新工作树，物理隔离，天然规避冲突。
排障时记住一个原则：先确认统一通道通不通（§2 的三件套），再查具体能力。通道不通，后面全白搭。接入文档在 https://taotoken.net/doc ，API Keys 在 https://taotoken.net/api-keys 。
6. 把能力串成工程流：从单点配置到可复用工作流
单项能力配完只是零件，真正提效的是把它们串成 workflow。这一节给几个可直接照抄的组合，你按项目需要挑。
安全开发流：Fork（分叉）→ 写代码 → 测试 → Derive（派生）→ Git 提交。核心是永远不弄脏原项目。改代码前先分叉拍快照，改崩了切回去；要开新思路就派生到新工作树，物理隔离；确认没问题再 Git 提交。适合改动风险高的场景。
标准化开发流：Skills（加载规范）→ 生成代码 → Hooks（自动格式化）→ Git 提交。核心是规范固化。你把项目规范写进 Skills，每次生成代码自动套规则，生成完 Hooks 自动格式化 lint，最后 Git 提交。适合团队协作、需要统一代码风格的场景。
全自动化流：MCP（读取 Figma/接口）→ Skills → 生成代码 → Hooks → Git 提交。核心是外部数据驱动。MCP 读设计稿或接口文档，Skills 套规范，生成代码，Hooks 格式化，Git 提交。适合从设计到代码的流水线。
多项目管理流：工作树 1 → 派生 → 新工作树 2，工作树 A ↔ 工作树 B 自由切换。核心是并行。多个项目同时推进，每个项目一个工作树，需要并行实验就派生新工作树，切换工作树等于切换项目。
串这套流的关键还是统一 Key。Skills 调模型、MCP 调工具、Subagent 并行跑任务、Hooks 触发脚本，这些环节只要涉及模型调用，都走 §2 配好的 TaoToken 通道。你不用给每个能力单独配 Key，一处配置全链路生效。长期跑编码和 Agent 任务的话，用 Coding Plan 更划算，额度集中管理，不用每次担心某个环节额度不够。
最后给个上手顺序建议：先接通道（§2），再配 Skills（最提效），然后 Git 集成（最常用），接着 Hooks（自动化），再 MCP（扩展），最后 Subagent 和派生分叉（并行和隔离）。一次别全上，跑通一个再加下一个，出问题好定位。我试过一口气全配，结果 401 和 MCP 连接失败混在一起，排查花了半天。逐个来，每步验证通过再往下，稳得多。
