OpenClaw + Claude Code/Codex: Byg en personlig udviklingsagent sværm

Hej alle sammen, jeg er Lu Gong.

For nylig så jeg et tweet på X, som straks fangede min opmærksomhed. En uafhængig udvikler ved navn Elvis sagde, at han nu ikke længere bruger Claude Code og Codex direkte, men i stedet bruger OpenClaw som et orkestreringslag, hvor en AI-orkestrator ved navn Zoe styrer en hel sværm af Claude Code og Codex-agenter.

Dataene fra tweetet var også imponerende, 4,9 millioner visninger, 11.000 likes, 1.800 delinger.

Vi har skrevet Vibe Coding i over fire måneder, og Claude Code har altid været vores primære værktøj. Jeg har tidligere skrevet nogle artikler om multi-agent samarbejde, VSCode multi-agent arkitektur osv.

Men når jeg ser på denne tilgang fra Elvis, kan jeg kun kalde det professionelt. En person, der med et orkestreringssystem har en gennemsnitlig daglig kodeindsendelse på 50 gange, og på den mest intense dag indsendte han 94 gange, samtidig med at han tog 3 kundetelefoner, uden nogensinde at åbne editoren.

Er det ikke som at en person fungerer som et helt udviklingsteam?

I dag vil jeg nedbryde, hvordan han præcist gør det.

OpenClaw er ikke ukendt for alle

Denne lille krebs har været populær siden før det kinesiske nytår. Kort sagt er det et open source AI-agent rammeværk, der på GitHub allerede har over 240.000 stjerner og for nylig officielt overhalede React som det open source projekt med den hurtigste stigning i stjerner i GitHubs historie.

Grundlæggeren Peter Steinberger er en østrigsk udvikler, der tidligere grundlagde PSPDFKit (et B2B firma for PDF-rammer) og i 2021 modtog 100 millioner euro i investering fra Insight Partners. I februar i år annoncerede Peter, at han sluttede sig til OpenAI, og OpenClaw-projektet blev overdraget til en open source fond for drift.

OpenClaws positionering er ikke som en chatbot, men som en AI-agent runtime, der kører på dine lokale enheder. Den har fire kernekomponenter: Gateway (gateway, der forbinder over 50 messaging-platforme), Agent (inference engine), Skills (over 5400 plugins), Memory (hukommelsessystem).

Men Elvis bruger OpenClaw på en særlig måde. Han bruger det direkte som et orkestreringslag, specifikt til at styre kodningsagenterne Claude Code og Codex, og bruger det ikke som en generel assistent.

Denne tilgang er bestemt usædvanlig.

Hvorfor har vi brug for et orkestreringslag?

Elvis nævnte et meget vigtigt punkt i tweetet: Kontextvinduet er et nulsumspil.

Hvis du fylder det med kode, er der ikke plads til forretningskonteksten. Hvis du fylder det med kundehistorik og mødenotater, er der ikke plads til kodebasen. Uanset hvor stærk en enkelt AI er, kan den ikke samtidig rumme to helt forskellige typer information.

Derfor delte han systemet op i to lag.

Det øverste lag er OpenClaws orkestrator Zoe, som har kontrol over al forretningskontekst, herunder kundedata, mødenotater, historiske beslutninger, hvilke løsninger der er blevet prøvet, og hvilke der er fejlet. Disse oplysninger er alle gemt i Elvis' Obsidian-notesystem, som Zoe kan læse direkte.

Det nederste lag er kodningsagenterne Claude Code og Codex, som kun fokuserer på kode og skriver kode. Hver gang en agent starter, skriver Zoe en præcis prompt baseret på forretningskonteksten, der fortæller den, hvad den skal gøre, hvad baggrunden er, og hvad kunden ønsker.

Kort sagt: Orkestratoren er ansvarlig for at forstå kravene, mens kodningsagenterne er ansvarlige for at udføre arbejdet. Hver gør det, de er bedst til.

Denne arkitektur ligner meget det interne system Minions, som Stripe for nylig offentliggjorde. Stripes Minions er også designet med parallelle kodningsagenter og et centralt orkestreringslag, der kan fusionere over 1000 PR'er, der er helt skrevet af AI, hver uge. Elvis sagde, at han ved et tilfælde har bygget en lignende arkitektur, men den kører på hans egen Mac mini.

Virkelige casearbejdsgange

