OpenClaw + Claude Code/Codex: Создавање на личен развоен агентски рој

Здраво на сите, јас сум Лу Гонг.

Наскоро на X видов твит кој веднаш ме привлече. Независен развивач по име Елвис рече дека сега веќе не користи директно Claude Code и Codex, туку го користи OpenClaw како слој за оркестрација, дозволувајќи на AI оркестратор по име Зое да управува со целата група на агенти на Claude Code и Codex.

Податоците од овој твит исто така се неверојатни, 4.9 милиони прегледи, 11.000 лајкови, 1800 споделувања.

Ние пишуваме за Vibe Coding веќе повеќе од четири месеци, а Claude Code секогаш бил наш главен алат. Предходно напишав неколку статии за соработка на повеќе агенти, архитектура на повеќе агенти во VSCode и слично.

Но кога го видов овој начин на работа на Елвис, само можев да повикам дека е вистински професионалец. Една личност, со еден систем за оркестрација, во просек 50 поднесувања на код дневно, а во најдобриот ден поднел 94 пати, и примил 3 телефонски повици од клиенти, а не ја отворил уредникот ниту еднаш.

Зарем ова не е како една личност да работи како цел развоен тим?

Денес, во овој напис, ќе разгледаме како тој всушност го постигнал тоа.

OpenClaw не е непознат за сите

Овој мали рак преди Кинеската Нова Година е во подем. Во кратки црти, тоа е отворен изворен AI агентски рамка, на GitHub веќе има повеќе од 240.000 ѕвезди и пред два дена официјално го надмина React, станувајќи проект со најбрз раст на ѕвезди во историјата на GitHub.

Основачот Петер Штајнбергер е австриски развивач, претходно основал PSPDFKit (B2B компанија за PDF рамка), во 2021 година добил инвестиција од 100 милиони евра од Insight Partners. Овој февруари, Петер објави дека се приклучува на OpenAI, а проектот OpenClaw е пренесен на фондацијата за отворен извор.

OpenClaw не е позициониран како чат-бот, туку како AI агентски работен процес што работи на вашиот локален уред. Има четири основни компоненти: Gateway (порта, поврзува 50+ платформи за пораки), Agent (мотор за инферирање), Skills (повеќе од 5400 додатоци), Memory (систем за меморија).

Но Елвис го користи OpenClaw на посебен начин. Тој го користи како слој за оркестрација, специјално за управување со кодирачките агенти на Claude Code и Codex, а не како општ асистент.

Оваа идеја навистина е невообичаена.

Зошто е потребен слој за оркестрација?

Елвис во твитот спомена еден многу важен аспект: Контекстуалниот прозорец е нулта-сум игра.

Ако ставите код во него, нема простор за деловен контекст. Ако ставите историја на клиенти и записи од состаноци, нема простор за библиотека на код. Дури и најмоќниот AI не може истовремено да смести два сосема различни типа на информации.

Затоа тој го раздели системот на два слоја.

Горниот слој е оркестраторот Зое од OpenClaw, таа ги контролира сите деловни контексти, вклучувајќи податоци за клиенти, записи од состаноци, историја на одлуки, кои решенија се пробани, кои не успеале. Овие информации се чуваат во Elvis-овата библиотека на белешки Obsidian, а Зое може директно да ги чита.

Долниот слој се кодирачките агенти на Claude Code и Codex, тие само гледаат код, само пишуваат код. Кога секој агент се активира, Зое пишува прецизен упат за него според деловниот контекст, кажувајќи му што треба да направи, каква е позадината, што клиентот сака.

Во кратки црти: оркестраторот е одговорен за разбирање на потребите, а кодирачките агенти се одговорни за работа. Секој прави она што најдобро го знае.

Оваа архитектура е слична на внатрешниот систем Minions што Stripe неодамна го објави. Minions на Stripe исто така е дизајн со паралелни кодирачки агенти и централизирана оркестрација, способни да комбинираат повеќе од 1000 PR-ови целосно напишани од AI неделно. Елвис рече дека случајно изградил слична архитектура, само што работи на неговиот Mac mini.

Реален пример за работен тек

