OpenClaw

Orchestrer des PR avec OpenClaw : Cas Réel DevOps

Avant : un agent qui code seul. Après : 7 rôles, vérification, tests et PR. Comment Ryan Carson structure une équipe d'agents OpenClaw avec Antfarm.

La Pince

La Pince

— 5 min de lecture
Orchestrer des PR avec OpenClaw : Cas Réel DevOps

Bon dimanche ! ☕

Aujourd'hui, on plonge dans un cas qui touche un nerf sensible chez tous ceux qui utilisent des agents pour coder : comment passer d'un assistant puissant mais ponctuel à une vraie chaîne de livraison, avec rôles, validations, reprises et PR.

Le cas du jour s'appelle Antfarm. Ce n'est pas un simple prompt partagé dans un thread : c'est un repo public, maintenu par Ryan Carson, qui transforme OpenClaw en petite équipe d'agents spécialisés. L'architecture est suffisamment concrète pour être étudiée, critiquée et adaptée.

🎯 Le Cas : Une équipe d'agents pour livrer des PR

Auteur : Ryan Carson / snarktank (source GitHub)
Contexte : un workflow de développement logiciel où l'on veut confier une feature, un bugfix ou un audit sécurité à plusieurs agents OpenClaw spécialisés.
Objectif : installer une chaîne reproductible qui planifie, implémente, vérifie, teste, crée une PR et, selon le workflow, poste aussi une review.

Le repo Antfarm a été créé le 6 février 2026 et se présente comme un outil pour “build your agent team in OpenClaw with one command”. Son README annonce trois workflows : feature-dev, bug-fix et security-audit, avec Node.js 22+, OpenClaw v2026.2.9+ et gh CLI en prérequis.

📖 L'Histoire

Le problème de départ est classique : un agent généraliste peut aider à coder, mais il mélange souvent plusieurs responsabilités. Il comprend la demande, modifie les fichiers, lance des tests, juge son propre travail, puis résume. Ça marche pour une tâche courte. Ça devient fragile dès qu'il faut plusieurs passes, des tests, une revue et une trace exploitable.

Antfarm attaque ce problème en déplaçant la complexité du prompt vers un workflow explicite. Dans feature-dev, un planner découpe la tâche en user stories, un agent setup prépare la branche et mesure le baseline, un developer implémente chaque story, un verifier contrôle chaque étape, un tester passe sur l'intégration, puis une PR et une review sont produites. Ce n'est pas “un agent qui pense à tout”. C'est une chaîne où chaque rôle a un périmètre.

Le repo contient aussi un indice précieux : progress.txt. On y voit un run réel horodaté pour ajouter une commande cachée au CLI, puis plusieurs stories techniques sur l'injection de version, le polling, les prompts et le support de modèles. Les entrées listent les fichiers touchés, les tests créés, les commandes de build, les résultats et même les apprentissages du codebase. Une entrée note par exemple “All 105 tests pass, build passes, typecheck passes”. C'est exactement le type de trace qui rend un agent exploitable dans un workflow sérieux.

La solution finale n'essaie pas de remplacer GitHub, les tests ou la review. Elle les orchestre. OpenClaw fournit les sessions isolées, le cron et les workspaces ; Antfarm fournit le contrat : ordre, accès et condition de réussite.

🔧 Le Setup Technique

Architecture Agent

Le coeur du système tient en quatre briques :

  • OpenClaw : exécute les agents dans des sessions isolées, avec cron pour faire avancer les workflows.
  • Antfarm CLI : installe les workflows, crée les workspaces, stocke l'état et expose les commandes de suivi.
  • YAML + Markdown : chaque workflow décrit ses agents, ses rôles, ses étapes et ses prompts.
  • SQLite + fichiers de progression : l'état de run est persistant, tandis que les apprentissages opérationnels passent par des logs comme progress-<run_id>.txt.

Le workflow feature-dev est le plus parlant :

plan -> setup -> implement -> verify -> test -> pr -> review

L'étape implement est une boucle : le developer reçoit une story à la fois, dans une session fraîche, puis le verifier contrôle avant de passer à la suivante. Ce choix réduit le bruit de contexte.

Fichiers Clés

workflow.yml

id: feature-dev
name: Feature Development Workflow
version: 5
description: |
  Story-based execution pipeline. Planner decomposes tasks into user stories.
  Setup prepares the environment and establishes baseline.
  Developer implements each story (with tests) in a fresh session.
  Verifier checks each story.

Rôles

agents:
  - id: planner
    role: analysis
  - id: developer
    role: coding
  - id: verifier
    role: verification
  - id: tester
    role: testing
  - id: reviewer
    role: analysis