Elvis brugte et virkeligt eksempel i tweetet til at forklare sin komplette arbejdsgang, og jeg vil kort opsummere de centrale trin.Han tog et opkald fra en kunde, der ønskede at genbruge eksisterende konfigurationer internt i teamet. Efter opkaldet talte han med Zoe om dette behov. Da alle mødenotater automatisk synkroniseres til Obsidian, vidste Zoe allerede, hvad kunden havde sagt, så der var ikke behov for, at Elvis skulle forklare yderligere. De fastsatte sammen funktionsomfanget, og den endelige løsning blev at lave et skabelonsystem.

Derefter gjorde Zoe automatisk tre ting: hun genopladede kundens service (hun har administrator API-rettigheder), trak den eksisterende konfiguration fra produktionsdatabasen (kun læserettigheder, kodningsagenten vil aldrig have denne rettighed), og genererede derefter en Codex Agent med en detaljeret prompt, der indeholdt den fulde forretningskontekst.

Hver agent har sit eget uafhængige worktree (isoleret gren) og tmux-session. Startkommandoen ser cirka sådan ud:

# Opret worktree + start 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"Når agenten er startet, er der en tidsplanlagt opgave, der tjekker hver 10. minut. Men den spørger ikke direkte agenten (det ville være for dyrt i tokens), men kører et deterministisk shell-script, der tjekker, om tmux-sessionen stadig er aktiv, om der er oprettet PR, og om CI er bestået.

Hvis CI fejler, genstarter den automatisk agenten, maksimalt 3 gange. Der sendes kun en notifikation, når der er behov for manuel indgriben.

Når agenten har fuldført opgaven, opretter den automatisk en PR. Men blot at oprette en PR er ikke nok; Elvis har defineret et sæt færdighedskriterier: PR oprettet, gren synkroniseret til main (uden merge-konflikter), CI bestået, koden fra de tre AI-modeller er blevet gennemgået, og hvis der er UI-ændringer, skal der også vedlægges et screenshot.

Tre AI-modeller til kodegennemgang

De tre AI-modeller til kodegennemgang ser ud til at være meget stabile. Det er interessant at høre hans vurdering af de tre modeller.

Codex Reviewer, han vurderer højest, siger, at den er meget grundig i sin gennemgang af grænsetilfælde og logiske fejl, med en lav falsk positiv rate.

Gemini Code Assist Reviewer, gratis, han siger, at den er meget nyttig, da den kan opdage sikkerhedsrisici og skalerbarhedsproblemer, som de andre modeller overser, og den kan også give konkrete løsningsforslag.

Claude Code Reviewer, hans ord var "næsten ubrugelig", han sagde, at den er alt for forsigtig, med masser af forslag som "overvej at tilføje...", hvor de fleste tilhører overdesign. Medmindre det er markeret som et kritisk problem, springer han direkte over.

Jeg blev lidt overrasket over denne kommentar. Som en intensiv bruger af Claude Code har jeg også oplevet, at den er for konservativ i kodegennemgang, men at kalde den næsten ubrugelig er stadig lidt for meget. Men dette viser også, at kryds-gennemgang med flere modeller virkelig har værdi, da fordommene fra de forskellige modeller komplementerer hinanden.

Når alle tre gennemgange er bestået, vil Elvis først modtage en Telegram-notifikation. På dette tidspunkt ser han primært på screenshots for at bekræfte, at UI-ændringerne er korrekte; mange PR'er fusionerer han direkte uden at se koden. Han siger, at hans manuelle gennemgang kun tager 5 til 10 minutter.

Zoes Proaktivitet

Zoe er ikke bare en udfører. Mere interessant end selve arbejdsgangen er Zoes proaktivitet.

Elvis siger, at Zoe ikke venter på at få tildelt opgaver; hun søger aktivt efter arbejde. Om morgenen scanner hun Sentry's fejl-log, opdager 4 nye fejl og genererer automatisk 4 agenter til at rette dem. Efter mødet scanner hun mødenotaterne, markerer de 3 funktionalitetsbehov, som kunden nævnte, og starter automatisk 3 Codex-agenter. Om aftenen scanner hun Git-loggen og starter Claude Code for at opdatere changelog og kundedokumentation.

Når Elvis kommer tilbage fra en gåtur, ligger der en besked på Telegram: 7 PR'er er klar, 3 nye funktioner, 4 fejlrettelser. Er det ikke præcis den effekt, jeg altid har ønsket at skabe med OPC som et enmandsudviklingsteam?Når Agent fejler, er Zoes håndtering også meget mere avanceret end blot at prøve igen. Den vil kombinere forretningskonteksten for at analysere årsagen til fejlen. Er Agent konteksten sprunget over? Den vil indsnævre fokus, så Agent kun koncentrerer sig om tre filer. Er Agentens retning skæv? Den vil også rette op, fortælle Agent, at kunden ønsker X og ikke Y, og vedlægge de præcise ord fra mødet.

