多引擎回退与智能抓取
多引擎回退与智能抓取
学习目标
- 理解 Firecrawl 如何通过多引擎竞争机制实现高抓取成功率
- 掌握引擎质量评分与 Feature Flag 的协同工作原理
- 了解反反爬策略的自动升级机制
前置知识
本章涉及多引擎回退与质量评分的通用原理，建议先阅读：
下文假设你已理解通用概念，直接聚焦 Firecrawl 的具体实现。
项目实践
引擎注册表
Firecrawl 在 engines/index.ts 中声明了一个固定的引擎列表，按质量排序：
| 引擎 | 质量分 | 触发条件 |
|---|---|---|
x-twitter | 1500 | 仅 X/Twitter URL |
index | 1000 | 缓存命中（始终优先尝试） |
wikipedia | 500 | Wikimedia URL |
fire-engine;chrome-cdp | 50 | 需要浏览器能力 |
fire-engine(retry);chrome-cdp | 45 | CDP 重试 |
playwright | 20 | 本地浏览器 |
fire-engine;tlsclient | 10 | TLS 指纹模拟 |
fetch | 5 | 静态 HTML |
pdf / document | -20 | PDF/DOCX 文件 |
关键设计决策：引擎可用性由环境变量控制。自托管实例如果没有配置 Fire Engine 服务，所有 Fire Engine 相关引擎都不会注册到列表中：
const useFireEngine = config.FIRE_ENGINE_BETA_URL !== "";const usePlaywright = config.PLAYWRIGHT_MICROSERVICE_URL !== "";这意味着自托管实例的引擎列表会大幅缩减 —— 只剩 Fetch、PDF、Document 三个基础引擎。这也是自托管模式下无法处理反爬站点的根本原因。
瀑布流竞争算法
Firecrawl 的核心创新是 scrapeURLLoop 中的瀑布流竞争算法。不同于传统的”依次尝试”模式，它使用并发竞争 + 延迟注入的混合策略：
时间线:t=0 ┃ Engine 1 (Chrome CDP) 启动t=3000 ┃ 超时延迟触发 → Engine 2 (TLS Client) 启动t=5000 ┃ Engine 2 先返回成功结果 → 胜出t=5000 ┃ Engine 1 被取消关键实现：
getEngineMaxReasonableTime(engine)：根据请求特征动态计算每个引擎的”合理等待时间”SCRAPEURL_ENGINE_WATERFALL_DELAY_MS：延迟注入常量，控制何时启动下一个引擎Promise.race([...enginePromises, timeoutSignal])：并发竞争核心
动态超时计算
每个引擎的超时时间不是固定值，而是根据请求的 Feature Flags 动态计算。例如，当请求包含 actions（页面交互）时，Chrome CDP 引擎会获得更长的等待时间；fastMode 则会缩短超时。
反反爬自动升级
当引擎返回 401/403/429 状态码且内容不足时，系统会自动检测是否为代理问题：
if statusCode in [401, 403, 429] && proxy === "auto" && !has("stealthProxy"): throw AddFeatureError(["stealthProxy"])这会触发 Feature Flag 动态调整，整个请求带着 stealthProxy 标志重新进入引擎选择流程，自动选择支持 stealth proxy 的引擎（如 fire-engine;chrome-cdp;stealth）。
问题与规避
1. 自托管实例引擎缺失
自托管实例默认没有 Fire Engine，导致可用的引擎只有 Fetch（纯 HTTP）。遇到任何需要 JS 渲染或反爬的站点都会失败。
规避：需要自行部署 Playwright 微服务，或配置 Fire Engine 兼容接口。
2. 引擎瀑布导致的成本累积
在瀑布流竞争中，如果前两个引擎都执行了部分工作（消耗了 Token 或代理请求）但都失败，最终成功的第三个引擎的成本加上前面引擎的浪费成本会被累加。
规避：SCRAPEURL_ENGINE_WATERFALL_DELAY_MS 的调优很关键 —— 延迟太短会浪费资源，太长会增加延迟。
3. Index 缓存命中的过期数据
Index 引擎质量分 1000，永远最先尝试。但如果缓存是旧的，用户可能拿到过期内容。
规避：请求可指定 maxAge 参数（毫秒），控制可接受的最大缓存时间。设置为 0 则跳过 Index 引擎。
设计取舍
为什么用质量评分而非 AI 选择？
Firecrawl 选择了声明式质量评分而非 AI 动态选择引擎。原因是：
- 可预测性：质量评分的引擎选择是确定性的，便于调试和监控
- 零延迟：AI 选择本身需要一个 LLM 调用，增加 500ms-2s 延迟
- 成本可控：AI 选择每次多消耗 Token
代价是引擎能力矩阵需要手动维护，新增引擎需要声明支持哪些 Feature Flags。
为什么用并发竞争而非顺序回退？
并发竞争的优势在于”先成功者胜出”—— 对于不确定的页面类型，多个引擎同时运行，最快的引擎自然胜出。相比顺序回退，减少了”第一个引擎尝试很久才失败”的等待时间。
代价是资源消耗更大 —— 可能有 2-3 个引擎同时运行，虽然只有 1 个的结果被采用。