摘要： 2026 年，替 AI agent 接上 web search 與 deep research 早已脫離實驗階段，成為實際運轉的生產級基礎設施。Firecrawl 部落格 4 月刊出的分析把這波轉變說得很直接：新的 API、逐步標準化的協定（MCP 是代表），加上 OpenAI、Google 等公司端出的成熟產品，讓這兩項能力在這一年迅速落地。對產品開發者來說，眼前的抉擇早已不是「要不要加 web search」；真正要回答的是「怎麼最快整合進來」。
2026 年，替 AI agent 接上 web search 與 deep research 早已脫離實驗階段，成為實際運轉的生產級基礎設施。Firecrawl 部落格 4 月刊出的分析把這波轉變說得很直接：新的 API、逐步標準化的協定（MCP 是代表），加上 OpenAI、Google 等公司端出的成熟產品，讓這兩項能力在這一年迅速落地。對產品開發者來說，眼前的抉擇早已不是「要不要加 web search」；真正要回答的是「怎麼最快整合進來」。
兩個常被混用的名詞：Web Search 與 Deep Research 的分界
Firecrawl 在文中把這兩個詞劃出清楚的界線。Agentic web search 處理的是單一任務：agent 為了同一個目標發出多次查詢，逐一檢視回傳結果，再決定是否重新搜尋。像「GPT-5.4 透過 OpenAI API 的目前定價是多少？」這類問題，只要核對少數幾個來源就能確認。
Deep research 面對的則是另一個量級：一道複雜查詢可能得讀完數百個網頁。以「比較 2025 和 2026 年所有主要 AI code editor，包含定價、支援語言、用戶評價和 benchmark 結果」為例，網路上沒有任何單一頁面能直接給出答案，agent 必須不斷搜尋、閱讀、交叉比對，直到覆蓋面足夠，或預算耗盡為止。
文中引述一篇 arXiv 論文，把搜尋的演進切成四個階段：關鍵字比對、LLM 只靠訓練資料作答、RAG 帶進檢索，以及 agentic deep research 的搜尋-推理迴圈。真正的分水嶺在第四階段：agent 不再是搜尋一次、推理一次的單趟流程，而是搜尋完、讀完、修正自身理解之後，帶著更好的問題再搜一輪。
為什麼轉折發生在 2026 年
按照 Firecrawl 的說法，兩年前想讓 agent 連上網路，多半還是個 side project：自己刻一個 scraper，然後默默期望頁面版型永遠別改。如今專用 API 與標準協定都已就位，甚至有整間公司完全圍繞這個模式在營運。
這波轉變背後有幾個關鍵事件：2025 年 8 月，微軟關閉 Bing Search API，開發者被迫改投獨立搜尋供應商；MCP 從草案一路走到被廣泛採用，agent 接上外部工具簡化成寫一行設定。產品面上，Perplexity Comet、Browser Company Dia 與 OpenAI 的 GPT Atlas 在幾個月內接連問世，ChatGPT Agent Mode 也在 2025 年 7 月上線。
市場數字同樣呼應這條成長曲線：全球 AI agent 市場規模在 2025 年達到 78.4 億美元，預估 2030 年將成長至 526.2 億美元；Gartner 推估，到 2026 年底會有 40% 的企業應用內建特定任務的 AI agent，高於 2025 年的 5%。Cloudflare 的 CEO 更預言，agent 產生的網路流量將在 2027 年超越人類流量。
三種已經跑通的模式：知識庫、研究工具與排程任務
Firecrawl 在文中點名了幾個把自家服務放進正式環境的團隊，這些案例大致可以整理成三種成熟模式。
第一類是 AI 知識庫與助理。Retell AI 過去得為每個客戶人工維護 Puppeteer scraper；改用 Firecrawl 之後，客戶只需交出一串 URL，便能取得自動同步、LLM-ready 的知識庫。Botpress 的 CTO Michael Masson 表示，Firecrawl 開箱即用，就能智慧擷取相關資料。Credal 則讓企業 agent 每月處理超過 600 萬個 URL，支撐即時 context pipeline 與長期知識庫。
第二類是研究與探索型工具。SciSpace 收錄了 2.8 億篇研究論文，其 Deep Review 功能會執行多步驟的文獻回顧——換成人類研究員得耗上數天。you.com 讓搜尋-抓取迴圈持續運轉、刻意不設終點，因為只要一停下來，答案就跟著過時。
第三類是排程與重複性任務：競爭情報（定期盯著競品定價與產品發布）、潛在客戶 enrichment（爬取公司網站把 CRM 資料補齊），以及法規監控（緊追政府與產業網站的更新）。這類任務不靠有人提問才啟動，而是照表操課。Firecrawl 的 web monitoring endpoint 在偵測到頁面出現實質變化時會送出 signed webhook，agent 於是可以略過那些沒有變動的頁面。
把它接進 Agentic Stack：共通的三層架構
Firecrawl 觀察到，大多數 agentic search 系統其實共享同一套三層架構，而且每一層的元件都已經存在。文章本身沒有把架構完整攤開，但順著脈絡可以整理成：
- 搜尋層：查詢在這一層發生——可能是 web search API，也可能是 deep research 引擎，由它決定搜尋什麼、何時搜尋。
- 擷取層：把搜尋結果轉成 LLM 讀得懂的格式，例如 HTML-to-Markdown；Firecrawl 這類工具負責的正是這一段。
- 推理層：LLM 讀進擷取到的內容、進行推理，再擬定下一輪的搜尋策略，讓整個流程轉成迴圈。
重點在於，這三層並非一層做完換下一層的線性流程，而是彼此交織：搜尋結果會扭轉推理方向，推理又決定下一趟搜尋。另外，RAG 與 deep research 之間不存在誰取代誰的關係：RAG 處理內部知識（文件、知識庫、資料庫），deep research 處理即時的公開網路資料。不少正式環境的系統兩者並行——RAG 供內部 context，web search 或 deep research 補上最新的外部資料。
文中還附了一個 end-to-end 整合範例：用 LangGraph 打造一個會呼叫 Firecrawl /search 的 agent，回答需要 live web 資訊的問題。第一步先設定 Firecrawl client，並把搜尋包成一個 LangChain tool：
from firecrawl import Firecrawl
from langchain_core.tools import tool
firecrawl = Firecrawl(api_key="your-firecrawl-api-key")
@tool
def web_search(query: str) -> str:
"""Search the web and return scraped content for the given query."""
results = firecrawl.search(query, limit=4, scrape_options={"formats": ["markdown"]})
output = []
for doc in results.web:
url = doc.url or ""
title = doc.title or ""
content = (doc.markdown or "").strip()[:1000]
output.append(f"Source: {title} ({url})\n\n{content}")
return "\n\n---\n\n".join(output)再來把 agent 建起來、實際執行：
from langchain_openai import ChatOpenAI
from langgraph.prebuilt import create_react_agent
llm = ChatOpenAI(model="gpt-4o-mini")
agent = create_react_agent(llm, tools=[web_search])
response = agent.invoke({
"messages": [{"role": "user", "content": "What are the main new features in Python 3.13?"}]
})
print(response["messages"][-1].content)全份 script 壓在 30 行以內：搜尋、抓取與 markdown 轉換交給 Firecrawl，推理迴圈交給 LangGraph。如果你用的是 Claude Code 這類 terminal agent，也可以改走 Firecrawl CLI，不必安裝 SDK 同樣能直接存取 web，全域安裝方式如下：
npm install -g firecrawl-cli
firecrawl login --api-key fc-YOUR_API_KEY裝好之後，像 firecrawl search "AI agent benchmarks 2026" --scrape --limit 5 -o results/ 這樣的子指令就能直接用來查詢。
接下來該怎麼走，才夠務實
Firecrawl 給了一組清楚好用的判斷準則：agent 要快速回答單一來源的問題，選 web search；要把多個來源彙整成綜合報告，選 deep research；要檢索內部文件，選 RAG。
對打造產品的人來說，2026 年的重點在於這些能力已經降到「設定一行設定」的等級，不必再從零打造。文章建議挑一個具體 use case 起步——知識庫同步或競爭情報都好——再用現成的 API 與協定把它們串起來。走到這一步，難的早已不是技術可不可行，而是怎麼替 agent 設計搜尋策略：什麼時候該搜尋、要搜尋什麼，又該怎麼判斷何時停止。
當然，Firecrawl 這篇文章本質上是 vendor 內容，所有案例清一色採用他們的服務，數據與案例都得先打個折扣再讀。不過大方向——web search 與 deep research 正在成為 agent 的標準基礎設施——是站得住腳的，因為它與過去一年 MCP、agentic browser 和 deep research 產品的實際發展步調一致。