AI Search Hub : un Skill qui délègue la recherche à huit plateformes et récupère le résultat
One Query. All Search Skill. 聚合 Gemini、Grok、豆包、元宝等平台原生 AI 搜索能力，免费获取科技趋势、行业舆情、热点追踪、旅行规划、日常问题统一接进自己的 Agent 与工作流，指定链接免费爬取
En bref
- De quoi s’agit-il ?
- Le dépôt minsight-ai-info/AI-Search-Hub orchestre Gemini, Grok, 豆包, 元宝 et quatre autres plateformes pour exécuter une requête ou extraire une page, puis renvoie une sortie unique vers votre agent. Le point à trancher n'est pas la fonctionnalité mais la dépendance : rien ne fonctionne sans navigateur ni session ouverte sur chaque plateforme.
- À qui s’adresse-t-il ?
- AI Search Hub convient à un développeur qui possède déjà un compte sur plusieurs de ces plateformes et veut un point d'entrée unique pour la recherche et l'extraction de liens dans son agent. Il ne convient pas à un pipeline serveur sans navigateur, ni à un usage où chaque appel doit être traçable et reproductible.
- Puis-je l’utiliser commercialement ?
- Pas sans autorisation. GitHub ne trouve aucun fichier de licence dans ce dépôt, et sans licence tous les droits sont réservés par défaut : vous pouvez lire le code, mais pas le réutiliser. Consultez le README ou demandez l’accord des auteurs avant de l’utiliser.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 142 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : la collecte, pas la recherche
Le README énumère ce que l'auteur ne veut plus maintenir : des crawlers fragiles, une automatisation de navigateur par plateforme, les cycles de connexion et de captcha, la gestion du rate limiting, l'extraction du corps de page, le nettoyage et la mise en forme, puis l'assemblage manuel des morceaux. La cible est donc l'ingénieur qui doit alimenter un agent en informations provenant de sources chinoises et internationales, et qui a déjà constaté que le scraping direct coûte plus cher en entretien qu'en développement.
La formulation du dépôt est explicite sur la division du travail : « 给一个问题，让这些平台替你搜；给一个链接，让这些平台替你抓 ». Autrement dit, la recherche et l'extraction ne sont pas réimplémentées, elles sont sous-traitées aux interfaces que ces plateformes exposent déjà. Le projet se présente comme un Skill, pas comme un service : il s'installe dans un hôte qui sait exécuter des Skills, et il n'existe pas de démon autonome décrit dans le matériel fourni.
Le périmètre couvert est volontairement asymétrique. Gemini est positionné sur la découverte web au sens large, Grok sur X et Twitter en temps réel, 豆包 sur l'écosystème de contenu chinois, 元宝 sur les sources WeChat. Ce découpage est un choix éditorial du README, pas une garantie contractuelle : rien dans le matériel ne documente la méthode exacte par laquelle chaque plateforme atteint ces sources.
Architecture réelle : un navigateur piloté, pas une API
Le badge le plus informatif du README est celui-ci : Mode browser-driven. Le projet ne s'appuie pas sur des clés d'API officielles mais sur des sessions de navigateur ouvertes sur les interfaces web des plateformes. Cela explique la promesse de gratuité et l'absence de configuration de quota : vous consommez ce que votre compte personnel consomme déjà.
Le flux décrit est le suivant. Une requête entre par le Skill, elle est distribuée vers les plateformes retenues, chacune exécute sa propre recherche dans sa session, et les résultats reviennent pour être agrégés en une sortie unique destinée à l'agent ou au workflow appelant. Le second mode prend une URL en entrée et délègue l'extraction du contenu à la plateforme, qui se charge de retirer la navigation, la publicité et le bruit avant de restituer une version structurée.
Les huit plateformes annoncées comme intégrées sont Gemini, Grok, 豆包, 元宝, LongCat, 通义千问, MiniMax et Kimi. Le README les présente comme « 当前编排的核心搜索入口 », ce qui signifie qu'elles sont dans le chemin d'exécution principal et non en option. Aucun schéma d'architecture, aucun diagramme de séquence et aucune description du format d'échange entre le Skill et les plateformes ne figurent dans le matériel fourni. C'est la principale zone d'ombre du dépôt : on sait ce qui entre et ce qui sort, pas comment les résultats intermédiaires sont normalisés.
Mise en route : ce que le README documente et ce qu'il omet
Le dépôt cible explicitement plusieurs hôtes : Claude Code, OpenAI Codex CLI, Cursor, Kiro, OpenClaw, Google Antigravity et OpenCode. Le vocabulaire employé dans le corps du texte reste centré sur OpenClaw, ce qui suggère que c'est l'intégration de référence, mais le README ne tranche pas.
Le problème est là. Le matériel fourni ne contient aucune commande d'installation, aucune clé de configuration, aucun exemple d'appel. On ne peut donc pas écrire ici un `git clone` suivi d'une commande d'activation sans inventer. Ce que l'on peut affirmer : le dépôt est en Python, la branche par défaut est main, le dernier push date du 27 avril 2026, et la page d'accueil du projet n'est pas renseignée. La structure attendue d'un Skill impose en général un fichier de manifeste et un répertoire de ressources, mais le contenu réel du dépôt n'est pas visible dans le matériel transmis, donc je m'abstiens de le décrire.
Un point pratique en revanche est certain : puisque le mode est browser-driven, la première exécution impliquera une connexion manuelle sur chaque plateforme retenue. Tant que la session tient, les appels suivants réutilisent les cookies. Quand elle tombe, il faut rouvrir un navigateur et se reconnecter. Ce cycle est le vrai coût d'exploitation du projet, et il n'est pas chiffré dans le README.
La gratuité a une contrepartie : le navigateur et la session
C'est la limite structurante du projet, et elle découle directement du choix browser-driven. Un Skill qui pilote un navigateur ne tourne pas dans un conteneur sans affichage, ni dans une fonction serverless, ni dans un job CI qui s'exécute la nuit sans intervention. Il lui faut un environnement avec navigateur, et un état de session persistant entre les exécutions.
Le README présente cela comme un avantage : « 尽量沿用平台已有入口 », moins de lutte contre les mécanismes anti-bot. C'est exact à court terme. À moyen terme, la situation s'inverse. Vous ne contrôlez ni la mise en page des interfaces, ni la fréquence des changements de sélecteurs, ni les règles de détection. Une modification de l'interface de 豆包 ou de 元宝 peut casser le chemin d'extraction sans préavis, et le dépôt ne publie aucune release permettant de savoir quand cela arrive.
Il y a un second point, moins technique. Le README revendique l'accès à des données WeChat, Douyin et Weibo « 通过大厂 AI 平台 ». Cela signifie que la collecte passe par le compte personnel de l'utilisateur sur ces plateformes, avec les conditions d'utilisation qui s'y appliquent. Le dépôt n'aborde pas ce sujet, et je ne peux pas dire ce que ces conditions autorisent. C'est un point à vérifier avant tout usage en production, pas après.
Ce que le projet n'est pas : comparaison avec une API de recherche classique
L'alternative la plus directe n'est pas un autre agrégateur de Skills, c'est une API de recherche commerciale : Brave Search API, Tavily, SerpAPI, ou une API de moteur classique. La différence d'approche est nette et elle porte sur trois axes.
Sur la facturation, l'API se paie à la requête et le coût est prévisible. AI Search Hub ne facture rien mais consomme les comptes existants, avec des quotas que vous ne fixez pas. Sur la stabilité, une API expose un contrat versionné : si le schéma change, il y a une nouvelle version et une période de dépréciation. Ici, le contrat est une interface web qui peut changer demain matin. Sur le déterminisme, une API renvoie la même structure pour la même requête, ce qui rend les tests possibles. Un chemin browser-driven sur huit plateformes différentes ne produit pas naturellement des sorties comparables, et le README ne décrit aucune étape de normalisation qui corrigerait cela.
En échange, l'API ne vous donnera pas accès à ce que 元宝 atteint côté WeChat, ni à ce que Grok atteint côté X. C'est exactement la valeur du projet : des sources qui ne sont pas exposées par une API publique. Si vos requêtes ne portent pas sur ces sources, l'API est le meilleur choix, sans hésitation.
Licence, maintenance et coût de suivi
Le README affiche un badge MIT. Les métadonnées du dépôt indiquent que la licence n'est pas renseignée. Ces deux informations se contredisent, et c'est le premier élément à lever avant de dépendre du projet : un fichier LICENSE absent à la racine laisse juridiquement la situation ouverte, quelle que soit l'intention affichée. Je ne peux pas trancher à partir du matériel fourni, et ce n'est pas un avis juridique.
Sur la maintenance, les faits disponibles sont minces : aucune release publiée, un dernier push au 27 avril 2026, un dépôt non archivé. L'absence de releases n'est pas un défaut en soi pour un Skill, mais elle prive l'utilisateur de points de repère pour savoir quand un changement de rupture est intervenu. Si vous l'adoptez, la question à se poser n'est pas « combien de temps le projet sera maintenu » mais « combien de temps je peux fonctionner quand une plateforme change son interface ». La réponse dépend du nombre de plateformes que vous activez : une seule, la casse est isolée ; les huit, la surface de rupture est multipliée d'autant.
Un dernier élément à ne pas négliger : le README fait la promotion d'un produit commercial distinct, NotYet, hébergé sur notyet.chat. Ce n'est pas un problème en soi, mais cela indique que le dépôt et le produit ne partagent pas nécessairement le même cycle de développement.
Conclusion éditoriale
AI Search Hub convient à un développeur qui possède déjà un compte sur plusieurs de ces plateformes et veut un point d'entrée unique pour la recherche et l'extraction de liens dans son agent. Il ne convient pas à un pipeline serveur sans navigateur, ni à un usage où chaque appel doit être traçable et reproductible. Avant d'adopter, vérifiez deux choses concrètement : le fichier LICENSE à la racine du dépôt, puisque le README affiche un badge MIT mais que la licence n'est pas renseignée dans les métadonnées, et le contenu de docs/images/, qui est la seule preuve visuelle de fonctionnement fournie par le dépôt.
Notes de la communauté