AI Search Hub：把八個大廠 AI 搜尋入口接進你的 Agent
One Query. All Search Skill. 聚合 Gemini、Grok、豆包、元宝等平台原生 AI 搜索能力，免费获取科技趋势、行业舆情、热点追踪、旅行规划、日常问题统一接进自己的 Agent 与工作流，指定链接免费爬取
秒懂
- 它是什麼？
- 這個 Python Skill 不自己寫爬蟲，而是透過瀏覽器自動化借用 Gemini、Grok、豆包、元寶等平台的原生搜尋與網頁抽取能力，再把結果回收給 Agent。核心判斷：它省下的是平台對抗成本，換來的是對瀏覽器登入狀態的長期依賴。
- 適合誰用？
- 如果你已經有 OpenClaw、Claude Code 或 Cursor 這類 Agent 環境，而痛點正好是微信公眾號、抖音、微博這類難以自建爬蟲的入口，AI Search Hub 值得先裝起來驗證一條鏈路。若你需要的是穩定 SLA、可審計的資料管線，或無法接受瀏覽器登入狀態成為執行前提，這個專案目前不適合你。
- 可以商用嗎？
- 未經許可不行。GitHub 在這個儲存庫中沒有找到授權檔案；沒有授權，預設即「保留所有權利」：你可以閱讀程式碼，但不能重複使用。使用前請看看 README，或先取得作者同意。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 142 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要取代的不是搜尋 API，是你自己養的那批爬蟲
多數團隊做輿情或趨勢追蹤時，真正消耗人力的不是查詢本身，而是入口。微信公眾號、抖音、微博、B 站的內容，公開網頁上抓不到完整正文，自己寫解析規則又要面對版面改版。AI Search Hub 的定位是把這件事外包給已經在對抗這些入口的公司：README 開頭寫得很直白，它想讓你不用再維護「一堆脆弱爬蟲和網頁解析規則」，也不用「反復登錄、驗證碼、限流、風控處理」。
目標使用者因此相當明確。已經在用 OpenClaw、Claude Code、Codex CLI、Cursor、Kiro、Antigravity 或 OpenCode 的人，可以把這個 Skill 當成一個搜尋與抽取的後端；需要跨平台比對中文內容的人，可以用一次提問分發到多個平台。反過來說，如果你的資料來源本來就有官方 API 且額度充足，這個專案解決的不是你的問題。
瀏覽器驅動：資料流是提問、分發、回收三段
README 的標籤把模式寫成 browser-driven，這是理解整個架構的關鍵。它不是呼叫各家廠商的搜尋 API，而是驅動瀏覽器去操作這些平台既有的搜尋介面。資料流大致是三段：你送出一個查詢，Skill 把它分發到多個已接入平台；各平台用它自己已經調校過的排序與理解邏輯執行搜尋、抓取與清洗；最後結果被統一回收，交回你的 Agent 或工作流。
這個設計的取捨很明顯。好處是搜尋品質站在平台既有成果上，README 也強調「複用平台已有的排序、理解和體驗」，你不需要自己調關鍵詞與檢索策略。代價是整條鏈路的穩定性取決於外部網頁介面，以及你的瀏覽器登入狀態。當平台改版、加驗證或調整風控，受影響的是你的執行環境，而不是某個可以重新協商的 API 合約。
連結抽取走的是同一條路。README 說明給它一個連結，它會借力平台做網頁理解與正文抽取，包括去廣告、去噪、提重點與結構化整理，再回傳給 Agent。換句話說，清洗工作也一併外移了。
已接入的八個平台，各自補的是不同的資料缺口
README 列出的當前接入清單是 Gemini、Grok、豆包、元寶、LongCat、通義千問、MiniMax、Kimi，並附了一張擅長方向與典型覆蓋的對照表。這張表比平台數量本身更有參考價值，因為它暗示了分發策略：你不會對每個查詢都跑滿八家。
Gemini 對應 Google 搜尋與公開網頁發現；Grok 對應 X 與 Twitter 的即時動態與熱點討論；豆包對應抖音與中文內容生態；元寶被標為中文補充檢索與公眾號信源，同時承擔內容交叉驗證；LongCat 偏中文知識與行業報告的結構化總結；通義千問做中文網頁與搜索入口的擴展。MiniMax 與 Kimi 在提供的材料中被截斷，只能確認它們在接入清單內，具體擅長方向無法從現有內容判斷。
實務上這意味著選平台要看查詢類型。追蹤海外科技趨勢與 Grok 的即時社群訊號是兩件事，前者偏 Gemini，後者偏 Grok；中文生態的熱點與公眾號文章則落在豆包與元寶。把八家全部打開只會讓回收與比對的負擔變重。
安裝與執行：Skill 形態決定了你怎麼開始
README 沒有提供 pip 安裝指令，也沒有列出環境變數或設定檔的鍵名。它把自身定位為 open-source skill，並以 Claude Code、Codex CLI、Cursor、Kiro、OpenClaw、Antigravity、OpenCode 的徽章標示可掛載的宿主環境。因此取得方式就是從 GitHub 倉庫取得內容，放進對應 Agent 的 skill 目錄，由宿主負責觸發。
這一點必須說清楚：由於材料中沒有安裝章節、沒有依賴清單、沒有設定鍵，任何具體的安裝命令或 config key 都是我無法查證的。倉庫首頁欄位為空，也沒有檢索到任何 release，所以沒有版本化的安裝途徑可參考。Language 欄位標示為 Python，這是目前唯一能確認的技術棧資訊。
要驗證能不能跑，最實際的做法是先把範圍縮到單一平台：選一個你本來就有帳號、且已在接入清單中的平台，確認瀏覽器登入狀態可用，再觀察一次查詢能否完整走完分發與回收。確認單條鏈路成立後，才值得擴到多平台。
真正的成本在登入狀態，不在程式碼
這個專案把風控處理外移給平台，但不代表風控消失，只是換了位置。Browser-driven 意味著執行時需要可用的瀏覽器與已登入的會話。當平台要求重新驗證、觸發限流，或調整搜尋介面的互動方式，失敗會出現在你的執行環境裡，而不是回傳一個帶錯誤碼的回應。
除錯難度也隨之上升。API 呼叫失敗時你能看到狀態碼與訊息；瀏覽器自動化失敗時，你面對的是頁面沒載完、選擇器失效、或會話過期這類症狀。README 沒有描述重試策略、逾時設定或失敗回報格式，這些在正式導入前都是未知數。
另一個容易被忽略的限制是平台覆蓋範圍會變。接入清單與狀態欄位由維護者更新，平台的介面與政策則由外部公司決定。這代表這個 Skill 的可用性不是你能控制的變數，你只能控制自己對它的依賴程度。
跟自建爬蟲與官方 API 的差異，差在誰承擔維護
最直接的替代方案是自己寫爬蟲，用 requests 加解析器處理公開網頁。差異在維護歸屬：自建方案讓你能完全控制抓取頻率、欄位與儲存格式，但微信公眾號、抖音這類入口的正文取得與反爬對抗要你自己承擔，改版時也是你自己修。AI Search Hub 把這段轉嫁給平台，代價是你拿到的是平台整理後的結果，而非原始資料。
另一個方向是直接用各家廠商的官方 API。這條路換來的是穩定合約、明確配額與可預期的錯誤處理，但你得逐家申請、逐家對接，而且官方 API 能觸及的資料範圍與平台自家搜尋產品不一定相同。README 強調的正是後者：平台原生搜尋能力，以及它們「更容易觸達的數據」。
所以選擇不是誰比較強，而是你要把維護成本放在哪一側。要原始資料與可審計性，自建或官方 API 更合適；要快速取得中文平台入口的整理後結果，這個 Skill 的槓桿才成立。
授權與維護：目前最需要先確認的兩件事
倉庫的 License 欄位在提供的資料中是 unknown，但 README 的徽章區塊標示 MIT License。兩者不一致，而這不是可以自行推定的問題。在倉庫根目錄出現 LICENSE 檔案之前，採用者應該把它當成授權未定，尤其是要放進商業工作流的情況。這裡不構成法律意見，只是指出事實上的落差。
維護節奏方面，最後推送時間為 2026-04-27，沒有檢索到任何 release，也沒有版本標籤可依賴。這表示升級不會是「換一個版本號」這麼簡單，你得自己追蹤主線變更，並承擔平台介面變動帶來的非預期中斷。
README 中提到的商業調研產品 notyet.chat 與本專案並列展示。這本身不影響使用，但值得留意維護者的注意力分配。若你要長期依賴這條鏈路，先確認 LICENSE 狀態與你需要的平台是否仍在接入清單內，再決定投入程度。
編輯結論
如果你已經有 OpenClaw、Claude Code 或 Cursor 這類 Agent 環境，而痛點正好是微信公眾號、抖音、微博這類難以自建爬蟲的入口，AI Search Hub 值得先裝起來驗證一條鏈路。若你需要的是穩定 SLA、可審計的資料管線，或無法接受瀏覽器登入狀態成為執行前提，這個專案目前不適合你。動手前先確認三件事：倉庫是否已補上 LICENSE 檔案、README 中對各平台登入與風控的說明是否足夠、以及你打算使用的平台是否真的在已接入清單內。授權狀態未明之前，商用前請直接向維護者確認。
社群筆記