Over tid vil Zoe også akkumulere erfaring, huske hvilke prompt-strukturer der fungerer godt til hvilke opgaver, og næste gang skrive mere præcise prompts.

Denne tilgang er faktisk en opgradering af Ralph Loop. Ralph Loops kerne-logik er at trække kontekst, generere output, evaluere resultater og gemme erfaringer i en cyklus, men de fleste implementeringer har en fast prompt for hver cyklus. Elvis' system er anderledes; hver gang Zoe prøver igen, justerer den dynamisk prompten baseret på årsagen til fejlen, og der er en komplet forretningskontekst til stede.

Omkostninger og hardware

Med hensyn til omkostningerne er de offentlige data fra Elvis, at Claude koster cirka 100 dollars om måneden, og Codex koster cirka 90 dollars om måneden. Han nævnte også, at man kan starte med 20 dollars for at prøve det af.

Denne omkostning er selvfølgelig latterligt billig sammenlignet med at ansætte en udvikler. Men hvis man overvejer, at man også skal træffe produktbeslutninger, kommunikere med kunder og lave kodegennemgang, fungerer det mere som en effektivitetforstærker, der hjælper med at spare tid på kodning og test, som er de mest repetitive opgaver.

Med hensyn til hardware nævnte Elvis, at hans største flaskehals lige nu er RAM. Hver Agent har brug for et uafhængigt worktree, hver worktree har sine egne node_modules, og hver Agent skal køre bygning, typekontrol og test. At køre 5 Agenter samtidigt betyder 5 parallelle TypeScript-kompilatorer, 5 testkørere og 5 sæt afhængigheder.

Hans Mac mini med 16 GB RAM kan maksimalt køre 4 til 5 Agenter samtidigt; mere end det begynder at bruge swap. Så han købte en Mac Studio M4 Max med 128 GB RAM (3500 dollars) for at kunne håndtere flere Agenter samtidigt.

Sammenfatning og virkelige problemer

Ærligt talt, så har Elvis' system haft en stor indflydelse på mig. Jeg har tidligere betragtet OpenClaw som et legetøj, og når det kom til produktivitet, har jeg været afhængig af den uafhængige Claude Code. Jeg har lejlighedsvis brugt worktree til parallelle opgaver, men det har ikke været på dette systematiske niveau. Efter at have læst hans tweets, føler jeg, at loftet for AI-programmering er blevet hævet endnu en gang.

Jeg arbejder i øjeblikket på at bruge hans tilgang til at skabe et fuldautomatiseret enmands udviklingsteam med OpenClaw. Derfor vil vi snart udgive flere artikler om OpenClaw i vores kanal.

Der er dog et par virkelige problemer, jeg gerne vil advare om.

Forudsætningen for dette system er, at du har et klart produkt, klare kundebehov og en velfungerende CI/CD-pipeline. Elvis arbejder på et rigtigt B2B SaaS-produkt med kunder, indtægter og produktionsmiljø. Hvis du stadig er i demo- eller læringsfasen, kan ROI for denne arkitektur være mindre fordelagtig.

Derudover skal man også være opmærksom på de nuværende sikkerhedsproblemer med OpenClaw. Ifølge offentlige oplysninger er der allerede blevet offentliggjort flere kritiske CVE'er, og der er blevet opdaget 341 ondsindede community-plugins, der udviser datatyveri. Når du implementerer OpenClaw, skal du sørge for at have isolering og adgangskontrol på plads. Dette er også grunden til, at jeg ikke har implementeret OpenClaw på min lokale hovedmaskine.

En anden ting er, at Elvis i sine tweets har en lav vurdering af kodegennemgangen af Claude Code, men for nylig har Claude Code netop lanceret Agent Teams-funktionen (officielt indbygget multi-Agent samarbejde), og Anthropic arbejder også i retning af at forbedre orkestrering.

Men uanset disse detaljer, er Elvis' tilgang til orkestreringslag og udførelseslag bestemt værd at bemærke. Den nul-sum spil af kontekstvinduet er en reel begrænsning, og at bruge en lagdelt arkitektur til at løse dette problem, så forskellige AI'er kan udføre deres opgaver, synes jeg personligt er den rigtige retning.

Venner, der er interesseret i dette emne, kan direkte se Elvis' originale tweet, da informationsdensen er meget høj:...