Claude Code的Skill和子代理到底有什么区别？一个共享上下文一个独立窗口

摘要：Skill和子代理（subagent）都能让Claude Code“多一项本事”，名字也都像扩展，所以特别容易混。但它俩的根本区别只有一句话：Skill在你的主对话里运行、和你共享同一个上下文窗口；子代理在自己独立的上下文窗口里干活、干完只把一句结论甩回来。这一个差别决定了一切——要在主对话里反复迭代、需要它看见前面聊过的东西，用Skill；要把一堆刷屏的脏活隔离出去、不污染主上下文，或者想给某类任务限制工具权限，用子代理。本文从机制讲到选择，把子代理的.claude/agents/配置、/agents命令、关键字段说清楚，再讲两者怎么配合，以及它和worktree、Agent Teams这几个隔离层级怎么分。

用Claude Code稍微深一点，绕不开两个词：Skill和子代理。问题是它俩听起来太像了——都是给它“增加能力”，都能让它去干一类特定的活，文档里还经常并排出现。于是很多人一直没真正分清：到底什么时候该写个Skill，什么时候该开个子代理？两个是不是一回事，换个名字而已？

不是。它们解决的是两个不同维度的问题，混用会让你的工作流别扭。保哥带团队落地这套东西时，发现卡住大家的几乎都不是“怎么写”，而是“该用哪个”——选错了，要么把该隔离的脏活全堆进主对话搞得一团乱，要么把需要持续对话的活塞进子代理，结果它看不见上下文干得稀烂。这篇就把这层窗户纸捅破：先讲清两者各自是什么、在哪运行，再给一套“该用哪个”的判断，最后说它俩怎么配合。

Skill和子代理，为什么总有人分不清？

根源在于，市面上的二手讲解经常只说“它们都能扩展Claude Code的能力”，然后举几个功能例子就完了，从不点破最关键的那个区别。你看到的都是“Skill能做X、子代理能做Y”，自然觉得不就是两套功能嘛，挑顺手的用。

但功能的相似是表象。真正把它们分开的，是它们各自在哪个上下文里运行。这是个底层的架构区别，一旦抓住，所有“该用哪个”的纠结都迎刃而解；抓不住，你就只能靠感觉瞎选。所以下面不从功能列表讲起，而是从“运行在哪”讲起。

先把那句根本区别放这儿，后面的内容都是在解释它：Skill在主对话的上下文窗口里运行，子代理在它自己独立的上下文窗口里运行。记住这句，往下看。

Skill到底是什么，它在哪里运行？

Skill是一段打包好的可复用指令或工作流。你把一套做法——比如“按我们团队的规范生成一个接口”或者“把这份数据整理成周报格式”——写进一个SKILL.md文件，需要时一句话触发，Claude就按里面的流程走。

关键在于它怎么运行：Skill被触发后，它的内容是加载进你当前主对话的上下文窗口的。这意味着它和你之前聊的所有东西共享同一块“记忆”——它看得见你刚才贴的代码、刚才讨论的需求、刚才它自己改过的文件。它就像给主对话现场注入了一段专业知识和操作步骤，然后Claude带着这段知识，在原来的对话里接着干。

这里有个常被误解的细节值得讲清。Skill用的是一种渐进式加载：平时只有它的名字和简短描述常驻在上下文里，占的地方极小；只有当任务匹配上、真要用它时，完整的SKILL.md内容才被加载进来。这套机制让你可以挂很多Skill而不撑爆上下文——没被触发的，几乎不占地方。所以Skill“省上下文”省的是“平时不加载”，但它一旦运行，运行过程是发生在主对话窗口里的，和你共享。

这就决定了Skill的适用场景：当你需要的是“在当前对话里，带着现有的全部上下文，按某套规范把活干了”。它不隔离、不分身，就是给主对话增援一套现成的做法。

打个比方，Skill像是你正在干活时，随手翻开的一本“操作手册”——你人还在原地，手里的活还是那摊活，只是手册告诉你这一步该怎么做得更专业。手册的内容进了你的脑子（主对话上下文），和你正在处理的东西混在一起用。这个比方能帮你记住它的关键特征：增援，但不分身；进场，但不隔离。关于Skill本身怎么设计、怎么写才好用、怎么把长流程拆进附属文件，站内的Skill设计模式那篇讲得很细，这里只聚焦它和子代理的分野。

