Orchestration multi-agents
Lancez plusieurs agents. Laissez un controller décider de l'ordre.
Certains travaux ont un ordre impossible à écrire à l'avance. Posez type: controller, déclarez ce qui doit être vrai à la fin du run, et Dagu laisse un modèle choisir l'étape d'agent suivante au fil des retours. Chaque action reste une étape de workflow ordinaire, avec logs, retries, approbations et historique d'audit.
# code-review.yaml
type: controller
llm:
provider: anthropic
model: claude-opus-5
system: |
Get top_n.py past both reviews. When a review fails, pass its finding
to revise, then ask that same reviewer again. A revision made for one
reviewer can break the other.
steps:
- name: review_simplicity
description: Judge simplicity. Prints PASS, or FAIL with what to change.
action: harness.run
with:
provider: opencode
prompt: Read top_n.py. Print "PASS" or "FAIL: <what to change>".
- name: review_correctness
description: Judge correctness. Prints PASS, or FAIL with the bug.
action: harness.run
with:
provider: codex
prompt: Read top_n.py. Print "PASS" or "FAIL: <the bug>".
- name: revise
description: Edit top_n.py to resolve one review finding.
action: dag.run
with: { dag: revise }
tasks:
- name: simplicity_passed
description: The latest simplicity review returned PASS on the current file.
- name: correctness_passed
description: The latest correctness review returned PASS on the current file.Déclarez des critères de fin, pas un ordre d'étapes
Chaque action est un vrai CLI d'agent : Claude, Codex, Gemini, OpenCode
Une tâche se solde en completed, skipped ou failed
Les pauses en attente d'une réponse humaine ne laissent aucun processus vivant
At a glance
Workflows controller et frameworks d'agents
Vous déclarez les critères de fin. Le run se termine quand plus aucune tâche n'est ouverte.
Soit le modèle décide qu'il a fini, soit tous les chemins sont dessinés à l'avance et maintenus à la main.
Un run en attente termine son processus et reprend sur un autre.
Une longue attente suppose généralement un processus à garder en vie et un magasin d'état à exploiter.
Planifications, files, retries, artefacts et audit viennent du run de DAG.
Reconstruit projet par projet, ou délégué à un control plane hébergé.
L'ensemble des étapes du fichier de workflow.
Tout ce que permettent les définitions d'outils.
In depth
Where each tool fits
L'ordre est justement ce qu'on ne peut pas écrire
Un graphe sait brancher sur un code de sortie. Il ne sait pas brancher sur ce qu'une relecture a réellement dit. Un workflow controller garde les actions fixes et ne cède que l'ordonnancement.
- Les étapes deviennent un catalogue d'actions, donc plus aucun depends à maintenir
- Une liste tasks déclare ce qui doit être vrai à la fin du run
- Le controller transporte le constat d'un agent dans les paramètres du suivant
Le modèle choisit l'ordre, jamais les capacités
Le controller choisit uniquement parmi les étapes que vous avez déclarées. Il ne peut pas inventer une étape, écrire sa propre commande shell ni atteindre ce que le fichier ne nomme pas : le rayon d'action est donc la définition du workflow.
- Exécutez chaque agent sur l'hôte ou dans un bac à sable conteneurisé, montages et règles de sortie explicites
- Donnez à chaque rôle son provider et son modèle, pour qu'aucun modèle ne note son propre travail
- Ce à quoi vous finissez par faire confiance passe en sous-workflow et cesse d'être une décision
Les garde-fous de production viennent du run, pas d'un framework
Un run controller est un run de DAG. Planifications, files, retries, artefacts et audit s'appliquent tels quels, et les limites de dépense de l'agent sont des réglages du moteur plutôt que des consignes de prompt.
- ask_user suspend le run durablement : le processus se termine et le slot de worker est libéré
- Quelqu'un répond des heures plus tard et le run reprend sur un nouveau processus
- Les limites de tours, de tentatives et de questions font échouer le run au lieu de dépenser sans borne
Reconstituer n'importe quel run après coup
Un controller n'a pas d'arêtes de dépendance : le run est présenté comme la suite des décisions réellement prises, et non comme un graphe.
- Une chronologie des décisions : une ligne par tour, avec tentatives, durées et lien vers le run enfant produit
- Une vue des tâches indiquant pourquoi le controller a soldé chaque objectif
- La transcription complète, y compris chaque résultat d'outil vu par le modèle
FAQ
Practical questions before adopting Dagu
En quoi un workflow controller diffère-t-il d'une boucle d'agent ?
Une boucle nue laisse le modèle décider qu'il a fini. Un controller garde la boucle mais récupère la condition d'arrêt : vous déclarez les tâches et ce que « terminé » signifie, et le run s'achève quand plus aucune tâche n'est ouverte.
Que se passe-t-il si une tâche s'avère inutile ?
Le controller la marque skipped en consignant pourquoi, et le run reste un succès. Skipped et failed sont deux états distincts, car « il n'y avait rien à faire » et « cela n'a pas pu être fait » sont des issues différentes dans un journal d'audit.
Peut-on utiliser des modèles différents selon les étapes ?
Oui. Chaque étape Agent Harness nomme son provider et son modèle, et le modèle du controller se configure à part : un modèle bon marché peut piloter des spécialistes coûteux, ou deux providers peuvent se contrôler mutuellement.
Comment empêcher un run de dépenser sans limite ?
Les limites sont appliquées par le moteur. Une action s'exécute au plus cinq fois par run, un run pose au plus cinq questions, et la limite de tours vaut cinquante par défaut et peut être abaissée. Une limite atteinte fait échouer le run en nommant ce qui reste ouvert.
Quand faut-il quand même un graphe classique ?
Si vous pouvez dessiner le graphe, dessinez-le. type: graph reste la valeur par défaut : plus rapide, moins cher, reproductible. Ne prenez un controller que lorsque l'ordre dépend réellement de ce que les étapes précédentes ont produit.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.