OpenOutreach：用一句话换一批带理由的 B2B 线索
Open-source AI agent for B2B lead generation — describe your product, it finds the people who fit, explains why each one does, and emails them from your mailbox. Self-hosted CLI, one install.
秒懂
- 它是什么？
- OpenOutreach 是一个自托管的命令行 AI 代理，输入产品描述和目标市场，它从授权数据商处找线索、按 ICP 逐个判定并给出入选理由，然后从你自己的邮箱发信。本文基于仓库文档分析其机制、用法与边界。
- 适合谁用？
- 适合以下人群：想摆脱上传名单和手动筛选、愿意把线索判定交给大模型、并且能接受 GPL-3.0 传染性约束的独立开发者或小团队。不适合：需要精细控制邮件措辞与发送节奏的成熟销售团队，以及那些线索数据必须来自自有 CRM 或内部数据库的组织。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 8 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的不是发信问题，而是名单问题
市面上多数外联工具要求你先有一份名单，OpenOutreach 反着来。文档明确说，输入是一句关于你产品的描述，输出不是数据行，而是对每个人的判定，附带入选理由的明文解释。这个定位把它和冷邮件序列器、线索数据库区分开。冷邮件工具优化的是送达率和回复率，线索数据库优化的是字段完整度，它优化的是从产品描述到合格联系人之间的那段推理。目标用户是那些没有现成名单、也不打算买名单的独立开发者和小团队。你纠正判定的方式不是改筛选条件，而是改产品描述本身。这个交互模型意味着，描述质量直接决定线索质量，文档没有给出描述写法的建议，这算一个隐性的上手门槛。
三个包一条管道，公开契约是 JSON Lines
OpenOutreach 本身不是单一程序，而是编排器。它把两个独立工具装进一个进程、一个数据库、一次引导流程。OpenOutFind 负责发现、判定、丰富和 CRM 功能，OpenOutSend 负责邮件发送和发送保护。两者之间的公开契约是一条管道：outfind find 50 --json 的输出可以直接喂给 outsend。文档特别强调，openoutreach run 在单进程内执行时，JSON Lines 仍然会跨越边界，只是改走内存缓冲。它刻意不做特权内存直传，理由是两条程序之间如果有第二条未经测试的路径，会让公开管道变成谎言。这个设计取舍值得肯定，它把组合性放在性能前面。对脚本或 AI 代理用户，文档建议直接使用两个子 CLI 和管道，而不是外层封装。
一条命令完成引导、查找与发送
安装方式是 uv tool install openoutreach，然后运行 openoutreach。首次运行会触发引导向导，收集产品描述和目标市场。命令动词分得很细：init 只做引导不花钱，find 只找线索并输出 CSV 到标准输出，文档明确标注这是免费的、不会消耗点数，send 只发送已存储的线索。带数字参数的 run 5 表示找到五个带地址的线索再发送，最多消耗五个点数。状态数据存放在 ~/.openoutreach，因此中断后重跑会从上次位置继续，目标是「比你已有的多 N 个」而不是「总共 N 个」。find 0 用于查看当前已有内容而不做任何新工作。这个命令设计把成本敏感操作和免费操作分开，用户可以在不花钱的情况下先看线索质量。
CSV 输出格式与部分成功语义
查找结果的交付物是一个 CSV 文件，列名固定为 email, first_name, last_name, company, title, website, linkedin_url, reason, lead_id, qualified_at。其中 reason 列是每个线索入选的说明，这是它区别于普通线索数据库的核心输出。文档强调，命令会一直运行到获得足够数量的带地址线索，然后把当前拥有的全部线索打印为 CSV 再退出。退出码 0 表示达到目标，未达目标时仍会打印已有行并说明停止原因。这种部分成功语义对自动化脚本很友好，调用方可以根据退出码决定是否重试，而不必解析输出内容判断成功与否。CSV 直接输出到标准输出，方便重定向给其他工具，不需要额外导出步骤。
零平台 ToS 表面与真实限制
文档宣称它没有浏览器、没有社交网络账号、没有爬虫，因此不存在账号被封的问题。线索来自授权数据提供商，每个带工作邮箱的线索消耗一个点数。这里有一个需要用户自行判断的边界：文档没有说明数据提供商是谁、覆盖哪些地区、邮箱验证的准确率是多少。另一个限制是，它只负责找到人和发出第一封邮件，不包含后续跟进序列。文档没有提及退订处理、邮件内容模板定制或 A/B 测试功能。对于需要多轮跟进的外联场景，它只能作为线索发现和首触工具，后续流程要交给别的系统。GPL-3.0 许可证意味着如果你修改代码并分发，必须开源修改版本，这对内部使用无影响，但如果你打算把它嵌入商业产品并提供服务，需要仔细评估。
Claude Code 插件与代理无关的契约
仓库附带一个 Claude Code 插件，安装命令是 /plugin marketplace add eracle/OpenOutreach 然后 /plugin install openoutreach@openoutreach。插件的技能文件 skills/find-leads/SKILL.md 教会 Claude 何时运行 find、哪些操作消耗点数、如何读取标准输出上的 CSV，以及每个 error: <type> 的含义。文档明确说，插件永远不会购买你没要求的地址，不会未经要求发送邮件，也不会替你接受法律声明。如果你不用 Claude Code，可以直接把 skills/find-leads/ 目录复制到 ~/.claude/skills/，或者让 Codex、Cursor 等其他代理读取同一个技能文件。这个技能文件本质上是 CLI 自身契约的 Markdown 描述，不包含 Claude 专属逻辑。这种设计让代理集成成本降到最低，任何能读 Markdown 的代理都能获得相同的操作规则。
维护成本与升级路径判断
仓库最后一次推送是 2026 年 9 月，没有检索到正式 release 记录。这意味着版本号、变更日志和语义化版本承诺都不可用，用户只能跟踪 main 分支。两个子项目 OpenOutFind 和 OpenOutSend 各自保留独立的控制台脚本、设置模块和测试套件，外层包只是添加了引导向导。这种结构的好处是，如果你只需要查找或只需要发送，可以直接用 uvx --from openoutfind outfind find 10 或 uvx --from openoutsend outsend send，不必安装完整包。但代价是，你同时依赖三个仓库的更新节奏。配置通过 OPENOUTFIND_* 和 OUTSEND_* 环境变量传递，子程序每次运行都重新读取、不记忆任何状态，这种无状态设计适合代理驱动，但排查问题时你需要自己追踪环境变量来源。
编辑结论
适合以下人群：想摆脱上传名单和手动筛选、愿意把线索判定交给大模型、并且能接受 GPL-3.0 传染性约束的独立开发者或小团队。不适合：需要精细控制邮件措辞与发送节奏的成熟销售团队，以及那些线索数据必须来自自有 CRM 或内部数据库的组织。采用前先验证三件事：第一，你所在司法辖区对未经请求的商业邮件有何规定，OpenOutreach 的文档没有提供合规指引；第二，你能否接受每次带工作邮箱的线索消耗一个点数，以及点数对应真实购买成本；第三，你的邮箱服务商是否容忍这种自动化外联。若这三项都过关，它可能是目前把「找谁」和「为何找他」压缩成一次 CLI 调用的最直接工具。
社区笔记