BLOG
OpenResearch-Zerlegung: Ein lokales Arbeitsverzeichnis, das Claude Code in einen Forschungs-Agenten verwandelt
Technische Zerlegung: Analyse von KI-Technologie-Frameworks – Erklärung, Analyse, technische Bewertung, Werturteil, praktische Anwendung. Autor: Yongliang
Am 18. September 2026 hatte alphaXiv/OpenResearch auf GitHub 4.941 Sterne (Stand 18. September), 305 Forks, 42 offene Issues, MIT-Lizenz; das Repository wurde am 7. Juni 2026 erstellt – in etwas mehr als zwei Monaten fast fünftausend Sterne erhalten, mit dem Abzeichen für Platz 1 bei Trending (trendshift) im README. Was es tut, lässt sich in einem Satz zusammenfassen: Es baut keinen neuen Forschungs-Agenten, sondern verwandelt die von Ihnen bereits genutzten Tools Claude Code, Codex, OpenCode und Cursor in Forschungs-Agents, indem es ihnen einen lokalen Arbeitsbereich (local-first workspace) zur Verfügung stellt – Literaturrecherche, Hypothesen, Experimente und Forschungsberichte sind alles versionierte Artefakte. Dieser Artikel zerlegt das Thema in sechs Teile: Was ist es?, Wie installiert man es?, Das Dreigestirn auf Quellcode-Ebene, Nüchterne Betrachtung, Lohnt es sich?, Fazit.
1. Was ist das
Die Selbstpositionierung von OpenResearch steht in der ersten Zeile der README: „The local-first workspace for research agents and autoresearch“. Die zweite Zeile ist direkter – „Turn your coding agents into research agents“. Beachten Sie dieses Verb: turn, also umwandeln/verändern, nicht replace (ersetzen). Es gibt eine Realität zu: Die Fähigkeiten zum Reasoning und zum Aufrufen von Tools, die Forschungs-Agents benötigen, besitzen Coding-Agents bereits. Was fehlt, ist die für Forschung typische Struktur – Experimente müssen reproduzierbar sein, Hypothesen müssen eine Herkunft haben, Beweise müssen im Kontext bleiben und Ergebnisse müssen überprüfbar sein. Wenn allgemeine Coding-Agents direkt mit der Forschung beginnen, ist die häufigste Todesursache nicht, dass sie Fragen falsch beantworten, sondern dass sie Änderungen in verschiedene Richtungen in einem einzigen Verzeichnis vermischen und ein einmalig erfolgreiches Ergebnis als zitierbare Schlussfolgerung behandeln. Genau diese Struktur soll OpenResearch ergänzen.
Der Tech-Stack selbst ist eine Fußnote zu dieser Positionierung. Das gesamte Repository umfasst 515 Dateien. Rust macht 3,63 MB aus (115 .rs-Dateien) und trägt die lokale Laufzeitumgebung sowie die Harness-Management-Ebene; TypeScript mit 1,38 MB (89 .tsx plus 47 .ts) stützt das ui/-Dashboard mit 254 Dateien; JavaScript umfasst etwas mehr als 204 KB, hauptsächlich in Build-Skripten, während Python nur 49 KB und 40 Dateien hat, verteilt auf Demos und Skripte. Die Verzeichnisse der obersten Ebene sind ui/, src/, demo/, agent-skills/ (29 Dateien), macos/, docs/ – eine Struktur aus „lokalem Prozess + Browser-Oberfläche + Skill-Paketen + nativer App-Hülle“, wobei der Desktop nicht vernachlässigt wurde.
Die README fasst die Fähigkeiten in einer Tabelle mit sechs Zeilen zusammen: Parallele Erkundung (eine unabhängige Agent-Sitzung pro Forschungsrichtung, ausgestattet mit isoliertem git worktree); Reproduzierbare Experimente (nativer Experiment-Baum von git, jeder Run ist ein unveränderliches Archiv); Beweise im Kontext; Wahl des Agents (pro Sitzung Harness und Modell wechseln); Wahl der Rechenleistung (lokal, eigener Cluster, gehostet); Lokaler Besitz. Diese sechs Punkte sind keine Funktionsliste, sondern ein Design-Manifest – jeder Punkt antwortet auf ein spezifisches Versagen allgemeiner Coding-Agents bei der Forschung. Beachten Sie, dass der sechste Punkt „Lokaler Besitz“ separat aufgeführt ist: Artefakte und Daten verbleiben in Ihrem eigenen git-Repository; das ist in dieser Produktkategorie eine Haltung, keine Funktion.
2. Installation und Nutzung
Installation mit einem einzigen Befehl:
curl -LsSf https://openresearch.sh/install.sh | shNach der Installation führen Sie orx up aus; das lokale Dashboard startet unter http://127.0.0.1:4791. Die nachfolgenden Operationen werden größtenteils im Browser erledigt: Sitzungen starten, den Experimentbaum ansehen, Beweise durchsuchen. Das Befehlszeilenwerkzeug ist orx. Die Plattformunterstützung umfasst macOS 11 und höher, Linux (Ein-Klick-Installation) und Windows Beta (benötigt Git for Windows) – die Beta-Kennzeichnung ist wörtlich zu nehmen, die Stabilität ist selbst einzuschätzen. Zudem hängt es stark von git ab; stellen Sie unter Windows sicher, dass Git for Windows installiert ist. Auf Modellseite können LM Studio, oMLX, Ollama oder beliebige benutzerdefinierte OpenAI-kompatible Endpunkte angebunden werden, oder es können direkt die Cloud-APIs verschiedener Anbieter genutzt werden. Die Verwendung lokaler Modelle bedeutet, dass der gesamte Prozess auch ohne Internetverbindung ausgeführt werden kann, was für datensensitive Forschung eine unabdingbare Anforderung ist.
Die Nutzung unterteilt sich in zwei Ebenen. Manuelle Ebene: Sie öffnen im Dashboard mehrere Sitzungen. Jede Sitzung entspricht einer Forschungsrichtung, in der jeweils eigene Agents laufen und eigenen Code schreiben. In der Baumansicht sehen Sie, welche Richtung Ergebnisse hervorgebracht hat. Die automatische Ebene heißt Autoresearch: Man gibt eine Idee ein, und der Agent durchläuft selbstständig den Kreislauf „Idee einreichen → Code ändern → Experimente laufen → Beweise ansehen → nächsten Schritt entscheiden“. Mehrere Agents arbeiten parallel voran, und der Experimentbaum garantiert die Nachverfolgbarkeit der Abstammung jedes Schritts.
Auf der Ausführungsseite gibt es einen Schalter, der es wert ist, separat notiert zu werden: orx up --remote user@host. Ein und derselbe committed Code-Snapshot kann lokal, auf SSH-Remote-Maschinen, Slurm-Clustern, K8s, Ray, HuggingFace Jobs, Modal, Tinker oder in gehosteten Umgebungen laufen – Browser und Daten verbleiben auf Ihrem Laptop, während die Berechnung auf die entfernte GPU ausgelagert wird. Für Personen, deren Rechenleistung nicht lokal fest installiert ist, entscheidet dieser Schalter darüber, ob es ein Spielzeug ist oder nicht: Der Großteil der Rechenleistung bei Forschungsexperimenten liegt im Training, der Laptop dient nur zum Betrachten der Ergebnisse.
3. Hardcore-Zerlegung: Das Dreierpack auf Quellcode-Ebene
Das ist der Kernpunkt des gesamten Textes. Die README spricht von „local-first“, „Isolierung“ und „Reproduzierbarkeit“ – das sagen alle Tools. Wenn man den Quellcode aufbricht, sieht man, dass drei Dinge sehr konkret umgesetzt wurden: Isolierung von Experimentbaum und worktree, der Playbook-Injektionsmechanismus und die Modularisierung von agent-skills. Man kann sogar die Zeilennummern genau angeben.
3.1 Isolierung von Experimentbaum und worktree
Die größte Gefahr bei Forschungs-Agents ist die Kreuzkontamination: Zwei Agents aus verschiedenen Richtungen ändern Code im selben Verzeichnis, überschreiben sich gegenseitig, und am Ende kann niemand mehr sagen, welches Ergebnis aus welchem Code stammt. Die Antwort von OpenResearch liegt in ensure_session_worktree in src/local/git.rs – bei jedem Start einer Sitzung wird sichergestellt, dass sie ihre eigene git worktree hat. Der Quellcode-Kommentar formuliert das Prinzip sehr deutlich: „one opencode serve child per chat session, cwd=私有 worktree“. Eine Sitzung, ein Agent-Subprozess, das Arbeitsverzeichnis ist eine private worktree. Auf Dateisystem-Ebene sind die beiden Richtungen damit getrennt; die Agents benötigen dafür kein besonderes Bewusstsein.
Über der worktree steht der Experimentbaum. Jeder experimentelle run entspricht einem Commit auf diesem Baum, eine unveränderliche Archivierung – nach dem Ende des Runs werden dieser Code, diese Konfiguration und diese Eingabe nicht mehr geändert. Spätere Vergleiche finden immer mit einem historischen Snapshot statt, nicht mit einem Haufen lebendigen Codes. Der Wert dieses Designs zahlt sich in dem Moment aus, in dem man das Paper schreibt: Jede Zahl lässt sich auf einen wiederspielbaren Baum zurückverfolgen. Wenn ein Gutachter es reproduzieren will, checkt er den Baum einfach aus und lässt ihn erneut laufen. Git ist hier kein Zusatz zur Versionskontrolle, sondern die Datenstruktur des Experiments selbst – das ist die wahre Bedeutung der drei Worte „git nativ“.
3.2 Playbook-Injektion: Jeden Agenten umprogrammieren
Die erste Hürde bei der Modifikation von Coding-Agents ist der System-Prompt. OpenResearch verlangt nicht, dass Benutzer Forschungsanweisungen manuell in die Konfigurationsdateien der verschiedenen Tools schreiben. Stattdessen ist ein SYSTEM_PROMPT.md eingebaut – ein Forschungs-Playbook, das bei orx up über die nativen Kanäle der jeweiligen Agents in jede Sitzung injiziert wird. Die drei Kanäle haben im Quellcode jeweils ihren Ankerpunkt: Claude Code nutzt Kommandozeilenparameter und ruft src/local/claude.rs:481 mit --append-system-prompt-file auf; Codex nutzt das Feld developerInstructions; OpenCode nutzt die instructions-Liste in der config. Dasselbe Playbook, drei Harnesses, jeder füttert es über den Kanal ein, den er akzeptiert – das ist die wahre technische Bedeutung von „turn your coding agents“: kein Hijacking, kein Patching, sondern native Mechanismen. Der Agent glaubt, er macht einfach seine normale Arbeit.
Das Playbook selbst ist kein statischer Text. playbook_md() in src/local/opencode.rs:179 ersetzt beim Rendern eine Reihe von {token}-Platzhaltern: Projektfakten, aktueller Status, Standardwerte für Rechenleistung, Artefakt-Pfade. Das bedeutet: Wenn dieselbe Claude Code-Sitzung in OpenResearch gestartet wird, erhält sie eine Forschungs-Rollenkarte, die weiß, in welchem Projekt sie sich befindet, wo die Artefakte liegen und wo standardmäßig Berechnungen ausgeführt werden – und nicht ein generisches „Du bist ein hilfreicher Assistent“. Das Kontext-Engineering beginnt in der ersten Sekunde der Sitzung, was dem Benutzer die paar hundert Wörter erspart, die er sonst jedes Mal manuell zur Erklärung des Hintergrunds schreiben müsste.
3.3 agent-skills: Ein Forschungs-Skillset aus 12 Modulen
Die zweite Hürde sind die Fähigkeiten. Nur chatten zu können reicht nicht, die Forschung hat ihre eigenen Abläufe: wie man eine Literaturrecherche durchführt, wie man Experimente archiviert, wie man Diagramme erstellt und wie man Berichte schreibt. Im Verzeichnis agent-skills/ sind nach Ablaufschritten 12 Module unterteilt: orx-agent-delegation (wie Aufgaben zwischen Agents delegiert werden), orx-compute (Rechenleistungsplanung), orx-create, orx-customize, orx-evidence (Beweisverwaltung), orx-experiment-tree (Operationen am Experimentbaum), orx-figures (Diagrammerstellung), orx-git, orx-instances (Verwaltung von Laufzeitinstanzen), orx-lit-review (Literaturrecherche), orx-paper (Verfassen von wissenschaftlichen Arbeiten), orx-reports (Berichterstellung). Jedes Modul enthält eine SKILL.md, die mit vier „cardinal rules“ beginnt – erst werden die roten Linien der Forschungsarbeit gezogen, dann wird darüber gesprochen, wie die Arbeit zu erledigen ist. Innerhalb einer Sitzung werden sie bei Bedarf über orx skill <name> geladen; es wird nur das abgerufen, was gebraucht wird, und nicht alles auf einmal in den Kontext gestopft.
Das Gesamtbild, das sich aus diesem Dreiergespann ergibt, ist: Die worktree-Isolation gewährleistet, dass es physisch keine Vermischung gibt, die playbook-Injektion stellt sicher, dass jede Sitzung von der ersten Sekunde an nach den Regeln der Forschung verläuft, und die 12 Fähigkeitsmodule garantieren, dass der Agent weiß, wie man Literaturrecherchen und Experimentarchivierungen jeweils durchzuführen hat. Die Harness-Verwaltungsebene befindet sich unter src/local/harness/ und umfasst sechs Dateien: claude.rs, codex.rs, cursor.rs, opencode.rs, opencode_v2.rs und detect.rs. Sie wird einheitlich vom AgentHost (ein lokaler Dienst basierend auf axum) verwaltet – die parallele Ausführung mehrerer Agents bedeutet nicht, dass mehrere Prozesse chaotisch laufen, sondern dass ein lokaler Host die zentrale Steuerung übernimmt; dabei ist detect dafür zuständig, zu erkennen, welche verfügbaren Harnesses auf dem Computer installiert sind. Rust ist eine vernünftige Wahl für diese Ebene: Der Hostprozess muss lange laufen, gleichzeitig mehrere Unterprozesse verwalten, und hier kommen sowohl Speichersicherheit als auch das Nebenläufigkeitsmodell zum Einsatz.
4. Nüchterner Blick
Lassen Sie uns zunächst die Kriterien klären. 4.941 Stars sind das Ergebnis von etwas mehr als zwei Monaten, und das README trägt das Abzeichen für den ersten Platz bei Trending – das ist eine faktische Aussage; aber die Wachstumsrate der Stars und die Brauchbarkeit des Tools sind zwei verschiedene Paar Schuhe. Bei einem Projekt, das erst zwei Monate alt ist, liegen 42 offene Issues vor, und die Schnittstellen und Befehle in den 515 Dateien sind noch in Bewegung. Die heute geschriebene Integrationsmethode könnte sich morgen ändern – die MIT-Lizenz deckt jedoch den Worst Case ab, sodass die Version, die Sie besitzen, weiterhin genutzt werden kann, selbst wenn das Projekt nicht mehr aktualisiert wird.
Zweitens ist „Local First“ (lokale Priorität) sowohl ein Vorteil als auch eine Grenze. Artefakte, Beweise und Code liegen alle im lokalen Git, das Eigentum ist klar, es funktioniert offline, und bei der Verbindung mit lokalen Modellen verlassen die Daten den Rechner nicht – das sind harte Anforderungen für diejenigen, die mit unveröffentlichten Daten und Ergebnissen arbeiten; Arbeit vor der Einreichung gehört ohnehin nicht in die Cloud. Umgekehrt fehlt ihm derzeit eine zentrale Freigabeebene: Teamzusammenarbeit, Veröffentlichung von Ergebnissen und Synchronisation zwischen Geräten müssen Sie selbst durch die Nutzung der vorhandenen Git-Mechanismen zusammenfügen, das Tool übernimmt das nicht für Sie. Menschen, die an die GitHub-Art der Zusammenarbeit gewöhnt sind, werden hier spüren, dass etwas fehlt.
Drittens sollte die Autonomie von Autoresearch so verstanden werden, wie sie beworben wird. Die Beschreibung im README lautet „Idee einreichen → Code ändern → Experimente laufen → Beweise ansehen → Nächste Schritte festlegen“. Die Richtung ist glaubwürdig, aber die Qualität jedes Durchlaufs hängt von dem Modell ab, an das Sie anschließen, und von der Rechenleistung, die Sie bereitstellen. Wenn der Agent die falsche Richtung wählt, kostet das die Rechenleistung für einen ganzen Versuchsbaum. Es ist in Ordnung, es als automatisierten Forschungsassistenten zu nutzen, als Forscher, der eigenständig Schlussfolgerungen ziehen kann, ist es jedoch derzeit nicht geeignet.
Viertens, Windows ist immer noch Beta. Für Personen, deren Hauptentwicklungsmaschine ein Mac oder Linux ist, ist dies kein Problem, aber Windows-Nutzer sollten zunächst abwägen, ob sie die Git-Umgebung und den Beta-Status akzeptieren können.
5. Lohnt es sich?
Aufgeteilt nach Zielgruppen. Für diejenigen, die in den Bereichen ML, Systeme oder einer anderen Forschungsrichtung tätig sind, die Experimente erfordert, und die bereits Claude Code oder OpenCode nutzen, ist dies der reibungsloseste Integrationspfad: Kein Toolwechsel, keine Gewohnheitsänderung, nach orx up verfügt dein ursprünglicher Agent über das wissenschaftliche Rückgrat – Experimentbaum, Worktree-Isolierung, Playbook, Skillpakete sind allesamt vorhanden, die Lernkurve ist fast null. Für diejenigen, die Modelle lokal ausführen müssen (daten- oder budgetempfindlich), funktionieren LM Studio, oMLX, Ollama per Direktverbindung, die volle Kontrolle über die Rechenleistung bleibt gewahrt. Für diejenigen, deren Rechenleistung remote liegt, verlagert der Befehl orx up --remote die Berechnung nach außen, während Browser und Artefakte lokal verbleiben; diese Form ist wesentlich gesünder, als es auf dem Laptop hart durchzuziehen.
Auch die Fälle, in denen man abwarten sollte, sind klar: Wer keine experimentelle Forschung betreibt und nur Papers lesen und Notizen machen muss, wird die meisten der 12 Skillmodule nicht brauchen; das ist wie mit Kanonen auf Spatzen schießen, ein praktischer Notizen-Workflow reicht aus. Wer stark auf Teamzusammenarbeit und zentrales Ergebnismanagement angewiesen ist, für den läuft die lokal-first-Architektur den Anforderungen zuwider. Wer erwartet, dass „der Agent mir automatisch ein Paper schreibt“, wird enttäuscht sein, denn Autoresearch ist eine Prozessunterstützung und kein Ghostwriting; falsche Erwartungen führen zu Enttäuschung. Außerdem sorgen die MIT-Lizenz und der lokale Betrieb dafür, dass die Kosten für Versuch und Irrtum sehr gering sind – installiere es, nimm eine kleine Reproduktionsaufgabe und gehe den Prozess einmal durch; ob es dir liegt, weißt du nach einem halben Tag. Das ist die lohnenswerteste Art, solche Tools direkt auszuprobieren.
Fazit
OpenResearch beantwortet eine Frage, die lange vermieden wurde: Müssen Forschungs-Agents neu erschaffen werden? Die Antwort ist nein – die Reasoning- und Werkzeugfähigkeiten von Claude Code, Codex, OpenCode und Cursor sind bereits ausreichend; was fehlt, ist die Struktur der Forschung, und diese Struktur kann durch Engineering ergänzt werden. Im Quellcode wird diese Einschätzung sehr konkret umgesetzt: ensure_session_worktree verleiht jeder Sitzung eine private Worktree, eine SYSTEM_PROMPT.md wird über die drei nativen Kanäle --append-system-prompt-file (claude.rs:481), developerInstructions und config instructions in die jeweiligen Sitzungen injiziert, playbook_md() füllt beim Rendern Projektfakten und Standardwerte für Rechenleistung ein, 12 Agent-Skills-Module werden über orx skill bei Bedarf geladen, und die Harness-Ebene wird von AgentHost einheitlich koordiniert. Der Experimentbaum wächst auf Git; jeder Run ist ein unveränderliches Archiv, und Reproduzierbarkeit wird von einem Versprechen zu einer Datenstruktur. Für diejenigen, die bereits Coding-Agents für die Forschung nutzen, ist dies derzeit die vollständigste Lösung des „Anpassens statt Neuerfindens“; für diejenigen, die Agent-Engineering erforschen, demonstriert es, wie man „Local-First“ vom Slogan zur Zeilennummer bringt.
Referenzquellen
- alphaXiv/OpenResearch README（GitHub；Positionierung, Installation, Tabelle der sechs Hauptfähigkeiten, Autoresearch, Ausführungsebene）
- OpenResearch-Quellcode (lokaler Klon): src/local/git.rs (ensure_session_worktree), src/local/claude.rs:481 (—append-system-prompt-file), src/local/opencode.rs:179 (playbook_md), src/local/harness/ (claude.rs / codex.rs / cursor.rs / opencode.rs / opencode_v2.rs / detect.rs), agent-skills/ (12 SKILL.md-Dateien)
- Repository-Daten: 4,941★, Forks 305, Issues 42, MIT, erstellt am 2026-06-07 (Stand 2026-09-18)