Open Science von AIPOCH: Agenten, Notizbücher und Provenienz in einer App

Projekte, Sitzungen und Nachrichtenverzweigung in Open Science

Open Science wird von AIPOCH entwickelt und als quelloffene, lokal betriebene und modellunabhängige Forschungswerkbank beschrieben. Die Anwendung läuft als Desktop-Programm auf macOS, Windows und Linux, geschrieben in TypeScript auf Basis von Electron, React, Prisma und SQLite, mit einer auf ACP aufsetzenden Agent-Laufzeit. Das Repository liegt bei 3265 Sternen, 207 Forks und 46 offenen Issues und steht unter Apache License 2.0.

Die Arbeit ist in Projekte und Sitzungen gegliedert. Ein Projekt hält zusammengehörige Sitzungen, hochgeladene Dateien, erzeugte Artefakte und den Vorschauzustand. Das Gespräch protokolliert nicht nur die Antwort des Agenten, sondern auch die Befehle, Lesezugriffe, Bearbeitungen, Suchen und Konnektoraufrufe, die zu ihr geführt haben. Eine Besonderheit ist die Verzweigung: Wird eine bereits gesendete Nachricht bearbeitet und erneut abgeschickt, entsteht ein neuer Pfad, ohne die folgenden Schritte zu löschen, und über die Revisionssteuerung lässt sich zwischen beiden Wegen wechseln.

Fünf Schritte beim ersten Start von Environment bis Data Location

Der Erststart besteht aus fünf geführten Schritten. Environment prüft Kompatibilität, App-Speicher, sichere Speicherung von Zugangsdaten und Netzwerkzugang. Agent runtime wählt und bereitet eines der Backends Claude Code, OpenCode, Codex oder CodeBuddy vor; app-verwaltete Laufzeiten lassen sich laut README ohne Node.js, npm oder Administratorpasswort installieren.

Danach folgt Model provider, wo ein Modell verbunden und getestet wird, wahlweise ein eingebauter Anbieter, ein eigenes Gateway oder eine bestehende Claude- oder Codex-Anmeldung. Notebook runtime bereitet optional app-verwaltete Python- und R-Umgebungen vor oder bindet erkannte und manuell registrierte Interpreter ein. Data location legt fest, wo große Artefakte, Notebooks, Uploads und Umgebungen liegen. Die Notebook- und Speicherpunkte können auf Voreinstellungen bleiben und später geändert werden, die Umgebungs- und Laufzeitprüfungen müssen dagegen bestanden sein, bevor es weitergeht.

Provenienzansicht, Prüfsummen und was Open Science als Beleg offenlegt

Erzeugte Berichte, Abbildungen und Tabellen werden als unveränderliche, mit Prüfsummen versehene Versionen abgelegt. Die Provenienzansicht eines Artefakts zeigt, welche Belege Open Science zum Zeitpunkt der Erstellung verifizieren konnte: den erzeugenden Code und den Ausführungsverlauf, referenzierte Eingaben, ein beobachtetes Umgebungsinventar, den Gesprächszweig, aus dem das Artefakt stammt, sowie Prüfbefunde zur jeweiligen Version.

Wichtig ist die Behandlung von Lücken. Fehlende Belege werden als nicht verfügbar markiert und nicht geraten, die Ansicht füllt also keine Lücken mit Vermutungen. Vorschauen decken gängige wissenschaftliche Datenformate, PDFs, Office-Dokumente, Bilder, Quellcode mit Syntaxhervorhebung, Molekülstrukturen und Reaktionen sowie den Notebook-Verlauf ab. Grenzen der Vorschau beschneiden laut README die zugrunde liegende Datei nicht, das vollständige Artefakt bleibt für den Agenten und externe Werkzeuge erreichbar.

18 Fähigkeiten von AlphaFold2 bis Remote Compute (SSH) und die 24 Konnektoren

Die README listet 18 dateibasierte Forschungsfähigkeiten auf, darunter AlphaFold2, Boltz, Chai-1, DiffDock, ESM-2, ESMFold2, Evo 2, Literature Review, scGPT, scvi-tools und Remote Compute (SSH) für lang laufende Aufträge auf HPC-Clustern. Eigene Fähigkeiten entstehen über SKILL.md, ZIP oder .skill-Pakete, die hochgeladen werden; kompatible Fähigkeiten lassen sich aus GitHub in der Vorschau ansehen und importieren, ebenso bereits in globalen Agentenverzeichnissen installierte.

Dazu kommen 24 eingebaute Konnektoren für Literatur, Gene, Genome, Varianten, Expression, Chemie, klinische Studien, Arzneimittelzulassungsdaten und Forschungsressourcen. Fähigkeiten und Konnektoren stehen hinter einem Berechtigungssystem mit drei Werkzeugsteuerungen: Immer erlauben, Jedes Mal fragen und Blockieren. Die README weist ausdrücklich darauf hin, dass Fähigkeiten und Konnektoren Code ausführen oder Daten nach außen senden können, und rät, vor dem Aktivieren Quelle, Lizenz, Skripte und Netzverhalten zu prüfen.

Modellanbieter: OpenAI, Anthropic, Volcengine Ark und der Weg über ein eigenes Gateway

