一、两者的职责

技能解决的是「知识太多、不必每轮都在」。它把做法写成一份文件，触发时读进来。 子智能体解决的是「过程太脏、不该进主窗口」。它开一个新窗口去做，只交回结论。 一个管内容，一个管上下文。两者不冲突，也不互相替代。

所以「该用技能还是子智能体」这个问题问错了。正确的问法是：这件事的做法要不要沉淀？过程要不要隔离？ 两个答案可以都是「要」。 两个都要的时候，组合方式只有一种：技能提供做法，子智能体提供工作区。

二、三路做法实测

任务：给五个模块补单元测试，项目有五条约定（有断言、用 pytest、覆盖异常分支、有 fixture、 文件放 tests 下）。 只用技能：主窗口按技能正文的步骤一个个写。五条全中，但五个模块的测试代码全堆在主窗口。 只用子智能体：派一个去写，不告诉它项目规范。主窗口干净，五条只中三条。

漏的两条恰好是「用 pytest」和「有 fixture」——两条项目特有的约定。它不笨，只是没人告诉它。 技能加子智能体：技能说怎么做，子智能体在那边做。五条全中，主窗口也干净。

三、规矩写在哪，差别很大

规矩写在技能里，五个子智能体共用一份。改一次，五处生效。 规矩写进每一条指令，改一次要改五处，而且很容易漏一处。 这就是依赖倒置的那个道理：调用方依赖的是「有一份规范」，不是规范里的每一条（4.7 节）。

实际操作上有个折中：技能里写全套规范，派出去的指令里写「按 deploy-check 技能里的规范做」。 子智能体能不能读到那个技能，取决于实现——读不到就只好把关键几条抄进指令。 抄的时候只抄「会做错的那几条」。全抄一遍等于把技能正文又复制一份，改的时候两处都要改。

四、一次组合的代价

演示里指令八十一 token、回传五十 token，一次委派多花一百三十一。 这一百三换的是：主窗口里没有五个测试文件，只有一条回执。 所以值不值，取决于「后面还要不要接着干」。要接着干，这一百三很值；问完就结束，这一百三纯亏。

还有一个隐性收益：规矩写在技能里之后，子智能体的指令可以很短——短指令也意味着更少的误解空间。 反过来说，把一个技能的全部正文抄进指令，不只是浪费 token， 还会让子智能体分不清哪句是「这次的要求」、哪句是「一直的规矩」。

五、什么时候不需要组合

活很小、又不脏主窗口：直接在主窗口做，别派。技能一个人就够。 活很脏、但没有固定做法：只派子智能体，把要求写在指令里。这种活通常是一次性的。 活有固定做法、又不脏：只写技能。比如「怎么回答某类问题」，不需要独立窗口。

只有「有固定做法」加「过程很脏」同时成立，组合才划算。两个条件缺一个，就用单个。 这个判据和 4.4 节选形状的判据是一路的：先看这次要什么，再看哪种组合给得起。

六、动手 Demo：技能和子智能体，谁管什么

任务：给五个模块补单元测试。项目有五条约定，三种做法：只用技能、只用子智能体、两者组合。 比较五条约定的合规率，再算一次委派多花多少。

NEED = [u"有断言", u"用 pytest", u"覆盖异常分支", u"有 fixture", u"文件放 tests 下"]

SKILL_OK = [1, 1, 1, 1, 1]   # 技能正文写了五条，照着做就合规
SUB_OK   = [1, 0, 1, 0, 1]   # 子智能体不知道规范，五条里中三条
BOTH_OK  = [1, 1, 1, 1, 1]   # 技能说怎么做，子智能体在那边做

实跑输出：

--------------------------------------------------------------------
技能和子智能体，谁管什么
--------------------------------------------------------------------

  任务：给五个模块补单元测试。三路做法：只用技能、只用子智能体、技能加子智能体。

  ① 三路做法
  --------------------------------------------------------------------
| 做法 | 怎么跑 | 结果 |
|---|---|---|
| 只用技能 | 主窗口按技能正文的步骤一个个写 | 懂规范，但噪声进主窗口 |
| 只用子智能体 | 派一个去写，不告诉它项目规范 | 干净，但产出不合规 |
| 技能加子智能体 | 技能说怎么做，子智能体在那边做 | 懂规范，且不脏主窗口 |


  ② 五份产出的合规率
  --------------------------------------------------------------------
