做 B2B 获客的朋友应该都有过这种体验最花时间的不是“发消息”而是“找谁聊”。销售团队每天泡在 LinkedIn、企业官网、展会名单里翻候选人几个小时过去真正的有效线索没几条如果花钱买名单又面临数据过时、联系人离职、行业标签不准的问题。开源社区最近出现的一批“AI 代理自动找 B2B 潜客”项目试图把这条最原始的“人肉寻客流程”改造成一条自动化流水线。这类项目最吸引人的点是无需自备客户列表AI 代理会自己完成从线索发现、信息补充、联系人验证到初步触达的全过程。我的判断是这类项目的真正价值不在于“用 AI 生成一批名单”而在于把过去分散在搜索、清洗、验证、写作、发送等环节的工作合并成一个可复用、可审计的 Agent 工作流。它改变的是 B2B 获客流程中“从 0 到 1”的那一步不是让已有名单更高效而是让“没有名单时也能冷启动”。这篇快报文章会围绕“开源 AI 代理自动找 B2B 潜客”这个方向讲清楚它的技术原理、适用边界、典型架构、最小实践示例以及你接入时最容易踩的坑。如果你正在做销售工具、增长工具或者你是独立开发者想给某个垂直行业做线索系统这篇文章可以帮你少走不少弯路。1. 这篇文章真正要解决的问题很多技术人第一次看到这类项目会下意识把它理解为“高级爬虫 ChatGPT 写信”。这个理解不算错但漏掉了最关键的差异它不是抓取一批网址而是围绕“一个目标人物/公司”完成多轮决策。传统的 B2B 找线索流程大概是这样的销售 or 市场人员定义目标客户画像比如“年营收 5000 万以上、总部在华东、使用 Salesforce 的软件服务公司”。人手去企业信息平台搜索逐条查看官网、新闻、招聘信息判断是否匹配。把匹配的公司和联系人整理进 Excel。用邮箱验证工具批量验证联系人邮箱。写一封模板邮件手动或半自动发送。把有回复的线索录入 CRM。这个过程的问题很明显每一步都非常耗时而且高度依赖人的经验。新人可能连“找什么”都理解不清楚只能照着老板给的十几个关键词硬搜。AI 代理解决的不是某一环而是把第 1 步到第 6 步串成一个可执行的“任务闭环”。更关键的是它实现了“无需自备列表”你只需要输入一个目标画像比如“帮助跨境卖家做独立站营销 SaaS 的公司”Agent 会自己去公开数据源里找候选公司再用 LLM 判断是否是目标客户、提取联系人、验证邮箱最后生成个性化触达文案。所以这篇文章真正要回答的问题有三个这类开源 AI 代理的内部结构是怎样的它凭什么能找到“未提供名单”的潜客想跑通一个最小 Demo需要准备哪些环境、配置和代码真实场景中哪些环节最容易失败哪些合规风险必须提前规避如果你只是想要一个“输入关键词、输出客户名单”的工具这类项目当前还不能无脑用但如果你把它当作自动化工作流的参考实现它打开的思路非常有价值。2. 什么是“AI 代理找 B2B 潜客”核心概念与适用场景2.1 从“ChatBot”到“Agent”的关键升级这里需要先澄清一个概念AI Agent 和常见的 AI 聊天机器人不是一回事。聊天机器人是“你问一句它答一句”。它没有自主行动的能力也不会为你调用外部工具。你问它“帮我找几家做跨境电商 SaaS 的公司”它只能给你一段泛泛的建议不能真的去搜索。AI Agent 则是在大模型的基础上增加了“感知—决策—行动”的循环感知观察当前任务状态例如候选公司列表、网页内容、验证结果决策调用 LLM 判断下一步做什么例如“这家公司看起来匹配继续查找创始人信息”行动执行具体工具例如调用搜索接口、请求网页、发送验证邮件、写数据库。在 B2B 潜客发现这个场景里Agent 的每一步都需要工具配合。常见的工具包括搜索引擎 API 或网页搜索企业信息查询接口邮箱验证服务邮件发送服务CRM 系统接口。因此一个“找潜客 Agent”本质上是一个编排系统LLM 负责判断工具负责执行。2.2 “无需自备列表”的含义与误区“无需自备列表”是这类项目的核心卖点但它的准确含义是你不必提供一份现成的公司或联系人名单Agent 会用目标画像Ideal Customer Profile, ICP自动构建候选池。这里有一个新手容易踩的误区以为“无需自备列表”等于“随便输入一个模糊想法就能得到高质量客户”。实际并非如此。Agent“找谁”的准确性极大依赖你如何描述目标画像。先看一个模糊画像找做外贸的公司。再看一个稍微可执行的画像目标中国出海 DTC 品牌提供独立站建站与营销自动化服务的 SaaS 公司。 公司规模50-500 人。 目标客户年 GMV 1000 万以上的跨境电商卖家。 关键信号官网有 pricing 页面、有英语版页面、招聘信息中出现 Shopify 或 Stripe。真正能跑通的 Agent 项目都会把后面这种“可执行画像”作为输入。它要求的是你能把业务经验转成结构化规则而不是让 AI 替你思考“我的客户是谁”。2.3 适用场景与不适用场景从目前的开源项目和行业实践看这类 AI 代理比较适合以下场景目标客户是公开信息充足的企业而不是个体消费者获客链路是“少而准”而不是“广撒网”你已经有初步筛选标准想用自动化扩大排查范围触达是通过邮件或 LinkedIn 等允许自动化的渠道而不是微信或电话。反之在以下场景中它并不合适目标人群是个人消费者个人信息保护风险很高数据源需要登录后才能访问或者需要跨越复杂的身份验证业务高度依赖“人情关系”首封触达邮件作用不大候选池非常小人工处理反而更快。一句话总结这个方向适合“批量初筛 人工精准跟进”的组合模式而不是把销售直接替换掉。3. “无需自备列表”的背后核心流程与架构拆解一个成熟的“AI 代理自动找 B2B 潜客”项目内部流程通常可以拆成五个阶段。每个阶段都有输入、输出和需要做好的技术决策。3.1 阶段一线索发现Prospect Discovery目标是从公开信息中找到“候选公司集合”。常见数据源包括企业信息平台公开数据行业目录与展会参展商名单招聘网站上的企业招聘信息开源社区、技术社区的企业账号与招聘帖垂直新闻媒体中出现的企业动态。这个阶段的技术难点是“去重”和“初筛”。Agent 不可能把全网所有公司都拉一遍它需要根据目标画像中的关键词、地域、规模信号做初步过滤。例如如果画像要求“员工规模 50-500 人”那么 agent 可以先通过企业信息查询接口批量获取员工规模范围而不是等抓到官网后再判断。这个阶段最常见的坑是候选池太大导致后续 LLM 判断和邮箱验证成本飙升。最佳实践是先用“硬性条件”做规则过滤再用 LLM 做“软性判断”。3.2 阶段二信息增强Enrichment拿到候选公司列表后Agent 不能跳过“信息补充”直接找联系人。它需要为每一家公司补充足够上下文官网地址、所在行业、成立时间公司最近动态融资、产品发布、招聘岗位技术栈信号通过官网 HTML 或公开技术博客判断关键决策人线索CEO、CMO、销售负责人等。这一步的关键技术点是如何从非结构化网页中提取结构化信息。许多开源项目会采用“抓取正文 → 分块 → LLM 抽取”的方式。抽取结果通常用 JSON Schema 来约束例如{ company_name: string, website: string, industry: string, headcount_range: string, tech_stack: [string], recent_news: [string], decision_makers: [ { name: string, title: string, email: string } ] }不要试图用一个大 prompt 塞进去所有网页内容。更可靠的做法是先把网页正文提取出来再按段落或语义块交给 LLM 抽取。3.3 阶段三联系人发现与邮箱验证Contact Discovery Verification这是决定项目能否真正落地的一步。很多项目在“找公司”环节很棒但到了找联系人阶段就掉链子因为个人邮箱比企业公开邮箱更难获取。目前的常见验证策略是组合多种信号公开渠道中的邮箱企业邮箱命名规则如 firstname.lastnamedomain.com邮箱验证服务返回的 deliverability 状态社交媒体账号交叉确认。需要特别注意验证服务并不是 100% 准确且频繁验证会消耗 API 预算。更稳妥的做法是先过滤明显不合格的格式比如缺少域名、包含 spam 特征词再调用验证服务。3.4 阶段四个性化触达内容生成Personalized Outreach找到联系人之后Agent 需要生成一封“看起来不像模板”的邮件。这部分的典型实现方式是用一个 Prompt 模板把前面阶段收集到的公司信息、联系人角色、你的产品介绍都拼接进去让 LLM 生成 3 到 5 个不同版本再由人工挑选或 A/B 测试。但这里有一个容易被忽略的问题生成内容越多触达的一致性越难控制。建议在 Prompt 里明确“只写一段 80-120 字的引入语不要编造没有依据的客户数据”避免 LLM 一本正经地编造“贵公司年营收 3000 万”这类信息。3.5 阶段五发送与后续动作Send Follow-up发送环节通常不走 LLM而是用 SMTP 或第三方邮件 API 完成。一个合格的系统还应该包括发送频率限制避免触发垃圾邮件机制退订链接合规必需打开/回复事件的回调将已触达记录写入 CRM 或数据库。很多开源项目会把“发送”做成可插拔模块开发环境使用本地邮件调试工具生产环境切换到真实邮件服务。这是非常推荐的工程实践。3.6 架构图拆解用文字描述整体流程虽然正文不引入图表但你可以按下面的模块清单理解整体架构配置层ICP 画像、数据源开关、验证规则、发送策略 ↓ 调度层以公司为单位依次执行 发现 → 增强 → 验证 → 触达 ↓ 数据层数据库表companies / contacts / campaigns / events ↓ 集成层搜索 API、抓取模块、LLM 接口、验证服务、邮件服务、CRM调度层是整个 Agent 的核心。它决定了当前任务是串行还是并行、失败重试几次、哪些阶段可以由 LLM 动态决策哪些阶段必须走固定规则。4. 环境准备与前置条件如果只是想理解原理看完第 3 章就够了但如果想跑通一个最小示例建议按下面的环境准备。以下版本信息仅供参考请以你实际安装时的最新稳定版本为准。本文重点演示通用思路不锁定某个特定项目版本。4.1 操作系统与基础工具Linux / macOS 均可Windows 建议使用 WSL2 或 Docker 环境。Python 3.10 或更高版本。Git。Docker可选用于启动数据库或邮件调试服务。4.2 Python 依赖以通用实现为例至少需要以下依赖openai1.0.0 requests2.31.0 pydantic2.0.0 python-dotenv1.0.0 rich13.0.0你可以用以下命令创建虚拟环境并安装依赖python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install openai requests pydantic python-dotenv rich4.3 LLM 接口准备这类 Agent 需要调用大模型做判断和生成。你可以选择OpenAI 兼容接口本地部署的开源模型如通过 Ollama 或 vLLM 提供兼容服务。如果选择本地模型需要保证机器内存足够并在代码中把 base_url 指向本地服务。这样也可以避免外部接口不稳定带来的影响。4.4 数据存储最小 Demo 阶段不必上重型数据库使用 SQLite 即可。一个简单的表结构可以这样设计CREATE TABLE IF NOT EXISTS companies ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, website TEXT, industry TEXT, headcount_range TEXT, source TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE IF NOT EXISTS contacts ( id INTEGER PRIMARY KEY AUTOINCREMENT, company_id INTEGER, name TEXT, title TEXT, email TEXT, verified INTEGER DEFAULT 0, created_at TEXT DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE IF NOT EXISTS campaigns ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, contact_id INTEGER, status TEXT, message TEXT, sent_at TEXT, reply_at TEXT );4.5 合规前提在开始任何演示之前必须明确这一点B2B 潜客发现涉及企业联系人信息不同国家/地区对商业联系人数据的使用和触达有不同法律要求。请务必只使用公开的商业信息不采集个人敏感信息遵守目标网站的服务条款和 robots 协议控制请求频率避免影响对方网站稳定性设置退订链接遵守反垃圾邮件法规生产环境使用前咨询法务。这不是套话。很多开源项目只管“技术能跑”不会替你把合规问题也解决掉这是你自己要守住的红线。5. 完整示例一个最小可运行的潜客发现 Agent下面这个示例是“通用实现演示”目的是把第 3 章的理论流程落到代码上。它不代表任何具体开源项目的 API只是帮助你理解核心流程。5.1 项目目录规划prospect-agent/ ├── config.yaml ├── prospect_agent.py ├── requirements.txt ├── .env └── data/ └── prospects.db5.2 配置文件config.yamlconfig.yaml 是 Agent 的“大脑”里面定义了目标画像、数据源开关和运行参数# 文件路径prospect-agent/config.yaml icp: description: 找中国出海 DTC 品牌提供独立站建站与营销自动化服务的 SaaS 公司 region: cn industry_keywords: - 跨境电商 - 独立站 - DTC - 营销自动化 headcount_range: 50-500 signals: - 官网有 pricing 页面 - 有英语版页面 - 招聘信息中出现 Shopify 或 Stripe data_sources: search_api: enabled: true max_results_per_keyword: 10 business_directory: enabled: false verification: email_verify_api: enabled: false max_verified_per_run: 20 llm: model: gpt-4o-mini temperature: 0.2 database: path: data/prospects.db说明icp.description是给 LLM 看的目标画像描述industry_keywords和signals是给规则引擎用的硬性筛选信号verification.email_verify_api.enabled先关闭避免 Demo 阶段产生外部 API 费用llm.temperature设为 0.2让判断更稳定。5.3 核心代码prospect_agent.py下面代码是单文件最小实现把“发现—增强—验证—生成触达文案”串起来。# 文件路径prospect-agent/prospect_agent.py import json import os import sqlite3 import time from dataclasses import dataclass, asdict import requests import yaml from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI(api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL)) dataclass class Company: name: str website: str industry: str headcount_range: str signals: list decision_makers: list def load_config(path: str) - dict: with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def setup_db(db_path: str) - sqlite3.Connection: conn sqlite3.connect(db_path) conn.execute( CREATE TABLE IF NOT EXISTS companies ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, website TEXT, industry TEXT, headcount_range TEXT, source TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP ) ) conn.execute( CREATE TABLE IF NOT EXISTS contacts ( id INTEGER PRIMARY KEY AUTOINCREMENT, company_id INTEGER, name TEXT, title TEXT, email TEXT, verified INTEGER DEFAULT 0, created_at TEXT DEFAULT CURRENT_TIMESTAMP ) ) conn.commit() return conn def search_candidates(config: dict) - list: 模拟从公开数据源搜索候选公司。 在实际项目中这里会调用搜索 API、企业信息平台或行业目录。 为了演示这里返回几条伪造数据并标注来源。 return [ { name: 示例出海科技, website: https://example-saas.com, industry: SaaS, headcount_range: 100-200, signals: [官网有 pricing 页面, 招聘信息中出现 Shopify], }, { name: 远方营销云, website: https://example-marketing.cn, industry: MarTech, headcount_range: 50-100, signals: [有英语版页面, 招聘信息中出现 Stripe], }, ] def llm_judge_company(config: dict, raw: dict) - dict: 让 LLM 判断一家公司是否匹配目标画像并抽取关键字段。 icp config[icp] prompt f 判断下面的公司是否符合目标画像。 目标画像{icp[description]} 硬性行业关键词{icp[industry_keywords]} 额外信号{icp[signals]} 候选公司信息 {json.dumps(raw, ensure_asciiFalse)} 请返回 JSON格式如下 {{ match: true, reason: 简短理由, decision_makers: [ {{name: 张三, title: CEO, email: zhangsanexample.com}} ] }} resp client.chat.completions.create( modelconfig[llm][model], temperatureconfig[llm][temperature], messages[ {role: system, content: 你是一个严谨的 B2B 潜客筛选助手只返回 JSON。}, {role: user, content: prompt}, ], ) content resp.choices[0].message.content return json.loads(content) def save_company(conn: sqlite3.Connection, company: Company) - int: cur conn.execute( INSERT INTO companies (name, website, industry, headcount_range, source) VALUES (?, ?, ?, ?, ?), (company.name, company.website, company.industry, company.headcount_range, agent_demo), ) conn.commit() return cur.lastrowid def save_contact(conn: sqlite3.Connection, company_id: int, contact: dict) - None: conn.execute( INSERT INTO contacts (company_id, name, title, email, verified) VALUES (?, ?, ?, ?, 0), (company_id, contact[name], contact[title], contact[email]), ) conn.commit() def generate_outreach_message(config: dict, company: Company, contact: dict) - str: 基于公司信息生成一段个性化触达文案。 prompt f 你是一家营销 SaaS 公司的销售顾问。请写一段 80 字以内的英文邮件开场白。 目标是引起对方兴趣不要编造对方公司数据。 公司名称{company.name} 公司官网{company.website} 行业信号{company.signals} 联系人{contact[name]}职位{contact[title]} 邮件开场白 resp client.chat.completions.create( modelconfig[llm][model], temperature0.7, messages[{role: user, content: prompt}], ) return resp.choices[0].message.content.strip() def main(): config load_config(config.yaml) conn setup_db(config[database][path]) candidates search_candidates(config) for raw in candidates: result llm_judge_company(config, raw) if not result[match]: print(f跳过{raw[name]}原因{result.get(reason, 无)}) continue company Company( nameraw[name], websiteraw[website], industryraw[industry], headcount_rangeraw[headcount_range], signalsraw[signals], decision_makersresult.get(decision_makers, []), ) company_id save_company(conn, company) for dm in company.decision_makers: save_contact(conn, company_id, dm) message generate_outreach_message(config, company, dm) print(f已保存联系人{dm[name]} - {dm[email]}) print(触达文案, message) print(- * 60) # 演示节奏防止请求过快 time.sleep(1) conn.close() print(Demo 运行完成数据已写入 SQLite。) if __name__ __main__: main()代码要点说明search_candidates目前返回模拟数据真实项目请替换为搜索 API 或企业信息接口llm_judge_company让 LLM 输出匹配结果和决策人列表这是“AI 判断”的核心环节generate_outreach_message只生成文案不负责发送发送需要单独接邮件服务数据库字段与第 4.4 节的表结构一一对应便于你后续扩展字段。5.4 环境变量文件.env# 文件路径prospect-agent/.env OPENAI_API_KEYsk-xxxx OPENAI_BASE_URLhttps://api.openai.com/v1如果你使用本地模型可以把 OPENAI_BASE_URL 指向本地兼容服务。5.5 运行命令cd prospect-agent python prospect_agent.py如果你是第一次运行建议只保留search_candidates中 1 到 2 条候选数据先验证流程通不通再扩大数据源。6. 运行结果与效果验证运行 Demo 成功后你会看到类似下面的输出已保存联系人张三 - zhangsanexample.com 触达文案Hi Zhang, I noticed that your team is building cross-border e-commerce SaaS products... ------------------------------------------------------------ 已保存联系人李四 - lisiexample.com 触达文案Hi Li, your marketing cloud looks interesting, especially the Stripe integration... ------------------------------------------------------------ Demo 运行完成数据已写入 SQLite。验证是否成功的标准不能只看“有没有报错”。建议按以下顺序确认数据库表是否生成了记录sqlite3 data/prospects.db SELECT * FROM companies; sqlite3 data/prospects.db SELECT * FROM contacts;预期能看到companies表新增记录contacts表也有对应联系人记录。匹配判断是否合理查看llm_judge_company返回的match和reason确认 LLM 不是把所有公司都判为匹配。如果全部匹配或全部不匹配通常是目标画像描述太模糊或太苛刻。触达文案是否“看起来像人写的”如果文案里有明显的编造数字或者与公司信息无关说明 prompt 需要加限制。联系人邮箱格式Demo 阶段没接验证服务所以必须人工检查邮箱格式是否符合namedomain.com的规范。如果发现格式杂乱说明邮箱抽取逻辑还需要调整。如果运行失败最常见的两类原因是OPENAI_API_KEY 没有正确加载或者 LLM 返回的不是合法 JSON。前者检查.env文件路径和变量名后者在代码里增加异常处理或重试机制。7. 常见问题与排查思路问题现象可能原因排查方式解决方案运行时报ModuleNotFoundError: openai依赖未安装或虚拟环境未激活执行pip list查看已安装包激活虚拟环境后重新安装依赖LLM 返回内容无法解析为 JSONPrompt 约束不足或模型输出带多余文字打印content原始内容在 Prompt 中强调“只返回 JSON”增加重试和清洗逻辑所有候选公司都被判定为不匹配目标画像描述过严或行业关键词太窄检查config.yaml中的icp配置放宽规模范围或减少硬性关键词所有候选公司都被判定为匹配画像描述太模糊查看reason字段是否空泛补充明确信号如“官网有 pricing 页面”联系人邮箱格式混乱抽取 prompt 没有给出格式约束检查 LLM 返回的decision_makers在 JSON Schema 中强制规定字段格式并做正则过滤发送邮件进入垃圾箱发送内容模板化严重、发送频率过高检查邮件服务商投递报告提高个性化程度限制每日发送量配置 SPF/DKIM外部网站访问被拒绝请求频率过快或未遵守网站条款查看 HTTP 状态码和日志降低并发增加延时使用官方 API排查顺序建议先看命令行输出中的错误堆栈再看数据库是否写入记录最后检查 LLM 返回的原始内容。不要在不知道是哪一步失败的情况下盲目改 prompt。8. 最佳实践与工程建议8.1 先“规则过滤”再“LLM 判断”LLM 判断成本高、速度慢不适合对所有候选公司无差别执行。更合理的做法是先用规则引擎过滤掉明显不匹配的公司例如地点、员工规模、行业关键词再用 LLM 对剩余候选做深度判断最后再决定是否进入联系人发现环节。这样既能节省成本也能让判断结果更稳定。8.2 把“联系人验证”当独立服务不建议把邮箱验证逻辑直接写进 Agent 主流程。原因有三第三方验证 API 经常有配额限制需要做熔断验证服务响应时间不稳定串行等待会拖慢整体流程后续还需要重复验证同一域名下的多个邮箱独立模块更好复用。最佳实践是把联系人验证做成异步任务验证结果回调更新contacts表。8.3 所有外部调用都要可重试、可降级一个完整的潜客发现流程会依赖搜索接口、LLM、验证服务、邮件服务等多个外部系统。任何一个不稳定都会导致任务中断。建议为每个外部调用增加超时时间最大重试次数失败降级策略比如跳过该阶段并记录日志而不是中断整个任务。8.4 数据质量要“可审计”这类项目最容易出问题的地方是对 LLM 生成结果的过度信任。LLM 可能虚构不存在的联系人也可能把“可能匹配”写成“确定匹配”。因此数据库里应该增加两个字段source这条记录来自哪个数据源confidenceLLM 或规则引擎给出的置信度。这样做的好处是后续你可以复盘“哪些数据源质量高”“哪些 prompt 误判多”而不是把所有记录混在一起。8.5 触达频率必须人为限制开源项目默认参数往往比较“激进”因为它想演示出效果。但你接入真实业务时必须设置发送上限。建议每个域名每日最多发送 1 到 2 封每轮 Campaign 总量不超过 100 封必须有退订链接和人工审核机制。好的工具不是帮你发更多邮件而是帮你筛出更值得发的那批人。8.6 本地开发与生产环境分离本地开发时邮件发送建议使用本地邮件调试工具而不是真实发送。这样既不会打扰真实用户也能方便查看渲染效果。生产环境再切换到真实邮件服务并通过 webhook 将打开、回复、退订事件写入数据库。9. 总结与后续学习方向回到这一期 GitHub 快报想传达的核心信号开源 AI 代理正在从“聊天玩具”走向“垂直业务自动化”“无需自备列表的 B2B 潜客发现”就是其中一个典型方向。它的技术本质不是简单的爬虫加 ChatGPT而是一个把规则引擎、大模型判断、数据验证、自动化触达组合起来的 Agent 工作流。如果你要动手实践按照本文第五部分的代码跑通最小 Demo你会在 10 分钟内完成“发现一家候选公司 → LLM 判断 → 保存联系人 → 生成触达文案”的完整链路。之后的优化方向很清楚把模拟数据源换成真实的企业信息 API 或行业目录增加邮箱验证服务把 SQLite 换成 PostgreSQL接入 CRM 系统把已触达联系人同步过去为目标画像增加更多业务规则让 LLM 判断更精准。需要再次提醒的是技术只是水位合规是底线。不要采集个人敏感信息不要遵守不了 robots 协议还要硬抓不要一天给同一个域名发几十封邮件。先在小范围验证、再逐步放大才是这类项目最稳妥的落地方式。下一篇快报中我建议关注的方向是“开源 Agent 如何与 CRM 数据双向同步”因为潜客发现只是起点真正决定业务价值的是后续数据回流和跟进策略。你可以先把本文里的表格结构和数据库字段设计好到时候接入 CRM 会顺畅很多。 开源AI代理如何实现B2B潜客自动化发现？
做 B2B 获客的朋友应该都有过这种体验最花时间的不是“发消息”而是“找谁聊”。销售团队每天泡在 LinkedIn、企业官网、展会名单里翻候选人几个小时过去真正的有效线索没几条如果花钱买名单又面临数据过时、联系人离职、行业标签不准的问题。开源社区最近出现的一批“AI 代理自动找 B2B 潜客”项目试图把这条最原始的“人肉寻客流程”改造成一条自动化流水线。这类项目最吸引人的点是无需自备客户列表AI 代理会自己完成从线索发现、信息补充、联系人验证到初步触达的全过程。我的判断是这类项目的真正价值不在于“用 AI 生成一批名单”而在于把过去分散在搜索、清洗、验证、写作、发送等环节的工作合并成一个可复用、可审计的 Agent 工作流。它改变的是 B2B 获客流程中“从 0 到 1”的那一步不是让已有名单更高效而是让“没有名单时也能冷启动”。这篇快报文章会围绕“开源 AI 代理自动找 B2B 潜客”这个方向讲清楚它的技术原理、适用边界、典型架构、最小实践示例以及你接入时最容易踩的坑。如果你正在做销售工具、增长工具或者你是独立开发者想给某个垂直行业做线索系统这篇文章可以帮你少走不少弯路。1. 这篇文章真正要解决的问题很多技术人第一次看到这类项目会下意识把它理解为“高级爬虫 ChatGPT 写信”。这个理解不算错但漏掉了最关键的差异它不是抓取一批网址而是围绕“一个目标人物/公司”完成多轮决策。传统的 B2B 找线索流程大概是这样的销售 or 市场人员定义目标客户画像比如“年营收 5000 万以上、总部在华东、使用 Salesforce 的软件服务公司”。人手去企业信息平台搜索逐条查看官网、新闻、招聘信息判断是否匹配。把匹配的公司和联系人整理进 Excel。用邮箱验证工具批量验证联系人邮箱。写一封模板邮件手动或半自动发送。把有回复的线索录入 CRM。这个过程的问题很明显每一步都非常耗时而且高度依赖人的经验。新人可能连“找什么”都理解不清楚只能照着老板给的十几个关键词硬搜。AI 代理解决的不是某一环而是把第 1 步到第 6 步串成一个可执行的“任务闭环”。更关键的是它实现了“无需自备列表”你只需要输入一个目标画像比如“帮助跨境卖家做独立站营销 SaaS 的公司”Agent 会自己去公开数据源里找候选公司再用 LLM 判断是否是目标客户、提取联系人、验证邮箱最后生成个性化触达文案。所以这篇文章真正要回答的问题有三个这类开源 AI 代理的内部结构是怎样的它凭什么能找到“未提供名单”的潜客想跑通一个最小 Demo需要准备哪些环境、配置和代码真实场景中哪些环节最容易失败哪些合规风险必须提前规避如果你只是想要一个“输入关键词、输出客户名单”的工具这类项目当前还不能无脑用但如果你把它当作自动化工作流的参考实现它打开的思路非常有价值。2. 什么是“AI 代理找 B2B 潜客”核心概念与适用场景2.1 从“ChatBot”到“Agent”的关键升级这里需要先澄清一个概念AI Agent 和常见的 AI 聊天机器人不是一回事。聊天机器人是“你问一句它答一句”。它没有自主行动的能力也不会为你调用外部工具。你问它“帮我找几家做跨境电商 SaaS 的公司”它只能给你一段泛泛的建议不能真的去搜索。AI Agent 则是在大模型的基础上增加了“感知—决策—行动”的循环感知观察当前任务状态例如候选公司列表、网页内容、验证结果决策调用 LLM 判断下一步做什么例如“这家公司看起来匹配继续查找创始人信息”行动执行具体工具例如调用搜索接口、请求网页、发送验证邮件、写数据库。在 B2B 潜客发现这个场景里Agent 的每一步都需要工具配合。常见的工具包括搜索引擎 API 或网页搜索企业信息查询接口邮箱验证服务邮件发送服务CRM 系统接口。因此一个“找潜客 Agent”本质上是一个编排系统LLM 负责判断工具负责执行。2.2 “无需自备列表”的含义与误区“无需自备列表”是这类项目的核心卖点但它的准确含义是你不必提供一份现成的公司或联系人名单Agent 会用目标画像Ideal Customer Profile, ICP自动构建候选池。这里有一个新手容易踩的误区以为“无需自备列表”等于“随便输入一个模糊想法就能得到高质量客户”。实际并非如此。Agent“找谁”的准确性极大依赖你如何描述目标画像。先看一个模糊画像找做外贸的公司。再看一个稍微可执行的画像目标中国出海 DTC 品牌提供独立站建站与营销自动化服务的 SaaS 公司。 公司规模50-500 人。 目标客户年 GMV 1000 万以上的跨境电商卖家。 关键信号官网有 pricing 页面、有英语版页面、招聘信息中出现 Shopify 或 Stripe。真正能跑通的 Agent 项目都会把后面这种“可执行画像”作为输入。它要求的是你能把业务经验转成结构化规则而不是让 AI 替你思考“我的客户是谁”。2.3 适用场景与不适用场景从目前的开源项目和行业实践看这类 AI 代理比较适合以下场景目标客户是公开信息充足的企业而不是个体消费者获客链路是“少而准”而不是“广撒网”你已经有初步筛选标准想用自动化扩大排查范围触达是通过邮件或 LinkedIn 等允许自动化的渠道而不是微信或电话。反之在以下场景中它并不合适目标人群是个人消费者个人信息保护风险很高数据源需要登录后才能访问或者需要跨越复杂的身份验证业务高度依赖“人情关系”首封触达邮件作用不大候选池非常小人工处理反而更快。一句话总结这个方向适合“批量初筛 人工精准跟进”的组合模式而不是把销售直接替换掉。3. “无需自备列表”的背后核心流程与架构拆解一个成熟的“AI 代理自动找 B2B 潜客”项目内部流程通常可以拆成五个阶段。每个阶段都有输入、输出和需要做好的技术决策。3.1 阶段一线索发现Prospect Discovery目标是从公开信息中找到“候选公司集合”。常见数据源包括企业信息平台公开数据行业目录与展会参展商名单招聘网站上的企业招聘信息开源社区、技术社区的企业账号与招聘帖垂直新闻媒体中出现的企业动态。这个阶段的技术难点是“去重”和“初筛”。Agent 不可能把全网所有公司都拉一遍它需要根据目标画像中的关键词、地域、规模信号做初步过滤。例如如果画像要求“员工规模 50-500 人”那么 agent 可以先通过企业信息查询接口批量获取员工规模范围而不是等抓到官网后再判断。这个阶段最常见的坑是候选池太大导致后续 LLM 判断和邮箱验证成本飙升。最佳实践是先用“硬性条件”做规则过滤再用 LLM 做“软性判断”。3.2 阶段二信息增强Enrichment拿到候选公司列表后Agent 不能跳过“信息补充”直接找联系人。它需要为每一家公司补充足够上下文官网地址、所在行业、成立时间公司最近动态融资、产品发布、招聘岗位技术栈信号通过官网 HTML 或公开技术博客判断关键决策人线索CEO、CMO、销售负责人等。这一步的关键技术点是如何从非结构化网页中提取结构化信息。许多开源项目会采用“抓取正文 → 分块 → LLM 抽取”的方式。抽取结果通常用 JSON Schema 来约束例如{ company_name: string, website: string, industry: string, headcount_range: string, tech_stack: [string], recent_news: [string], decision_makers: [ { name: string, title: string, email: string } ] }不要试图用一个大 prompt 塞进去所有网页内容。更可靠的做法是先把网页正文提取出来再按段落或语义块交给 LLM 抽取。3.3 阶段三联系人发现与邮箱验证Contact Discovery Verification这是决定项目能否真正落地的一步。很多项目在“找公司”环节很棒但到了找联系人阶段就掉链子因为个人邮箱比企业公开邮箱更难获取。目前的常见验证策略是组合多种信号公开渠道中的邮箱企业邮箱命名规则如 firstname.lastnamedomain.com邮箱验证服务返回的 deliverability 状态社交媒体账号交叉确认。需要特别注意验证服务并不是 100% 准确且频繁验证会消耗 API 预算。更稳妥的做法是先过滤明显不合格的格式比如缺少域名、包含 spam 特征词再调用验证服务。3.4 阶段四个性化触达内容生成Personalized Outreach找到联系人之后Agent 需要生成一封“看起来不像模板”的邮件。这部分的典型实现方式是用一个 Prompt 模板把前面阶段收集到的公司信息、联系人角色、你的产品介绍都拼接进去让 LLM 生成 3 到 5 个不同版本再由人工挑选或 A/B 测试。但这里有一个容易被忽略的问题生成内容越多触达的一致性越难控制。建议在 Prompt 里明确“只写一段 80-120 字的引入语不要编造没有依据的客户数据”避免 LLM 一本正经地编造“贵公司年营收 3000 万”这类信息。3.5 阶段五发送与后续动作Send Follow-up发送环节通常不走 LLM而是用 SMTP 或第三方邮件 API 完成。一个合格的系统还应该包括发送频率限制避免触发垃圾邮件机制退订链接合规必需打开/回复事件的回调将已触达记录写入 CRM 或数据库。很多开源项目会把“发送”做成可插拔模块开发环境使用本地邮件调试工具生产环境切换到真实邮件服务。这是非常推荐的工程实践。3.6 架构图拆解用文字描述整体流程虽然正文不引入图表但你可以按下面的模块清单理解整体架构配置层ICP 画像、数据源开关、验证规则、发送策略 ↓ 调度层以公司为单位依次执行 发现 → 增强 → 验证 → 触达 ↓ 数据层数据库表companies / contacts / campaigns / events ↓ 集成层搜索 API、抓取模块、LLM 接口、验证服务、邮件服务、CRM调度层是整个 Agent 的核心。它决定了当前任务是串行还是并行、失败重试几次、哪些阶段可以由 LLM 动态决策哪些阶段必须走固定规则。4. 环境准备与前置条件如果只是想理解原理看完第 3 章就够了但如果想跑通一个最小示例建议按下面的环境准备。以下版本信息仅供参考请以你实际安装时的最新稳定版本为准。本文重点演示通用思路不锁定某个特定项目版本。4.1 操作系统与基础工具Linux / macOS 均可Windows 建议使用 WSL2 或 Docker 环境。Python 3.10 或更高版本。Git。Docker可选用于启动数据库或邮件调试服务。4.2 Python 依赖以通用实现为例至少需要以下依赖openai1.0.0 requests2.31.0 pydantic2.0.0 python-dotenv1.0.0 rich13.0.0你可以用以下命令创建虚拟环境并安装依赖python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install openai requests pydantic python-dotenv rich4.3 LLM 接口准备这类 Agent 需要调用大模型做判断和生成。你可以选择OpenAI 兼容接口本地部署的开源模型如通过 Ollama 或 vLLM 提供兼容服务。如果选择本地模型需要保证机器内存足够并在代码中把 base_url 指向本地服务。这样也可以避免外部接口不稳定带来的影响。4.4 数据存储最小 Demo 阶段不必上重型数据库使用 SQLite 即可。一个简单的表结构可以这样设计CREATE TABLE IF NOT EXISTS companies ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, website TEXT, industry TEXT, headcount_range TEXT, source TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE IF NOT EXISTS contacts ( id INTEGER PRIMARY KEY AUTOINCREMENT, company_id INTEGER, name TEXT, title TEXT, email TEXT, verified INTEGER DEFAULT 0, created_at TEXT DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE IF NOT EXISTS campaigns ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, contact_id INTEGER, status TEXT, message TEXT, sent_at TEXT, reply_at TEXT );4.5 合规前提在开始任何演示之前必须明确这一点B2B 潜客发现涉及企业联系人信息不同国家/地区对商业联系人数据的使用和触达有不同法律要求。请务必只使用公开的商业信息不采集个人敏感信息遵守目标网站的服务条款和 robots 协议控制请求频率避免影响对方网站稳定性设置退订链接遵守反垃圾邮件法规生产环境使用前咨询法务。这不是套话。很多开源项目只管“技术能跑”不会替你把合规问题也解决掉这是你自己要守住的红线。5. 完整示例一个最小可运行的潜客发现 Agent下面这个示例是“通用实现演示”目的是把第 3 章的理论流程落到代码上。它不代表任何具体开源项目的 API只是帮助你理解核心流程。5.1 项目目录规划prospect-agent/ ├── config.yaml ├── prospect_agent.py ├── requirements.txt ├── .env └── data/ └── prospects.db5.2 配置文件config.yamlconfig.yaml 是 Agent 的“大脑”里面定义了目标画像、数据源开关和运行参数# 文件路径prospect-agent/config.yaml icp: description: 找中国出海 DTC 品牌提供独立站建站与营销自动化服务的 SaaS 公司 region: cn industry_keywords: - 跨境电商 - 独立站 - DTC - 营销自动化 headcount_range: 50-500 signals: - 官网有 pricing 页面 - 有英语版页面 - 招聘信息中出现 Shopify 或 Stripe data_sources: search_api: enabled: true max_results_per_keyword: 10 business_directory: enabled: false verification: email_verify_api: enabled: false max_verified_per_run: 20 llm: model: gpt-4o-mini temperature: 0.2 database: path: data/prospects.db说明icp.description是给 LLM 看的目标画像描述industry_keywords和signals是给规则引擎用的硬性筛选信号verification.email_verify_api.enabled先关闭避免 Demo 阶段产生外部 API 费用llm.temperature设为 0.2让判断更稳定。5.3 核心代码prospect_agent.py下面代码是单文件最小实现把“发现—增强—验证—生成触达文案”串起来。# 文件路径prospect-agent/prospect_agent.py import json import os import sqlite3 import time from dataclasses import dataclass, asdict import requests import yaml from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI(api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL)) dataclass class Company: name: str website: str industry: str headcount_range: str signals: list decision_makers: list def load_config(path: str) - dict: with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def setup_db(db_path: str) - sqlite3.Connection: conn sqlite3.connect(db_path) conn.execute( CREATE TABLE IF NOT EXISTS companies ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, website TEXT, industry TEXT, headcount_range TEXT, source TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP ) ) conn.execute( CREATE TABLE IF NOT EXISTS contacts ( id INTEGER PRIMARY KEY AUTOINCREMENT, company_id INTEGER, name TEXT, title TEXT, email TEXT, verified INTEGER DEFAULT 0, created_at TEXT DEFAULT CURRENT_TIMESTAMP ) ) conn.commit() return conn def search_candidates(config: dict) - list: 模拟从公开数据源搜索候选公司。 在实际项目中这里会调用搜索 API、企业信息平台或行业目录。 为了演示这里返回几条伪造数据并标注来源。 return [ { name: 示例出海科技, website: https://example-saas.com, industry: SaaS, headcount_range: 100-200, signals: [官网有 pricing 页面, 招聘信息中出现 Shopify], }, { name: 远方营销云, website: https://example-marketing.cn, industry: MarTech, headcount_range: 50-100, signals: [有英语版页面, 招聘信息中出现 Stripe], }, ] def llm_judge_company(config: dict, raw: dict) - dict: 让 LLM 判断一家公司是否匹配目标画像并抽取关键字段。 icp config[icp] prompt f 判断下面的公司是否符合目标画像。 目标画像{icp[description]} 硬性行业关键词{icp[industry_keywords]} 额外信号{icp[signals]} 候选公司信息 {json.dumps(raw, ensure_asciiFalse)} 请返回 JSON格式如下 {{ match: true, reason: 简短理由, decision_makers: [ {{name: 张三, title: CEO, email: zhangsanexample.com}} ] }} resp client.chat.completions.create( modelconfig[llm][model], temperatureconfig[llm][temperature], messages[ {role: system, content: 你是一个严谨的 B2B 潜客筛选助手只返回 JSON。}, {role: user, content: prompt}, ], ) content resp.choices[0].message.content return json.loads(content) def save_company(conn: sqlite3.Connection, company: Company) - int: cur conn.execute( INSERT INTO companies (name, website, industry, headcount_range, source) VALUES (?, ?, ?, ?, ?), (company.name, company.website, company.industry, company.headcount_range, agent_demo), ) conn.commit() return cur.lastrowid def save_contact(conn: sqlite3.Connection, company_id: int, contact: dict) - None: conn.execute( INSERT INTO contacts (company_id, name, title, email, verified) VALUES (?, ?, ?, ?, 0), (company_id, contact[name], contact[title], contact[email]), ) conn.commit() def generate_outreach_message(config: dict, company: Company, contact: dict) - str: 基于公司信息生成一段个性化触达文案。 prompt f 你是一家营销 SaaS 公司的销售顾问。请写一段 80 字以内的英文邮件开场白。 目标是引起对方兴趣不要编造对方公司数据。 公司名称{company.name} 公司官网{company.website} 行业信号{company.signals} 联系人{contact[name]}职位{contact[title]} 邮件开场白 resp client.chat.completions.create( modelconfig[llm][model], temperature0.7, messages[{role: user, content: prompt}], ) return resp.choices[0].message.content.strip() def main(): config load_config(config.yaml) conn setup_db(config[database][path]) candidates search_candidates(config) for raw in candidates: result llm_judge_company(config, raw) if not result[match]: print(f跳过{raw[name]}原因{result.get(reason, 无)}) continue company Company( nameraw[name], websiteraw[website], industryraw[industry], headcount_rangeraw[headcount_range], signalsraw[signals], decision_makersresult.get(decision_makers, []), ) company_id save_company(conn, company) for dm in company.decision_makers: save_contact(conn, company_id, dm) message generate_outreach_message(config, company, dm) print(f已保存联系人{dm[name]} - {dm[email]}) print(触达文案, message) print(- * 60) # 演示节奏防止请求过快 time.sleep(1) conn.close() print(Demo 运行完成数据已写入 SQLite。) if __name__ __main__: main()代码要点说明search_candidates目前返回模拟数据真实项目请替换为搜索 API 或企业信息接口llm_judge_company让 LLM 输出匹配结果和决策人列表这是“AI 判断”的核心环节generate_outreach_message只生成文案不负责发送发送需要单独接邮件服务数据库字段与第 4.4 节的表结构一一对应便于你后续扩展字段。5.4 环境变量文件.env# 文件路径prospect-agent/.env OPENAI_API_KEYsk-xxxx OPENAI_BASE_URLhttps://api.openai.com/v1如果你使用本地模型可以把 OPENAI_BASE_URL 指向本地兼容服务。5.5 运行命令cd prospect-agent python prospect_agent.py如果你是第一次运行建议只保留search_candidates中 1 到 2 条候选数据先验证流程通不通再扩大数据源。6. 运行结果与效果验证运行 Demo 成功后你会看到类似下面的输出已保存联系人张三 - zhangsanexample.com 触达文案Hi Zhang, I noticed that your team is building cross-border e-commerce SaaS products... ------------------------------------------------------------ 已保存联系人李四 - lisiexample.com 触达文案Hi Li, your marketing cloud looks interesting, especially the Stripe integration... ------------------------------------------------------------ Demo 运行完成数据已写入 SQLite。验证是否成功的标准不能只看“有没有报错”。建议按以下顺序确认数据库表是否生成了记录sqlite3 data/prospects.db SELECT * FROM companies; sqlite3 data/prospects.db SELECT * FROM contacts;预期能看到companies表新增记录contacts表也有对应联系人记录。匹配判断是否合理查看llm_judge_company返回的match和reason确认 LLM 不是把所有公司都判为匹配。如果全部匹配或全部不匹配通常是目标画像描述太模糊或太苛刻。触达文案是否“看起来像人写的”如果文案里有明显的编造数字或者与公司信息无关说明 prompt 需要加限制。联系人邮箱格式Demo 阶段没接验证服务所以必须人工检查邮箱格式是否符合namedomain.com的规范。如果发现格式杂乱说明邮箱抽取逻辑还需要调整。如果运行失败最常见的两类原因是OPENAI_API_KEY 没有正确加载或者 LLM 返回的不是合法 JSON。前者检查.env文件路径和变量名后者在代码里增加异常处理或重试机制。7. 常见问题与排查思路问题现象可能原因排查方式解决方案运行时报ModuleNotFoundError: openai依赖未安装或虚拟环境未激活执行pip list查看已安装包激活虚拟环境后重新安装依赖LLM 返回内容无法解析为 JSONPrompt 约束不足或模型输出带多余文字打印content原始内容在 Prompt 中强调“只返回 JSON”增加重试和清洗逻辑所有候选公司都被判定为不匹配目标画像描述过严或行业关键词太窄检查config.yaml中的icp配置放宽规模范围或减少硬性关键词所有候选公司都被判定为匹配画像描述太模糊查看reason字段是否空泛补充明确信号如“官网有 pricing 页面”联系人邮箱格式混乱抽取 prompt 没有给出格式约束检查 LLM 返回的decision_makers在 JSON Schema 中强制规定字段格式并做正则过滤发送邮件进入垃圾箱发送内容模板化严重、发送频率过高检查邮件服务商投递报告提高个性化程度限制每日发送量配置 SPF/DKIM外部网站访问被拒绝请求频率过快或未遵守网站条款查看 HTTP 状态码和日志降低并发增加延时使用官方 API排查顺序建议先看命令行输出中的错误堆栈再看数据库是否写入记录最后检查 LLM 返回的原始内容。不要在不知道是哪一步失败的情况下盲目改 prompt。8. 最佳实践与工程建议8.1 先“规则过滤”再“LLM 判断”LLM 判断成本高、速度慢不适合对所有候选公司无差别执行。更合理的做法是先用规则引擎过滤掉明显不匹配的公司例如地点、员工规模、行业关键词再用 LLM 对剩余候选做深度判断最后再决定是否进入联系人发现环节。这样既能节省成本也能让判断结果更稳定。8.2 把“联系人验证”当独立服务不建议把邮箱验证逻辑直接写进 Agent 主流程。原因有三第三方验证 API 经常有配额限制需要做熔断验证服务响应时间不稳定串行等待会拖慢整体流程后续还需要重复验证同一域名下的多个邮箱独立模块更好复用。最佳实践是把联系人验证做成异步任务验证结果回调更新contacts表。8.3 所有外部调用都要可重试、可降级一个完整的潜客发现流程会依赖搜索接口、LLM、验证服务、邮件服务等多个外部系统。任何一个不稳定都会导致任务中断。建议为每个外部调用增加超时时间最大重试次数失败降级策略比如跳过该阶段并记录日志而不是中断整个任务。8.4 数据质量要“可审计”这类项目最容易出问题的地方是对 LLM 生成结果的过度信任。LLM 可能虚构不存在的联系人也可能把“可能匹配”写成“确定匹配”。因此数据库里应该增加两个字段source这条记录来自哪个数据源confidenceLLM 或规则引擎给出的置信度。这样做的好处是后续你可以复盘“哪些数据源质量高”“哪些 prompt 误判多”而不是把所有记录混在一起。8.5 触达频率必须人为限制开源项目默认参数往往比较“激进”因为它想演示出效果。但你接入真实业务时必须设置发送上限。建议每个域名每日最多发送 1 到 2 封每轮 Campaign 总量不超过 100 封必须有退订链接和人工审核机制。好的工具不是帮你发更多邮件而是帮你筛出更值得发的那批人。8.6 本地开发与生产环境分离本地开发时邮件发送建议使用本地邮件调试工具而不是真实发送。这样既不会打扰真实用户也能方便查看渲染效果。生产环境再切换到真实邮件服务并通过 webhook 将打开、回复、退订事件写入数据库。9. 总结与后续学习方向回到这一期 GitHub 快报想传达的核心信号开源 AI 代理正在从“聊天玩具”走向“垂直业务自动化”“无需自备列表的 B2B 潜客发现”就是其中一个典型方向。它的技术本质不是简单的爬虫加 ChatGPT而是一个把规则引擎、大模型判断、数据验证、自动化触达组合起来的 Agent 工作流。如果你要动手实践按照本文第五部分的代码跑通最小 Demo你会在 10 分钟内完成“发现一家候选公司 → LLM 判断 → 保存联系人 → 生成触达文案”的完整链路。之后的优化方向很清楚把模拟数据源换成真实的企业信息 API 或行业目录增加邮箱验证服务把 SQLite 换成 PostgreSQL接入 CRM 系统把已触达联系人同步过去为目标画像增加更多业务规则让 LLM 判断更精准。需要再次提醒的是技术只是水位合规是底线。不要采集个人敏感信息不要遵守不了 robots 协议还要硬抓不要一天给同一个域名发几十封邮件。先在小范围验证、再逐步放大才是这类项目最稳妥的落地方式。下一篇快报中我建议关注的方向是“开源 Agent 如何与 CRM 数据双向同步”因为潜客发现只是起点真正决定业务价值的是后续数据回流和跟进策略。你可以先把本文里的表格结构和数据库字段设计好到时候接入 CRM 会顺畅很多。