apify-lead-generation – B2B 潜在客户线索生成 Skill

3周前更新 8 0 0 0

lead-generation 是帮助 AI Agent 通过 Apify 平台自动化采集潜在客户信息的 Skill,可用于从网页、搜索引擎或社交平台批量抓取企业名称、联系方式等线索数据,适合销售拓客和市场调研场景。

Skill 安装

多 Agent 安装
npx skills add https://github.com/apify/awesome-skills --skill apify-lead-generation

使用 npx skills 快速安装,支持将 Skill 添加到多个兼容的 AI Agent。

Skill 调研报告

Skill 详细介绍

apify/awesome-skills#apify-lead-generation 是 Apify 官方维护的 awesome-skills 仓库中的一个 Skill,用于在 AI Agent 中接入 Apify 平台能力,完成线索生成(Lead Generation)相关的任务。

需要先明确一点:它本身不是一个独立运行的软件,而是提供给 AI Agent 的一套技能指令。安装之后,Agent 会获得与 Apify 平台交互的能力,可以根据用户的自然语言需求,调用 Apify 上的 Actor(爬虫 / 自动化任务)来采集公开数据并整理成结构化线索。

它主要解决什么问题

传统线索获取流程通常需要人工打开多个网站、逐个复制信息、再整理进表格。这个 Skill 的目标是把这套流程交给 AI Agent:用户描述想要的目标客户特征,Agent 通过 Apify 上的现成 Actor 执行采集,再把结果结构化输出。

典型任务

– 从公开目录、企业黄页、行业站点、招聘页面等来源采集潜客信息
– 按关键词、行业、地区、职位等条件筛选目标对象
– 将采集结果整理为结构化线索(如公司名、网址、联系方式等公开字段)
– 批量生成线索池供后续销售或市场团队使用

它和普通 Agent 的区别

普通 Agent 受限于自身没有持续、规模化的网页数据采集能力。这个 Skill 相当于给 Agent 提供了一条通往 Apify 平台 Actor 生态的通道,让 Agent 可以调用平台上成熟的采集工具,而不是自己临时抓取。

能力归属要分清

– Skill 本身:提供的是指令、调用逻辑和与 Agent 的衔接方式
– Apify 平台:提供实际的 Actor 运行、代理、调度、数据存储能力
– 采集到的数据:取决于所选 Actor 和数据源本身

适合谁

– 需要批量获取公开潜客线索的销售、市场、增长团队
– 想用 AI Agent 自动化部分线索调研流程的个人或小团队
– 已经在用 Apify,希望通过 Agent 简化操作的用户

不适合什么需求

– 需要采集非公开或受权限保护的数据
– 需要绕过目标网站条款或法律的场景
– 期望完全免费、无配额限制地大规模采集

线索生成的结果质量和合规性,很大程度上取决于所选 Actor 以及目标网站的条款,这一点在使用前要有清晰预期。

Skill 安全评估

总体判断:这是一个功能正常、用途明确的 Skill,但它会把 AI Agent 连接到 Apify 平台并触发实际的网络采集行为,因此风险主要集中在账号凭证、采集合规和数据使用上,而不是 Skill 本身藏有恶意代码。

一、来源可信度

该 Skill 属于 Apify 官方组织下的仓库,来源可靠度较高。即便如此,仍建议以该 Skill 当前官方仓库和说明为准,不要使用来源不明的镜像或第三方重新发布版本。

二、账号与凭证

使用 Apify 平台通常需要 Apify 账号和对应的 API Token。Token 一旦泄露,可能被他人用于消耗你的账户额度,甚至产生费用。建议:

– 使用专门的 Token,避免使用主账号全权限 Token
– 不要把 Token 写进会公开提交的文件或仓库
– 定期在 Apify 后台轮换 Token

三、网络访问

这个 Skill 的核心功能就是驱动网络采集,因此网络访问属于正常且必需的行为,不应简单判定为危险。需要关注的是采集目标是否允许被抓取。

四、采集合规

– 遵守目标网站的服务条款和 robots 规则
– 遵守所在地区的数据保护法规(如个人信息相关法规)
– 不要用于采集受保护或明确禁止采集的数据

