并联听起来只是「一起发」，但主智能体只有一个上下文，三路活同时开它装不下。 子智能体是解法：派三个分身各自读一大份材料，只把 120 字的结论交回来。 三份四千字的材料自己读要 17634 token（窗口的 2.2 倍），派出去只回来 531，差 33 倍。
上一篇把并联说成「同层一起发」，这一篇讲它在真实上下文里怎么才发得出去。 第 2 章算过上下文预算，第 4 章的流水线也会撞上同一个限制，这里是那个限制的正解。 第 6 章讲设计时会用到「派活的话要写全」这一条：子智能体是一份独立的技能描述。
一、上下文是个固定大小的桌面
先把约束摆出来。主智能体的上下文是个固定大小的桌面，这一课按 8192 token 算。 桌面就这么大。你往上放什么，就挤掉什么。放了三份长材料，就没地方写正文了。 这个约束在并联的时候最要命：三路活同时开，三路的材料都要进同一个桌面。 很多人以为并联的瓶颈是速度，其实是空间。速度不够只是慢，空间不够是干不了。 所以并联之前先算一笔账：这一层的几路活，材料加起来占多少桌面。
二、三份材料放不进去
拿三份访谈稿试一下。每份 4000 字，三份合计 17634 token。 17634 是 8192 的 2.2 倍——一份都放不进去，更别说三份。 这不是「有点紧」，是根本装不下。任何「让主智能体自己读三份再写」的方案，在这一步就该被否掉。 注意 token 和字数的关系：4000 字约 5878 token，一个字约 1.47 个 token。 中文按这个比例粗算就够用了。要精确得用真分词器，本机没有，所以这里只用来比大小。
三、子智能体是什么
子智能体可以理解成一个分身：它有自己独立的上下文，自己读材料，干完只交结论。 关键在「独立的上下文」这五个字。它读的四千字在它那边，不进你的桌面。 它交回来的只有摘要。三份 120 字的摘要，合计 531 token。 17634 比 531，差 33 倍。省下来的空间刚好够写三节初稿。 所以子智能体不是「更快的模型」，是一个能替你占地方的人。价值在空间，不在速度。 它和技能也不是一回事：技能是一份经验，子智能体是一个干活的人。这个区别下面单独说。
四、派活的三条
派活的话要当成一份独立的技能描述来写。三条，缺一条就会返工。 一、背景写全。子智能体看不到你之前说过什么，它只知道你这一句。 所以别写「按刚才说的整理一下」——它没有「刚才」。把背景、目的、材料位置都写进去。 二、要什么写清。是提炼观点，还是找原话，还是列数字？三者的产出完全不同。 三、输出格式定死。一句话还是三条，带不带标题，这些不写清，回来的东西合并不了。 第三条最容易被跳过，也最容易在合并那一步爆掉。第 4 章的流水线崩的就是这里。
五、技能 vs 子智能体：用哪个
| 比什么 | 技能 | 子智能体 |
|---|---|---|
| 是什么 | 一份经验，纯文本 | 一个分身，独立上下文 |
| 谁读它 | 主智能体自己读 | 另一个自己读 |
| 占不占主上下文 | 占，正文要读进来 | 不占，只交摘要 |
| 什么时候用 | 有固定做法可循 | 有一大块独立的活 |
这张表能挡掉最常见的误用：用子智能体去干一件其实一句话就能说清的事。 派一个分身要写一段派活的话，还要等它跑完，成本比自己做高。 反过来，用技能去干一件要读三万字的活，就是把桌面撑爆——那才是子智能体的场子。 一条判断：活的大小接近或者超过桌面，才值得派人。
六、什么时候不该派
三种情况派了反而更糟。 任务有依赖。第二路要等第一路的结论才知道怎么干，这不是并联，是串联。 要来回追问。主上下文只有摘要，想看原话得再派一次，来回两次的成本超过自己读。 一步就完。一句话能说清的小活，派人的开销比干活的成本还高。 还有一条软限制：你只能同时盯有限几个分身。三个还行，十个就不知道谁交了什么。 所以层宽不是越宽越好。真正决定并行度的是「你能不能管得过来」，不是「机器能开几个」。
七、动手 Demo：三份材料，是自己读还是派三路子智能体
这一段算一笔账：三份四千字的材料，自己读要占多少桌面，派三个子智能体又占多少。 两边都按同一套估算（中文一字约 1.47 token），比的是数量级，不是精确值。
tot = sum(tokens(grow(4000)) for _n in range(3)) # 自己读三份
s = tokens(grow(120)) # 一份摘要
print(tot, 'vs', s * 3, '差 %.0f 倍' % (tot / (s * 3.0)))
print('占 8192：%.1f 倍' % (tot / 8192.0))
实跑输出：
--------------------------------------------------------------------
三份材料，是自己读还是派三路子智能体
--------------------------------------------------------------------
① 主智能体的上下文是个固定大小的桌面
--------------------------------------------------------------------
这一课按 8192 token 的窗口算，跟前面几篇用的是同一个数。
桌面就这么大，你往上放什么，就挤掉什么。
② 自己读：三份材料全搬到桌面上
--------------------------------------------------------------------
| 材料 | 字数 | token |
|---|---:|---:|
| 访谈一 | 4000 | 5878 |
| 访谈二 | 4000 | 5878 |
| 访谈三 | 4000 | 5878 |
三份合计 17634 token，是 8192 窗口的 2.2 倍——一份都放不进去。
! 这就是第 2 章那张预算表的实测版：搬数据比搬结论贵得多。
③ 派子智能体：只把结论搬回来
--------------------------------------------------------------------
| 做法 | 进主上下文的 token | 留下什么 | 代价 |
|---|---:|---|---|
| 自己读三份 | 17634 | 全文都在 | 能随时翻细节 |
| 派三路子智能体 | 531 | 三份摘要 | 细节在主上下文里没了 |
17634 比 531，差 33 倍。
! 子智能体读完就结束，它的上下文不占你的。这是它能省的原因。
④ 省下来的空间拿去干什么
--------------------------------------------------------------------
| 做法 | 材料加三千字正文 | 能不能干活 |
|---|---:|---|
| 自己读 | 22043 | 超窗口 2.7 倍，装不下 |
| 派子智能体 | 4940 | 还剩 3252 token 写正文 |
第二列是「三份材料 + 3000 字正文」占掉的量，第三列才是结论。
⑤ 派活的代价：它只知道自己那一份
--------------------------------------------------------------------
| 限制 | 具体表现 |
|---|---|
| 任务必须互不依赖 | 三份访谈各自提炼，不需要互相看 |
| 问细节要再派一次 | 主上下文只有摘要，想看原话得回头再要 |
| 派活的话要写全 | 子智能体看不到你之前说过什么 |
第三条最容易翻车：你以为它知道背景，它其实只知道你这一句。
! 所以派活的那段话要当成一份独立的技能描述来写：背景、要什么、什么格式。
第一段先把约束说清：8192 的桌面，放什么就挤掉什么。 第二段算自己读：三份 4000 字合计 17634 token，是窗口的 2.2 倍，一份都放不进去。 第三段派子智能体：三份 120 字摘要合计 531 token，差 33 倍。 第四段算省下来的空间够干什么：自己读加三千字正文超窗口 2.5 倍，派出去还剩四千多 token。 第五段是派活的代价：任务必须互不依赖、问细节要再派一次、派活的话要写全。 第三条最容易翻车——你以为它知道背景，它其实只知道你这一句。
30 秒实验
- 算一下你最近一次「一次读好几份材料」的活，材料加起来多少 token。超窗口就该派人。
- 把你上次派活的那段话翻出来，检查三件事：背景写没写、要什么写没写、格式定没定。
- 找一件你本来打算派人的小活，自己做完。对比一下，是不是自己干更快。
常见误区
- 以为并联的瓶颈是速度。真正的瓶颈是空间：三路材料同时进同一个桌面，装不下就是装不下。
- 派活的话写得太省。「按刚才说的整理一下」——子智能体没有「刚才」，它只知道你这一句。
- 拿子智能体干小活。派一个人要写一段话还要等它跑完，一句话能干完的事，派人更贵。
自测三问（点开对答案）
1. 子智能体省下的到底是什么？ —— 空间，不是速度。它自己读材料，材料不进主上下文，只交摘要回来。 2. 三份四千字材料自己读要多少 token？为什么这个数直接否掉方案？ —— 17634，是 8192 窗口的 2.2 倍。不是紧，是装不下，所以「自己读三份再写」根本不成立。 3. 什么情况下不该派子智能体？ —— 任务有依赖、要来回追问细节、一步就能干完。另外同时盯太多分身也管不过来。下一篇把五个技能真串起来：串起来的关键不是每步做得好，是上一步的产出下一步读得懂。
- ☐ （本篇完，下一篇 5.4 五个技能搭起一条写作工作流）