Après avoir exploré les cron jobs pour l'automatisation récurrente, découvrons l'une des fonctionnalités les plus puissantes d'Hermes Agent : la délégation de tâches. Grâce à l'outil delegate_task, un agent peut lancer des sous-agents isolés, chacun avec son propre contexte, son terminal dédié et ses outils — capables de travailler en parallèle sur des sous-tâches complexes, puis de restituer un résumé au parent.
Cette capacité transforme Hermes Agent d'un exécutant linéaire en véritable orchestrateur d'agents autonomes, capable de paralléliser la recherche, le développement multi-fichiers, les audits de code et bien plus encore.
Qu'est-ce que delegate_task ?
L'outil delegate_task permet à l'agent de spawner des instances enfants d'AIAgent. Chaque sous-agent :
-
Démarre avec une conversation fraîche et isolée — il ne connaît rien du contexte parent
-
Possède son propre terminal, séparé de celui du parent
-
Dispose d'un ensemble d'outils restreint défini par le parent
-
Retourne uniquement un résumé structuré de son travail
Ce modèle d'isolation est fondamental : il empêche la pollution de contexte et permet de paralléliser sans risque.
Deux modes de délégation
Mode tâche unique (goal)
Le mode le plus simple : déléguer une seule tâche à un sous-agent.
delegate_task(
goal="Debug why tests fail",
context="Error: assertion in test_foo.py line 42",
toolsets=["terminal", "file"]
)
Le sous-agent reçoit un prompt système construit à partir du goal et du context, exécute sa mission avec son propre cycle de raisonnement LLM, puis retourne un résumé structuré : ce qu'il a fait, les fichiers modifiés, les problèmes rencontrés.
Mode batch (tasks array)
Pour la parallélisation, on passe un tableau tasks :
delegate_task(tasks=[
{
"goal": "Research topic A",
"context": "Focus on browser support and tooling",
"toolsets": ["web"]
},
{
"goal": "Research topic B",
"context": "Focus on ecosystem maturity",
"toolsets": ["web"]
},
{
"goal": "Fix the build",
"context": "TypeError in api/handlers.py line 47",
"toolsets": ["terminal", "file"]
}
])
Les sous-agents s'exécutent en parallèle via un ThreadPoolExecutor, jusqu'à max_concurrent_children simultanés (3 par défaut). Les résultats sont triés par index pour correspondre à l'ordre d'entrée, quel que soit l'ordre d'achèvement.
Contexte isolé : la règle d'or
Les sous-agents ne savent rien du parent. Zéro historique de conversation, zéro appel d'outil antérieur. Leur seul contexte provient des champs goal et context fournis lors de l'appel.
Erreur courante :
# MAUVAIS - le sous-agent n'a aucune idee de ce qu'est "l'erreur"
delegate_task(goal="Fix the error")
Bonne pratique :
# BON - tout le contexte nécessaire est fourni
delegate_task(
goal="Fix the TypeError in api/handlers.py",
context="The file api/handlers.py has a TypeError on line 47:
'NoneType' object has no attribute 'get'.
The function process_request() receives a dict from parse_body(),
but parse_body() returns None when Content-Type is missing.
Project at /home/user/myproject, Python 3.11."
)
Le parent doit passer absolument tout ce dont le sous-agent a besoin : chemins de fichiers, messages d'erreur, contraintes techniques, stack traces, objectifs de qualité.
Rôles : leaf vs orchestrator
Hermes Agent introduit deux rôles pour les sous-agents :
Leaf (défaut)
Un sous-agent leaf est un exécutant terminal. Il ne peut pas déléguer à son tour. Il accomplit sa tâche et retourne son résumé. C'est le comportement par défaut et le plus sûr.
Orchestrator
Un sous-agent orchestrator peut lancer ses propres sous-agents, créant une arborescence de délégation :
delegate_task(
goal="Survey three code review approaches and recommend one",
role="orchestrator",
context="Compare: GitHub PR reviews, CodeMirror, custom lint rules..."
)
L'orchestrateur enfant peut spawner des workers leaf pour paralléliser sa recherche, puis synthétiser les résultats.
Paramètres de contrôle : max_concurrent_children et max_spawn_depth
Deux garde-fous essentiels empêchent la prolifération incontrôlée :
-
max_concurrent_children (défaut : 3) : nombre maximal de sous-agents exécutés simultanément par batch. Configurable via
delegation.max_concurrent_childrenou la variable d'environnementDELEGATION_MAX_CONCURRENT_CHILDREN. Pas de plafond dur — le floor est 1. -
max_spawn_depth (défaut : 1 = plat) : profondeur maximale de l'arbre de délégation. À 1, seul le parent peut déléguer. À 2, les orchestrateurs peuvent spawner des leafs. À 3, trois niveaux (maximum).
Avertissement coût : avec max_spawn_depth: 3 et max_concurrent_children: 3, l'arbre peut atteindre 3x3x3 = 27 agents leaf simultanés. Chaque niveau supplémentaire multiplie les coûts. Augmentez max_spawn_depth intentionnellement.
Un kill switch global existe : delegation.orchestrator_enabled: false force tous les enfants au rôle leaf, peu importe le paramètre role.
Configuration complète
# ~/.hermes/config.yaml
delegation:
max_iterations: 50 # Tours max par enfant (defaut: 50)
max_concurrent_children: 3 # Enfants paralleles par batch (defaut: 3)
max_spawn_depth: 1 # Profondeur arbre 1-3 (defaut: 1 = plat)
orchestrator_enabled: true # false = force leaf pour tous
child_timeout_seconds: 600 # Timeout inactivite (defaut: 600s)
model: "google/gemini-flash-2.0" # Modele optionnel pour sous-agents
provider: "openrouter" # Provider optionnel
# base_url: "http://localhost:1234/v1" # Endpoint custom
# api_key: "local-key"
Timeout enfant
Les sous-agents sont tués s'ils restent silencieux plus de child_timeout_seconds secondes (600 par défaut). Le timer se réinitialise à chaque appel API ou outil — seuls les workers réellement inactifs déclenchent le kill. Ajustez : plus bas pour les modèles rapides locaux, plus haut pour les modèles de raisonnement lents.
En cas de timeout avec zéro appel API (souvent : provider injoignable, erreur d'auth, rejet de schema), Hermes écrit un diagnostic structuré dans ~/.hermes/logs/subagent-timeout-*.log.
Modèle override
Pour les tâches simples, déléguer à un modèle moins cher et plus rapide :
delegation:
model: "google/gemini-flash-2.0"
provider: "openrouter"
Si omis, les sous-agents utilisent le même modèle que le parent.
Max iterations
delegate_task(
goal="Quick file check",
context="Check if /etc/nginx/nginx.conf exists",
max_iterations=10 # Tache simple, peu de tours necessaires
)
Outils disponibles pour les sous-agents
Le paramètre toolsets contrôle les outils accessibles :
-
["terminal", "file"]— Code, debugging, builds -
["web"]— Recherche, vérification de faits -
["terminal", "file", "web"]— Full-stack (défaut) -
["file"]— Analyse read-only -
["terminal"]— Administration système
Outils bloqués pour les sous-agents
Certains outils sont systématiquement bloqués, peu importe la config :
-
clarify — les sous-agents ne peuvent pas interagir avec l'utilisateur
-
memory — pas d'écriture dans la mémoire persistante partagée
-
send_message — pas d'effets de bord cross-plateforme (pas d'envoi Telegram, etc.)
-
code_execution — les enfants doivent raisonner étape par étape
-
delegate_task — bloqué pour les leafs (défaut), conservé pour les orchestrateurs
Ces restrictions sont fondamentales : un sous-agent ne peut ni poser de question, ni mémoriser, ni envoyer de messages à l'utilisateur. Il doit être totalement autonome.
Quand déléguer vs faire soi-même
Déléguer quand :
-
La tâche nécessite un contexte frais pour éviter la pollution (longue session parente)
-
Plusieurs tâches sont indépendantes et parallélisables
-
La tâche risque de noyer le contexte parent (refactoring massif, logs longs)
-
Vous voulez utiliser un modèle différent (plus rapide/cher) pour une sous-tâche
-
La tâche nécessite un raisonnement complet avec boucle outil-LLM
Faire soi-même quand :
-
La tâche est simple et courte (un fichier à lire, une commande à lancer)
-
Le contexte parental est essentiel à la compréhension de la tâche
-
Vous avez besoin d'interagir avec l'utilisateur pendant le processus
-
La tâche modifie des fichiers que le parent manipule aussi (risque de conflit)
-
Le coût d'un sous-agent additionnel n'est pas justifié
Exemples concrets
Recherche parallèle
Rechercher trois sujets simultanément et collecter les résumés :
delegate_task(tasks=[
{
"goal": "Rechercher l'etat de WebAssembly en 2025",
"context": "Focus: support navigateurs, runtimes non-navigateur, langages",
"toolsets": ["web"]
},
{
"goal": "Rechercher l'adoption de RISC-V en 2025",
"context": "Focus: serveurs, embarque, ecosysteme logiciel",
"toolsets": ["web"]
},
{
"goal": "Rechercher les avancees en informatique quantique 2025",
"context": "Focus: correction d'erreurs, applications pratiques",
"toolsets": ["web"]
}
])
Les trois sous-agents travaillent en parallèle, chacun avec son propre terminal et cycle de recherche. Le parent reçoit trois résumés structurés qu'il peut synthétiser.
Développement multi-fichiers
Déléguer un refactoring massif qui inonderait le contexte parent :
delegate_task(
goal="Remplacer tous les print() par du logging dans src/",
context="Project at /home/user/myproject.
Use logging.getLogger(__name__).
- print(f'Error: ...') -> logger.error(...)
- print(f'Warning: ...') -> logger.warning(...)
- print(f'Debug: ...') -> logger.debug(...)
- Other prints -> logger.info(...)
Don't change test files or CLI output.
Run pytest after to verify.",
toolsets=["terminal", "file"]
)
Audit de sécurité avec correction
delegate_task(
goal="Auditer le module d'authentification et corriger les failles",
context="Project at /home/user/webapp.
Auth files: src/auth/login.py, src/auth/jwt.py, src/auth/middleware.py
Stack: Flask, PyJWT, bcrypt.
Focus: injection SQL, validation JWT, gestion mots de passe, sessions.
Run pytest tests/auth/ after fixes.",
toolsets=["terminal", "file"]
)
Code review en contexte isolé
Lorsqu'une session parente accumule trop de contexte, déléguer la review à un sous-agent frais garantit une analyse impartiale :
delegate_task(
goal="Reviewer les derniers commits et identifier les problemes",
context="Project at /home/user/myapp. Run 'git log --oneline -20' first.",
toolsets=["terminal", "file"]
)
Vérification des résultats des sous-agents
Un sous-agent retourne uniquement un résumé final, pas les résultats intermédiaires. Le parent doit :
-
Lire le résumé pour comprendre ce qui a été fait
-
Vérifier les fichiers modifiés listés dans le résumé
-
Valider les résultats (exécuter les tests, lire le code modifié)
-
Corriger si nécessaire — le parent peut reprendre là où le sous-agent s'est arrêté
Ne faites jamais confiance aveuglément à un sous-agent. La vérification parentale est essentielle, surtout pour les modifications de code en production.
Monitoring : la commande /agents
Le TUI d'Hermes Agent inclut un overlay /agents (alias /tasks) pour surveiller les sous-agents en temps réel :
-
Vue arborescente live des sous-agents actifs et récemment terminés
-
Métriques par branche : coût, tokens, fichiers touchés
-
Contrôles : tuer ou pauser un sous-agent spécifique sans interrompre ses siblings
-
Review post-mortem : parcourir l'historique tour-par-tour de chaque sous-agent
En CLI classique, /agents affiche un résumé textuel. La vue TUI est la plus complète.
Propagation des interruptions
Interruption du parent = interruption de tous les enfants actifs. Cela inclut les petits-enfants sous les orchestrateurs. Les sous-agents interrompus retournent un résultat structuré status="interrupted", mais le parent étant aussi interrompu, ce résultat n'atteint souvent pas l'utilisateur.
Pour du travail durable qui doit survivre aux interruptions, préférez les cron jobs ou terminal(background=True, notify_on_complete=True).
Délégation vs execute_code
Hermes Agent propose aussi execute_code pour les pipelines mécaniques. Comment choisir ?
-
delegate_task — raisonnement LLM complet, boucle outil-LLM, parallélisme, meilleur pour les tâches complexes nécessitant du jugement. Coût en tokens plus élevé.
-
execute_code — exécution de script Python, pas de conversation, 7 outils via RPC, pas de raisonnement. Meilleur pour les pipelines mécaniques multi-étapes. Coût en tokens plus faible.
Règle empirique : déléguez quand la sous-tâche nécessite du raisonnement, du jugement ou de la résolution de problème multi-étapes. Utilisez execute_code pour le traitement de données mécanique.
ACP : spawner Claude Code et Codex CLI comme sous-agents
Grâce aux outils disponibles dans Hermes, il est possible de spawner des agents externes comme sous-traitants :
`# Spawner Claude Code pour un audit de code
delegate_task(
goal="Run Claude Code to audit the codebase",
context="Launch claude code in /home/user/project.
Ask it to review the auth module for security issues.
Report findings as a structured list.",
toolsets=["terminal"]
)
Spawner Codex CLI pour du code generation
delegate_task(
goal="Use Codex CLI to generate API endpoints",
context="Project at /home/user/api.
Run 'codex \"generate CRUD endpoints for users model\"'
Integrate the output into the existing FastAPI app.",
toolsets=["terminal"]
)`
Cette approche combine le meilleur de chaque outil : l'orchestration d'Hermes Agent avec l'expertise spécialisée de Claude Code ou Codex CLI, le tout dans des contextes isolés et parallélisables.
Pièges courants à éviter
-
Contexte insuffisant : ne pas passer assez d'informations dans
context. Le sous-agent est aveugle — soyez explicite. -
Conflits de fichiers : deux sous-agents qui modifient le même fichier simultanément. Planifiez les tâches pour éviter les chevauchements.
-
S'attendre à des résultats intermédiaires : seul le résumé final est retourné. Pas de streaming pas-à-pas.
-
Oublier la vérification : un sous-agent peut produire un résultat partiellement incorrect. Validez toujours.
-
Coûts cachés : chaque sous-agent consomme des tokens. Surveillez avec
/agents. -
Profondeur excessive :
max_spawn_depth: 3avec 3 enfants = 27 agents potentiels. Soyez prudent.
Conclusion
La délégation de tâches via delegate_task est l'une des capacités les plus transformatrices d'Hermes Agent. Elle permet de passer d'un modèle d'exécution séquentiel à une orchestration parallèle d'agents autonomes, chacun isolé dans son contexte mais coordonné par un parent intelligent.
Les points clés à retenir :
-
Les sous-agents démarrent avec un contexte vierge — fournissez tout ce dont ils ont besoin via
goaletcontext -
Le mode batch parallélise jusqu'à N tâches simultanées (3 par défaut)
-
Les rôles leaf vs orchestrator et les paramètres
max_spawn_depth/max_concurrent_childrencontrôlent la complexité de l'arbre -
Les sous-agents ne peuvent pas utiliser clarify, memory, send_message ni code_execution
-
Vérifiez toujours les résultats retournés par les sous-agents
-
Combinez avec des outils externes comme Claude Code ou Codex CLI pour des workflows hybrides puissants
Conclusion
Maîtriser la délégation, c'est transformer Hermes Agent en un véritable chef d'orchestre d'IA, capable de mener à bien des projets complexes en fractionnant le travail intelligemment — tout en gardant la supervision humaine là où elle compte.
Les points essentiels :
-
Utilisez delegate_task pour les sous-tâches autonomes qui consommeraient trop de contexte
-
Les sous-agents travaillent en isolement complet — passez tout le contexte nécessaire
-
Réspectez la limite de
max_concurrent_childrenet lemax_spawn_depth -
Vérifiez toujours les résultats retournés avant de les exploiter
Pour approfondir, consultez notre guide sur les serveurs MCP qui permettent d'étendre les capacités des sous-agents avec des outils externes.
Conclusion
La délegation via delegate_task est l'une des fonctionnalités les plus puissantes d'Hermes Agent. Elle permet de paralléliser le travail, de gérer plusieurs tâches simultanément, et de conserver un contexte principal propre tout en explorant des pistes en parallèle. Les sous-agents travaillent en isolation complète, ce qui garantit que le contexte du parent reste pertinent et exploitable. Pour des projets complexes nécessitant de la recherche, du développement et des tests en parallèle, la délegation est un atout décisif qui multiplie la productivité de votre agent IA.