OpenScience: ein Arbeitsplatz für agentengestützte Forschung

Was OpenScience lösen soll und für wen es gedacht ist

Wissenschaftliche Arbeit besteht selten aus einem einzigen Schritt. Ein Datensatz wird geprüft, eine Hypothese formuliert, Code geschrieben, ein Lauf gestartet, ein Ergebnis interpretiert und schließlich aufgeschrieben. OpenScience setzt genau an dieser Kette an: Der Nutzer gibt ein Ziel vor, und die Workbench soll laut README die Literatur lesen, Code schreiben und ausführen, Experimente durchführen und das Gefundene verschriftlichen. Die Zielgruppe sind demnach Forschende, die bereits mit Python oder R arbeiten und denen die manuelle Orchestrierung dieser Schritte zu viel Reibung erzeugt. Die Themenliste des Repositories verweist zusätzlich auf Bioinformatik, ML-Engineering und wissenschaftliches Rechnen, also auf Disziplinen, in denen Datenanalyse und Publikation ohnehin eng verzahnt sind. Wer nur eine einzelne statistische Auswertung braucht, wird die Workbench nicht benötigen. Wer dagegen wiederkehrende Auswertungspipelines mit nachvollziehbarer Herkunft der Ergebnisse fährt, findet hier einen Rahmen, der genau diese Wiederholbarkeit adressiert.

Wie der Agent arbeitet: Aufgaben, Skills und Werkzeugzugriff

Das zentrale Steuerelement ist die Forschungsaufgabe in natürlicher Sprache. Das README zeigt ein Beispiel, in dem der Nutzer eine CSV-Datei prüfen, die Originaldaten unverändert lassen und einen Qualitätsbericht samt Plot in results/ ablegen soll. Der Agent liest also das Projektverzeichnis, identifiziert fehlende Werte und inkonsistente Labels, schreibt Ausführungscode und legt Artefakte an. Für mehr Kontrolle lässt sich mit /plan zuerst die Methode abstimmen, bevor ausgeführt wird. Die Dokumentation trennt dabei ausdrücklich zwischen einem Skill und der Verfügbarkeit der darin referenzierten Werkzeuge: Ein Skill beschreibt eine Prozedur, nicht die installierte Umgebung. Diese Unterscheidung ist praktisch relevant, weil ein Agent sonst Werkzeuge aufruft, die gar nicht vorhanden sind. Das README empfiehlt deshalb, vor einer substanziellen Aufgabe unter Customize die Verfügbarkeit zu prüfen. Erweiterbar ist das Ganze über MCP-Verbindungen, eigene Agenten und Kommandos, Plugins oder eine SDK-Integration.

Installation und die drei Wege zur Modellanbindung

Die Einrichtung beginnt mit der Installation des CLI-Pakets:

npm install -g @synsci/openscience openscience

Alternativ nennt das README einen Ein-Schritt-Starter über npx synsci. Für ein bestehendes Projekt lässt sich der Pfad direkt übergeben, etwa openscience ~/research/my-project. Die Modellwahl erfolgt anschließend unter Customize → Models. Drei Optionen stehen zur Verfügung. Erstens Ace mit verwalteten Modellen und Research-Suche, bei dem der Nutzer sich anmeldet, einen Funding-Workspace wählt und dessen Wallet auflädt. Zweitens eigene Anbieterzugänge per API-Schlüssel oder unterstützter Anmeldung, wobei Abrechnung und Zugriffsbedingungen beim jeweiligen Anbieter liegen. Drittens lokale Modelle über Ollama, LM Studio oder einen kompatiblen Endpunkt. Terminalbefehle dafür sind openscience keys add und openscience models für eigene Anbieter sowie openscience local add für einen lokalen Endpunkt. Ein OpenScience-Konto ist laut README für eigene Anbieter und lokale Modelle optional. Für einzelne Terminalzüge existieren openscience run und openscience run --continue, mit denen sich etwa ein Analyseplan prüfen und anschließend Annahmen hinterfragen lassen.

Die Abrechnung über Ace ist kein Abonnement, aber auch nicht kostenlos

Ace funktioniert nach dem Prinzip der Nutzungsabrechnung ohne Monatsgebühr. Die Aktivierung ist eine Autorisierung über 0 US-Dollar. Abgerechnet wird laut README auf Basis der vom Anbieter gemeldeten Kosten zuzüglich einer Finanzierungsgebühr von 5,5 Prozent, die einmal pro Anfrage anfällt. Weitere Aufschläge werden nicht genannt; die Kartenverarbeitungsgebühr wird separat beim Bezahlvorgang ausgewiesen. Ein Detail mit praktischen Folgen: Bei aktivierten automatischen Aufladungen löst ein Wallet-Guthaben unter 5 US-Dollar eine Aufladung von 20 US-Dollar aus. Der Wechsel auf einen eigenen Anbieter deaktiviert diese automatische Aufladung nicht. Wer also Ace testet und später auf eigene Schlüssel umsteigt, sollte die Wallet-Einstellungen explizit prüfen, sonst kann weiter Geld nachgeladen werden, obwohl die Modelle längst über den eigenen Anbieter laufen. Die genauen Bedingungen stehen in der Dokumentation unter Pricing and usage.

