O

multi-search-engine

作者 openclaw

multi-search-engine 是一款用於 Web Research 的搜尋技能,支援 17 種搜尋引擎、進階運算子、時間篩選、重視隱私的搜尋選項,以及 WolframAlpha 查詢。它可協助代理程式在不需 API key 的情況下,更有效地建立並執行搜尋 URL。

Stars3.8k
收藏0
評論0
加入時間2026年4月5日
分類Web 研究
安裝指令
npx skills add openclaw/skills --skill multi-search-engine
編輯評分

這個技能評分為 70/100,代表對於想要輕量、免 API 的搜尋 URL 工具包的目錄使用者而言,具備上架價值,但也應預期仍需自行做出部分執行判斷。該儲存庫清楚整理了 17 種搜尋引擎、URL 模式與進階運算子的範例,因此代理程式比起依賴泛用提示,更能穩定地觸發使用。不過,它本質上仍偏向文件與 URL 參考型技能,而不是具備決策規則、限制條件或自動化支援的完整工作流程。

70/100
亮點
  • 在 SKILL.md/config.json 中整理了 17 個明確的引擎端點,對使用 web_fetch 類工具的代理程式而言,觸發方式相當直接。
  • 提供基本搜尋、站內搜尋、隱私導向搜尋與進階運算子搜尋的實用範例,另附 Google 風格深度搜尋語法的參考指南。
  • 不需要 API keys,可降低採用門檻,也讓安裝用途更容易理解。
注意事項
  • 此技能沒有 scripts、安裝指令或可執行輔助工具,因此使用者實際上安裝的主要是搜尋 URL 模式與文件,而非可重複使用的自動化能力。
  • 在引擎選擇、fallback 行為、rate limits/封鎖情況,以及解析預期等操作指引方面著墨較少,因此代理程式在真實瀏覽情境中,仍可能需要透過反覆嘗試來調整。
總覽

multi-search-engine skill 概覽

multi-search-engine 實際上能做什麼

multi-search-engine skill 為 agent 預先整理好 17 個搜尋引擎的搜尋 URL 模式,涵蓋中文與全球網頁研究情境,並附上進階運算子範例與直接使用 web_fetch 的方式。它特別適合已經具備瀏覽能力、想在不使用 API keys 的前提下,更快擴大搜尋面與探索範圍的人。

最適合用於 Web Research 的情境

當單一搜尋引擎不夠用時,就很適合用 multi-search-engine 來做 Web Research:例如交叉比對不同地區的收錄差異、找出預設索引沒那麼容易看到的頁面、執行 site:filetype: 查詢,或切換到像 DuckDuckGo、Startpage、Brave 這類偏重隱私的搜尋引擎。它也納入了 WolframAlpha,可用來處理一般網頁搜尋不擅長的事實查詢或計算型問題。

為什麼使用者會安裝它,而不是手動寫提示

這個 skill 的真正價值,不只是「可以搜尋網頁」,而是「降低組搜尋語句時的摸索成本」。它把各搜尋引擎的端點、地區選項與運算子範例集中在同一處,讓 agent 可以更快把像「找出 EU 監管機構最近發布的 PDF 報告」這種模糊需求,轉成具體可執行的搜尋。它不需要 API keys,但你的執行環境必須能開啟或抓取搜尋結果頁面。

安裝前要先知道的主要取捨

這個 multi-search-engine skill 很輕量,並不是完整的搜尋協調器。它不會幫你做來源排序、結果去重,也不保證能繞過 bot protection。部分搜尋引擎的頁面呈現方式也可能隨時間改變,而搜尋品質仍然高度取決於 query 寫得好不好。如果你要的是一套實用的搜尋 URL 工具箱,它值得安裝;如果你需要的是受管理的搜尋 API 或自動化爬取流程,就不太適合。

如何使用 multi-search-engine skill

安裝情境與優先閱讀的檔案

安裝方式:
npx skills add openclaw/skills --skill gpyangyoujun/multi-search-engine

安裝後先讀 SKILL.md,了解搜尋引擎清單與範例呼叫方式;再看 config.json,確認正式定義的 engine 設定;接著讀 references/international-search.md,這份檔案對高價值運算子與時間篩選的用法最有幫助。metadata.json 則可用來確認目前範圍:共 17 個搜尋引擎,且不需要 API key。

這個 skill 需要哪些輸入

multi-search-engine skill 在你的提示包含以下資訊時,效果最好:

  • 主題或明確實體
  • 目標地區或語言
  • 時效要求
  • 來源類型,例如新聞、文件、論壇、PDF 或官方網站
  • 若有需要排除的內容,也要一併寫明

弱目標:「Research AI policy.」

強目標:「Use multi-search-engine to find English and Chinese sources on 2025 AI safety regulation, prioritize official sites and PDFs, include results from Google, Bing INT, Baidu, and DuckDuckGo, and prefer the last 12 months.」

