可以把它们理解成 Claude Code 里 3 种不同职责的构件：
| 类型 | 本质 | 谁触发 | 适合什么 |
|---|---|---|---|
skill |
给 Claude 的"做事方法 / 领域知识 / 工作流" | 自动匹配、手动调用、也可被 command/其他流程带起 |
工作流、规范、最佳实践、知识补充 |
command |
用户可见的"快捷指令 / 交互入口 / 提示模板" | 主要由用户输入 /xxx 触发 |
高频重复任务、标准化入口、参数化流程 |
subAgent |
独立运行的"子代理 / 专项执行者" | 主代理按需拉起，也可被上层流程显式要求使用 | 复杂、多步、可并行、需要独立上下文的任务 |
更直白一点：
-
skill像"作战手册"它定义的是 Claude 遇到某类任务时应该怎么做。它可以自动触发，也可以手动要求 Claude 使用某个 skill，还可以被 command 间接带起。
-
command像"快捷菜单"你输入
/review-pr 123、/deploy staging这种，本质上是在给 Claude 一个稳定的交互入口。它擅长收参数、组织上下文、执行脚本、串起流程。 -
subAgent像"分出去干活的同事"主代理把一个复杂任务委托给它，它带着自己的角色设定、工具权限和独立上下文去完成，再把结果返回。
三者关系
最准确的理解不是"谁更高级"，而是三种职责：
skill是能力command是快捷入口（其实可以用skill替代的）subAgent是独立执行者
所以它们经常会组合使用，而不是互相替代。
一个典型链路可能是：
- 你直接手动调用某个
skill，或输入一个command - Claude 按该
skill的方法论处理任务 - 如果任务复杂，再拉起一个
subAgent深入执行 - 最终由主代理汇总结果返回给你
怎么选
- 想沉淀"遇到 X 就按这种方式做" -> 用
skill - 想给用户一个稳定、好记、可传参的入口 -> 用
command（也可以用skill） - 想把复杂任务拆给独立智能体处理 -> 用
subAgent
实战图
需要沉淀做事方法
需要一个稳定入口
需要独立完成复杂任务
用户提出任务
这是在解决什么问题?
Skill\n方法论 / 规范 / 知识
Command\nslash 命令 / 参数入口
SubAgent\n独立执行
主代理整合结果
返回给用户
再给你一个更贴近实战的例子：
否
是
用户: /review-pr 123
command: review-pr
收集 PR 参数、文件、git/gh 上下文
skill: code-review-standards
改动是否复杂?
主代理直接完成评审
subAgent: code-reviewer
输出评审结果
一句最终版总结：
skill 负责"怎么做"，command 负责"怎么进来"，subAgent 负责"谁去独立做"。