OpenClaw + Claude Code/Codex: Skapa en personlig utvecklingsagent svärm

Hej alla, jag är Lu Gong.

För en tid sedan såg jag en tweet på X som genast fångade mitt intresse. En oberoende utvecklare vid namn Elvis sa att han nu inte längre använder Claude Code och Codex direkt, utan istället använder OpenClaw som ett orkestreringslager, där en AI-orkestrator vid namn Zoe hanterar en hel svärm av Claude Code och Codex-agenter.

Denna tweet hade också imponerande data, 4,9 miljoner visningar, 11 000 gillningar, 1800 delningar.

Vi har skrivit om Vibe Coding i över fyra månader, och Claude Code har alltid varit vårt huvudverktyg. Jag har tidigare skrivit några artiklar om fleragentssamarbete, VSCode fleragentarkitektur och liknande.

Men när jag såg Elviss sätt att arbeta, kunde jag bara kalla honom en expert. En person, med hjälp av ett orkestreringssystem, gör i genomsnitt 50 kodinlämningar per dag, och en dag gjorde han hela 94 inlämningar, samtidigt som han tog tre kundsamtal utan att ens öppna sin editor.

Är det inte som att en person fungerar som ett helt utvecklingsteam?

Idag kommer jag att bryta ner hur han faktiskt gör detta.

OpenClaw är ingen nyhet för oss

Denna lilla kräfta har varit populär sedan före det kinesiska nyåret. Enkelt uttryckt är det ett öppet AI-agentramverk, som för närvarande har över 240 000 stjärnor på GitHub, och för två dagar sedan överträffade det officiellt React, vilket gör det till det snabbast växande öppna projektet i GitHubs historia.

Grundaren Peter Steinberger är en österrikisk utvecklare som tidigare grundade PSPDFKit (ett B2B-företag för PDF-ramverk) och fick en investering på 100 miljoner euro från Insight Partners 2021. I februari i år meddelade Peter att han gick med i OpenAI, och OpenClaw-projektet överlämnades till en öppen källkodsorganisation för drift.

OpenClaws positionering är inte som en chattbot, utan som en AI-agent-runtime som körs på din lokala enhet. Den har fyra kärnkomponenter: Gateway (gateway, kopplar samman över 50 meddelandeplattformar), Agent (slutledningsmotor), Skills (över 5400 plugins), Memory (minnessystem).

Men Elviss sätt att använda OpenClaw är ganska speciellt. Han använder det direkt som ett orkestreringslager, specifikt för att hantera kodningsagenter som Claude Code och Codex, utan att använda det som en allmän assistent.

Denna idé är verkligen ovanlig.

Varför behöver vi ett orkestreringslager?

Elvis nämnde en mycket viktig punkt i sin tweet: Kontextfönstret är ett nollsummespel.

Om du stoppar in kod finns det ingen plats för affärskontext. Om du stoppar in kundhistorik och mötesanteckningar finns det ingen plats för kodbibliotek. En enskild AI, hur kraftfull den än är, kan inte samtidigt rymma dessa två helt olika typer av information.

Så han delade upp systemet i två lager.

Överlagret är OpenClaws orkestrator Zoe, som har all affärskontext, inklusive kunddata, mötesanteckningar, historiska beslut, vilka lösningar som har testats och vilka som har misslyckats. All denna information finns i Elviss Obsidian-noteringssystem, och Zoe kan läsa den direkt.

Underlaget är kodningsagenter som Claude Code och Codex, som bara ser kod och fokuserar på att skriva kod. När varje agent startar, skriver Zoe en exakt prompt baserat på affärskontexten, som berättar för den vad den ska göra, vad bakgrunden är och vad kunden vill ha.

Enkelt uttryckt: orkestratorn ansvarar för att förstå kraven, kodningsagenterna ansvarar för att utföra arbetet. Var och en gör det de är bäst på.

Denna arkitektur liknar Stripe's interna system Minions som nyligen offentliggjordes. Stripes Minions är också en design med parallella kodningsagenter och ett centralt orkestreringslager, som kan slå samman över 1000 PR:er helt skrivna av AI varje vecka. Elvis sa att han av en slump byggde en liknande arkitektur, bara att den körs på hans egen Mac mini.

Verkligt fall arbetsflöde

