Paper2Agent: Was Unternehmen von Stanfords KI-Agenten lernen

Aus einer Studie wird ein Agent

Wissenschaftliche Veröffentlichungen haben ein Problem, das auch viele Unternehmen kennen: Das Wissen steckt in Texten und Code, aber wer es nutzen will, muss sich mühsam einarbeiten, Umgebungen aufsetzen und hoffen, dass die Beispiele noch laufen. Ein Team der Stanford University um James Zou hat dafür eine Lösung entwickelt, die im September 2026 in Nature erschienen ist: Paper2Agent verwandelt eine Veröffentlichung samt Code in einen KI-Agenten – einen „virtuellen korrespondierenden Autor", der Fragen beantwortet und die Methoden der Studie auf neue Daten anwendet.

Das Projekt stammt aus der Biologie. Die Idee dahinter ist aber für jedes Unternehmen interessant, das eigenen Code, eigene Bibliotheken oder Fachwissen für KI-Agenten nutzbar machen will. Denn die Studie liefert harte Zahlen zu einer Frage, die viele umtreibt: Reicht es, einem Agenten einfach das Repository zu geben – oder lohnt es sich, ihm geprüfte Werkzeuge zu bauen?

Wie Paper2Agent arbeitet

Paper2Agent ist als Multi-Agenten-System mit dem Agent SDK von Claude Code umgesetzt. Ein zentraler Orchestrator steuert spezialisierte Sub-Agenten, die jeweils eine klar umrissene Rolle und begrenzte Rechte haben. Gemeinsam durchlaufen sie sechs Schritte:

1. den Code der Studie finden und herunterladen,
2. eine isolierte Umgebung aufsetzen,
3. die Tutorials und Beispiele im Code identifizieren,
4. diese Tutorials ausführen und prüfen,
5. daraus parametrisierte Werkzeuge ableiten, gegen die Referenzergebnisse testen und so lange nachbessern, bis sie stimmen – Werkzeuge, die dauerhaft scheitern, fliegen raus,
6. die geprüften Werkzeuge zu einem MCP-Server zusammenbauen.

flowchart TD
    P["Veröffentlichung und Code"] --> O[Orchestrator]
    O --> U["Code laden und<br/>Umgebung aufsetzen"]
    U --> TU["Tutorials finden<br/>und ausführen"]
    TU --> W[Werkzeuge ableiten]
    W --> T{"Test gegen<br/>Referenzergebnisse"}
    T -->|scheitert| W
    T -->|bestanden| M["MCP-Server mit<br/>geprüften Werkzeugen"]
    M --> A["Agent, etwa Claude Code oder Codex"]

Das Ergebnis ist ein MCP-Server, den jeder MCP-fähige Agent nutzen kann, etwa Claude Code oder Codex. Wichtig ist Schritt 5: Jedes Werkzeug wird gegen die Ergebnisse der Originalstudie geprüft und anschließend festgeschrieben. Damit soll verhindert werden, dass der Agent bei jeder Anfrage neuen, womöglich fehlerhaften Code erzeugt – die Autoren sprechen von „Code-Halluzination".

Inzwischen gibt es Paper2Agent auch als Agent Skill für Claude Code und Codex. Man installiert den Skill und lässt ihn eine Veröffentlichung oder ein Code-Repository in Werkzeuge umwandeln.

Was die Studie zeigt

Die Zahlen aus der Nature-Veröffentlichung sind bemerkenswert:

• Breite: Von 100 Veröffentlichungen aus der computergestützten Biologie ließen sich 74 vollständig automatisch in Agenten umwandeln. Dabei entstanden 599 Werkzeuge, von denen 593 die automatische Prüfung bestanden.
• Genauigkeit: Bei 300 Testfragen erreichte Paper2Agent 91,2 % Genauigkeit. Claude Code mit direktem Zugriff auf das Repository kam mit demselben Modell auf 80,3 %, mit einem neueren Modell auf 86,3 %.
• Kosten und Tempo: Pro Anfrage kostete Paper2Agent 0,20 US-Dollar und brauchte 1,6 Minuten – gegenüber 0,38 US-Dollar und 4,3 Minuten, wenn das Modell direkt mit Studie und Repository arbeitete.
• Aufwand: Für ein großes Genomik-Modell erzeugte Paper2Agent 22 geprüfte Werkzeuge in rund 45 Minuten, für 14 US-Dollar, auf einem normalen Laptop.
• Über die Biologie hinaus: Bei 42 Aufgaben aus zehn Veröffentlichungen anderer Fachgebiete lag die Genauigkeit bei 98,1 %.

Was Unternehmen daraus lernen können

Die wichtigste Erkenntnis ist nicht biologisch, sondern architektonisch: Geprüfte Werkzeuge schlagen rohen Zugriff auf den Code. Ein Agent, der für jede Frage selbst im Repository suchen und Code schreiben muss, ist ungenauer, teurer und langsamer als einer, der auf vorbereitete, getestete Werkzeuge zugreift.

