OpenClaw + Claude Code/Codex : Créer un essaim d'agents de développement personnel

Bonjour à tous, je suis Lu Gong.

Récemment, j'ai vu un tweet sur X qui m'a immédiatement captivé. Un développeur indépendant nommé Elvis a déclaré qu'il n'utilisait plus directement Claude Code et Codex, mais qu'il utilisait OpenClaw comme couche d'orchestration pour gérer un essaim d'agents Claude Code et Codex avec un orchestrateur AI nommé Zoe.

Les données de ce tweet étaient également impressionnantes, avec 4,9 millions de vues, 11 000 likes et 1 800 partages.

Nous avons écrit sur Vibe Coding pendant plus de quatre mois, et Claude Code a toujours été notre outil principal. J'ai également écrit quelques articles sur la collaboration multi-agents et l'architecture multi-agents de VSCode.

Mais en voyant la méthode d'Elvis, je ne peux que l'appeler un expert. Une personne, avec un système d'orchestration, soumet en moyenne 50 fois du code par jour, et a même soumis 94 fois en une seule journée, tout en prenant trois appels de clients, sans jamais ouvrir l'éditeur.

N'est-ce pas comme si une seule personne faisait le travail d'une équipe de développement ?

Aujourd'hui, cet article va décomposer comment il a réussi à faire cela.

OpenClaw, tout le monde le connaît déjà

Ce petit homard a été populaire depuis le Nouvel An. En termes simples, c'est un cadre d'agent AI open source, qui a déjà dépassé 240 000 étoiles sur GitHub, et a officiellement dépassé React il y a deux jours, devenant le projet open source à la croissance la plus rapide en termes d'étoiles dans l'histoire de GitHub.

Le fondateur Peter Steinberger est un développeur autrichien, qui a précédemment fondé PSPDFKit (une entreprise B2B de cadre PDF), et a obtenu un investissement de 100 millions d'euros de Insight Partners en 2021. En février de cette année, Peter a annoncé qu'il rejoignait OpenAI, et le projet OpenClaw a été transféré à une fondation open source pour son exploitation.

La position d'OpenClaw n'est pas celle d'un chatbot, mais d'un runtime d'agent AI qui fonctionne sur votre appareil local. Il a quatre composants principaux : Gateway (passerelle, connectant plus de 50 plateformes de messagerie), Agent (moteur d'inférence), Skills (plus de 5400 plugins), Memory (système de mémoire).

Mais la façon dont Elvis utilise OpenClaw est assez particulière. Il l'utilise directement comme couche d'orchestration, spécifiquement pour gérer des agents de codage comme Claude Code et Codex, sans l'utiliser comme assistant général.

Cette idée est en effet peu commune.

Pourquoi a-t-on besoin d'une couche d'orchestration ?

Elvis a mentionné un point clé dans son tweet : la fenêtre contextuelle est un jeu à somme nulle.

Si vous y mettez du code, il n'y a plus d'espace pour le contexte commercial. Si vous y mettez l'historique des clients et les comptes rendus de réunion, il n'y a plus d'espace pour le code. Peu importe la puissance d'un AI, il ne peut pas contenir simultanément ces deux types d'informations complètement différentes.

C'est pourquoi il a divisé le système en deux couches.

La couche supérieure est l'orchestrateur OpenClaw, Zoe, qui maîtrise tout le contexte commercial, y compris les données clients, les comptes rendus de réunion, les décisions historiques, quelles solutions ont été essayées et lesquelles ont échoué. Toutes ces informations sont stockées dans la bibliothèque de notes Obsidian d'Elvis, que Zoe peut lire directement.

La couche inférieure est constituée des agents de codage comme Claude Code et Codex, qui ne se concentrent que sur le code. Chaque fois qu'un agent est lancé, Zoe rédige un prompt précis basé sur le contexte commercial pour lui, lui indiquant ce qu'il doit faire, quel est le contexte et ce que le client souhaite.

En termes simples : l'orchestrateur est responsable de la compréhension des besoins, et les agents de codage sont responsables de l'exécution. Chacun fait ce qu'il sait faire le mieux.

Cette architecture est similaire à celle du système interne Minions récemment publié par Stripe. Les Minions de Stripe sont également conçus avec des agents de codage parallèles et une couche d'orchestration centralisée, capables de fusionner plus de 1000 PR entièrement rédigées par AI chaque semaine. Elvis a déclaré qu'il avait accidentellement construit une architecture similaire, mais qui fonctionne sur son propre Mac mini.

Flux de travail d'un cas réel

