arnaud/MagicCode
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
MagicCode/GUIDE_AUTONOMOUS.md

383 lines
24 KiB
Markdown
Raw Normal View History

Autonomous agents
2026-10-26 23:45:53 +00:00
# Guide des agents autonomes (workflows) de MAIA
Un **workflow** fait travailler des agents **sans interface** : un **agent parent** (l'orchestrateur) reçoit une tâche, la découpe, confie des morceaux à des **sous-agents**, puis rend un résultat. On le lance en ligne de commande, à la main, depuis un script, une tâche planifiée ou un service, et on interroge MAIA pour savoir où il en est.
```
maia run …/Main/AGENT.md --task "…"
│
▼
┌───────────────┐ outil Agent ┌──────────────┐
│ agent parent │ ───────────────▶ │ sous-agent │ (un processus par lancement,
│ (Main) │ ◀─── résumé ──── │ (reviewer) │ en parallèle si besoin)
└───────────────┘ └──────────────┘
│ états, journal, demandes, résultat
▼
~/.maia/workflows/<id>/ ◀── maia workflows · workflow · logs · approve · reply · stop · result
```
Sommaire : [1. Préparer les agents](#1-préparer-les-agents) · [2. L'agent parent](#2-lagent-parent) · [3. Les sous-agents](#3-les-sous-agents) · [4. Lancer](#4-lancer-un-workflow) · [5. Autorisations](#5-autorisations-sans-interface) · [6. Superviser](#6-superviser) · [7. Intervenir](#7-intervenir-répondre-arrêter) · [8. Scripts et services](#8-scripts-tâches-planifiées-et-services) · [9. Registre](#9-le-registre) · [10. Limites](#10-limites) · [11. Dépannage](#11-dépannage) · [12. Aide-mémoire](#12-aide-mémoire)
---
## 1. Préparer les agents
Les agents sont des fichiers `AGENT.md`, un dossier par agent :
```
X:/projX/
├── MAIA.md ← contexte du projet (lu par les agents, sauf omitMd: true)
└── .maia/
├── settings.json ← permissions du projet (allow / ask / deny)
└── agents/
├── Main/AGENT.md ← agent PARENT (orchestrateur)
├── reviewer/AGENT.md ← sous-agent du projet
└── test_runner/AGENT.md ← sous-agent du projet
~/.maia/
├── settings.json ← LiteLLM, DefaultModel, permissions globales
└── agents/
└── doc_checker/AGENT.md ← sous-agent GLOBAL (disponible pour tous les projets)
```
- **Créer un agent** : dans MAIA interactif, `/createAgent` (niveau projet ou global) copie un modèle commenté ; il suffit de remplir la description et les sections. Exemples prêts à copier : `examples/agents/release_check` (parent) et `examples/agents/code_reviewer` (sous-agent).
- **Le nom de l'agent** (`name:`) doit être celui de son dossier.
- **Un agent parent est un agent comme les autres** : même format, mêmes champs. Ce qui en fait un parent, c'est qu'on le lance avec `maia run`. Le même fichier peut servir de sous-agent dans un autre workflow.
## 2. L'agent parent
```markdown
---
name: Main
description: Vérifie qu'une branche est prête à être livrée.
model: sonnet # facultatif (voir § 4, « Modèle »)
effort: high # étapes maximales : low 10 · medium 25 · high 50
timeout: 60m # facultatif : durée maximale du workflow (90s, 30m, 2h, 1d)
permissionMode: wait # facultatif : wait (défaut) | deny | allow (voir § 5)
permissions: # facultatif : règles ajoutées à celles des settings.json
allow: [Agent, Read, Grep, "Bash(git diff *)"]
---
# Instructions system
Tu es un orchestrateur de vérification avant livraison. Tu ne relis pas le code toi-même :
tu délègues à tes sous-agents et tu consolides leurs résultats.
# Missions
1. Lance reviewer et doc_checker en parallèle sur les fichiers modifiés (git diff --name-only main...HEAD).
2. Si reviewer ne signale aucun problème CRITICAL, lance test_runner.
3. Consolide les trois rapports.
# Constraints (optionnelle)
- ne modifie aucun fichier, ne fais ni commit ni push
- si un problème CRITICAL est trouvé : ne conclus pas seul, demande l'intervention de l'équipe sécurité
# Output
- Verdict : GO ou NO-GO
- Problèmes par gravité, avec fichier et ligne
- Décision de l'équipe sécurité, s'il y en a eu une
```
**Champs de l'en-tête**
| Champ | Rôle pour le parent |
| --- | --- |
| `name`, `description` | obligatoires (comme tout agent) |
| `model` | modèle du parent ; c'est aussi celui que **ses sous-agents héritent** |
| `effort` | nombre maximal d'étapes (un appel au modèle + ses outils) : 10 / 25 / 50. Au-delà, le parent rédige son résultat avec ce qu'il a. |
| `timeout` | durée maximale du workflow, sous-agents compris ; dépassée : arrêt, état « en erreur ». Sans ce champ : pas de limite. |
| `permissionMode` | traitement des demandes d'autorisation sans interface (§ 5) ; `--permission-mode` l'emporte |
| `permissions` | règles `allow` / `ask` / `deny` **ajoutées** à celles des `settings.json` (un `deny` ou `ask` des settings n'est jamais levé) |
| `tools` | restreint les outils du parent ; l'outil `Agent` et l'outil `RequestIntervention` restent toujours disponibles |
| `skills`, `omitMd` | comme pour un sous-agent (skills autorisés ; `omitMd: true` = sans MAIA.md / CLAUDE.md) |
**Sections** : `# Instructions system`, `# Missions`, `# Output` sont obligatoires ; `# Constraints` est facultative. Le résultat final du workflow est la dernière réponse du parent, au format de la section **Output**.
**Bien écrire un parent**
- **Nommez les sous-agents** dans les missions et les contraintes (« lance reviewer… ») : c'est ainsi que le parent sait qui appeler, et les agents cités apparaissent dès le départ en « non exécuté » dans le suivi.
- **Parallèle ou séquence** : écrivez-le. « Lance A et B en parallèle » → les deux sous-agents tournent en même temps ; « Si A …, lance C » → C attend le résultat de A.
- **Contraintes qui demandent un humain** : écrivez « demande l'intervention de … ». Le parent utilise alors l'outil `RequestIntervention` et le workflow passe en attente jusqu'à votre réponse (§ 7).
- **Un sous-agent ne voit rien** de la conversation du parent : le parent doit tout mettre dans la tâche qu'il confie (fichiers, objectif, contraintes). Rappelez-le dans les instructions si les sous-agents manquent de contexte.
## 3. Les sous-agents
**Quels sous-agents le parent peut lancer**
- tous ceux du dossier `.maia/agents` qui contient le parent (pour `X:/projX/.maia/agents/Main/AGENT.md` : tout `X:/projX/.maia/agents/`) ;
- tous les agents globaux (`~/.maia/agents/`) ;
- à nom égal, celui du dossier du parent l'emporte ; le parent ne se lance jamais lui-même ;
- les agents d'un autre projet ne sont **pas** visibles.
**Comment ils s'exécutent**
- chaque lancement = **un processus séparé**, avec une conversation **vide** : le sous-agent ne connaît que la tâche reçue et son propre `AGENT.md` (plus MAIA.md sauf `omitMd`) ;
- seul son **résumé final** (section Output) revient au parent ;
- **modèle** : celui du parent, sauf s'il a son propre champ `model` (nom exact ou morceau : `haiku` → premier modèle LiteLLM dont le nom contient « haiku ») ;
- **outils** : ceux de l'agent principal (intégrés, personnalisés de `./.maia/tools` et `~/.maia/tools`, `Skill`), limités par `tools:` ; jamais l'outil `Agent` ;
- **permissions** : celles des `settings.json` + celles de son en-tête (elles s'ajoutent, un `deny` hérité n'est jamais levé). Ses demandes d'autorisation remontent au workflow et sont traitées selon `permissionMode` (§ 5), attribuées au sous-agent dans le suivi ;
- **étapes** : selon son `effort` (10 / 25 / 50) ; s'il les épuise, on lui demande son résumé ;
- **durée** : pas de délai propre dans un workflow (c'est le `timeout` du workflow qui borne tout) ;
- **conversation** : toujours enregistrée dans le registre (`traces/<agent>.json`, `<agent>-2.json` au 2e lancement…), que `trace` soit à `true` ou non ;
- un sous-agent **ne peut pas poser de question** : devant un cas prévu par ses `Constraints`, il s'arrête sur ce point et le signale dans son résumé ; c'est au parent de demander l'intervention.
**Un bon sous-agent** a une `description` claire (le parent choisit d'après elle), une mission étroite, une section Output structurée que le parent pourra consolider, et des `tools` / `permissions` limités au nécessaire (ex. `tools: Read, Grep, Glob` pour un relecteur).
## 4. Lancer un workflow
```bash
maia run X:/projX/.maia/agents/Main/AGENT.md --task "Vérifie la branche feature/x"
maia run ./.maia/agents/Main/AGENT.md "Vérifie la branche feature/x" # la tâche peut suivre le fichier
maia run ./.maia/agents/Main/AGENT.md --detach --name livraison-nuit # en arrière-plan
```
| Option | Effet |
| --- | --- |
| `--task "…"` | la tâche du parent ; sans tâche : « exécute ta mission telle qu'elle est décrite » |
| `--model <spec>` | modèle du parent (et donc des sous-agents sans `model`) |
| `--name <nom>` | nom du workflow, utilisable à la place de l'identifiant |
| `--detach` / `-d` | lance en arrière-plan : affiche l'identifiant et rend la main tout de suite |
| `--json` | résultat en JSON sur la sortie standard |
| `--permission-mode wait\|deny\|allow` | remplace `permissionMode` de l'en-tête |
| `--timeout 30m` | remplace `timeout` de l'en-tête |
| `--quiet` / `-q` | sans la progression |
**Avec pnpm** (depuis le dépôt MAIA, sans rien installer ni compiler : le script `maia` exécute les sources avec tsx) :
```bash
cd /chemin/vers/maia
pnpm maia run X:/projX/.maia/agents/Main/AGENT.md --task "Vérifie la branche feature/x"
pnpm maia workflows
pnpm maia workflow last --watch
pnpm maia approve last r1
# depuis le dossier du projet, sans s'y déplacer dans le dépôt MAIA :
cd X:/projX
pnpm --dir /chemin/vers/maia maia run ./.maia/agents/Main/AGENT.md --detach
pnpm --dir /chemin/vers/maia maia logs last -f
```
- `pnpm dev run …` fonctionne aussi (même script) ; un `--` après le nom du script (`pnpm maia -- run …`) est accepté et ignoré.
- Les **chemins relatifs** (`./.maia/agents/Main/AGENT.md`) sont résolus depuis le dossier **où vous avez tapé la commande** (pnpm le transmet dans `INIT_CWD`), pas depuis le dépôt MAIA. `MAIA_CWD=/autre/dossier` force un autre dossier.
- Après `pnpm build`, la commande compilée est `node /chemin/vers/maia/packages/cli/dist/index.js run …`, ou `maia run …` si elle est installée dans le PATH (voir le README, « Lancer MAIA depuis un autre dossier »). Pour une tâche planifiée ou un service, préférez la version compilée : elle démarre plus vite et ne dépend pas de tsx.
- `--detach` fonctionne aussi avec pnpm : le processus détaché est relancé avec le même interpréteur (tsx compris).
- **Dossier de travail** : le projet qui contient `.maia/agents` (`X:/projX`), quel que soit le dossier d'où vous lancez. Si le `AGENT.md` n'est pas dans un dossier `.maia/agents`, c'est le dossier de lancement, et les sous-agents disponibles sont ceux du dossier qui contient le dossier de l'agent, plus les globaux.
- **Modèle** : `--model`, sinon `model` du parent, sinon `DefaultModel` de `~/.maia/settings.json`, sinon le premier modèle de LiteLLM (avec un avertissement). Conseil : fixez `DefaultModel` pour les workflows planifiés.
- **Au premier plan**, la progression s'affiche sur la sortie d'erreur et le résultat sur la sortie standard :
```
Workflow wf_20261027_000558_3f50 — suivi : maia workflow wf_20261027_000558_3f50
[00:05:58] workflow › Workflow wf_… démarré : agent Main, modèle litellm:sonnet, autorisations « wait », dossier X:/projX
[00:05:58] Main › Sous-agents disponibles : doc_checker, reviewer, test_runner
[00:05:59] reviewer › en exécution
[00:06:00] reviewer › terminé
…
VERDICT GO — …
```
- **Codes de sortie** : `0` terminé · `1` en erreur (dont délai dépassé) · `2` mauvaise utilisation · `130` arrêté par `maia stop`.
- **`--json`** : `{ "id", "state", "label", "exitCode", "result", "error" }`. Avec `--detach --json` : `{ "id", "pid" }`.
## 5. Autorisations sans interface
Les règles des `settings.json` (et de l'en-tête de l'agent) s'appliquent comme en mode interactif : `allow` passe sans demander, `deny` refuse. Ce qui change, c'est une demande **`ask`** (ou un outil sans règle, qui demande par défaut) : personne n'est là pour répondre « o/n ». `permissionMode` décide :
| Mode | Une demande `ask` est… |
| --- | --- |
| **`wait`** (défaut) | enregistrée ; l'agent passe **en attente** jusqu'à `maia approve <id> <demande>` (ou `--deny`). Le travail déjà fait est conservé. |
| `deny` | refusée aussitôt ; le modèle en est informé et continue autrement |
| `allow` | acceptée aussitôt — à réserver à un environnement isolé (conteneur, machine jetable) |
**Important : l'outil `Agent` demande une autorisation par défaut.** Sans règle, chaque lancement de sous-agent attend donc un `maia approve`. Pour un workflow qui doit tourner seul, autorisez au moins le lancement des sous-agents :
```yaml
# en-tête de l'agent parent
permissions:
allow: [Agent] # tous ses sous-agents
# ou, plus précis : allow: ["Agent(reviewer)", "Agent(doc_checker)"]
```
ou dans `X:/projX/.maia/settings.json` : `"permissions": { "allow": ["Agent", "Read", "Grep", "Glob"] }`.
Recette pour un workflow de nuit : des règles `allow` précises pour ce que le workflow doit faire (lecture, `Bash(git diff *)`, `Bash(npm test)`…), des `deny` pour ce qui ne doit jamais arriver (`Bash(git push *)`, `Bash(rm *)`), et `wait` pour le reste : seules les actions imprévues attendront une réponse. Syntaxe des règles : [`GUIDE_PERMISSIONS.md`](GUIDE_PERMISSIONS.md).
## 6. Superviser
```bash
maia workflows # workflows en cours
maia workflows --all # tous, y compris terminés et en erreur
maia workflow last # le plus récent
maia workflow livraison-nuit # par nom (--name)
maia workflow 3f50 --watch # par morceau d'identifiant, rafraîchi toutes les 2 s jusqu'à la fin
maia logs 3f50 -f # journal en continu
maia logs 3f50 reviewer # journal d'un seul agent
maia result 3f50 # résultat final
```
`<id>` accepte : l'identifiant complet, un morceau unique de celui-ci (`3f50`), le nom donné par `--name` (le plus récent s'il y en a plusieurs), ou `last`.
**États**
| État | Pour un agent | Pour le workflow |
| --- | --- | --- |
| `non exécuté` | cité par le parent mais pas encore lancé | créé, pas encore démarré |
| `en exécution` | il travaille | au moins un agent travaille |
| `en attente` | il attend une réponse (autorisation ou intervention) | au moins un agent attend |
| `terminé` | il a rendu son résultat | le parent a rendu le résultat |
| `en erreur` | échec, délai, arrêt, ou workflow interrompu pendant qu'il tournait | échec du parent, délai, `maia stop`, ou processus disparu |
Un sous-agent en erreur ne fait pas échouer le workflow : le parent en est informé et décide (le workflow peut être « terminé » avec un agent « en erreur »).
**Exemple de `maia workflow`**
```
Workflow wf_20261027_000558_3f50 : en attente
Agent parent : Main (X:/projX/.maia/agents/Main/AGENT.md)
Modèle : litellm:sonnet · autorisations : wait · durée : 2 min 10 s
Dossier : X:/projX
Tâche : Vérifie la branche feature/x
Agents :
Main en attente parent · 2 min 10 s · litellm:sonnet
doc_checker terminé 41 s · litellm:haiku
reviewer en exécution 1 min 02 s · litellm:sonnet
test_runner non exécuté
Demandes en attente :
r3 Main (intervention : équipe sécurité) : Faille CRITICAL dans auth.ts:42, livre-t-on quand même ?
→ maia reply wf_20261027_000558_3f50 r3 "réponse"
```
Dans MAIA interactif : `/workflows` (en cours), `/workflows all`, `/workflow <id>`.
## 7. Intervenir : répondre, arrêter
```bash
maia approve <id> r1 # autoriser une demande d'autorisation
maia approve <id> r1 --deny # la refuser
maia reply <id> r3 "Non, on bloque la livraison." # répondre à une demande d'intervention
maia stop <id> # arrêter le workflow et ses sous-agents
```
- `maia workflow <id>` affiche chaque demande en attente avec la commande exacte pour y répondre.
- Chaque demande reçoit **une seule** réponse ; une autorisation se règle avec `approve`, une intervention avec `reply`.
- Le workflow lit les réponses et les demandes d'arrêt toutes les secondes.
- **Stop** : le tour en cours s'interrompt, les sous-agents en cours reçoivent l'ordre de s'arrêter, le workflow passe « en erreur (arrêté) », code 130. Ce qui a déjà été fait (fichiers, journal, traces) est conservé, mais le workflow ne reprend pas : relancez-en un nouveau.
## 8. Scripts, tâches planifiées et services
**Script : lancer et attendre**
```bash
#!/usr/bin/env bash
cd /srv/projX
maia run .maia/agents/Main/AGENT.md --task "Vérifie la branche $BRANCH" --json --permission-mode deny > resultat.json
case $? in
0) echo "OK : $(jq -r .result resultat.json)" ;;
130) echo "Arrêté" ;;
*) echo "Échec : $(jq -r .error resultat.json)"; exit 1 ;;
esac
```
**Script : lancer en arrière-plan puis surveiller**
```bash
id=$(maia run .maia/agents/Main/AGENT.md --detach --json | jq -r .id)
while :; do
state=$(maia workflow "$id" --json | jq -r .state) # pending | running | waiting | done | error
[ "$state" = done ] || [ "$state" = error ] && break
[ "$state" = waiting ] && maia workflow "$id" | sed -n '/Demandes en attente/,$p' | mail -s "MAIA attend" moi@exemple.fr
sleep 60
done
maia result "$id"
```
Le JSON utilise des codes stables (`pending`, `running`, `waiting`, `done`, `error`) et le libellé français dans `label` : testez les codes, affichez les libellés.
**Tâche planifiée** (cron, chaque nuit à 2 h 13) :
```cron
13 2 * * * cd /srv/projX && /usr/local/bin/maia run .maia/agents/Main/AGENT.md --name nuit --quiet >> /var/log/maia-nuit.log 2>&1
```
Sous Windows, le Planificateur de tâches lance la même commande (`maia run X:\projX\.maia\agents\Main\AGENT.md --name nuit --quiet`).
**Service** (systemd, en tant qu'utilisateur `maia`) : le service lance `maia run …` au premier plan (pas `--detach` : systemd suit lui-même le processus) ; pensez à `WorkingDirectory=` et aux variables d'environnement utiles (`LITELLM_API_KEY`, variables `${…}` de `mcp.json`).
**À savoir pour l'automatisation**
- MAIA lit `~/.maia/settings.json`, `~/.maia/agents`, `~/.maia/mcp.json` **de l'utilisateur qui lance la commande** : un service lancé sous un autre compte a son propre `~/.maia`, et ses workflows n'apparaissent que dans **son** `maia workflows`.
- Aucun terminal n'est nécessaire : `maia run` et les commandes de supervision fonctionnent sans TTY.
- `NO_COLOR=1` supprime les couleurs de l'affichage texte (elles sont déjà absentes hors terminal).
## 9. Le registre
Chaque workflow a un dossier dans **`~/.maia/workflows/<id>/`** (registre global, pour tous les projets) :
| Fichier | Contenu |
| --- | --- |
| `workflow.json` | agent parent, tâche, modèle, dossier, mode d'autorisation, pid, dates, état, erreur |
| `agents.json` | état de chaque agent (modèle, nombre de lancements, durée, erreur) |
| `events.jsonl` | journal horodaté, une ligne JSON par évènement (ce qu'affiche `maia logs`) |
| `requests/` | `r1.json`… : demandes ; `r1.answer.json` : réponse déposée par `approve` / `reply` |
| `traces/` | conversation complète de chaque agent (`Main.json`, `reviewer.json`, `reviewer-2.json`…) |
| `result.md` | résultat final du parent |
| `run.log` | sortie du processus en mode `--detach` |
| `stop` | présent si `maia stop` a été demandé |
- Pas de serveur : les commandes lisent ces fichiers. Seul le processus du workflow écrit `workflow.json`, `agents.json` et `events.jsonl` (écritures atomiques) ; les réponses et l'arrêt sont déposés dans des fichiers à part.
- **Nettoyage** : rien n'est supprimé automatiquement. Supprimez les dossiers des anciens workflows à la main (ils sont nommés par date : `wf_AAAAMMJJ_HHMMSS_xxxx`).
- Les traces contiennent tout ce que les agents ont lu (code, sorties de commandes) : traitez ce dossier comme sensible.
## 10. Limites
- **Un seul niveau d'agents** : le parent lance des sous-agents, un sous-agent ne lance jamais d'agent (il n'a pas l'outil `Agent`). Pour une chaîne plus longue, c'est le parent qui enchaîne les étapes.
- **Le parent ne voit que les résumés** de ses sous-agents, pas leur conversation (elle est dans `traces/`).
- **Une demande d'autorisation à la fois** : même avec des sous-agents en parallèle, les demandes `ask` sont posées l'une après l'autre (la suivante apparaît quand la précédente a reçu sa réponse). D'où l'intérêt des règles `allow` (§ 5).
- **Seul le parent peut demander une intervention** (`RequestIntervention`) ; un sous-agent signale le besoin dans son résumé.
- **Pas de reprise** : un workflow arrêté, en erreur, ou dont le processus a disparu (redémarrage de la machine, fermeture de session) ne reprend pas ; il apparaît « en erreur » et il faut en relancer un.
- **Pas de compactage du contexte** pour le parent ni pour les sous-agents : une très longue conversation peut dépasser la fenêtre du modèle. Gardez des missions courtes et des sous-agents qui résument.
- **Les sous-agents n'ont pas les outils MCP** (le parent les a, si les serveurs sont activés pour le projet).
- **Pas d'API HTTP** : la supervision passe par la ligne de commande et les fichiers du registre, sur la même machine et pour le même utilisateur.
- **Pas de nettoyage automatique** du registre.
- **Le délai par sous-agent** n'existe pas dans un workflow : seul `timeout` (du workflow) borne la durée totale.
- Les sous-agents d'**autres projets** ne sont pas accessibles ; partagez un agent en le plaçant dans `~/.maia/agents`.
## 11. Dépannage
| Symptôme | Cause probable / solution |
| --- | --- |
| Le workflow reste « en attente » dès le début | le lancement d'un sous-agent demande une autorisation : `maia workflow <id>` puis `maia approve`, ou ajoutez `allow: [Agent]` (§ 5) |
| « Agent parent invalide » | section obligatoire manquante, `name` différent du dossier, `description` absente : le message dit laquelle |
| « Aucun sous-agent disponible » | le `AGENT.md` n'est pas dans un dossier `.maia/agents`, ou ce dossier ne contient que le parent ; vérifiez aussi `~/.maia/agents` |
| Le parent ne lance pas un sous-agent attendu | son nom n'apparaît pas dans les missions, ou sa `description` ne correspond pas à la tâche ; nommez-le explicitement |
| « en erreur — processus disparu » | le processus a été tué (machine éteinte, session fermée, `kill`) ; relancez. Pour un lancement durable, utilisez un service ou une tâche planifiée |
| « Aucun modèle indiqué… » | ni `--model`, ni `model`, ni `DefaultModel`, et LiteLLM injoignable : vérifiez `~/.maia/settings.json` |
| Rien ne s'affiche avec `--detach` | normal : la sortie va dans `~/.maia/workflows/<id>/run.log` ; suivez avec `maia logs <id> -f` |
| `workflow « x » introuvable` / « ambigu » | utilisez l'identifiant complet, `last`, ou un morceau plus long |
## 12. Aide-mémoire
```bash
# Lancer (ou : pnpm maia run … depuis le dépôt MAIA, pnpm --dir <maia> maia run … d'ailleurs)
maia run <AGENT.md> [--task "…"] [--model m] [--name n] [--detach] [--json]
[--permission-mode wait|deny|allow] [--timeout 30m] [--quiet]
# Superviser
maia workflows [--all] [--json]
maia workflow <id> [--json] [--watch]
maia logs <id> [agent] [-f]
maia result <id>
# Intervenir
maia approve <id> <rN> [--deny]
maia reply <id> <rN> "texte"
maia stop <id>
```
| | |
| --- | --- |
| Sous-agents disponibles | dossier `.maia/agents` du parent + `~/.maia/agents` |
| Modèle | `--model` > `model` du parent > `DefaultModel` > 1er modèle LiteLLM ; sous-agents : celui du parent sauf `model` |
| Autorisations | `wait` (défaut) · `deny` · `allow` ; pensez à `allow: [Agent]` |
| États | non exécuté · en exécution · en attente · terminé · en erreur |
| Codes de sortie | 0 terminé · 1 erreur · 2 utilisation · 130 arrêté |
| Registre | `~/.maia/workflows/<id>/` |
| Niveaux | 1 seul : parent → sous-agents |
Reference in a new issue Copy permalink