DeepSeek 自建搜尋引擎，AI Agent 的權力正在重新分配！當 OpenCode、Codex 都會搜尋，誰才是真正的指揮官？

一、DeepSeek 的新動作，揭露 AI 產業一場不容易察覺的變化

2026 年 10 月，DeepSeek 正式公開 Search API 與 Fetch API，讓開發者可以直接透過 API 搜尋網頁、擷取內容。

乍看之下，這似乎不是什麼突破性的技術。

畢竟，ChatGPT 可以搜尋網路，Claude Code 可以查資料，Codex 和 OpenCode 也都有自己的工具呼叫機制。

但如果站在企業 AI 技術主管的角度觀察，這件事情背後其實隱藏著一個重要訊號：

過去由 AI Agent 框架掌握的搜尋能力，現在正逐漸成為模型供應商自己提供的基礎設施。

這意味著，AI 產業的競爭不再只是誰的模型比較聰明，而是誰能掌握模型、工具、搜尋資料，以及整個 Agent 執行流程。

而這也帶出一個很有意思的問題：

當我們在 OpenCode 使用 DeepSeek 模型，要求它上網搜尋時，到底是 OpenCode 搜尋，還是 DeepSeek 搜尋？

如果兩邊都會搜尋，難道不會重複執行？

要理解這個問題，必須先拆開現代 AI Agent 的技術架構。

二、模型不是搜尋引擎，Harness 才是執行工作的關鍵

許多人對 AI Agent 有一個常見誤解，以為模型本身可以直接操作網路、讀取檔案，甚至執行程式。

實際上，大部分 LLM 並沒有這些能力。

模型主要負責理解、推理、規劃與生成內容。

真正讓模型可以操作外部世界的，是 Harness。

我們可以把它想像成一家公司的運作方式。

LLM 就像一位能力很強的技術顧問，知道應該做什麼，但沒有直接操作公司系統的權限。

Harness 則像技術部門的執行主管，負責管理工具、分派任務、執行操作，以及把結果交回顧問分析。

搜尋引擎則像情報研究部門，負責從外部世界取得最新資訊。

整體流程大致如下：

使用者提出問題 → Harness 將問題送給 LLM → LLM 判斷需要搜尋 → Harness 呼叫搜尋工具 → 搜尋結果返回 LLM → LLM 整理答案。

這個架構有一個非常重要的觀念：

LLM 可以決定需要搜尋，但真正發出搜尋請求的，不一定是 LLM 供應商。

而這正是理解 DeepSeek 新服務的關鍵。

三、DeepSeek 不只賣模型，也開始賣搜尋能力

根據 DeepSeek 2026 年 10 月公開的 API 文件，它提供兩個獨立服務。

第一個是 Search API，負責搜尋網頁，回傳標題、網址、摘要、相關性評分與其他結構化資料。

第二個是 Fetch API，負責讀取指定網址，將網頁內容轉換為 Markdown。

官方宣稱搜尋服務由自家搜尋引擎支援，而不是單純包裝一個 Google 搜尋介面。不過，公開資料仍不足以證明所有底層索引與資料來源都完全不依賴第三方。

真正值得注意的是，這兩個 API 可以獨立呼叫。

例如：

POST https://api.deepseek.com/v1/tools/search

開發者不必先呼叫 DeepSeek LLM，就能直接取得搜尋結果。

這代表搜尋服務與模型推論已經可以分開使用。

假設企業使用本地部署的 Qwen 模型，完全可以讓 DeepSeek Search API 負責蒐集網路資料，再交由 Qwen 分析。

換句話說：

DeepSeek 的搜尋引擎，不一定要搭配 DeepSeek 的模型。

這種架構讓企業有更多選擇，也讓 DeepSeek 從單純的模型供應商，進一步跨入 AI 工具基礎設施市場。

四、OpenCode 搭配 DeepSeek，會不會搜尋兩次？

這是整個議題最值得深入討論的地方。

假設開發者使用 OpenCode，模型選擇 DeepSeek，然後輸入：

「請上網搜尋最新的 Qwen 模型，並整理技術規格。」

這時候，OpenCode 會把使用者要求交給 DeepSeek 模型。

模型可能判斷需要使用搜尋工具，於是提出工具呼叫要求。

接著，OpenCode 依照自己的工具設定，執行搜尋。

OpenCode 的搜尋工具可以使用 Exa 等搜尋服務，並非因為選擇了 DeepSeek 模型，就自動改成 DeepSeek Search API。

因此，一般情況下，這是一條搜尋流程。

不是 OpenCode 搜尋一次，DeepSeek 又偷偷搜尋一次。

選擇哪一家 LLM，與選擇哪一家搜尋服務，是兩個不同的技術決策。

但事情還有另一種可能。

如果 DeepSeek API 的伺服器端搜尋功能也被啟用，而且 Agent 同時可以使用自己的搜尋工具，那麼系統就可能存在兩條搜尋路徑。

第一條由 OpenCode 執行。

第二條由 DeepSeek 的伺服器端工具執行。

如果兩者都被實際觸發，就可能產生重複搜尋。

不過，這不是必然現象，而是取決於工具設定、模型介面與執行流程。

五、Codex 與 DeepSeek Harness，情況又有什麼不同？

DeepSeek 自家的 Harness，理論上最容易整合自家搜尋服務。