如何把模糊目標改寫成可用提示

不要只叫 agent 跑一個籠統搜尋,而是要求它產生並執行多組 query 變體。好的 multi-search-engine 使用提示,會像這樣:

“Use the multi-search-engine skill for Web Research. Create 6 search queries for this goal: compare open-source vector databases for on-prem deployment. Include site:github.com, site:docs.*, and filetype:pdf variants, run them across Google, Brave, and DuckDuckGo, and summarize overlaps, unique findings, and missing evidence.”

這種寫法之所以有效,是因為它清楚指定了搜尋引擎、query 類型、來源偏向,以及預期要產出的整合結果。

實際工作流程與品質建議

先廣後窄:

  1. 先在一個全球型與一個區域型搜尋引擎上,各跑 2 到 3 組偏廣泛的探索查詢。
  2. 從結果中抽出精確的產品名稱、作者、網域名稱或檔案格式。
  3. 再用 site:filetype:、引號、排除條件與時間篩選重新搜尋。
  4. 對於看起來出乎意料的說法,用第二個搜尋引擎交叉驗證。

實用建議:

  • 想要廣泛召回時,優先用 GoogleBing INT
  • 如果中文平台覆蓋率很重要,可用 BaiduSogouWeChat
  • 如果你想看不同排序邏輯,或偏好隱私導向結果,可用 DuckDuckGoStartpageBrave
  • WolframAlpha 適合可計算的問題,不適合拿來做文件探索。

multi-search-engine skill 常見問題

multi-search-engine 會比一般的 web search prompt 更好嗎?

通常會,尤其是在結構化研究任務中。一般 prompt 常把搜尋引擎選擇與 query 設計留在暗處,不明講;multi-search-engine skill 則把這些選擇明確化,因此能提升涵蓋率與可重複性,特別適合多語研究、限定站內搜尋,以及有時間範圍的事實查找。

它對新手友善嗎?

算友善,前提是你已經理解基本搜尋運算子,或願意直接照著範例使用。這個 skill 本身很簡單,因為它主要提供的是搜尋 URL 樣板與 query 模式。不過新手仍可能需要學會什麼時候該用引號、site:filetype: 或排除條件,才能避免結果太雜。

什麼情況下不適合用?

如果你需要穩定可保證的 scraping、官方 API SLA,或自動彙整搜尋結果,就不應依賴這個 multi-search-engine skill。它也不適合處理封閉資料庫、需要登入才能看的內容,或那些「直接萃取來源內容」比「先做發現與搜尋」更重要的任務。

一開始應該先試哪些搜尋引擎?

一般英文研究:GoogleDuckDuckGoBrave
全球與中國導向混合探索:Bing INTBaiduSogouWeChat
文件與官方出版物:先用 Google 搭配 site:filetype:pdf
計算型事實查詢:WolframAlpha

如何改進 multi-search-engine skill 的使用效果

為 multi-search-engine 加上更明確的限制條件

搜尋結果好不好,很大程度取決於搜尋框架設得夠不夠清楚。請明確指定地理範圍、日期區間、內容類型與信任偏好。「Find startup funding news」太弱;「Use multi-search-engine to find venture funding announcements for robotics startups in Japan since Jan 2025 from company blogs, TechCrunch-like outlets, and official filings」就強得多。

用運算子驅動的 query 組合,不要只做單次搜尋

最常見的失敗模式,就是跑完一個寬泛 query 就停下來。更好的做法是直接要求一組 query pack:

  • 使用引號的精確比對 query
  • 針對已知網域的 site: query
  • 尋找報告的 filetype:pdf query
  • 用來去除雜訊的排除 query
  • 聚焦近期資訊的時間篩選 query

這也是這個 skill 的參考資料,真正能超出「只快速翻一下 repo」價值的地方。

處理常見的品質問題

如果結果太少,先換搜尋引擎,再考慮重寫整個任務。
如果結果太雜,加入引號、排除條件與網域限制。
如果主題有明顯地域性,就改用對應地區的搜尋引擎與語言。
如果任務偏分析、不是找文件,應把其中一部分導向 WolframAlpha,而不是硬把所有內容都塞進一般搜尋。

第一輪之後要再迭代

第一輪使用 multi-search-engine 之後,請要求 agent 列出:

  • 哪些搜尋引擎找到了獨特來源
  • 哪些地方的結果高度重複
  • 冒出了哪些新的關鍵詞
  • 還缺少哪些證據

接著再用第一輪發現的新術語、組織名稱與檔案類型跑第二輪。通常也是到第二輪迭代時,這個 skill 才會明顯比一般瀏覽型 prompt 更有價值。

評分與評論

尚無評分
分享你的評論
登入後即可為這項技能評分並留言。
G
0/10000
最新評論
儲存中...