riceprompt-engine: Agenten-Workflows als eine YAML-Datei, ausgeführt in Rust
YAML-native agent workflow execution engine, written in Rust
Auf einen Blick
- Was ist das?
- Der Autor beschreibt die Engine als YAML-native Laufzeit für Agenten-Graphen mit LLM-Knoten, MCP-Werkzeugen und Datenkonnektoren. Der Ansatz ist reizvoll für alle, die Workflow-Topologie versionieren wollen, aber die Version 0.1.x und die dünne Dokumentationslage verlangen genaue Prüfung vor einem Einsatz.
- Für wen ist es gedacht?
- Wer Agenten-Abläufe als versionierbaren Graphen in einer Datei pflegen und in eine Rust-Anwendung einbetten will, findet hier ein passendes Modell. Wer stabile APIs, publizierte Release Notes oder ausführliche Anleitungen braucht, sollte zuerst docs/FLOW_SPEC.md gegen die eigenen Knotentypen prüfen und die genaue Version pinnen, weil der Autor selbst API-Änderungen zwischen Minor-Versionen ankündigt.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 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 141 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, 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
Ein Graph statt verstreuter Prompt-Aufrufe
In den meisten Agenten-Projekten liegt die Logik verstreut: ein Prompt in einer Konstanten, die Reihenfolge im Anwendungscode, der Datenbankzugriff in einer Hilfsfunktion. riceprompt-engine zieht das in eine einzige YAML-Datei. Knoten, Kanten, Templates, Provider und Datenquellen stehen dort deklarativ nebeneinander, die Engine parst die Datei, löst Abhängigkeiten auf und führt den Graphen aus. Das README nennt als Zielgruppe ausdrücklich den eigenen Anwendungsfall: die Engine treibt RicePrompt an, eine visuelle IDE, in der dieselben YAML-Dateien per Graph-Editor entstehen. Wer diese YAML von Hand schreibt, ist damit Zweitnutzer eines Formats, das primär für ein graphisches Werkzeug entworfen wurde. Genau das ist die interessante Spannung: Ein Dateiformat als Schnittstelle zwischen Editor und Laufzeit ist versionierbar, diffbar und in Code-Reviews lesbar. Ob es sich ohne den Editor ebenso angenehm pflegen lässt, sagt das Material nicht.
Knotentypen als eigentliche Architektur
Die Struktur der Engine zeigt sich weniger im Ausführungsmodell als im Katalog der Knotentypen. generate ruft ein Modell auf, transform führt Rhai-Skripte aus, iterator läuft über Datenmengen, supervisor verteilt an mehrere Agenten, subgraph bettet einen weiteren Graphen ein, data_connector spricht mit externen Systemen, mcp und mcp_tools binden Model-Context-Protocol-Werkzeuge an, skill_set bündelt Wissen nach dem Muster der progressiven Offenlegung. Das ist eine breite Oberfläche für Version 0.1. Jeder dieser Typen muss in docs/FLOW_SPEC.md definiert sein, denn das README bezeichnet diese Datei als maßgebliche Spezifikation. Wer den Funktionsumfang bewerten will, kommt um dieses Dokument nicht herum; das README allein nennt nur die Namen. Bemerkenswert ist die Entscheidung für Rhai statt JavaScript oder Lua in transform: Das hält die Engine abhängigkeitsarm, bindet Nutzer aber an eine kleine Skriptsprache mit eigener Semantik. Für kurze Datenumformungen reicht das, für alles mit Ökosystem-Bibliotheken wird es eng.
Der Datenfluss durch die Kanten
Das Quick-Start-Beispiel macht den Mechanismus sichtbar. Drei Knoten (start, greet, response) sind über edges verbunden: von start zu greet, von greet zu response. Der generate-Knoten verweist mit template: tpl_greet auf einen Eintrag im templates-Block und füllt dessen user_prompt über variables. Die Zuordnung name: "start.name" ist ein Pfadausdruck in den Ausgaberaum eines vorherigen Knotens, kein gewöhnlicher Variablenname. Dasselbe Muster wiederholt sich bei der Ausgabe: output.greeting: "greet.output" zieht das Ergebnis des generate-Knotens in die Antwort. Daten fließen also nicht über einen globalen Kontext, sondern über benannte Pfade zwischen Knoten. Das ist nachvollziehbar und macht Abhängigkeiten explizit, verlangt aber, dass die Feldnamen der Vorgängerknoten exakt bekannt sind. Ein Tippfehler im Pfad ist ein Laufzeitproblem, kein Compilerfehler. Ob die Engine solche Pfade beim Parsen validiert, geht aus dem Material nicht hervor. Das ist eine der ersten Fragen, die man an die Spezifikation stellen sollte.
Einbetten in Rust: run_yaml und der Builder
Die Integration ist knapp gehalten. In Cargo.toml steht riceprompt-engine = "0.1", im Code erzeugt Engine::builder().build()? eine Instanz, und engine.run_yaml(&yaml, json!({ "name": "Ada" })) startet den Lauf. Das zweite Argument ist der Eingabekontext, der die Variablen im Graphen versorgt. Zurück kommt ein Ergebnis, das sich mit serde_json::to_string_pretty ausgeben lässt. Das README beschreibt ExecutionResult als selbstbeschreibend: Das Ergebnis kann die Quell-YAML enthalten, damit nachgelagerte Werkzeuge Topologie und Knotenergebnisse aus einer Datei rendern können. Für Debugging ist das praktisch, für große Läufe bedeutet es zusätzlichen Speicher und größere Logs. Provider-Zugangsdaten stehen im providers-Block und werden über ${OPENAI_API_KEY} aus der Umgebung gezogen. Das Beispiel zeigt nur OpenAI; die Liste im README nennt zusätzlich Anthropic, Gemini, DeepSeek, Qwen, Zhipu, Moonshot, MiniMax, xAI, Huoshan und jeden OpenAI-kompatiblen Endpunkt. Wie unterschiedlich diese Anbieter bei Tool-Calling und strukturierter Ausgabe reagieren, lässt sich aus dem README nicht ableiten.
Checkpointing, Harness und die Grenze des Bekannten
Zwei Funktionen stechen hervor, weil sie selten sind. Checkpoint und Resume erlauben, lang laufende Workflows anzuhalten und fortzusetzen; das README nennt sie, ohne Mechanik, Speicherort oder Granularität zu beschreiben. Die Harness-Schicht injiziert Workflow-Anweisungen im Stil einer CLAUDE.md in jeden generate-Knoten und unterstützt persistenten Speicher. Auch hier bleibt offen, wie Anweisungen mit Knoten-Prompts konkateniert werden und wie persistenter Speicher adressiert wird. Für einen Betreiber sind das keine Details: Wenn jede generate-Anweisung dieselbe Harness-Präambel enthält, wächst der Token-Verbrauch mit der Knotenzahl, und Fehler in der Präambel wirken überall gleichzeitig. Das sind Fragen, die vor einem Produktiveinsatz an der Spezifikation zu klären sind, nicht nach dem ersten Vorfall. Das Material liefert dazu keine Antworten, und ich werde keine erfinden.
Wann die Engine das falsche Werkzeug ist
Der Autor ist selbst deutlich: 0.1.x, die API kann sich zwischen Minor-Versionen ändern, bei Bedarf exakte Version pinnen. Wer eine stabile Schnittstelle für ein langlebiges Produkt braucht, plant hier Wartungsarbeit ein. Ein zweiter Punkt ist die Ausrichtung auf den visuellen Editor. Wer Workflows programmatisch aus vorhandenem Code erzeugen will, schreibt YAML als Zwischenformat und verliert die Typprüfung, die eine Rust-API bieten würde. Drittens die Skriptgrenze: transform kennt nur Rhai. Wer komplexe Datenverarbeitung mit ausgereiften Bibliotheken braucht, sollte diesen Schritt in einen eigenen Dienst auslagern und per data_connector oder REST anbinden, statt die Engine zu belasten. Und wer ohnehin nur einen einzelnen Modellaufruf mit einem Prompt braucht, trägt mit Graph, Kanten und Templates mehr Struktur ein, als der Fall verlangt.
Alternativen und der tatsächliche Unterschied
Der naheliegende Vergleich ist LangChain in seinen Ausprägungen für Rust und Python. Dort beschreibt man Ketten und Agenten in Code: Funktionen, Klassen, Callbacks. Der Unterschied liegt nicht im Funktionsumfang, sondern im Träger der Definition. Bei LangChain ist der Code die Wahrheit, bei riceprompt-engine ist es die YAML-Datei. Das verschiebt die Werkzeugkette: Ein Graph lässt sich als Datei versionieren, in einem Editor öffnen und ohne Neukompilieren ändern. Umgekehrt verliert man die Typprüfung des Compilers und die freie Wahl der Kontrollflusskonstrukte. Ein zweiter Unterschied ist der Zuschnitt auf MCP: Die Engine behandelt MCP-Werkzeuge als Knotentypen erster Klasse, während andere Frameworks Werkzeuge als Registrierung im Anwendungscode führen. Wer bereits eine Tool-Schicht im Code pflegt, gewinnt durch die Verlagerung in YAML wenig und verliert die gewohnte Testbarkeit. Wer die Tool-Anbindung deklarativ halten will, gewinnt.
Lizenz und Pflegeaufwand
Der Code steht dual unter Apache-2.0 und MIT, nach Wahl des Nutzers. Das README enthält den üblichen Beitragspassus: Beiträge werden ohne zusätzliche Bedingungen unter derselben Doppellizenz eingereicht. Für die meisten Anwendungen ist das unproblematisch; wer den Code verändert und weiterverteilt, muss die Bedingungen der gewählten Lizenz einhalten. Das ist keine Rechtsberatung, sondern die Wiedergabe dessen, was im Repository steht. Zum Pflegeaufwand liefert das Material wenig: Es gibt keine abgerufenen Releases, keine veröffentlichten Release Notes, und das README verweist auf einen separaten Nutzerleitfaden, der noch erscheinen soll. Der letzte Push liegt laut Repository-Metadaten im April 2026. Wer die Engine einführt, übernimmt damit auch die Pflege der eigenen Workflow-Spezifikation, weil Änderungen an der YAML-Oberfläche laut Mitwirkendenrichtlinie im selben Pull Request in docs/FLOW_SPEC.md nachgezogen werden müssen. Das ist eine disziplinierte Regel, aber sie bindet Beitragende an ein Dokument, das man vor der Adoption lesen sollte.
Redaktionelles Fazit
Wer Agenten-Abläufe als versionierbaren Graphen in einer Datei pflegen und in eine Rust-Anwendung einbetten will, findet hier ein passendes Modell. Wer stabile APIs, publizierte Release Notes oder ausführliche Anleitungen braucht, sollte zuerst docs/FLOW_SPEC.md gegen die eigenen Knotentypen prüfen und die genaue Version pinnen, weil der Autor selbst API-Änderungen zwischen Minor-Versionen ankündigt.
Community-Notizen