子代理又是什么，凭什么说它“独立”？

子代理是另一回事。它是一个有独立身份的“专项助手”——有自己的系统提示、自己能用的工具、自己的权限，最重要的是，有一个全新的、和主对话隔开的上下文窗口。

很多二手资料把子代理讲得很轻，好像就是“把某个MCP功能封装一下”。这严重低估了它。官方的子代理文档讲得很清楚，它是一套完整机制：你在.claude/agents/目录下放一个带YAML头的Markdown文件，就定义了一个子代理；或者直接用/agents命令，走一个引导式界面把它建出来。Claude Code还内置了几个现成的子代理——只读、专跑搜索的Explore，规划阶段用的Plan，以及啥都能干的general-purpose，平时它会自动调用，你也能自己点名用。

“独立”体现在哪？当Claude把一个任务委派给子代理，这个子代理是从一张白纸开始的——它看不见你的对话历史、看不见主对话里已经读过的文件、看不见你之前触发过的Skill。Claude会写一段任务交接说明给它，它就拿着这段说明，在自己的窗口里独立干活。干完，它只把一份结论摘要返回主对话，中间产生的那一大堆过程——翻了几十个文件、刷了几百行日志——全留在它自己的窗口里，不进你的主对话。

子代理怎么被叫起来？两种方式。一种是自动委派——Claude会拿你的任务描述去比对每个子代理的description字段，匹配上了就自己把活分过去，你甚至不用点名。这也是为什么子代理的描述一定要写清楚，它是Claude判断“该不该委派给你”的唯一依据，描述里写上“主动使用”这类话还能鼓励它更积极地委派。另一种是手动指定：你可以在话里直接点名“用code-reviewer这个子代理看看我的改动”，也能用@提及锁定某个子代理，还能用--agent启动参数让整个会话都以某个子代理的身份运行。从随口建议到强制锁定，几档力度任你挑。还有一点容易被忽略——子代理之间是平级的，一个子代理不能再去开另一个子代理，需要多层委派时得回到主对话来串，或者改用别的机制。

这正是子代理最大的价值：隔离。官方文档把这个场景说得很直白——当一个边角任务会用一大堆你后面根本不会再看的搜索结果、日志、文件内容淹没你的主对话时，就让子代理在它自己的上下文里干这件事，只返回摘要。除了隔离上下文，子代理还能干两件Skill干不了的事：一是限制工具权限，比如配一个只读的代码审查子代理，连Edit和Write工具都不给它，从机制上保证它不会改你的代码；二是用更便宜的模型，把那些不需要顶级智力的脏活（跑测试、查文件）路由给Haiku这种又快又省的模型，控制成本。

“限制工具权限”这条在实际项目里比听起来重要得多。举个例子，你想让它审查一批改动、挑出问题，但你绝不希望它在审查过程中手痒顺手把代码改了——审查就该只看不动。光靠在提示里写“只审查不要修改”是不牢靠的，它是软约束，可能照做也可能没忍住。子代理能从机制上解决：配一个审查子代理，工具列表里只给Read、Grep、Glob这些只读工具，连Edit和Write都不挂，那它就算想改也无从下手，物理上不可能。这种“用权限边界代替口头叮嘱”的可靠性，是Skill给不了的——Skill跑在主对话里，用的是主对话的全部权限。需要“既要它干活、又要锁死它能干什么”的场景，子代理几乎是唯一靠谱的答案，这在涉及生产代码、敏感操作时尤其值钱。

一句话的根本区别：共享窗口还是独立窗口？

把前面两段压成一句对照，就是这篇的核心。

Skill运行在主对话的上下文窗口里，共享你的全部上下文，给当前对话增援一套做法——它不分身，是给原对话现场增援。子代理运行在自己独立的上下文窗口里，隔离于主对话，从白纸起步、独立干活、只回摘要——它是个分身，是把活外包出去。一个共享、一个隔离，一个增援、一个外包，这就是全部分野的源头。

