---
title: '23 用并行化改进线索抓取器'
video_id: MxyRjL7NG18
part: 23
---

> 章节 23 / 37 · [[00-总览|课程总览]] · 起始 [3:23:17](https://youtu.be/MxyRjL7NG18?t=12197)


## 章节主旨

同时开五个 Claude Code 实例,让它们各自独立地去搭同一个「线索抓取工作流」,借并行在极短时间内探索大量方案,再从幸存方案里挑最优或合并最优,最后把选中的方案合回主 directives。

## 核心论点

1. **并行化 = 用多实例扩大搜索空间**——同一任务派给多个 agent 实例并行跑,单位时间探索的方案数成倍增加。([[#1-并行化多实例同跑一个任务-32325|→ 详解1]])
2. **并行的前提是工作区隔离**——每个 agent 在各自独立临时目录里干活,才不会互相踩文件。([[#2-工作区隔离并行的物理前提-32437|→ 详解2]])
3. **构建走优胜劣汰**——遇到难缠障碍就直接弃掉该方案,只留幸存者并排比测。([[#3-优胜劣汰遇大障碍即弃-32546|→ 详解3]])
4. **多方案可合并出更强的统一工作流**——把各方案最能出结果的部分拼起来,覆盖率叠加。([[#4-合并最优拼出统一工作流-32610|→ 详解4]])
5. **人退到监督者位**——只旁观、按需供给密钥与决策,不介入每步执行。([[#5-人退到监督者位-32819|→ 详解5]])
6. **产出必须校验数据质量**——抓来的线索会混入明显错误,需收紧搜索条件而非只信数量。([[#6-数据质量校验收紧搜索而非只数条数-32940|→ 详解6]])

## 知识点详解

### 1. 并行化:多实例同跑一个任务 [3:23:25](https://youtu.be/MxyRjL7NG18?t=12205)

把之前做过的线索抓取工作流,从「一个云实例生成」升级成「多个云实例并行生成」。同一份需求(这里是「德州 HVAC 公司的 B2B 线索及邮箱」)同时交给五个 Claude Code 实例,各自独立去搭一条流水线。

并行化 的收益不在于更快跑完一次,而在于**同一时间探索更多可能**。搜索的方案越多、选项越广,最终留下的那条工作流「碰巧更好」的概率就越高。

作者也强调这只是演示规模——平时不一定同时开五个,重点是让你看到「短时间内趟一大片解空间」是可行的。

### 2. 工作区隔离:并行的物理前提 [3:24:37](https://youtu.be/MxyRjL7NG18?t=12277)

给每个 agent 相同的脚手架式指令(scaffolding):任务是按下述细节搭线索抓取工作流,但因为多个 agent 共用同一个工作区,为把冲突概率降到最低,**所有工作都放进各自独立的新临时目录**(如 `tmp/test3`)。

这样每个 agent 生成的文件夹互不干扰,也不会碰到已有的 directives、执行脚本等共享资产。工作区隔离 是并行能跑起来的硬前提——没有它,五个 agent 会在同一批文件上打架。

### 3. 优胜劣汰:遇大障碍即弃 [3:25:46](https://youtu.be/MxyRjL7NG18?t=12346)

并行跑起来后,作者只做一件事:扫一眼每条流水线,判断谁最可能成。任何一条流遇到麻烦(hiccup),就看障碍大小——**大到处理起来太费劲,就直接放弃那条,不再跟进**。

留下来的「幸存者」等到各自长成一条像样的工作流后,再拉到一起并排测试:让它们都去跑一次抓取,然后对比结果。这是一种优胜劣汰式构建——不追求每条都成功,只要有若干条跑通即可。

### 4. 合并最优:拼出统一工作流 [3:26:10](https://youtu.be/MxyRjL7NG18?t=12370)

幸存方案跑完后,一个很有价值的动作是**把各方案的长处合并**:让 agent 搭一条统一工作流,组合 X、Y、Z 三种方式的最优部分。

效果类似覆盖率叠加——一种方式找到 30% 的线索,第二种再找 30%,第三种再补 30%。合并最优 把并行探索出的多条路径收敛成一条更全面的流水线,而不是二选一地丢掉其余成果。

### 5. 人退到监督者位 [3:28:19](https://youtu.be/MxyRjL7NG18?t=12499)

并行跑的时候,作者对每条流水线的介入极少:一条在调试抓取器、一条转而改用第三方抓取 API(Apify)、一条在跑批量邮箱抓取——他都不必参与。

角色收缩为纯监督者:只旁观全局,哪个 worker 需要东西(某个 API key、某个 Sales Navigator 搜索 URL、某个决策)就临时供给,其余交给 agent 自己推进。这让一个人同时编排多个构建者成为可能。

### 6. 数据质量校验:收紧搜索而非只数条数 [3:29:40](https://youtu.be/MxyRjL7NG18?t=12580)

并行产出的线索不能照单全收。一次 50 条测试抓回 26 个邮箱,里面却混进了一个「在 Neurolink 工作的人」,后来又抓到微软 CEO Satya Nadella 的邮箱——显然不是目标 HVAC 客户。

问题根源在搜索条件太粗:直接拿关键词「HVAC」去 LinkedIn Sales Navigator 抓,命中的既有 HVAC 相关、也有大量无关的 [3:29:54](https://youtu.be/MxyRjL7NG18?t=12594)。修法是**改用行业筛选**(选 industry 里的 HVAC 而非关键词),把 341 条候选收窄后再测,准确率明显提升(20 家里 18 家有网站、13 家有邮箱)。校验与收紧,是把「数量」变成「有效线索」的关键一步。

### 7. 成本账:5 倍测试只多花几美元 [3:33:10](https://youtu.be/MxyRjL7NG18?t=12790)

挑定方案后,让 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(自退火,工作流反复自我修正趋向稳健)

## 自检问题

1. 并行开多个 agent 实例的主要收益是什么?为什么必须给每个实例独立目录?
   **答案**:收益是同一时间探索更多方案,提高「留下的那条碰巧更好」的概率(不是把一次任务跑更快);独立临时目录是为避免共用工作区时多个 agent 互相踩文件、且不干扰已有 directives 与脚本。见详解1、2。 [3:24:37](https://youtu.be/MxyRjL7NG18?t=12277)
2. 面对多条并行流水线,作者如何决定去留?最后怎么收敛?
   **答案**:遇到大到难处理的障碍就直接弃掉该方案;幸存者并排比测,再让 agent 合并各方案最优部分成统一工作流(覆盖率叠加),最后合回主 directives。见详解3、4。 [3:26:10](https://youtu.be/MxyRjL7NG18?t=12370)
3. 抓回的线索为什么不能只看条数?怎么提高有效率?
   **答案**:因为会混入明显无关的错误线索(如 Neurolink 员工、微软 CEO 的邮箱);根源是关键词搜索太粗,改用行业筛选收窄候选再测,有效率明显提升。见详解6。 [3:29:40](https://youtu.be/MxyRjL7NG18?t=12580)