📚AI 编程官方教程中文版
从原理到实战

08 · Skills、Subagents、Hooks 解决什么问题

回想一下你过去一周,Codex 让你重复做过这些事吗?

⏱️ 预计阅读 13 分钟 | 🎯 目标:把 Codex 从"单 Agent 单次任务"升级到"流程复用 + 分工协作 + 自动检查"

上一篇讲完工具栈 4 层。这一篇展开 Skills / Subagents / Hooks —— 三种升级 Codex 工作方式的机制。 关键判断:先把单 Agent 用熟,再上这三个。它们不是越早用越好。


🎬 三种"重复劳动"的痛

回想一下你过去一周,Codex 让你重复做过这些事吗?

表现解法
😩 重复多步流程每次 PR review 都要走 5-6 步同样的提示词🛠️ Skill(流程复用)
😵 大任务一锅炖"重构整个登录模块"扔给单 Agent,乱成一团👥 Subagent(分工协作)
😨 改完总忘记跑某个检查经常忘 lint / typecheck / 安全扫描🔔 Hook(自动检查)

💡 判断口诀"重复 5 次以上的事 → 想想能不能 Skill / Subagent / Hook"。 一两次的事不值得做成机制。


🗺️ 三者全景:它们各管什么?

flowchart TB
    User[👤 你提任务]
    Codex[🤖 Codex 主 Agent]

    subgraph Mech1["🛠️ Skill —— 复用流程"]
        S[多步工作流打包]
        S2["例:PR review / 文档生成"]
    end

    subgraph Mech2["👥 Subagent —— 分工并行"]
        Sub[专项 Agent 配置]
        Sub2["例:reviewer / browser-debugger / docs-researcher"]
    end

    subgraph Mech3["🔔 Hook —— 生命周期触发"]
        H[事件钩子]
        H2["例:改完文件自动 typecheck / 跑命令前审计"]
    end

    User --> Codex
    Codex -.调用.-> Mech1
    Codex -.派生.-> Mech2
    Codex -.触发.-> Mech3

    style Mech1 fill:#dcfce7,stroke:#22c55e
    style Mech2 fill:#fef3c7,stroke:#f59e0b
    style Mech3 fill:#dbeafe,stroke:#3b82f6

一句话区分

机制一句话关键词
🛠️ Skill把"我每次都要交代的多步流程"做成可复用动作复用
👥 Subagent把"大任务"拆给多个专项 Agent 并行干分工
🔔 Hook在生命周期事件上"自动插一脚"自动化

🛠️ Skill · 把多步流程做成一键

是什么

Skill = 一份带说明书的工作流包

my-pr-review-skill/
├── SKILL.md          ← 流程说明(Codex 看这个学怎么做)
├── checklist.md      ← 资源文件
└── scripts/          ← 可选脚本
    └── run-checks.sh

📖 来源:OpenAI Codex · Agent Skills

为什么 Codex 不会被 Skill "撑爆"

设计精巧之处:渐进式披露(progressive disclosure)

flowchart LR
    A["Codex 启动<br/>只读 Skill 名字 + 描述"] --> B{遇到任务<br/>需要这个 Skill 吗}
    B -->|是| C["完整加载 SKILL.md"]
    B -->|否| D["跳过,节省上下文"]

    style C fill:#dcfce7,stroke:#22c55e
    style D fill:#fef3c7,stroke:#f59e0b

结果:你装 50 个 Skill,启动只读 50 行描述;用到哪个才完整加载。不撑爆上下文窗口

怎么放 / 怎么用

范围路径适合
🌍 全局(你个人用)~/.codex/skills/所有项目通用的工作流
📁 项目级(团队共享).agents/skills/(提交到仓库)团队约定的项目专属流程

一个简单的 Skill 例子

`<!-- ~/.codex/skills/pr-review/SKILL.md -->`
---
name: PR Review
description: 系统性地评审一个 PR,检查代码风格、测试覆盖、安全风险
---

