一、三者的分工

这三行要按顺序读：先问「怎么做」有没有共识，再问「一次装不装得下」， 最后问「工具要不要常驻」。 顺序反了会怎样？ 先接一堆 MCP，再发现「怎么做」根本没统一——那工具描述白占了窗口，因为流程还没定。 一个反例很常见： 为了「让它能查数据库」，先接一个数据库 MCP；接完才发现「查什么、怎么算对」还没定。 这两件事的先后不该反。

二、复杂度预算

「预算」这个词是认真的：每加一个组件，都有一份常驻成本。

注意第三行是「全程」——MCP 的工具描述从一开始就在窗口里，不管这次任务用不用。 而 Skill 是「被触发时」才加载，子 Agent 的结论只在汇总时需要。 所以三者的成本性质不一样： Skill 像按次收费、子 Agent 像按件收费、MCP 像月租。 月租最贵——因为不管你用不用。

三、本章小结

下一章进第三部分：四个实战场。 这一章装的是能力，下一章开始用这些能力干活——从「一个真需求怎么落地」开始。 这一章最该带走的一句： 复杂度不是能力，是负债。 每加一样东西，都要能从账上找到它替掉的那一样。

四、动手 Demo：复杂度预算：三者协同，不是堆叠

三套方案，各算常驻成本和收益。 收益按边际递减估：第一件六成、第二件两成、第三件一成、之后每件半成。 要说明的是：这个收益模型是粗的，只用来比较三套方案的相对关系， 不代表真实项目的成功率。成本那几个数也是估值，不是实测。

PLANS = [(u"朴素", 1, 0, 0), (u"中等", 2, 2, 1), (u"堆叠", 6, 5, 4)]

for name, sk, sa, mc, why in PLANS:
    cost = sk * 800 + sa * 600 + mc * 600
    n = sk + sa + mc
    gain = sum([0.6, 0.2, 0.1][i] if i < 3 else 0.05 for i in range(n))

实跑输出：

--------------------------------------------------------------------
复杂度预算：三者协同，不是堆叠
--------------------------------------------------------------------


  ① 三者分工
  --------------------------------------------------------------------
| 东西 | 解决什么 | 谁付成本 |
|---|---|---|
| Skill | 「这种事该怎么做」 | 一份说明书的上下文 |
| Subagent | 「一次别装太多」 | 每个子 Agent 的结论 |
| MCP | 「这个工具反复要用」 | 常驻的工具描述 |

  三样解决的是三个不同的问题。混着用，成本会叠；对上了用，一个能替掉另外两个。

  ② 复杂度预算：三样各算一份成本
  --------------------------------------------------------------------
| 方案 | Skill | 子 Agent | MCP | 常驻成本 | 说明 |
|---|:---:|:---:|:---:|:---:|---|
| 朴素 | 1 | 0 | 0 | 800 | 一个 Agent 一个脚本 |
| 中等 | 2 | 2 | 1 | 3,400 | 两个 Skill、两个子 Agent、一个 MCP |
| 堆叠 | 6 | 5 | 4 | 10,200 | 什么都上 |

  成本按「常驻上下文」估：一个 Skill 约八百 token、一个子 Agent 的结论约六百、
  一个 MCP 服务器约六百。

  ③ 收益不是线性的
  --------------------------------------------------------------------
  设每个组件的边际收益递减：第一件解决六成问题，第二件再解决两成，第三件一成，之后每件半成。
  收益上限按一算。
| 方案 | 组件数 | 预计解决 | 常驻成本 | 每千 token 收益 |
|---|:---:|:---:|:---:|---:|
| 朴素 | 1 | 60% | 800 | 7.50 |
| 中等 | 5 | 100% | 3,400 | 2.94 |
| 堆叠 | 15 | 100% | 10,200 | 0.98 |

  ! 第三行那组数是这一篇的落点：组件从五个加到十五个，解决的还是那百分之百，
  成本翻三倍——「每千 token 收益」从二点九四掉到零点九八。这就是堆叠的代价。

  ④ 怎么定预算
  --------------------------------------------------------------------
| 问题 | 该加什么 | 不该加什么 |
|---|---|---|
| 总是忘记某个步骤 | Skill | 子 Agent |
| 一次要读太多文件 | Subagent | Skill |
| 同一个外部系统反复调 | MCP | Skill |
| 只是这次任务特殊 | 什么都不加 | 全都不要 |

  最后一行是这一章最该记住的：一次性的特殊需求，不要为它加任何常驻组件——加进去的成本，
  下次任务还要付。
  ! 复杂度预算的意思是：每加一个组件，都要问「它替掉了哪个」。替不掉任何东西的组件，就是纯成本。

  ⑤ 本章小结
  --------------------------------------------------------------------
| 问题 | 答案在哪一节 | 一句话 |
|---|---|---|
| 什么时候值得能力化 | 8.1 | 被反复调、要解释、要上下文 |
| 怎么拆复杂任务 | 8.2 | 拆上下文，不拆工作量 |
| 要不要接 MCP | 8.3 | 反复用、用法一致才接 |
| 三者怎么配 | 8.4 | 每加一个都要替掉一个 |

三套方案的常驻成本：八百、三千四百、一万零二百。 收益：六成、满、满。 看「每千 token 收益」那一列：七点五、二点九四、零点九八。 堆叠那套只有中等那套的三分之一。 这就是堆叠的代价——不是「没效果」，是「不值得」。 注意中等那套已经到百分之百了。 再加十个组件，收益一分不涨，成本翻三倍。 这是边际递减的必然结果，不是这套模型的问题。 最后那句「每加一个都要问它替掉了哪个」是这一章的核心。 替不掉任何东西的组件，就是纯成本——而纯成本的东西，你会在三个月后自己删掉它。

30 秒实验

1. 数一下你现在装了几个常驻组件。 每个写一句「它替掉了什么」。写不出来的，就是该删的。
2. 下次想接一个新 MCP 之前，先问「这个能不能写成脚本」。 能，就别接。
3. 把一个反复出现的流程写成 Skill，看它触发几次。 一个月触发不到三次的，说明不该做成 Skill。

常见误区

1. 「三样都上，能力最全。」 Demo 里堆叠那套单位收益只有三分之一。 能力全不等于划算。
2. 「Skill 越多越好，反正按需加载。」 按需加载也要「先知道有哪些」——名字和描述列表本身是常驻的。
3. 「接 MCP 是一次性成本。」 工具描述是常驻的，每次对话都付。 它更像月租，不像买断。

第 8 章到这里收住。下一章进第三部分：四个实战场。 先从一个真需求怎么落地开始。

• ☐ （本篇完，下一篇 9.1 Subagent：从串行阅读到全局俯瞰）

相关笔记

• 从脚本到 Harness：什么时候值得能力化
• MCP：先问是否值得接，再问怎么接
• 为什么实现智能之前要先控制
• 🛠️ Codex快速入门 · 索引