Das lässt sich direkt auf Unternehmen übertragen. Viele haben Code, der Fachwissen enthält: Berechnungsroutinen, interne Bibliotheken, Auswertungen, ältere Werkzeuge, die nur noch wenige Mitarbeitende bedienen können. Statt einem Agenten einfach das Repository zu geben, lohnt es sich, daraus geprüfte Werkzeuge zu machen – genau so, wie Paper2Agent es vormacht:

• Beispiele und Tests sind der Schlüssel. Paper2Agent baut seine Werkzeuge aus vorhandenen Tutorials und prüft sie gegen bekannte Ergebnisse. Code ohne Beispiele und Tests lässt sich deutlich schlechter umwandeln.
• Reproduzierbare Umgebungen zählen. Ein großer Teil der gescheiterten Umwandlungen lag an fehlendem Code, fehlenden Daten oder Umgebungen, die sich nicht aufsetzen ließen.
• MCP ist das verbindende Format. Ein so gebauter MCP-Server lässt sich in Claude Code, GitHub Copilot oder andere Werkzeuge einbinden. Wie man eigene MCP-Server mit .NET baut, zeigen wir in Eigene MCP-Server mit .NET entwickeln: ein Praxisleitfaden.

Die Autoren sprechen davon, dass sich an der „Agentifizierbarkeit" einer Veröffentlichung ablesen lässt, wie gut sie reproduzierbar ist. Für Unternehmen gilt dasselbe: Wie leicht sich eigener Code in Agenten-Werkzeuge verwandeln lässt, ist ein guter Gradmesser für seine Wartbarkeit.

Was man beachten sollte

Nicht alles gelingt. Ein Viertel der Veröffentlichungen ließ sich nicht umwandeln. Bei gewachsenem Unternehmenscode dürfte die Quote eher niedriger liegen.

Werkzeuge brauchen Pflege. Die Autoren weisen selbst darauf hin, dass solche Agenten laufend gepflegt werden müssen, wenn sich Code und Abhängigkeiten ändern.

Sicherheit und Rechte. Während der Umwandlung führen Agenten fremden Code mit Shell-Zugriff aus. Das gehört in eine abgeschottete Umgebung, nicht auf einen Arbeitsrechner mit Zugriff auf Produktivsysteme. Die Autoren nennen außerdem Sicherheit, geistiges Eigentum und Urheberschaft ausdrücklich als Herausforderungen. Und während die Studien-Agenten öffentlich auf Hugging Face laufen, gehören MCP-Server mit internem Code und Daten in die eigene Infrastruktur. Mehr dazu in Warum KI-Agenten im Unternehmen echte Sandboxes brauchen.

Kein Orakel. Die Autoren verstehen Paper2Agent ausdrücklich als Werkzeug, das Forschung unterstützt – nicht als eigenständige oder maßgebliche Quelle wissenschaftlicher Schlussfolgerungen. Für Unternehmenswerkzeuge gilt sinngemäß dasselbe: Der Agent bedient die Werkzeuge, die Verantwortung für das Ergebnis bleibt beim Menschen.

Aus unserer Praxis

Die Erkenntnis der Studie deckt sich mit unserer eigenen Erfahrung. Wir bauen eigene MCP-Server, etwa für unser CMS und unsere Zeiterfassung, statt Agenten direkt auf Datenbanken oder Code loszulassen. Ein Agent, der über ein klar definiertes Werkzeug einen Artikel anlegt oder eine Buchung abfragt, arbeitet verlässlicher als einer, der sich den Weg selbst suchen muss. Wie so ein Werkzeugpaket in der Praxis aussieht, zeigt unser Beitrag Agent-Plugin in der Praxis: eine LaTeX-Schreibstube für Claude Code.

Fazit

Paper2Agent zeigt mit belastbaren Zahlen, was viele in der Praxis vermuten: Agenten werden besser, günstiger und schneller, wenn man ihnen geprüfte Werkzeuge statt rohen Code gibt. Für Unternehmen ist das eine klare Empfehlung, beim Einsatz von KI-Agenten nicht nur auf das Modell zu schauen, sondern auf die Werkzeuge, mit denen es arbeitet. Wann ein Agent und wann ein fest umrissener Skill die richtige Wahl ist, beschreiben wir in KI-Agenten vs. Skills; wie Skills, Plugins und MCP-Server zusammenspielen, in Plugin, Agent, Skill oder MCP: wer steckt eigentlich in wem?.

Sie möchten eigenen Code oder eigene Fachanwendungen für KI-Agenten nutzbar machen? Mehr zu unserem Angebot finden Sie unter MCP-Integrationen für Unternehmen. Oder sprechen Sie uns direkt an.

Quellen: Nature – Reimagining research papers as interactive and reliable AI agents (16.09.2026) · Nature – Research Briefing: Turning scientific research papers into interactive AI agents · arXiv – Paper2Agent (Preprint) · GitHub – jmiao24/Paper2Agent