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 加 web access 還是 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 行：Firecrawl 負責搜尋、抓取與 markdown 轉換，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 產品的實際發展。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。