OpenClaw + Claude Code/Codex: Személyre szabott fejlesztői Agent Swarm létrehozása

Üdvözlöm mindenkit, én Lu Gong vagyok.

Nemrég egy tweetet láttam az X-en, ami azonnal felkeltette az érdeklődésemet. Egy Elvis nevű független fejlesztő azt mondta, hogy már nem közvetlenül a Claude Code-ot és Codexet használja, hanem az OpenClaw-t használja mint orchestrációs réteget, hogy egy Zoe nevű AI orchestrátor kezelje az egész Claude Code és Codex Agent Swarm-ot.

Ez a tweet adatai is lenyűgözőek, 4,9 millió megtekintés, 11 ezer lájk, 1800 megosztás.

Mi már több mint négy hónapja írunk a Vibe Codingról, a Claude Code mindig is a fő eszközünk volt. Korábban írtam már néhány cikket a több Agent együttműködésről, VSCode több Agent architektúrákról stb.

De amikor megláttam Elvis módszerét, csak annyit tudtam mondani, hogy ez igazán profi. Egy ember, egy orchestrációs rendszer segítségével, napi átlag 50 kódbejegyzés, a legjobb napján 94 bejegyzést tett közzé, és még 3 ügyfélhívást is fogadott, anélkül, hogy egyszer is megnyitotta volna a szerkesztőt.

Ez nem egy ember, aki egy fejlesztőcsapatot helyettesít?

Ma ebben a cikkben elemezzük, hogyan is csinálta ezt.

Az OpenClaw nem ismeretlen senkinek

Ez a kis rák a tavaszi ünnepek óta folyamatosan népszerű. Egyszerűen fogalmazva, ez egy nyílt forráskódú AI Agent keretrendszer, a GitHub-on már több mint 240 ezer csillagot kapott, és az elmúlt napokban hivatalosan is megelőzte a React-ot, így a GitHub történetének leggyorsabban növekvő nyílt forráskódú projektjévé vált.

A megalapító Peter Steinberger osztrák fejlesztő, korábban alapított egy B2B céget, a PSPDFKit-et (PDF keretrendszer). 2021-ben 100 millió eurós befektetést kapott az Insight Partners-től. Idén februárban Peter bejelentette, hogy csatlakozik az OpenAI-hoz, az OpenClaw projektet pedig átadta egy nyílt forráskódú alapítványnak.

Az OpenClaw nem egy chatbot, hanem egy AI Agent futtatási környezet, amely a helyi eszközödön fut. Négy alapvető összetevője van: Gateway (kapu, több mint 50 üzenetplatformot összeköt), Agent (értelmező motor), Skills (több mint 5400 plugin), Memory (memória rendszer).

De Elvis különösen használja az OpenClaw-t. Ő közvetlenül orchestrációs rétegként használja, kifejezetten a Claude Code és Codex kódoló Agentek kezelésére, nem általános asszisztensként.

Ez a gondolat valóban nem mindennapi.

Miért van szükség egy orchestrációs rétegre?

Elvis a tweetjében egy nagyon fontos nézőpontot említett: A kontextusablak zéró összegű játék.

Ha kódot töltesz bele, akkor nincs hely a üzleti kontextus számára. Ha ügyfél történeteket és értekezleti jegyzeteket töltesz bele, akkor nincs hely a kódtár számára. Egyetlen AI, bármennyire is erős, nem tudja egyszerre kezelni ezt a két teljesen különböző típusú információt.

Ezért a rendszert két rétegre bontotta.

A felső réteg az OpenClaw orchestrátor Zoe, aki az összes üzleti kontextust kezeli, beleértve az ügyféladatokat, értekezleti jegyzeteket, történelmi döntéseket, hogy mely megoldásokat próbálták ki, és melyek buktak el. Ezek az információk mind Elvis Obsidian jegyzetkészletében találhatók, Zoe közvetlenül olvashatja őket.

Az alsó réteg a Claude Code és Codex kódoló Agentek, akik csak a kódra figyelnek, csak kódot írnak. Minden egyes Agent indításakor Zoe a üzleti kontextus alapján pontos promptot ír neki, hogy mit kell tennie, mi a háttér, és mit kér az ügyfél.

Egyszerűen fogalmazva: az orchestrátor felelős a követelmények megértéséért, a kódoló Agentek pedig a munkáért. Mindenki a saját szakterületén dolgozik.

Ez az architektúra hasonló a Stripe nemrégiben nyilvánosságra hozott belső rendszeréhez, a Minions-hoz. A Stripe Minions is párhuzamos kódoló Agentekből és központosított orchestrációs rétegből áll, hetente több mint 1000 teljesen AI által írt PR-t tudnak egyesíteni. Elvis azt mondta, hogy véletlenül egy hasonló architektúrát állított fel, csak a saját Mac mini-jén fut.

Valódi eset munkafolyamat

