Créer un agent avec OpenClaw
Créez un agent OpenClaw avec un workspace isolé, une identité claire, des skills ciblés et un binding vérifiable, sans code Python inventé.
Introduction
La requête « créer agent OpenClaw » désigne la création d’un espace d’assistant durable, pas celle d’une classe Python. Cette démarche est utile lorsque vous voulez séparer une mission, une identité, une mémoire, des skills ou un canal dans un Gateway existant. Vous allez créer un workspace, définir des instructions, vérifier les capacités puis exécuter un premier tour ciblé. Si votre besoin est une seule question ponctuelle ou un script déterministe, un nouvel agent est inutile : gardez une approche plus simple et le profil principal. Le résultat attendu est un agent identifiable, correctement routé et limité aux outils nécessaires, avec une recette reproductible avant toute mise en production.
Résumé rapide
- Vérifiez le Gateway et listez les agents existants.
- Créez un agent avec
openclaw agents addet un workspace distinct. - Écrivez son rôle dans les fichiers du workspace.
- Ajoutez seulement les skills nécessaires et contrôlez leur éligibilité.
- Testez un tour, puis ajoutez un binding si un canal doit lui être dédié.
Du concept au workspace isolé
OpenClaw est un assistant agentique self-hosted distribué comme application Node/TypeScript. Son centre de gravité est le Gateway : un processus durable qui relie le runtime d'agent aux interfaces de contrôle, aux canaux de messagerie et, si besoin, à des nodes mobiles ou headless. La CLI et la Control UI pilotent ce même système. Cette architecture diffère d'un framework Python intégré dans une application : on configure et exploite un service, on ne construit pas un pipeline en important une classe Agent.
Chaque agent possède un workspace. On y trouve ses instructions, son identité, ses fichiers de mémoire et ses skills. Les skills sont des dossiers documentaires contenant un SKILL.md ; ils apprennent à l'agent quand et comment employer des tools déjà disponibles. Une capacité runtime nouvelle relève plutôt d'un plugin, qui peut ajouter tools, providers, canaux ou hooks. Cette distinction évite de transformer un simple mode opératoire Markdown en faux SDK.
Le mode mono-agent suffit par défaut. Le multi-agent ajoute des workspaces, états et sessions séparés, puis des bindings déterministes pour router les messages. Il ne s'agit pas d'une équipe CrewAI qui se distribue spontanément des rôles : ce sont des assistants isolés servis par un Gateway commun. Les automations planifient des tours ou des événements à l'intérieur de ce Gateway.
La commande de création produit l’identité opérationnelle que l’ancien pseudo-SDK Python prétendait construire par code. Les instructions et la configuration remplacent AgentConfig, tandis que les tools et plugins portent les capacités exécutables. Lisez les agents OpenClaw pour approfondir les frontières d’état et de sessions.
Créer le premier agent pas à pas
1. Vérifier le service
openclaw gateway status
openclaw agents list --bindings
Notez l’agent par défaut et les bindings existants. Ne réutilisez pas le workspace d’un autre agent.
2. Créer l’agent
openclaw agents add research --workspace ~/.openclaw/workspace-research --non-interactive
Le nom devient l’identifiant utilisé par la CLI et la configuration. Pour un parcours guidé, lancez openclaw agents add research sans options et répondez aux questions.
3. Définir sa mission
Dans le workspace, utilisez AGENTS.md pour les règles de travail et SOUL.md pour le ton. Ajoutez USER.md seulement si cet agent a besoin de préférences stables. Une bonne mission précise les entrées acceptées, le livrable, les sources permises, les actions interdites et le moment où demander confirmation.
4. Préparer les skills
Placez un skill spécifique sous ~/.openclaw/workspace-research/skills/<nom>/SKILL.md, puis vérifiez :
openclaw skills list --agent research
openclaw skills check --agent research
Un skill est une instruction Markdown ; il ne crée pas une méthode exécutable. S’il dépend d’un binaire, d’une variable ou d’un plugin, déclarez le prérequis et vérifiez que le tool réel est autorisé. Le guide des skills donne le format.
5. Exécuter un premier tour
openclaw agent --agent research --message "Analyse les notes du workspace et produis un résumé test"
Relisez le résultat et vérifiez les fichiers créés. Testez aussi une action interdite pour confirmer la policy.
6. Ajouter un binding si nécessaire
Un agent utilisable en CLI n’a pas besoin de binding. Ajoutez-en un seulement pour router un compte de canal vers lui, puis contrôlez openclaw agents list --bindings. Redémarrez le Gateway si le changement l’exige et envoyez un message réel depuis le canal.
7. Préparer la production
Limitez les tools, activez le sandbox adapté et exécutez openclaw security audit --deep. Documentez le modèle, les credentials, les propriétaires, le chemin du workspace et la procédure de retrait du binding.
Checklist finale
- workspace distinct ;
- mission et interdits lisibles ;
- skills éligibles ;
- tools minimaux ;
- tour positif vérifié ;
- cas négatif refusé ;
- binding testé si présent ;
- audit sans alerte critique.
Repère opérationnel supplémentaire
Le Gateway doit rester le point de référence opérationnel. Il porte les sessions, les connexions aux canaux et le routage ; un redémarrage ou une panne affecte donc toutes les surfaces qui en dépendent. En production, supervisez le processus, conservez une procédure de redémarrage, puis vérifiez son état avec openclaw gateway status. Les automations exigent elles aussi un Gateway actif au moment prévu. Cette topologie est plus simple à exploiter qu'une collection de scripts dispersés, mais elle impose de traiter le Gateway comme un service durable et non comme une commande ponctuelle.
Repère opérationnel supplémentaire
Le workspace facilite l'organisation, mais ce n'est pas une frontière de sécurité. Il fournit le répertoire de travail, les instructions, les skills et les fichiers de mémoire ; sans sandbox, un outil autorisé peut encore atteindre d'autres chemins de l'hôte. Pour un assistant exposé à plusieurs personnes, limitez les outils, activez l'isolation adaptée et séparez les Gateway lorsque les utilisateurs ne partagent pas le même niveau de confiance. Une allowlist de skills réduit ce que le modèle voit, mais ne remplace jamais une politique d'exécution shell.
Repère opérationnel supplémentaire
La validation doit porter sur un effet observable. Après une modification, lancez une demande courte, vérifiez le fichier ou le message produit, puis consultez les logs et l'historique de session en cas d'écart. Évitez de conclure qu'une opération a réussi uniquement parce que la CLI n'a pas retourné d'erreur. Pour les actions avec effets de bord, ajoutez une étape de lecture après écriture, un identifiant d'exécution et une règle d'idempotence. Cela réduit les doublons lors d'un retry ou d'une reprise après interruption.
Exemple concret
Une équipe éditoriale crée research pour préparer des dossiers sans publier. Elle lance la commande de création avec un workspace dédié. Dans AGENTS.md, elle impose trois règles : utiliser uniquement les sources présentes dans un dossier de recherche, produire un brouillon Markdown et ne jamais envoyer de message externe. Un skill dossier-editorial décrit la checklist de collecte et le format de sortie.
L’opérateur vérifie le skill avec openclaw skills check --agent research, puis lance un tour CLI demandant un résumé des notes disponibles. Il ouvre le fichier généré et contrôle la présence des rubriques attendues. Un second prompt demande de publier le texte ; la policy de tools doit empêcher l’envoi. Enfin, l’équipe crée un compte de canal dédié, ajoute le binding vers research et vérifie qu’un message test n’arrive pas dans main. Cette recette prouve la mission, les capacités, le refus et le routage, au lieu de se limiter à un message de succès.
Bonnes pratiques
Créez un agent seulement pour une frontière durable : identité, canal, credentials, mémoire ou policy. Utilisez des noms stables et des workspaces séparés. Gardez AGENTS.md actionnable ; déplacez les longs modes opératoires dans des skills. N’accordez pas un tool parce qu’un exemple pourrait un jour en avoir besoin.
Votre checklist de maintenance doit inclure l’agent propriétaire, les bindings, les secrets, les skills, le sandbox, les logs et un test périodique. Avant la production, exécutez openclaw doctor et openclaw security audit --deep. Si deux groupes d’utilisateurs sont adverses, ne comptez pas sur deux agents du même Gateway : séparez les services et les comptes système.
Questions fréquentes
Comment créer un agent OpenClaw sans Python ?
Utilisez openclaw agents add <nom> et attribuez-lui un workspace. Son comportement vient des fichiers d’instructions, de la configuration, des skills et des tools autorisés. Testez-le ensuite avec openclaw agent --agent <nom> --message "...". Aucun import Python n’est nécessaire.
Faut-il un binding pour chaque agent OpenClaw ?
Non. Un agent peut être ciblé directement par la CLI. Un binding est nécessaire seulement pour router automatiquement un canal, un compte ou une conversation vers lui. Après l’ajout, vérifiez toujours le routage avec openclaw agents list --bindings et un message réel.
Quels fichiers définissent un agent OpenClaw ?
Le workspace peut contenir AGENTS.md, SOUL.md, USER.md, MEMORY.md, des notes sous memory/ et des skills sous skills/. Le répertoire d’état séparé conserve notamment l’authentification et les sessions. Tous ces fichiers ont des rôles différents.
Comment tester un premier agent OpenClaw ?
Lancez un tour ciblé, relisez l’effet produit, puis essayez une demande qui doit être refusée. Vérifiez ensuite le skill avec openclaw skills check, le routage avec openclaw agents list --bindings et l’installation avec openclaw doctor.
Articles liés
Un agent OpenClaw réussi est un workspace durable, ciblé et vérifié, pas un objet Python. Commencez sans canal dédié, puis ajoutez skills, tools et binding uniquement quand le cas d’usage le demande.
Restez informé sur les agents IA
Nouveaux tutoriels, comparatifs et guides pratiques directement dans votre boîte mail.