Claude 技能、斜杠命令与子代理的区别

2026 年 8 月更新。

摘要： 斜杠命令是你经常输入的提示词的简写——你按名字调用它。子代理是拥有独立上下文窗口的并行工作者——你（或 Claude）为一项有边界的任务生成它，然后拿回结果。技能是打包好的专业知识，Claude 会根据你的请求内容自行决定是否加载，无需你命名任何东西。大多数人本该用斜杠命令时却去搭建自定义代理，本该用技能自动触发时却又去用斜杠命令。

【操盘者视角】 我在两家公司同时运行着 30 多个生产环境代理，几乎每一个的第一个设计问题都是这个——用命令、子代理还是技能。选错了，你要么造出十个没人记得住名字的命令，要么造出一个宽泛到永远无法可靠触发的技能。解决方法不是一条经验法则，而是问清楚每次运行之间到底哪些东西在变化。

Table of contents

Open Table of contents

• 这三种原语解决的是不同的问题
• 斜杠命令：你经常输入的提示词的简写
• 子代理：拥有独立上下文窗口的并行工作者
• 技能：Claude 自行加载的打包专业知识
• 决策框架
• 我见过最多的错误
• 操盘者的结论
• FAQ
  • Claude 技能和斜杠命令有什么区别？
  • 什么时候该用子代理而不是技能？
  • 让技能自动触发发布或花钱这类操作安全吗？
  • 我最终需要把三种都建起来吗？

这三种原语解决的是不同的问题

三者都能让你把指令打包一次、反复复用。相似之处到此为止——而这恰恰也是人们把它们混为一谈的原因：从外部看，“输入一小段东西然后得到有用的结果”看起来都一样，无论底层到底是谁在干活。

真正的区别在于谁来决定调用它，以及它在什么上下文中运行：

• 斜杠命令由你按名字调用。你输入 /deploy 或 /review，Claude 把它展开成更完整的指令，并在你当前的对话中运行。
• 子代理由你或 Claude调用，用于边界清晰的任务。它拥有自己的上下文窗口，完成工作后汇报结果——它看不到你整个对话，你也看不到它的中间步骤，除非你主动询问。
• 技能由Claude自动调用，当你的请求匹配该技能描述所覆盖的内容时触发。你从不需要输入它的名字。如果你没有提出该技能能处理的请求，它就永远不会被加载。

第三个特性——无需显式调用——正是被人们低估的那个。一旦你打包的工作流超过几个,它也会成为杠杆最大的那个，因为你不再需要记住自己给东西起了什么名字。

斜杠命令：你经常输入的提示词的简写

当触发条件是“我一直在输入基本相同的指令”时，就该搭建一个斜杠命令。命令总是解析成同一段底层提示词，从你选定的一个简短名字展开，在你已经进行的对话中运行。没有独立的上下文，没有自主调用——由你决定它何时运行，每一次都是。

适合的场景：固定的发布检查清单、内置了你个人规则的代码审查流程、一个“总结这个 PR”的快捷方式。命令不需要判断是否该运行——按下它的人是你，这个判断由你来做。

失败模式是为某件实际上需要模型自行判断是否适用的事情搭建了命令。如果你有一半的使用场景都是“等等，这种情况算不算数”——那是一个技能问题，不是命令问题，因为命令没有办法自己触发自己。

子代理：拥有独立上下文窗口的并行工作者

当任务边界清晰、可委派，并且如果放进主对话只会带来一堆你不需要看到的步骤时，就该搭建一个子代理。子代理运行在自己的上下文里——自己的工具调用、自己的来回沟通——然后交回一个结果。这和我在上下文工程那篇文章里写的原则是一致的：每一次额外的工具调用和中间步骤都是你主线程不需要承载的上下文，而子代理正是把这些噪音挡在外面的方式。

适合的场景：“研究一下这个然后汇报结果”“并行跑这五项独立检查”“单独去修好这一个文件”。这类任务有开始、有结束、有交付物——这正是我用来交付代理的评测框架当作单一可评分单元来处理的形状。

失败模式是为某件本该留在主上下文里的事情生成了子代理，因为下一步依赖的细节被子代理的摘要漏掉了。如果你不停地要反过来问子代理“等等，你到底发现了什么”，说明边界划错了——要么把它折回主线程，要么让子代理的汇报结构化到足以确保翻译过程中不会丢失任何东西。

技能：Claude 自行加载的打包专业知识

当触发条件是 Claude 应该从你的请求中自行识别、而不是你必须记住去命名的东西时，就该搭建一个技能。技能是一段描述加上一捆指令和脚本；Claude 读取描述，判断你的请求是否匹配，只有匹配时才会加载完整指令。你从不需要输入 /skill-name。