| 规范要求 | 只用技能 | 只用子智能体 | 技能加子智能体 |
|---|---|---|---|
| 有断言 | 是 | 是 | 是 |
| 用 pytest | 是 | 否 | 是 |
| 覆盖异常分支 | 是 | 是 | 是 |
| 有 fixture | 是 | 否 | 是 |
| 文件放 tests 下 | 是 | 是 | 是 |

  只用技能五条全中，但它的产出是在主窗口里写的——五个模块的测试代码全堆在主窗口。
  只用子智能体五条中三条，漏的恰好是「用 pytest」和「有 fixture」这两条项目特有的约定。
  它不笨，只是没人告诉它。

  ③ 谁补谁的短
  --------------------------------------------------------------------
  技能懂「怎么做」——它写着项目里测试该怎么写、放哪、断言什么。
  但它只能在调用它的那个窗口里做，噪声全留下。
  子智能体懂「在别处做」——它有独立窗口，噪声不进主窗口。
  但它不知道这个项目的规矩，除非有人写在派它出去的那段话里。
  所以组合的办法很自然：技能负责「怎么做」，子智能体负责「在哪做」。
  派它的时候，把那几条规矩写进指令里。
  ! 顺带一个工程上的好处：规矩写在技能里，五个子智能体共用一份；
  规矩要是写进每一条指令，改一次要改五处。这和依赖倒置是一回事（4.7 节）。

  ④ 代价：一次多花多少
  --------------------------------------------------------------------
  指令 81 token、回传 50 token，一次委派多花 131。
  这 131 换来的是：主窗口里没有五个测试文件，只有一条回执。
  后面还要继续改别的东西时，这 131 值不值就看得出来了。

①三路做法：只用技能（懂规范但噪声进主窗口）、只用子智能体（干净但产出不合规）、组合（两头都要）。 ②五条合规率里，只用技能五条全中； 只用子智能体五条中三条，漏的恰好是「用 pytest」和「有 fixture」两条项目特有的约定。 它不笨，只是没人告诉它。这一条是整节的关键：子智能体不知道的规矩，它不会问。 ③技能懂「怎么做」，但它只能在调用它的那个窗口里做，噪声全留下； 子智能体懂「在别处做」，但它不知道这个项目的规矩。 所以组合的办法很自然：技能负责「怎么做」，子智能体负责「在哪做」， 派它的时候把那几条规矩写进指令里。 顺带一个工程上的好处：规矩写在技能里，五个子智能体共用一份；写进每条指令，改一次要改五处。 这和依赖倒置是一回事。 ④代价：指令八十一 token、回传五十 token，一次委派多花一百三十一。 这一百三换来的是主窗口里没有五个测试文件，只有一条回执。 后面还要继续改别的东西时，这一百三值不值就看得出来了。

30 秒实验

1. 把「文件放 tests 下」这条规矩从技能里删掉，重跑第 ② 步。组合那一列会掉到几条？ 这说明技能里哪些条目是必须的？
2. 把指令从八十一 token 写到三百（把整份技能正文抄进去），重跑第 ④ 步。合规率会涨吗？成本涨多少？
3. 把任务改成「只补一个模块的测试」，重跑三路。组合还划算吗？不划算的话，边界在哪？

常见误区

1. 把技能和子智能体当成二选一。它们管的是两件不同的事：内容和上下文。
2. 指望子智能体自己发现项目规矩。它不知道的不问，只会按通用做法来。
3. 把整份技能正文抄进委派指令。既浪费 token，又让子智能体分不清「这次要求」和「长期规矩」。
4. 规矩写进每一条指令而不放技能里。改一次要改五处，必漏一处。
5. 小活也走组合。活不脏主窗口时，一层委派带来的不确定性比省下的空间更贵。

组合方式有了，下一节算清这笔账：派出去到底省不省、什么时候才划算。

• ☐ （本篇完，下一篇 4.6 Token 经济学）

相关笔记

• 五种模式：五种分工形状
• Token 经济学：总账怎么算
• Skill 提效实战 · 索引
• 🐎 Claude Code 实战 · 索引