Elvis a utilisé un cas réel dans son tweet pour expliquer son flux de travail complet, je vais résumer les étapes clés.Il a pris un appel d'un client, qui souhaitait réutiliser une configuration existante au sein de l'équipe. Après l'appel, il a discuté de ce besoin avec Zoe. Comme tous les comptes rendus de réunion sont automatiquement synchronisés avec Obsidian, Zoe savait déjà ce que le client avait dit, il n'était pas nécessaire qu'Elvis explique davantage. Ils ont ensemble défini la portée des fonctionnalités, et la solution finale était de créer un système de modèles.

Ensuite, Zoe a automatiquement effectué trois actions : recharger le service de déverrouillage pour le client (elle a des droits d'API administrateur), extraire la configuration existante du client depuis la base de données de production (droits en lecture seule, l'Agent de codage n'aura jamais ce droit), puis générer un Agent Codex, avec un prompt détaillé contenant le contexte commercial complet.

Chaque Agent a son propre worktree (branche isolée) et sa session tmux. La commande de démarrage ressemble à ceci :

# Créer un worktree + lancer l'agent git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high" Après le démarrage de l'Agent, il y a une tâche planifiée qui vérifie toutes les 10 minutes. Mais il ne va pas directement demander à l'Agent (cela consommerait trop de tokens), mais exécute un script Shell déterministe pour vérifier si la session tmux est toujours active, s'il y a eu des PR créées, et si le CI a réussi.

Si le CI échoue, l'Agent redémarre automatiquement, avec un maximum de 3 tentatives. Une notification n'est envoyée que lorsque l'intervention humaine est nécessaire.

Après que l'Agent ait terminé sa tâche, il crée automatiquement une PR. Mais créer une PR ne suffit pas, Elvis a défini un ensemble de critères d'achèvement : création de la PR, synchronisation de la branche avec main (sans conflit de fusion), CI entièrement réussi, révision de code par les trois modèles d'IA entièrement réussie, et si des modifications de l'UI sont apportées, une capture d'écran doit également être jointe.

Trois modèles d'IA pour la révision de code

Les trois modèles d'IA pour la révision de code semblent très fiables. Discutons de son évaluation de ces trois modèles, c'est assez intéressant.

Codex Reviewer, il lui a donné la meilleure note, disant que sa révision est très approfondie en ce qui concerne les cas limites et les erreurs logiques, avec un faible taux de faux positifs.

Gemini Code Assist Reviewer, gratuit, il a dit qu'il est très utile, capable de détecter les vulnérabilités de sécurité et les problèmes d'évolutivité que d'autres modèles ont manqués, et peut également fournir des solutions de correction spécifiques.

Claude Code Reviewer, ses mots exacts étaient "pratiquement inutile", disant qu'il est trop prudent, avec plein de suggestions comme "envisagez d'ajouter...", la plupart étant des conceptions excessives. À moins qu'il ne soit marqué comme un problème critique, il passe directement.

Quand j'ai vu cela, j'ai été un peu surpris. En tant qu'utilisateur intensif de Claude Code, j'ai effectivement rencontré des situations où il était trop conservateur lors de la révision de code, mais dire qu'il est pratiquement inutile est un peu exagéré. Cependant, cela souligne également que la révision croisée par plusieurs modèles a effectivement de la valeur, les biais différents des modèles se complétant parfaitement.

Une fois que les trois révisions ont été approuvées, Elvis reçoit une notification Telegram. À ce stade, il se concentre principalement sur les captures d'écran pour confirmer si les modifications de l'UI sont correctes, et il fusionne de nombreuses PR sans même regarder le code. Il dit que sa révision manuelle ne prend que 5 à 10 minutes.

Proactivité de Zoe

Zoe n'est pas seulement une exécutante. Ce qui est plus intéressant que le flux de travail lui-même, c'est la proactivité de Zoe.

Elvis dit que Zoe ne reste pas à attendre qu'on lui attribue des tâches, elle cherche activement du travail à faire. Le matin, elle scanne les journaux d'erreurs de Sentry, découvre 4 nouvelles erreurs, et génère automatiquement 4 Agents pour les corriger. Après la réunion, elle scanne les comptes rendus de réunion, marque les 3 besoins fonctionnels mentionnés par le client, puis lance automatiquement 3 Agents Codex. Le soir, elle scanne les journaux Git, et lance Claude Code pour mettre à jour le changelog et la documentation client.

Quand Elvis sort faire un tour et revient, il trouve un message sur Telegram : 7 PR prêtes, 3 nouvelles fonctionnalités, 4 corrections de bugs. N'est-ce pas l'effet que j'ai toujours espéré créer avec une équipe de développement d'une seule personne dans l'OPC ?Et quand l'Agent échoue, la manière dont Zoe gère cela est beaucoup plus avancée qu'un simple nouvel essai. Elle analysera la raison de l'échec en tenant compte du contexte commercial. Le contexte de l'Agent est-il saturé ? Elle réduira la portée, permettant à l'Agent de se concentrer uniquement sur trois fichiers. L'Agent s'est-il égaré ? Elle le corrigera également, en informant l'Agent que le client veut X et non Y, et en fournissant les mots exacts de la réunion.

Au fil du temps, Zoe accumulera également de l'expérience, se souvenant de quelles structures de prompt fonctionnent bien pour quel type de tâche, afin de rédiger des prompts plus précis la prochaine fois.

Cette idée est en fait une version améliorée de Ralph Loop. La logique centrale de Ralph Loop est un cycle de récupération de contexte, génération de sortie, évaluation des résultats et sauvegarde de l'expérience, mais la plupart des implémentations utilisent un prompt fixe à chaque cycle. Le système d'Elvis est différent, à chaque nouvel essai, Zoe ajustera dynamiquement le prompt en fonction de la raison de l'échec, et cela avec un contexte commercial complet.

Coûts et matériel

En ce qui concerne les coûts, les données publiques d'Elvis indiquent que Claude coûte environ 100 dollars par mois, et Codex environ 90 dollars par mois. Il a également mentionné qu'on peut commencer à tester avec un budget de 20 dollars.

Ce coût est évidemment dérisoire comparé à l'embauche d'un développeur. Mais si l'on considère que vous devez également prendre des décisions produit, communiquer avec les clients et faire des revues de code, cela ressemble davantage à un amplificateur d'efficacité, vous aidant à éviter les tâches répétitives de codage et de test.

En ce qui concerne le matériel, Elvis a mentionné que son plus grand goulot d'étranglement est la RAM. Chaque Agent nécessite un worktree indépendant, chaque worktree a ses propres node_modules, et chaque Agent doit exécuter des constructions, des vérifications de type et des tests. Avoir 5 Agents en cours d'exécution signifie 5 compilateurs TypeScript parallèles, 5 exécuteurs de tests, et 5 ensembles de dépendances.

Son Mac mini avec 16 Go de RAM peut faire fonctionner au maximum 4 à 5 Agents simultanément, au-delà, il commence à échanger de la mémoire. Il a donc acheté un Mac Studio M4 Max avec 128 Go de RAM (3500 dollars), prévoyant de l'utiliser pour gérer plus de concurrence d'Agents.

Résumé et problèmes réels

Pour être honnête, le système d'Elvis m'a vraiment impressionné. J'ai toujours considéré OpenClaw comme un jouet, et pour augmenter ma productivité, je comptais sur Claude Code de manière indépendante. J'utilisais parfois des worktrees pour le parallélisme, mais pas à un niveau aussi systématique. Après avoir lu ses tweets, je pense que le plafond de la programmation AI a encore été relevé.

Je suis récemment en train de suivre son approche, prêt à utiliser OpenClaw pour créer une équipe de développement entièrement automatisée. Donc, nous publierons bientôt plusieurs articles pratiques sur OpenClaw.

Il y a quelques problèmes réels dont je dois vous avertir.

Le prérequis pour ce système est d'avoir un produit clair, des besoins clients définis et une pipeline CI/CD bien établie. Elvis travaille sur un véritable produit SaaS B2B, avec des clients, des revenus et un environnement de production. Si vous êtes encore en phase de démonstration ou d'apprentissage, le ROI de cette architecture peut ne pas être très rentable.

De plus, les problèmes de sécurité d'OpenClaw doivent également être pris en compte. Selon les informations publiques, plusieurs CVE critiques ont été divulgués, et 341 plugins communautaires malveillants ont été découverts avec des comportements de vol de données. Lors du déploiement d'OpenClaw, l'isolement et le contrôle des permissions doivent être bien gérés. C'est aussi la raison pour laquelle je n'ai pas encore déployé OpenClaw sur ma machine principale.

Un autre point, Elvis a exprimé une évaluation plutôt basse de la révision de code de Claude Code dans ses tweets, mais récemment, Claude Code a lancé la fonctionnalité Agent Teams (collaboration multi-Agent intégrée), et Anthropic travaille également dans cette direction.

Cependant, en laissant de côté ces détails, l'architecture d'Elvis, qui combine une couche d'orchestration et une couche d'exécution, mérite vraiment d'être examinée. Le jeu à somme nulle de la fenêtre de contexte est une contrainte réelle, et utiliser une architecture en couches pour résoudre ce problème, permettant à différentes IA de jouer leur rôle, est une direction que je considère comme correcte.

Les amis intéressés par ce sujet peuvent directement consulter le tweet original d'Elvis, qui est très riche en informations :...