Elvis använde ett verkligt exempel i sin tweet för att förklara sitt kompletta arbetsflöde, och jag kommer att sammanfatta de centrala stegen.Han tog ett kundsamtal, kunden ville återanvända befintliga konfigurationer inom teamet. Efter samtalet pratade han med Zoe om detta behov. Eftersom alla mötesanteckningar automatiskt synkroniseras till Obsidian, visste Zoe redan vad kunden hade sagt, så Elvis behövde inte förklara ytterligare. De bestämde tillsammans funktionsomfånget, och den slutliga lösningen var att skapa ett mallsystem.

Sedan gjorde Zoe automatiskt tre saker: laddade kundens konto med upplåsningsservice (hon har administratörs-API-behörighet), hämtade kundens befintliga konfigurationer från produktionsdatabasen (endast läsbehörighet, kodningsagenten kommer aldrig att ha denna behörighet), och genererade sedan en Codex Agent med en detaljerad prompt som innehöll fullständig affärskontext.

Varje agent har sitt eget oberoende worktree (isolerad gren) och tmux-session. Startkommandot ser ungefär ut så här:

# Skapa worktree + starta 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 Efter att agenten har startat finns det en schemalagd uppgift som kontrollerar var 10:e minut. Men den kommer inte att fråga agenten direkt (det skulle förbruka för många tokens), utan kör ett deterministiskt Shell-skript som kontrollerar om tmux-sessionen fortfarande är aktiv, om det har skapats PR, och om CI har godkänts.

Om CI misslyckas, startar agenten om automatiskt, högst 3 gånger. Meddelanden skickas endast när manuell intervention behövs.

Agenten skapar automatiskt en PR efter att ha slutfört uppgiften. Men att bara skapa en PR räcker inte, Elvis definierade en uppsättning fullföljande standarder: PR skapad, gren synkroniserad till main (inga sammanslagningskonflikter), CI godkänd, kodgranskning av tre AI-modeller godkänd, och om det finns UI-ändringar måste skärmdumpar bifogas.

Tre AI-modeller gör kodgranskning

Tre AI-modeller gör kodgranskning ser stabilt ut. Att diskutera hans bedömning av dessa tre modeller är ganska intressant.

Codex Reviewer, han ger den högsta betyg, säger att den är mycket grundlig när det gäller gränsfall och logiska fel, med en låg falsk positiv rate.

Gemini Code Assist Reviewer, gratis, han säger att den är mycket användbar, kan upptäcka säkerhetsrisker och skalbarhetsproblem som andra modeller missar, och kan ge specifika lösningar.

Claude Code Reviewer, hans exakta ord var "praktiskt taget oanvändbar", han säger att den är överdrivet försiktig, med massor av förslag som "överväg att lägga till...", de flesta är överdesignade. Om det inte är markerat som ett kritiskt problem hoppar han över det direkt.

Jag blev lite överraskad när jag läste detta. Som en tung användare av Claude Code har jag också stött på situationer där den är för konservativ vid kodgranskning, men att den är "praktiskt taget oanvändbar" känns lite överdrivet. Men detta visar också att korsgranskning med flera modeller verkligen har värde, eftersom olika modellers fördomar kompletterar varandra.

Efter att alla tre granskningar har godkänts får Elvis en Telegram-notis. Vid detta steg tittar han huvudsakligen på skärmdumpar för att bekräfta om UI-ändringarna är korrekta, många PR:er går han inte igenom koden för utan slår bara ihop dem direkt. Han säger att hans manuella granskning bara tar 5 till 10 minuter.

Zoes Proaktivitet

Zoe är inte bara en utförare. Mer intressant än arbetsflödet i sig är Zoes proaktivitet.

Elvis säger att Zoe inte väntar på att få uppgifter tilldelade, utan hon söker aktivt efter arbete. På morgonen skannar hon Sentrys fel-loggar, upptäcker 4 nya fel, och genererar automatiskt 4 agenter för att åtgärda dem. Efter mötet skannar hon mötesanteckningarna, markerar 3 funktioner som kunden nämnde, och startar automatiskt 3 Codex-agenter. På kvällen skannar hon Git-loggarna, startar Claude Code för att uppdatera changelog och kunddokument.

När Elvis går ut för en promenad och kommer tillbaka, ligger det ett meddelande på Telegram: 7 PR:er är klara, 3 nya funktioner, 4 buggfixar. Är inte detta precis den effekt jag alltid har velat skapa med OPC, ett enmansutvecklingsteam?Och när Agenten misslyckas, är Zoes hantering mycket mer avancerad än en enkel omprövning. Den kombinerar affärssammanhang för att analysera orsaken till misslyckandet. Har Agentens kontext kraschat? Den kommer att begränsa området så att Agenten bara fokuserar på tre filer. Har Agentens riktning avvikit? Den kommer också att korrigera och berätta för Agenten att kunden vill ha X, inte Y, och bifoga de exakta orden från mötet.

