Command 按按钮、Skill 给经验、Subagent 借个脑子：三者到底怎么配合

一句话总结：这三个东西容易混，是因为它们都长得像 markdown 加 frontmatter。区别不在格式，在两件事：谁触发它，以及它在哪个上下文里跑。Command 是人按的按钮，Skill 是模型自己翻的手册，Subagent 是另开一间房干活。想清楚这两件事，选型就没有纠结了。

一、先给一句话分工

我见过最多的困惑是："这三个我都能用来封装流程，到底选哪个。"

其实它们管的不是同一件事。

Command 管触发。 你打 /xxx，它才动。不主动，不智能，纯粹是个快捷方式。

Skill 管知识。 模型自己判断要不要用，用的时候把手册翻进上下文。你不知道它什么时候翻的，但它翻了你也不用管。

Subagent 管隔离。 另开一个上下文去干活，干完只把结论交回来。中间读了多少文件、试了多少次错，主对话一概看不到。

所以选型问题可以拆成两句：要不要人主动按一下？要不要换个房间干？

二、三个东西各自长什么样

形式上它们几乎一样，都是 markdown 文件加一段 frontmatter。这也是混淆的来源。

Command，放在命令目录里的一个 md，文件名就是命令名。

---
description: 按检查清单审一遍 PR
---
1. 读 diff，列出改动的文件
2. 对每个文件检查：命名、错误处理、边界条件
3. 输出问题列表，按严重程度排序

你打 /review-pr，这段文字就整段进上下文，模型照着做。

Skill，是一个目录，里面至少一个 SKILL.md。前面写过的三层加载机制在这篇里，这里只说结论：平时只占 100 token 的元数据，任务对上了才读正文。

Subagent，也是一个 md，但带工具权限和模型配置。

---
name: code-explorer
description: 在陌生代码库里定位实现。当需要跨多个文件追踪调用链时使用。
tools: Read, Grep, Glob
model: haiku
---
你负责在代码库中定位实现位置。只读文件，不做修改。
返回：相关文件路径 + 关键行号 + 一句话说明。

主 agent 会在需要时把它派出去，它在自己的上下文里跑完，回来只给一份结果。

三、一张图看清区别

图 1：横轴是谁触发，纵轴在哪儿执行。三者分别落在不同的格子里

横轴问的是"谁决定开始"，纵轴问的是"在哪儿干"。

Command 在左下：人触发，就在当前对话里执行。

Skill 在右下：模型触发，也在当前对话里，但只是往上下文里加内容。

Subagent 在右上：模型（或 command 间接）触发，另开上下文。

左上那格是"人触发 + 独立上下文"，实践里也常见：你打一个 command，command 里第一句就是"派三个 subagent 并行审这三个模块"。这时候人按了按钮，活在别的房间里干。

四、四种配合方式

单独用任何一个都不难，难的是组合。我整理了实际用得上的四种。

方式一：Command 当入口，里面调度其他两个

这是最顺的用法。人只需要记住一个命令名，后面的复杂度都藏在文件里。

---
description: 全量代码审查，适合发版前跑
---
1. 先按 .claude/skills/review-checklist/SKILL.md 的清单确认检查项
2. 派 3 个 subagent 分别审：接口层、数据层、前端
3. 汇总三份报告，按严重程度合并成一张表
4. 对 P0 问题给出具体修改建议

人打 /full-review，模型先加载检查清单这个 Skill，再派三个 subagent，收回结果后统一汇总。

这个组合的好处是省心：你不需要记得"这次要加载哪个 skill""要派几个 agent"，命令里写死了。

方式二：Skill 里规定什么时候必须派 Subagent

这条最容易被忽略，但很有用。

Skill 的正文可以写判断规则，比如："如果需要检查超过 10 个文件，不要自己逐个读，派 subagent 去做。"

这样做的价值在于控制上下文。一个 Skill 触发后，模型很容易顺着"那我再看看这个文件"一路读下去，主对话被塞满。提前在 Skill 里写死边界，比事后清理便宜。

## 什么时候必须派 subagent
- 需要读超过 10 个文件
- 需要在 3 个以上目录里搜索
- 需要试错三次以上

这三种情况自己做完，主对话会被塞满。派出去，只收结论。

方式三：Subagent 带自己的工具和模型

Subagent 定义里可以限定工具，也可以换模型。

这两项都直接影响成本。搜索类的活只需要读，把工具限定成 Read、Grep、Glob，它就不可能误改文件；简单的定位工作换小模型，一次能省下大半开销。

