DeepSeek Search 和 Fetch 為即時網絡存取訂下每 1,000 次成功呼叫 0.75 美元的價格
DeepSeek 已開放其 Search 和 Fetch API，每 1,000 次成功請求收費 0.75 美元，為 AI 代理的即時網絡存取訂下相當低的價格。DeepSeek Search 和 Fetch 將網絡檢索與模型推理分開，讓開發者可透過兩個原始 JSON 端點搜尋或擷取網頁。
這改變了研究代理、程式編寫助理及檢索增強生成（RAG）的經濟模式；RAG 讓模型可在執行時取得外部資訊。搜尋經常被視為次要功能，但在生產環境的代理中，重複搜尋及網頁擷取可能成為一項獨立的基礎設施開支。
這個低廉的標價隨即引起關注。然而，更重要的競爭並非 DeepSeek 與某一家搜尋供應商之爭，而是低成本檢索與可靠檢索之爭。開發者仍需要證據，證明 DeepSeek 能返回相關來源、擷取複雜網頁、保障敏感查詢，以及支援生產流量。
比較範圍亦延伸至整合式模型平台。OpenAI 會分別就網絡搜尋呼叫及相關模型輸入收費，而專門供應商則將搜尋、擷取或研究服務作為獨立服務出售。DeepSeek 押注於簡單介面及進取的請求定價，讓網絡存取成為一般代理的基本能力。
DeepSeek Search 和 Fetch 將檢索拆分為兩個 API
DeepSeek 已把兩項常見的代理操作轉為可獨立計費的服務：尋找網頁和閱讀網頁。
Search and Fetch guide 記錄了公司現有 API 網域下的兩個端點。Search 接受查詢並返回結構化結果；Fetch 接受一個 URL，並以 Markdown 返回網頁標題及內容。
Search 端點可返回一至 50 項結果。回應包括標題、URL、摘要片段、較長摘要、發布日期（如有）及權威性分數。DeepSeek 表示，三或四分代表高度權威的來源，而負一則表示權威性未知。
開發者亦可要求每項搜尋結果附帶完整網頁內容。need_content 選項可在搜尋呼叫內做到這一點，但如檢索失敗，內容仍會留空。這項設計可減少同時需要發現資料及可讀文字的代理所需的編排工作。
查詢語法支援精確片語、排除條件、語言限制、日期範圍及網站篩選。開發者可將結果限制於選定網域，或排除某個來源，而毋須另行建立查詢轉換器。原始用戶問題亦可隨搜尋片語一併提交，協助 DeepSeek 理解意圖。
Fetch 執行較狹窄的工作：擷取一個 HTTP 或 HTTPS URL，並將可擷取內容轉換為 Markdown；這是一種保留標題及連結的純文字格式。這類輸出比未處理的 HTML 文件更容易傳入語言模型。
兩項服務均採用 bearer 驗證及一般 JSON 請求，並不局限於專有的軟件開發套件。應用程式可從函式工具、工作流程引擎、命令列代理或自訂後端呼叫它們。
這項拆分很重要，因為搜尋及擷取的失敗方式不同。搜尋可能找不到相關結果，而 Fetch 則可能遇上被封鎖的網域、不支援的格式，或沒有可用內容的網頁。將操作分開可讓開發者重試、替換或快取任一階段。
DeepSeek 列出明確的錯誤碼，包括無效輸入、帳戶餘額不足、安全性拒絕、內容不可用、速率限制及下游逾時。它建議對逾時、速率限制及伺服器錯誤進行重試，但其他用戶端錯誤若不更改請求則不應重試。
該服務為唯讀。它可發現及擷取內容，但不會點擊按鈕、提交表單，或操作瀏覽器工作階段。團隊如需處理互動式網站、已驗證資源，或在用戶操作後才呈現重要資訊的應用程式，仍需要瀏覽器自動化層。
Search 請求的帳戶級限制為每秒 100 次請求。Fetch 則有每秒 25 次請求的獨立限制，並附加每網域限制。獨立配額可避免突發的擷取工作耗盡所有搜尋容量。
這些細節令這次發布不僅是一項模型功能。DeepSeek 提供的是檢索基礎設施，可置於其模型旁邊，或納入更廣泛的代理系統。下一個問題是，計費規則將如何改變應用程式設計。
每 1,000 次 0.75 美元的費率獎勵成功檢索
DeepSeek 針對可用回應而非每次嘗試收費，將部分檢索失敗風險轉回供應商承擔。
Search 每 1,000 次成功請求收費 0.75 美元，Fetch 的費率相同。DeepSeek 將成功的 Search 請求定義為：HTTP 200 回應中含有非空的結果陣列。Fetch 只有在返回網頁內容時才會計費。
失敗呼叫、逾時及沒有結果的搜尋均不收費。結果數量不會改變請求價格，因此要求 50 項結果與要求一項結果的搜尋收費相同。模型處理及其他 API 使用量仍屬獨立開支。
因此，一個進行一次搜尋並擷取五個網頁的工作流程，會產生六次可能計費的檢索呼叫。按公布費率計算，1,000 個這類工作流程會產生 6,000 次成功呼叫，檢索費用為 4.50 美元。Token 處理則會增加另一項成本。
這個區別避免人們誤解標價。廣告所示的數字並不代表整項研究工作只需 0.00075 美元。一個代理在撰寫答案前，可以重新表述查詢、檢視多個來源、追蹤引文，並擷取多個網頁。
深度研究工作流程可能產生數十次呼叫。當來源互相矛盾，或初始查詢缺乏有用結果時，自主代理亦可能重複搜尋。低廉的單位價格固然重要，但最終帳單仍取決於編排方式。
DeepSeek 的規則仍為開發者提供一定程度的可預測性。搜尋費用不會隨結果數量而變，失敗的檢索亦不會消耗付費單位。團隊可按成功的工具呼叫估算成本，而毋須為額外的檢索 token 流量建模。
這次發布亦影響 DeepSeek 的程式編寫及代理整合。其文件指出，來自 DeepSeek Harness、Claude Code 和 Codex 的伺服器端工具呼叫，已使用 Search 和 Fetch 服務。這些呼叫將維持免費，直至 2026 年 11 月 1 日北京時間午夜開始計費。
該日期在營運上相當重要。開發者未必直接發出端點請求，但代理在解決任務時可觸發搜尋。因此，使用量儀表板及預算需要計算自主工具呼叫，而不僅是由個人明確發起的操作。
DeepSeek 的 Responses API guide 展示伺服器端搜尋如何參與模型回應。在該設定中，平台會執行檢索、把結果加入模型的上下文，然後繼續生成。這種便利性亦令長時間代理工作階段內的搜尋用量較不顯眼。
作為比較，現時的 OpenAI API pricing 列出網絡搜尋每 1,000 次呼叫收費 10 美元，而搜尋內容 token 則按所選模型的費率計費。服務並不完全相同，因此數字差距並不代表價值相等。
整合式搜尋可包括排序、來源處理、引文、安全控制、區域功能或針對模型的最佳化。獨立 API 可能對檢索迴圈提供更多控制。買家需要比較完整任務，而非定價頁上的一行資料。
不過，DeepSeek 的方案確實為市場較低端帶來壓力。嘗試數千次呼叫的開發者，現在可將託管檢索視為一項小型的變動開支。這削弱了每個代理團隊都必須自行營運爬蟲及搜尋堆疊以控制成本的假設。
這項改變亦有利於模組化架構。Search 可服務一個模型，而 Fetch 可為另一個模型提供內容。團隊可保留模型選擇，並測試 DeepSeek 作為檢索元件，惟帳戶條款及資料處理仍須審閱。
低成本 AI 搜尋向整合式及專門供應商施壓
DeepSeek 正在測試，搜尋應否繼續是一項高價 AI 功能，還是成為低成本基礎設施。
AI 應用程式會為多種工作使用網絡檢索。支援代理會查閱最新文件；研究助理會為某項說法尋找證據；程式編寫代理則會閱讀在其訓練截止日期後出現的發布說明、問題追蹤及程式庫參考資料。
這些工作不只需要熟悉的搜尋結果頁面。應用程式需要機器可讀的輸出、穩定的回應欄位、可預測的延遲，以及可進入模型上下文的文字。它亦需要一個不會懲罰合理重試行為的計費系統。
專門供應商透過索引覆蓋率、排序品質、擷取成功率、新鮮度及工作流程功能競爭。有些提供全文文字、答案綜合、網域篩選或研究端點；另一些則強調資料駐留及合約控制。
模型供應商則採取不同路線。他們可把搜尋嵌入回應中，並讓模型決定何時使用。這可減少整合工作，但亦可能令檢索行為較難觀察或在平台之間轉移。
DeepSeek 結合了兩種方法的部分特點。其原始端點類似專門基礎設施，而其伺服器端工具則把檢索連接至 DeepSeek 模型及相容代理用戶端。這為該公司提供兩條進入開發者技術堆疊的路徑。
低費率對高頻率、低單項價值的工作最具吸引力。以每小時檢查供應商文件的內部監控系統為例，搜尋品質必須可接受，但每次個別查詢並不足以值得採用昂貴的研究流程。
高風險工作的計算方式則有所不同。法律、醫療、金融或保安工作流程，可能更重視可靠的來源覆蓋率，而非請求價格。遺漏一份權威文件的代價，可能高於數千次搜尋。
延遲亦很重要。聊天助理不能在每個簡短問題後，都暫停等待一連串緩慢的搜尋及擷取。研究工作可容許較長時間，但仍需要在眾多網域中成功擷取內容。
在 Hacker News thread 討論這次發布的開發者，指出了這種取捨的兩面。一些人認為託管檢索比自行維護爬蟲更容易且更可靠；另一些人則質疑覆蓋率、私隱、速率限制及擷取品質。
這些評論屬軼事，並非基準測試結果。它們反映買家正在提出的問題，但並不能證明某一家供應商表現較佳。該服務仍太新，尚未有廣泛的生產環境證據可定論比較結果。
自託管搜尋仍是另一個競爭對手。開源的元搜尋系統可聚合公開搜尋引擎，而毋須支付每次請求的供應商費用。直接擷取工具亦可將許多一般網頁轉換為乾淨文字。
然而，「免費」自架仍涉及伺服器、代理、更新、可觀測性，以及回應封鎖情況。團隊必須判斷，避免託管服務費用是否值得承擔這些營運工作。答案會隨規模、人手及可靠性要求而改變。
DeepSeek 的定價削弱了維護這些基建的經濟理據，但並未消除掌控權的理據。本地營運的系統可讓查詢留在機構內，並套用自訂排序或允許清單。
實際的應對方法是量度。團隊應建立一套代表其真實領域及問題的固定評估集，然後比較相關性、來源多樣性、擷取完整度、延遲，以及每項完成任務所需的總呼叫次數。
可搜尋的內部技術資料集合可補足即時檢索。團隊往往同時需要最新的公開來源及私有脈絡。結構化的工程知識庫可保留內部證據可供取用，而無須將每條問題都送往公開網絡。
這種組合式架構亦可減少不必要的搜尋。代理可先查閱本地資料、識別缺漏，再把外部檢索留給需要最新核實的資訊。
DeepSeek Search API 品質仍是缺失的關鍵數字
定價已獲核實，但評估搜尋品質所需的證據仍未完整。
DeepSeek 表示，Search 運行於其自研搜尋引擎。其回應 schema 提供摘要、排序分數、權威程度及可選頁面內容。這些欄位有用，但 schema 無法證明底層結果是否相關或完整。
搜尋品質會因語言、地區、主題及查詢類型而異。引擎可能在中文技術來源上表現良好，卻遺漏北美本地報道；亦可能穩定找到官方文件，卻難以處理小眾論壇或剛更新的頁面。
擷取品質亦有自身的失敗模式。現代網站可能需要 JavaScript、拒絕自動化用戶端、將內容置於驗證登入之後，或把重要資訊放在文件內。DeepSeek 指出，擷取仍受網站可用性及存取政策所限。
成功的 HTTP 回應亦不代表有用的證據。擷取出的 Markdown 可能漏掉表格、將導覽內容誤作文章正文，或失去圖片說明與圖片之間的關係。代理其後可能根據不完整資料產生看似有把握的答案。
「成功請求」的收費定義，比成功完成任務更狹窄。只要搜尋回傳至少一個結果，即使結果不相關，便會計費；只要擷取回傳內容，即使內容沒有所需事實，亦會計費。
因此，團隊應把語義成功與可計費成功分開監察。有用的指標包括正確來源是否出現、擷取內容是否包含目標段落，以及最終答案是否引用支持其主張的證據。
來源多樣性是另一項測試。若引擎反覆回傳同一報道的複製版本，便可能營造出互相印證的假象。單靠 URL 去重，無法偵測經聯播或改寫的內容。
開發人員亦需要檢視權威分數。DeepSeek 定義了該量表，但其公開指南未有說明完整的評分方法。高分應用於引導排序，而不應取代對來源的獨立判斷。
政治及地區報道值得審慎測試。搜尋引擎會對索引、排序、安全及法律合規作出選擇。這些選擇可在語言模型開始推理前，影響代理所看見的內容。
私隱是另一項關注。查詢可能披露產品計劃、安全問題、客戶名稱、收購目標或未公開研究。擷取 URL 則可能揭示機構正在調查哪些文件及系統。
在敏感部署前，應連同 API 協議一併審閱 DeepSeek 的公開私隱政策。Search 及 Fetch 指南說明功能與收費，但未有為這些端點提供專門的零資料保留承諾。
採購審查應確認哪些請求資料會被記錄、在哪裡處理、保留多久，以及是否可用於改善服務。具合約約束力的承諾，比從低價推斷出來的假設更重要。
安全團隊亦應檢視間接提示注入。被擷取的頁面可能含有旨在操控代理、索取秘密資訊或改變其行為的文字。將頁面轉為 Markdown，並不會令其中的指令變得可信。
應用程式必須把檢索到的內容視為不受信任的資料。工具權限應與頁面文字分開，代理不應僅因指令出現在來源中便執行。敏感操作需要在模型生成計劃以外進行明確的政策檢查。
快取可同時減少成本及暴露風險。只要新鮮度要求容許重用，經常請求的公開頁面毋須重複擷取。快取亦可保留紀錄，顯示較早前的答案究竟受哪些內容影響。
不過，快取亦帶來版本問題。若團隊需要可重現的結果，必須記錄擷取時間、來源 URL 及內容雜湊值。否則，之後的擷取可能回傳已更改的頁面，而該頁面已不再支持原有主張。
DeepSeek 令成本變得容易理解，但未有消除讓檢索準確、安全及可審計所需的工程工作。
DeepSeek Search 與 Fetch 如何改變代理設計
這次發布令檢索成本低至可更頻繁使用，但優秀代理應更有目的地搜尋，而非不加分辨地搜尋。
強健的工作流程，先要判斷是否需要即時資訊。穩定的定義及內部程序，可能已存在於可信任的知識庫中；最新價格、發布、政策及新聞通常需要外部核實。
代理其後可將用戶問題轉化為一個小型搜尋計劃。一條查詢應針對主要來源，另一條可尋找獨立報道或批評；額外搜尋應處理特定缺口，而非重複寬泛措辭。
DeepSeek 的運算子支援這種模式。查詢可鎖定官方網域、設定發布時間窗，或限制語言。這些控制有助代理帶着證據目的進行搜尋，而非收集大量且缺乏焦點的結果。
結果數量亦帶來最佳化機會。由於已公布的請求費率不會因回傳一個或 50 個結果而改變，系統可請求足夠候選項目供重新排序。不過，仍應避免把每一項回傳內容都塞進模型上下文。
獨立的排序階段可按相關性、權威性、時效性及多樣性選取來源。然後，Fetch 應只擷取可能影響答案的頁面。這可減少擷取呼叫，並限制進入模型的不受信任文字。
工作流程應在整個處理過程中保留引用。摘要固然方便，但最終答案需要 URL 及支持每項重要主張的段落。當證據互相矛盾時，系統應報告分歧，而非將其混合成一個欠缺支持的結論。
Fetch 失敗需要有限度的重試。經過延遲後重試受速率限制或逾時的請求是合理的；在未改變請求下，重複安全拒絕或不支援內容錯誤只會浪費時間，並可能形成迴圈。
生產系統亦需要多個層級的預算。工作階段限制可防止單一用戶請求觸發數百次搜尋；每日帳戶限制可控制意外流量；每個網域的控制則可減少對個別網站的壓力。
新的經濟條件可能鼓勵過度檢索，因為每次呼叫看似幾乎免費。這會是錯誤。更多搜尋結果可增加延遲、重複證據、上下文大小，以及提示注入的機會。
代理設計人員應量度每個獲接受答案的成本，而非每次 API 呼叫的成本。該指標包括檢索、模型 token、重試、驗證及人手審查，亦反映答案是否真正解決用戶問題。
有用的評估集可包含四類問題。新鮮度問題測試最近更新；已知項目問題測試引擎能否找到特定權威頁面；比較問題測試來源多樣性；困難頁面則測試擷取行為。
每項測試應記錄預期來源的排名、擷取完整度、延遲及付費請求數量。評估人員可為引用支持度評分，並記錄答案何時需要另一個供應商或人手審查。
原始端點亦令備援路由變得實際。應用程式可先以 DeepSeek 處理一般搜尋，然後在涵蓋範圍或擷取失敗時使用其他來源。這可保障品質，同時維持較低的平均成本。
這個策略需要標準化。不同供應商回傳的欄位、分數、摘要及日期格式各異。共用的內部 schema 可避免應用程式其餘部分依賴單一供應商的回應格式。
因此，DeepSeek 的 API 易於測試，但不會自動變得易於替換。開發人員應把驗證、錯誤處理及供應商特定的排序欄位隔離於 adapter 內。代理便可請求「搜尋」，而毋須知道由哪項服務執行。
這種架構將價格競爭轉化為買方優勢。供應商必須以可量度的表現爭取流量，而團隊則保留在政策或品質改變時轉移工作負載的能力。
三個訊號將決定低價是否重要
下一項測試是，DeepSeek 能否把開發人員的好奇心轉化為持續的生產使用，同時不削弱品質或信任。
第一個訊號是獨立檢索基準測試。有用的測試必須涵蓋語言、近期事件、技術文件、本地資訊及對抗性頁面；測試應公布查詢集及評分方法，而非只公布單一平均值。
若 DeepSeek 能持續找到權威來源並擷取完整內容，低費率便具備策略份量。若結果需要反覆搜尋或經常使用備援供應商，標題所述的優勢便會在任務層面縮小。
第二個訊號是企業資料處理。買家需要清楚了解查詢保留、處理地點、訓練用途、安全控制及合約刪除安排。具備記錄在案的零保留選項，將加強 DeepSeek 在敏感工作負載中的地位。
沉默或含糊其辭則會帶來相反效果。由於搜尋詞可暴露機密意圖，許多機構會為可執行的控制措施支付更高費用。廉價檢索無法彌補不可接受的資料路徑。
第三個訊號是競爭對手的回應。搜尋專家及模型平台可降低價格、綑綁檢索服務、改善免費額度，或強調更高品質的研究能力；亦可透過區域處理、引用、瀏覽器執行或企業協議作出差異化。
廣泛的降價回應，將確認 DeepSeek 已重設基本檢索的預期；有限的回應則表示競爭對手相信，買家對品質、整合及治理的重視高於請求費用。
開發人員亦應留意 11 月 1 日開始計費後的使用情況。持續採用將顯示用戶看重的不只是其初期免費期；若使用量急劇下跌，則表示早期關注是由好奇心而非生產需求所推動。
公開定價為 DeepSeek 帶來實際的切入點。Search 和 Fetch 簡單易試，數小時內便可完成測試，而失敗的請求不會產生檢索費用。這降低了進行實際評估的成本。
這並不能決定採購取向。團隊應比較具代表性的任務、審閱相關協議，並追蹤從查詢到附有引文的答案之完整流程。他們亦應在透過服務傳送客戶或公司資料前，測試各種失敗情況。
DeepSeek Search and Fetch 提出了一項令人難以忽視的主張：即時網絡存取不再必須是附加於模型上的昂貴高階功能。餘下的問題是，DeepSeek 能否以這個價格提供可靠且可管治的檢索服務。
在你現有供應商與 DeepSeek 之間，使用同一套評估項目進行測試。衡量相關來源、完整擷取、延遲、計費呼叫數量及引文準確度。然後在移除敏感查詢後重複測試，直至資料條款符合你的要求。若 DeepSeek 在完整任務而非孤立呼叫上勝出，其 $0.75 的收費便會具意義；若它只是在價目表上勝出，最便宜的搜尋請求仍可能帶來成本更高的答案。
