波仔
🐎 第4章 分而治之：子智能体与任务委派的艺术
📄 一句话概括

四个坑，四个小实验：回执太大会把省下的还回去、并行改同一个文件会静默丢改动、 委派太深上下文一层层掉、互相委派会转不出来。 四个坑有一个共同点：都不是「模型不聪明」，都是「接口没定好」。

📝 本章和前面几章的关系

前面七节讲机制，这一节讲落地。 四个坑按「踩到的顺序」排：先踩回执，再踩并发，再踩层级，最后踩循环。 这一节也是第 4 章的收尾，本章小结并在本篇末尾。

一、坑一：回执太大

派出去省下的空间，一半可能被回执吃回去。演示里短回执十九 token，长回执三百。 长的那份是「改了五个文件，第 12 行到第 88 行是新增的用例， 第 90 行到第 140 行也是」这种写法——它在汇报过程，不是在给结论。 主窗口峰值从一千三百三十九涨到一千六百二十。一次多花二百八十一，派十次就是两千八。

所以派它出去的时候要说清「只回结论，不要贴代码」。这一句能省下的，比定义里其他几句加起来都多。 如果确实需要明细，让它写进文件、回执里给路径——明细在磁盘上，不在主窗口里。

二、坑二：并行改同一个文件

两个子智能体各自读了 config.py、各加一行、各自写回。最后磁盘上只剩后写的那份。 演示里 A 加的 LOG 不见了，B 加的 TIMEOUT 还在。整个过程没有任何报错。 这是最阴的一种失败：先写的那份改动无声消失，而你以为两个都做了。

所以并行的边界要按文件划分，不能按「谁先抢到」。同一个文件只能有一个写者。 退一步的做法：并行阶段只读不写，写回统一由主窗口或者一个收口的子智能体来做。 这也是 4.4 节把「只读型」排在第一位的原因。

三、坑三：委派太深

每多一层，上一层只把摘要往下传，细节就掉一截。演示里按每层保留七成算，三层之后剩不到三成半。 代价还有系统提示：每多一层多一份八百。深委派既丢信息又费钱。 所以实践中很少超过两层。真要三层，说明任务本身的分解方式有问题——该重新划块，而不是继续往下派。

还有一个信号：如果某一层只能靠「猜测上一层的意图」来干活，那就是分解错了。 层级是给上下文做隔离的，不是给组织架构画图的。

四、坑四：互相委派

演示里 A 派给 B、B 又派回 A，三步之后回到起点，再跑下去只是重复。 没有终止条件的话它能一直转。转的每一圈都在花钱，而你看不见。 所以委派必须有一个「谁负责收口」的约定：要么只允许上层往下派、下层不许往上派，要么给一个最大步数。

这条和 1.1 节讲的那个循环是同一条：没有终止条件的循环，在哪一层都是死循环。 实操上有个简单约定：只有主窗口能发起委派，子智能体不能再派。这样层级天然是一层，循环也就无从产生。

五、四个坑的共同点

四个坑看上去各不相关，其实都是「接口没定好」。 回执太大是返回值没定；并行冲突是写权限没定；委派太深是层级没定；互相委派是「谁能发起」没定。 四件事都能在派出去之前写清楚：回执格式、写范围、最大层级、能不能再派。

这四条加起来不过是定义里多写几行，但它决定了这次委派是「可控」还是「只能祈祷」。 所以这一节的真正结论是：委派的可靠性不在模型，在接口。

六、本章小结

第 4 章讲子智能体。八节收在一句话上：它是给主窗口腾工位的手段，不是省钱工具。 4.1 算清两件事：窗口装不下（三十份只装十七份）、成本是平方的。 4.2 讲本质：独立上下文、只回结论，省的是主窗口不是总账。

4.3 讲定义：四个字段，其中 tools 最要紧——不写就是全部权限。 4.4 讲五种形状：只读、执行、并行、流水线、团队，按「这次要什么」选。 4.5 讲组合：技能管怎么做，子智能体管在哪做。

4.6 算账：规模越大两路越接近打平，稳定的收益是主窗口那个常数。 4.7 讲接口：回执是返回值，四个字段就够，blocked 不能省。 4.8 讲四个坑：回执太大、并行写冲突、委派太深、互相委派。

下一章换一整块：钩子。前面讲的是「模型决定做什么」，钩子讲的是「不归模型决定的事怎么写死」。

七、动手 Demo：四个坑，各跑一个小实验

四个实验：回执从十九 token 写到三百、两个子智能体同时改 config.py、委派一到三层、A 和 B 互相委派。 每个都能在几行代码里复现，不需要真的起一个子智能体——它们全都是「机制」层面的事。

# 坑二：两个智能体各读各写，后写的赢
put(root, u"config.py", a)      # A 加了 LOG
put(root, u"config.py", b)      # B 加了 TIMEOUT，整个文件覆盖
lost = u"LOG" not in get(root, u"config.py")