Елвис во твитот користеше реален пример за да ја опише неговата целосна работна тек, јас ќе ги поврзам клучните моменти.Тој одговори на повик од клиент, клиентот сакаше да ги повтори постоечките конфигурации во тимот. По завршувањето на разговорот, тој разговараше со Zoe за оваа потреба. Пошто сите записи од состаноците автоматски се синхронизираат во Obsidian, Zoe веќе знаеше што кажа клиентот, не беше потребно Елвис дополнително да објаснува. Тие заедно ја утврдија функционалноста, а конечниот план беше да се направи систем за шаблони.

Потоа, Zoe автоматски направи три работи: наполни сметка на клиентот за отклучување на услугата (таа има администраторски API права), извлече постоечките конфигурации на клиентот од производната база на податоци (права за само-читач, кодирачот Agent никогаш нема да има ова право), а потоа генерираше Codex Agent, со детална упатство што вклучува целосен бизнис контекст.

Секој Agent има своја независна worktree (изолирана гранка) и tmux сесија. Командата за стартување изгледа некако вака:

# 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По стартувањето на Agent, има закажана задача која проверува на секои 10 минути. Но, тој не оди директно да праша Agent (така би потрошил премногу токени), туку извршува детерминистички Shell скрипт, кој проверува дали tmux сесијата е сè уште активна, дали е создаден PR, и дали CI е успешен.

Ако CI не успее, автоматски го рестартира Agent, со максимум три обиди. Само кога е потребна човечка интервенција, се испраќа известување.

По завршувањето на задачата, Agent автоматски создава PR. Но, само создавањето на PR не е крајот, Елвис дефинираше сет на стандарди за завршување: создавање на PR, синхронизација на гранката со main (без конфликти при спојување), целосно успешен CI, кодот на трите AI модели мора да помине ревизија, а ако има UI промени, мора да се приложи и слика.

Трите AI модели прават ревизија на кодот

Трите AI модели што прават ревизија на кодот изгледаат многу стабилно. Разговаравме за неговата оценка на овие три модели, и беше интересно.

Codex Reviewer, тој го оцени највисоко, велејќи дека неговата ревизија е многу темелна во гранични случаи и логички грешки, а стапката на лажни аларми е многу ниска.

Gemini Code Assist Reviewer, бесплатен, тој рече дека е многу корисен, може да открие безбедносни ризици и проблеми со проширливост што другите модели ги пропуштаат, и може да понуди конкретни решенија за поправка.

Claude Code Reviewer, неговите зборови беа "основно непотребен", велејќи дека е прекумерно внимателен, со многу предлози како "размислете да додадете...", а поголемиот дел од нив припаѓаат на прекумерно дизајнирање. Освен ако не е означен како критичен проблем, тој директно го прескокнува.

Кога го видов ова, бев малку изненаден. Како тежок корисник на Claude Code, навистина сум се соочил со ситуации кога беше премногу конзервативен во ревизијата на кодот, но оцената "основно непотребен" е малку претерување. Но, ова исто така укажува на тоа дека крос-ревизијата со повеќе модели навистина има вредност, бидејќи предрасудите на различните модели се комплементарни.

По успешната ревизија на трите, Елвис добива известување преку Telegram. На оваа точка, тој главно гледа слики, потврдувајќи дали UI промените се точни, многу PR-ови ги спојува без да ги погледне кодот. Тој вели дека неговата човечка ревизија трае само 5 до 10 минути.

Проактивноста на Zoe

Zoe не е само извршител. Повеќе од самата работна струја, поважно е проактивното однесување на Zoe.

Елвис вели дека Zoe не чека да и се доделат задачи, туку активно бара работа. Наутро скенира грешките во Sentry, открива 4 нови грешки, автоматски генерира 4 агенти за поправка. По состанокот, скенира записи од состанокот, означува три функционални барања спомнати од клиентот, а потоа автоматски стартува 3 Codex агенти. Навечер скенира Git логови, стартува Claude Code за ажурирање на changelog и клиентска документација.

Кога Елвис излегува на прошетка и се враќа, на Telegram има порака: 7 PR-ови се подготвени, 3 нови функции, 4 поправки на грешки. Зарем ова не е ефектот на OPC една личност што секогаш сум го посакувал во развојниот тим?И кога агентот не успее, начинот на обработка на Zoe е многу понапреден од едноставно повторување. Таа ќе комбинира анализа на причините за неуспехот со контекстот на бизнисот. Дали контекстот на агентот е преоптоварен? Ќе го намали опсегот, така што агентот ќе се фокусира само на три датотеки. Дали агентот тргнал во погрешна насока? Исто така, ќе го исправи, ќе му каже на агентот дека клиентот бара X, а не Y, и ќе приложи оригинални зборови од состанокот.

