riceprompt-engine : exécuter un graphe d'agents décrit en YAML, côté Rust

Un format déclaratif à la place de l'orchestration écrite à la main

Le problème visé est celui de l'enchaînement. Dès qu'un agent doit appeler un modèle, consulter une base, itérer sur une liste, puis router vers un sous-agent, le code d'orchestration grossit et devient difficile à relire. riceprompt-engine déplace cette logique dans un fichier YAML unique qui contient le graphe, les prompts, les sources de données et les fournisseurs. Le README résume l'ambition en une phrase : vous décrivez un workflow comme un fichier YAML, le moteur l'analyse, résout les dépendances et exécute le graphe. Le public visé est donc l'ingénieur qui veut versionner ses workflows au même endroit que son code, et qui accepte d'écrire du Rust pour les déclencher. Le moteur alimente aussi RicePrompt, un IDE visuel présenté comme construisant et exécutant ces mêmes workflows. Ce détail compte pour la suite : le YAML n'est pas un format de sérialisation interne, c'est le contrat public entre l'éditeur graphique et le moteur.

Ce que le moteur fait entre le YAML et le résultat

Le README décrit un pipeline en trois temps : analyse du fichier, résolution des dépendances, exécution du graphe. Les arêtes déclarées sous la clé edges indiquent l'ordre, et les valeurs des nœuds se référencent par chemin, comme "start.name" ou "greet.output", ce qui laisse entendre que les sorties sont adressables par identifiant de nœud. Les nœuds disponibles couvrent plusieurs familles : generate pour les appels de modèle, transform pour du scripting Rhai, iterator pour la répétition, supervisor pour le routage multi-agents, subgraph pour l'imbrication, data_connector pour les bases et API, skill_set pour des paquets de connaissances, et mcp ou mcp_tools pour le Model Context Protocol. Une couche appelée harness injecte des instructions de niveau workflow dans chaque nœud generate, avec une mémoire persistante. Le résultat d'exécution peut inclure le YAML source, ce qui permet à un outil en aval de redessiner la topologie et de placer les sorties de chaque nœud à partir d'un seul fichier. C'est un choix utile pour la traçabilité, mais il implique que le YAML reste lisible et stable dans le temps.

Mise en route : dépendance, fichier, exécution

L'installation passe par Cargo. Le README donne cette déclaration : riceprompt-engine = "0.1" dans la section dependencies du Cargo.toml. Le workflow minimal fourni en exemple déclare une version de format (version: "1.0"), un nom, une section providers avec une clé api_key pointant vers la variable d'environnement ${OPENAI_API_KEY}, trois nœuds (start, greet, response), deux arêtes, et un modèle de prompt nommé tpl_greet contenant un user_prompt avec la variable {{name}}. Le nœud greet référence ce modèle via template: tpl_greet et passe name: "start.name" dans ses variables. Côté Rust, l'exemple lit le fichier avec std::fs::read_to_string, construit le moteur via Engine::builder().build(), puis appelle engine.run_yaml(&yaml, json!({ "name": "Ada" })). Le résultat est sérialisé avec serde_json::to_string_pretty. Le README indique que d'autres exemples exécutables se trouvent dans le dossier examples/. Rien dans le matériel fourni ne documente une CLI : l'entrée se fait par la bibliothèque.

La surface de configuration est large, et c'est le principal risque

Un fichier qui décrit à la fois le graphe, les prompts, les fournisseurs, les sources de données et les outils concentre beaucoup de choses au même endroit. La liste des fournisseurs est longue (OpenAI, Anthropic, Gemini, DeepSeek, Qwen, Zhipu, Moonshot, MiniMax, xAI, Huoshan, plus tout point de terminaison compatible OpenAI), et les connecteurs intégrés couvrent PostgreSQL, MySQL, MongoDB, Redis, Qdrant, le stockage objet compatible S3 et les API REST. Chaque fournisseur et chaque connecteur ajoute des champs et des comportements. Le README précise que le document faisant autorité est docs/FLOW_SPEC.md, et qu'un guide d'usage destiné aux utilisateurs sera publié séparément. Autrement dit, au moment où ces lignes sont écrites, la spécification technique existe mais le guide pédagogique n'est pas encore là. Pour un lecteur qui découvre le projet, cela signifie que la compréhension fine des champs passe par la lecture du spec, pas par un tutoriel. C'est un coût d'entrée réel, pas un détail de documentation.

Version 0.1.x : l'instabilité est annoncée, pas subie