Med tiden kommer Zoe också att samla erfarenhet och komma ihåg vilka promptstrukturer som fungerar bra för vilka typer av uppgifter, så nästa gång kan den skriva mer precisa prompts.

Denna idé är egentligen en uppgradering av Ralph Loop. Kärnlogiken i Ralph Loop är att hämta kontext, generera utdata, utvärdera resultat och spara erfarenhet i en cykel, men de flesta implementationer har en fast prompt för varje cykel. Elvis system är annorlunda; varje gång Zoe omprövar justerar den dynamiskt prompten baserat på orsaken till misslyckandet, och har dessutom en komplett affärskontext.

Kostnader och hårdvara

När det gäller kostnader, är de offentliga uppgifterna från Elvis att Claude kostar cirka 100 dollar per månad, Codex kostar cirka 90 dollar per månad. Han nämnde också att man kan börja med 20 dollar för att prova på.

Denna kostnad är självklart löjligt billig jämfört med att anställa en utvecklare. Men om man tänker på att man också behöver fatta produktbeslut, kommunicera med kunder och granska kod, fungerar det mer som en effektivitetsskapare som hjälper till att spara tid på de mest repetitiva delarna av kodning och testning.

När det gäller hårdvara nämnde Elvis att hans största flaskhals just nu är RAM. Varje Agent behöver en oberoende worktree, varje worktree har sina egna node_modules, och varje Agent måste köra bygg, typkontroll och tester. Att köra 5 Agenter samtidigt innebär 5 parallella TypeScript-kompilatorer, 5 testkörningar och 5 uppsättningar beroenden.

Hans Mac mini med 16 GB RAM kan maximalt köra 4 till 5 Agenter samtidigt, annars börjar den använda swap-minne. Så han köpte en Mac Studio M4 Max med 128 GB RAM (3500 dollar) för att kunna hantera fler Agenter parallellt.

Sammanfattning och verkliga problem

Ärligt talat, Elvis system har verkligen imponerat på mig. Jag har tidigare alltid sett OpenClaw som en leksak, och när det kommer till produktivitet har jag förlitat mig på den oberoende Claude Code. Jag har ibland använt worktree för parallellisering, men långt ifrån denna systematiska arrangemang. Efter att ha läst hans tweet känner jag att taket för AI-programmering har höjts ytterligare.

Jag planerar nu att använda hans idéer för att skapa ett helt automatiserat enmansutvecklingsteam med OpenClaw. Så inom kort kommer vi att publicera flera artiklar om praktisk användning av OpenClaw.

Det finns några verkliga problem som jag måste påpeka.

Detta system förutsätter att du har en tydlig produkt, klara kundbehov och en väl fungerande CI/CD-pipeline. Elvis arbetar med en verklig B2B SaaS-produkt, med kunder, intäkter och produktionsmiljö. Om du fortfarande skriver demo eller är i lärande fas, kan ROI för denna arkitektur vara mindre fördelaktig.

Dessutom måste man vara medveten om säkerhetsproblem med OpenClaw. Enligt offentliga uppgifter har flera högprioriterade CVE:er avslöjats, och 341 skadliga community-plugins har upptäckts med datastöldbeteende. När man distribuerar OpenClaw måste isolering och behörighetskontroll göras ordentligt. Detta är också anledningen till att jag inte har distribuerat OpenClaw på min lokala huvudmaskin.

En annan punkt är att Elvis i sin tweet gav en låg bedömning av kodgranskningen av Claude Code, men nyligen har Claude Code just lanserat Agent Teams-funktionen (inbyggd samarbete mellan flera Agenter), och Anthropic arbetar också i den riktningen.

Men bortsett från dessa detaljer är Elvis arkitektur med en arrangemangsnivå och en exekveringsnivå verkligen värt att uppmärksamma. Den nollsumma spel av kontextfönstret är en verklig begränsning, och att använda en lagerarkitektur för att lösa detta problem, så att olika AI kan specialisera sig, tycker jag personligen är rätt väg att gå.

För vänner som är intresserade av detta ämne, kan ni direkt kolla in Elvis ursprungliga tweet, informationsdensiteten är mycket hög:...