一份供應商比較報告列出六個來源，最後寫著：「A 服務支援資料匯出，適合這次整合。」審查者點進其中一個連結，看到登入畫面；另一個連結雖然能開，內容卻沒有說明匯出格式。

這是本文的虛構案例。Agent 沒有憑空造出網址，它確實搜尋到了結果。問題出在下一步：程式把搜尋回傳的摘要交給模型，模型便以讀過原文的口氣下結論。報告有六個連結，仍然缺少能支持選型的那一段證據。

DeepSeek 在 2026 年 10 月 17 日的公告 中，同時發布 DeepSeek-V4.1-Flash-1017，並開放 Search、Fetch API。對要做研究 Agent 的工程師，我認為最值得處理的是這個交界：找到來源後，系統必須知道自己究竟讀到了什麼，才准許把它寫進結論。

summary 很好讀，也最容易被當成原文

依 Search & Fetch 官方指南，Search 回傳結構化結果，Fetch 則取回單一網頁的 Markdown。兩者是獨立的 JSON API，端點分別是 /v1/tools/search 與 /v1/tools/fetch。

Search 的結果本身就有 snippet、summary 與 content。其中 summary 是供模型閱讀的較長摘要；need_content 預設為 false，此時 content 一律是空字串。即使要求內容，無法取得時仍可能是空字串。

因此，把 need_content 打開並不能省掉內容檢查。搜尋回應是 HTTP 200，也不能證明每一筆結果都有可供查核的原文。官方還明定，正常搜尋沒有符合結果時會回傳空陣列。

回到那份供應商報告，最小修改不需要換模型。我會在應用程式裡保留三種內部狀態：

  • discovered：找到網址與摘要，尚未取得可讀內容。可以列為研究線索，不能聲稱已查核功能。
  • content_received：拿到非空內容，保留來源 URL、取得時間，以及文字支持哪一項主張。仍需檢查頁面是否過時、是否只是登入提示或無關段落。
  • unavailable：這次沒有取得可用內容，留下回應碼與原因；報告應顯示資料缺口。

這些名稱是本文的設計建議，並非 DeepSeek 提供的回傳欄位。模型收到的資料也應保留這個區別，避免一份內容完整的文件與一筆搜尋摘要被壓成同一串「參考資料」。

Fetch 的 404，不足以宣判網站不存在

假設 A 服務的文件被 Fetch 回覆 404，程式下一步要做什麼？

一般網站的 404 容易讓人聯想到頁面不存在；但 DeepSeek 對 Fetch 的定義較廣。官方列出的原因包含 URL 無法使用、目標站政策阻擋、目標站錯誤、不支援的內容類型，以及沒有可擷取的 Markdown。403 則是 Fetch 請求被安全政策拒絕。錯誤定義見官方指南。

同一個回應碼可能對應不同原因。Agent 若直接寫「A 沒有提供匯出文件」，就把「工具這次讀不到」推成了「文件不存在」。若改成不斷重試，或換身分嘗試通過限制，又把調查工作變成存取控制問題。

這裡需要一條可以直接檢查的停止規則：403 或明確的政策拒絕停止存取；404 未能取得可用內容時，保留缺口，不把摘要升格成原文，也不繞過限制。

可以另找獨立公開的一手文件，例如供應商公開的 API 規格，但要記錄它是替代來源。若仍找不到，就將「匯出格式待確認」帶回選型報告。這會讓報告少一個肯定句，卻保住工程決策所需的誠實程度。

暫時失敗要走另一條路。官方建議 408、429 與 5xx 等待後重試；其他 4xx 不應在未修改請求時重試。應用程式可設退避、次數與總等待時間上限，若回應提供有效的 Retry-After 就遵守它。這是重試策略建議，並不表示 DeepSeek 保證每次都送出該標頭。401 應回報憑證問題，402 應回報餘額不足，都不該交給模型無限循環。

多開幾個 Worker，可能只會一起撞到 429

內容狀態分清後，團隊可能想把六份文件平行抓完。這時要看的數字是工具 API 限速，而非模型的並行能力。

截至 2026 年 10 月 18 日查核，官方指南寫的是每帳號 Search 5 QPS、Fetch 5 QPS，兩者額度獨立，與模型並行限制分開；換同帳號的 API key 仍共享各自額度。Fetch 另有每網域的 QPS 限制，但這份指南未列出該限制的數值。來源：Rate Limits。

我的最小方案會讓同帳號的工作共用兩個排程入口，分別控制 Search 與 Fetch，再讓 Fetch 依目標網域排隊。只在單一 Worker 裡設定每秒五次，無法約束其他 Worker。每網域額度未知，也不應假設它必然容許五次。

這份報告只有六個候選來源，可以先用保守的低併發處理。等到觀察到實際等待時間、429 與來源分布，再調整速率。此處沒有壓測結果，也沒有理由把官方上限直接當成穩定吞吐承諾。

取捨很直接：排隊讓部分任務晚一點完成，卻能避免所有任務同時重試，把有限額度消耗在碰撞上。報告的完成時間應有上限；期限到了仍讀不到，就交付有缺口的調查結果，而非讓背景工作一直跑。

便宜的搜尋，也需要一筆有範圍的帳

官方公告把 Search 與 Fetch 各標為每千次 0.75 美元；指南進一步限定，只有 HTTP 200 且產生結果的請求才計費：Search 的結果陣列須非空，Fetch 須取得頁面內容。失敗、空搜尋結果與逾時不計費。count 影響回傳筆數，不影響單次請求價格。來源：Billing。

以這份報告為教學假設：兩次有結果的搜尋，加六次取得內容的 Fetch，共八次計費請求，工具費為 8 ÷ 1000 × 0.75 = 0.006 美元。這不是實測帳單，也不包含模型 token、儲存與其他服務費。

同樣地，一次搜尋取回六個網址，不等於六次 Search 計費；後續若逐一 Fetch，才會各自產生請求。程式應記錄實際可計費成功數，並限制每份報告的總呼叫與重試預算。免費失敗仍會消耗時間與系統資源。

截至查核日，透過 DeepSeek Harness、Claude Code、Codex 使用 DeepSeek API 的指定伺服器端 Search／Fetch 工具呼叫暫時免費；官方宣布從 2026 年 10 月 31 日 16:00 UTC，也就是臺北時間 11 月 1 日 00:00 開始計費。這項優惠不能解讀成所有直接 API 呼叫或模型推論免費。正式上線前仍應重讀當時價格，避免把限時優惠寫死在成本模型裡。

報告可以少一個答案，不能多一個假裝查過的來源

那份供應商比較報告最後可以這樣交付：A 的匯出能力仍待確認；B 的公開文件提供了可核對的格式與限制。這會改變下一步，團隊可以先驗證 B，或請 A 提供正式文件，而不會依靠搜尋摘要開始串接。

下一次驗收研究 Agent，可以放入四個測試案例：正常內容、200 空搜尋結果、Fetch 404，以及連續 429。檢查報告是否保留來源缺口、是否在預算內停止、是否把暫時失敗與拒絕存取分開。這是本文提出的驗收方式，尚未實際呼叫 DeepSeek API 執行。

結論很窄，也很實用：搜尋能力接上後，下一個要實作的是「什麼資料有資格支持一句結論」。只要這條規則仍由模型自行猜測，多找幾個網址就只會讓報告看起來更有根據。