所有别的差异，都是从这一条派生出来的。为什么Skill能接着用你刚才的讨论、子代理却要重新交接？因为一个共享窗口、一个独立窗口。为什么子代理能把刷屏的脏活挡在主对话外、Skill不能？同理。为什么子代理能限制工具权限、Skill是在主对话权限下跑的？还是同理。理解了“共享还是独立”这个根，剩下的全是推论。

从上下文管理的视角看，这俩其实是一对互补的工具。上下文窗口是有限的稀缺资源，装的东西越多越杂，模型注意力越分散、判断越容易飘。Skill帮你往主窗口里精准注入需要的能力；子代理帮你把不需要留在主窗口的过程挡在外面。一个做加法、一个做减法，方向相反，但都是在伺候同一件事——让主对话的上下文保持干净、聚焦。官方专门有一个上下文窗口的可视化演示，走了一遍子代理在自己窗口里做研究、主窗口保持清爽的全过程，想直观感受这个机制可以去官方的上下文窗口文档看那张图。

什么时候用Skill，什么时候用子代理？

有了根本区别，选择就有了准绳。下面是一套能直接套的判断。

这几种情况用Skill：任务需要频繁来回、反复迭代调整；多个阶段共享大量上下文（你边看它的产出边给反馈）；你要的是“按某套规范把当前这件事干了”，而这件事离不开前面聊过的背景。简单说，凡是“得在原对话里接着、看着现有上下文办”的活，都是Skill的主场。写周报、按团队规范生成代码、把刚讨论的方案落成文档，这类都属于。

这几种情况用子代理：任务会产生一大堆你不需要留在主上下文里的输出（跑整个测试套件、翻一大段文档、处理日志）；这活是自包含的，能独立干完、返回一个摘要就行，不需要中途跟你来回；你想强制限制某类任务的工具权限（只读审查、禁止写文件）；或者你想把廉价任务丢给便宜模型省钱。简单说，凡是“自己关起门干完、只要个结果”的活，都是子代理的主场。

还有个特别实用的反向判断：如果一个任务做完，它产生的中间过程你压根不想看，那就该用子代理把这些过程挡在外面。比如你让它“查一下这个函数在整个项目里被哪些地方调用了”，你要的只是那份调用清单，它翻文件的过程对你毫无价值——这种就是子代理的典型场景，让它在自己窗口里翻个底朝天，只把清单递给你。反过来，如果中间过程恰恰是你要参与、要把关的（比如一边重构一边你得确认每步对不对），那就别隔离，留在主对话用Skill或者直接对话。

官方还给了个更细的提示：如果只是想问一个关于当前对话里已有内容的小问题，连子代理都不用开，用/btw这种轻量方式问一句就行，它能看见你的全部上下文、但不占工具、答完就丢，比开子代理还轻。工具的轻重要配任务的轻重，别杀鸡用牛刀。

还有个延迟成本值得提一句，常被忽略。子代理是从白纸起步的，它得先花时间把上下文重新摸一遍才能干活，所以对那种“一句话就能办、改一个字”的小活，开子代理反而比直接在主对话里做更慢——隔离的好处抵不过重新建立上下文的开销。反过来，活越大、产出的噪音越多，隔离省下的上下文就越值钱，子代理的优势才显出来。所以选不选子代理，除了看“要不要隔离”，还要掂量“这活够不够大、值不值得为它重新交接一遍上下文”。小而频繁、需要来回的活，留主对话或用Skill；大而自包含、产出一堆中间垃圾的活，丢子代理。把这两个维度叠起来判断，基本不会选错。

同一个项目里，这俩到底怎么配合落地？

抽象讲完，拿保哥团队的一个真实场景走一遍，你会更有体感。这是个出海独立站的代码库，某次要做的事是“给商品详情页加一套A/B测试，同时把现有的几百个商品页的结构化数据补全”。这一件需求，恰好把Skill和子代理的分工照得清清楚楚。

先说结构化数据这块。“扫一遍所有商品页、检查结构化数据缺了哪些字段、列个清单出来”——这活会翻几百个文件、刷出一长串检查日志，而这些过程你一点都不想看，只要最后那份“哪些页缺哪些字段”的清单。典型的子代理场景。于是丢给一个子代理去扫，它在自己的窗口里翻个底朝天，主对话里干干净净，最后递回来一张缺漏清单。如果当初把这活留在主对话里干，几百行文件内容灌进来，后面做A/B测试时上下文早被噪音塞满了。