# 步骤

1. 拉取 PR 改动列表(用 git diff)
2. 检查每个改动文件:
   - 代码风格符合项目 AGENTS.md
   - 有对应测试
   - 无明显性能问题
3. 跑安全扫描脚本 `./scripts/run-checks.sh`
4. 输出三段:
   - ✅ 通过项
   - ⚠️ 建议项
   - ❌ 阻塞项

💡 写 Skill 的最佳实践:每个 Skill 只做一件事;优先用说明文字而不是脚本(除非要确定性结果)。

Skill vs Plugin 区别

SkillPlugin
是什么流程的编写格式Skills 的可分发包装
谁用自己写自己用给团队 / 社区分发
类比你写的菜谱出版的菜谱书

👥 Subagent · 把大任务拆给多个专项 Agent

是什么

Subagent = 主 Agent 派生出的专项分身,并行干活,最后汇总。

flowchart TB
    Main["🤖 主 Agent<br/>接到大任务"]
    S1["📚 docs-researcher<br/>查框架文档"]
    S2["🔍 pr-explorer<br/>读代码库"]
    S3["🐛 browser-debugger<br/>复现 bug"]
    S4["🧪 ui-fixer<br/>改 UI 代码"]
    Result["📦 主 Agent 汇总结果"]

    Main --> S1 & S2 & S3 & S4
    S1 & S2 & S3 & S4 --> Result

    style Main fill:#fef3c7,stroke:#f59e0b
    style Result fill:#dcfce7,stroke:#22c55e

📖 来源:OpenAI Codex · Subagents

何时该用 Subagent

强并行任务:codebase 探索、多模块同时改、多源信息汇总 ✅ 专项能力分工:让 reviewer agent 用更便宜模型 + 让 architect agent 用最强模型 ✅ 大任务拆分:一个 Agent 做不完,分给多个

简单任务:单 Agent 几步就完成的,别拆分(拆了反而慢) ❌ 强串行任务:A 必须等 B 输出再做,并行不出来

⚠️ 成本警告:每个 Subagent 自己消耗 token,总开销显著高于单 Agent。预算敏感场景慎用。

Subagent 配置

可以给每个 Subagent 单独配模型 / sandbox / MCP:

# ~/.codex/agents/reviewer.toml

name = "reviewer"
description = "代码评审专家,检查风格 / 测试 / 安全"
model = "gpt-5.4"
model_reasoning_effort = "low"   # 评审用低推理就够
sandbox_mode = "read-only"       # 评审不改代码
mcp_servers = ["github"]         # 只接 GitHub MCP

# 让 UI 显示更友好的实例名
nickname_candidates = ["巡查 A", "巡查 B", "巡查 C"]

启动方式:

请用 reviewer 子 Agent 检查最近 3 个 PR

默认是开还是关

默认开:当前 Codex 版本里 Subagent 工作流默认启用(在 App / CLI 可见) ⏳ IDE 可见性:陆续接入中


🔔 Hook · 在生命周期事件上自动触发

是什么

Hook = 在 Codex 干活的关键节点上挂一个"检查员"

flowchart LR
    A[Codex 想做某动作] --> B{🔔 Hook 触发}
    B -->|通过| C[继续]
    B -->|拦截| D[停下问 / 报错]

    style B fill:#dbeafe,stroke:#3b82f6
    style D fill:#fee2e2,stroke:#ef4444

能挂在哪些事件上

MCP 工具调用前后:审计哪个工具被调 ✅ apply_patch 改文件前:审查 diff 是否符合规则 ✅ 长时间 Bash 会话:超时 / 安全扫描

配置方式

# ~/.codex/config.toml

[hooks]
before_apply_patch = "scripts/lint-diff.sh"     # 改文件前先 lint diff
after_mcp_call = "scripts/audit-mcp.sh"         # MCP 调用后审计日志

