AutoResearchClaw: 23 Stufen von der Idee zum Paper, mit Gates dazwischen
Völlig autonome und sich selbst entwickelnde Forschung von der Idee bis zum Papier. Chatten Sie mit einer Idee. Holen Sie sich ein Papier.
Auf einen Blick
- Was ist das?
- AutoResearchClaw ist eine in Python geschriebene Forschungspipeline, die ein Thema über 23 Stufen in ein LaTeX-Paper überführt, mitten drin drei Gates für menschliche Freigabe. Der Überblick behandelt die Stufenabfolge, config.arc.yaml, den Human-in-the-Loop-Modus ab v0.4.0, ARC-Bench und die Maßnahmen gegen erfundene Zitate.
- Für wen ist es gedacht?
- AutoResearchClaw passt zu Forschungsgruppen, die einen wiederholbaren Ablauf für Literatur, Experiment und Papierentwurf suchen und bereit sind, die Gates bei Stufe 5, 9 und 20 selbst zu bedienen.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 28 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
Die 23 Stufen von TOPIC_INIT bis CITATION_VERIFY
AutoResearchClaw beschreibt sich als Pipeline, die eine Forschungsfrage aufnimmt und ein vollständiges akademisches Paper zurückgibt. Die Repository-Metadaten nennen es fully autonomous and self-evolving research from idea to paper, als Sprache ist Python angegeben, die Lizenz ist MIT. Das Projekt liegt bei 14266 Sternen, 1659 Forks und 8 offenen Issues.
Die README gliedert den Ablauf in acht Phasen mit 23 Stufen, beginnend bei TOPIC_INIT und endend bei CITATION_VERIFY. Phase A grenzt das Forschungsthema ab, Phase B sammelt Literatur über OpenAlex, Semantic Scholar und arXiv, Phase C synthetisiert das Wissen und bildet Hypothesen, Phase D entwirft Experimente und erzeugt Code, Phase E führt sie in einer Sandbox aus, Phase F wertet aus und entscheidet mit PROCEED, REFINE oder PIVOT über das weitere Vorgehen, Phase G schreibt und begutachtet das Paper, Phase H schließt mit Qualitätsgate, Wissensarchivierung und LaTeX-Export für Vorlagen wie NeurIPS, ICML oder ICLR ab.
Gates bei Stufe 5, 9 und 20 sowie was --auto-approve abschaltet
Drei Stufen sind als Gates ausgelegt: 5, 9 und 20. Standardmäßig hält die Pipeline dort an und wartet auf eine menschliche Freigabe. Mit der Option --auto-approve werden diese Stopps übersprungen, der Lauf endet dann ohne Zwischenprüfung.
Der empfohlene Einstieg läuft über die Brücke OpenClaw. Man teilt dem Agenten die Repository-URL mit, dieser liest RESEARCHCLAW_AGENTS.md, installiert die Pipeline und startet sie auf die Aufforderung Research [Thema]. Daneben existiert ein eigenständiges Kommandozeilen-Interface mit researchclaw run --topic "..." --auto-approve, eine Python-API über from researchclaw.pipeline import Runner sowie der Betrieb mit jedem ACP-kompatiblen Backend, genannt werden Claude Code, Codex CLI, Copilot CLI, Gemini CLI und Kimi CLI. Über die OpenClaw-Brücke lassen sich zusätzlich Messenger wie Discord, Telegram, Lark und WeChat anbinden.
config.arc.yaml: simulated, sandbox, docker und ssh_remote im Vergleich
Die Konfiguration liegt in config.arc.yaml. Die README führt dort Referenzen für Projekt, Forschung, Laufzeit, LLM-Anbieter, Literaturrecherche, Experimentmodus, Export-Zielkonferenz, HITL-Einstellungen, Sicherheitsoptionen und Wissensdatenbank-Backend auf.
Beim Experimentmodus gibt es vier Werte: simulated, sandbox, docker und ssh_remote. Der Unterschied betrifft die Frage, ob überhaupt etwas gerechnet wird. Im Modus simulated werden Ergebnisse erzeugt, ohne dass eine Ausführungsumgebung beteiligt ist, in sandbox, docker und ssh_remote läuft der erzeugte Code tatsächlich, entweder lokal abgekapselt, im Container oder auf einem entfernten Rechner. Für jede Aussage über Messwerte in einem erzeugten Paper ist das die Voreinstellung, die man in config.arc.yaml zuerst prüfen sollte.
HITL v0.4.0: sechs Interventionsmodi und die Befehle attach, status, approve, reject, guide
Mit v0.4.0 vom 1. April 2026 ist AutoResearchClaw nicht mehr rein autonom. Das Human-in-the-Loop-System bringt sechs Interventionsmodi: full-auto, gate-only, checkpoint, step-by-step, co-pilot und custom. Sie steuern, wie oft die Pipeline für menschliche Eingaben anhält, und lassen sich pro Stufe als Richtlinie festlegen.
Zum Funktionsumfang gehören eine Idea Workshop für die gemeinsame Hypothesenbildung, ein Baseline Navigator zur Prüfung des Versuchsdesigns, ein Paper Co-Writer für das gemeinsame Schreiben, SmartPause für konfidenzgesteuertes Pausieren, ein Interventionslernen namens ALHF, eine Behauptungsprüfung gegen Halluzinationen, Kostenbudget-Grenzen und eine Verzweigung der Pipeline für parallele Hypothesen. Bedient wird das über die Befehle attach, status, approve, reject und guide, beschrieben in docs/HITL_GUIDE.md. Ein Beispiel aus der README zeigt eine Prüfung in Stufe 8, bei der Dropout, Label Smoothing, MixUp und CutMix als Baselines nachgefordert werden.
ARC-Bench mit 55 Themen und die Fach-Agenten ColliderAgent, COBRApy und Docker-Executor
Mit v0.5.0 vom 19. Mai 2026 kamen zwei Erweiterungen. Die erste betrifft die Experimentphase: Die Stufen 10 bis 13 werden nicht mehr zwingend in der Standard-ML-Sandbox ausgeführt, sondern an Fach-Agenten weitergeleitet. Für Hochenergiephysik übernimmt ColliderAgent die Kette von Lagrangian über FeynRules und MadGraph5 bis Delphes über die Magnus-Cloud, für Biologie steht genomskalige Stoffwechselmodellierung mit COBRApy bereit, für Statistik ein Simulations-Agent, und ein generischer Docker-Executor deckt Chemie und Materialforschung ab. Die Auswahl erfolgt laut README automatisch anhand der Forschungsdomäne.
Die zweite Erweiterung ist ARC-Bench, ein Benchmark mit 55 offen formulierten Forschungsthemen: 25 aus dem Maschinellen Lernen, 10 aus Hochenergiephysik, 10 aus Quantenphysik, 7 aus Biologie und 3 aus Statistik. Jedes Thema bringt ein Manifest mit Forschungsfrage, Bedingungen, Metriken und Datensätzen mit sowie ein Bewertungsschema. Die Dateien liegen unter experiments/arc_bench/ und sind zusätzlich auf Hugging Face unter AIMING-Lab-UNC/ARC-Bench veröffentlicht.
VerifiedRegistry, vierstufige Zitierprüfung und die Ausgaben unter artifacts/rc-
Gegen erfundene Belege setzt das Projekt mehrere Mechanismen. Die Zitierprüfung läuft über vier Stufen: arXiv, CrossRef, DataCite und eine Relevanzbewertung durch ein Sprachmodell. Eine VerifiedRegistry erzwingt, dass im Paper nur verifizierte Experimentdaten landen, und fehlgeschlagene Experimente durchlaufen eine Diagnose- und Reparaturschleife. Die README beziffert den Testbestand mit 2699 bestandenen Tests, ohne die Prüfmethode offenzulegen.
Pro Lauf entstehen paper_draft.md, paper.tex, references.bib und verification_report.json, dazu Experimentläufe mit Code und Metriken, Diagramme, Notizen des Multi-Agenten-Reviews, ein Verzeichnis evolution/ für selbst gelernte Lektionen und ein Ordner deliverables/ mit den Endergebnissen. Abgelegt wird das unter artifacts/rc-YYYYMMDD-HHMMSS-hash/deliverables/. Wer die Pipeline bewerten will, sollte zuerst verification_report.json lesen, dort steht, welche Behauptungen geprüft wurden.
Grenzen der Autonomie und die Alternative: externe CLI-Agenten für Stufe 10 und 13
Die auffälligste Grenze liegt in der Stofffülle selbst. Ein 23-stufiger Ablauf erzeugt viele Artefakte, deren Qualität von der Konfiguration in config.arc.yaml und vom gewählten Sprachmodell abhängt. Die README nennt keine unabhängigen Messwerte zur Papierqualität; die Angaben zu 8 Showcase-Papers, zu ARC-Bench und zur MetaClaw-Brücke sind Projektangaben. Die MetaClaw-Brücke ist standardmäßig aus (metaclaw_bridge.enabled: true schaltet sie ein), die README berichtet von einem Anstieg des zusammengesetzten Robustheitswerts von 0.714 auf 0.845 in einem kontrollierten Experiment, ohne die Methodik vollständig zu beschreiben. Ein zugehöriges Paper liegt auf arXiv unter 2605.20025.
Wer die Pipeline nicht vollständig einsetzen will, findet im Projekt selbst eine Alternative: Seit v0.3.2 kann die Codeerzeugung in den Stufen 10 und 13 an externe CLI-Agenten delegiert werden, mit eigener Budgetkontrolle und Timeout-Verwaltung. Der Unterschied zum integrierten Weg ist klar benennbar. Der externe Agent bringt seine eigene Umgebung und seine eigenen Stärken mit, liefert aber keine Anbindung an die VerifiedRegistry und an die Diagnose- und Reparaturschleife, sodass die Absicherung gegen erfundene Ergebnisse am Menschen hängen bleibt. Für die Absicherung ist der integrierte Weg mit sandbox oder docker vorzuziehen, für einzelne schwierige Codeaufgaben die Delegation an den CLI-Agenten.
Redaktionelles Fazit
AutoResearchClaw passt zu Forschungsgruppen, die einen wiederholbaren Ablauf für Literatur, Experiment und Papierentwurf suchen und bereit sind, die Gates bei Stufe 5, 9 und 20 selbst zu bedienen. Es passt nicht zu Nutzern, die einen Knopfdruck erwarten und das Ergebnis ungeprüft abgeben wollen: Die README rät selbst zum Human-in-the-Loop-Betrieb, und die Anti-Fabrikationsmechanismen greifen nur, wenn Experimente tatsächlich in sandbox, docker oder ssh_remote laufen und nicht im Modus simulated. Vor dem ersten Lauf klären: Welcher LLM-Anbieter ist konfiguriert, welcher Experimentmodus steht in config.arc.yaml, und sind die Ausgaben unter artifacts/rc-YYYYMMDD-HHMMSS-hash/deliverables/ mit verification_report.json als Prüfprotokoll ausreichend für die eigene Qualitätssicherung.
Community-Notizen