摘要： Firecrawl 於 5 月 18 日說明 AI agent 的 web context 缺口，並提出 Search、Scrape、Parse、Crawl、Map、Interact 六個端點。文章指出 production workflow 多數只會組合其中二到三個，應從任務所需最小組合起步；Interact 的瀏覽器 session 最長 10 分鐘，且需要權限邊界。
一個模型再博學，也說不出競爭對手把價格改成多少是上星期的事，更打不開那些非得跑 JavaScript、先登入、或是不斷翻頁才讀得完的網站。5 月 18 日，Firecrawl 在 Firecrawl 101 這篇貼文裡替這個狀況取了名字：Agent 的 web context 缺口。面對它，他們沒有交出更強的爬蟲，而是端出六個端點，合起來構成所謂的「web 的 context API」：Search、Scrape、Parse、Crawl、Map 和 Interact。六個端點可以各做各的，也能接成一條流程；更值得留意的是，原文直接挑明，production workflow 在實務上多數只會組合其中二到三個——光這一句，本身就是選型建議。
病根在訓練資料：快照凍在過去，網路卻一直往前走
真要追究起因，看的不是模型本領高低，而是它學習時吃下什麼形態的資料。模型認識的網際網路，是某個時間點凍結下來的靜態快照：上週發生什麼它無從知曉，沒見過的頁面它打不開，填表單、登入這類操作更是完全碰不到邊。一般的 SERP API 幫不上忙——丟回來的只有一排連結，抓取每個頁面、搞定 JavaScript 渲染這些活兒照樣落在 Agent 自己肩上。Firecrawl 的切入角度，是乾脆把「取得可餵給 LLM 的網頁內容」整件事包成一種服務：渲染、清理、結構化全部收進 API 裡做掉，輸出的格式模型拿來推理、拿來引用都順手。
先搜後抓，一次搞定：Search 與 Scrape
/search 有別於一般搜尋 API 的關鍵，是一個設計決策：同一通呼叫不只交回 URL，還把每頁清理過的完整內容（例如 Markdown）一併附上。原本夾在搜尋和抓取之間的接線工作就這麼憑空消失，research 類任務省下的工夫相當可觀。
/scrape 接手另外一半：URL 早已在手的情境。它吃單一網址，能回 clean Markdown、screenshot、用 prompt 抽出來的 structured JSON，幾樣同樣能任意搭。官方文件那組範例最能點出用途：對定價頁丟一句「抽出所有方案名稱與月費」這樣的 prompt，拿到的便是 {name: "Starter", price: "$19/mo"} 這類可直接寫入資料庫的結構。服務本身也會自動處理 JavaScript rendering，目標網站採用什麼 tech stack，已經輪不到使用者煩惱。
要掃全站、要讀非 HTML 文件：Crawl、Map 與 Parse 各司其職
任務範圍從單頁擴大到整個網站時，就交給 /crawl：它順著連結把全站走完，每一頁的內容都帶回來，建知識庫或任何講究完整 coverage 的場景都指望它。/map 則是同一件事的輕量版：只把全部 URL 探過一輪、內容一概不抓，適合在真正投入完整 crawl 之前，先摸清站點結構、抓出範圍估算。兩個搭配著用，成本這條線就握在自己手裡。
/parse 接手的是 PDF 與 Word 文件這一類麻煩資料。多欄版面、插在句子中間的 footnotes、掃描出來的頁面，向來是 LLM 讀文件時的頭號殺手。Firecrawl 的處理方式，是將這些文件轉換成跟 Scrape 相同的輸出，也就是 clean Markdown 或 structured JSON，文件內容從此與網頁內容走同一條管線、受到同等待遇。
Interact：得先操作才拿得到的資料
有一批資料天生不是讀出來的，而是操作出來的：搜尋框過濾後的結果、Load more 按鈕後頭的商品、多步表單全部走完才肯露面的資訊。/interact 會開著一個 live browser session，Agent 在裡頭 type、click、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，npm install -g firecrawl-cli 或 pip install firecrawl-py 擇一即可動工；想再進一步，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。