或者写在独立 hooks.json,企业可通过 requirements.toml 强制下发。

典型用例

事件Hook 干什么价值
改文件前检查 diff 不动 .env / secrets/防泄露
跑命令前黑名单扫描(拦截 rm -rf防误操作
MCP 调用后把请求记录到审计日志合规追溯
Bash 长会话超时强杀防失控

📖 Hooks 现已稳定,可在 config.toml 内联或外置 hooks.json,企业可强制管控。


⚖️ 三者怎么选:决策矩阵

维度🛠️ Skill👥 Subagent🔔 Hook
解决流程复用分工 / 并行自动化检查 / 拦截
触发方式Codex 主动选用显式调用生命周期事件自动触发
成本低(按需加载)高(每个子 Agent 独立 token)极低(脚本执行)
适合场景"我每次都要做的 X""任务太大要并行""我老忘记 / 防误操作"
新手优先级⭐⭐⭐⭐ 最先学⭐⭐ 后期再上⭐⭐⭐ 团队场景必备

🚫 常见误解 → ✅ 正确理解

❌ 误解✅ 正解
新手就该一上来配 Skill / Subagent / Hook先把单 Agent 单次任务用熟,再上这三个
Skill 越多越能干每个 Skill 都占描述位;只留高频复用的
Subagent 是 Codex 的并发模式是任务编排机制,token 成本高
Hook 是企业才需要的个人开发者用 Hook 防 rm -rf 也很值
三者哪个最强各管不同问题(复用 / 分工 / 检查),互补

🔍 想再深一层(点击展开)

📐 写一个好 Skill 的 4 条原则
  1. 单一职责:每个 Skill 只做一件事,不搞"万能助手"
  2. 说明优先:能用文字描述的就别用脚本(除非要确定性结果或外部工具)
  3. 明确输入输出:每步写清"接收什么、产出什么"
  4. 触发可测:写完后用几个不同提示词验证 Codex 能正确触发它

📖 来源:Codex Skills Best Practices

🤝 多 Agent 协作工具集

Codex 提供 5 个稳定的多 Agent 协作工具(默认开):

工具作用
spawn_agent派生新 Agent
send_input给某 Agent 发新输入
resume_agent恢复挂起的 Agent
wait_agent等某 Agent 完成
close_agent关闭 Agent

这些底层工具支撑 App 里的 worktree + 多 Agent 编排。

🏢 企业级 Hooks 管控

公司可以通过 requirements.toml 强制员工的 Codex 必须挂某些 Hooks:

# IT 下发的 requirements.toml

[required_hooks]
before_apply_patch = "/opt/security/scan-diff.sh"   # 强制 diff 安全扫描
after_mcp_call = "/opt/audit/log-mcp.sh"            # 强制审计日志

员工无法关闭。金融 / 医疗 / 政府场景的标配

📖 术语速查表
英文 / 缩写中文一句话解释
Skill技能多步工作流的可复用打包
Subagent子 Agent / 子代理主 Agent 派生的专项分身
Hook钩子在生命周期事件上自动触发的脚本
progressive disclosure渐进式披露按需加载,避免一次性吃满上下文
apply_patch应用补丁Codex 改文件的内置工具
nickname_candidates昵称候选同 Subagent 多实例的 UI 显示名
Plugin插件Skills 的可分发包装

📖 官方文档来源:


📝 本章自检

#问题对应章节自检
1Skill / Subagent / Hook 各解决什么痛点?🗺️ 全景
2Skill 怎么做到装 50 个不撑爆上下文?🛠️ Skill
3什么时候不该用 Subagent?👥 Subagent

过关标准:能用一句话说清 —— "Skill 复用流程,Subagent 分工并行,Hook 自动检查 —— 各管一摊。"


📚 下一篇


🧭 一句话记住

Skill 让流程能复用,Subagent 让任务能分工,Hook 让规则自动执行。
三者互补,按身份和痛点按需上。

On this page