波仔
🧡 第八章 多智能体协作
📄 一句话概括

并行省的时间是真的，但协调要花钱——协调成本超过省下的时间，并行就变成负收益；所以不是活越多越该并行。

📝 本节和前面几节的关系

第三部分第二站。前一章讲给它加能力，这一章讲用多个它。前两节先把【并行到底划不划算】算清楚。

一、并行省了什么

三件互不依赖的活：改登录页 30 分钟、写结算文案 20 分钟、修样式 bug 10 分钟。 串行 60 分钟，并行 30 分钟——被最长的那件拖住。 省下 30 分钟，这是真的。

二、并行要付什么

协调：谁先做、结果怎么合、两边说法不一致时听谁的。 本节的演示把协调成本代进去算：花 5 分钟还净省 25 分钟，花 30 分钟就变成倒亏。 所以有个反直觉的结论：大部分时候不该并行。活少的时候，串行反而更快。

三、所以什么时候该开多个窗口

三个条件同时满足：活是独立的、量大到值得协调、你能忍住不去频繁插手。 只满足前两条还不够——第三条最容易被忽略，见第 8.6 节。 反过来，一件事拆成三步（第 6.5 节那种）就不该并行，那是依赖关系，不是并列关系。

四、一个人开很多窗口的本质

它不是【你变成了团队】，是你一个人的注意力被拆成几份。 所以窗口开多了，判断质量会下降——每个窗口都要你抽空看一眼。 这就是为什么本节标题是【一个人为什么】——问的是值不值，不是能不能。

五、动手 Demo：一个人为什么要开那么多窗口

下面把三件活的串行与并行算一遍，再把协调成本代进去。

jobs = [(u"改登录页", 30), (u"写结算文案", 20), (u"修样式 bug", 10)]
total = sum(m for _, m in jobs)
for extra in (5, 15, 30):
    P(u"    协调花 %2d 分钟 -> 净省 %2d 分钟" % (extra, total - max(m for _, m in jobs) - extra))

实跑输出：

--------------------------------------------------------------------
一个人为什么要开那么多窗口
--------------------------------------------------------------------

先算清楚并行到底省了什么。下面是三件互不依赖的活：

  活                 串行要多久
  ------------------------------
  改登录页           30 分钟
  写结算文案         20 分钟
  修一个样式 bug     10 分钟

串行：60 分钟。并行：30 分钟（被最长的那件拖住）。

省下 30 分钟——但**并行不是免费的**。加上协调：
    协调花  5 分钟 -> 净省 25 分钟
    协调花 15 分钟 -> 净省 15 分钟
    协调花 30 分钟 -> 净省  0 分钟

协调成本超过 30 分钟，并行就变成负收益。
**所以不是活越多越该并行，而是【协调成本低于省下的时间】才该并行。**

代进协调成本之后结论就变了：协调花 30 分钟，并行就是倒亏。 所以这一节的判据不是【活多不多】，是【协调成本有没有低于省下的 30 分钟】。

30 秒实验

  1. 回忆最近一次并行做的事，算一算省了多少分钟、协调花了几分钟。
  2. 如果只有一两件小事，别并行——串行更快更稳。

常见误区

  1. 以为并行总比串行好。活少的时候并行是倒亏——协调成本吃掉了收益。
  2. 把有依赖的步骤拆成并行。比如第 6.5 节那五轮，那是先后关系不是并列关系。
自测三问（点开对答案） 1. 并行的收益是怎么被吃掉的？ —— 协调成本——花 30 分钟协调时，并行就成了倒亏。 2. 什么时候该开多个窗口？ —— 活独立、量大到值得协调、而且你忍得住不频繁插手，三条都满足。 3. 为什么【一个人开很多窗口】不等于变成团队？ —— 你一个人的注意力被拆成几份，判断质量会下降。

相关笔记