再说A/B测试这块。这是要在主对话里反复打磨的活——先讨论分流逻辑怎么设计、保哥看一版改一版、还得结合刚才那份结构化数据清单（因为测试variant也得带对结构化数据）。它离不开现有上下文、需要来回迭代。典型的Skill场景。团队早就把“按我们规范搭A/B测试”沉淀成了一个Skill，触发它，它带着主对话里已有的全部背景，按规范把骨架搭出来，你盯着调。

你看，同一个需求，刷屏的脏活外包给子代理隔离掉，需要盯着迭代的活留在主对话用Skill增援，两个工具各司其职，互不打架。这就是为什么说它们是搭档不是对头——分清了哪段活属于哪个维度，工作流自然就顺了。选错的代价也在这例子里：要是把扫描脏活留在主对话、把A/B测试塞进一个看不见上下文的子代理，结果就是主对话被日志淹没、子代理因为不知道前面的讨论把测试搭得驴唇不对马嘴。

子代理具体怎么配，有哪些字段能调？

既然子代理是重头，把它的配置讲清楚。最省事的是直接跑/agents命令，走引导式界面：选位置（项目级还是个人级）、让Claude帮你生成系统提示、勾选它能用的工具、选模型、甚至给它配个持久记忆，一路点下来就建好了，建完立即可用。

想手写或者想精细控制，就在.claude/agents/（项目级，可提交Git团队共享）或~/.claude/agents/（个人级，所有项目可用）下写Markdown文件。文件头的YAML定义配置，正文是这个子代理的系统提示。常用字段值得记住几个：

---
name: code-reviewer          # 唯一标识，必填
description: 代码审查专家，改完代码后主动调用   # 决定Claude何时委派给它，必填
tools: Read, Grep, Glob, Bash  # 只给这几个工具，连Edit/Write都没有
model: sonnet                # 这个子代理用哪个模型，可填haiku省钱
---

你是一名资深代码审查员，专注代码质量与安全……（这里写它的系统提示）

只有name和description是必填的，其中description尤其关键——Claude就是靠它来判断“这个任务该不该委派给这个子代理”，所以描述要写得清楚，想让它被主动调用还可以在里面写上“主动使用/proactively”这类话。其余字段都是可选的精细控制：tools用白名单限定它能用的工具，disallowedTools反过来用黑名单排除某些工具；model能给它单独指定模型；permissionMode控制它怎么处理权限提示；memory给它一个跨会话的持久记忆目录，让它把“这个项目的模式、踩过的坑”攒下来越用越聪明；skills字段还能在它启动时预载几个Skill进它的上下文——这点下一节细说。字段很多但不用全配，绝大多数子代理写好name、description、tools、model这四样就够用了。

这里顺带说说那几个内置子代理，因为日常你接触最多的其实是它们。Explore是只读的，专干搜代码、找文件、摸清代码库这类活，默认用又快又便宜的Haiku模型，跑研究既快又省；它有个特点，为了快，会跳过CLAUDE.md不加载。Plan是规划模式下用的，帮你在出方案前把代码库摸清楚。general-purpose则是个全能选手，又能探索又能动手，适合那种既要搜又要改的复杂多步任务。这几个平时Claude会按情况自动调用，你大多数时候根本意识不到——但理解它们的存在，你就明白为什么有时候让它“查点东西”它特别快：那是Explore在它自己的窗口里替你跑，结果回来主对话还是干净的。自己建的自定义子代理，本质就是在这几个内置款之外，补上你项目特有的专项分身。

Skill和子代理能配合用吗？

能，而且配合起来很有意思——它俩不是二选一的对头，是能叠在一起的。

最直接的配合，是用子代理frontmatter里的skills字段，在子代理启动时就把某些Skill的完整内容预载进它的独立上下文。这等于给这个分身“开局就发了一套专业手册”。举个例子：你配一个专门实现接口的子代理，把团队的“接口规范”和“错误处理模式”两个Skill用skills字段预载进去，那它一开工就带着这些规范，在自己隔离的窗口里按规矩把接口写出来，写的过程不污染你的主对话，写完交一份成品回来。这就把“隔离”和“专业规范”两个好处合到了一起。

