模型要上網，長期只有兩條路：綁死特定 provider 的原生搜尋工具，或在 client 端自己接搜尋與抓取 API，再處理各家 schema 的差異。OpenRouter 發布的 agentic web tools 給出第三條路：openrouter:web_search 與 openrouter:web_fetch 兩個 server tools，任何 model 都能在單一 request 內呼叫，搜尋目標頁面、抓回內容，再自己綜合出答案。
關鍵差異有兩層。執行位置：工具由 OpenRouter 在 server 端執行、結果直接回傳給 model，client 端不需要任何實作。一致性：tool 定義、呼叫方式與結果格式在所有支援 tool calling 的 model 間完全一致——換 model 不必換工具，這是路由平台做工具層的自然優勢。
從外掛到 agentic 工具：誰來決定搜尋
OpenRouter 先前的 web search plugin 是被動的：每個 request 固定執行一次搜尋，不管任務需不需要，model 對搜尋時機與 query 都沒有發言權。新的 server tools 把決策權交還給 model——同一個 request 內可以搜尋 0 到 N 次，query 與時機都由 model 依任務自行判斷。要比價三家雲端 GPU 供應商，model 可以自己發出三次不同 query 的搜尋再彙整。搜尋次數從固定常數變成模型決策，這正是 agentic 的分界線。
Server-side 執行，client 零實作
工具宣告只需要一次 {"type": "openrouter:web_search"}。過去換 provider 就得重寫 tool 定義與結果 parser，還不保證行為一致——例如嚴格執行的 blocked domains 在某些原生工具裡根本不存在。現在這層抽象把工具能力從 provider 差異中剝離：要行為也一致，指名 Exa 或 Parallel 當 engine，無論 request 最後路由到哪個 model，回給 model 的結果都相同。
Web Search：四種 engine 與計價
| Engine | 行為 | 計價 |
|---|---|---|
| Auto（預設） | provider 支援時用 native，否則用 Exa | 依實際 engine |
| Native | provider 內建搜尋 | provider 計價 |
| Exa | 搜尋交給 Exa，從 OpenRouter credits 扣款 | 每次 $0.005（含最多 10 筆），加筆 $0.001 |
| Parallel | 搜尋交給 Parallel，同樣走 credits | 每次 $0.005（含最多 10 筆），加筆 $0.001 |
四種 engine 的分工：Auto 在 provider 支援時用 native search，否則退回 Exa；要跨 model 一致、要可控計價，就指名 Exa 或 Parallel，兩者同價，差別只在搜尋由誰執行。只有 Exa 與 Parallel 支援 search_context_size（結果 context 的大小），native engine 會忽略這個參數；多數 engine 也支援 allowed_domains 與 excluded_domains 做網域過濾。文件給的範例直接可用：max_results 設 5、allowed_domains 限定 arxiv.org 與 nature.com、search_context_size 拉到 high，就是一個只讀學術來源的高 context 研究設定。
Web Fetch：五種 engine，有免費選項
Fetch 的典型用法是接在搜尋後面：model 先用 web_search 找到候選頁面，再用 web_fetch 取回完整內容，兩個工具在同一個 request 裡串成一條研究動線。
| Engine | 行為 | 計價 |
|---|---|---|
| Auto（預設） | provider 支援時用 native，否則用 Exa | 依實際 engine |
| Native | provider 內建抓取 | provider 計價 |
| OpenRouter | OpenRouter 直接 HTTP fetch | Free |
| Exa | content extraction 與 clean markdown 輸出 | 每次 $0.001 |
| Parallel | Parallel 的 extract API | 每次 $0.001 |
fetch 端多了一個 OpenRouter 自家 engine：直接 HTTP fetch、定價 Free，是成本敏感場景的起點。Exa 與 Parallel 每次 $0.001，提供內容抽取與乾淨的 markdown。指名 Exa、Parallel 或 OpenRouter 任一個，就能跨 model 一致地用 allowed_domains 與 blocked_domains 限制可抓取的 URL——native fetch 能力在不同 model 間並不一致，需要參數被尊重就選這三個。
成本與 context 的控制參數
agentic loop 裡真正的風險不是單次費用，而是次數乘以 context。兩個參數值得寫進預設值：max_total_results 限制單一 request 內所有搜尋的累積結果數，達到上限時 model 會收到限額訊息，而不是再發一次搜尋；max_content_tokens（文件範例為 50000）限制 model 收到的內容 token 數，避免一個大頁面吃掉半個 context window。以實際數字感受量級：比較三家 GPU 供應商的任務，若 model 對每家各發一次搜尋、每次 max_results 是 5，累積就是 15 筆結果；把 max_total_results 設在 15，任務的搜尋邊際成本就被鎖住了。
從 plugin 遷移：一行改動與相容性紅線
"plugins": [{ "id": "web" }] → "tools": [{ "type": "openrouter:web_search" }]遷移本身只需把 request body 的 plugins 換成 tools，官方也提供了完整的遷移指南。紅線在 model 相容性：server tools 需要支援 tool calling 的 model；不支援的 model 只能續用舊 plugin——代價是回到每個 request 固定一次搜尋的被動模式。
取捨與限制
這是 server-side 工具，執行不在你手裡：不能跑自訂 JavaScript，不能在 client 端處理 redirect。內容被 max_content_tokens 截斷時，model 拿到的就是截斷後的版本，重要資訊若在頁尾會遺漏。成本上，agentic loop 中 model 可能連續搜尋多次，Exa 與 Parallel 單價不高，但乘上行為次數後需要監控；native engine 的計價由 provider 決定，跨 provider 比較時要分開算。另一個實務細節是帳務位置：Exa 與 Parallel 的計費走 OpenRouter credits，費用集中在一份紀錄；native engine 的費用落在 provider 帳單，成本可見性分成兩處。
Builder 建議
三個可直接落地的起手式：第一，先用 OpenRouter fetch engine（Free）驗證流程，再依內容品質需求升級到 Exa 的 clean markdown；第二，把 max_total_results 與 max_content_tokens 設為預設值，讓成本與 context 用量可預測；第三，用 allowed_domains 把搜尋與抓取限制在可信網域，反向的 blocked_domains 則把內部網域排除——文件範例正是用它擋掉 internal.example.com——這在對外提供 agent 服務時同時是安全邊界。Chatroom 介面的工具圖示可以直接開啟這兩個工具，API 則照上表參數設定。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。