gpt-researcher: Rechercheberichte mit Planer, Ausführung und Quellenangaben

gpt-researcher: ein Recherche-Agent mit Planer und Ausführung

Die Beschreibung des Repositories bringt den Anspruch in einem Satz unter: ein autonomer Agent, der tiefe Recherche über beliebige Daten mit beliebigen LLM-Anbietern betreibt. assafelovic/gpt-researcher ist in Python geschrieben, unter Apache-2.0 lizenziert und verweist als Startseite auf https://gptr.dev. In den Metadaten stehen 29.186 Sterne, 3.965 Forks und 58 offene Issues. Die letzte Änderung datiert vom 24. August 2026, passend zum Release v3.6.1.

Das Problem, an dem das Projekt ansetzt, benennt das README selbst. Manuelle Recherche zu einer objektiven Schlussfolgerung dauere Wochen, Sprachmodelle mit veraltetem Trainingsstand erfänden Inhalte, Kontextgrenzen reichten für lange Berichte nicht aus, und zu wenige oder einseitig gewählte Webquellen führten zu falschen Ergebnissen.

Als Grundlage nennt das README zwei Veröffentlichungen: Plan-and-Solve (arxiv.org/abs/2305.04091) und RAG (arxiv.org/abs/2005.11401). Der Geschwindigkeitsgewinn soll aus parallel arbeitenden Agenten kommen, die einzelnen Teilfragen gleichzeitig abarbeiten.

Planner, Execution Agents und Publisher: der Ablauf in gpt-researcher

Der Kern der Architektur ist eine Aufgabenteilung. Ein Planer erzeugt aus der Ausgangsfrage mehrere Forschungsfragen, die zusammen eine möglichst objektive Antwort abdecken sollen. Für jede dieser Fragen sammelt ein Ausführungs-Agent Informationen, ein sogenannter Crawler-Agent.

Das README beschreibt fünf Schritte: einen aufgabenspezifischen Agenten erzeugen, Fragen formulieren, pro Frage mit einem Crawler sammeln, jede Quelle zusammenfassen und ihre Herkunft festhalten, dann die Zusammenfassungen filtern und zum Bericht zusammenführen. Der letzte Schritt gehört dem Publisher, der die Einzelergebnisse aggregiert.

Das Quellen-Tracking ist der Teil, der den Unterschied zu einem einzelnen Modellaufruf macht. Weil jede Zusammenfassung mit ihrer Herkunft verknüpft wird, lassen sich Behauptungen im fertigen Bericht auf eine Fundstelle zurückführen. Wie streng diese Zuordnung geprüft wird, ist in der Dokumentation nicht angegeben.

Python 3.11, OPENAI_API_KEY und uvicorn: der Aufbau laut README

Der Weg zur laufenden Instanz beginnt mit Python 3.11 oder neuer. Danach wird das Repository geklont und das Verzeichnis gewechselt: `git clone https://github.com/assafelovic/gpt-researcher.git` gefolgt von `cd gpt-researcher`.

Die Zugangsdaten werden als Umgebungsvariablen gesetzt oder in eine `.env`-Datei geschrieben. Das README nennt `export OPENAI_API_KEY={Your OpenAI API Key here}` und `export TAVILY_API_KEY={Your Tavily API Key here}`. Für Nachvollziehbarkeit lassen sich optional `LANGCHAIN_TRACING_V2=true` und `LANGCHAIN_API_KEY` setzen, beide Zeilen sind im README auskommentiert.

Wer statt OpenAI einen kompatiblen Endpunkt nutzt, setzt `OPENAI_BASE_URL`, was laut README lokale Modelle und andere Anbieter einschließt. Danach folgen `pip install -r requirements.txt` und `python -m uvicorn main:app --reload`, erreichbar unter http://localhost:8000. Für Poetry oder virtuelle Umgebungen verweist das README auf die Separate Anleitung unter docs.gptr.dev.

GPTResearcher als PIP-Paket: conduct_research und write_report

Wer keinen Server betreiben will, installiert nur das Paket: `pip install gpt-researcher`. Der gezeigte Ausschnitt ist kurz und besteht im Wesentlichen aus drei Zeilen plus Import. Aus `gpt_researcher` wird die Klasse `GPTResearcher` geholt, mit einer Frage instanziiert, danach folgen `research_result = await researcher.conduct_research()` und `report = await researcher.write_report()`.

