章节主旨
同时开五个 Claude Code 实例,让它们各自独立地去搭同一个「线索抓取工作流」,借并行在极短时间内探索大量方案,再从幸存方案里挑最优或合并最优,最后把选中的方案合回主 directives。
核心论点
- 并行化 = 用多实例扩大搜索空间——同一任务派给多个 agent 实例并行跑,单位时间探索的方案数成倍增加。(→ 详解1)
- 并行的前提是工作区隔离——每个 agent 在各自独立临时目录里干活,才不会互相踩文件。(→ 详解2)
- 构建走优胜劣汰——遇到难缠障碍就直接弃掉该方案,只留幸存者并排比测。(→ 详解3)
- 多方案可合并出更强的统一工作流——把各方案最能出结果的部分拼起来,覆盖率叠加。(→ 详解4)
- 人退到监督者位——只旁观、按需供给密钥与决策,不介入每步执行。(→ 详解5)
- 产出必须校验数据质量——抓来的线索会混入明显错误,需收紧搜索条件而非只信数量。(→ 详解6)
知识点详解
1. 并行化:多实例同跑一个任务 3:23:25
把之前做过的线索抓取工作流,从「一个云实例生成」升级成「多个云实例并行生成」。同一份需求(这里是「德州 HVAC 公司的 B2B 线索及邮箱」)同时交给五个 Claude Code 实例,各自独立去搭一条流水线。
并行化 的收益不在于更快跑完一次,而在于同一时间探索更多可能。搜索的方案越多、选项越广,最终留下的那条工作流「碰巧更好」的概率就越高。
作者也强调这只是演示规模——平时不一定同时开五个,重点是让你看到「短时间内趟一大片解空间」是可行的。
2. 工作区隔离:并行的物理前提 3:24:37
给每个 agent 相同的脚手架式指令(scaffolding):任务是按下述细节搭线索抓取工作流,但因为多个 agent 共用同一个工作区,为把冲突概率降到最低,所有工作都放进各自独立的新临时目录(如 tmp/test3)。
这样每个 agent 生成的文件夹互不干扰,也不会碰到已有的 directives、执行脚本等共享资产。工作区隔离 是并行能跑起来的硬前提——没有它,五个 agent 会在同一批文件上打架。
3. 优胜劣汰:遇大障碍即弃 3:25:46
并行跑起来后,作者只做一件事:扫一眼每条流水线,判断谁最可能成。任何一条流遇到麻烦(hiccup),就看障碍大小——大到处理起来太费劲,就直接放弃那条,不再跟进。
留下来的「幸存者」等到各自长成一条像样的工作流后,再拉到一起并排测试:让它们都去跑一次抓取,然后对比结果。这是一种优胜劣汰式构建——不追求每条都成功,只要有若干条跑通即可。
4. 合并最优:拼出统一工作流 3:26:10
幸存方案跑完后,一个很有价值的动作是把各方案的长处合并:让 agent 搭一条统一工作流,组合 X、Y、Z 三种方式的最优部分。
效果类似覆盖率叠加——一种方式找到 30% 的线索,第二种再找 30%,第三种再补 30%。合并最优 把并行探索出的多条路径收敛成一条更全面的流水线,而不是二选一地丢掉其余成果。
5. 人退到监督者位 3:28:19
并行跑的时候,作者对每条流水线的介入极少:一条在调试抓取器、一条转而改用第三方抓取 API(Apify)、一条在跑批量邮箱抓取——他都不必参与。
角色收缩为纯监督者:只旁观全局,哪个 worker 需要东西(某个 API key、某个 Sales Navigator 搜索 URL、某个决策)就临时供给,其余交给 agent 自己推进。这让一个人同时编排多个构建者成为可能。
6. 数据质量校验:收紧搜索而非只数条数 3:29:40
并行产出的线索不能照单全收。一次 50 条测试抓回 26 个邮箱,里面却混进了一个「在 Neurolink 工作的人」,后来又抓到微软 CEO Satya Nadella 的邮箱——显然不是目标 HVAC 客户。
问题根源在搜索条件太粗:直接拿关键词「HVAC」去 LinkedIn Sales Navigator 抓,命中的既有 HVAC 相关、也有大量无关的 3:29:54。修法是改用行业筛选(选 industry 里的 HVAC 而非关键词),把 341 条候选收窄后再测,准确率明显提升(20 家里 18 家有网站、13 家有邮箱)。校验与收紧,是把「数量」变成「有效线索」的关键一步。
7. 成本账:5 倍测试只多花几美元 3:33:10
挑定方案后,让 agent 把选中的 directives 合回主 directives 分支并修正文件路径,一条可复用、可再优化的工作流就落地了。
成本上,并行相比单跑几乎没多花时间,额外开销只是些许 Claude 用量 + 几美元 Google Places API + 少量第三方 token。整体是「用每条工作流几美元的代价换 5 倍测试量」,再叠加 self-annealing(自退火)得到的稳健流水线——作者据此认为这比传统自动化平台(n8n / Make / Zapier)仅开发测试环节的花费还低。此为其商业主张,技术要点是并行 + 自退火本身。
术语
- parallelization(并行化,同时开多个 agent 实例跑同一任务以扩大搜索空间)
- scaffolding(脚手架指令,给并行 agent 的统一任务模板与约束)
- workspace isolation(工作区隔离,各 agent 用独立临时目录避免文件冲突)
- hiccup(障碍/卡点,方案遇到的麻烦,大则弃之)
- survivors(幸存方案,未被弃掉、进入并排比测的候选)
- best-of-merge(合并最优,把多方案长处拼成统一工作流)
- self-annealing(自退火,工作流反复自我修正趋向稳健)
自检问题
- 并行开多个 agent 实例的主要收益是什么?为什么必须给每个实例独立目录? 答案:收益是同一时间探索更多方案,提高「留下的那条碰巧更好」的概率(不是把一次任务跑更快);独立临时目录是为避免共用工作区时多个 agent 互相踩文件、且不干扰已有 directives 与脚本。见详解1、2。 3:24:37
- 面对多条并行流水线,作者如何决定去留?最后怎么收敛? 答案:遇到大到难处理的障碍就直接弃掉该方案;幸存者并排比测,再让 agent 合并各方案最优部分成统一工作流(覆盖率叠加),最后合回主 directives。见详解3、4。 3:26:10
- 抓回的线索为什么不能只看条数?怎么提高有效率? 答案:因为会混入明显无关的错误线索(如 Neurolink 员工、微软 CEO 的邮箱);根源是关键词搜索太粗,改用行业筛选收窄候选再测,有效率明显提升。见详解6。 3:29:40