但即使如此，也不能直接認定每次搜尋都一定使用 DeepSeek Search。

因為 Harness 本身可以支援不同搜尋後端，實際使用哪一個，仍然取決於配置。

Codex 的情況更加值得關注。

Codex 原本就有自己的工具執行環境。如果將模型後端改為相容的 DeepSeek API，Codex 仍然可能使用自己管理的搜尋工具。

但 DeepSeek 官方文件也指出，透過特定 Harness、Claude Code 或 Codex 整合方式，伺服器端工具呼叫可能使用 DeepSeek 的 Search 與 Fetch 服務。

這意味著，搜尋權限的邊界開始變得複雜。

過去我們習慣認為：

Harness 負責工具，LLM 負責思考。

現在則可能變成：

Harness 有工具，模型供應商也有工具。

兩者之間的職責開始重疊。

從企業系統設計角度來看，這不一定是壞事，但必須建立明確的管理規則。

否則，開發團隊可能連自己的 AI 系統究竟呼叫了哪個搜尋引擎，都無法準確回答。

六、搜尋價格降低，企業真正要管理的是執行成本

DeepSeek 公開的定價相當具有競爭力。

Search API 每 1,000 次成功請求收費 0.75 美元。

Fetch API 也是相同價格。

換算下來，每次成功搜尋約 0.00075 美元。

如果一個企業系統每月執行 10 萬次搜尋，搜尋 API 費用約為 75 美元。

但這只是搜尋成本。

實際 Agent 工作流程還可能包含多次網頁擷取、模型推論、長上下文處理，以及反覆驗證。

假設一個研究任務執行五次搜尋，讀取二十個網頁，再由 LLM 進行分析，總成本就不能只看搜尋 API 的單價。

更重要的是，如果 Harness 與模型供應商各自執行相似搜尋，還可能造成不必要的重複請求。

因此，企業技術主管應該要求團隊建立完整的工具呼叫紀錄。

至少要能追蹤每次搜尋由誰發起、使用哪個搜尋後端、取得多少資料、耗費多少時間，以及產生多少費用。

未來 AI 系統的成本控制，不只是 Token 管理，更是工具調度管理。

七、站在技術主管角度，我會如何設計企業 AI 架構？

如果今天要為企業建立一套長期運作的 AI Agent 平台，我不會讓每個 Agent 自由選擇不同搜尋引擎，卻缺乏統一管理。

我會設計一個獨立的 Search Gateway，也就是搜尋服務閘道。

所有 AI Agent，包括 OpenCode、Codex、自建 Agent 或內部 RAG 系統，都盡可能透過統一介面取得外部資料。

搜尋閘道再依照需求，決定使用 DeepSeek Search、Exa、其他搜尋服務，或企業內部知識庫。

這樣做有四個好處。

第一，可以集中管理 API Key 與搜尋成本。

第二，可以建立快取機制，避免不同 Agent 重複搜尋相同資料。

第三，可以依照搜尋品質、語言與時效性，自動選擇合適的供應商。

第四，可以保留完整的搜尋紀錄，方便資安稽核與問題追蹤。

但還有一個必要條件：必須確認模型供應商的伺服器端工具是否啟用。

否則，即使建立 Search Gateway，也可能有部分搜尋繞過企業自己的管理機制。

這就像公司已經設置統一採購部門，卻允許員工私下使用其他採購管道。

短期可能方便，長期卻不利於成本與風險控制。

八、下一場 AI 競爭，不只是模型能力，而是誰掌握工具執行權

DeepSeek 開放 Search 與 Fetch API，表面上只是新增兩個服務。

但從產業發展來看，它反映的是 AI 基礎設施正在重新整合。

模型供應商希望提供更多工具能力。

Harness 開發者希望掌握 Agent 的執行流程。

搜尋服務商希望成為 AI 取得外部知識的主要入口。

企業開發者則希望保留選擇權，不被單一平台綁定。

這幾種力量正在同時發展。

未來我們可能看到更多模型供應商直接提供搜尋、程式執行、資料擷取與其他伺服器端工具。

但這不代表 Harness 會消失。

相反地，當工具越來越多，Harness 在權限管理、任務協調、執行監控與錯誤恢復方面的重要性，反而可能提高。

從資深技術主管的角度，我認為最重要的不是選擇哪一家搜尋引擎，而是企業是否真正掌握整個 AI 執行流程。

誰決定搜尋？誰執行搜尋？誰支付費用？誰驗證結果？誰承擔安全責任？

這五個問題，將成為未來企業 AI Agent 架構設計的核心。

DeepSeek 這次的新服務，讓我們看見一個值得注意的方向：

AI 的競爭正在從「誰擁有最聰明的大腦」，走向「誰能有效率地調度整個數位世界」。

而真正成熟的企業 AI 系統，不應該把所有能力綁死在單一模型或單一 Harness 上。

它應該能自由更換模型、搜尋服務與執行工具，同時保留統一的治理與監控能力。

這才是企業在 AI Agent 時代，真正值得長期投資的技術架構。

技術參考：DeepSeek API Search & Fetch 官方文件、DeepSeek Harness GitHub、OpenCode 官方工具文件。本文以 2026 年 10 月公開資訊為基礎，實際工具調用行為仍須依各版本與部署設定驗證。