Codex 的 Skill 到底是怎么被调用的？
最近在看 Codex / Coding Agent 的 skill 机制时，我一开始有一个疑问：
用户发消息以后，Agent 是不是会把所有 skill 都读一遍，然后再开始工作？
后来梳理下来，我觉得可以把 Codex 的 skill 调用理解成一句话：
它不是“全量遍历式执行”，而是“基于 skill description 的路由选择”。
也就是说，Codex 并不是每次收到任务后，把所有 skill 的完整 SKILL.md 都打开读一遍。而是先看到一份 skill 的索引列表，根据里面的 name 和 description 判断当前任务是否匹配某个 skill。
如果匹配了，才会读取对应 skill 的完整内容，并按照里面的流程工作。
这篇文章主要回答三个问题：
- 用户发消息后，Agent 会查一遍所有 skill 再工作吗？
- 工作过程中，它会不会反复重新检查所有 skill？
- 最后响应的时候，还会不会再走 skill？
一、用户发消息后，Agent 会查一遍所有 skill 再工作吗？
答案是：
会看到所有 skill 的简介索引，但不会读取所有 skill 的全文。
更准确地说，Codex 会在上下文里看到一份可用 skill 列表。这个列表通常包含每个 skill 的：
namedescription
这两个字段的作用，就是帮助 Agent 判断：
当前任务有没有适合的 skill？如果有，应该选哪个？
所以它的过程不是这样：
读取 skillA 的完整 SKILL.md
读取 skillB 的完整 SKILL.md
读取 skillC 的完整 SKILL.md
然后开始工作
而更像这样：
看到 skillA / skillB / skillC 的简介
判断当前任务更匹配 skillB
读取 skillB 的完整 SKILL.md
按照 skillB 的流程工作
这也是为什么 skill 的 description 非常重要。
因为它不仅是给人看的说明，更像是 Agent 的触发条件。如果 description 写得模糊，Agent 就可能不知道什么时候该用这个 skill；如果 description 写得清楚，自动触发就会稳定很多。
比如一个 skill 的 description 如果写成：
Use when implementing features or fixing bugs with test-driven development.
Agent 就更容易在“实现功能”或“修 bug”时自动选中它。
但如果只写成：
A useful development skill.
这个描述就太泛了，Agent 很难判断它到底该在什么时候使用。
所以，skill 的核心不是只写好 SKILL.md，还要写好 description。
二、工作过程中，Agent 会不会反复重新检查所有 skill？
默认不会。
它不会机械地每完成一步，就重新扫描一遍所有 skill，更不会每写一段代码就重新读取所有 skill 全文。
但是，在两种情况下，它可能会再次考虑是否需要新的 skill。
1. 任务阶段发生变化
一个开发任务往往不是单一阶段。
比如用户一开始说：
帮我实现一个登录功能。
这时候 Agent 可能先判断：需求还不够清楚，需要先做设计，于是使用 brainstorming 或 planning 类 skill。
等需求明确后，任务进入实现阶段，它可能又需要使用 test-driven-development 之类的 skill。
等实现完成后，它可能再进入 review 或 finish 阶段。
所以真实流程更像：
用户提出需求
↓
判断是否需要需求澄清 / 设计
↓
使用 brainstorming
↓
需求明确
↓
使用 planning
↓
进入实现
↓
使用 TDD / implementation skill
↓
实现完成
↓
使用 review / finishing skill
这不是因为 Codex 底层在不停“全量扫描”，而是因为任务本身进入了不同阶段，不同阶段匹配到了不同 skill。
2. 当前 skill 自己要求检查其他 skill
有些 skill 本身不是具体实现类 skill，而是流程管理类 skill。
比如 Superpowers 这类方法论里，可能会要求 Agent：
- 不要直接开始写代码
- 先检查是否有相关 skill
- 多个 skill 适用时，先使用 process skill
- 实现完成后，再进入 review / finish 流程
这种情况下，Agent 之所以再次考虑 skill，不是因为系统自动反复扫描，而是因为当前 skill 的规则要求它这么做。
换句话说：
Codex 的基础机制负责“选择 skill”，而 Superpowers 这类体系会进一步约束 Agent：什么时候必须重新检查、什么时候必须进入下一个流程。
所以这里要区分两件事：
Codex 底层机制：
根据 description 选择合适 skill。
Superpowers 工作流：
规定 Agent 在不同阶段应该主动检查和使用 skill。
三、最后响应的时候，还会不会再走 skill？
这个问题的答案是：
取决于当前任务用过的 skill 有没有定义收尾规则。
有些 skill 会明确规定最后应该怎么回复用户。
比如它可能要求最后必须说明：
- 改了哪些文件
- 做了哪些测试
- 测试结果是什么
- 还有哪些风险或后续事项
如果当前任务使用了这样的 skill，那么最后响应就应该受这个 skill 的影响。
但这不代表 Codex 在最后会自动再做一次：
重新扫描所有 skill
寻找 final response skill
读取它
然后输出
默认不是这样。
更准确地说：
如果已激活的 skill 规定了收尾格式，Agent 就应该按照它来；如果没有规定，就正常总结。
所以最后响应是否“走 skill”，不是一个固定的后置钩子，而是取决于：
- 当前任务是否使用过 skill
- 这个 skill 是否定义了验收、汇报、收尾格式
- AGENTS.md 或项目规则里是否规定了额外的结束流程
四、一个更准确的流程图
可以把 Codex 的 skill 调用理解成下面这个流程：
用户发消息
↓
Codex 看到：
- 当前用户请求
- AGENTS.md / 项目说明
- 已安装 skills 的 name + description
- 当前对话上下文
↓
判断：这个任务匹配哪个 skill？
↓
如果匹配：
读取对应 skill 的完整 SKILL.md
按 skill 里的流程工作
↓
如果不匹配：
直接按普通 agent 方式工作
↓
过程中如果任务阶段变化：
可能再次选择 / 读取新的 skill
↓
最后响应：
如果 skill 规定了收尾格式，就按 skill 来
如果没有，就正常总结
这个流程的关键点是：
Codex 不是每次都读取所有 skill 全文，而是先通过简介索引做选择。
五、可以用前端路由来类比
作为前端开发者，我觉得最容易理解的类比是：
skills 列表 = route table
description = path matcher / trigger condition
SKILL.md = matched route component
agent 当前任务 = incoming request
用户发来一个任务，就像浏览器访问一个路径。
系统不是每次都把所有页面组件完整加载一遍，而是先根据路由表匹配。
匹配到了哪个 route，才加载对应页面组件。
同理，Codex 也是先看到 skill 的索引，根据 description 判断哪个 skill 适合当前任务。只有当某个 skill 被选中时，才读取它完整的 SKILL.md。
所以 skill 的 description 就很像路由匹配规则。
写得清楚，Agent 就容易选中。
写得含糊，Agent 就可能漏掉，或者在不该用的时候误用。
六、最后总结
Codex 的 skill 调用机制，可以总结成一句话：
Codex 的 skill 调用不是全量遍历式执行，而是基于 skill description 的路由选择。
它会先在上下文中看到可用 skill 的简介列表，根据用户任务显式或隐式选择相关 skill；只有当某个 skill 被选中后，才会读取该 skill 的完整 SKILL.md。
任务推进过程中，如果阶段发生变化，或者当前 skill 要求重新检查其他 skill，Agent 才可能再次选择新的 skill。
最终响应是否受 skill 影响，也取决于已激活 skill 是否定义了收尾、验收和输出规则。
所以，理解 skill 机制时，最重要的不是把它想象成一个“每次全量扫描所有说明书”的系统，而是把它想象成一个“先匹配，再加载，再执行”的工作流系统。
这也解释了为什么一个好的 skill 不只是 SKILL.md 写得详细，还必须把 description 写清楚。
因为 SKILL.md 决定了 Agent 选中以后怎么做。
而 description 决定了 Agent 会不会选中它。
浙公网安备 33010602011771号