Le README est explicite sur le statut du projet : la série 0.1.x, avec des changements d'API possibles entre versions mineures pendant que la spécification se stabilise, et une recommandation d'épingler une version exacte si la stabilité importe. Cette phrase doit être lue comme un avertissement opérationnel. Une mise à jour mineure peut casser du code de compilation, ou modifier la sémantique d'un champ YAML. Le corollaire pratique est qu'un workflow en production doit être accompagné de la version exacte du crate qui l'exécute, sinon une reconstruction peut produire un comportement différent sans qu'aucune ligne du YAML n'ait changé. Le README ne décrit pas de mécanisme de migration ni de politique de dépréciation. C'est le point que je vérifierais en premier avec l'équipe : combien de temps une version donnée reste-t-elle utilisable, et comment les changements de spec sont-ils annoncés. Le matériel fourni ne permet pas de répondre.

Quand ce moteur n'est pas le bon outil

Trois cas se dessinent à la lecture du dépôt. D'abord, si vos workflows sont des chaînes linéaires de deux ou trois appels, la résolution de dépendances et le format de graphe n'apportent rien que du code Rust direct n'apporterait pas, avec une couche de configuration en plus. Ensuite, si votre équipe n'écrit pas de Rust, l'exemple d'exécution est du code Rust asynchrone avec tokio : il n'existe pas, dans le matériel fourni, de point d'entrée en ligne de commande ni de binding vers un autre langage. Le moteur alimente RicePrompt, un IDE visuel, mais le README ne dit pas si cet IDE est le seul moyen d'exécuter un workflow sans écrire de Rust. Enfin, le checkpoint et la reprise sont annoncés comme fonctionnalités, sans que le README détaille où l'état est stocké ni ce qui se passe si un processus s'arrête au milieu d'un nœud iterator. Pour un workflow long qui touche une base de données, cette zone d'ombre est précisément celle qu'il faut lever avant de s'engager.

Face à un orchestrateur Python ou à du code d'enchaînement écrit à la main

L'alternative la plus directe n'est pas un autre moteur, c'est le code que vous écrivez déjà : appeler le SDK du fournisseur, enchaîner les fonctions, sérialiser les résultats vous-même. La différence d'approche est nette. Dans le code, la topologie est implicite dans l'ordre des appels et se lit dans le flux d'exécution. Avec riceprompt-engine, la topologie est un objet du fichier YAML, déclarée sous forme de nœuds et d'arêtes, ce qui la rend inspectable sans exécuter le programme et modifiable sans recompiler. C'est un gain pour les workflows que plusieurs personnes doivent relire ou faire évoluer, et une perte pour ceux qu'une seule personne maintient dans un seul fichier de code. Comparé aux orchestrateurs écrits en Python, le choix du Rust déplace le coût : vous obtenez un binaire compilé et typé, mais vous perdez l'accès direct à l'écosystème Python de traitement de données. Le README ne cherche pas à trancher ce débat, il expose le compromis.

Licence, maintenance et coût de mise à jour

Le dépôt est sous double licence Apache-2.0 ou MIT, au choix, et le README précise que toute contribution soumise est automatiquement placée sous cette double licence, sans termes additionnels. Pour un usage interne, ce choix est permissif et n'impose pas de publier vos propres modifications. La clause de contribution mérite toutefois d'être connue des entreprises qui envisagent d'envoyer des correctifs : en ouvrant une pull request, vous acceptez ce régime de licence pour votre code. Sur la maintenance, le README demande de lancer cargo fmt et cargo clippy --all-targets avant de soumettre, d'ajouter des tests pour tout nouveau type de nœud ou comportement de fournisseur, et de mettre à jour docs/FLOW_SPEC.md dans la même PR que tout changement touchant la surface YAML. Cette dernière règle est la plus importante pour un utilisateur : elle signifie que la spécification est censée suivre le code, pas l'inverse. Le coût de mise à jour se concentre donc sur deux fichiers à surveiller, Cargo.toml et docs/FLOW_SPEC.md, plutôt que sur l'ensemble du dépôt.

Conclusion éditoriale

Adoptez riceprompt-engine si vous voulez garder la définition de vos workflows dans un fichier YAML versionnable et l'exécuter depuis du code Rust, en acceptant de figer une version exacte dans Cargo.toml tant que la série 0.1.x dure. Passez votre chemin si votre équipe n'écrit pas de Rust ou si vos workflows sont surtout des chaînes linéaires : un simple appel de SDK suffit alors, et le format YAML n'apporte que de la surface à maintenir. Avant tout engagement, lisez docs/FLOW_SPEC.md en entier, car c'est le seul document désigné comme faisant autorité sur les champs et les types de nœuds, et vérifiez que le type de nœud dont vous dépendez y figure.

Sources officielles

1. Issues
2. jieyefriic/rp-engine on GitHub
3. License: Apache-2.0
4. Project website
5. README