fire-enrich
firecrawl/fire-enrich加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图1：Fire Enrich 运行效果演示（来源：项目 README）
想象一个销售团队负责人面对的局面：Excel 里躺着一万条企业邮箱，有的来自展会签到表，有的来自 LinkedIn 导出，还有的来自客户主动注册。每条记录只有一个孤零零的邮件地址，背后的公司叫什么、融了几轮、用什么技术栈、 CEO 是谁——一无所知。
传统解法是花钱买商业数据库（Clearbit、Hunter、Apollo），按查询条数付费，量大了成本惊人。还有一种是人肉 Google 搜索，一条一条查，一个销售一周也填不满 500 行。
Fire Enrich 就是来解决这个问题的：输入一堆邮箱，输出一个完整的公司画像数据集。 只需三步——上传 CSV、选择要补充的字段、点击开始——剩下的全交给 AI 和 Firecrawl 完成。
Fire Enrich 由 Mendable AI（Firecrawl 背后的公司）开发和维护，GitHub 已有 1198 颗星。作为 Firecrawl 生态的重要组成，它的使命是让 AI 数据采集能力下沉到非技术用户的日常工作中。
作者之一 Eric Ciarla 是 Firecrawl 的联合创始人兼 CEO，项目与 Firecrawl 深度绑定——通过 Firecrawl API 完成所有网页抓取和数据聚合，再由 OpenAI GPT 模型完成信息提取和综合判断。整个链路完全依赖云端 API，无本地推理需求。
项目采用 Next.js 15 全栈架构，TypeScript 开发，UI 组件库选用了 Radix UI + Tailwind CSS，开箱即支持浅色/深色主题切换，界面现代感强。
这是 Fire Enrich 最值得深入了解的部分——它的数据 enrichment 不是一条简单的爬虫链路，而是精心设计的多 Agent 协作架构。整体分为五个阶段，每个阶段由专门的 AI Agent 负责：
从邮箱地址中提取域名，判断是否为企业邮箱（如区分 gmail.com 和 firecrawl.dev）。企业邮箱进入 enrichment 流程，gmail/outlook 等个人邮箱直接跳过或标记为个人联系人。发现 Agent 的核心职责是找到公司名称和官网地址，这是后续所有 Agent 的基础。
在已知公司名称的基础上，搜索行业分类、总部所在地、成立年份、企业性质（上市公司/私营/子公司）。搜索策略优先访问公司官网的 About 页面，其次搜索 "{公司名} headquarters founded" 等标准查询模式。
搜索公司最新融资轮次、融资金额、投资方、估值。数据来源包括 TechCrunch、Crunchbase、VC 新闻等。与公司档案 Agent 不同，融资 Agent 还需要识别被收购和 IPO 等特殊状态。
这个 Agent 最有技术含量。它通过三种方式推断公司技术栈：
site:github.com "{公司名}" 找到公司的开源仓库，分析其中的 package.json、requirements.txt 等依赖文件处理前四个 Agent 没有覆盖到的自定义字段，如「CEO 姓名」「产品特色」「社交媒体账号」等。它拥有前面所有阶段的上下文数据，可以进行更精准的交叉推理。
每个 Agent 的输出都带有置信度分数和来源 URL，五个 Agent 的结果汇入 GPT-4o 进行最终综合——解决数据冲突、验证一致性、输出格式统一的结果。
从代码层面深入分析，Fire Enrich 的技术架构有以下几个亮点：
项目同时使用了 两套 Agent 框架：
@openai/agents）：Discovery Agent、Company Profile Agent、Funding Agent 采用这套框架，每个 Agent 定义自己的 instruction、tools 和 output schema（Zod），输出天然类型安全z.zod() schema 和 OpenAI Chat Completion 接口两套框架混用的原因是 Tech Stack Agent 需要更细粒度地控制搜索结果解析逻辑，而 OpenAI Agents SDK 的高阶接口不够灵活。
AgentOrchestrator 是整个 enrichment 管线的大脑（91KB 的单文件），负责：
FirecrawlService 封装了 @mendable/firecrawl-js，提供了三个核心工具函数：
search(query)：执行语义搜索，返回相关网页列表scrape(url)：抓取指定 URL 的完整内容（支持 markdown 格式）extract(url, fields)：使用 AI 从页面中提取结构化数据每个 Agent 内部都直接调用这三个函数，实现了搜索 → 抓取 → 提取的标准 RAG 流程。
数据输入输出流程如下：
CSV 上传 (email 列)
↓
API Route: /api/enrich (POST)
↓
CSV Parser + Field Mapper
↓
逐行调用 AgentOrchestrator.enrichRow()
↓
并行执行 Discovery/Profile/Funding/TechStack Agent
↓
GPT-4o 综合 + 格式统一
↓
EnrichmentResult[] 返回前端
↓
前端渲染为可下载 CSV / 详情 Modal
API 层使用 Next.js App Router 的 Route Handler（app/api/enrich/route.ts），支持实时进度推送（Server-Sent Events 或轮询）。
Fire Enrich 没有任何容器化配置（无 Dockerfile、无 docker-compose），这既是缺点也是特点——它本质上是一个 Next.js 应用，开发者通过 npm run dev 本地运行即可。
部署前置条件（必须）：
本地部署步骤（5 分钟）：
git clone https://github.com/firecrawl/fire-enrich.git
cd fire-enrich
cp .env.example .env.local
# 编辑 .env.local 填入两个 API Key
npm install
npm run dev
# 打开 http://localhost:3000
Vercel 一键部署： 项目 README 内置了 Vercel 部署按钮，自动配置环境变量拉起应用，对非技术用户最友好。
硬件需求极低： 纯前端 + 云端 API 调用，不需要 GPU，不需要大内存，2GB 磁盘空间即可。开发笔记本就能跑。
主要限制：
Fire Enrich 不是一个完美的工具，以下几个问题值得关注：
每个字段 enrichment 都触发一次 Firecrawl 搜索 + 一次 OpenAI LLM 调用。如果用户选择了 8 个字段、CSV 有 1000 行，理论上会产生 8000 次 API 调用（实际有缓存优化，但量级仍然可观）。商业化使用前需要仔细测算 OpenAI 和 Firecrawl 的账单。
对于没有官网、没有 GitHub 仓库、没有新闻报道的小公司，enrichment 结果可能只有公司名称，其他字段为空。置信度分数可以提示用户哪些数据是可信的，但无法解决信息不存在的问题。
项目要求上传包含邮箱地址的 CSV 文件——这意味着用户的客户联系数据会上传到 Fire Enrich 的服务器（无论是本地部署还是 Vercel 托管）。对于金融、医疗等强监管行业，这可能触发合规问题。README 中未提及数据存储策略。
Fire Enrich 代表了一个趋势：将 AI 能力封装为非技术用户可直接使用的业务工具。传统的数据 enrichment 工具（如 Clearbit）依赖结构化数据库查询，而 Fire Enrich 走的是 RAG 路线——让 LLM 实时从网页中提取信息，不受固定数据库覆盖面的限制。
从增长曲线看，Firecrawl 生态正在快速扩张：Firecrawl 本身负责网页采集，Fire Enrich 负责数据 enrichment，两者形成采集 → 结构化 → 消费的数据管线。随着 Firecrawl 生态的工具链完善，可能会出现更多垂直场景的数据 enrichment 插件。
对于 AI 开发者而言，Fire Enrich 的多 Agent 协作架构（Discovery → Profile → Funding → TechStack → General）是一个很好的参考设计——分而治之、链式上下文、置信度汇总，这些模式可以复用到任何需要多步骤信息聚合的场景。
技术栈汇总： TypeScript · Next.js 15 · React 19 · OpenAI Agents SDK · LangChain · Firecrawl API · Radix UI · Tailwind CSS · Framer Motion · Zod · OpenAI GPT-4o
适合场景： 销售线索 enrichment · B2B 市场调研 · 投资尽职调查 · 技术栈竞品分析
不适合场景： 大规模批量处理（1000+ 行）· 离线环境 · 无官网的小公司 enrichment · 强数据合规要求场景