脚本和能力的分界不在复杂度，在「带不带上下文」。 三个信号：被反复调、要解释参数、要多带一份上下文。后两个是真正的判据。 Demo 里四个脚本，两个该升级——共同点是「每次都得解释一遍」。
前面两章装了说明书和护栏。这一章装能力。 为什么先说护栏再说能力？ 因为能力越强，出错半径越大。 没有护栏的能力装配，是把更强的工具交给一个还没被约束住的手。 Demo 造四个小脚本，用调度器真跑十次任务，数出每个被调用几次。 结果是四次、三次、两次、一次——分布很不均，而这不均就是信号。
一、脚本是给人和机器都能跑的
脚本的特点是「参数即全部」。
python tools/fmt.py 就是全部信息——
它在哪个仓库跑、为什么跑、跑完该看什么，脚本自己不知道。
这个特点在两种情况下是优点：
人手动跑的时候，上下文在人脑子里；
另一个脚本调它的时候，上下文在调用代码里。
但在第三种情况下就是缺点：Agent 调它。
Agent 没有「脑子里的上下文」，它只有你给它的东西。
所以它得先猜「这个脚本什么时候用」，猜错就白跑一轮。
这就是能力化要解决的问题：
不是让脚本更聪明，是让它自带一份「什么时候该用我」。
二、能力化的三个信号
| 信号 | 怎么判断 | 为什么 |
|---|---|---|
| 被反复调 | 数调用次数 | 调得越多，解释成本越高 |
| 要解释参数 | 每次都要说「加哪个参数」 | 说明参数不直观 |
| 要多带上下文 | 要连规则、约定一起说 | 说明它离不开环境 |
三个信号里，第一个最好算，后两个靠感觉。 但真正的判据是第三个。 Demo 里 fmt 和 test 都中了三个信号，tree 和 count 一个都没中。 注意它们的差别不在「复杂度」——四个脚本都是一两行，复杂程度差不多。 差别在「要不要多带一份上下文」。 fmt 要知道本仓库的缩进约定，test 要知道测试入口在哪儿—— 这些信息脚本自己装不下，只能每次由人说一遍。 说一百遍之后，就该把它写下来。
三、Harness 不是框架，是装配
这一课反复出现的 Harness，容易被人当成某个库。 它不是。 它指的是「把脚本、规则、上下文装成一套」这个动作。
| 东西 | 是什么 | 谁用 |
|---|---|---|
| 脚本 | 一个能干活的零件 | 人和机器 |
| 能力 | 零件加一份说明书 | 主要给 Agent |
| Harness | 装配图 | 谁都不直接跑 |
判断一个东西是不是 Harness，看它有没有「装配」这个动作： 它决定哪个零件在什么时候被拿起来。 所以 Harness 是长出来的，不是选出来的。 你先有几个脚本，再发现某几个总被反复调，然后给它们补说明书， 最后才意识到「这套东西需要一个装配图」。 反过来做——先选一个框架再往里填——通常填不满。
四、动手 Demo：能力化的三个信号：四个脚本，哪两个该升级
四个一两行的小脚本，一个调度器真跑十次任务，数出每个被调几次。
然后按三个信号打分，看哪两个该升级成能力。
调用次数是真数的，不是我编的——调度器真的用 subprocess 起了十次子进程。
TASKS = [("改注释", "fmt"), ("跑测试", "test"),
("查目录", "tree"), ("统计行数", "count")]
used = {}
for name, tool in TASKS * 2 + TASKS[:2]:
used[tool] = used.get(tool, 0) + 1
subprocess.run([sys.executable, MAP[tool]], capture_output=True)
print(json.dumps(used, ensure_ascii=False, sort_keys=True))
实跑输出：
--------------------------------------------------------------------
能力化的三个信号：四个脚本，哪两个该升级
--------------------------------------------------------------------
① 一个调度器，跑十次任务
--------------------------------------------------------------------
fmt 被调用 4 次
test 被调用 3 次
tree 被调用 2 次
count 被调用 1 次
十次任务，四个脚本合计被调用十次。次数分布很不均：fmt 4 次、test 3 次、tree 2 次、count 1 次。
② 三个信号，逐条对
--------------------------------------------------------------------
| 脚本 | 调用次数 | 要解释参数 | 要上下文 | 得分 | 结论 |
|---|:---:|:---:|:---:|:---:|---|
| fmt | 4 | 是 | 是 | 3/3 | 该能力化 |
| test | 3 | 是 | 是 | 3/3 | 该能力化 |
| tree | 2 | 否 | 否 | 0/3 | 留着当脚本 |
| count | 1 | 否 | 否 | 0/3 | 留着当脚本 |
两个该能力化：fmt 和 test。它们的共同点是「被反复调，而且每次都得解释一遍」。
! 三个信号里，第一个（被反复调用）最好算，后两个要靠感觉。
但真正的判据是第三个：这个脚本要不要「多带一份上下文」才能跑对？
要，它就不该是脚本，该是一个能力。
③ 能力化之后长什么样
--------------------------------------------------------------------
---
name: repo-fmt
description: 本仓库的格式化规则。当需要清理行尾空白或统一缩进时使用。
---
## 什么时候用
改完文件、提交之前。
SKILL.md 三样：什么时候用、怎么做、别做什么。第三样最容易被漏——而它恰恰是脚本给不了的。
④ 脚本和能力的分界
--------------------------------------------------------------------
| 东西 | 谁能跑 | 带不带上下文 |
|---|---|---|
| 脚本 | 人和机器都能跑 | 不带，参数即全部 |
| 能力 | 主要给 Agent 用 | 带一份「什么时候用」 |
| 框架 | 谁都不直接跑 | 管装配 |
! 所以「能力化」不是把脚本包装一下，是给它补上「什么时候该用」这个信息。
脚本不知道自己的使用场景，能力知道。
⑤ Harness 不是框架，是装配
--------------------------------------------------------------------
这一章反复出现的 Harness，指的不是某个库，是「把脚本、规则、上下文装成一套」这件事。
! 判断一个东西是不是 Harness，看它有没有「装配」这个动作：脚本是零件，
Harness 是那套装配图——它决定哪个零件在什么时候被拿起来。
四次、三次、两次、一次。
这个分布不是随机的——它反映的是「哪些动作在流程里出现得早」：
改文件（fmt）几乎每个任务都有，跑测试（test）次之，查目录（tree）更少，
统计行数（count）只出现一次。
表格里两个三分的，恰好是「要解释参数」和「要上下文」都中了的。
而 tree 和 count 一个都没中——它们不需要额外信息，参数就是全部。
第三段那张 SKILL.md 是能力的样子：三样内容，「什么时候用、怎么做、别做什么」。
第三样最容易被漏，而它恰恰是脚本给不了的——脚本不知道「别顺手改缩进风格」这种话该说。
最后那张三行表要分清：脚本是零件，能力是带说明书的零件，Harness 是装配图。
三者不是三个等级，是三个角色。
30 秒实验
- 数一下你这周跑得最多的那三条命令。 每条跑了几次？超过十次的，就值得写个说明。
- 找一条「每次都要解释参数」的命令。 解释的那句话，就是它该有的说明书。
- 给你的项目画一张装配图：哪个脚本在哪个环节被拿起来。 画不出来的环节，说明那个环节靠人记着。
常见误区
- 「能力化就是把脚本包装成插件。」 包装解决不了「它不知道自己什么时候该用」。 能力化的核心是补上下文，不是补接口。
- 「所有脚本都该能力化。」 Demo 里四个脚本只有两个该升级。 一次性脚本能力化了，成本是常驻的，收益是一次性的。
- 「先选框架，再往里填。」 Harness 是长出来的。 先有零件和反复调用的场景，装配图才有内容可画。
自测三问（点开对答案）
1. 脚本和能力的分界在哪儿？ —— **在「带不带上下文」。** **脚本是参数即全部；能力额外带一份「什么时候该用我」。** 2. 三个信号里哪个是真正的判据？ —— **第三个：要不要多带一份上下文。** **前两个是征兆，第三个是病因**——**因为上下文装不下，才需要每次解释。** 3. 为什么 Harness 不该先选框架？ —— **因为装配图要有内容可画。** **先有零件和反复调用的场景，才谈得上装配；先选框架通常填不满。**下一篇 8.2 讲拆分：Subagent 拆的是上下文，不是工作量。
- ☐ （本篇完，下一篇 8.2 Subagent 如何拆分复杂任务）