La séparation des rôles est importante : le verifier n'a pas le même mandat que le developer. Le guide documente des capacités différentes : analysis, coding, verification, testing, pr, scanning. Celui qui écrit le code ne devrait pas être le seul à déclarer que tout va bien.

Installation

curl -fsSL https://raw.githubusercontent.com/snarktank/antfarm/v0.5.1/scripts/install.sh | bash
antfarm workflow list
antfarm workflow install feature-dev
antfarm workflow run feature-dev "Add user authentication with OAuth"
antfarm workflow status "OAuth"

Le README propose aussi une installation manuelle :

git clone https://github.com/snarktank/antfarm.git ~/.openclaw/workspace/antfarm
cd ~/.openclaw/workspace/antfarm
npm install
npm run build
npm link
antfarm install

Étapes de Mise en Place

  1. Installer Node.js 22+, OpenClaw v2026.2.9+ et gh CLI.
  2. Installer Antfarm depuis GitHub, pas depuis npm : le README précise qu'un paquet npm homonyme existe mais n'est pas ce projet.
  3. Lancer antfarm workflow list pour vérifier les workflows disponibles.
  4. Installer un workflow ciblé, par exemple antfarm workflow install feature-dev.
  5. Démarrer une tâche avec antfarm workflow run feature-dev "".
  6. Suivre l'avancement via antfarm workflow status ou le dashboard sur le port 3333.
  7. En cas d'échec, utiliser antfarm workflow resume plutôt que relancer à zéro.

📊 Les Résultats

Gains mesurés publiquement :

  • 3 workflows prêts à l'emploi : feature development, bug fix, security audit.
  • 6 à 7 agents par workflow selon le scénario.
  • Jusqu'à 20 stories ou fixes par run dans le modèle documenté.
  • Un run public dans progress.txt montre des stories exécutées avec fichiers modifiés, tests ajoutés, build, typecheck et jusqu'à 105 tests passants.
  • Le repo expose une adoption GitHub notable : plusieurs milliers de stars et plusieurs centaines de forks au moment de la consultation via l'API GitHub.

Limites rencontrées :

  • Les gains de temps ne sont pas quantifiés publiquement. On peut mesurer la structure, pas promettre “X heures économisées”.
  • Le setup dépend fortement de l'environnement local : Node 22 réel, OpenClaw récent, GitHub CLI configuré et tests du projet cible.
  • Le workflow exécute du code localement : le bénéfice vient avec une surface de risque réelle.

🧐 Analyse Critique

✅ Ce qui est bien fait

  • Le workflow est déterministe. Les étapes sont explicites, ordonnées et vérifiables. C'est plus robuste qu'un long prompt demandant à un agent de “faire une PR propre”.
  • La vérification est séparée de l'implémentation. Le verifier contrôle les critères, les tests, le diff et les placeholders. Dans bug-fix, il doit même rejeter un diff vide ou trivial.
  • La mémoire opérationnelle est concrète. Les fichiers de progression capturent les patterns du codebase, les fichiers touchés et les résultats de tests.
  • La sécurité est prise au sérieux dans le design. Le fichier SECURITY.md explique que les workflows sont en YAML/Markdown lisibles, que les contributions passent par review et que les agents sont isolés par session et workspace.

⚠️ Points d'attention

  • Installer via curl | bash reste un acte de confiance. Pour un usage professionnel, mieux vaut lire le script, pinner une version et tester ailleurs.
  • Les agents peuvent modifier du code et créer des PR. Les tokens GitHub, les secrets locaux et les dépôts privés doivent être cloisonnés. Le workflow ne remplace pas une politique de permissions.
  • La qualité dépend des critères d'acceptation. Si le planner découpe mal la tâche ou écrit des critères vagues, toute la chaîne devient mécaniquement vague.
  • La vérification automatisée n'est pas une review humaine complète. Elle attrape beaucoup de problèmes de process, pas tous les choix produit ou architecture.

💡 Améliorations possibles

  • Ajouter des exemples de runs complets avec PR publiques, du ticket initial jusqu'à la review finale.
  • Publier des métriques comparatives : temps moyen par story, taux de retries, causes d'échec, pourcentage de PR acceptées sans retouche humaine.
  • Proposer un profil “lecture seule” pour tester Antfarm sur un repo sans risquer de pousser des branches ou d'ouvrir des PR.

🎓 Ce qu'on en retient

Leçons clés :

  1. Un bon agent de production n'est pas seulement un bon prompt : c'est un contrat d'exécution, de vérification et de reprise.
  2. Les sessions fraîches sont un vrai avantage quand une tâche dépasse une fenêtre de contexte raisonnable.
  3. La séparation des rôles rend les agents plus auditables : planner, developer, verifier et reviewer ne doivent pas porter la même casquette.

Pour aller plus loin :

À dimanche prochain pour un nouveau cas ! 🦞

Lire la suite