Beide Aufrufe sind asynchron, der aufrufende Code braucht also einen laufenden Event-Loop. Die Trennung in zwei Schritte ist praktisch: Die Recherche lässt sich ausführen und zwischenspeichern, der Bericht später daraus erzeugen, ohne die Quellen erneut abzufragen. Als Beispielfrage nennt das README „why is Nvidia stock going up?“. Das Material bricht danach ab, der Rest des Beispiels ist nicht enthalten.

Zusätzlich bewirbt das README die Installation als Claude Skill über `npx skills add assafelovic/gpt-researcher`. Damit läuft der Agent nicht als eigener Dienst, sondern eingebettet in eine Konversation.

RETRIEVER=tavily,mcp: eigene Datenquellen über MCP einbinden

Neben der Webrecherche unterstützt gpt-researcher das Model Context Protocol, um spezialisierte Datenquellen wie GitHub-Repositories, Datenbanken oder eigene Schnittstellen einzubinden. Aktiviert wird das über die Umgebungsvariable `RETRIEVER` mit dem Wert `tavily,mcp`, was Websuche und MCP zu einer hybriden Recherche verbindet.

Im Python-Beispiel wird dieselbe Variable alternativ über `os.environ["RETRIEVER"] = "tavily,mcp"` gesetzt. Der Konstruktor bekommt dann das Argument `mcp_configs`, eine Liste von Serverbeschreibungen mit den Schlüsseln `name`, `command`, `args` und `env`. Gezeigt wird ein GitHub-Server mit `command: "npx"`, den Argumenten `["-y", "@modelcontextprotocol/server-github"]` und einem `GITHUB_TOKEN` in `env`.

Damit verschiebt sich der Einsatzzweck: Aus einem Websuch-Werkzeug wird ein Werkzeug, das auch interne Bestände durchsucht. Welche Retriever-Kombinationen außer tavily und mcp gültig sind, dazu macht das README an dieser Stelle keine Angabe.

Was v3.6.1 laut README nicht leistet: 20 Quellen und kein deutsches README

Die Leistungsangaben sind selbst berichtet und stehen im Abschnitt Features: Berichte mit mehr als 2.000 Wörtern, mehr als 20 aggregierte Quellen, Bildgewinnung mit Filterung, inline erzeugte Illustrationen über Googles Gemini-Modelle (im README „Nano Banana“ genannt), JavaScript-fähiges Scraping, Kontexterhalt über die gesamte Recherche sowie Export nach PDF und Word. Beim Frontend gibt es zwei Varianten, eine schlanke mit HTML/CSS/JS und eine mit NextJS und Tailwind.

Zwei Punkte fallen unangenehm auf. Erstens sind die Zahlen nicht belegt, es gibt im Material keine Messreihe. Zweitens bietet das Repository sein README in vier Sprachen an, Englisch, Chinesisch, Japanisch und Koreanisch, Deutsch fehlt. Wer im deutschsprachigen Umfeld arbeitet, übersetzt die Anleitung selbst.

Wer die Fähigkeiten nicht braucht, kommt ohne den Agenten aus: Eine eigene Sammlung aus zehn gezielt ausgewählten Dokumenten, die direkt in den Kontext eines Modells wandert, liefert für eine klar umrissene Frage oft dasselbe Ergebnis. Der Unterschied liegt im Aufwand, den gpt-researcher übernimmt, und in den Kosten, die dafür anfallen. Die 58 offenen Issues zeigen, dass auch bei v3.6.1 nicht alles rund läuft, und die Releases v3.6.0 vom 18. Juli 2026 und v3.5.1 vom 23. Juni 2026 deuten auf zügige, aber nicht fehlerfreie Weiterentwicklung hin.

Redaktionelles Fazit

Geeignet ist gpt-researcher für Teams, die eine wiederkehrende Recherche automatisieren wollen und bereit sind, OpenAI- und Tavily-Schlüssel sowie einen Python-3.11-Server zu betreiben. Weniger geeignet ist es für alle, die kurze Antworten brauchen, denn das README wirbt ausdrücklich mit Berichten jenseits von 2.000 Wörtern und mehr als 20 Quellen, nicht mit knappen Ergebnissen. Vor dem Einsatz lohnt der Test mit einer einzigen Frage über das PIP-Paket und `await researcher.conduct_research()`, um Tokenverbrauch und Laufzeit zu sehen, bevor der Server mit uvicorn dauerhaft läuft.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes