模型知道很多事，卻不代表它知道競爭對手上星期改了什麼價格，也不代表它能讀取需要 JavaScript、登入或翻頁的網站。Firecrawl 在 5 月 18 日發布的 Firecrawl 101，把這個問題稱為 Agent 的 web context 缺口。他們給的答案不是一個更強的爬蟲，而是一組定位為「web 的 context API」的六個端點：Search、Scrape、Parse、Crawl、Map 與 Interact。六者可以獨立使用，也可以串接；有意思的是，文章明說多數 production workflow 只會組合其中二到三個——這句話本身就是選型建議。
缺口來自靜態快照與即時網路的落差
問題的根源不在模型能力，而在訓練資料的形態。AI 模型學的是網際網路的靜態快照：它不知道上週的變更、讀不了沒見過的頁面，更不能填表單或登入。一般的 SERP API 解決不了這件事——它回傳的是連結清單，Agent 還是得自己逐頁抓取、自己處理 JavaScript 渲染。Firecrawl 的切入點是把「取得可餵給 LLM 的網頁內容」整段服務化：渲染、清理、結構化都在 API 內完成，輸出直接是模型可推理、可引用的格式。
Search 與 Scrape：最常見的兩步，一次呼叫完成
/search 與一般搜尋 API 的差別在一個設計決策：同一次呼叫回傳的不是只有 URL，而是連同清理後的完整頁面內容（例如 Markdown）。搜尋與抓取之間的接線工作直接消失，這對 research 類任務是明顯的省工。
/scrape 處理已知 URL 的那一半。它接受單一網址，可回傳 clean Markdown、以 prompt 抽取的 structured JSON、screenshot，或任意組合。文件裡的範例很能說明用途：對定價頁下一個「抽出所有方案名稱與月費」的 prompt，拿回來的就是 {name: "Starter", price: "$19/mo"} 這種可直接入庫的結構。JavaScript rendering 也由服務自動處理，目標網站用什麼 tech stack 不再是使用者的問題。
Crawl、Map 與 Parse：整站廣度與非 HTML 文件
當任務從單頁放大到整個網站，/crawl 沿著連結走遍全站、回傳每一頁的內容，適合建立知識庫或需要完整 coverage 的場景。/map 是它的輕量版：只探索全部 URL、不抓內容，適合在投入完整 crawl 之前先理解站點結構、估算範圍。兩者搭配使用，成本控制權在自己手上。
/parse 面向另一種髒資料：PDF 與 Word 文件。多欄版面、句中 footnotes、掃描頁面是 LLM 讀文件最常見的殺手；Firecrawl 把這些文件轉成與 Scrape 相同的輸出——clean Markdown 或 structured JSON——讓文件內容與網頁內容在同一條管線裡被同樣對待。
Interact：需要動作才會出現的資料
有些資料不是讀出來的，是操作出來的：Load more 按鈕後面的商品、搜尋框過濾後的結果、多步表單走完才出現的資訊。/interact 維持一個 live browser session，讓 Agent click、type、scroll，取得動作之後才存在的資料。
操作方式有兩層。多數任務用自然語言就夠：CLI 裡一句 firecrawl interact "Click the Load more button..." 即可；需要細粒度控制時再換 SDK。Session 也可以從 Scrape 重用：先用 result.metadata.scrape_id 拿到 session，之後 app.interact(scrape_id, prompt=...) 串接任意次數的互動，用完呼叫 stop_interaction 收尾。唯一的硬限制是 session 最長 10 分鐘——對多數讀取型任務夠用，但把長流程塞進單一 session 是錯誤的設計方向。
這也是六個端點裡最需要安全設計的一個。輸入憑證、提交表單或執行可能改變外部狀態的操作，都應該有權限邊界與人類確認；不能只因為技術上可以點擊，就把所有動作全部自動化。
兩個可直接套用的 production 模式
文章給的兩個模式幾乎可以照抄。第一個是 research agent：用 /search 找來源、/scrape 抓回前幾筆的全文 Markdown、再交給 LLM 綜合，適合 competitive monitoring 與 market research。第二個是 enrichment pipeline：拿一份公司 URL 清單，用 batch_scrape 搭配 json prompt 抽出公司名稱、成立年份等欄位，直接寫進 CRM——每個網站零客製程式碼，這是它最吸引人的性質。兩者的分工也反映了取捨：research 每次任務重新抓，即時性優先；enrichment 一次清單跑完就入庫，批次經濟性優先。
從最小組合開始
入門成本設計得很低：firecrawl.dev 註冊就有 1,000 個 free credits，pip install firecrawl-py 或 npm install -g firecrawl-cli 都能開始；npx -y firecrawl-cli@latest init --all --browser 還能把 CLI 註冊成 agent skill。如果你已經在 Claude、Cursor 或 Windsurf 裡工作，Firecrawl 也提供 MCP server，把 Search、Scrape、Crawl、Map 直接掛進 host，remote URL 是 https://mcp.firecrawl.dev/{FIRECRAWL_API_KEY}/v2/mcp。
但選型原則比安裝指令重要：從任務的最小端點組合開始。價格監控可能只需要 Search 加 Scrape；文件問答是 Map 加 Crawl 加 Parse；真正需要登入或互動時才動用 Interact。上線前也值得先量三個數：來源抓取成功率、資料新鮮度、以及每次任務平均消耗的頁面數。Web context 的價值不是抓得愈多愈好，而是以可預測的成本，把夠乾淨、夠新的證據交給 Agent。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。