# 坑四：A -> B -> A，靠步数上限收口
while steps < 6:
    if cur in seen:
        break
    seen.add(cur)
    cur = edges[cur]

实跑输出：

--------------------------------------------------------------------
四个坑，各跑一个小实验
--------------------------------------------------------------------


  ① 回执太大：省下的又被还回去
  --------------------------------------------------------------------
| 回执 | token | 主窗口峰值 |
|---|---:|---:|
| 短回执 | 19 | 1339 |
| 长回执 | 300 | 1620 |

  长回执 300 token，主窗口峰值从 1339 涨到 1620。一次多花 281，派十次就是 2810。
  所以派它出去的时候要说清「只回结论，不要贴代码」。这一句能省下的，比定义里其他几句加起来都多。

  ② 并行写同一个文件
  --------------------------------------------------------------------
  两个子智能体各自读了 config.py、各加一行、各自写回。最后磁盘上只剩后写的那份。
  A 加的 LOG 还在吗：不在。B 加的 TIMEOUT 在不在：在。
  所以并行的边界要按文件划分，不能按「谁先抢到」。
  两个子智能体改同一个文件，后写的赢，先写的那份改动无声消失。

  ③ 委派太深：上下文一层层掉
  --------------------------------------------------------------------
| 委派深度 | 原始细节剩多少 | 额外系统提示 |
|---|---:|---:|
| 1 层 | 70% | 800 |
| 2 层 | 49% | 1600 |
| 3 层 | 34% | 2400 |

  每多一层，上一层只把摘要往下传，细节就掉一截。三层之后剩不到三成半。
  代价还有系统提示：每多一层多一份八百。深委派既丢信息又费钱，所以实践中很少超过两层。

  ④ 互相委派：跑不完的循环
  --------------------------------------------------------------------
  A 派给 B、B 又派回 A。
  跑起来就是 3 步之后回到起点，再跑下去只是重复——没有终止条件的话它能一直转。
  ! 所以委派必须有一个「谁负责收口」的约定：要么只允许上层往下派、下层不许往上派，
  要么给一个最大步数。没有终止条件的循环，在哪一层都是死循环。

①回执从十九 token 写到三百，主窗口峰值从一千三百三十九涨到一千六百二十，一次多花二百八十一。 所以派它出去的时候要说清「只回结论，不要贴代码」。这一句能省下的，比定义里其他几句加起来都多。 ②并行写同一个文件那个实验是真跑的文件写：A 先写、B 后写，读回来只剩 B 那份。 A 加的 LOG 不见了，整个过零报错。 这是最阴的一种失败：先写的那份改动无声消失，而你以为两个都做了。 所以并行的边界要按文件划分，同一个文件只能有一个写者。 ③委派深度：按每层保留七成算，一层七成、两层四成九、三层三成四。代价还有系统提示，每层多八百。 深委派既丢信息又费钱，所以实践中很少超过两层。 真要三层，说明任务分解方式有问题，该重新划块而不是继续往下派。 ④互相委派那个循环三步就回到起点。没有终止条件的话它能一直转，转的每一圈都在花钱而你看不见。 四个坑其实都是「接口没定好」：回执太大是返回值没定、并行冲突是写权限没定、委派太深是层级没定、 互相委派是「谁能发起」没定。 这四条加起来不过是定义里多写几行，但它决定了这次委派是「可控」还是「只能祈祷」。

30 秒实验

  1. 把回执里的文件清单改成「只报数量不报名字」，重跑第 ① 步。主窗口峰值降到多少？ 这个改动丢掉了什么信息？
  2. 给并行的两个子智能体各分配一个文件，重跑第 ② 步。改动还会消失吗？这说明并行边界该怎么划？
  3. 把委派深度限制成两层，重跑第 ③ 步。剩下的细节从三成四涨到多少？第三层原本要干的活，改由谁来干？

常见误区

  1. 让子智能体详细汇报过程。回执是返回值，不是日志；日志该写进文件。
  2. 并行时按「谁先抢到文件」分活。后写的赢，先写的改动无声消失，而且不报错。
  3. 一层层往下派，觉得「分得越细越好」。每多一层丢三成细节、多一份系统提示。
  4. 允许子智能体再委派子智能体。层级不封顶就会转出循环，而你看不见它在转。
  5. 把这四个坑当成「模型的毛病」。它们全是接口没定，在派出去之前就能写清楚。
自测三问（点开对答案） 1. 回执太大为什么等于白派一次？ —— 因为委派省下的是主窗口空间，回执一大就把空间又占回去了。明细该写进文件，回执里给路径。 2. 并行改同一个文件为什么会出事？ —— 后写的整份覆盖先写的，先写的那份改动无声消失，而且整个过程不报错。 所以同一个文件只能有一个写者。 3. 四个坑的共同点是什么？ —— 都是接口没定好：返回值、写权限、最大层级、能不能再派。四件事都能在派出去之前写清楚。

第 4 章到此收尾。下一章讲钩子：前面都是「模型决定做什么」，钩子是把不归模型决定的事写死。

相关笔记