用途：把工作量、时效性、合规、吞吐与恢复需求转化为明确的 Firecrawl 架构选择，优先采用能满足目标的、最小的 Firecrawl 接口面。
主要能力：帮助在 scrape（同步单资源原语）、map（仅发现 URL 不取内容）、batch scrape（已知 URL 集合，异步任务、分页、Webhook、状态查询）、crawl（递归站点发现）、search（发现外部来源）、parse（处理本地文件字节）之间做选择；并决定轮询、WebSocket 流式或签名 Webhook 的异步交付方式，以及选择 Cloud 还是自托管。
使用方式：先盘点来源域名、授权依据、预期页面量、时效目标、输出格式、数据分类与恢复目标，再按场景选接口；在 Firecrawl 前放置策略网关处理域名授权、请求整形、预算、密钥选择与审计凭证；定义队列与爬取上限、保留/缓存策略、幂等键、分页归属与降级模式；用一个获批金丝雀验证所选方案，并记录失败、重试、取消与回滚路径。REST 请求使用 Authorization: Bearer，密钥 FIRECRAWL_API_KEY 应来自获批的密钥管理器，切勿打印、提交、传输或放入 URL。
适用场景：如设计夜间文档摄取，或要求所有流量留在自有基础设施内时评估自托管能力缺口。
限制：默认自托管 Compose 栈不提供全部 Cloud 能力，也不是生产安全设计；涉及选择自托管、引入新外部提供方、允许抓取需认证页面、启用仅 Cloud 能力或扩大域名与保留范围时，需先获批准。具体端点、SDK 方法、套餐限制、价格、保留选项与自托管版本应以官方 Firecrawl 文档为准，资料未提供相关细节。