五、Agent 权限

如果 Agent 具备自动执行 Shell 或自动调用外部服务的权限,采集会在你确认前自动发生。如果不希望这样,可以关闭 Agent 的自动执行权限,让每一步操作由你手动确认。

六、成本风险

Apify 上部分 Actor 按用量计费,大规模运行可能产生费用。建议先小批量测试,再扩大规模。

只要账号管理规范、采集目标合规、Agent 权限可控,这个 Skill 的使用风险是可以接受的。

Skill 使用要求

一、Agent / 客户端

该 Skill 来自 Apify 官方组织,主要面向支持 Skill 加载机制的 AI Agent。官方没有公布完整的第三方 Agent 兼容列表。从 Agent Skill 的一般工作方式来看,在支持 Skills 或自定义指令加载的环境(如 Claude Code)中通常可以优先尝试;在 Codex、Cursor、Trae、OpenClaw、WorkBuddy 等其他主流 Agent 中,只要具备类似的 Skill 加载或指令注入能力,一般也可以尝试,但兼容程度可能不同,具体以对应 Agent 当前版本为准。

二、运行环境 / 依赖

| 项目 | 要求 |
|—|—|
| Agent | 支持 Skill 加载的 Agent 均可尝试 |
| Apify 账号 | 通常需要,用于获取 API Token 并运行 Actor |
| 网络 | 必需,需要能访问 Apify 平台 |

具体的运行环境细节以该 Skill 当前官方说明为准。

三、权限

– 网络访问:必需,用于调用 Apify 平台和触发采集
– API Token 使用:通常必需
– 文件读写:可选,用于保存采集结果
– Shell:一般不需要

四、账号 / API Key

– Skill 本身:不包含账号或密钥
– 使用 Apify 服务:通常需要一个 Apify 账号,并获取对应的 API Token

Token 的具体获取和配置方式,以 Apify 官方文档为准。

最小使用条件

1. 一个支持 Skill 加载的 AI Agent
2. 可用的网络环境
3. 一个 Apify 账号及 API Token
4. 明确、合规的采集目标

Skill 安装、使用与卸载教程

一、安装

LemonAIKit 的 Skill 详情页已经单独提供了该 Skill 的安装指令。直接复制本页面提供的安装指令,粘贴到对应的 Agent 或终端中执行即可。

如果你不确定自己使用的 Agent 应该如何安装,可以直接在 Agent 里提问,让它根据自身的 Skill 加载机制来指导:

如何安装 apify/awesome-skills#apify-lead-generation?

如何在 Claude Code 中安装 apify/awesome-skills#apify-lead-generation?

如何在 Cursor 中安装 apify/awesome-skills#apify-lead-generation?

Apify 账号与 API Token 的准备,以 Apify 官方说明为准。

二、安装后如何使用

安装后,用自然语言向 Agent 描述你的线索需求即可。适合交给这个 Skill 的任务包括:按条件批量收集潜客信息、整理公开企业名录、按行业或地区筛选目标对象等。

自然语言使用示例:

使用 apify-lead-generation,帮我从公开行业目录中收集一批做跨境电商的中小企业线索。

使用 apify-lead-generation,按行业和地区收集潜在客户名单,并按公司名称整理成表格。

使用 apify-lead-generation,帮我先小批量测试采集 20 条线索,确认结果格式合适后再扩大规模。

三、卸载

不同 Agent 的 Skill 安装位置和管理方式可能不同。可以:

– 通过对应 Agent 或 Skill 管理器提供的删除方式移除该 Skill
– 直接询问当前 Agent:“如何卸载 apify/awesome-skills#apify-lead-generation?”

如果没有统一的卸载命令,直接让当前 Agent 处理通常更稳妥。

常见问题

使用这个 Skill 一定要有 Apify 账号吗?

通常是需要的。核心采集能力由 Apify 平台上的 Actor 提供,账号和 API Token 是调用这些能力的前提。具体以 Apify 官方说明为准。

采集到的线索数据准确吗?

准确度取决于所选 Actor 和目标数据源本身。不同来源的完整性和更新频率不同,建议先小批量验证结果质量,再决定是否扩大规模。

