Alternative à LangGraph
Un runtime pour workflows d'agents, pas une bibliothèque dans votre application.
LangGraph est une bonne façon d'exprimer un graphe d'agents en code. Dagu est la couche qui l'exécute : un binaire auto-hébergé unique où un workflow est du YAML, où les agents sont des étapes ordinaires, et où planifications, files, retries, pauses durables et historique viennent du moteur plutôt que de l'application écrite autour.
# triage.yaml
schedule: "*/15 * * * *"
max_active_runs: 1
steps:
- id: fetch
run: ./scripts/fetch-new-issues.sh
output: ISSUES
- id: classify
action: harness.run
with:
provider: claude
prompt: Classify each issue in ${ISSUES}. Return JSON.
output_schema: schemas/triage.json
retry_policy:
limit: 3
interval_sec: 30
depends: [fetch]
- id: apply_labels
run: ./scripts/apply-labels.sh
depends: [classify]Les workflows sont du YAML, pas du code applicatif
Une étape est un processus : n'importe quel langage, n'importe quel CLI
Planification, files, retries et historique sont dans le binaire
Un run en attente libère son processus et reprend plus tard
At a glance
LangGraph et Dagu du point de vue de l'exploitation
Un moteur de workflow que vous exécutez comme un binaire.
Une bibliothèque intégrée à une application Python ou JavaScript.
Du YAML déclaratif, versionné à côté du code qu'il exécute.
Construction du graphe dans le code applicatif.
Planifications, files, retries, artefacts et historique viennent avec le moteur.
Les checkpointers persistent l'état du graphe ; la planification et l'exposition viennent de votre service ou de LangGraph Platform.
Un processus : n'importe quel langage, n'importe quel CLI, au besoin dans un conteneur.
Une fonction dans le processus hôte.
In depth
Where each tool fits
Une bibliothèque a besoin d'une application. Pas un moteur.
LangGraph construit le graphe. Il faut encore quelque chose pour le planifier, le mettre en file, le relancer, persister son état et montrer ce qui s'est passé. Ce quelque chose, c'est le service que vous écrivez, ou LangGraph Platform. Dagu est déjà cette couche.
- Un seul binaire à lancer. Aucun service web à écrire, aucun pool de workers à concevoir
- Planification, files, retries et historique sont des fonctions du moteur, pas des intégrations
- La même définition tourne sur un portable, une VM ou un coordinator avec des workers
Les étapes sont des processus, donc le workflow n'est pas lié à un langage
Les nœuds LangGraph sont des fonctions Python ou JavaScript dans votre processus. Une étape Dagu est une commande : l'unité de travail est donc ce qui tourne déjà dans votre environnement.
- Appelez scripts shell, binaires, conteneurs, commandes SSH, endpoints HTTP et SQL depuis un seul workflow
- Lancez des agents de code via harness.run : Claude, Codex, Gemini, OpenCode ou un CLI interne
- Donnez à toute étape un bac à sable conteneurisé avec montages, toolchain et règles de sortie explicites
Dessinez le graphe quand vous pouvez, cédez l'ordre quand vous ne pouvez pas
LangGraph demande de dessiner chaque chemin, ce qui est juste jusqu'au moment où l'ordre dépend de ce qu'a dit un relecteur. Dagu garde type: graph par défaut et ajoute type: controller pour le travail qui n'a jamais tenu dans un seul graphe.
- Un workflow controller déclare des critères de fin et laisse un modèle choisir l'action suivante
- Le modèle choisit uniquement parmi vos étapes déclarées : le rayon d'action est le fichier
- Les deux types produisent le même run, avec les mêmes logs, retries, artefacts et historique
FAQ
Practical questions before adopting Dagu
Dagu remplace-t-il LangGraph tel quel ?
Non. Ils se situent à des couches différentes. LangGraph convient quand vous voulez composer des appels de modèle en Python ou JavaScript avec un contrôle fin de l'état du graphe. Dagu convient mieux quand le travail est un ensemble de commandes et de CLI d'agents qui réclament planification, retries, approbations et piste d'audit.
Peut-on continuer à utiliser LangGraph dans Dagu ?
Oui. Gardez l'application LangGraph sous forme de script ou de conteneur et exécutez-la comme une étape. Dagu fournit autour la planification, la politique de retries, les logs, les artefacts et l'historique.
Comment Dagu gère-t-il le human-in-the-loop ?
Les tâches humaines, et ask_user dans les workflows controller, suspendent le run durablement. Le processus se termine, le slot de worker est libéré, et le run reprend sur un nouveau processus dès qu'une personne répond.
Dagu a-t-il besoin d'une base de données ?
Non. Dagu est un binaire unique qui stocke définitions, historique et logs sous forme de fichiers : aucune base de métadonnées ni broker de messages à exploiter avant le premier run.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.