Make.com 四 Agent 线索路由:用 Gemini 当大脑完成 拉取、评分、分配、通知
目录
凌晨 3 点 47 分,手机弹出 Slack 通知:过去四小时里 412 份新表单提交,全部来自一场 webinar 活动。等我早上 7 点煮上咖啡,销售团队的频道已经变成了投诉箱 —— SDR(Sales Development Representatives,销售开发代表)们手动分拣,用公司名上的正则表达式把 73 条标成"垃圾",还漏掉了 3 个企业级线索里的 2 个。第 3 个企业线索被分给了一个日程排满的初级销售。
那个早上我做了一个决定:用正则评分线索的时代结束,我要把整条管线重构成四个小 agent。十四个月过去了,它一直在跑。在典型的 1,200 条/周的流量下,API(Application Programming Interface,应用程序接口) 和 Make(原 Integromat)操作的月成本大概 11 美元。这篇文章写的就是真实的场景蓝图。
为什么是四个 agent,而不是一个超级 prompt
用一个 mega-prompt 把 enrichment、scoring、routing、notification 全做完,确实很诱人。我搭过。在 10 条线索里 8 条是好的,另外 2 条模型悄悄在幻觉公司规模 —— 因为 prompt 留不出空间让它承认"我不知道"。更糟的是,出问题的时候根本看不出是哪一步坏的。
拆成四个小 agent,一次性解决三件事:
- 可组合 —— 我可以单独换 enrichment 供应商(Apollo、Clearbit、Dropcontact),scoring 完全不动。上个季度我把 Clearbit 换成 Apollo,只因为 Clearbit 改了 credit 定价。其他三个 agent 一个字没改。
- 可调试 —— 每个 agent 都会记录自己的输入包和输出包。SDR 反馈一条线索分错了,我打开这条线索的运行历史,看到每个 agent 的 JSON(JavaScript Object Notation,一种结构化数据格式),一分钟内就能定位坏在哪一步。mega-prompt 的模式下,每次失败都是 prompt engineering 问题。
- 成本与延迟 —— routing 是廉价的规则,scoring 才是贵的 LLM(Large Language Model,大语言模型)调用。拆开之后,70% 的线索根本不会触发 LLM scoring(比如免费邮箱域名 + 通用语气的消息体直接进 nurture 培育序列)。
架构,从上到下
整条管线就是一个 Make.com 场景。6 个模块,其中 4 个是命名"agent" —— 每个 agent 就是一个 HTTP → Make a Request 模块,调用 Gemini API(Google 的 LLM 系列,便宜的调用用 gemini-2.5-flash,scoring 这块大脑用 gemini-2.5-pro),并附带结构化 prompt 和 JSON 响应 schema。
- Webhook 触发 —— Typeform 或 Webflow 表单提交后调用 Make。(1 operation)
- Agent 1:Enrichment —— Apollo API 拿公司 firmographics(规模、行业、融资),然后 Gemini 从公司首页 HTML 里抽出一句"这公司是干嘛的"。(2 operations)
- Filter 模块 —— 如果线索是免费邮箱域名 AND 消息体少于 20 个词,直接分支到 nurture。这步在 LLM 成本之前就把机器人和"随便问问"的长尾干掉。
- Agent 2:Scoring —— Gemini 读完整的 enriched bundle 加原始消息,返回结构化 JSON,包含
score(0-100)、intent(枚举:buy / evaluate / lurk / vendor / spam)和reasoning(1-2 句说明打分依据)。(1 operation) - Agent 3:Routing —— 纯规则模块,没有 LLM。如果
score >= 75且intent in [buy, evaluate],分到企业线索轮询池;score 50-74分到 SMB(Small and Medium Business,中小型企业)队列;score < 50且intent == lurk,加进 newsletter nurture;其余自动回"我们 2 个工作日内联系你"。 - Agent 4:Notification —— 一条 Slack 消息推给被分到的销售所在频道,score 75+ 再加一封邮件。Slack 消息用 Block Kit,带一个"Claim lead"按钮,点一下回调 Make,把 HubSpot 里的 owner 字段更新。
中位线索的端到端延迟:38 秒。每条线索端到端成本:$0.009。其中 $0.0066 是 Gemini scoring 调用,其余是 enrichment 和 Make operation 成本。
开始搭之前你需要的
| 组件 | 原因 |
|---|---|
| Make.com Core 套餐($10.59/月) | 免费档 1,000 ops 撑不过这种流量的第二周。Core 的 10,000 ops 覆盖 1,500 条/月还有富余 |
| Google AI Studio 的 Gemini API key | Agent 1(抽取是便宜活)用 gemini-2.5-flash,Agent 2(scoring 需要推理)用 gemini-2.5-pro |
| Apollo API key,Growth 套餐 | 免费 credit 在 50 条/月就用完。Growth 是现实下限 |
| 一个开放 API 的 CRM | HubSpot、Pipedrive、Salesforce 都行。Make 的 CRM 模块两步就能配好 auth |
| 一个 Slack workspace | 用来推销售通知。邮件可作备份,但销售看邮件的反应慢 |
第一次搭大概 3 小时。之后,改任何一个 agent 的 prompt 是 5 分钟的事。十四个月里我重写了四次 scoring agent 的 prompt,每次都学到了哪些信号真的能预测 SQL(Sales Qualified Lead,销售合格线索)转化。
四个 agent,逐个讲清楚
Agent 1:Enrichment(Apollo + Gemini 抽取)
Apollo People/Company Enrichment API 返回结构化 firmographics —— 行业、员工数、估算营收、技术栈、最近融资事件。这覆盖了我 60% 的需求。剩下的 40% —— 这公司到底干嘛的,用一句大白话讲 —— 来自一次 Gemini 调用:把公司首页 HTML 抽成纯文本,返回一句话。
prompt 故意写短。长的 prompt 更贵,模型也会比"答对"更努力地"显得聪明"。
System:你是一个 B2B(Business to Business,企业对企业)研究助手。读完首页文本,产出一句准确的话,讲清这公司是干嘛的、服务谁、怎么赚钱。如果文本太薄答不了,返回字面量字符串
INSUFFICIENT。 User:{{homepage_text}}Response schema:{ "summary": string }
INSUFFICIENT 这个字面量是一道护栏。Agent 2 看到它,就把 intent 降到 lurk,不管消息体写啥。这个教训我付过学费:有次 Apollo enrichment 返回了某家真实公司的首页,但那其实是个 parking page,Gemini 兴高采烈地幻觉了一段 SaaS 总结。字面量护栏能直接抓住这种失败。
Agent 2:Scoring(大脑)
这是唯一真正用 Gemini Pro 的 agent。它接收完整 bundle:Apollo firmographics、Agent 1 的一句话总结、原始表单字段、消息体。返回结构化 JSON。
System:你给一家 B2B SaaS 公司的入站线索打分。0 到 100,100 表示"这是有预算有时间表的买家"。返回 JSON,包含
score(整数 0-100)、intent(枚举:buy、evaluate、lurk、vendor、spam)、reasoning(1-2 句,引用你用到的实际信号)。不要编造公司细节 —— bundle 缺什么,就把分降下来并说清楚。 User:{{enriched_bundle}}Response schema:{"score": int, "intent": enum, "reasoning": string}
两件事值得说:
第一,response schema 是强制的。Gemini 的结构化输出模式会拒绝任何不匹配 schema 的响应。这条规则是模型"贴心"地返回一段话而不是 JSON 的唯一解药。Make 模块用 HTTP → Make a Request,Response type: JSON,加上 Data structure 校验器。
第二,prompt 明确告诉模型它可以降分。没这句话的时候,模型倾向于给所有线索 60-90 分,因为它分不清哪些字段是缺的。写上之后,"邮件是个人 Gmail、没有 Apollo 数据、消息体写'就是好奇' —— 22 分"成了正常输出。
Agent 3:Routing(不用 LLM,纯规则)
这是整个场景里最无聊的模块,这也是重点。一旦你从 Agent 2 拿到结构化输出,做 routing 决策根本不需要再叫一次 LLM。一个带 3 个分支的 Router 模块就覆盖 95% 场景:
score >= 75 AND intent in [buy, evaluate]→ 企业线索轮询score 50-74→ SMB 队列score 30-49 OR intent == lurk→ newsletter nurture(加入 HubSpot 列表)- 其余 → 自动回复"感谢,2 个工作日内联系"
剩下的 5% —— 高分但行业不在销售团队覆盖范围内 —— 落到一个手动 triage 队列,每天 Slack 摘要一次。SDR 经理周五早上统一看。这是刻意留的 human-in-the-loop 节点。
Agent 4:Notification(Slack Block Kit + HubSpot)
两条路径。score 75 以下:只发 Slack。score 75+:Slack 加邮件,邮件里把完整的 enriched bundle 内嵌进去 —— 因为企业销售在 Slack 认领之前,更喜欢先在邮件里读完整上下文。
Slack 消息用 Block Kit 长这样(简化版):
New lead:Sarah Chen,VP Engineering at LogiTech Solutions Score:87 | Intent:buy | Source:Webinar Q1 "Looking for a tool to replace our current vendor by end of Q2..." Enriched:240 employees,Series B,fintech vertical
[Claim lead][View in HubSpot][Mark as nurture]
Claim lead 按钮是 Slack 交互 webhook,回调 Make。Make 更新 HubSpot 的 owner 字段、把 lead 状态置为 Working、在同一条 thread 里发确认消息。从认领到 CRM 写完,大概 6 秒。
三个最常坏的地方
十四个月的生产环境,同样这三个失败反复出现。我都加了护栏。
1. Apollo 返回陈旧数据。 Apollo 的"估算员工数"对大约 8% 的公司是 6 个月前的快照。Agent 1 老老实实传过去,Agent 2 读着这个陈旧数字打分。修法:在 Agent 1 和 Agent 2 之间加一个 Make 过滤,Apollo 返回的 last_updated 超过 90 天就丢进手动 triage。我周日批量重新 enrichment。
2. 免费邮箱过滤器太凶。 我把阈值设成"免费邮箱域名 AND 消息体少于 20 词"。结果意外多 —— 不少真实买家,尤其是种子轮创业公司的 solo founder 和早期员工,会用 Gmail 写又短又随意的消息。修法:不滤,直接打分。Agent 2 区分 lurk 和 buy 的能力已经够好,过滤器早就不划算了。我第三个月就把它删了。
3. Score 随时间漂移。 大概六个月后,score 分布开始压缩。均值从 60 漂到 70,因为 prompt 在悄悄奖励某些措辞。我校准的方法是:抽 100 条销售实际成单的线索 + 100 条成单后失联的线索,重写 system prompt,让 Gemini 把打分锚定在这两个分布上。这事不是一次性的 —— 我每个季度做一次。成本是一个下午加几百次 Gemini 调用。收益是 score 始终有意义,即使你的买家画像在变。
真正要搭什么,重新想一下
如果只从这篇文章带走一件事,带走这件:不要写一个什么都干的超级 prompt。要搭四个小、可观察、可替换的 agent。赢的不是 LLM,赢的是 —— 当下个季度 Clearbit 改定价,或者 Gemini 的结构化输出模式改了参数名,你用一个下午就能换掉一个 agent,其他三个照常跑。
那个早上 412 条没打分的线索,正则并没有错,它做了正则该做的事。错的是把一个需要判断力的活交给确定性规则去扛。四 agent 管线并没有"解决"线索打分 —— 它让打分变得可观察、可替换、可审计。这才是生产级 AI 真正该有的样子,也是 SDR 早上 7 点 @ 你时你真正想要的东西。