DeepSeek 於二零二六年十月推出 Search API 與 Fetch API，把自家搜尋引擎與網頁擷取能力開放給開發者。Search 依查詢找出網頁並回傳結構化結果，Fetch 把單一網址轉為 Markdown 正文；兩者皆為原始 JSON 介面，沿用與模型相同的 Bearer 金鑰，每千次成功請求收費 0.75 美元。

DeepSeek Search 與 Fetch API 是什麼？

Search API 依查詢找出網頁並回傳結構化結果，Fetch API 把單一網址轉為 Markdown 正文，兩者由自家搜尋引擎驅動，同屬原始 JSON 介面。

兩支介面的端點分別是 https://api.deepseek.com/v1/tools/search 與 https://api.deepseek.com/v1/tools/fetch，皆為 POST 請求，並使用與 DeepSeek 模型相同的 Bearer 金鑰與 JSON 內容型別。官方把定位寫成讓代理與檢索增強應用取得即時網路內容，也就是把「搜尋」與「讀取」拆成兩個獨立動作，由呼叫方自行決定何時檢索、何時深入單一頁面。

設計上值得留意的是搜尋引擎為自家建置，而非轉接既有搜尋服務。對需要控制資料流向的團隊而言，這代表檢索鏈路少了一層外部依賴；對已經在使用 DeepSeek 模型的專案而言，金鑰與計費都能沿用同一套後台。兩項介面皆為唯讀操作，不會修改目標網站內容。

Search API 支援哪些查詢條件與運算子？

查詢最長一百二十八個字元，支援 site、排除詞、精確短語、lang、after 與 before 等運算子，並可設定回傳數量、是否附帶正文及原始問題。

搜尋請求的核心欄位是 query，長度限制為一至一百二十八個 Unicode 字元，不可全為空白。系統會原樣轉送查詢語法，因此支援多種運算子：site: 可把結果限制在指定網域，並以 OR 串接多個網域；前綴減號可排除網域或特定詞彙；雙引號用於精確短語比對；lang: 依語言代碼過濾；after: 與 before: 則以年份或完整日期限制發佈時間。

其餘欄位用於調整回傳內容。count 控制結果數量，範圍為一至五十，預設十筆；need_content 決定是否在 content 欄位附上頁面正文，關閉時該欄位固定為空字串；ori_question 用來帶入觸發搜尋的原始問題，官方說明可改善查詢理解；localization 則接受一個 IP 位址以調整結果的地區傾向。請求中未知的欄位會被忽略，不會導致錯誤。

搜尋結果包含哪些欄位與評分？

每筆結果包含零至三分的排序分數、標題、網址、摘要、長摘要與可選正文，並附站名、圖示、發佈時間及零至四級的權威度。

回傳結構為 results 陣列，每筆包含多個可用於排序與篩選的訊號。rerank_score 是零至三分的相關性分數，綜合相關度、權威性與時效，官方以一．五分以上視為高品質結果；authority 是零至四級的站點權威分層，三分以上代表來源高度權威，負一表示無法判定。這兩項欄位讓呼叫方可以在生成答案前先行過濾，而不必只依賴回傳順序。

文本欄位則分為三層用途。snippet 約一百至二百字，適合直接顯示在介面；summary 約六百至八百字，設計上供模型閱讀；content 是完整頁面內容，僅在 need_content 為真且頁面可取得時才有值。其餘欄位包括標題、網址、站名、站點圖示與發佈時間，時間以 RFC 3339 格式的 UTC 表示，無法判定時為空值。

兩項 API 如何計費？

Search 與 Fetch 各按每千次成功請求收 0.75 美元計費，失敗、逾時與空結果不計費，回傳筆數不影響單次價格，經官方代理工具呼叫則暫免收費。

計費單位是成功請求，而非代幣或回傳結果數量。Search 與 Fetch 的價格同為每千次成功請求 0.75 美元，只有當請求回傳 HTTP 200 並產生結果時才計費：搜尋必須回傳非空的 results 陣列，擷取必須取得頁面內容。失敗請求、空搜尋結果與逾時都不收費，count 只控制回傳筆數，不會改變單次請求的價格。

