OpenClaw

Animer des Réunions avec OpenClaw : Cas Réel Support

Avant : des agents isolés dans leurs canaux. Après : une discussion Feishu orchestrée, testable et conclue par [END]. Setup complet avec OpenClaw.

La Pince

La Pince

— 5 min de lecture
Animer des Réunions avec OpenClaw : Cas Réel Support

Bon dimanche ! ☕

Aujourd'hui, on plonge dans un cas très concret : faire discuter plusieurs agents OpenClaw dans un vrai canal d'équipe, sans transformer le daemon en usine à règles métier. Le projet s'appelle openclaw-team-in-feishu, il est public, maintenu par nativeProductor, et il documente une intégration Feishu pensée pour des discussions multi-agents structurées.

Le point intéressant n'est pas seulement “OpenClaw répond dans un chat”. C'est plutôt : comment orchestrer plusieurs agents spécialisés, dans plusieurs groupes, avec un transcript partagé, des rôles clairs, et une condition d'arrêt explicite.

🎯 Le Cas : Agents OpenClaw en Réunion Feishu

Auteur : nativeProductor (source GitHub)
Contexte : une équipe utilise déjà plusieurs agents OpenClaw séparés, mais veut les faire collaborer dans des groupes Feishu/Lark.
Objectif : lancer une discussion structurée depuis un @host, faire intervenir les agents membres, puis obtenir une synthèse quand la conversation converge.

📖 L'Histoire

La situation de départ est familière : on crée plusieurs agents OpenClaw, chacun avec son rôle, son workspace et son SOUL.md. Individuellement, ils répondent. Mais dans une équipe, la valeur vient souvent de la confrontation : un agent produit, un agent dev, un agent QA, un agent marketing. Si chacun reste dans son canal, il faut recoller les morceaux à la main.

openclaw-team-in-feishu part de ce problème. Le README explique que l'utilisateur mentionne un bot hôte dans un groupe Feishu avec un sujet. Le hôte ouvre un fil, les membres contribuent, puis le hôte émet une synthèse finale quand la discussion a convergé. Ce n'est pas présenté comme un bot généraliste Feishu : le projet assume un périmètre plus étroit, celui d'un orchestrateur de discussions entre agents OpenClaw.

La première version distinguait apparemment un hôte avec plugin désactivé et des membres avec plugin activé. Depuis la note v0.1.2, le contrat a changé : le daemon possède tout le dispatch. Tous les plugins Feishu natifs des bots OpenClaw doivent être désactivés. C'est une décision importante, parce qu'elle évite les doubles réponses et permet à un même agent de servir plusieurs groupes Feishu.

La solution finale tient dans une séparation nette : le daemon gère la mécanique, les agents gèrent le jugement. Le daemon surveille Feishu, injecte le transcript, appelle openclaw agent --agent X --message ..., puis poste la réponse dans le fil. Les règles de discussion restent dans SOUL.md : ordre de parole, moments où répondre [SKIP], condition d'arrêt [END], ton et rôle métier.

🔧 Le Setup Technique

Architecture Agent

Le schéma conceptuel est simple :

Feishu group
  -> @host avec un sujet
  -> octf daemon détecte la mention
  -> host OpenClaw ouvre le fil
  -> membres OpenClaw appelés via CLI
  -> transcript injecté à chaque invocation
  -> réponses postées dans le thread Feishu
  -> host conclut avec [END]

Le daemon octf tourne comme un processus Node.js. Il maintient un état de transcript dans un dossier partagé, par exemple transcript-<thread_id>.md, mais les agents ne lisent pas directement ces fichiers. Le README insiste sur ce point : le daemon injecte le transcript pertinent dans le prompt à chaque appel.

Deux modes sont disponibles :

  • round-robin : le hôte appelle les membres dans un ordre prévu par le SOUL.md.
  • free-speak : le daemon sonde les agents ; chacun peut parler ou répondre [SKIP].

Fichiers Clés

SOUL.md

Tu es l'agent hôte.
Tu maintiens le fil de discussion, tu appelles les bons rôles,
tu conclus uniquement quand les points importants sont couverts.
Quand la décision est claire, termine par [END].

Le dépôt ne force pas ce texte exact : il fournit des templates et laisse les règles métier dans les âmes des agents. C'est précisément le bon endroit pour définir si la réunion doit être une revue produit, un débat technique, un brainstorming ou un triage support.

