网页爬虫后端AI 应用【免费下载链接】firecrawlThe web data API to search, scrape, and interact at scale. 项目地址https://gitcode.com/GitHub_Trending/fi/firecrawl点击查看免费下载面对把网页数据接进自己的产品这类需求很多开发者容易一上来就写抓取代码结果在端点选型上反复返工。Firecrawl 将绝大多数应用场景收敛为三种集成形态已知 URL 直接提取、以查询开头的发现式抓取、抓取之后的浏览器交互。本文以 firecrawl-build 技能库中的 integration-patterns.md 为骨架结合本仓库的请求样例、控制器源码与测试用例完整讲解三种模式的适用场景、端点选择依据、REST 请求写法与落地验证方式帮助你为任意产品场景选出最窄、最合适的集成路径。三种集成形态从输入形态决定集成骨架Firecrawl 的集成通常可以归纳为三种固定形状integration shape每种形状对应不同的起点输入与端点选择。判断的依据不是我想抓取网页而是产品功能从哪里开始手里已经握着 URL还是只有一个查询词还是需要先渲染页面再做操作。集成形态起点输入对应端点典型产品场景已知 URL → 提取内容已有完整 URL/scrape文档导入、竞品页面定价提取、内容灌入检索管线查询 → 发现 → 提取只有搜索查询/search带新鲜来源的答案生成、竞品发现、产出候选 URL 列表的研究流程抓取 → 交互 → 提取已抓取的页面 操作动作/interact点击展开区块、表单驱动的搜索结果、分页列表、登录态仪表盘三种形态之间存在清晰的优先级关系绝大多数集成从/scrape起步只有在发现本身是产品行为时才升级到/search只有页面必须被操作后才能取到数据时才升级到/interact。下面分别展开。形态一已知 URL → 提取内容/scrape当应用已经持有目标 URL时直接使用/scrape提取单页内容。原文档给出了三类典型场景文档导入从一个已保存的 URL 导入文档内容定价提取从竞品页面提取定价信息内容摄取把网页内容灌入检索/向量管线供后续 RAG 或搜索使用。这一形态的核心特征是单页、单 URL、确定性输入因此端点选择不需要任何发现逻辑。仓库中的真实请求样例 apps/api/requests/v2/scrape.requests.http 展示了/v2/scrape的常用载荷指定formats数组即可一次请求同时拿到多种产物例如[summary]直接返回摘要formats也支持对象形式配合 JSON Schema 做结构化提取POST {{baseUrl}}/v2/scrape HTTP/1.1 Authorization: Bearer {{$dotenv TEST_API_KEY}} content-type: application/json { url: https://docs.firecrawl.dev, formats: [{ type: json, schema: { type: object, properties: { name: { type: string } } } }] }同一请求文件里还能看到changeTracking格式modes: [git-diff]用于追踪页面变更以及parsers参数如pdf: false用于关闭特定文档类型的解析器。也就是说单次/scrape就能同时完成抓取、提取、结构化、变更追踪等子任务这正是最窄端点也能覆盖大部分需求的原因。需要提醒的是/v2/scrape只接受 POST。仓库测试 apps/api/src/tests/routes/not-found.routes.test.ts 明确断言了对/v2/scrape发起 GET 会返回GET /v2/scrape is not supported. Use POST instead.的错误提示集成时请勿套用常见 REST 习惯改用 GET。形态二查询 → 发现 → 提取/search当产品功能以搜索查询为起点、尚未持有 URL时应使用/search完成发现这一步。原文档强调只有在产品确实需要完整正文内容时才针对搜索结果中的页面追加/scrape如果产品只需要来源列表、标题或摘要/search一次调用即可交付。典型场景包括答案生成用最新来源支撑答案搜索负责发现、必要时抓取正文竞品发现以品类关键词发现竞争者页面研究流程产出候选 URL 短清单shortlist供用户筛选后再决定是否抓取。仓库请求样例 apps/api/requests/v2/search.requests.http 展示了/v2/search的两种sources写法。简单场景用字符串数组同时覆盖多类来源POST {{baseUrl}}/v2/search HTTP/1.1 Authorization: Bearer {{$dotenv TEST_API_KEY}} content-type: application/json { query: firecrawl, sources: [web, images, news], limit: 5 }需要按来源单独定制参数时可改用对象数组形式每个元素用{type: web}这类结构声明来源类型。设计上query与limit是控制发现规模的核心参数limit决定候选清单长度进而在抓多少与成本多少之间取得平衡。形态三抓取 → 交互 → 提取/interact/interact只在页面被抓取之后还必须被操作时使用它不是/scrape的替代品而是其后续动作的延续。原文档列出的典型场景都是静态抓取拿不到数据的页面类型点击展开区块内容折叠在按钮或手风琴组件之后表单驱动的搜索结果结果依赖提交搜索表单分页列表需要逐页翻页才能聚合完整数据登录态仪表盘需要先登录或保持会话才能访问数据。仓库中的实现证据集中在 apps/api/src/controllers/v2/scrape-browser.tsscrapeInteractController注册于/v2/scrape/:jobId/interact见测试 apps/api/src/tests/routes/interact-agent-concurrency.routes.test.ts即交互动作绑定在某个已完成抓取的 scrape job 之上。其请求校验模式browserExecuteRequestSchema第 5776 行透露了交互载荷的关键约束code与prompt二选一交互可以通过浏览器自动化代码驱动也可以通过自然语言提示驱动但不能同时缺失language枚举python/node/bash默认node支持多语言编写交互脚本timeout1300 秒默认 30 秒用于限制交互执行时长existingSessionId可复用已有浏览器会话典型场景就是登录态仪表板——首次登录建立会话后续抓取复用同一会话免去重复认证。交互底层的浏览器会话能力可参考 apps/api/requests/v2/browser.requests.http先POST /v2/browser创建会话支持ttl、activityTtl、streamWebView等选项再通过/v2/browser/:sessionId/execute执行代码例如POST {{baseUrl}}/v2/browser/{{sessionId}}/execute HTTP/1.1 Authorization: Bearer {{$dotenv TEST_API_KEY}} content-type: application/json { code: await page.goto(\https://example.com\)\nprint(await page.title()), language: python }把这条链路放进产品集成中点击展开翻页填表单都可编码为一次或多次交互步骤且每个步骤都产出可继续提取的页面状态。端点选择先问Firecrawl 在产品里做什么原文档所属技能库在 endpoint-selection.md 中给出了统一的选型方法在选端点之前先问一个核心问题——Firecrawl 应该在产品里做什么然后选择与该功能匹配的最窄端点端点什么时候用什么时候不该从这里开始/scrape已持有 URL只需要一个页面功能以查询为起点/search功能以查询为起点需要发现来源目标 URL 已知/interact页面被抓取后还需要点击、输入或导航纯/scrape已经能拿到数据技能库给出的默认优先级是/scrape→/search→/interact并配套两条升级规则先试/scrape再考虑/interact只有静态抓取不足时才引入交互成本当 URL 发现本身就是产品行为时才从/search开始。这套最窄端点优先的策略同时控制了延迟与成本交互与搜索的代价都高于单页抓取能用简单端点解决的场景不应动用重型能力。三个端点之外的专属索引在/scrape、/search、/interact之外Firecrawl 还维护两个独立索引且二者都不会被/search查询研究论文索引research paper index当查询目标是已发表的研究论文——生物医学、临床、生命科学文献PubMed、bioRxiv、medRxiv或 arXiv 预印本——而非普通网页时使用。通过 MCP 的firecrawl_research_*工具或 CLI 的firecrawl research subcommand访问开发者索引developer index当答案存在于 issue、已合并的 pull request、README 或文档页中代码行为、API 契约、错误字符串、已知 bug时使用。通过GET/POST /v2/search/developer、MCP 的firecrawl_developer_search或 CLI 的firecrawl developer访问。这里有一个容易混淆的细节/search上的categories: [research]和categories: [developer]只是网站过滤器。它们把一次普通网页搜索限定到一组域名清单研究类包含 PubMed、bioRxiv、medRxiv、arXiv 及出版商站点返回的仍是网页结果背后没有摘要检索、相关论文扩展或全文片段检索能力。只有当功能想要的就是一次网页搜索且这些来源应该在同一个调用里被加权时才选择这两个 categories 选项。从形态到落地技能库定义的默认集成顺序确定形态与端点后SKILL.md 给出了可复用的默认集成顺序值得作为工程 checklist先把FIRECRAWL_API_KEY云服务或FIRECRAWL_API_URL自托管环境配置正确详见 auth-and-env.md判断这是全新项目还是既有代码库确认产品需要什么网页数据行为据此选择匹配的端点对既有项目先检查仓库结构、匹配其工程约定再动手写集成代码为目标技术栈安装 SDK或直接调用 REST 接口安装方式见 sdk-installation.md编写集成代码前先阅读对应语言Node/TypeScript、Python、Rust、Java、Elixir、cURL/REST的官方 source-of-truth 页面以官方请求/响应 schema、参数与端点行为为准把端点专属的实现细节留在更窄的技能文件中主集成代码保持端点无关跑一个冒烟测试smoke test证明一次真实的 Firecrawl 请求能成功返回。其中第 1 步的环境变量是硬前提FIRECRAWL_API_KEY为必填FIRECRAWL_API_URL仅在自托管部署而非托管api.firecrawl.dev时设置。第 24 步强调先读仓库再写代码这与 firecrawl-build 技能库中既有项目应先检查仓库、匹配约定的强制 intake 要求一致完整清单见 project-intake.md。与 CLI 的边界和验证firecrawl-build 技能用于把 web 数据能力集成进应用代码与一次性终端任务有明确边界会话内的临时网页调研、即时搜索、抓取某个页面应使用 CLI 技能而不是集成代码。二者可通过同一命令安装npx -y firecrawl-clilatest init --all --browser安装后两类能力并存build 类技能负责应用集成CLI 负责当前会话的一次性网页工作。最后无论采用哪种形态验证环节都不能省。技能库要求跑一个冒烟测试证明一次真实的 Firecrawl 请求成功具体检查项可参考 verification.md。一个实用的验证策略是先用一个你已知的 URL 跑通/scrape拿到结构化输出再按产品实际起点跑/search或/interact链路逐步把端到端流程钉死——这也恰好对应本文三条集成形态的优先级次序从最窄的端点开始验证通过后再向更重的能力升级。赞分享网页爬虫后端AI 应用【免费下载链接】firecrawlThe web data API to search, scrape, and interact at scale. 项目地址https://gitcode.com/GitHub_Trending/fi/firecrawl点击查看免费下载相关推荐openEuler OBS未来路线图构建系统演进与技术创新展望openEuler OBS未来路线图构建系统演进与技术创新展望 前往项目官网免费下载 https://ar.openeuler.org/ar/ https:网页爬虫后端AI 应用GitHub Copilot CLI 实战GitHub.com 集成、模型选择与端到端 Python 开发工作流GitHub Copilot CLI 实战GitHub.com 集成、模型选择与端到端 Python 开发工作流 本文是 Mastering GitHub C教程文档人工智能Perplexity MCP Server四大核心工具详解搜索、问答、研究、推理全方位解析Perplexity MCP Server四大核心工具详解搜索、问答、研究、推理全方位解析 Perplexity MCP Server是一个强大的AI助手扩展AI 应用MCP 服务人工智能后端上一篇Floci API Gateway VTL模板RCEExploitarium无代码执行面PoC实战下一篇AndroidLibs资源链接所有分类的GitHub仓库直达链接创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考