我见过最实用的一个配置：探索类 subagent 一律用小模型加只读工具，因为你只需要它告诉你"在哪"，不需要它给出判断。

方式四：三者串成一条流水线

真实的复杂任务通常是这样：

/release-check（command）
  → 加载 release-checklist（skill）
  → 派 2 个 subagent 并行：一个跑测试，一个查依赖
  → 收回结果，按 skill 里的判定标准给结论

每一层只干自己的事。Command 负责"什么时候开始"，Skill 负责"什么算合格"，Subagent 负责"重活别在主对话里干"。

五、决策顺序：四个问题

拿到一件具体的事，按这个顺序问，第一个"是"就是答案。

第一问：需不需要人主动按下才执行？

需要的话，用 Command。典型场景：发版前检查、固定格式的日报、你不想让它自动跑的危险操作。

第二问：需不需要独立上下文、并行、或者换模型？

需要的话，用 Subagent。典型场景：跨几十个文件找实现、同时审三个模块、只需要结论不需要过程。

第三问：是不是"怎么做"的知识，且希望模型自己判断该不该用？

是的话，用 Skill。典型场景：写作规范、代码风格、你们团队的发布流程。

第四问：什么都不是？

那可能只是一段 prompt，直接说就行，不用封装。

我把这个顺序倒过来试过，先问"这是不是知识"，结果把所有东西都想做成 Skill。先问触发方式更靠谱，因为它最有区分度。

六、成本和边界的对照

这张表能回答大部分"该用哪个"的问题。

需要并行，只有 Subagent 能。需要零成本常驻一堆知识，只有 Skill 能。需要人精确控制什么时候跑，只有 Command 能。

七、一处我没法确认的地方

写这篇时我查了几个来源，对"subagent 能不能用 Skill"说法不一致。

一种说法是 subagent 拥有自己的系统提示和工具集，可以配套自己的 Skill；另一种说法是 Skill 只对主 agent 可见，subagent 拿不到。

我倾向于认为这取决于具体实现和配置，不同产品、不同版本可能不一样。这件事建议你自己实测：定义一个明显依赖某个 Skill 的 subagent，看它能不能读到。

有一条倒是几个来源一致的：subagent 不能再派 subagent。 不允许递归，只有主 agent 负责调度。这个限制是防止无限套娃，合理。

八、坑清单

1. 把 Skill 当 Command 用，指望打命令触发。 Skill 是模型自己判断的，你打什么都不会直接触发它。要人控制，就写 Command。

2. 在 Command 里塞几百行说明。 Command 的内容是整段进上下文的，每次调用都付一遍。内容长了就拆：Command 只留调度逻辑，细节挪进 Skill。

3. 该派 Subagent 的时候硬扛。 表现是主对话越来越长、模型开始忘事、回答越来越笼统。这时候不是模型不行，是上下文满了。

4. 反过来，什么小事都派 Subagent。 派一个 subagent 就有一次启动开销，还要重新建立上下文。查一个函数在哪，自己 Grep 一下更快。

5. Command 名字起得太抽象。 /do-stuff 这种命名，过两周你自己都不记得它干什么。

九、边界

这套东西的取舍不涉及对错，只涉及你更在意什么。

如果你更在意确定性，就多用 Command，所有入口都由人控制。如果你更在意省心，就多用 Skill，让模型自己判断。两者不冲突，可以同时用。

Subagent 的边界在任务能不能切分。一个任务如果步骤之间强依赖，派出去反而更慢，因为每个 subagent 都要重新理解一遍背景。

结语

回到最开始那句：这三个不是同一层的三个选项，是三个不同位置的零件。

Command 在最外面，管入口。Skill 在中间，管知识。Subagent 在最里面，管执行。

判断的时候别问"这个功能该做成什么"，问两个更具体的问题：谁来决定开始，以及在哪儿干。

给个能马上做的动作：把你现在最常用的那段提示词翻出来看一眼。如果它每次都需要你主动粘贴，做成 Command；如果它是一套"什么时候该注意什么"的规则，做成 Skill；如果它里面有一堆"先读这些文件再说"，那部分该派 Subagent。

Skill 本身怎么写，这篇有完整流程；写完怎么检查质量，这篇给了实测数据。

参考资料

• Claude Code 原语组合指南 - 四类原语的能力矩阵与组合示例
• Commands 是按钮，Agents 是函数，Skills 是 mixin - 三者心智模型对比
• Claude Code 机制选择器 - 按需求选 Command/Skill/Subagent/Hook 的决策树
• Agent Skills 开放标准 - Skill 的格式与加载机制