OpenClaw + Claude Code/Codex: Creant un Agent Swarm de Desenvolupament Personal

Hola a tots, sóc el Lu Gong.

Fa un temps vaig veure un tuit a X que em va cridar l'atenció de seguida. Un desenvolupador independent anomenat Elvis deia que ara ja no utilitzava directament Claude Code i Codex, sinó que utilitzava OpenClaw com a capa d'orquestració, deixant que una IA anomenada Zoe gestionés tot un Agent Swarm de Claude Code i Codex.

Les dades d'aquest tuit també són impressionants, amb 4,9 milions de visualitzacions, 11.000 m'agrada i 1.800 retuits.

Hem estat escrivint Vibe Coding durant més de quatre mesos, i Claude Code ha estat la nostra eina principal. Abans també havia escrit alguns articles sobre la col·laboració entre múltiples agents, arquitectures de múltiples agents a VSCode, etc.

Però en veure el mètode d'Elvis, només puc dir que és un expert. Una sola persona, amb un sistema d'orquestració, fa una mitjana de 50 enviaments de codi al dia, i en el dia més intens va enviar 94 vegades, mentre atenia 3 trucades de clients, sense obrir mai l'editor.

Això no és com si una sola persona fos un equip de desenvolupament?

Avui, aquest article analitzarà com ho va aconseguir.

OpenClaw no és desconegut per a ningú

Aquest petit cangrejo de riu ha estat molt popular des de abans del Nou Any. En poques paraules, és un marc d'Agent AI de codi obert, que actualment té més de 240.000 estrelles a GitHub, i fa uns dies va superar oficialment React, convertint-se en el projecte de codi obert amb el creixement d'estrelles més ràpid en la història de GitHub.

