章节主旨
现场从零搭一个 LinkedIn B2B 线索抓取工作流(Sales Navigator → Vain 抓取 → AnyMailFinder 补邮箱 → Google Sheets),并借这个例子讲透一套通用方法:先和 agent 来回收窄构建路径、用新数据而非模型自造用例做测试、串行改并行提速、冷启动验证到「battle-tested」,以及三方案并行探索与 steering(前期把方向掰正)为何是最高回报的动作。
核心论点
- agent 不只是「建造者」,也是「构思助手」——建之前先用自然语言来回问几轮,把需求收窄成高成功率的构建路径,比让它闷头一条路走到底省时得多。(→ 详解1)
- 测试必须喂「新数据」——模型自造的测试用例天然贴合它自己写的脚本格式,过了也不说明什么;拿真实来源的新数据端到端跑一遍才算数。(→ 详解2)
- 第一版工作流一定是最朴素的串行实现,提速靠并行化——把逐条请求改成一次并发几百条,同样的活儿时间可缩到零头。(→ 详解3)
- 真正的「能用」标准是冷启动全新实例能跑通——反复迭代让 agent 把修复写回 directive 与 execution,可靠度会一路爬到 99%+,即所谓 battle-tested。(→ 详解4)
- 让 agent 同时产出三套方案再挑最优,几乎免费——探索多路径的 token 成本相对「智能」的价值极低,却能一次性覆盖大片解空间。(→ 详解5)
- 前期 steering 是整个 agentic 生涯里回报最高的时间——过程步数越多输出方差越大,而你唯一能低成本掰正方向的窗口就在最开头。(→ 详解6)
知识点详解
1. 用 agent 参与构思,来回收窄构建路径 3:09:11
开工第一步不是写代码,而是用语音转写把需求丢给 Claude Code:「我想做一个抓公开信息、产出 B2B 线索清单的工作流,最好的三条路子是什么?」哪怕自己心里已有方案,也让 agent 先帮忙做 ideation(构思)——它会去调研 Phantom Buster、Vain 等工具并回推一条 pipeline。
作者用自己的人类知识参与几轮问答(已有 Sales Navigator 订阅、已有 AnyMailFinder 补邮箱工具、指定用 DOE 框架 搭),把开放需求「pair down」成一条高成功率的构建路径。
为什么值得这么做:agent 建一次东西也就 5-15 分钟,但一旦走错路要退回重来,又得再花 10-15 分钟重建。开头给一点点输入去 steering(方向掰正),既省时又强力。(3:10:24)
建议在它做搜索时至少来回聊几句,用人的判断把「所有可能路径」的总数先砍下来,而不是让模型自己一条条盲试。
2. 用「新数据」测试,而非模型自造的用例 3:12:38
一个高频误区:让模型自己生成测试用例(如 test_leads.csv)再端到端跑。问题在于——模型刚写完这一堆脚本,它造出来的测试数据几乎必然是这些脚本本就期待的格式,过了也不能证明工作流真的健壮。
更有信息量的做法是完全基于「新数据」测。作者的真实测法:回到 LinkedIn Sales Navigator,在左侧生成一个搜索、复制 URL 粘进去让它跑,直接看真实的 231 个 prospect 能抓下多少(结果 231 条里补出 139 个有效邮箱、导出 159 行)。
一句可迁移的原则:验证工作流,只认「模型没见过的输入」;它自证的绿灯不算数。
3. Self-annealing 与串行改并行提速 3:13:31
首轮跑时某个对 Vain 的 API 调用出错,工作流 Self-annealing 自退火 自动诊断并修好,继续往下建——这正是让 agent 在测试循环里自愈的价值。
但第一次建出来的工作流一定是「能多简单就多简单」,通常是串行请求:发一条、等它完、再发下一条。补 200 条邮箱因此拖了很久;作者点出——熟手用批量请求 15 秒就能补完 200 条。
提速手段是 并行化:把逐条串行改成一次并发几百条,再在同一时间块里等所有输出返回。(3:14:45)作者跑到一半嫌慢,直接说「能不能快很多」,模型就把请求全 batch 起来了。要点:先让它端到端至少跑通一次,再谈并行优化。
4. 冷启动验证 + 迭代到 battle-tested 3:13:44
「模型说它好了」和「工作流真的能用」是两码事。作者的验收标准是 冷启动验证:先让它把所有改动(directive 与 execution)文档化,再开一个全新的 Cloud Code 实例(bypass permissions),只丢一句「这是搜索 URL,用我们的 pipeline 抓」。全新实例会自己去查 LinkedIn 抓取的 directive、执行完整抓取——66 个 prospect 抓出 45 个,约 4 分钟跑通,证明它在陌生列表上也成立。
迭代心法:第一版一定不完美(作者自陈「我建的很多东西第一版都很烂」),DOE 本就依赖 iteration。跑几遍、打开推理循环、记下哪里慢/哪里贵/哪个 API 调用不合理,然后直白告诉模型(别拟人化、别怕伤它「感情」),它会诊断并把修复写回 execution 与 directive——下次 fresh 实例开箱即知解法。
这样可靠度会一路往上爬:80% → 90% → 95% → 97% → 98% → …逼近 99.25% 的理论上限。(3:22:59)跑过 10-20 次、见过各种边界情况的工作流,就是所谓 battle-tested(实战淬炼)。
5. 三方案并行探索,几乎免费 3:18:21
一个越来越常用的技巧:不让 agent 只解一条路,而是让它同时产出三套方案。要么人从三者里挑一个,要么更进一步——开三个并行实例各自按一套方案生成 directive + execution 脚本,再按「多快、多可靠、多便宜」实测评分,选最优的那一套。
为什么是三套:探索多方案的成本基本可忽略。token 虽不是真免费,但相对「智能」本身的价值极其便宜,却能一次覆盖一大片解空间——与其让 agent 自己一条条串行摸索,不如把搜索空间切成几份、让三四个 agent 同时探,用十分之一的时间扫完。(3:18:50)
操作提醒:让它们在临时文件夹里跑,明确说「别动主 directive/execution 框架,因为我要把同一任务并发给几个兄弟姐妹 agent」。(3:19:28)
6. Steering 是最高 ROI 的时间 + 构建权衡 3:20:19
任何有输出方差的过程,方差都会随步数累积放大——步骤越往后,模型可能落到的位置就摊得越开。而你唯一能低成本掰正方向的窗口,就在最开头:哪怕第一步就朝错误方向偏一点,后面花再多力气也白搭;若一开始就把方向重新对准目标,解才落在可达范围内。
作者把这叫 steering,像开车(3:21:13):直道上车头起步就有点偏,司机最该做的就是在开头一两分钟把它掰回正中央。因此他强烈建议——真正动手建每套方案前,先问 agent「你会怎么做」,别把「思考本身」也外包给模型。
每种建法都有权衡,值得在 steering 阶段就想清:①速度 vs 成本(要快还是要便宜);②可靠性 vs 复杂度(能塞进 1 个 execution 脚本就别拆成 10 个,简单方案更少坏);③广度 vs 深度(覆盖面广还是少数项挖深);④有些取舍最终仍需人的判断。
术语
- ideation(构思)——让 agent 在动手前帮你调研并生成候选方案、参与想法定型,而非只当代码建造者。
- lead scraping workflow(线索抓取工作流)——自动从公开来源(如 LinkedIn Sales Navigator)抓取 B2B 潜客并补全联系方式的流水线。
- Sales Navigator——LinkedIn 的销售检索工具,按职位/行业/公司规模等筛人并生成可复制的搜索 URL。
- Vain / AnyMailFinder——本例用到的抓取工具与邮箱补全(enrichment)工具。
- self-annealing(自退火)——工作流运行中自动诊断报错并修复、继续推进的能力。
- parallelization(并行化)——把逐条串行请求改为一次并发大量请求以大幅提速。
- battle-tested(实战淬炼)——工作流反复运行、处理过各种边界情况后达到的高可靠状态。
- steering(方向掰正)——在流程最开头以极小代价把 agent 的走向对准目标,回报最高的干预点。
自检问题
- 为什么「让模型自己生成测试用例并跑通」不足以证明工作流可靠? 答案:模型刚写完脚本,它造的测试数据几乎必然贴合这些脚本期待的格式,过了也不说明什么;必须用它没见过的真实新数据端到端测。见详解2。3:12:38
- 第一版工作流为什么通常慢,提速的通用手段是什么? 答案:第一版一定是最朴素的串行实现(发一条等一条),提速靠并行化——一次并发几百条、在同一时间块等全部返回。见详解3。3:14:45
- 为什么值得让 agent 同时产出三套方案,而不是只解一条路? 答案:探索多方案的 token 成本相对「智能」的价值极低,却能一次覆盖一大片解空间;开几个并行实例各建一套再按快/可靠/便宜实测挑最优,用十分之一时间扫完。见详解5。3:18:21
- 作者为什么说前期 steering 是回报最高的时间? 答案:过程输出方差随步数累积放大,唯一能低成本掰正方向的窗口在最开头;起步偏一点后面再努力也白搭,开头对准目标解才落在可达范围。见详解6。3:20:19