Elvis a tweetjében egy valós esetet használt, hogy bemutassa a teljes munkafolyamatát, én pedig egyszerűen összefoglalom a kulcsfontosságú lépéseket.Ő felvett egy ügyfélhívást, az ügyfél szeretné újrahasználni a meglévő konfigurációt a csapaton belül. A hívás után beszélgetett Zoe-val erről a követelményről. Mivel minden értekezleti jegyzőkönyv automatikusan szinkronizálódik az Obsidianba, Zoe már tudta, mit mondott az ügyfél, így Elvisnek nem kellett külön magyaráznia. Együtt meghatározták a funkciók körét, a végső megoldás egy sablonrendszer létrehozása lett.

Ezután Zoe automatikusan három dolgot végzett el: feltöltötte az ügyfél fiókját a szolgáltatás feloldásához (adminisztrátori API jogosultsága van), lekérte az ügyfél meglévő konfigurációját a termelési adatbázisból (csak olvasási jogosultság, a kódoló Agent soha nem rendelkezik ezzel a jogosultsággal), majd létrehozott egy Codex Agentet, amely tartalmazta a teljes üzleti kontextust részletes prompttal.

Minden Agentnek saját, független worktree-je (izolált ág) és tmux munkamenete van. A parancs indítása körülbelül így néz ki:

# Create worktree + spawn 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 Az Agent elindítása után van egy ütemezett feladat, amely 10 percenként ellenőrzi a működést. De nem kérdezi közvetlenül az Agentet (mert az túl sok tokent égetne el), hanem futtat egy determinisztikus Shell szkriptet, amely ellenőrzi, hogy a tmux munkamenet még él-e, létrejött-e PR, és hogy a CI átment-e.

Ha a CI megbukik, automatikusan újraindítja az Agentet, legfeljebb 3 alkalommal próbálkozik. Csak akkor küld értesítést, ha emberi beavatkozás szükséges.

Az Agent a feladat befejezése után automatikusan létrehoz egy PR-t. De a PR létrehozása még nem elég, Elvis egy készültségi szabványt határozott meg: PR létrehozása, ág szinkronizálása a main-re (nincs egyesítési ütközés), CI teljes átmenetele, három AI modell kódellenőrzése mind átmegy, ha van UI módosítás, akkor képernyőképet is csatolni kell.

Három AI modell kódellenőrzése

A három AI modell kódellenőrzése nagyon megbízhatónak tűnik. Beszéljünk arról, hogy mit gondol ezekről a modellekről, ez elég érdekes.

Codex Reviewer, őt értékeli a legjobban, azt mondja, hogy a határhelyzetek és logikai hibák ellenőrzése nagyon alapos, a hamis pozitív arány nagyon alacsony.

Gemini Code Assist Reviewer, ingyenes, azt mondja, hogy nagyon hasznos, képes felfedezni más modellek által kihagyott biztonsági kockázatokat és skálázhatósági problémákat, és konkrét javítási javaslatokat is ad.

Claude Code Reviewer, az ő szavai szerint "alapvetően haszontalan", azt mondja, hogy túl óvatos, tele van olyan javaslatokkal, mint "fontolja meg a hozzáadást...", a legtöbbje túltervezett. Kivéve, ha kulcsfontosságú problémaként van megjelölve, akkor egyszerűen átugorja.

Amikor ezt a részt olvastam, meglepődtem. Mint a Claude Code intenzív felhasználója, valóban találkoztam azzal, hogy a kódellenőrzés során túl konzervatív volt, de az, hogy alapvetően haszontalan, egy kicsit túlzás. De ez is közvetve azt mutatja, hogy a több modell közötti keresztellenőrzés valóban értékes, a különböző modellek elfogultsága éppen kiegészíti egymást.

Miután mindhárom ellenőrzés átment, Elvis csak akkor kap Telegram értesítést. Ezen a ponton ő főleg a képernyőképeket nézi, hogy megbizonyosodjon arról, hogy a UI módosítások helyesek, sok PR-t anélkül egyesít, hogy megnézné a kódot. Azt mondja, hogy a saját manuális ellenőrzése 5-10 percet vesz igénybe.

Zoe proaktivitása

Zoe nem csak végrehajtó. A munkafolyamatnál érdekesebb Zoe proaktivitása.

Elvis azt mondja, hogy Zoe nem várja meg, hogy feladatot kapjon, hanem aktívan keres munkát. Reggel átnézi a Sentry hibajegyzékét, felfedez 4 új hibát, automatikusan létrehoz 4 Agentet a javításhoz. A megbeszélés után átnézi a jegyzőkönyvet, megjelöli a három funkciós követelményt, amelyet az ügyfél említett, majd automatikusan elindít 3 Codex Agentet. Este átnézi a Git naplót, elindítja a Claude Code-ot a changelog és az ügyfél dokumentáció frissítésére.