Со текот на времето, Zoe ќе акумулира искуство, ќе запомни кои структури на промпт даваат добри резултати за кои типови задачи, и следниот пат ќе напише по-прецизен промпт.

Оваа идеја всушност е надградба на Ralph Loop. Основната логика на Ralph Loop е циклусот на повлекување контекст, генерирање излез, оценка на резултатите и зачувување на искуството, но повеќето имплементации на секој циклус имаат фиксни промптови. Системот на Elvis е различен, секое повторување Zoe динамички ќе го прилагоди промптот во зависност од причината за неуспехот, и има целосен бизнис контекст.

Трошоци и хардвер

Во однос на трошоците, јавните податоци на Elvis велат дека Claude чини околу 100 долари месечно, а Codex околу 90 долари месечно. Тој исто така спомена дека можете да започнете со проба од 20 долари.

Овие трошоци се многу поевтини во споредба со вработување на развивач. Но, ако се земе предвид дека треба да направите сопствени производствени одлуки, комуникација со клиенти и преглед на код, тоа повеќе изгледа како уред за зголемување на ефикасноста, помагајќи ви да заштедите на кодирање и тестирање, кои се најповторливите фази.

Во однос на хардверот, Elvis спомена дека неговиот најголем проблем е RAM меморијата. Секој агент треба независен worktree, секој worktree има свои nodemodules, а секој агент мора да изврши градење, проверка на типови и тестирање. Пет агенти кои работат истовремено значи пет паралелни TypeScript компилатори, пет тестери и пет комплети зависности.

Неговиот Mac mini со 16GB RAM може да работи максимум 4 до 5 агенти истовремено, а повеќе од тоа почнува да разменува меморија. Затоа, купи Mac Studio M4 Max со 128GB RAM (3500 долари), со намера да го користи за да поднесе повеќе паралелни агенти.

Заклучок и реални проблеми

Искрено, системот на Elvis направи голем впечаток на мене. Претходно, го гледав OpenClaw како играчка, а за зголемување на продуктивноста, се потпирав на независен Claude Code. Понекогаш користев worktree за паралелизам, но далеку од оваа систематска организација. По читањето на неговите твитови, чувствувам дека границата на AI програмирањето повторно е подигната.

Последно време, работам според неговата идеја, подготвувајќи се да создадам целосно автоматизирана едночлена развојна екипа со OpenClaw. Затоа, наскоро ќе објавиме неколку практични статии за OpenClaw.

Постојат неколку реални проблеми на кои треба да се внимава.

Овој систем подразбира дека имате јасен производ, јасни потреби на клиентите и развиена CI/CD линија. Elvis работи на реален B2B SaaS производ, има клиенти, приход и производствена средина. Ако сè уште работите на демонстрации или сте во фаза на учење, ROI на оваа архитектура можеби не е исплатлив.

Исто така, моменталните безбедносни проблеми на OpenClaw треба да се земат во предвид. Според јавните информации, веќе се откриени неколку високо ризични CVE, а 341 злонамерен заеднички додаток е откриен со активности на кражба на податоци. Кога ќе го распоредите OpenClaw, изолацијата и контрола на правата мора да бидат добро направени. Ова е и причината зошто сè уште не го распоредив OpenClaw на мојата главна локална машина.

И уште нешто, Elvis во твитовите имаше ниска оценка за прегледот на кодот на Claude Code, но неодамна Claude Code лансираше функција Agent Teams (вградена соработка на повеќе агенти), а Anthropic исто така работи на оваа насока.

Но, оставувајќи ги настрана овие детали, архитектонската идеја на Elvis за слој на организација и извршување навистина вреди да се следи. Нултата игра на контекстуалниот прозорец е вистинско ограничување, а решавањето на овој проблем со хиерархиска архитектура, овозможувајќи различни AI да работат на своите задачи, сметам дека е правилен правец.[[HTMLPLACEHOLDER_0]]