Wo die Workbench an ihre Grenzen stößt

Die wichtigste Einschränkung steht im README selbst, allerdings leicht zu überlesen: Quellen, Annahmen, Code und Ausgaben sollen geprüft werden, bevor man sich auf eine wissenschaftliche Schlussfolgerung verlässt. Das ist kein Formalhinweis, sondern beschreibt das tatsächliche Betriebsmodell. Der Agent produziert Artefakte, keine validierten Ergebnisse. Ein zweiter Punkt betrifft die Umgebung: Ein Skill garantiert nicht, dass die darin genannten Dienste oder Werkzeuge vorhanden sind. Ein reproduzierbarer Lauf kann daher an einer fehlenden Datenbankverbindung scheitern, obwohl der Skill korrekt ausgewählt wurde. Drittens eignet sich OpenScience schlecht für Aufgaben, bei denen der Weg wichtiger ist als das Ergebnis, etwa explorative Statistik, bei der jede Zwischenentscheidung fachlich begründet werden muss. Der Agent kann einen Plan vorschlagen, aber die Begründung bleibt beim Menschen. Und für regulierte Datenumgebungen mit klaren Aufbewahrungs- und Löschpflichten liefert das Material keine Aussage darüber, wohin Prompts und Dateiinhalte bei Ace oder einem externen Anbieter fließen. Diese Frage muss vor dem Einsatz geklärt werden, nicht danach.

Wie sich OpenScience von einem reinen Chat-Assistenten unterscheidet

Der naheliegende Vergleich ist ein allgemeiner Chat-Assistent mit Dateizugriff oder ein Coding-Agent. Der Unterschied liegt in der Struktur: OpenScience bündelt einen Skills-Katalog, Connectors, Datenbankanbindungen und einen Reproduktionsablauf, bei dem laut README zunächst eine Behauptung, ihre Voraussetzungen und ein Budget vereinbart werden, bevor gemessene Ergebnisse verglichen werden. Ein Chat-Assistent kennt diesen Begriff von Budget und Voraussetzungen nicht. Umgekehrt ist OpenScience kein Ersatz für eine domänenspezifische Pipeline wie Snakemake oder Nextflow. Diese Werkzeuge beschreiben Abhängigkeiten zwischen Rechenschritten deterministisch und ohne Modellaufruf; OpenScience beschreibt Arbeitsschritte in natürlicher Sprache und überlässt die Umsetzung einem Modell. Wer reproduzierbare Läufe über Monate hinweg mit identischem Ergebnis braucht, ist mit einem expliziten Workflow-Manager besser bedient. Wer dagegen den Einstieg in eine neue Datenquelle oder Literaturfrage sucht und dabei Code und Bericht in einem Durchgang erhalten will, für den ist der agentengestützte Ansatz der passendere.

Wartung, Release-Takt und Lizenz

Das Repository wird aktiv gepflegt: Der letzte Push datiert auf den 9. September 2026, und die drei jüngsten Releases v2.0.85, v2.0.86 und v2.0.87 stammen alle aus diesem Monat, teils im Abstand von wenigen Stunden. Dieser Takt bedeutet für Betreiber, dass Updateprüfungen häufiger anfallen als bei Projekten mit quartalsweisen Veröffentlichungen. Das CLI wird über npm verteilt, ein Update läuft also über die gewohnten Paketbefehle. Die Desktop-App wird separat über die Downloadseite für macOS, Windows und Linux bereitgestellt, sodass hier zwei Aktualisierungspfade nebeneinander existieren. Lizenziert ist das Projekt unter Apache-2.0, was kommerzielle Nutzung und Modifikation erlaubt, sofern die Lizenzbedingungen eingehalten werden; für abgeleitete Werke sind die üblichen Hinweispflichten zu beachten. Das gilt für den Code. Für die über Ace abgerechneten Modellaufrufe und für über Connectors angebundene Fremddienste gelten deren jeweilige Bedingungen, die von der Apache-Lizenz nicht berührt werden. Eine rechtliche Bewertung ersetzt das nicht.

Redaktionelles Fazit

OpenScience passt zu Forschenden, die reproduzierbare Auswertungspipelines brauchen und bereit sind, die Modellanbindung selbst zu konfigurieren, sei es über eigene API-Schlüssel oder einen lokalen Endpunkt wie Ollama. Wer den Agenten ohne Prüfschritt auf klinische oder personenbezogene Daten ansetzt, sollte es nicht adoptieren, solange die Datenflusskontrolle nicht im Detail geprüft ist. Vor dem ersten Einsatz lohnt es sich, mit openscience models die aktive Modellkonfiguration und mit openscience local add den lokalen Endpunkt zu verifizieren, bevor eine Aufgabe mit echtem Datenzugriff gestartet wird.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. synthetic-sciences/openscience on GitHub