Config / Scripts

git clone https://github.com/nativeProductor/openclaw-team-in-feishu.git
cd openclaw-team-in-feishu
npm install --no-audit --no-fund
sudo npm link --no-audit --no-fund
octf --help

Le fichier de configuration suit cette forme :

{
  "version": 1,
  "openclawRoot": "/path/to/oc",
  "transcriptDir": "/path/to/oc/.shared",
  "polling": { "intervalMs": 2500, "openclawTimeoutSec": 180 },
  "apps": [
    {
      "appId": "cli_xxx",
      "appSecret": "${PM_HOST_SECRET}",
      "agent": "pm-host",
      "role": "Product",
      "botName": "ProductBot"
    }
  ],
  "chats": [
    {
      "name": "ProductReview",
      "chatId": "oc_xxx",
      "mode": "round-robin",
      "host": "pm-host",
      "members": ["dev", "mkt", "qa"],
      "modeOptions": { "maxRounds": 5, "endKeyword": "[END]" }
    }
  ]
}

Étapes de Mise en Place

  1. Créer les agents OpenClaw dans <openclawRoot>/<agent>/workspace/.
  2. Vérifier qu'un appel direct répond :
openclaw agent --agent pm-host --message "test"
  1. Créer les applications Feishu, une par agent, et ajouter les bots dans le groupe cible.
  2. Scaffolder la configuration :
mkdir -p /etc/octf && cd /etc/octf
octf init
  1. Renseigner les secrets via variables d'environnement ou /etc/octf/secrets.env, avec permissions strictes.
  2. Valider et appliquer le câblage :
octf link --apply
  1. Démarrer le daemon :
octf daemon start
  1. Tester de bout en bout :
octf verify --chat oc_xxx --topic "smoke test"

📊 Les Résultats

Gains mesurés :

  • 2 modes de collaboration documentés : round-robin et free-speak.
  • 1 commande de vérification end-to-end : octf verify, qui sort en succès quand le hôte émet [END].
  • Multi-groupes supporté depuis le changement de contrat v0.1.2 : un même agent peut servir plusieurs chats, tant que le daemon contrôle le dispatch.

Limites rencontrées :

  • Les bornes maxRounds et maxMessages sont “soft” : elles reposent sur le respect des consignes par le modèle.
  • Le coût d'entrée augmente avec la taille du transcript, puisque chaque invocation reçoit l'historique complet.
  • Si le daemon tombe, aucun bot ne répond : le README recommande un supervisor type systemd avec redémarrage automatique.

🧐 Analyse Critique

✅ Ce qui est bien fait

  • La responsabilité est proprement séparée. Le daemon transporte les messages ; les règles de discussion vivent dans SOUL.md. C'est plus maintenable qu'un orchestrateur rempli de cas métier.
  • Le risque de double réponse est traité explicitement. Exiger que tous les plugins Feishu natifs soient désactivés rend le flux plus prévisible.
  • Le test octf verify est une bonne idée : il valide le chemin complet, pas seulement la syntaxe de la config.

⚠️ Points d'attention

  • Le contrôle [END] reste fragile si les prompts sont mal écrits. Il faut tester les âmes des agents avec des sujets ambigus, pas seulement avec un smoke test heureux.
  • Le transcript complet dans chaque prompt est simple et robuste, mais il peut devenir cher sur des discussions longues.
  • La sérialisation par agent protège contre la corruption de session, mais elle réduit le parallélisme si plusieurs groupes partagent les mêmes agents.

💡 Améliorations possibles

  • Ajouter un résumé intermédiaire du transcript après N messages pour limiter le coût sans perdre le contexte.
  • Prévoir une commande humaine d'interruption contrôlée, par exemple un /octf stop, plutôt que de dépendre uniquement du [END] émis par le hôte.

🎓 Ce qu'on en retient

Leçons clés :

  1. Un bon orchestrateur multi-agent doit rester mécanique : router, injecter, journaliser, vérifier.
  2. Les règles métier doivent rester proches des agents, donc dans SOUL.md, pas dispersées dans le daemon.
  3. Le multi-agent en chat d'équipe devient exploitable quand il a une condition d'arrêt explicite et testable.

Pour aller plus loin :

À dimanche prochain pour un nouveau cas ! 🦞

Lire la suite