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

智能体之间可以自动分配活了，但分配完之后要不要合并、谁来审，还是得你决定——协调权可以给它们，判断权不能。

📝 本节和前面几节的关系

这一节讲多个智能体同时接活的那一层，也是最容易被高估的一层。

一、这一层解决什么

上一节的副线是你派它；这一层是给它一堆活，让它们自己分工。 典型场景：一批同类活，你不想一个个分派。 省下来的是分派的动作，不是判断的动作。

二、分配的第一原则：最重的先分

把一整批活按耗时排序，先把最重的分出去——否则最后剩下的全堆在一个人手上。 本节的演示跑了一个真实的贪心分配：六件活分给三个，负载被摊平。 这一步看着简单，但顺序错了就会有一方一直在等。

三、自动的是分配，不是判断

分完之后，要不要合并、谁来审、哪个版本对——这三件事仍然得你决定。 这一点很关键：智能体之间的协调可以自动，但对结果的判断权不在它们手里。 第 4.8 节说过它不会说不知道；这一层只是把这个缺点放大了。

四、什么时候用这一层

活多且同质：二十件同类的小活，分派本身就是负担。 反过来，活少、且每件都需要你亲自定方向的，别用——你分派的时间比它干活还长。 判断标准还是第 8.1 节那句：协调成本低于省下的时间。

五、动手 Demo：Agent Teams——让智能体自己协调

下面跑一个真实的贪心分配，看负载怎么被摊平。

load = {w: 0 for w in [u"A", u"B", u"C"]}
for name, cost in sorted(tasks, key=lambda x: -x[1]):
    w = min(load, key=lambda k: load[k])
    load[w] += cost
    assign.append((name, cost, w))

实跑输出：

--------------------------------------------------------------------
Agent Teams——让智能体自己协调
--------------------------------------------------------------------

多个智能体同时接活，会遇到分配问题。下面跑一个真实的贪心分配：

  活             要多久     分给
  -------------------------------
  改登录页       3          A
  写结算文案     2          B
  整理文档       2          C
  修样式 bug     1          B
  加一条测试     1          C
  查依赖版本     1          A

三个人的负载：A=4，B=3，C=3
最重的活先分——**这是分配的第一原则**。

注意：分完之后**要不要合并、谁来审，还是得你决定**。
智能体之间的协调是自动的，**对结果的判断权不在它们手里**。

输出里那行负载是结果：三个人的数被摊平了——最重的活先分是分配的第一原则。 但下面那句才是重点：分完之后要不要合并、谁来审，还是得你决定。

30 秒实验

  1. 手上有三件以上同类的小活时，试着一次性交给它们自动分配。
  2. 分配完问自己一句：这三个结果我都得亲自看吗？是的话，先想清楚值不值。

常见误区

  1. 以为派下去就不用管了。合并与审查仍然在你手上，而且这部分不会变少。
  2. 把需要你定方向的活丢进去。分派的时间比它干活还长——那就别用这一层。
自测三问（点开对答案） 1. 这一层省下的是什么？ —— 分派的动作，不是判断的动作。 2. 分配的第一原则是什么？ —— 最重的活先分，否则最后全堆在一方。 3. 自动的是协调，为什么判断权不能给？ —— 因为对结果的判断是第 4.8 节说的那条边界——它不会说不知道，判断权必须留在你这。

相关笔记