當你要求一個 AI 代理去回答需要查閱數十個網頁的複雜問題時，常見的體驗是「等幾分鐘，甚至十幾分鐘才拿到結果」。這種等待不只是 UX 不夠好，也限制了開發者能塞進產品裡的即時研究流程。
Exa 在 4 月 20 日發表的 Deep Max，正是為了同時解決準確度與延遲這兩個問題而設計的 agentic 搜尋端點。Exa 的公告 指出，它在所有主要的 agentic 搜尋基準測試上達到最先進的準確率，而且速度比最接近的競爭對手快多達 20 倍。本文會從產品開發者的角度，把這個端點的原理、速度和實際限制梳理清楚。
代理搜尋的瓶頸在哪裡
許多 deep research 產品之所以慢，常常不是 LLM 推理本身花了太多時間，而是搜尋工具鏈太慢。
典型流程是：模型先規劃出幾個搜尋方向，然後逐一呼叫搜尋 API、擷取頁面內容、消化後再決定下一步。如果每一輪呼叫都要等待一個慢速的傳統搜尋索引，再加一次網頁爬取，幾輪下來就變成了分鐘級的操作。這讓「搜尋」這件事變成了整個 pipeline 的瓶頸，而不是模型理解問題的時間。
Deep Max 的思路，就是把這個瓶頸拆成三層來解。
Deep Max 的核心設計
Deep Max 並非一個全新的獨立產品，而是 Exa 搜尋堆疊上最高規格的一個端點。它把以下三個東西綁在一起運作：
- 一個前線 LLM，用來拆解複雜問題、規劃多角度的搜尋策略，並匯總結果；
- 數十個平行的 Exa 搜尋呼叫，從不同面向出發同時查找資料；
- Exa 自己的搜尋索引與內容清理管線，負責快速回傳結果與壓縮後的頁面文字。
你可以這樣想像：它不是讓 LLM 慢條斯理地「搜一下、等一下、再看下一頁」，而是一次發起幾十個搜尋動作，並在回傳時立刻整合。這大幅壓縮了等待搜尋結果的空閒時間。
速度的秘密：三層加速
Exa 團隊在公告裡解釋了為什麼 Deep Max 可以把時間壓到「幾十秒」而非「幾十分鐘」。這三層加速機制對任何想打造研究型 AI 應用的人都很有參考價值。
第一層，平行工具呼叫。 現代的 LLM SDK 能夠同時展開多個搜尋與內容擷取請求，每個請求針對問題的不同側面。模型一邊收回結果，一邊就能開始聚合，而不是等最後一個請求完成才動筆。這種 fan-out 模式把原本序列化的等待時間變成幾乎平行處理。
第二層，對 token 友善的內容格式。 Exa 回傳的網頁文字已經過裁剪，去除了導航列、頁首頁尾等雜訊，並附上能引導模型判斷重點的 highlights。最終答案才需要完整內容時，可以用 full crawl 取得。這樣一來，LLM 的上下文大多數時間都用在「推理」而非「消化 HTML 垃圾」上。
第三層，搜尋本身很快。 因為所有工具呼叫都直接打在 Exa 自己的搜尋引擎上，單次搜尋的回應時間低於一秒。當一次查詢會發出幾十次呼叫時，每一次都快，累積起來就讓整體體驗與依賴老舊、慢速搜尋 API 的編排層完全不同。
基準測試結果
Exa 把 Deep Max 跟主要的 agentic 搜尋系統（Parallel Ultra、You.com Frontier、Perplexity Deep Research）以及有原生搜尋工具的前沿 LLM（GPT 5.4、Gemini 3.1 Pro、Claude Opus 4.7）做了比較。公告 中提到，在三項評估上都呈現出明顯的右上角趨勢：準確度更高，延遲更低。
不過，公告裡並沒有具體列出這三項基準的名稱或設計細節。對想要自行複現或深入比較的開發者來說，這是一個目前缺乏的資訊；需要跟 Exa 團隊聯繫才能確認基準是否涵蓋了你關心的任務型態（例如多語言長文、時效性新聞查證，或是結構化資料擷取）。
對產品開發者的意義
如果你正在規劃一個需要「查很多網頁才能產出結論」的功能——例如研究助理、投資盡職調查摘要、政策分析工具——這類 agentic 搜尋端點可能會改變你的架構決策。
傳統上，你會自己組合搜尋 API、爬蟲、LLM 編排層和 prompt 策略，而且為了壓低延遲，不得不犧牲搜尋的廣度。Deep Max 把這幾層打包成一個 API 呼叫，讓你有機會在「十秒級」的延遲內，完成原本需要一、兩分鐘的資訊整合工作。這代表你能在互動式產品裡放進更複雜的查詢，而不必強迫使用者接受一個「按下去，去泡杯咖啡再回來」的體驗。
但是，目前的限制也很明顯。定價尚未公開，公告只說「聯絡團隊洽談用量與定價」。這代表它不是一個能立刻整合到正式產品的自助式 API，至少前期必須跟 Exa 溝通用量與成本分攤。另外，速度是相對於那些原本就要跑上好幾分鐘的查詢，對於簡單的「一句話問答」，這個端點未必是經濟實惠的選擇。
現在能做的事
Deep Max 的出現，反映了一個正在發生的轉變：搜尋工具本身的品質（索引廣度、頁面內容乾淨程度、回應速度）正在成為 agentic 系統的瓶頸，而不再只是模型能力的問題。
對產品開發者來說，現在比較務實的做法是：
- 密切關注 Exa 後續是否釋出自我服務的定價方案，以及更詳細的基準報告；
- 在自己現有的架構裡，先嘗試把「平行搜尋」和「內容清理」這兩層優化做進去——這兩件事不太依賴 Exa 的特定堆疊，卻能立刻改善研究型管線的延遲；
- 評估你的使用場景是否真正需要「幾十次搜尋、十秒內完成」的速度，還是使用者其實可以接受更長的回應時間，換取更便宜的單位成本。
Deep Max 把 agentic 搜尋的速度邊界往前推了很大一步，但現階段它還是一個需要對話才能啟用的方案。把它當作一個觀察搜尋架構演進的窗口，而不是一個今天就能直接接入的模組，會是更貼近現實的態度。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。