我能举出的最清晰的例子，就是驱动这个博客背后流水线的那个技能。Alejandrorioja.com 用 13 种语言发布内容，而生成 → 翻译 → 渲染 → 审核的整个流程都装在一个技能里：一个描述何时使用它（“生成一篇新文章”“翻译成所有语言”“起草一条推广文案”）的 SKILL.md 文件，加上实际干活的脚本。我不需要运行四个独立的命令并记住它们的顺序。我只需用大白话说出我想要什么，这个技能的描述足够具体，Claude 就会识别并执行正确的步骤——就像那个跑我 Facebook 广告的技能在我说“查一下我的广告”时会自动触发，而我根本不需要输入命令名。

这个设计选择——让技能自己决定何时适用——也是为什么这里的安全默认值比命令或子代理更重要。斜杠命令只有在你输入时才运行；技能是在模型认为应该运行时就运行。我的内容技能默认只起草文稿，在任何东西发布或推送之前都需要一个明确、独立的批准步骤——这和我在任何技能可能自行触发出具有真实后果的操作时都会用到的人机协同模式是一样的。

适合的场景：任何有可识别触发短语、背后有可重复流程的事情——“生成一份报告”“给这份作业打分”“为 Slack 起草一条摘要”。失败模式是技能描述宽泛到你不想要它触发时它也触发了，或者狭窄到你想要它触发时它却没触发。写描述的方式，应该像你在向一个新员工解释触发条件，而不是像你在给一个函数命名。

决策框架

问这个问题	如果是 →	原因
我是否总想输入一个名字来触发它？	斜杠命令	触发者是你，不是模型
任务是否边界清晰、可委派，并且最好不出现在我的主上下文里？	子代理	拥有独立上下文窗口，返回结果
Claude 是否应该在我不点名的情况下自行识别需求？	技能	按描述匹配，自动调用
它是否涉及资金、发布，或任何难以撤销的事情？	三者皆可，但需加一道明确的批准关卡	自动调用不等于自动执行

大多数真实的工作流是这三者的组合叠加，而不是单选一个。我的内容流水线是一个技能（在我说“写一篇文章”时自动触发），内部会调用子代理（每个语言一个，并行运行），并对外暴露一个斜杠命令（/publish）——专门用于那一步“正式发布”，绝不应该在我没有明确说出口的情况下发生。

我见过最多的错误

为某件实际上只是穿着戏服的斜杠命令的事情，搭建一整套自定义代理——有自己的调度、自己的状态、自己的部署。如果任务是“我说了就按这个确切流程执行”，你不需要自主性、不需要记忆、不需要触发条件。你需要的是一个名字和一段提示词。把子代理和技能这套机械留给边界（子代理）或触发条件（技能）真正在发挥作用的任务，而不是给本来就简单的事情硬加基础设施。

操盘者的结论

在你思考怎么搭建之前，先问谁来决定调用它。你自己每次按名字来决定 → 斜杠命令。一项你想挪出主上下文的边界任务 → 子代理。Claude 自行识别需求 → 技能，并对任何无法撤销的事情加一道批准关卡。把这一个问题问对了，剩下的——文件里该放什么、该打包多少指令——大多会自然而然地水到渠成。

FAQ

Claude 技能和斜杠命令有什么区别？

斜杠命令是显式调用的，每次你想让它运行时都要按名字触发。技能是自动调用的——Claude 会把你的请求与技能的描述做匹配，匹配上就加载它，无需你命名任何东西。当你总是自己决定要不要触发时，用命令；当触发条件是模型应该自行识别的东西时，用技能。

什么时候该用子代理而不是技能？

当任务边界清晰、可委派，并且你希望它在自己的上下文窗口里运行，与你的主对话分开——这不是关于如何被触发，而是关于工作发生在哪里。技能和子代理并不互斥：一个技能内部可以生成子代理，就像一个翻译技能可能把一篇文章分发给每个语言各一个子代理。

让技能自动触发发布或花钱这类操作安全吗？

只有在关键步骤上加了明确的批准关卡才安全。技能本身的自动调用没问题——那只是说明 Claude 识别出了你的需求。风险在于任何难以撤销的事情的自动执行。让自动触发的技能只做起草、阅读和汇报；对发布、付款或删除这类操作，要求一个独立、明确的确认。

我最终需要把三种都建起来吗？

只有当你的工作流真的具备这三种形状时才需要。一个只有少数几个可重复任务的单人操盘者,可能会长期只靠斜杠命令就过得很好。当你拥有足够多不同的触发条件、多到记不住命令名字，或者拥有足够多边界任务、多到放进主上下文会拖累质量时，对技能和子代理的需求才会显现出来。

---

相关文章： 那个跑我 Facebook 广告的 Claude 技能 · 上下文工程：上下文窗口里该放什么 · 人机协同 AI 代理：何时该搭建批准关卡 · 我用来运行 30 多个生产代理的代理技术栈

需要帮忙决定该自动化什么、怎么做？联系我——我为运营团队设计生产级代理系统。