AI Search Hub: Browser-gesteuerte Suche über acht KI-Plattformen
One Query. All Search Skill. 聚合 Gemini、Grok、豆包、元宝等平台原生 AI 搜索能力，免费获取科技趋势、行业舆情、热点追踪、旅行规划、日常问题统一接进自己的 Agent 与工作流，指定链接免费爬取
Auf einen Blick
- Was ist das?
- Ein Python-Skill, der Gemini, Grok, Doubao, Yuanbao und weitere Plattformen hinter einer Abfrage bündelt. Die Suche läuft über den Browser, nicht über offizielle APIs. Das ist die zentrale Designentscheidung und zugleich das größte Risiko.
- Für wen ist es gedacht?
- Wer bereits OpenClaw oder Claude Code nutzt und die Suche über chinesische Plattformen wie Doubao, Yuanbao oder Tongyi Qianwen benötigt, findet hier eine funktionierende Orchestrierungsschicht. Wer eine stabile API für Produktionssysteme braucht, sollte einen Bogen machen: Die Browser-Automation ist strukturell fragil, und die Lizenzlage ist ungeklärt (die README zeigt einen MIT-Badge, das Repository liefert aber keine bestätigte Lizenzdatei).
- Darf ich es kommerziell nutzen?
- Nicht ohne Erlaubnis. GitHub findet in diesem Repository keine Lizenzdatei, und ohne Lizenz sind standardmäßig alle Rechte vorbehalten: Sie dürfen den Code lesen, aber nicht wiederverwenden. Prüfen Sie die README oder fragen Sie die Autoren, bevor Sie ihn nutzen.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 142 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Problem: acht Plattformen, acht Sitzungen, kein gemeinsamer Ausgang
Wer heute Informationen aus mehreren KI-Suchdiensten zusammenführen will, steht vor einem wiederkehrenden Problem. Gemini findet andere Dinge als Grok. Grok sieht Echtzeit-Diskussionen auf X, die Gemini nicht indexiert. Doubao erreicht Inhalte aus dem chinesischen Ökosystem, die außerhalb schwer zugänglich sind. Jede Plattform hat ihre eigene Stärke, aber auch ihre eigene Sitzungsverwaltung, ihre eigene Weboberfläche und ihr eigenes Verhalten bei Rate Limiting. AI Search Hub setzt genau hier an: Eine Abfrage soll an mehrere Plattformen verteilt und die Ergebnisse in einem einheitlichen Format zurückgegeben werden.
Die Zielgruppe ist eng umrissen. Das Projekt richtet sich an Nutzer von OpenClaw, Claude Code, OpenAI Codex CLI, Cursor und ähnlichen Agent-Umgebungen, die ihre Suchfähigkeiten über die Grenzen eines einzelnen Anbieters hinaus erweitern wollen. Wer bereits einen Agenten betreibt und ihm Zugang zu chinesischen Quellen oder Echtzeit-Social-Daten verschaffen möchte, ist der adressierte Fall. Wer einfach nur eine Suchmaschine braucht, ist es nicht.
Browser-Automation statt API: der eigentliche Mechanismus
Die README beschreibt das Projekt als browser-driven. Das ist keine Nebenbemerkung, sondern die Architekturentscheidung, die alles andere bestimmt. AI Search Hub ruft die Suchfunktionen der Plattformen über deren Weboberflächen auf, nicht über offizielle APIs. Ein Query wird an mehrere Plattform-Adapter verteilt, jede Instanz führt die Suche in ihrem jeweiligen Web-Frontend aus, und die Ergebnisse werden zurück in ein gemeinsames Ausgabeformat überführt.
Dasselbe Muster gilt für das Crawling: Übergibt man dem Skill einen Link, liest eine der Plattformen die Seite und liefert den extrahierten Inhalt zurück. Die Dokumentation nennt das den Kern des Ansatzes: nicht selbst crawlen, sondern die bereits vorhandene Web-Verständnis- und Extraktionsfähigkeit der Plattformen nutzen. Der Datenfluss ist also: Query oder URL rein, Verteilung an die Adapter, Ausführung im Browser, Zusammenführung, Ausgabe an den aufrufenden Agenten.
Der Vorteil liegt auf der Hand. Man muss keine eigenen Scraping-Regeln pflegen, keine Login-Flows für jede Plattform nachbauen und keine Captcha-Behandlung implementieren. Der Nachteil ist ebenso klar: Man hängt an der Weboberfläche. Ändert eine Plattform ihr DOM, bricht der Adapter.
Acht Adapter und ihre dokumentierten Zuständigkeiten
Die README listet acht Plattformen als aktuell integriert: Gemini, Grok, Doubao, Yuanbao, LongCat, Tongyi Qianwen, MiniMax und Kimi. Für jede nennt sie einen Schwerpunkt. Gemini deckt Google-Suche und öffentliche Webseiten ab. Grok ist auf X und Echtzeit-Diskussionen ausgerichtet. Doubao adressiert chinesische Inhalte und Trendthemen, einschließlich Douyin. Yuanbao ergänzt chinesische Quellen und WeChat-Public-Account-Inhalte. LongCat und Tongyi Qianwen liefern chinesisches Wissen und Web-Erweiterung. MiniMax und Kimi sind als allgemeine chinesische Assistenten eingeordnet.
Die README markiert alle acht mit dem Status Good. Diese Angabe stammt aus dem Projekt selbst und ist nicht unabhängig überprüfbar. Wer den Skill einsetzt, sollte die für ihn relevanten Adapter einzeln testen, bevor er sich auf sie verlässt. Besonders die drei Plattformen, die auf chinesische Datenquellen zielen (Doubao, Yuanbao, LongCat), sind für Nutzer außerhalb Chinas interessant, weil sie Inhalte erreichen, die über westliche Suchdienste kaum auffindbar sind.
Einrichtung: was die README zeigt und was sie verschweigt
Das Projekt ist in Python geschrieben und als Skill für Agent-Umgebungen gedacht. Die README selbst enthält keine Installationsanweisungen, keine Konfigurationsschlüssel und keine Kommandozeilenbeispiele. Sie beschreibt das Konzept, die Plattformliste und den Vergleich mit selbstgebauten Crawlern, aber nicht den Weg von git clone bis zur ersten Abfrage.
Das ist eine echte Lücke. Wer den Skill in OpenClaw oder Claude Code einbinden will, muss die Installationsdetails aus der Repository-Struktur oder aus separaten Dateien erschließen, die in der vorliegenden README nicht dokumentiert sind. Ein Python-Projekt dieser Art benötigt üblicherweise eine requirements.txt oder pyproject.toml, eine Skill-Manifest-Datei für die Agent-Integration und eine Konfiguration für die Plattform-Anmeldedaten. Ob und in welcher Form diese Dateien existieren, lässt sich aus dem vorliegenden Material nicht bestätigen. Wer den Skill evaluiert, sollte den Repository-Inhalt vollständig prüfen, bevor er Zeit in die Einrichtung investiert.
Die Grenzen: warum Browser-Automation ein Betriebsrisiko ist
Der browser-driven Ansatz ist die größte Einschränkung des Projekts. Er funktioniert, solange die Weboberflächen stabil bleiben. Ändert eine Plattform ihr Layout, ihre Login-Sequenz oder ihr Anti-Bot-Verhalten, bricht der zugehörige Adapter. Bei acht Plattformen bedeutet das acht unabhängige Bruchstellen, jede mit eigenem Release-Zyklus.
Hinzu kommt die Frage der Nutzungsbedingungen. Die README formuliert den Ansatz offen: die nativen Suchfunktionen der Plattformen nutzen, um Daten zu beziehen, die sonst schwer zugänglich sind. Ob das mit den Nutzungsbedingungen jeder einzelnen Plattform vereinbar ist, klärt das Projekt nicht. Wer den Skill produktiv einsetzt, trägt dieses Risiko selbst.
Für Anwendungsfälle mit hohem Durchsatz ist das Projekt die falsche Wahl. Browser-Automation skaliert nicht wie eine API. Wer tausende Abfragen pro Stunde verarbeiten muss, braucht offizielle Schnittstellen. AI Search Hub ist für den gelegentlichen, explorativen Einsatz in einem Agenten gedacht, nicht für Massenverarbeitung.
Alternative: offizielle APIs mit eigenem Aggregations-Layer
Der naheliegende Gegenentwurf ist ein selbstgebauter Aggregations-Layer über offiziellen APIs. Statt die Weboberflächen von Gemini, Grok und Doubao zu automatisieren, ruft man die jeweiligen API-Endpunkte auf und normalisiert die Antworten in einem eigenen Dienst. Der Unterschied im Ansatz ist grundlegend: APIs sind vertraglich abgesichert und versioniert, Weboberflächen nicht.
Der Preis dafür ist ein anderer. Nicht jede der acht Plattformen bietet eine offene API, und die chinesischen Anbieter haben oft eigene Zugangsverfahren, die für Entwickler außerhalb Chinas schwerer erreichbar sind. Genau diese Lücke füllt AI Search Hub. Wer Zugang zu den offiziellen APIs hat, sollte sie nutzen. Wer ihn nicht hat, für den ist der Browser-Ansatz die verbleibende Option, mit allen genannten Risiken.
Ein zweiter Vergleichspunkt: einzelne Plattform-SDKs. Wer nur Grok braucht, kann das xAI-SDK direkt einbinden und spart sich die gesamte Orchestrierungsschicht. AI Search Hub lohnt sich erst, wenn mehrere Plattformen gleichzeitig abgefragt werden sollen.
Wartung, Lizenz und der Stand der Dokumentation
Der letzte Push datiert auf den 27. April 2026. Es gibt keine abgerufenen Releases. Das Projekt ist also aktiv, aber ohne versionierte Veröffentlichungen. Für Nutzer bedeutet das: Updates kommen über den main-Branch, es gibt keine stabilen Tags, an denen man sich festhalten kann.
Die Lizenzlage ist widersprüchlich. Die README trägt einen MIT-License-Badge, das Repository liefert laut den vorliegenden Angaben aber keine bestätigte Lizenzkennung. Wer den Code in ein kommerzielles Produkt einbetten will, muss das vorher klären. Ohne bestätigte Lizenzdatei fehlt die rechtliche Grundlage für die Weitergabe oder den kommerziellen Einsatz. Das ist keine Formalie, sondern ein Ausschlusskriterium für viele Anwendungsfälle.
Der Wartungsaufwand liegt beim Nutzer. Acht Browser-Adapter bedeuten acht potenzielle Bruchstellen, die bei jeder Änderung der Zielplattform nachgezogen werden müssen. Das Projekt selbst liefert keine Angaben dazu, wie häufig solche Anpassungen nötig sind.
Redaktionelles Fazit
Wer bereits OpenClaw oder Claude Code nutzt und die Suche über chinesische Plattformen wie Doubao, Yuanbao oder Tongyi Qianwen benötigt, findet hier eine funktionierende Orchestrierungsschicht. Wer eine stabile API für Produktionssysteme braucht, sollte einen Bogen machen: Die Browser-Automation ist strukturell fragil, und die Lizenzlage ist ungeklärt (die README zeigt einen MIT-Badge, das Repository liefert aber keine bestätigte Lizenzdatei). Vor dem Einsatz zu prüfen: ob das Repository eine LICENSE-Datei enthält und welchen Status die acht Plattform-Adapter tatsächlich haben.
Community-Notizen