Amikor Elvis kimegy sétálni, és visszatér, a Telegramon ott fekszik egy üzenet: 7 PR készen áll, 3 új funkció, 4 hibajavítás. Ez nem az, amit mindig is szerettem volna, hogy az OPC egyéni fejlesztői csapat hatását elérjem?És amikor az Agent megbukik, Zoe kezelési módja sokkal fejlettebb, mint egy egyszerű újrapróbálkozás. Összekapcsolja az üzleti kontextust a hiba okának elemzésével. Az Agent kontextusa megszakadt? Kicsinyíti a terjedelmet, és az Agent csak három fájlra összpontosít. Az Agent iránya eltévedt? Azt is kijavítja, és elmondja az Agentnek, hogy az ügyfél X-et kér, nem Y-t, és mellékeli a megbeszélés során elhangzottakat.

Az idő múlásával Zoe tapasztalatokat is felhalmoz, megjegyzi, hogy mely prompt struktúrák működnek jól bizonyos feladatokhoz, és legközelebb pontosabb promptokat ír.

Ez a gondolatmenet valójában Ralph Loop fejlettebb változata. Ralph Loop alaplogikája a kontextus lehívása, a kimenet generálása, az eredmények értékelése és a tapasztalatok megőrzése ilyen ciklusban zajlik, de a legtöbb megvalósítás minden ciklushoz rögzített promptot használ. Elvis rendszere más, minden újrapróbálkozásnál Zoe dinamikusan módosítja a promptot a hiba oka alapján, és teljes üzleti kontextussal rendelkezik.

Költségek és hardver

Költségek szempontjából Elvis nyilvános adatai szerint a Claude havonta körülbelül 100 dollárba, a Codex havonta körülbelül 90 dollárba kerül. Azt is mondta, hogy 20 dollárral is el lehet kezdeni a próbálkozást.

Ez a költség nyilvánvalóan nevetségesen olcsó egy fejlesztő alkalmazásához képest. De ha figyelembe vesszük, hogy saját termékdöntéseket, ügyfélkommunikációt és kódellenőrzést is kell végezni, akkor inkább egy hatékonyságnövelő eszköz, amely segít elkerülni a kódolás és tesztelés legismétlődőbb szakaszait.

Hardver szempontjából Elvis megemlítette, hogy jelenleg a RAM a legnagyobb szűk keresztmetszete. Minden Agentnek külön worktree-re van szüksége, minden worktree-nek saját node_modules könyvtára van, minden Agentnek futnia kell a buildelés, típusellenőrzés és tesztelés során. 5 Agent egyidejű futtatása 5 párhuzamos TypeScript fordítót, 5 tesztfuttatót és 5 függőségi csomagot jelent.

A Mac mini 16GB memóriával legfeljebb 4-5 Agentet tud egyszerre futtatni, több már memória cserét eredményez. Ezért vásárolt egy 128GB memóriás Mac Studio M4 Max-ot (3500 dollár), hogy több Agent párhuzamos futtatását támogassa.

Összegzés és valós problémák

Őszintén szólva, Elvis rendszere meglehetősen nagy hatással volt rám. Korábban az OpenClaw-t játéknak tekintettem, a termelékenység növelésében pedig a független Claude Code-ra támaszkodtam. Néha használtam worktree-t párhuzamos munkára, de messze nem értem el ezt a szisztematikus rendezést. Miután elolvastam a tweetjeit, úgy érzem, hogy az AI programozás határai újra megemelkedtek.

Mostanában az ő gondolatmenete alapján készülök az OpenClaw segítségével egy teljesen automatizált egyéni fejlesztői csapatot létrehozni. Tehát a közeljövőben több OpenClaw gyakorlati cikket fogunk közzétenni.

Van néhány valós probléma, amire figyelmeztetni kell a közönséget.

Ennek a rendszernek a feltétele, hogy legyen egy világos termék, egyértelmű ügyféligény és kifinomult CI/CD folyamat. Elvis egy valódi B2B SaaS terméket készít, van ügyfél, bevétel és termelési környezet. Ha még mindig demókat írsz vagy tanulási fázisban vagy, akkor ennek a struktúrának a ROI-ja valószínűleg nem éri meg.

Ezen kívül az OpenClaw jelenlegi biztonsági problémáira is figyelni kell. Nyilvános információk szerint már több magas kockázatú CVE-t tettek közzé, és 341 rosszindulatú közösségi plugint találtak, amelyek adatlopási tevékenységet folytattak. Az OpenClaw telepítésekor a szigetelésre és a jogosultságkezelésre különös figyelmet kell fordítani. Ez az oka annak is, hogy soha nem telepítettem az OpenClaw-t a helyi főgépre.

Egy másik dolog, hogy Elvis a tweetjeiben alacsonyabbra értékelte a Claude Code kódellenőrzését, de nemrégiben a Claude Code bemutatta az Agent Teams funkciót (hivatalosan beépített több Agent együttműködés), az Anthropic pedig ebbe az irányba is dolgozik.

De eltekintve ezektől a részletektől, Elvis architektúrája, amely a rendezési és végrehajtási rétegeket ötvözi, valóban figyelemre méltó. A kontextusablak zéró összegű játékának valódi korlátai vannak, és a rétegzett architektúra alkalmazása ennek a problémának a megoldására, lehetővé téve, hogy a különböző AI-k a saját feladatkörükben működjenek, szerintem helyes irány....