OpenClaw + Claude Code/Codex: Bygge et personlig utviklingsagent-sverm

Hei alle sammen, jeg er Lu Gong.

For en tid tilbake så jeg en tweet på X som umiddelbart fanget interessen min. En uavhengig utvikler ved navn Elvis sa at han nå ikke lenger bruker Claude Code og Codex direkte, men har byttet til OpenClaw som et orkestreringslag, og lar en AI-orchestrator kalt Zoe administrere en hel sverm av Claude Code og Codex-agenter.

Dataene fra denne tweeten er også imponerende, med 4,9 millioner visninger, 11 000 likerklikk og 1800 delinger.

Vi har skrevet om Vibe Coding i over fire måneder, og Claude Code har alltid vært vårt hovedverktøy. Jeg har tidligere skrevet noen artikler om samarbeid mellom flere agenter, VSCode multi-agent-arkitektur og lignende emner.

Men når jeg så hvordan Elvis bruker dette systemet, måtte jeg bare si meg enig i at han er en ekspert. En person, med et orkestreringssystem, har i gjennomsnitt 50 kodeinnleveringer per dag, og på den mest hektiske dagen leverte han 94 ganger, samtidig som han tok tre kundesamtaler uten å åpne redigeringsprogrammet en eneste gang.

Er ikke dette som å ha en hel utviklingsteam i én person?

I dag vil jeg bryte ned hvordan han faktisk klarte dette.

OpenClaw er ikke ukjent for alle

Denne lille krepsen har vært populær siden før nyttår. Kort sagt er det et åpen kildekode AI-agentrammeverk, som nå har over 240 000 stjerner på GitHub, og for to dager siden overgikk det offisielt React, og ble det raskest voksende open source-prosjektet i GitHubs historie.

Grunnleggeren Peter Steinberger er en utvikler fra Østerrike, som tidligere har grunnlagt PSPDFKit (et B2B-selskap for PDF-rammeverk), og i 2021 mottok han en investering på 100 millioner euro fra Insight Partners. I februar i år kunngjorde Peter at han ble med i OpenAI, og OpenClaw-prosjektet ble overført til en open source-stiftelse for drift.

OpenClaws posisjon er ikke som en chatbot, men som et AI-agent-runtime som kjører på din lokale enhet. Den har fire kjernekomponenter: Gateway (gateway, kobler til over 50 meldingsplattformer), Agent (resonneringsmotor), Skills (over 5400 plugins), Memory (minnesystem).

Men Elvis bruker OpenClaw på en spesiell måte. Han bruker det direkte som et orkestreringslag, spesifikt for å administrere kodeagenter som Claude Code og Codex, og bruker det ikke som en generell assistent.

Denne tankegangen er virkelig uvanlig.

Hvorfor trenger vi et orkestreringslag?

Elvis nevnte et veldig viktig poeng i tweeten: Kontekstvinduet er et nullsumspill.

Hvis du fyller det med kode, er det ikke plass til forretningskonteksten. Hvis du fyller det med kundehistorikk og møtereferater, er det ikke plass til kodebasen. Uansett hvor kraftig en enkelt AI er, kan den ikke samtidig håndtere to helt forskjellige typer informasjon.

Derfor delte han systemet opp i to lag.

Det øverste laget er OpenClaws orkestrator Zoe, som har kontroll over all forretningskontekst, inkludert kundedata, møtereferater, historiske beslutninger, hvilke løsninger som har blitt prøvd, og hvilke som har feilet. All denne informasjonen er lagret i Elvis' Obsidian-notatbibliotek, og Zoe kan lese det direkte.

Det nedre laget er kodeagenter som Claude Code og Codex, som kun ser på kode og kun skriver kode. Hver gang en agent starter, vil Zoe skrive en presis prompt basert på forretningskonteksten, og fortelle den hva den skal gjøre, hva bakgrunnen er, og hva kunden ønsker.

Kort sagt: Orkestratoren er ansvarlig for å forstå behovene, mens kodeagentene er ansvarlige for å utføre arbeidet. Hver gjør det de er best på.

Denne arkitekturen ligner på Stripes interne system Minions som ble offentliggjort for en tid tilbake. Stripes Minions er også designet med parallelle kodeagenter og et sentralisert orkestreringslag, og kan slå sammen over 1000 PR-er som er helt skrevet av AI hver uke. Elvis sa at han tilfeldig bygde en lignende arkitektur, bare at den kjører på hans egen Mac mini.

Virkelig case arbeidsflyt

