HomeRail : un runtime d'orchestration DAG voice-first pour la maison
xiaotianfotos/homerail offre une implémentation open source exploitable en conditions réelles avec une structure réutilisable.
En bref
- De quoi s’agit-il ?
- Un moteur de workflows multi-agents qui tourne sur un homelab ou un NAS, avec entrée vocale, UI générée et piste d'audit comme objectif de conception central.
- À qui s’adresse-t-il ?
- HomeRail oppose une session de chat à un DAG inspectable et rejouable, et le README documente aujourd'hui déjà un chemin complet de l'installation à l'inspection des runs, tandis que le composant d'UI générative reste explicitement marqué comme exploratoire. L'essai de HomeRail doit suivre le CLI `hr` plutôt qu'une promesse d'interface.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 3 jours.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le README commence par le nom
Le premier paragraphe du README de HomeRail positionne le projet comme un runtime TypeScript qui transforme des chats d'agent ponctuels en workflows auditable et réutilisables. Le nom est expliqué directement : Home signifie qu'il tourne sur votre propre homelab, NAS ou serveur domestique, au service des personnes qui y vivent ; Rail est la forme de voie d'un DAG, où le travail des agents circule de nœud en nœud le long d'arêtes explicites au lieu de s'accumuler dans un seul chat. Le README énonce le pari de conception sans détour : l'attention d'une personne est la ressource la plus rare dans toute automatisation, donc le système doit en demander très peu.
Voix, UI générative et état actuel du moteur DAG
La section « ce qui fonctionne aujourd'hui » du README liste quatre composants. Le runtime DAG est marqué comme le plus mûr, avec orchestration multi-agents, isolation d'espace de travail par run, rejeu, scorecards et évaluation des runs. La CLI s'appelle hr et expose start, config, doctor, run, smoke, dag supervise, scorecard, eval-run et replay ; le README la présente comme le principal moyen d'opérer HomeRail. La surface vocale inclut ASR, TTS et VAD, est en chinois par défaut, est servie via un shell vocal de bureau, et l'agent collecte l'intention à travers plusieurs tours avant d'agir. L'UI générative est explicitement marquée comme en exploration : le README dit que son contrat et son jeu de widgets vont continuer à changer, et que sa forme est conçue à travers des cas d'usage réels. Docker Worker est décrit comme Manager et Node tournant comme services locaux, Node provisionnant un conteneur Worker Docker par nœud DAG, partageant un espace de travail par run.
Le chemin de démarrage rapide documenté
Le Quickstart liste trois exigences d'environnement : Node.js 20+ avec npm 10+, Docker utilisé par Node pour provisionner les conteneurs Worker, et un point de terminaison de modèle compatible Claude Agent SDK pour les runs d'agent en direct. Les notes de plateforme disent que macOS fonctionne avec le mappage host.docker.internal par défaut de Docker Desktop, que Windows nécessite d'exécuter la CLI depuis Git Bash car certains scripts supposent un shell de type Unix, et que Linux peut nécessiter une configuration réseau supplémentaire entre Worker et Manager. Les commandes d'installation et de build sont npm run install:all et npm run build, suivies de cd homerail_cli && npm link pour rendre la commande hr disponible. Le README montre ensuite hr start, hr doctor et une invocation hr run avec le profil offline-deterministic pour une vérification de topologie locale qui n'a pas besoin de fournisseur de modèle.
Synchroniser, exécuter, superviser et scorer des DAG
Le parcours d'exécution d'un DAG commence par hr templates list, puis exécute directement un fichier de template ou synchronise un workflow dans la base du Manager avec hr dag sync et hr profile sync. Le README avertit de garder workflow_id stable lors de l'édition du YAML, car le changer crée une nouvelle identité de workflow. Un run renvoie un run_id, et les commandes d'inspection documentées sont hr dag supervise, hr scorecard et hr eval-run. Les DAG multi-tours sont renvoyés vers docs/multi-round-dags.md, couvrant l'écriture stricte de WorkflowSpec v1, le round fencing, les commandes CLI et HTTP, la récupération, l'expiration et le comportement des slots de concurrence. Il existe aussi une bibliothèque de motifs DAG adossée au Manager pour le quorum, les cliquets bornés, la vérification d'objectifs permanents et le fan-out planificateur/travailleurs, opérée via hr patterns list, show et instantiate.
Un deuxième chemin : un agent de codage pilote la CLI
En plus de parler au Manager Agent ou de taper vous-même des commandes, le README décrit une autre utilisation : confier la CLI hr à un agent de codage déjà approuvé, comme Codex ou Claude Code, et le laisser exécuter des commandes directement. Ce chemin saute la couche Manager Agent, l'IA qui planifie un DAG à partir d'une demande, mais pas le service Manager, le coordinateur DAG. L'agent de codage prend le rôle de planification : il lit un template, décide quoi modifier, exécute le DAG, inspecte le résultat et itère. Le README dessine la boucle comme vous, agent de codage, CLI hr, service Manager, nœuds DAG. Le Manager Agent reste le bon choix quand on veut que HomeRail planifie et exécute un workflow de bout en bout à partir d'une seule demande, surtout par la voix.
Structure des paquets et configuration
Le tableau d'architecture liste six paquets : homerail_protocol pour les contrats de messages et de validation partagés, homerail_manager comme service Manager et coordinateur DAG qui possède aussi la surface vocale et le contrat d'UI générative, homerail_node pour provisionner les conteneurs Worker Docker, homerail_worker comme runtime Worker avec des adaptateurs de harnais pour Claude Agent SDK et des backends compatibles, homerail_cli comme commande hr, et agent-ui comme UI navigateur découplée. La section configuration dit que HOMERAIL_HOME est la racine de données locale, par défaut ~/.homerail, et que chaque run DAG écrit ses artefacts sous ${HOMERAIL_HOME}/workspace/<run_id>/ ; le README suggère de la pointer vers un disque avec de la place. Les identifiants du fournisseur sont stockés dans le magasin de paramètres chiffré du Manager, jamais dans les fichiers du dépôt. L'ordre de résolution de l'URL du Manager est --base-url, HOMERAIL_MANAGER_URL, ${HOMERAIL_HOME}/config.json, puis http://localhost:19191.
Direction du projet et limites de licence
Le README dit que HomeRail se dirige vers un agent résident dans le datacenter domestique, voix à l'entrée, UI générée à la sortie, avec plusieurs terminaux comme téléphone, tablette, TV et voiture, et que la fondation ici est la première étape. Pour l'agent vocal Manager, Codex (codex_appserver) est le harnais recommandé aujourd'hui, car c'est le seul chemin qui synthétise automatiquement le canal vocal commentary à partir du flux de raisonnement natif du modèle ; d'autres harnais comme claude-sdk et kimi-code restent silencieux pendant l'exécution, ce que le README attribue à un écart de capacité du fournisseur, pas à quelque chose que HomeRail peut combler. Le dépôt utilise la licence MIT ; l'extrait de licence accorde la permission d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre des copies du logiciel, à condition que l'avis de droit d'auteur et de permission soit inclus. Le texte de licence ne dit rien sur la posture de sécurité, le support ou la garantie, au-delà de l'avertissement standard en l'état. L'essai de HomeRail doit suivre le CLI `hr` plutôt qu'une promesse d'interface. Après `hr doctor` et `hr config`, lancez `hr smoke`, puis un scénario avec `hr run` et consultez `hr scorecard`, `hr eval-run` et `hr replay`. Le README impose Node.js 20+, npm 10+ et Docker : le nœud Docker Worker crée un conteneur par nœud du DAG et partage un espace de travail par exécution. Vérifiez donc l'isolation, les handoffs et la rejouabilité dans les journaux d'une exécution réelle. La surface vocale et la generative UI restent moins mûres que le runtime DAG, ce qui doit guider le périmètre du premier déploiement.
Conclusion éditoriale
HomeRail oppose une session de chat à un DAG inspectable et rejouable, et le README documente aujourd'hui déjà un chemin complet de l'installation à l'inspection des runs, tandis que le composant d'UI générative reste explicitement marqué comme exploratoire. L'essai de HomeRail doit suivre le CLI `hr` plutôt qu'une promesse d'interface. Après `hr doctor` et `hr config`, lancez `hr smoke`, puis un scénario avec `hr run` et consultez `hr scorecard`, `hr eval-run` et `hr replay`. Le README impose Node.js 20+, npm 10+ et Docker : le nœud Docker Worker crée un conteneur par nœud du DAG et partage un espace de travail par exécution. Vérifiez donc l'isolation, les handoffs et la rejouabilité dans les journaux d'une exécution réelle. La surface vocale et la generative UI restent moins mûres que le runtime DAG, ce qui doit guider le périmètre du premier déploiement.
Notes de la communauté