波仔
🧡 第十三章 实战项目2：内容创作自动化
📄 一句话概括

能不能并行只看一条：两件活要不要等对方；最容易踩的坑不是调度而是回收——三个子代理各交回五千字，主上下文照样爆。

📝 本节和前面几节的关系

上一节把一条流水线走通了；这一节讲怎么把流水线上互相不等的活同时派出去。

一、分界线只有一条

两件活互相要不要等对方——要等，就只能串行。 能并行的：三篇不同题目的初稿、一篇稿的初稿与配图、多个选题的资料研究。 不能并行的：同一篇的改稿与校对——校对要看改完的版本。 同一件事的两个动作，只要后者要看前者的结果，就不能并行。

二、并行最容易踩的坑是回收

不是调度难，是结果回来的那一刻：三个子代理各交回五千字报告。 主上下文照样被塞爆——并行的收益，一下子被这句话吃掉了。 所以派活时要把要求写死：只交结论和必要的位置，别把过程整段带回来。

三、另外两条纪律

并行的活之间不能改同一个文件——用隔离的工作区（第 8.2 节）。 有先后的活就别硬并行（第 8.3 节）：只会让你多花时间读两份互相矛盾的结果。 并行的前提从来不是【开得多】，是【真的互不相干】（第 8.1 节）。

四、内容创作里最划算的并行

资料研究那条线最划算：几个选题同时查，互不依赖、输出也好裁剪。 初稿也可以并行，但要给它足够的背景——不然几篇写成同一个腔调。 判断顺序：先问【要不要等】，再问【回来的东西好不好收】。

五、动手 Demo：多智能体并行实践

下面把几类任务与【能不能并行、为什么】排开。

TH([u"任务", u"能并行吗", u"为什么"], [26, 14, 34])
T([u"写三篇不同题目的初稿", u"能", u"互相不依赖，各写各的"],
  [26, 14, 34])
T([u"同一篇的改稿与校对", u"不能", u"校对要看改完的版本"],
  [26, 14, 34])

实跑输出：

--------------------------------------------------------------------
多智能体并行实践
--------------------------------------------------------------------

内容创作里，**有些活天然可以并行**，有些不行。
分界线只有一条：**两件活互相要不要等对方**。

  任务                     能并行吗     为什么
  -----------------------------------------------------------
  写三篇不同题目的初稿     能           互相不依赖，各写各的
  一篇稿的初稿与配图       能           图不依赖文字定稿
  同一篇的改稿与校对       不能         校对要看改完的版本
  多个选题的资料研究       能           几条线各查各的

**并行最容易踩的坑不是调度，是回收**：
三个子代理各交回五千字报告，**主上下文照样被塞爆**。

所以派活的时候要把要求写死：

    **只交结论和必要的位置，别把过程整段带回来。**

另外两条：**并行的活之间不能改同一个文件**
（用 worktree 隔离，第 8.2 节）；
**有先后的活就别硬并行**——那只会让你多花时间读两份互相矛盾的结果。

能不能并行，只看一条：两件活互相要不要等对方。 最容易踩的坑不是调度，是回收——派活时写死【只交结论和必要的位置】，别把过程整段带回来。

30 秒实验

  1. 把你手头待办的活列出来，逐条标【能并行 / 要串行】。
  2. 挑一件要并行的，在派活的话里加上一句【只交结论与文件位置】。

常见误区

  1. 顺手把有先后的活也并行。只会让你多读一份互相矛盾的结果。
  2. 派活时不说清交付格式。三个子代理各交回五千字，主上下文照样爆。
自测三问（点开对答案） 1. 判断能不能并行，只看什么？ —— 两件活互相要不要等对方。 2. 并行最容易踩的坑是什么？ —— 回收——子代理的结果整段回流，把主上下文塞爆。 3. 并行还有哪两条纪律？ —— 并行的活之间不能改同一个文件；有先后的活别硬并行。

相关笔记