反过来也行：子代理在自己窗口里干活时，照样能通过Skill工具去发现和调用项目里、个人的、插件提供的Skill，不需要你提前在skills字段里列。skills字段控制的是“开局预载哪些”，不限制“运行中能调哪些”。

所以一个成熟的工作流里，常常是这样的分工：Skill承载“怎么做”的规范和流程，子代理承载“在哪做、用什么权限做”的隔离边界，两者叠加，你既能复用沉淀好的做法，又能把脏活和敏感操作关在隔离的窗口里。把这两个工具当成搭档而不是替代品，你的Claude Code工作流会清爽很多。

子代理、worktree、Agent Teams又怎么分？

最后还要拎清一组容易连环混淆的概念。子代理讲的是“上下文隔离”，但Claude Code里还有另外两个带“隔离/分身”味道的东西，层级不一样，一起捋顺。

子代理隔离的是上下文：在同一个会话内，开几个有独立上下文窗口的分身分头干活，干完汇总回主对话。它解决的是“别让脏活弄脏主对话”。

worktree隔离的是文件工作区：借Git的工作树机制，给不同任务各自一份互不干扰的代码副本，让Claude能在多个分支上同时改动而不互相踩脚。它解决的是“多条改动线别在文件层面打架”。子代理还能配合worktree用——给子代理设上隔离参数，它的文件改动就写进一个单独的worktree，不碰你的工作区。

Agent Teams是更重的一层：它开的是几个能互相通信的独立会话来协作，每个队友有自己完整的上下文，适合需要长时间并行、单个上下文窗口装不下的大工程。它和子代理的关键差别是：子代理在单个会话内、干完就回；Agent Teams是多个会话之间能对话协同。这块的实验性功能、怎么开、怎么配队友，站内的Agent Teams那篇专门讲过。

一个简单的记法：子代理分上下文，worktree分文件，Agent Teams分会话。复杂度从低到高，按需往上加。日常绝大多数“把脏活隔出去”的需求，子代理就够了；要并行改好几个分支，加worktree；真要搞需要多个智能体长时间协同的大工程，才上Agent Teams。而Skill和这三者都不在一个维度上——它是往主对话里注入能力的，不隔离任何东西。把这四个东西的边界划清，你就不会再在“该用哪个”上犯迷糊了。顺带一提，如果你还想把Skill和更上层的MCP、Hooks放一起比，站内有一篇MCP、Skills、Hooks怎么选做了横向拆解，和本篇正好互补。

常见问题解答

Skill和子代理最根本的区别到底是什么？

一句话：运行在哪个上下文窗口。Skill加载进你的主对话窗口，和你共享全部上下文，看得见前面聊过的东西；子代理在自己独立的窗口里从白纸起步，看不见主对话历史，干完只回一份摘要。所有别的差异都是从这一条派生的。

什么时候该用Skill，什么时候该用子代理？

需要在主对话里反复迭代、依赖现有上下文办事，用Skill；任务会刷出一大堆你不想留在主上下文的输出、能自包含地干完只要个结果，用子代理。一个反向判断：如果某任务的中间过程你压根不想看，就用子代理把它挡在主对话外。

子代理是不是就是把一个MCP功能封装一下？

不是，这是被二手资料带偏的误解。子代理是一套完整机制：在.claude/agents/下用带YAML头的Markdown定义，有独立上下文窗口、自己的系统提示、可限制的工具权限、可单独指定的模型，还有内置的Explore、Plan、general-purpose可直接用。它远不止封装某个功能。

Skill和子代理能一起用吗？

能。最常见的配合是用子代理frontmatter的skills字段，在子代理启动时把某些Skill预载进它的独立上下文，等于给这个隔离的分身开局发一套专业规范。子代理运行中也能自己通过Skill工具调用其他Skill。两者是搭档不是替代。

子代理、worktree、Agent Teams有什么不一样？

子代理分上下文，在单会话内开独立窗口的分身干脏活；worktree分文件，给不同任务各一份Git代码副本避免改动打架；Agent Teams分会话，开多个能互相通信的独立会话协同大工程。复杂度从低到高，按需往上加，大多数隔离需求子代理就够。