Bei der Modellwahl ist Open Science produktseitig unabhängig. Vier Wege sind dokumentiert: eingebaute Cloud-Anbieter, ein benutzerdefiniertes Gateway mit kompatibler Basis-URL und API-Schlüssel, ein Claude-Abonnement über gemeinsamen Browser-Login oder einen app-verwalteten claude setup-token-Ablauf, sowie ein Codex-Abonnement. Genannt werden unter anderem OpenAI, Anthropic, Grok (xAI), DeepSeek, Zhipu AI (GLM), Kimi (Moonshot), MiniMax, StepFun, Xiaomi MIMO, SenseNova, Volcengine Ark, Bailian von Alibaba Cloud und OpenRouter, wobei einzelne Anbieter regional begrenzt sind.

Zwei Einschränkungen sind zu beachten. Die Verfügbarkeit eines Anbieters hängt laut README vom gewählten Agent-Backend ab, und die verbindliche Auskunft über Anbieter und Verbindungstest liefert die installierte App, nicht die README. Der frühere Local-Claude-Anbieter wurde entfernt, gespeicherte Einträge werden beim Upgrade verworfen. Mit v0.22.0 kam der Anbieter Tencent TokenHub hinzu, zusammen mit persistentem Agentengedächtnis über Sitzungen hinweg, Provenienz in den Abbildungsworkflows der gebündelten Fähigkeiten, zentraler Verwaltung von GitHub-Tokens und einem Verbrauchs-Dashboard, das Token ihren Läufen zuordnet.

Genehmigungsprofile, Tool-Steuerung und was nicht in Issue-Protokolle gehört

Projektdaten, Einstellungen, Artefaktversionen und Provenienznachweise liegen lokal. API-Schlüssel bleiben auf dem Rechner und nutzen, wo vorhanden, die sichere Zugangsspeicherung des Betriebssystems; Protokolle sind lokal und werden nicht automatisch hochgeladen. Abflüsse nach außen gibt es trotzdem: Modellanfragen senden Prompt und Kontext an den Anbieter, Websuchen und Remote-Konnektoren übergeben ihre angezeigten Parameter, lokale Konnektoren können freigegebene Befehle ausführen.

Für die Steuerung bietet die README drei Profile: Genehmigung anfragen, Bearbeitungen automatisch genehmigen und Vollzugriff. Bei der Fehlerberichterstattung ist Vorsicht geboten, denn die README listet auf, was keinesfalls in öffentliche Issue-Protokolle gehört: API-Schlüssel, Zugangstoken, Patientenidentifikatoren, unveröffentlichte Daten und sensible lokale Pfade. Wer in einem regulierten Umfeld arbeitet, sollte das Profil Genehmigung anfragen wählen und Konnektoren vor dem Aktivieren prüfen.

Grenzen von Open Science und der Unterschied zum direkten Einsatz von Claude Code

Die wichtigste Grenze steht in der README selbst: Deterministische Rekonstruktion, portable Umgebungswiederherstellung und die Wiedergabe von Sitzungen mit vollständiger Treue sind als Roadmap geführt, also noch nicht vorhanden. Wer Reproduzierbarkeit im strengen Sinne braucht, bekommt derzeit Prüfsummen und Provenienzbelege, aber keinen garantiert wiederholbaren Lauf. Hinzu kommt die Abhängigkeit von gewerblichen Modellanbietern, und mit v0.22.0 vom 29. August 2026 sowie dem Nightly-Tag wechseln Versionen schnell, was die README auch bei Modellkatalogen als Grund nennt, die installierte App als Quelle zu nehmen.

Die Alternative liegt nahe, weil Open Science selbst auf Agent-Backends aufsetzt: Wer Claude Code, OpenCode, Codex oder CodeBuddy direkt benutzt, hat die Agenten ohne die App. Der Unterschied ist benennbar. Ohne Open Science fehlen die Projektebenen mit Verzweigung und Revisionswechsel, die prüfsummenbasierte Artefaktversionierung mit Provenienzansicht, die 24 Konnektoren und die Notebook-Runtime für Python und R inklusive Variablenansicht, die den aktiven Namensraum nach jeder Ausführung zeigt. Dafür entfällt die Installation einer Electron-Anwendung und die Verwaltung eines Genehmigungsprofils. Für einzelne Skriptaufgaben genügt der direkte Weg, für Arbeiten, bei denen Herkunft und Belege zählen, ist der Umweg über Open Science der Grund, die App überhaupt zu installieren.

Redaktionelles Fazit

Open Science passt zu Forschenden, die mit Agenten arbeiten und zu jedem Ergebnis die Belege sehen wollen, etwa in der Wirkstoffforschung oder in der Statistik, wo die Konnektoren und Fähigkeiten wie AlphaFold2, DiffDock oder scvi-tools greifen. Es passt nicht zu Teams, die eine serverbasierte Mehrplatzlösung oder garantierte Reproduzierbarkeit brauchen: Die README führt deterministische Rekonstruktion und portable Umgebungswiederherstellung als Roadmap, nicht als Funktion. Vor dem Einstieg klären: Welches Agent-Backend soll laufen, ist ein Notebook-Runtime für Python oder R nötig, und welcher Modellanbieter ist in der Region verfügbar. Wer nur gelegentlich Code ausführen will, fährt mit einem einzelnen Agenten-Backend ohne die App günstiger.

Offizielle Quellen

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