官方另設一段過渡安排。當透過 DeepSeek Harness、Claude Code 或 Codex 使用 DeepSeek 介面時，伺服器端的工具呼叫會直接打到這兩支介面，這些呼叫現階段免費，按次計費自北京時間二零二六年十一月一日零時起生效。對正在評估成本的團隊而言，先以官方工具鏈試用、再決定是否自行接入，是風險較低的驗證路徑。

使用時有哪些限制與錯誤處理要求？

帳號層級下，Search 與 Fetch 各限每秒五次請求，擷取另受單一網域上限約束；逾時、限流與伺服器錯誤建議重試，餘額不足則須先充值。

速率限制以帳號為單位計算，與模型併發限制分開，且與使用哪一把金鑰無關。Search 與 Fetch 各自限制為每秒五次請求，超過即回傳 HTTP 429；Fetch 另外受到單一網域的每秒請求上限約束，同一網址的高頻呼叫同樣會收到 429。這意味著批次處理大量網址時，需要在呼叫端自行加入節流與排隊。

錯誤處理亦有明確分層。官方建議對 HTTP 408、429 與 5xx 採等待後重試；402 代表帳號餘額不足，須先充值；其餘 4xx 錯誤在未改變請求內容前不應重試。常見失敗原因包括欄位值不合法、金鑰無效、擷取被安全策略拒絕，以及頁面無法產出可用的 Markdown 內容。兩項介面皆為唯讀，因此不會出現寫入型副作用。

對開發者與代理應用有什麼影響？

代理與檢索增強系統可直接取得即時網頁，檢索鏈路少一層外部依賴，計費以成功請求為單位便於估算，並以分數與權威度支援結果過濾。

把搜尋與擷取做成獨立介面，改變的是代理的動作顆粒度。過往要讓模型取得網路資訊，多半得依賴第三方搜尋服務或在提示詞中塞入網址，如今可在流程中明確區分「先找候選頁面」與「再讀取指定頁面」兩步，並在兩步之間加入自訂的過濾與驗證邏輯。對於需要引用來源的問答系統，這種可檢視的中間結果比單一摘要更便於追溯。

計費模式同樣值得注意。以成功請求計價、失敗不計費，讓成本估算相對直觀，尤其是搜尋失敗或頁面無法擷取的情況不會產生費用。搭配可過濾的排序分數與權威度，團隊可以在送入模型前先淘汰低品質來源，間接降低後續推理的用量。限制方面，每秒五次的速率上限意味高併發場景仍需自建佇列，而擷取受目標網站政策約束，部分頁面本來就無法取得內容。

出處連結有哪些？

本文資訊整理自 DeepSeek 官方 API 文件的 Search 與 Fetch 指南，讀者可經下列連結查閱完整的請求欄位、回應結構與計費說明。

官方指南：https://api-docs.deepseek.com/guides/search/ DeepSeek 開發者平台：https://platform.deepseek.com

總結：這組 API 適合哪些開發者？

適合正在建構代理、檢索增強問答或網頁監測流程的開發者，尤其是已使用 DeepSeek 模型並希望檢索與生成共用同一金鑰與後台的團隊。

這組介面的價值在於把檢索能力納入既有的模型呼叫體系，而非另開一套外部服務。對於已經在應用中使用 DeepSeek 模型的團隊，金鑰、計費與文件都集中在一處，整合成本相對低；對於需要嚴格追溯來源的問答與研究流程，結果中附帶的排序分數、權威度與發佈時間，提供了可程式化判斷的依據。

限制則提醒團隊不要把它當成萬用抓取器。每秒五次的速率上限、單一網域的擷取限制，以及部分網站拒絕被擷取，都要求在應用層設計重試、快取與降級策略。對正在比較檢索方案、重視成本可預測性的開發者而言，以官方工具鏈先試用至十一月初，再依實際命中率與費用決定是否長期接入，會是較務實的評估方式。