Firecrawl 实时页面交互

它解决什么问题

常规抓取经常拿不到页面的完整内容，因为目标数据不在初始 HTML 里。它可能藏在点击按钮后才触发的异步请求中，可能在表单提交后的列表里，也可能在翻页或登录之后。这类页面 scrape 直接失败，并不是抓取逻辑不够强，而是根本没有可读的渲染状态。

firecrawl-interact 的思路是：先 scrape 拿到一个浏览器会话，再在真实会话里执行交互。开发者不必手写 Playwright 脚本处理元素定位、等待和重试，可以直接描述「要做什么」。

它的工作原理

流程固定为两个阶段：

• 先 scrape：用 firecrawl-scrape 抓取页面，得到一个 scrape ID。interact 必须基于这个 ID 工作，页面上下文来自那次抓取。
• 再 interact：把 scrape ID 传给 firecrawl interact，工具在浏览器里执行操作。交互方式有两种：--prompt 传自然语言指令，或 --code 传可执行代码，配合 --language 指定 bash / python / node。

覆盖的操作包括点击、表单填充、翻页导航和数据提取。需要维持登录态时，可以在 scrape 时加 --profile 持久化 cookie 与 localStorage，后续 interact 直接复用。scrape ID 会自动保存，连续多次调用不必每次手动指定。

资源管理上，交互会话占用浏览器实例，用完需执行 firecrawl interact stop 释放。并行场景可以先对多个页面分别 scrape，再用 --scrape-id 让各次 interact 互不干扰。

适用边界

几个容易踩的坑：

• 不要用它做搜索。interact 是浏览器操作，语义上不是检索工具；需要找页面时用 firecrawl-search。
• 它是兜底手段。工作流升级路径是 search → scrape → map → crawl → interact，前几种都拿不到数据时才轮到它。
• 它不是无界自动化。--timeout 默认 30 秒、上限 300 秒，过长的流程需要拆分。
• 会话状态有代价。profile 让登录态可复用，也意味着后续操作都带着这份状态，注意不同任务间是否需要隔离。