装好 Claude Code 的第一周，几乎所有人都会卡在同一个问题上。
打开斜杠菜单，你看到三类东西：有的命令前缀是 /，有的技能似乎会自己冒出来，配置文档里还让你往 .claude/agents/ 目录塞文件。名字一个比一个像——commands、skills、subagents——功能描述读起来更是傻傻分不清，好像哪个都能"让 AI 干活"。
上篇讲记忆系统时我们说过，CLAUDE.md 是写给 AI 的入职手册。今天这三样，则是你给 AI 配置的三种"岗位"。这篇讲清楚一件事：它们分别是什么时候用什么，以及真正的高手是怎么把它们串起来用的。
先记三个人设：按钮、本能、分身
抛开术语，三者的差别用三个比喻就能说尽：
- Command 是按钮——你亲手按的那种。把每天重复说的话做成
/xxx，一按就执行。它只等你按，你不按它永远不动。 - Skill 是本能——你不用喊，AI 自己会。把某类任务的操作手册写好，AI 遇到匹配的活儿自动取用，平时不占它的脑子。
- Agent 是分身——一个独立的小 Claude。派它出去干活，它有自己的脑子（独立上下文），干完只把结论带回来。
素材仓库给这三者做过一个很形象的实拍：同一个"报时"任务，作者分别做成了 time-command、time-skill、time-agent 三份配置，斜杠菜单里三个并列——这正是很多人困惑的根源：同一个任务，三种机制都能做。区别不在能不能，而在合不合适。
一张表看懂差别
如果只看一个维度，看"上下文"就够了；但真正做决定时，这几行的差异都会用到：
| 维度 | Agent（分身） | Command（按钮） | Skill（本能） |
|---|---|---|---|
| 放在哪 | .claude/agents/*.md |
.claude/commands/*.md |
.claude/skills/*/SKILL.md |
| 谁触发 | AI 判断（或你派） | 只有你按 / |
AI 自动匹配，你也能 / |
| 跑在哪 | 独立上下文 | 主对话里 | 主对话里（可配 context: fork 隔离） |
| 中间过程 | 留在分身里，你看不到 | 全部留在主对话 | 全部留在主对话 |
| 结果 | 只回收结论 | 过程和结论都在 | 过程和结论都在 |
| 能预载技能 | 能（skills: 字段） |
— | — |
| 有持久记忆 | 能（memory: 字段） |
— | — |
表里最值钱的是第四、五行：分身干活的过程——它读了 20 个文件、试了 3 条死路——全都发生在它自己的上下文里，主对话只收到一份干净的结论。这就是上篇说的"上下文经济学"，也是 Agent 和另外两位的本质分界线。
一个案例看懂触发逻辑："现在几点？"
光看表还是抽象，看素材仓库做过的这个实验。用户在对话里打了一句"现在几点"，没有按任何斜杠命令。三兄弟的反应：
| 机制 | 会接活吗 | 为什么 |
|---|---|---|
| time-command | 不会 | 按钮只等你按。你不敲 /time-command，它永远不会自己动 |
| time-agent | 可能会 | AI 看描述匹配上了意图，可以派这个分身——但报时这种一句话的活，专门开一个独立上下文，杀鸡用牛刀 |
| time-skill | 最可能 | 描述匹配、随叫随到、就在主对话里直接干活，最轻 |
这背后有一条隐含的择优顺序：当多种机制都能接同一个活时，Claude 挑最轻的那个。本能优先于分身，因为本能不额外开上下文；按钮永远不在竞争序列里，因为它只听你的手。
这个实验还有个有趣的续集：如果给 time-skill 加一行 disable-model-invocation: true（禁止 AI 自动触发），AI 就只能派 time-agent——为了报个时间开一个分身，纯属浪费。所以配置这三个东西时，"要不要让 AI 自动触发"是个真实的设计决策，不是可开可不开的开关。
什么时候该用哪个
把官方文档和团队实践里的建议归拢一下，每种机制的舒适区其实很清晰：
用 Command，当这个流程的入口永远是你。比如每天下班前按一次 /commit、开发完按 /deploy。判断标准很简单：这件事你一天要手动做超过一次，就值得做成按钮。它的内容在你按之前不占任何上下文，是最省的。
用 Skill，当这是一套可复用的操作知识。比如"画架构图的规范""抓天气数据的步骤"。它最妙的地方是能从多处被调起——AI 自己触发可以、你的按钮里可以调它、分身的口袋里也可以揣一份。写一次，到处用。
用 Agent，当任务是 autonomous 且多步骤的——它需要自己探索、自己决定、干一阵子才出结果；或者这个活儿很脏（大量搜索、大量试错），你不想让过程污染主对话。再或者，你希望它越干越懂你（持久记忆）。
实在拿不准时，问自己两个问题就够：**这活儿谁发起？过程重不重？**你发起的日常流程 → 按钮；AI 遇到就能用的知识 → 本能；又重又需要独立干的活 → 分身。
真正的用法：不是三选一，是排兵布阵
讲到这你可能会觉得"哦，那我每次挑一个就行"。素材仓库用一整套天气系统演示了更高阶的玩法——三者串成一条流水线：
你按下 /weather-orchestrator 这个按钮（Command 层：入口和编排）；它先派 weather-agent 这个分身出门查天气（Agent 层：独立上下文、自主干活），而这个分身出厂时就预装了 weather-fetcher 技能（预载的 Skill：查 API 的手册）；分身带着温度回来后，按钮再调起 weather-svg-creator 技能，在主对话里当场画出天气卡片（Skill 层：内联输出）。
一句话总结这条流水线的分工：入口用按钮，重活用分身，手册用本能。
这个模式几乎可以套到任何开发工作流上——把"查天气"换成"跑测试收集报错"，把"画卡片"换成"生成修复补丁"，就是一条质量修复流水线。第 9 篇我们会手把手把这套系统搭一遍，这里先建立整体感。
两个常见的反模式
素材仓库的 tips 区记录了两条高频错误，都比"不配置"更浪费时间：
反模式一：养万能分身。 新手最爱配一个名叫 qa 或 backend-engineer 的通用代理，觉得"一个顶 all"。但 Claude Code 作者 Boris Cherny 的建议正相反：要按 feature 配——"支付流程审查员"比"代码审查员"好用得多，因为分身的价值在专属的上下文和预载的技能，而不是头衔大。配上技能（渐进式披露）的专项分身，完胜光杆将军。
反模式二：把工作流写成 Agent，而不是 Command。 你的"部署流程"是固定步骤、由你发起的——它是按钮的料。写成 Agent 的后果：AI 可能在你不期望的时候自主触发它，而且一个不需要独立上下文的流程白白多开一层。Boris 的原话很直接：工作流用 commands，别用 sub-agents。
快问快答
Q：Skill 配了 context: fork 就等于 Agent 了吗？
接近但不等于。context: fork 让技能在隔离子上下文里跑（过程不进主对话），但它没有 Agent 的持久记忆、不能预载别的技能、也没有 maxTurns、permissionMode 这类分身级配置。可以理解为：fork 是"临时单次分身"，Agent 是"有编制的长期岗位"。
Q：三者的配置文件都要学一遍吗？
不用。日常 80% 的需求只用到每个机制的两三个字段：Command 记住 allowed-tools 和 $ARGUMENTS，Skill 记住 description 和 disable-model-invocation，Agent 记住 tools、model 和 skills。第 4、5 篇会分别把分身和技能的完整字段掰开讲。
Q：我应该先配哪个？ 按钮。它零门槛（一个 markdown 文件）、见效最快（今天就少说三遍重复的话）、而且做了不亏——以后想升级成流水线，它就是现成的入口。
收工清单
- 你发起的重复流程 → Command；AI 该自己会的知识 → Skill；重活、脏活、要记忆的活 → Agent
- 拿不准就问：谁发起？过程重不重？
- 多机制都能接活时，AI 自动挑最轻的——别为了小事派分身
- 分身要专项，不要通用；工作流写成按钮，别写成 Agent
- 高阶玩法是组合：按钮做入口，分身干重活，本能当手册
下一篇我们深挖其中最重的一个：Subagents 的完整实战——frontmatter 十几个字段怎么配、上下文隔离到底隔离了什么，以及怎么让分身们组队并行干活。