会不会产生费用?

可能。Apify 上部分 Actor 按用量计费,使用前应了解所选 Actor 的计费方式,并控制采集规模,避免意外成本。

可以同时安装到多个 Agent 中吗?

一般可以。Skill 本身是一套指令,装在不同 Agent 中通常互不影响。不过各 Agent 的 Skill 目录和管理方式不同,具体以对应 Agent 的说明为准。

为什么安装后 Agent 没有识别到这个 Skill?

常见原因包括:Skill 目录位置不对、Agent 未在启动时加载 Skill、或当前 Agent 版本不支持该加载方式。可以先确认安装位置,再让 Agent 检查自身是否已加载该 Skill。

中国大陆使用是否有网络要求?

Apify 是境外平台,在中国大陆访问可能需要稳定的国际网络环境。使用时请遵守当地法律法规,并注意采集目标的合规性。

这个 Skill 适合直接用于生产环境吗?

取决于你的使用场景。建议先在小规模、非关键的流程中验证效果和合规性,再考虑纳入正式业务流程。

Skill 更新日志

版本列表
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-orchestrator-actor-development 技能 (#72) * 添加 apify-orchestrator-actor-development 技能 构建 TypeScript Apify 编排器 Actor —— 使用 apify-orchestrator 库协调一系列子 Actor(可选带有一个 LLM 步骤)。交互式脚手架流程, 包含 Apify MCP schema 发现、通过 maxTotalChargeUsd 实现的每步成本预算, 以及 OpenRouter LLM 步骤。 Co-Authored-By: Claude Opus 4.7 * fix(apify-orchestrator-actor-development): 修正成本跟踪、子任务状态检查和 MCP 字段名 对照实时 Apify 平台和 Apify MCP 服务器进行测量;以下每项更改 都有一次运行或一次调用作为依据,而非仅凭审查。 成本跟踪(返回的 Run 报告 $0): - `run.usageTotalUsd` 在 `.call()` 返回的对象上为 0,而且它不会随后 完整到达 —— 按事件付费的子任务在达到 SUCCEEDED 后数秒内仍会按每个 计费事件计费。实测:一个两项子任务在约 3 秒时读取为 $0.0020, 最终结算为 $0.0040,而一个同类子任务在 8 秒时仍读取为 $0。采用返回的 值会使整个工作流的 `spent` 保持为 0,因此累计总额从未变动。 - 将每个子 Run 记录在账本中,并等待其费用保持稳定,而不仅仅是变为 非零;在每次预算决策前和退出时重新读取已记录的 Run,以便延迟的 费用仍能计入总额。 - 修正关于累计总额可防止失控支出的说法。在均分且子任务遵守其上限的 情况下,该防护无法在最后一步之前触发;它是对未设上限步骤的兜底, 且仅当超支已及时累积完成时才有效。实测:一个未设上限的步骤在总额 $0.0030 的情况下计费 $0.0040,而下一步仍然启动了。 子任务状态(失败的步骤看起来像空步骤): - FAILED、ABORTED 或 TIMED-OUT 的子任务返回一个带有 dataset id 的 Run 对象,读取该 dataset 会得到 [] 而非错误 —— 在一个 TIMED-OUT 子任务上 实测。模板直接调用 listItems(),因此失败的步骤被当作空步骤处理, 工作流报告成功但无数据。添加了 requireSucceeded() 以及一个描述该 失败模式的注意事项。 Apify MCP 字段名(在 apify-mcp-server 0.16.0、7 个 Actor 上实测): - `fetch-actor-details` 的参数是 `actor`,不是 `actorId`;`actorId` 会失败 并报 "must have required property 'actor'"。 - 定价位于 `actorInfo.pricing`,不是 `pricingInfo`。对于按事件付费的 Actor,它会逐项列出费用,这正是设定上限所需的信息。 - 描述上没有 REQUIRED 前缀(7 个 Actor 中 0 个);必填字段通过标准的 `inputSchema.required` 数组传递。两条指示 agent 高亮 REQUIRED 前缀 字段的指令指向了空处。 - 枚举列表不会截断到 200 字符:google-search-scraper 返回了全部 240 个 countryCode 值(480 字符)。 - 所有 7 个 Actor 都缺少 `outputSchema`,包括本技能自己的示例。 同时添加必需的 `metadata` 块(keywords、category: actor-development); 没有它,scripts/generate_agents.py 会无法通过目录 lint。 Co-Authored-By: Claude Opus 5 * chore: 从技能 PR 中移除生成的目录文件 marketplace.json、agents/AGENTS.md 和 README 技能表由 SKILL.md frontmatter 生成,并在合并后由 bot 重新生成;技能 PR 必须只触及 skills/apify-/(validate-pr 范围检查)。 Co-Authored-By: Claude Opus 5 --------- Co-authored-by: Claude Opus 4.7 Co-authored-by: pavel242242
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-blocked-scrape-triage 技能 (#84) * 添加 apify-blocked-scrape-triage 技能 针对返回空结果的抓取进行分诊:在花费任何成本之前,区分硬封锁与 托管挑战、死路径和渲染问题,然后按成本顺序升级,浏览器放在最后。 * 纳入关于分诊技能的审查反馈 - 在使用其挑战标记之前先指明 CDN 供应商,并让正文覆盖缺失的头部 - 解释为什么解除盲化的修复是一个 hook:Actor 输入不包含任何 Crawlee 的 session-pool 选项,这是对照构建 schema 实测的 - 将住宅代理探测设为需先询问,并优先选择免费的第二个观测点而非付费运行 * 将目录元数据移入 SKILL.md frontmatter 目录现在由 frontmatter 生成,因此 keywords 和 category 位于 SKILL.md 中, 手写的 marketplace.json 条目已移除。 * fix(apify-blocked-scrape-triage): 修正实测结论、保护 pageFunction、设置 category 于 2026-09-21 对照实时平台验证;详情如下。 代码修复: - 两个示例 pageFunction 都未加保护地调用了 context.$。在没有 HTML 正文的 响应上 —— 空正文的 403,或 text/plain,即本技能所诊断的正是这种情况 —— context.$ 不是函数,pageFunction 会抛出异常。该项随后带有 #error, 与没有该 hook 的运行无法区分,因此 hook 的效果在下一行就被抵消了。 实测:一次运行中 6 次失败。现已加保护;当没有 HTML 时,依赖 $ 的字段 返回 null。针对 403(可读状态,无抛出)和 HTML 页面(title、scripts、 mountPoints、offHostLinks 不变)重新实测。 修正的结论: - 该 hook 的标题数字将 "items carrying fields" 列引用为 "classified refusals"。根据本技能自己的表格,classified 计数从 0 -> 2,而 3 -> 6 是 items carrying fields。 - `gotOptions.throwHttpErrors = false` 表格行并未测量某个设置:gotOptions 不在该 Actor 的 30 个输入字段中,且该 Actor 接受包含它的输入而不报验证 错误,并静默丢弃它。该行已移除,发现已在原处说明。 - application/json 和 application/xml 属于 cheerio-scraper 的默认 MIME 类型,因此 JSON 端点根本不需要 additionalMimeTypes。该 Actor 在其跳过 错误中列出了自己允许的列表。(该 Actor 发布的 schema 描述在这一点上 已过时。) - 完整账户审批并非仅限浏览器:cheerio-scraper 和 web-scraper 也需要它, 因此这不是偏好其中一个而非另一个的理由。已添加到 Prerequisites, 因为其失败模式在那里很重要:stdout 带退出码 0。 新增: - proxyConfiguration 通过 MCP 是必需的,但通过 CLI 不是。 - CLI 接受 additionalMimeTypes,而 MCP 在任何编码下都拒绝它。 元数据: - category: data-extraction -> actor-development Co-Authored-By: Claude Opus 5 --------- Co-authored-by: pavel242242 Co-authored-by: Claude Opus 5
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-jobs-data 技能 (#40) 添加 apify-jobs-data 技能:通过 agentx/all-jobs-scraper 跨 20+ 个招聘板 提取职位发布,具备跨板去重、启发式幽灵职位和转发标记、规范化字段, 以及在其之上的分析 / 导出 / 简历匹配模式。 在维护者对贡献者分支进行一轮审查后合并:验证了实时 Actor schema 和 定价,按 Actor 修正了上限字段名,删除了 Google Jobs 承诺(不在聚合器 枚举中),在没有捏造证据的情况下重建了简历匹配示例,围绕抓取的职位 描述添加了提示注入边界,并解决了路由矛盾,使一个返回区域内无行的 具名招聘板获得一次有上限的回退运行,而不是被放弃。 通过对照 Actor 自身文档的配对评估验证(9 月 16 日和 21 日): 0 个捏造值,每个统计量都可从记录重新计算,且 7 次 Actor 运行中 无策略偏差。 Co-authored-by: oleg martinez Co-Authored-By: Claude Opus 5
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-app-store-intelligence 技能 (#89) 两次提交:技能由 @donnywin85 提供,以及一次维护者提交,纳入了来自 #41 和 #54 的 Google Play 工作。 取代: - #41 由 @Freshactors 提供 —— freshactors/google-play-scraper mode=details, 带有 1–5★ 的 ratingHistogram、按模式的成本模型,以及跨商店标识符速查表 - #54 由 @0xsline 提供 —— neatrat recentDays 用于硬日期窗口,以及 sortBy "newest" / appVersion 作为真实输入字段
无版本号
feat(apify-app-store-intelligence): 纳入 #41 和 #54,对照实时 API 修正路由事实 - 来自 #41 的 Google Play 模块(@Freshactors):freshactors/google-play-scraper mode=details, 带有 $0.002/app 的 ratingHistogram、按模式的成本模型和跨商店标识符速查表 - 来自 #54 的 Google Play 窗口事实(@0xsline):neatrat recentDays,以及 sortBy "newest" / appVersion 是真实输入字段,尽管该 Actor README 记录的是其他字段 - 路由表现在为每个被路由的 Actor 都带有上限和价格(价格读取自实时 Actor 定价 2026-09-18),包括此前留作 "see schema" 的 fail-open 默认值 - Apple 确实发布 1-5 星直方图:sourabhbgp/apple-app-store-scraper mode=app-details 返回 ratingsHistogram,其总和等于 userRatingCount;includeVersionHistory 不额外收费 (2026-09-19 实测:有和没有均为 $0.004) - changesOnly 按其实际行为记录:该模式下的首次运行会输出每个应用并作为 基线,快照在整个 Apify 账户间共享,rating 以 5 位小数精度进行差异比较, 且源被边缘缓存约 24 小时,因此同日的版本更新可能被遗漏 - apify actors info 接受 --input 而无需 --json(CLI 1.10.0 否则会隐藏 schema) - brilliant_gum 版本可以是字面量 "VARY";评论文本标记为不可信内容 - 目录产物(marketplace.json、README 表格、agents/AGENTS.md)已还原为 main; bot 在合并后从 SKILL.md frontmatter 重新生成它们 Co-Authored-By: Claude Opus 5
无版本号
chore: 为 apify-app-store-intelligence 重新生成目录 该技能在 d32f471 中添加时未重新生成生成的目录,因此 marketplace.json、 agents/AGENTS.md 和 README 技能表未列出它。PR 工作流会重新生成目录并 进行比较;fork PR 的 token 无法将结果推送回去,因此该作业会失败而非 自愈。 由 scripts/generate_agents.py 生成,无手动编辑: 写入 14 个插件。纯新增 —— 26 处插入,0 处删除。 Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01MQCHGvdKdAa9fZroPjrXte
无版本号
fix(apify-osint-threat-intel): 替换已弃用的租赁 Reddit Actor,强制时效性,设置新闻时间范围 (#125) * fix(apify-osint-threat-intel): 将已弃用的 trudax/reddit-scraper 替换为 harshmaur/reddit-scraper trudax/reddit-scraper 在商店中已弃用(租赁,$45/月)。将三个 Reddit 步骤 路由到 harshmaur/reddit-scraper,它已是此处的回退方案,也是 apify-easy-competitive-intelligence 中 main 上的回退方案,其输入已通过实时运行验证:withinCommunity 恰好接受一个 subreddit("A OR B" 值会静默丢弃过滤器并搜索整个 Reddit),postedAfter 强制 窗口(searchTime 不会 —— 该 Actor 会用多年前的帖子填充上限), maxPostsCount 是按搜索词计的,没有 proxy 字段。Troubleshooting 现在指向 RUN-SUMMARY(inputWarnings、emptyReason)以及 fatihtahta/reddit-scraper-search-fast 作为按项付费的回退方案。 Co-Authored-By: Claude Opus 5 * fix(apify-osint-threat-intel): 在 google-news-scraper-fast 示例中设置 timeframe 该 Actor 的 `timeframe` 默认为 `1h`,因此 "recent activity" (2c) 和 "landscape" (2d) 新闻调用几乎返回不了任何内容,除非模型猜到了该字段。 为威胁行为者活动设置 `30d`,为每周 landscape 设置 `7d`,与评估运行 (E3、E4、E8、E9)不得不手动添加的内容一致。 Co-Authored-By: Claude Opus 5 --------- Co-authored-by: Claude Opus 5
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-reddit-scraper 技能 (#114) * feat: 添加 apify-reddit-scraper 技能 * fix(apify-reddit-scraper): 按词成本公式、相对时间段使用 postedAfter、实时 schema 事实 在作者设计之上的维护者文本修正(无结构性更改): - maxPostsCount 是按搜索词计的;成本公式 = terms × maxPostsCount × (1 + maxCommentsPerPost),附来自实时运行的示例计算 - "last month" → postedAfter(强制 sort=new),并明确说明与 searchTime 的权衡 - 运行前显示可见的运行部分(terms、estimate);运行后检查 estimate ≥ settled - dataType user → user_profile;帖子上的 searchTerm 为 null,评论上缺少 postTitle;removed_by 为 snake_case - 错误行与实时 README 一致(错误日期 = fail-open,无目标 = 0 项) - aiAnalysis 在 Free 上计费;UGC 防护语句;--user-agent 仅在可接受处使用 在三次隔离的评估运行中实测(R4/R4b/R4c,0 个捏造值)。 Co-Authored-By: Claude Opus 5 --------- Co-authored-by: Harsh Maur Co-authored-by: Pavel Chocholous Co-authored-by: Claude Opus 5
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
还原手动目录重新生成 目录文件由合并后重新生成工作流负责。此操作还原 e1245ea,以便修复后的 GITHUB_TOKEN 作业能够证明完整流程。
无版本号
Merge pull request #124 from apify/codex/use-github-token-catalog-regen 使用 GITHUB_TOKEN 修复目录重新生成
无版本号
fix: 使用 GitHub token 重新生成目录
无版本号
为 apify-plan-travel 重新生成目录
无版本号
Merge pull request #123 from apify/codex/consolidate-apify-travel-skills 添加整合后的 Apify 旅行规划技能
无版本号
添加整合后的 Apify 旅行规划技能
无版本号
Merge pull request #69 from johnisanerd/add-apify-yandex-search-api 添加 apify-yandex-search-api 技能
无版本号
在将 Yandex Images 合并到 main 后重新生成目录
无版本号
Merge pull request #70 from johnisanerd/add-apify-yandex-image-search-api 添加 apify-yandex-image-search-api 技能
无版本号
合并 main 并应用已审查的 Yandex 图像技能修正
无版本号
合并 main 并应用已审查的 Yandex 网页技能修正
无版本号
Merge pull request #106 from johnisanerd/add-apify-company-data-api 添加 apify-company-data-api 技能
无版本号
Merge pull request #107 from johnisanerd/add-apify-marketing-agency-database 添加 apify-marketing-agency-database 技能
无版本号
应用已审查的 Clutch 技能修正并重新生成目录 (#106)
无版本号
应用已审查的 Clutch 技能修正并重新生成目录 (#107)
无版本号
Merge pull request #93 from luispintoapify/add-apify-product-data-setup 添加 apify-product-data-setup 技能

暂无评论

none
暂无评论...