一個端點只做一件事：DeepSeek 的 Search 與 Fetch，是把查證流程拆開了賣

2026 年 10 月 17 日，DeepSeek 更新 V4.1 Flash 至 1017 版本，同日開放 Search 與 Fetch 兩個網頁工具 API。這件事常被讀成「DeepSeek 有搜尋了」，但從介面設計的角度看，更有意思的地方在於它們被拆成兩個獨立端點，而不是一個包辦查資料的黑箱。

先看官方文件裡可指認的細節。Search 的請求帶查詢詞、結果數量，以及是否要求回傳內容；結果包含標題、網址、摘要等欄位。Fetch 要求送入一個網址，回傳頁面標題和 Markdown 正文。兩者都是 JSON API，共用同一把 Bearer 金鑰。換句話說，Search 負責找出候選，Fetch 負責讀取單頁，一個是「找」，一個是「讀」，各自只做一件事。

這種拆法和把搜尋整包塞進模型端點的做法，表情完全不同。整包式的好處是呼叫者省事，代價是來源透明度低，使用者看不到模型看了哪些頁面。拆開賣之後，篩選候選網址、決定何時抓取正文、把答案句子和來源逐項核對，這些步驟全被推回整合層。官方文件也把界線講得相當清楚：Fetch 受目標網站可用性和存取政策影響，遇到不支援的格式、網站封鎖或無法擷取正文時請求可能失敗；它也不會替代理判斷該頁是否可信。搜尋結果裡的摘要同樣只是搜尋服務整理的內容，不能直接當作已核對的證據。

計費欄位也是這套設計的一部分。官方標示 Search 與 Fetch 每 1,000 次呼叫各為 0.75 美元，按成功請求計費，和模型依輸入輸出 token 計算的費用分開列。DeepSeek Harness、Claude Code 與 Codex 內的伺服器端呼叫暫免，2026 年 10 月 31 日 16:00 UTC 起開始計費。把工具費和模型費分列，等於把「查了多少次」變成一個可被看見、可被預算的欄位，這對代理工作流的成本設計是實質的介面資訊，因為一個會反覆重試的流程，花的錢會直接反映在請求次數上。

另一個容易被忽略的細節，是版本更新與搜尋功能其實被官方當成兩件事寫。V4.1 Flash 1017 是模型更新，API 呼叫方法與定價維持原狀；Search 與 Fetch 是另開的端點。也就是說，「搜尋 API 開放」並不代表第三方應用裡的 DeepSeek 模型自動連上網路。只呼叫一般模型 API 的系統，仍要自行加入工具流程；使用具備伺服器端工具的環境，則要確認該環境實際採用的工具路徑與計費方式。這條界線畫得誠實，但也把整合成本明白留給了接入方。

這種「把驗收條件拆成逐項確認」的做法，和先前觀察過的Mellum 2.1 的修復驗收介面屬於同一類設計思路：服務端不替你判斷結果可信與否，而是把可判斷的欄位交出來，讓流程自己長出核對的步驟。

回到最初的問題：工作流需要的是搜尋結果、網頁正文，還是能追溯來源的答案？DeepSeek 這次給的是前兩者的原料，第三種仍要靠整合層把來源可靠度、失敗處理、金鑰與資料治理自己排進流程。拆開的端點換來了透明與控制，代價是沒有人替你做完查證。對願意自己排工作流的團隊，這是一套欄位清楚、計價可讀的介面；對期待開箱即用聯網答案的人，它目前什麼都還沒答應。