摘要： Exa 於 4 月 20 日推出 Deep Max，用前線 LLM、數十路平行搜尋、自家索引與內容清理組成代理搜尋端點。官方宣稱在主要基準上達到最先進準確率，速度最多比最近對手快 20 倍；但公告未詳述基準設計，也尚未提供自助定價。
派 AI 代理去處理得翻閱幾十個網頁的難題，使用者最常碰到的劇本是：結果遲遲不來，一等就是好幾分鐘、甚至十幾分鐘。這段等待不只讓產品體驗打了折扣，也讓開發者想把即時研究流程做進產品裡時處處受限。
4 月 20 日，Exa 推出了 Deep Max——一個為了同時處理準確率與延遲而設計的 agentic 搜尋端點。依官方公告的說法，它在各個主要的 agentic 搜尋基準上都寫下最先進的準確率，速度更比距離最近的對手快上最多 20 倍。以下就站在產品開發者的立場，把這個端點的運作原理、速度從何而來，以及現階段的限制逐一整理。
時間到底耗在哪裡
一堆 deep research 產品給人慢吞吞的印象，肇事者往往不是 LLM 想得太久，而是它身後那條搜尋工具鏈跑不快。
流程大致是這樣走的：模型先想好幾條查詢路線，接著一輪接一輪地打搜尋 API、抓回頁面內容、讀完之後再盤算下一步。假如每一輪都得排在慢速的傳統搜尋索引後面乾等，外帶一次完整的網頁爬取，跑個幾輪就是以分鐘計的工程。真正卡住整條 pipeline 的是搜尋，而非模型理解題目所花的那點時間。
Deep Max 的解法，是將這個瓶頸拆成三層，逐一擊破。
Deep Max 是怎麼組出來的
先把定位講清楚：Deep Max 不是另起爐灶的新產品，而是 Exa 搜尋堆疊中規格最高的那個端點，由三個元件綁在一起協同運作：
- 一顆前線 LLM，負責把複雜問題拆開、擬定多路並進的搜尋策略，最後彙整出答案；
- 幾十路 Exa 搜尋同時出發，各查一個面向，互不等待；
- Exa 自家的搜尋索引加上內容清理管線，快速交回搜尋結果與去蕪存菁的頁面文字。
換個方式理解：與其讓 LLM 按部就班地「查一筆、等一會、再翻下一頁」，不如一口氣丟出幾十個搜尋，資料一回來就當場合併。過去耗在等搜尋回應的空轉時間，就這樣被大幅擠掉了。
三層加速，時間是這樣省下來的
Deep Max 憑什麼把一般查詢從「幾十分鐘」壓到「幾十秒」收工？Exa 團隊在公告中給出了答案，拆出三層加速機制——對任何想打造研究型 AI 應用的人來說，這套思路都值得借鏡。
第一層，工具呼叫全面平行化。 現在的 LLM SDK 都辦得到同時發出多個搜尋與內容擷取請求，每一發對準題目的不同切面。結果邊回來，模型邊彙整，不必等最後一筆到手才開工。這種 fan-out 打法，把過去一關做完才換下一關的序列等待，換成近乎全平行地執行。
第二層，內容格式替 token 省空間。 Exa 交回的頁面文字事先修整過：導航列、頁首頁尾這類雜訊都已切除，另附 highlights 幫模型鎖定重點段落。真的需要整份內容，才動用 full crawl 補齊。如此一來，LLM 的上下文幾乎全花在推理上，不必再啃 HTML 邊角廢料。
第三層，搜尋引擎本身夠快。 所有工具呼叫打的清一色是 Exa 自家搜尋引擎，單次回應不到一秒。一次查詢動輒發出幾十個呼叫，每一發都快，疊出來的整體手感，自然跟踩在老舊慢速搜尋 API 上的編排層拉開了完全不同的差距。
基準測試的成績
這輪比較分成兩組對手：一組是主流 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 的特定堆疊，卻能馬上壓低研究型管線的延遲；
- 想清楚你的使用場景是否真的需要「幾十次搜尋、十秒內完成」——若使用者其實願意多等一陣子，用更長的回應時間換更便宜的單位成本，未必是筆壞交易。
在推進 agentic 搜尋的速度邊界這件事上，Deep Max 確實跨出了一大步；只是現階段，它仍屬於需要先談過一輪才能啟用的方案。把它視為觀察搜尋架構如何演進的一扇窗，而非一個今天就能直接接上的模組，是更貼近現實的判讀。