Agents, skills et canaux — Openclaw

À retenir — Le cœur d'OpenClaw : faire cohabiter plusieurs agents spécialisés, chacun isolé dans son workspace, leur donner des skills (outils) et les rendre joignables depuis de vrais canaux de messagerie.

Au chapitre précédent, vous aviez un agent par défaut joignable en local. On passe maintenant au cœur d'OpenClaw : faire cohabiter plusieurs agents spécialisés, leur donner des outils (skills) et les rendre joignables depuis de vrais canaux de messagerie.

Créer des agents spécialisés

Chaque agent vit dans son propre workspace — un dossier qui contient sa mémoire et son état, totalement isolés des autres. On ajoute un agent en une commande :

# Un agent "work" et un agent "ops", chacun avec son workspace
openclaw agents add work --workspace ~/.openclaw/workspace-work
openclaw agents add ops  --workspace ~/.openclaw/workspace-ops

Dans la config, les agents sont décrits sous agents.list. Chacun a une identité (nom, emoji, avatar) et peut surcharger les réglages par défaut :

{
  agents: {
    // Réglages communs à tous les agents
    defaults: {
      skills: ["files", "shell", "web"],
    },
    list: [
      {
        id: "main",
        identity: { name: "OpenClaw", emoji: "🦞", avatar: "avatars/openclaw.png" },
      },
      {
        id: "ops",
        identity: { name: "Ops Bot", emoji: "🛠️" },
        // Cet agent voit moins d'outils que le défaut
        skills: ["files", "web"],
      },
    ],
  },
}

Isolation = sécurité + clarté

Chaque agent garde ses transcripts et son état dans son propre workspace. Un agent « support » ne peut pas lire la mémoire de l'agent « ops ». Cette isolation limite les fuites de contexte et rend le comportement de chaque agent prévisible.

Donner des outils : les skills

Les skills sont les capacités qu'un agent peut utiliser : accès aux fichiers, exécution shell, recherche web, automatisation de navigateur, intégrations Google Workspace, etc. La visibilité des skills se contrôle à deux niveaux :

agents.defaults.skills — les outils disponibles par défaut pour tous les agents.
agents.list[].skills — la liste propre à un agent, qui surcharge le défaut.

C'est le levier central du principe de moindre privilège : ne donnez à chaque agent que les outils dont il a réellement besoin.

Le bon réflexe : restreindre par défaut

Partez d'un périmètre minimal et élargissez seulement quand un usage le justifie. Un agent qui ne fait que résumer du web n'a aucune raison d'avoir accès au shell.

OpenClaw dispose en plus d'une bibliothèque communautaire de skills et d'intégrations réutilisables (productivité, vision/audio, domotique, automatisation…). On peut donc partir de briques existantes plutôt que tout réécrire.

Connecter des canaux de messagerie

Un canal, c'est l'interface par laquelle les humains parlent aux agents. La connexion suit toujours le même schéma : on déclare le canal dans la config (avec ses tokens en variables d'environnement), puis on (re)démarre le Gateway.

Exemple : Slack

Slack se connecte en mode Socket (le plus simple, sans URL publique) ou en mode HTTP. En Socket Mode :

{
  channels: {
    slack: {
      enabled: true,
      mode: "socket",
      appToken: { source: "env", provider: "default", id: "SLACK_APP_TOKEN" },
      botToken: { source: "env", provider: "default", id: "SLACK_BOT_TOKEN" },
    },
  },
}

On applique le patch, puis on démarre le Gateway :

openclaw config patch --file ./slack.socket.patch.json5
openclaw gateway

Restreindre qui peut parler à l'agent

Sur les canaux grand public (WhatsApp, Telegram…), on filtre les expéditeurs autorisés et on peut exiger une mention dans les groupes :

{
  channels: {
    whatsapp: {
      allowFrom: ["+15555550123"],
      groups: { "*": { requireMention: true } },
    },
  },
  messages: { groupChat: { mentionPatterns: ["@openclaw"] } },
}

Toujours filtrer les entrées

Un agent exposé sans allowFrom répond à n'importe qui. Sur un canal public, c'est la porte ouverte à l'abus. Définissez systématiquement la liste des expéditeurs autorisés et exigez une mention dans les groupes.

Router les messages vers le bon agent

Avec plusieurs agents et plusieurs canaux, il faut décider qui répond à quoi. OpenClaw épingle le trafic d'un canal sur un agent via une liaison --bind channel:account, et chaque tour de conversation peut cibler un agent précis :

# Cibler explicitement l'agent "ops" et livrer la réponse sur Slack
openclaw agent --agent ops --message "Résume les logs de la nuit" --deliver --reply-channel slack

Les clés de session permettent de garder des conversations distinctes : une clé préfixée agent:<agent-id>:<session-key> scope la mémoire à un agent donné.

À retenir

OpenClaw devient vraiment puissant quand on combine agents spécialisés (chacun dans son workspace isolé), skills finement dosés (principe de moindre privilège via agents.defaults.skills et agents.list[].skills) et canaux filtrés (allowFrom, requireMention). Le routage --bind et les clés de session orchestrent qui répond à quoi. Reste une question essentielle avant la prod : comment sécuriser tout ça ? C'est l'objet du dernier chapitre.