Elvis brukte et ekte case i tweeten for å forklare sin komplette arbeidsflyt, og jeg vil kort oppsummere de viktigste trinnene.Han tok en kundetelefon, kunden ønsket å gjenbruke eksisterende konfigurasjoner internt i teamet. Etter samtalen snakket han med Zoe om dette behovet. Siden alle møtereferater automatisk synkroniseres til Obsidian, visste Zoe allerede hva kunden hadde sagt, så Elvis trengte ikke å forklare noe ekstra. De ble enige om funksjonsomfanget, og den endelige løsningen var å lage et mal-system.

Deretter gjorde Zoe automatisk tre ting: hun ladet opp kundens tjeneste for opplåsning (hun har administrator-API-rettigheter), hentet kundens eksisterende konfigurasjon fra produksjonsdatabasen (kun lesetilgang, koding Agent vil aldri ha denne retten), og genererte deretter en Codex Agent, med en detaljert prompt som inneholdt full forretningskontekst.

Hver Agent har sitt eget uavhengige worktree (isolerte grener) og tmux-økt. Startkommandoen ser omtrent slik ut:

# Opprett 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 Etter at Agenten er startet, har den en tidsplanlagt oppgave som sjekker hvert 10. minutt. Men den spør ikke Agenten direkte (det ville vært for kostbart med tokens), men kjører et deterministisk Shell-skript som sjekker om tmux-økten fortsatt er aktiv, om det er opprettet PR, og om CI har bestått.

Hvis CI feiler, restarter Agenten automatisk, med maksimalt 3 forsøk. Varsler sendes kun når det er behov for manuell inngripen.

Agenten oppretter automatisk PR etter å ha fullført oppgaven. Men det å bare opprette PR er ikke nok; Elvis har definert en sett med fullføringsstandarder: PR opprettet, gren synkronisert til main (uten sammenslåingskonflikter), CI bestått, koden fra de tre AI-modellene har bestått gjennomgang, og hvis det er UI-endringer, må det også vedlegges skjermbilder.

Tre AI-modeller for kodegjennomgang

Tre AI-modeller for kodegjennomgang ser ut til å være veldig stabile. Det er interessant å høre hans vurdering av disse tre modellene.

Codex Reviewer, han gir den høyest vurdering, og sier at den er veldig grundig i vurderingen av grense tilfeller og logiske feil, med lav falsk positiv rate.

Gemini Code Assist Reviewer, gratis, han sier den er veldig nyttig, kan oppdage sikkerhetsrisikoer og skalerbarhetsproblemer som de andre modellene har oversett, og kan også gi konkrete løsningsforslag.

Claude Code Reviewer, hans ord var "praktisk talt ubrukelig", han sa den er overdrevent forsiktig, med mange forslag som "vurder å legge til...", som ofte er overdesign. Med mindre det er merket som et kritisk problem, hopper han bare over det.

Jeg ble litt overrasket over dette. Som en tung bruker av Claude Code har jeg også opplevd at den er for konservativ under kodegjennomgang, men å si at den er praktisk talt ubrukelig er kanskje å ta det for langt. Men dette viser også at kryssgjennomgang med flere modeller faktisk har verdi, da fordommene i de forskjellige modellene komplementerer hverandre.

Når alle tre vurderingene er bestått, vil Elvis motta en Telegram-varsling. På dette punktet ser han hovedsakelig på skjermbilder for å bekrefte at UI-endringene er riktige; mange PR-er blir han med en gang slått sammen uten å se på koden. Han sier at hans manuelle gjennomgang bare tar 5 til 10 minutter.

Zoes initiativ

Zoe er ikke bare en utfører. Det som er mer interessant enn arbeidsflyten i seg selv, er Zoes initiativ.

Elvis sier at Zoe ikke venter på at den skal bli tildelt oppgaver; den oppsøker aktivt arbeid. Om morgenen skanner den Sentrys feillogger, oppdager 4 nye feil, og genererer automatisk 4 Agenter for å fikse dem. Etter møtet skanner den møtereferatene, markerer de 3 funksjonsbehovene kunden nevnte, og starter deretter automatisk 3 Codex Agenter. Om kvelden skanner den Git-loggene, og starter Claude Code for å oppdatere changelog og kundedokumentasjon.

Når Elvis går ut for en tur og kommer tilbake, ligger det en melding på Telegram: 7 PR-er er klare, 3 nye funksjoner, 4 feilrettinger. Dette er ikke akkurat det jeg alltid har ønsket å skape: en enmanns utviklingsteam-effekt med OPC.Og når Agenten feiler, er måten Zoe håndterer det på mye mer avansert enn en enkel omstart. Den vil analysere årsaken til feilen i sammenheng med forretningskonteksten. Ble Agentens kontekst overbelastet? Den vil snevre inn fokuset, slik at Agenten kun konsentrerer seg om tre filer. Har Agenten mistet retningen? Den vil også korrigere, fortelle Agenten at kunden ønsker X, ikke Y, og legge ved de eksakte ordene fra møtet.