El fundador Peter Steinberger és un desenvolupador austríac, que anteriorment va fundar PSPDFKit (una empresa B2B d'un marc PDF), i el 2021 va rebre una inversió de 100 milions d'euros d'Insight Partners. Al febrer d'aquest any, Peter va anunciar que s'unia a OpenAI, i el projecte OpenClaw es va traslladar a una fundació de codi obert per a la seva gestió.

La posició d'OpenClaw no és la d'un chatbot, sinó un temps d'execució d'Agent AI que funciona en el teu dispositiu local. Té quatre components principals: Gateway (port, que connecta més de 50 plataformes de missatgeria), Agent (motor d'inferència), Skills (més de 5400 complements) i Memory (sistema de memòria).

Però la manera com Elvis utilitza OpenClaw és força especial. Ell l'utilitza com a capa d'orquestració, específicament per gestionar agents de codificació com Claude Code i Codex, sense utilitzar-lo com a assistent general.

Aquesta idea és realment inusual.

Per què necessitem una capa d'orquestració?

Elvis va mencionar un punt clau en el tuit: la finestra de context és un joc de suma zero.

Si hi poses codi, no hi ha espai per a contextos de negoci. Si hi poses historial de clients i registres de reunions, no hi ha espai per a la base de codi. Un AI individual, per molt potent que sigui, no pot gestionar simultàniament aquests dos tipus d'informació completament diferents.

Per això, va dividir el sistema en dues capes.

La capa superior és l'orquestrador OpenClaw, Zoe, que controla tot el context de negoci, incloent dades de clients, registres de reunions, decisions històriques, quines solucions s'han provat i quines han fallat. Aquesta informació es troba tota a la base de notes Obsidian d'Elvis, i Zoe pot llegir-la directament.

La capa inferior són els agents de codificació com Claude Code i Codex, que només veuen codi i només escriuen codi. Cada vegada que s'inicia un agent, Zoe li escriu un prompt precís basat en el context de negoci, indicant-li què ha de fer, quin és el context i què vol el client.

En poques paraules: l'orquestrador s'encarrega d'entendre les necessitats, i els agents de codificació s'encarreguen de fer la feina. Cada un fa el que millor sap fer.

Aquesta arquitectura és similar al sistema intern Minions que Stripe va fer públic fa un temps. Els Minions de Stripe també són un disseny d'agents de codificació paral·lels amb una capa d'orquestració centralitzada, que pot fusionar més de 1000 PR completament escrits per AI cada setmana. Elvis diu que va construir accidentalment una arquitectura similar, només que funciona en el seu Mac mini.

Flux de treball de casos reals

Elvis va utilitzar un cas real en el tuit per explicar el seu flux de treball complet, i jo resumiré els passos clau.Va atendre una trucada d'un client, que volia reutilitzar la configuració existent dins de l'equip. Després de la trucada, va parlar amb Zoe sobre aquesta necessitat. Com que tots els registres de les reunions es sincronitzen automàticament amb Obsidian, Zoe ja sabia què havia dit el client, així que no calia que Elvis ho expliqués de nou. Junts van determinar l'abast de la funcionalitat, i la solució final va ser crear un sistema de plantilles.

A continuació, Zoe va fer automàticament tres coses: va recarregar el servei de desbloqueig per al client (ella té permisos d'API d'administrador), va extreure la configuració existent del client de la base de dades de producció (permissos de només lectura, l'Agent de codificació mai tindrà aquest permís), i després va generar un Agent Codex, amb un prompt detallat que incloïa el context empresarial complet.

Cada Agent té el seu propi worktree independent (branques aïllades) i sessió tmux. La comanda d'inici és aproximadament així:

# Crear worktree + iniciar 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"Després que l'Agent s'iniciï, hi ha una tasca programada que revisa cada 10 minuts. Però no preguntarà directament a l'Agent (ja que això consumiria massa tokens), sinó que executarà un script Shell determinista, per comprovar si la sessió tmux encara està viva, si s'ha creat un PR, i si el CI ha passat.

Si el CI falla, reinicia automàticament l'Agent, amb un màxim de 3 reintents. Només s'envia una notificació quan es necessita intervenció manual.

Després que l'Agent completi la tasca, crearà automàticament un PR. Però només crear un PR no és suficient, Elvis ha definit un conjunt d'estàndards de completitud: creació de PR, sincronització de la branca amb main (sense conflictes de fusió), CI completament aprovat, revisió de codi de tres models d'IA completament aprovada, i si hi ha canvis d'UI, també s'han d'adjuntar captures de pantalla.

Tres models d'IA fan revisió de codi

Tres models d'IA fent revisió de codi semblen molt fiables. Parlem una mica sobre la seva valoració d'aquests tres models, que és força interessant.

Codex Reviewer, el valora més alt, diu que la seva revisió és molt exhaustiva en casos límit i errors lògics, amb una taxa de falsos positius molt baixa.

Gemini Code Assist Reviewer, gratuït, diu que és molt útil, pot detectar vulnerabilitats de seguretat i problemes d'escalabilitat que altres models poden passar per alt, i pot oferir solucions de reparació concretes.

Claude Code Reviewer, les seves paraules exactes són "bàsicament inútil", diu que és massa cautelós, amb un munt de suggeriments com "considera afegir...", la majoria dels quals són sobre disseny excessiu. Excepte si es marca com a problema crític, ell simplement ho salta.

Quan vaig llegir això em vaig sorprendre una mica. Com a usuari intensiu de Claude Code, també he trobat que és massa conservador durant la revisió de codi, però dir que és bàsicament inútil és una mica exagerat. Tanmateix, això també indica que la revisió creuada entre múltiples models té un valor real, ja que els prejudicis dels diferents models es complementen entre si.

Només després que les tres revisions siguin aprovades, Elvis rep la notificació per Telegram. En aquest punt, el que mira principalment són les captures de pantalla, per confirmar si els canvis d'UI són correctes, i molts PR els fusiona directament sense mirar el codi. Ell diu que la seva revisió manual només necessita de 5 a 10 minuts.

La iniciativa de Zoe

Zoe no és només una executora. Més enllà del flux de treball en si, el més interessant és la iniciativa de Zoe.

Elvis diu que Zoe no espera a que se li assignin tasques, sinó que busca activament feina. Al matí escaneja els registres d'errors de Sentry, descobreix 4 nous errors, i genera automàticament 4 Agents per solucionar-los. Després de la reunió, escaneja els registres de la reunió, marca 3 necessitats funcionals mencionades pel client, i llavors inicia automàticament 3 Agents Codex. Al vespre escaneja els registres de Git, inicia Claude Code per actualitzar el changelog i la documentació del client.

Quan Elvis surt a fer una volta i torna, té un missatge a Telegram: 7 PR preparats, 3 noves funcionalitats, 4 correccions de bugs. Això no és exactament l'efecte que sempre he esperat crear amb l'equip de desenvolupament d'una empresa unipersonal OPC?I quan l'Agent falla, la manera de gestionar-ho de Zoe és molt més avançada que un simple reintentar. Ella analitza la causa de la fallada combinant el context empresarial. El context de l'Agent s'ha trencat? Ella reduirà l'abast, fent que l'Agent només es concentri en tres fitxers. L'Agent s'ha desviat del seu camí? Ella també ho corregirà, dient a l'Agent que el client vol X i no Y, i adjuntant les paraules exactes de la reunió.

Amb el temps, Zoe també acumularà experiència, recordant quines estructures de prompt funcionen millor per a quins tipus de tasques, i escriurà prompts més precisos la propera vegada.

Aquesta idea és, de fet, una versió millorada del Ralph Loop. La lògica central del Ralph Loop és un cicle que implica extreure context, generar sortides, avaluar resultats i guardar experiències, però la majoria de les implementacions utilitzen un prompt fix per a cada cicle. El sistema d'Elvis és diferent; cada vegada que reintenta, Zoe ajusta dinàmicament el prompt segons la causa de la fallada, i té un context empresarial complet que l'acompanya.

Costos i maquinari

Pel que fa als costos, les dades públiques d'Elvis indiquen que Claude costa aproximadament 100 dòlars al mes, i Codex uns 90 dòlars al mes. També va dir que es pot començar a provar amb 20 dòlars.

Aquest cost és, sens dubte, molt més barat que contractar un desenvolupador. Però si considerem que també necessites prendre decisions sobre el producte, comunicar-te amb els clients i revisar codi, es converteix més en un amplificador d'eficiència, ajudant-te a estalviar en la codificació i les proves, que són les parts més repetitives.

Pel que fa al maquinari, Elvis va mencionar que el seu principal coll d'ampolla actual és la RAM. Cada Agent necessita un worktree independent, cada worktree té els seus propis node_modules, i cada Agent ha de fer construccions, comprovacions de tipus i proves. Cinc Agents funcionant simultàniament significa cinc compiladors de TypeScript en paral·lel, cinc executors de proves i cinc conjunts de dependències.

El seu Mac mini amb 16GB de RAM pot executar al màxim de 4 a 5 Agents alhora; si n'hi ha més, comença a haver-hi intercanvi de memòria. Per això, va comprar un Mac Studio M4 Max amb 128GB de RAM (3500 dòlars), amb la intenció de suportar més Agents en concurrència.

Resum i problemes reals

Honestament, el sistema d'Elvis m'ha impactat força. Abans, sempre havia considerat OpenClaw com un joguina, i en termes de productivitat, depenia de Claude Code de manera independent. De tant en tant utilitzava worktree per fer paral·lelisme, però lluny d'arribar a aquest nivell de sistematització. Després de llegir els seus tuits, crec que el sostre de la programació amb IA s'ha elevat un altre cop.

Recentment, estic seguint la seva idea, preparant-me per crear un equip de desenvolupament totalment automatitzat amb OpenClaw. Per tant, en breu publicarem diversos articles pràctics sobre OpenClaw.

Hi ha alguns problemes reals que cal recordar.

El pressupost d'aquest sistema requereix que tinguis un producte clar, necessitats de clients definides i una línia de CI/CD ben establerta. Elvis està treballant en un producte B2B SaaS real, amb clients, ingressos i un entorn de producció. Si encara estàs escrivint demos o en fase d'aprenentatge, el ROI d'aquesta arquitectura pot no ser massa rendible.

A més, actualment cal tenir en compte els problemes de seguretat d'OpenClaw. Segons la informació pública, ja s'han revelat diversos CVE de gran perill, i s'han trobat 341 plugins maliciosos de la comunitat amb comportaments de robatori de dades. Quan despleguis OpenClaw, és essencial fer un bon aïllament i control de permisos. Aquesta és també la raó per la qual no he desplegat OpenClaw al meu ordinador principal.

Una altra cosa, Elvis va fer una valoració baixa de la revisió de codi de Claude Code en els seus tuits, però recentment Claude Code acaba de llançar la funció Agent Teams (col·laboració de múltiples Agents integrada oficialment), i Anthropic també està treballant en aquesta direcció.

Però deixant de banda aquests detalls, l'arquitectura d'Elvis que combina capa d'orquestració i capa d'execució és realment digna d'atenció. El joc de suma zero de la finestra de context és una restricció real, i utilitzar una arquitectura en capes per resoldre aquest problema, permetent que diferents IA compleixin les seves funcions, és un enfocament que considero correcte.

Si estàs interessat en aquest tema, pots veure directament el tuit original d'Elvis, la densitat d'informació és molt alta:...