OpenClaw + Claude Code/Codex：Създаване на личен разработващ агентен рояк

Здравейте, аз съм Лу Гонг.

Преди време видях в X публикация, която веднага ме привлече. Един независим разработчик на име Елвис каза, че вече не използва директно Claude Code и Codex, а вместо това използва OpenClaw като слой за оркестрация, за да управлява цял рояк от агенти на Claude Code и Codex, наречен Зое.

Данните от публикацията също бяха впечатляващи: 4.9 милиона прегледа, 11 хиляди харесвания, 1800 споделяния.

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

Но когато видях начина, по който Елвис работи, не можах да не се възхитя. Един човек, с помощта на система за оркестрация, прави средно 50 кодови комита на ден, а в най-добрия ден е направил 94 комита, като е получил и три клиентски обаждания, без да е отварял редактора.

Не е ли това като един човек да бъде цял екип за разработка?

Днешната статия ще разгледа как точно е успял да го постигне.

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

Тази малка рачешка е популярна от преди Нова година. Накратко, това е отворен AI агентен фреймуърк, който в момента има над 240 000 звезди в GitHub и преди два дни официално надмина 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, който управлява целия бизнес контекст, включително клиентски данни, протоколи от срещи, исторически решения, какви решения са били опитвани, какви са се провалили. Всичките тези данни са съхранени в бележника на Елвис в Obsidian и Зое може да ги чете директно.

Долният слой включва кодовите агенти Claude Code и Codex, които се фокусират само върху кода и писането на код. Когато всеки агент стартира, Зое пише прецизен prompt на базата на бизнес контекста, за да му каже какво да прави, какъв е контекстът и какво искат клиентите.

Накратко: оркестраторът отговаря за разбирането на нуждите, а кодовите агенти отговарят за работата. Всеки прави това, в което е най-добър.

Тази архитектура е подобна на вътрешната система Minions, която Stripe наскоро обяви. Minions на Stripe също е проектиране с паралелни кодови агенти и централен слой за оркестрация, който може да обедини над 1000 PR, написани изцяло от AI, всяка седмица. Елвис казва, че случайно е изградил подобна архитектура, просто работеща на неговия Mac mini.

Реален случай на работен поток

Елвис използва реален случай в публикацията си, за да обясни своя пълен работен поток, аз ще обобщя основните етапи.Той вдигна телефонно обаждане от клиент, който иска да повторно използва съществуващите конфигурации в екипа. След края на разговора той обсъди това изискване с Зое. Тъй като всички протоколи от срещи автоматично се синхронизират с Obsidian, Зое вече знаеше какво е казал клиентът и не беше нужно Елвис да обяснява допълнително. Те заедно определиха обхвата на функционалността, а окончателното решение беше да се направи система за шаблони.

След това Зое автоматично направи три неща: презареди услугата за отключване на клиента (тя има администраторски API права), изтегли съществуващата конфигурация на клиента от производствената база данни (права само за четене, кодовият агент никога няма да има тези права), след което генерира Codex Agent с подробен prompt, съдържащ пълния бизнес контекст.

Всеки агент има собствен независим worktree (изолирана клонка) и tmux сесия. Командата за стартиране изглежда по следния начин:

# Създаване на worktree + стартиране на агент 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След като агентът стартира, има задача, която проверява на всеки 10 минути. Но той не пита директно агента (това би изразходвало твърде много токени), а изпълнява детерминистичен Shell скрипт, който проверява дали tmux сесията все още е активна, дали е създаден PR и дали CI е преминал.

Ако CI се провали, агентът автоматично се рестартира, с максимум 3 опита. Уведомления се изпращат само когато е необходимо човешко вмешателство.

След като агентът завърши задачата, автоматично създава 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 минути.

Проактивността на Зое

Зое не е само изпълнител. По-интересно от самия работен поток е проактивността на Зое.

Елвис казва, че Зое не чака да ѝ бъде възложена задача, а активно търси работа. Сутрин сканира грешките в Sentry, открива 4 нови грешки и автоматично генерира 4 агента, за да ги поправи. След срещата сканира протоколите от срещата, маркира 3 функционални изисквания, споменати от клиента, след което автоматично стартира 3 Codex агента. Вечер сканира Git логовете, стартира Claude Code, за да актуализира changelog и клиентската документация.

Когато Елвис излезе на разходка и се върне, в Telegram го чака съобщение: 7 PR са готови, 3 нови функции, 4 поправки на бъгове. Нали това е ефектът, който винаги съм искал да постигна с OPC едноличен екип за разработка?И когато Agent се провали, начинът, по който Zoe се справя, е много по-напреднал от простото повторно опитване. Тя ще анализира причините за провала, като вземе предвид бизнес контекста. Контекстът на Agent е изчерпан? Тя ще стесни обхвата, така че Agent да се фокусира само върху три файла. Направлението на Agent е сбъркано? Тя също ще коригира, ще каже на Agent, че клиентът иска X, а не Y, и ще приложи оригиналните думи от срещата.

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

Тази идея всъщност е подобрена версия на Ralph Loop. Основната логика на Ralph Loop е цикъл, който включва извличане на контекст, генериране на изход, оценка на резултатите и запазване на опит, но повечето реализации имат фиксиран prompt за всеки цикъл. Системата на Elvis е различна, при всяко повторно опитване Zoe динамично коригира prompt в зависимост от причината за провала и разполага с пълен бизнес контекст.

Разходи и хардуер

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

Тази цена е разбира се много по-ниска в сравнение с наемането на разработчик. Но ако вземете предвид, че трябва да вземате собствени продуктови решения, да комуникирате с клиенти и да преглеждате код, това по-скоро прилича на усилвател на ефективността, който ви спестява от най-повторяемите етапи на кодиране и тестване.

По отношение на хардуера, Elvis спомена, че в момента най-голямото му ограничение е RAM паметта. Всеки Agent се нуждае от независим worktree, всеки worktree има свои nodemodules, всеки Agent трябва да изпълнява изграждане, проверка на типове и тестване. 5 Agents, работещи едновременно, означава 5 паралелни компилатора на TypeScript, 5 тестови изпълнители и 5 комплекта зависимости.

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

Обобщение и реални проблеми

Честно казано, системата на 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 да изпълняват своите задачи, е правилната посока според мен.[[HTMLPLACEHOLDER0]] [[HTMLPLACEHOLDER_1]]