Etter hvert som tiden går, vil Zoe også samle erfaring, huske hvilke prompt-strukturer som fungerer godt for hvilke oppgaver, og skrive mer presise prompt neste gang.

Denne tankegangen er faktisk en oppgradering av Ralph Loop. Kjernen i Ralph Loop er en syklus av å hente kontekst, generere output, evaluere resultater og lagre erfaring, men de fleste implementeringer har en fast prompt for hver syklus. Elvis' system er annerledes; hver gang Zoe prøver på nytt, justerer den prompten dynamisk basert på årsaken til feilen, og har full forretningskontekst som støtte.

Kostnader og maskinvare

Når det gjelder kostnader, er de offentlige dataene fra Elvis at Claude koster omtrent 100 dollar per måned, og Codex koster omtrent 90 dollar per måned. Han nevnte også at man kan begynne med 20 dollar for å teste vannet.

Denne kostnaden er selvfølgelig latterlig billig sammenlignet med å ansette en utvikler. Men hvis man tar med i betraktning at man også må ta produktbeslutninger, kommunisere med kunder og gjennomføre kodegjennomganger, fungerer det mer som en effektivitetforsterker, som hjelper deg med å spare tid på koding og testing, som er de mest repetitive oppgavene.

Når det gjelder maskinvare, nevnte Elvis at hans største flaskehals for øyeblikket er RAM. Hver Agent trenger et eget arbeidsområde, hver arbeidsområde har sine egne nodemodules, og hver Agent må kjøre bygging, typekontroll og testing. Å kjøre 5 Agenter samtidig betyr 5 parallelle TypeScript-kompilatorer, 5 testkjørere og 5 sett med avhengigheter.

Hans Mac mini med 16 GB RAM kan maksimalt kjøre 4 til 5 Agenter samtidig; mer enn det begynner å bytte minne. Så han kjøpte en Mac Studio M4 Max med 128 GB RAM (3500 dollar), med planer om å bruke den til å håndtere flere samtidige Agenter.

Oppsummering og virkelige problemer

Ærlig talt, Elvis' system har gjort et stort inntrykk på meg. Jeg har tidligere sett på OpenClaw som et leketøy, og når det gjelder produktivitet, har jeg vært avhengig av den uavhengige Claude Code. Jeg har av og til brukt arbeidsområder for parallell behandling, men det har ikke vært på dette systematiske nivået. Etter å ha lest tweetene hans, føler jeg at taket for AI-programmering har blitt hevet enda et hakk.

Jeg jobber nå med å bruke hans tankegang for å bygge et helt automatisert en-person utviklingsteam med OpenClaw. Så i nær fremtid vil vi publisere flere artikler om praksisen med OpenClaw.

Det er noen virkelige problemer jeg må advare alle om.

Forutsetningen for dette systemet er at du må ha et klart produkt, tydelige kundebehov og et godt CI/CD-pipeline. Elvis jobber med et ekte B2B SaaS-produkt, med kunder, inntekter og produksjonsmiljø. Hvis du fortsatt er i demo- eller læringsfasen, kan ROI for denne arkitekturen være lite lønnsom.

I tillegg må man også være oppmerksom på sikkerhetsproblemer med OpenClaw. Ifølge offentlig informasjon har flere høyrisiko CVE-er blitt avslørt, og 341 ondsinnede fellesskapsplugins er oppdaget med datatyveri. Når du distribuerer OpenClaw, må isolasjon og tilgangskontroll være på plass. Dette er også grunnen til at jeg ikke har distribuert OpenClaw på min lokale hovedmaskin.

En annen ting, Elvis har en lav vurdering av kodegjennomgangene i Claude Code i tweetene sine, men nylig har Claude Code nettopp lansert Agent Teams-funksjonen (offisiell innebygd samarbeid med flere Agenter), og Anthropic jobber også mot å forbedre dette.

Men bortsett fra disse detaljene, er Elvis' tankegang om en arkitektur med en orkestreringslag og et utførelseslag absolutt verdt å merke seg. Nullsumspillet i kontekstvinduet er en reell begrensning, og å bruke en lagdelt arkitektur for å løse dette problemet, slik at forskjellige AI-er kan spesialisere seg, er en retning jeg personlig mener er riktig.

Venner som er interessert i dette emnet, kan gå direkte til Elvis' originale tweet, informasjonstettheten er veldig høy:[[HTMLPLACEHOLDER0]][[HTMLPLACEHOLDER1]][[HTMLPLACEHOLDER2]][[HTMLPLACEHOLDER3]][[HTMLPLACEHOLDER4]][[HTMLPLACEHOLDER_5]]