БАЗА по OpenClaw с НОВИЧКА до ПРОФИ (вайб-кодинг) обучись ИИ агентам за одну статью.

Кто такой, этот ваш OpenClaw?

Канал с гайдами и контентом по ИИшкам и что с ними можно реализовывать, мы выписываем абсолютно всю базу по ИИ в наш канал и там другие полезные материалы: https://t.me/claudedevolper

0. Введение

Openclaw сейчас активно обсуждают: вокруг него одновременно много шума, домыслов и завышенных ожиданий. Одни воспринимают его как обычный чат с базовой нейросетью, другие — ждут почти мгновенного «чуда» по одному запросу. На практике истина находится где-то посередине. Openclaw действительно является сильным инструментом, но его потенциал раскрывается лишь тогда, когда пользователь понимает, как он устроен, по каким принципам работает и какие у него есть ограничения.

Для кого этот материал?

Первая — новички, которые лишь поверхностно знакомы с Openclaw: возможно, видели упоминания в паре постов или наткнулись на него, пролистывая ленту в X.

Вторая — пользователи, которые уже установили систему, но столкнулись с трудностями: нестабильной работой, путаницей в скиллах и памяти, а также проблемами с оркестрацией процессов.

Третья — продвинутые пользователи, стремящиеся выйти за рамки экспериментов: масштабировать свои сценарии, оптимизировать затраты и превратить Openclaw в полноценный рабочий инструмент.

Для кого эта статья

Что ты получишь после прочтения?

После этой статьи у тебя сформируется чёткое и целостное понимание:

И это далеко не всё. Но главное, на мой взгляд, — ты разберёшься в общей логике работы системы. Это избавит от постоянного внутреннего ощущения, что «что-то непонятно» — состояния, с которым я и сам не раз сталкивался.

Openclaw - это целая система, которая связывает твои привычные каналы общения с ИИ-ассистентом и превращает все это в рабочий процесс. Ты строишь логику работы, даешь установки - что агенту делать, что запоминать, как проверять результат и куда это все отправлять. Это целая связанная инфраструктура под твои личные задачи.

Объяснение на пальцах:

Представь, что у тебя есть личный помощник (ака заложник), но он живет в твоих мессенджерах. Ты ему пишешь, он собирает инфу, сортирует, оформляет, проверяет и возвращает результат. Не как абстрактная нейросеть, а как инструмент, который встроен в твою повседневную работу.

Чем OpenClaw отличается от обычного чата с ИИ?

В обычном чате все держится на одном диалоге, и ты вручную тащишь весь контекст. В OpenClaw можно делать разделение по ролям, темам и сценариям, подключать скиллы, вести память, выстраивать маршруты задач и получать более предсказуемый, а главное качественный результат. Это разница между дефолт болтовней и целой системой.

Сравнение обычного чата с ИИ и Openclaw

Почему это не просто бот?

До этого можно и самому додуматься, но решил расписать. Все просто - бот обычно отвечает лишь на команды. OpenClaw - это слой управления: сессии, память, инструменты, логика передачи задач и тд. Он нужен не для фразы напиши мне постик, а для повторяемых рабочих процессов, в которых важны контроль и четкая стабильность.

Где OpenClaw реально полезен:

Переходим уже к интересному. Лучше всего Openclaw по моему личному опыту раскрывается в рутинных задачах, например: ресерч, контент, сводки, отчеты, поддержка и так можно перечислять дохуя всего. Если ты регулярно делаешь одно и то же вручную, он экономит время очень заметно.

Где он не нужен:

Если у тебя разовые запросы и ты не хочешь ничего настраивать, он будет избыточен. Если нет желания поддерживать структуру, память и правила, система быстро превращается в тот же чат, только сложнее. OpenClaw нужен тем, кто хочет собрать рабочий контур, а не просто иногда поговорить с ИИ. Все очень просто.

Сразу скажу, этот блок не обязательный к прочтению, если тебе нужен только практический результат здесь и сейчас. Можешь спокойно скипнуть и перейти к установке, архитектуре и боевым сценариям. Но если хочешь реально понять, почему OpenClaw такой, какой он есть сейчас, лучше пробежаться.

Все началось не с цели сделать очередной чат с ИИ, а с более приземленной боли. Людям нужен был помощник, который работает в привычных каналах, а не живет в отдельной вкладке и не требует каждый раз ручного запуска. То есть идея с самого начала была рабочая - сделать слой управления между мессенджерами и агентом, чтобы это было стабильно, удобно и под контролем пользователя.

Этап Warelay

Warelay - именно так называлась их первая оболочка. На этом этапе формировался так называемый фундамент. Один gateway, который принимает сообщения из канала и передает их агенту. Это ранняя стадия, где все было проще по упаковке, но уже заложены ключевые принципы - практичность, локальный контроль и интеграция с реальными каналами.

Этап Clawdbot

Дальше проект перешел в Clawdbot. На этом этапе уже появилась более узнаваемая айдентика, персонаж Clawd и активный комьюнити вайб. Проект начал расти не только как код, но и как полноценная экосистема, где были обсуждения, фидбек, реальные кейсы и первые устойчивые паттерны использования. Именно в этот период стало заметно, что это уже не просто прототип для энтузиастов, а база для масштабируемого рабочего инструмента.

Этап Moltbot

После ребрендинговой волны в январе 2026 проект вошел в фазу Moltbot с персонажем Molty. Это был тот самый момент, когда все менялось прямо на бегу. Название, визуал, упаковка, публичные ссылки, все ехало одновременно, а команде нужно было не просто переименоваться, а не уронить систему в процессе. На фоне этого в комьюнити был настоящий движ, кто-то не успевал за изменениями, кто-то спорил за новое имя, кто-то просто орал что это кино, но при этом продукт продолжал ебануто работать и развиваться. И это ключевой момент. Проект не остановился на косметике, он выдержал давление, сохранил темп и дошел до финальной формы. Moltbot был промежуточным изменением.

Финальный переход в OpenClaw

Финальный переход в OpenClaw был не про смену таблички на двери, а про взрослую сборку проекта в единую форму. В конце января 2026 команда за короткое окно перевела ключевые опоры под новое имя, репозиторий, пакеты и документацию. На фоне этого, как обычно, было много шума, обсуждений и попыток словить хайп вокруг названия, но важнее другое, ядро проекта не развалилось и не потерялось в ребренде. Наоборот, после фиксации OpenClaw система стала восприниматься намного цельнее, как рабочий продукт, а не как набор разрозненных этапов. Именно этот момент и закрепил проект в голове у большинства пользователей как зрелую версию с понятной идентичностью и понятным вектором развития.

Что менялось по названию и что не менялось по сути?

Я думаю, если вы прочитали 3 верхних пункта, вы поймете - менялись внутренности, проект развивался. Не менялось только одно - главная идея. Личный ассистент под контролем владельца, работа через привычные каналы, управляемая память, инструменты и маршрутизация задач. Если совсем уж просто, вывеска менялась, а ядро оставалось тем же.

История создания проекта Openclaw

Почему эта история важна для понимания продукта?

Эта история хорошо показывает реальный характер проекта. Это не одноразовый хайп и не красивый лендинг без внутренней базы, где внутри, по факту, нихуя нет. OpenClaw прошел через рост, давление, ребрендинг и при этом не потерял главный вектор, контроль, практичность, расширяемость и пользу в реальной работе. Когда это понимаешь, начинаешь смотреть на OpenClaw не как на чатик с фишками, а как на систему, которую нужно собирать под себя и обслуживать как рабочий инструмент, иначе потом словишь пиздец в проде.

Этот пункт также не обязателен к прочтению, но он очень сильно прокачает вас в понимании проекта, что на данный момент действительно важно и нужно. Если убрать весь маркетинг и красивую обертку, философия OpenClaw очень приземленная и практичная. Это инструмент для тех, кто хочет реальный контроль и рабочий результат, а не еще один чат ради поболтать. Здесь нет магии в один клик. Логика простая, ты собираешь контур под себя, задаешь правила, проверяешь качество, обслуживаешь систему и получаешь стабильную пользу. Если относиться к этому как к игрушке, через неделю будет каша. Если относиться как к рабочему инструменту, получишь сильного оператора под свои задачи.

Ключевая идея OpenClaw в том, что главный в системе не платформа, а ты. Ты решаешь, какие каналы подключать, какие модели использовать, что агенту можно, а что нельзя, как хранить память и как должен выглядеть финальный результат. Это важно, потому что в обычных сервисах правила спускают сверху, а здесь ты сам управляешь своим контуром. Проще говоря, меньше зависимости от чужих решений и меньше шансов однажды проснуться с ощущением, что все сломалось и ты нихуя не можешь с этим сделать. Короче ты - бригадир всей этой темы (и это чертовски круто).

Self hosted подход

Self hosted (все крутится у тебя, а не в чужом сервисе) это не модное словечко, а конкретная модель работы, где основа системы живет у тебя, а не в чужом черном ящике. Плюсы очевидные, больше контроля, гибкости, кастомизации и предсказуемости. Минусы тоже есть, нужно самому думать про настройку, обновления, доступы и безопасность. То есть тут не формат в плане заплатил и забыл, а формат настроил, управляешь, жалуешься (в некоторых случаях). Для кого-то это минус, а для тех, кто хочет нормальную систему, это как раз то, ради чего все затевается.

Один центр управления и много каналов

Одна из самых сильных идей OpenClaw это единый контур управления. Вместо зоопарка из разных ботов и ручных костылей ты получаешь одну точку, через которую идет логика работы. Telegram, WhatsApp, Discord и другие каналы не живут каждый своей жизнью, а подчиняются общей архитектуре. Это сильно снижает хаос и дубли, потому что память, маршрутизация задач и правила ответов не размазаны по десяти местам. Круто, правда?

Личный оператор вместо игрушки

Если вы до сих пор не поняли - Openclaw раскрывается не в режиме спросил, ответил, кайфанул. А в режиме делегировал рутину и получил качественный результат. Это не чатик с красивыми формулировками, можно сказать, что это твой личный работник (причем достаточно дешевый). Он может вести очень много, например ресерч, черновики, сводки, отчеты, техничку, контроль этапов и прочие рабочие сценарии, но я об этом уже упоминал не один раз. Когда ты прочтешь эту статью и соберешь качественную систему ты и сам в этом убедишься.

Ответственность пользователя за архитектуру и безопасность

Ну, а вы что думали, свобода почти всегда идет в комплекте с ответственностью. Если ты криво собрал архитектуру, засрал память, накидал сомнительных скиллов и не проверяешь доступы, система рано или поздно превратится в пиздец. Поэтому правило здесь одно, все важное прогонять через дисциплину. Тестовый контур перед продом, ревизия памяти, минимальные права, проверка скиллов, контроль логов и понятные протоколы работы (подробно обо всем этом чутка попозже). OpenClaw дает тебе мощный конструктор, но то, насколько он будет стабильным и безопасным, зависит уже от тебя.

Философия Openclaw.

Ура, от скучного и не интересного мы наконец-то пришли к реально важному для дальнейшего использования. Если вы поймете архитектуру, вы красавцы.

Что такое gateway и как он работает?

Gateway это не просто штука посередине, а реальный центр управления всей системой. Он принимает входящие сообщения из разных каналов, определяет, откуда пришел запрос, кому его отдать, в какой сессии обработать и в каком формате вернуть ответ. По сути, это диспетчер и шина данных в одном лице. Без него ты получаешь набор разрозненных чатов, которые не понимают друг друга и живут каждый своей жизнью, то есть полный бардак. Важный момент, gateway не только прокидывает сообщения, он еще держит единые правила обработки, следит за целостностью потока и не дает системе развалиться при росте нагрузки. Когда у тебя один канал, это не так заметно. Когда каналов несколько и задачи идут параллельно, без нормального gateway все быстро превращается в кашу, дубли и случайные ответы не туда, а дальше уже начинается пиздец с ручным разгребанием.

Что такое Gateway.

Каналы связи и маршрутизация

Каналы это точки входа в систему, Telegram, WhatsApp, Discord и другие. Но сами по себе каналы ничего не решают. Ключевое это маршрутизация, то есть логика, кто и как обрабатывает конкретный запрос. Один тип задач должен идти в один контур, другой в другой. Иначе ты теряешь контекст, мешаешь роли и начинаешь плакать, чиня последствия. Ахуенно грамотная и четкая маршрутизация помогает сразу на трех уровнях. Первый уровень, не возникает дублей по одной и той же задаче. Второй уровень, каждая роль получает ТОЛЬКО свой кусок работы. Третий уровень, легче дебажить, потому что понятно где именно отвалился этап. Если маршрутизация слабая, система вроде работает, но качество плавает и в какой-то момент это начинает сильно бесить и раздражать.

Каналы связи и правильная маршрутизация.

Сессии и изоляция контекста

Сессия это целый отдельный рабочий поток с собственной хистори и логикой. Изоляция контекста нужна для того, чтобы задачи из одного потока не перетекали в другой (если проще, чтобы они не перемешивались). Если у тебя контент, техничка и финансы сидят в одной кастрюли, кашу ты из этого не сваришь, агент неизбежно начнет тащить куски не туда. Правильный подход это разделение по сценариям. Отдельная сессия под контент, отдельная под ресерч, отдельная под операционку. Плюс жесткое правило переносов только по явной пометке INPUT from. Тогда система не фантазирует и не подмешивает чужой шум. Ну, а детальнее ты разберешься с настройкой по ходу статьи.

Память агента

Память это целая система хранения важных штуковин. Это рабочая структура, которая определяет, насколько агент стабилен через неделю, месяц и дальше. Обычно нужен минимум двухслойный контур. Долгосрочная память для правил, стабильных решений и предпочтений. Оперативная дневная память для текущих задач, ошибок и промежуточных выводов. Как я уже и говорил, несешь ответственность тут только ты, поэтому, если вести память на отъебисъ, готовься пожимать плоды в виде потери фокуса агента и повторении одного и того же. Важный нюанс, память надо регулярно чистить, переносить важное из daily в long-term и выкидывать мусор. Без ревизии даже хорошая система со временем задыхается. Но, самое крутое, что все это можно скинуть на агента!

Двухслойный контур памяти агента.

Скиллы

Самое опасное и одновременное самое полезное. Без скиллов агент = просто чатик. Так что вчитайтесь, постарался максимально подробно вывалить инфу.Скиллы это не просто допы для OpenClaw, а рабочие модули поведения агента под конкретные задачи. Они задают не только стиль ответа, но и весь контур выполнения, что агент читает, что игнорирует, в каком формате возвращает результат, где останавливается, какие действия запускает и какие риски обязан помечать (короче, считай все). Если коротко, хороший скилл = половина успеха.

Почему это важно? - Потому что модель сама по себе часто дает рандом, особенно на длинных сценариях. Скилл фиксирует так называемые рельсы. Один и тот же тип задачи начинает выполняться одинаково по структуре и качеству. Для контента это стабильный формат. Для ресерча это проверка источников. Для технички это повторяемая диагностика. То есть ты получаешь сразу готовую систему. И все это - СКИЛЛЫ.

Где люди чаще всего ловят проблемы? - Первая ошибка, ставят скиллы пачкой, потому что название звучит красиво, а проверить на вредоносность им лень. Вторая ошибка, не смотрят что скилл делает на уровне кода и зависимостей. Третья ошибка, сразу льют в прод без проверки в виде песочницы. В итоге начинается каша, пересечение ролей, конфликт инструкций, странные вызовы, лишние расходы и внезапные поломки. Экономия 10 минут на старте потом легко превращается в часы ручного разгребания пиздеца.

Перед установкой рекомендую проверять скилл на то, что он устанавливает и запускает, какие права ему реально нужны, есть ли hooks, postinstall и автозапуск, куда пишет файлы и что читает, куда идет сеть и какие внешние сервисы дергаются. Если видишь какие то черные мутки-схемки, лучше стопни и проверь поглубже. Последствия могут быть серьезнее, чем ты думаешь!!!

Отдельный нюанс, даже хорошие скиллы могут конфликтовать между собой.Причина простая, у них может совпадать зона ответственности или ломаться формат передачи данных. Например один ожидает структурный JSON, другой отдает свободный текст. На бумаге оба норм, а в связке не дружат :(. Поэтому рабочее правило, ставь по одному, тестируй на своих сценариях, фиксируй версию и только потом добавляй следующий, не ебашь 10 подряд, пожалуйста!!

Также добавлю чутка про обновления - обнова скилла это не косметика. Там может измениться логика, и твой стабильный pipeline начнет вести себя по-другому. Поэтому любое обновление прогоняй через тестовый контур. Если все ок, только после этого катишь в прод. Без этого ты каждый раз играешь в рулетку. Да, может показаться долго, но поверь моему опыту. Потрать свои 10 минут, но потом живи спокойно - святое правило.

Минимальный безопасный циклревью -> песочница -> тест на реальных кейсах -> фиксация версии -> релиз в рабочий контур -> мониторинг и откатный планНа схеме ниже это также показано

Минимальный безопасный цикл.

Инструменты и вызовы команд

Инструменты это практические руки агента, поиск, чтение, запуск команд, интеграции и внешние действия. Без инструментов агент просто пиздит и рассуждает, а с инструментами он реально делает работу. Но чтобы это было безопасно и полезно, вызовы должны быть четкими, ограниченными и проверяемыми. Чем меньше абстракции в команде, тем лучше результат и меньше шансов словить хуйню на выходе. Нужен конкретный формат входа, ожидаемый формат выхода и понятные условия остановки. Тогда агент не уходит в фантазии и не делает лишнего. В технических сценариях это особенно критично. Один раз дать расплывчатую команду можно, но если так построить весь процесс, будет постоянный рандом, нестабильность и в какой-то момент полноценный пиздец.

Оркестрация ролей и пайплайнов

Оркестрация это когда работа идет по этапам и ролям, а не одним жирным запросом на авось. То есть не формат сделай мне всё сразу, а понятный конвейер, где один собирает факты, второй упаковывает, третий проверяет, а четвертый отдает финал. На практике это выглядит так, research тянет фактуру, writer собирает текст, qa режет косяки, orch контролит маршрут и выпускает итог (писал обо всем этом в виде постов в своем тгк). Без оркестрации обычно начинается одна и та же хуйня, контекст смешивается, роли лезут друг в друга, появляются дубли, а качество прыгает от норм до полного пиздеца. Оркестрация убирает эту лотерею, потому что у тебя есть маршрут, правила перехода между этапами и понятные точки проверки. Если что-то сломалось, ты чинишь конкретный участок, а не переписываешь всё с нуля. В итоге получаешь стабильность, предсказуемость и систему, которая держит нагрузку без истерики. Дальше в статье мы разберем сразу три рабочих варианта оркестрации, от простого к более продвинутому, чтобы ты выбрал схему под себя, а не тыкался вслепую.

Оркестрация ролей.

Список здесь реально обширный, и его можно продолжать очень долго, потому что сценариев применения дохуя. Но ключевая мысль простая, пока вы сами не попробуете внедрить OpenClaw в свою жизнь и работу, вы до конца не поймете, нужен он вам или нет. Даже если прочитаете этот раздел от корки до корки, сомнения все равно могут остаться, и это нормально. По опыту лучше всего он заходит тем, у кого есть повторяемая рутина и постоянный поток задач. Контент креаторы через него выстраивают конвейер от идеи до публикации и перестают каждый день начинать с нуля. Разработчики используют его как операционный слой для логов, задач, черновых фиксов и контроля этапов, чтобы не тонуть в мелочевке. Фрилансерам он помогает не проебывать дедлайны. Малые команды через него режут хаос, дубли и бесконечные созвоны по одному и тому же и тд тп. Далее я расскажу более подробно про все категории пользователей, которые перечислил выше.

Кому подходит Openclaw.

Контентщикам OpenClaw обычно заходит быстрее всех, потому что у них каждый день один и тот же цикл, идея, ресерч, черновик, редактура, публикация, ответы, и так по кругу без конца. Я, кстати, тоже применяю его для этих дел. Так чем же он помогает? OpenClaw позволяет это собрать в понятный поток, где агент не просто пишет текст на коленке за вас. Он формирует это все в единую и понятную цепь, при этом держа структуру, стиль и ваш формат. Если ко всему этому прибавить оркестрацию, то вы получите настоящую конфетку, которая станет незаменимым помощником в плане контента. Но о ней мы поговорим попозже.

Разработчикам OpenClaw полезен не как волшебный генератор кода, а как операционный усилитель. Логи, разбор ошибок, черновые фиксы, структурирование задач, все это он может закрывать очень бодро.

Для фрилансеров Openclaw как будто является незаменимой составляющей. Когда ты делегируешь агенту входящие, черновики ответов, напоминания, ежедневные срезы и первичную упаковку задач, ты перестаешь тонуть в мелочевке и терять фокус. Личный помощник очень хорошо разгружает и дает больше времени на оплачиваемую работу, а не на бесконечную организационную дрочильню.

Солопренеры. Да тут даже без слов понятно, зачем им нужен Openclaw. Но, ладно, тут тоже распишу. Солопренерам OpenClaw заходит как вторая голова, которая держит структуру бизнеса, пока ты бегаешь между продуктом, продажами, контентом и операционкой. В таком режиме легко проебать важное просто потому, что задач дохуя и все горит одновременно. OpenClaw тут помогает собрать единый контур, где есть память, приоритеты, регулярные отчеты и контроль по этапам. Короче, меньше ручного хаоса, больше системности и спокойствия в ежедневной работе.

Для маленьких команд OpenClaw особенно полезен с точки зрения денег, потому что нанимать отдельного сотрудника под мелкие операционные задачи часто тупо дорого, особенно когда этих задач много, но каждая сама по себе маленькая и не требует много внимания. В итоге бюджет уходит, а скорость работы растет слабо. OpenClaw в таком режиме закрывает большой пласт рутины на раз-два (сортировка входящих, первичные ответы, черновики, напоминания, сводки и тд, перечислять можно реально долго). За счет этого команда не проебывает деньги, а без сомнений делегирует задачи Openclaw. Тут главное все правильно настроить, и тогда дела будут щелкаться как нечего делать.

Кому лучше не лезть?

Если ты не готов потратить время на базовую настройку, если не готов поддерживать порядок в памяти и если тебя бесит любая дисциплина процесса, лучше пока не лезть и забить на эти новые технологии. Без этих вещей OpenClaw быстро превратится в ту же свалку, только технологичнее на вид. И еще, если ты любишь ставить все подряд без проверки и надеяться на авось, то почти гарантированно словишь проблемы и потом будешь долго разгребать. OpenClaw отлично работает, когда к нему относятся как к рабочей системе.

Вот ты и увидел заветное слово "установка". Не спеши радоваться, это лишь подготовка. И да, именно на этом этапе большинство ловит пиздец, потому что хочется сразу нажать поехали, а базу никто не проверяет. Постараюсь долго не тянуть и по быстрому отправить вас на седьмой пункт.

Что проверить до старта?

До старта у тебя должна быть закрыта элементарная база. Проверяй, есть ли нормальный доступ к машине, работает ли терминал без косяков, стабилен ли интернет, есть ли свободное место на диске, и главное, понимаешь ли ты где тестовый контур, а где рабочий. Если ты это не разделил заранее, потом в боевом режиме легко можешь снести что-то не то или закатить сырые правки в рабочую среду. Плюс сразу проверь, кто у тебя отвечает за доступы и обновления, чтобы не было ситуации, где все завязано на одном человеке и при любой проблеме начинается паника. Короче, до старта нужно навести порядок в инфраструктуре, иначе дальше вся система поедет через одно место...

Минимальные требования?

Для базового старта OpenClaw можно завестись и на очень скромном VPS, но если хочешь, чтобы оно не задыхалось при реальной работе, лучше сразу брать запас. Нижний рабочий минимум для легкого контура это 2 vCPU, 4 GB RAM и 30–50 GB SSD, а комфортная конфигурация для ежедневного использования это 4 vCPU, 8 GB RAM и 60+ GB SSD. По системе самый ровный вариант это Ubuntu 22.04 LTS, меньше сюрпризов и проще поддержка. По рантайму важно писать точно, OpenClaw требует Node.js 22+ (рекомендован Node 24). Python не является базовым требованием самого OpenClaw, он нужен только для отдельных сценариев и некоторых скиллов. Если планируешь локальные модели через Ollama, особенно тяжелые, требования к железу резко растут. Для простых моделей 16 GB RAM еще ок, но 70B без мощной GPU это почти гарантированная боль, лаги и проебанное время. Короче, если хочешь стабильность, не ставь впритык и не экономь на ресурсах там, где потом словишь пиздец в проде.

Где лучше ставить?

Вопрос где ставить, это не вопрос вкуса, а вопрос задачи. Если ты просто тестишь и хочешь быстро понять механику, локалка подходит идеально, минимум бюрократии, все под рукой, можно спокойно ломать и чинить. Если тебе нужен стабильный рабочий контур на каждый день, лучше сразу смотреть в сторону VPS или сервера, потому что локальная машина всегда завязана на твой быт, то интернет отвалился, то ноут ушел в сон, то система решила обновиться в самый неподходящий момент. Серверный вариант требует чуть больше дисциплины по безопасности и администрированию, но зато дает стабильность и предсказуемость, а в рабочей эксплуатации это критично. И да, если не хочешь потом разгребать хаос, не мешай тестовую и боевую среду в один котел. Лично я сразу поставил на VPS, хотя тогда вообще не понимал зачем

Локалка или VPS?

Если делать так, чтобы сохранить на будущее, ставь сразу на VPS и не еби себе мозги с локалкой. Локалка хороша только для поиграться, но в реальной работе она постоянно подкидывает хуйню. VPS дает нормальный аптайм, доступ из любой точки, предсказуемую среду и понятный контроль. Плюс ты сразу строишь рабочий контур. Для новичка это даже проще в долгую, один раз поднял чисто на сервере, зафиксировал стек, сделал бэкап и поехал без постоянного бытового бардака. Если цель реально работать, то путь сразу на VPS самый адекватный и без лишней хуйни, но все это достаточно субъективно. Кто-то рекомендует сначала локалку, а после подключать VPS, но я пишу по своему личному опыту.

Какой стек выбрать на старте?

Достаточно спорный вопрос. Но давай поясню максимально понятно. На старте не надо строить чертолет из двадцати интеграций, пяти моделей и десятков скиллов, потому что это почти гарантированный путь в свалку/бардак. Нормальный старт это простой, понятный стек, где у тебя один основной канал связи, одна рабочая модель, минимальный набор проверенных скиллов и один четкий сценарий, который ты можешь прогнать от начала до конца. Когда этот контур стабильно работает, только тогда добавляешь новые роли, маршруты и автоматизации. Если сделать наоборот и сразу навалить всего, система начнет сыпаться, а ты не поймешь, где именно косяк. Короче, меньше понтов на старте, больше надёжности - и потом масштабируй спокойно

Базовый чеклист перед установкой

Перед установкой лучше пройтись по пунктам в одном потоке, чтобы потом не разгребать косяки в проде. Сначала закрываешь доступ и проверяешь, что у тебя есть нормальный SSH или локальный админ-доступ, терминал не отваливается и права на установку зависимостей на месте. Потом идешь в систему и смотришь, что ОС обновлена, сеть стабильная, а время и таймзона не кривые, иначе позже вылезет тупая хрень в логах и сервисах. Дальше проверяешь ресурсы, CPU и RAM не должны быть впритык, диск с запасом, под нагрузкой начнётся деградация и система ляжет. После этого переходишь к runtime, нужен Node.js 22+ (лучше 24), плюс git и базовые утилиты, и важно, чтобы зависимости ставились без конфликтов. Следом закрываешь безопасность, не держишь ключи в открытых файлах, не работаешь под root без причины и не ставишь suspicious штуки вслепую. Потом фиксируешь план отката, то есть бэкап конфигов, понятный сценарий отката и жесткое разделение тестового и рабочего контура. И только после всего этого запускаешь старт, сначала минимальный рабочий сценарий, потом уже масштабирование. Вот эта скучная последовательность и спасает от лишнего пиздеца, когда система должна работать, а не разваливаться от первой же нагрузки.

Базовый чеклист перед установкой.

Схематично должно быть так:Доступ -> Система -> Ресурсы -> Runtime -> Безопасность -> План отката -> Старт

Вот ты и подошел к самому интересному. В этих пунктах я постарался на максимум и расписал каждый шаг для идеальной установки. Но сначала немного поясню, почему так важно следовать всему, что написано ниже. Когда я первый раз ставил OpenClaw, думал что это история на 10 минут и погнали. По факту, если идти без структуры, очень быстро ловишь бардак. Поэтому тут идем по уму, сначала быстрый вариант для тех, кому надо просто запуститься, потом подробный путь для тех, кто хочет четко понимать что стоит в системе и как это обслуживать. Это, наверное, самый важный пункт для новичка. Моя рекомендация пройти четкий и долгий путь, чтобы во всем разобраться.

Перед тем как выбрать свой вариант - важный момент про авторизациюВо время онбординга тебе предложат выбрать как подключить модель. Два варианта:API ключ - вводишь ключ вручную, платишь за каждый токен. Подходит если уже есть ключ от Anthropic, OpenAI или другого провайдера.OAuth через браузер - онбординг выдаёт ссылку, открываешь её в браузере, логинишься в свой аккаунт нужного провайдера, копируешь токен из адресной строки и вставляешь обратно в терминал. Работает на подписке ChatGPT Plus/Pro и Gemini. Платишь фиксированно за подписку, без доплаты за токены. Хороший вариант на старте если подписка уже есть или много бабосов тратить не готов. Какой выбрать решаешь сам исходя из того что у тебя уже есть. Я лично заходил через OAuth на ChatGPT, так как за токены платить дороговато. Ну поехали.

Вариант 1) Windows (локалка)

Что понадобится перед стартом:- Компьютер или ноутбук с Windows 10/11- Стабильный интернет- API-ключ от провайдера модели (Anthropic, OpenAI или другой)- Аккаунт в Telegram и бот от @BotFather (если хочешь работать через Telegram)- Около 30–60 минут свободного времени

Windows нативно OpenClaw не поддерживает - нужна Unix-среда. Единственный нормальный путь это WSL2 (Windows Subsystem for Linux). Не Cygwin, не Git Bash, не эмуляторы - именно WSL2. Всё остальное рано или поздно сломается в самый неподходящий момент.

Шаг 1. Включаешь WSL2

Открываешь PowerShell от имени администратора - правая кнопка на иконке, «Запуск от имени администратора». Вводишь:

wsl --install -d Ubuntu-24.04

Эта команда сама установит WSL2 и Ubuntu 24.04. После установки перезагружаешь машину - без перезагрузки не пойдёт. Если WSL уже был установлен раньше, обновляешь и проверяешь версию:

wsl --update wsl --set-default-version 2

Шаг 2. Заходишь в Ubuntu

После перезагрузки открываешь Ubuntu из меню Пуск - попадаешь в терминал Linux прямо внутри Windows. При первом запуске Ubuntu попросит создать пользователя и пароль - заполняй, это твой локальный пользователь внутри WSL.

Шаг 3. Безопасность перед установкой

Это не опционально. Делаешь один раз и живёшь спокойно.

Обновляешь систему и ставишь нужные утилиты:

sudo apt update && sudo apt upgrade -y sudo apt install -y curl gnupg lsb-release jq ufw

sudo - запуск от имени администратора. apt update скачивает актуальный список пакетов. apt upgrade обновляет всё что стоит. -y - автоматически соглашаться на всё, чтобы не жать Enter на каждый вопрос. curl, gnupg, lsb-release, jq - базовые утилиты которые понадобятся дальше.

Ограничиваешь размер логов чтобы они не съели весь диск со временем:

sudo sed -i 's/^#SystemMaxUse=.*/SystemMaxUse=100M/' /etc/systemd/journald.conf sudo sed -i 's/^SystemMaxUse=.*/SystemMaxUse=100M/' /etc/systemd/journald.conf sudo systemctl restart systemd-journald sudo journalctl --vacuum-size=100M

sed -i - редактирует файл прямо на месте, без открытия редактора. Эти команды находят строку с SystemMaxUse в конфиге и выставляют лимит в 100 мегабайт.

Настраиваешь firewall, на локалке это базовая гигиена:

sudo ufw allow ssh echo "y" | sudo ufw enable

ufw - Uncomplicated Firewall, простой инструмент управления правилами. Разрешаешь SSH, остальное закрываешь. echo "y" - автоматически подтверждаешь включение, чтобы не отвечать на вопрос руками.

Шаг 4. Ставишь Node.js через nvm

Не ставь Node через apt - там старые версии, OpenClaw на них не запустится. Только через nvm:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash

curl -o- скачивает скрипт и передаёт его прямо в bash для выполнения. После установки перезагружаешь конфиг терминала чтобы nvm стал доступен:

source ~/.bashrc

source - выполняет файл в текущей сессии, как будто ты перезашёл в терминал. Теперь ставишь Node 24:

nvm install 24 nvm use 24

nvm install 24 скачивает и устанавливает Node.js версии 24. nvm use 24 - переключает текущую сессию на эту версию. Проверяешь:

node -v

Должно вернуть v24.x.x. Если вернуло что-то ниже 22 - закрой и открой терминал заново, потом снова nvm use 24.

Шаг 5. Устанавливаешь OpenClaw

curl -fsSL https://openclaw.ai/install.sh | bash

-fsSL - флаги для curl: -f падает с ошибкой если что-то пошло не так, -s тихий режим без лишнего вывода, -S показывает ошибки если они есть, -L следует за редиректами. Ждёшь окончания установки, обычно минута-полторы.

После этого запускаешь onboarding:

openclaw onboard

onboarding проведёт тебя по настройке: выбор модели, API ключ, канал связи. Не жми Ctrl+C посередине - там настраивается то, что потом придётся делать руками.

Шаг 6. Canvas Host делаешь сразу

По умолчанию OpenClaw открывает dashboard на 0.0.0.0 - на всех сетевых интерфейсах. На локалке это терпимо, но правильная привычка - закрыть сразу:

nano ~/.openclaw/openclaw.json

nano - простой текстовый редактор прямо в терминале. Находишь строку с bind или canvasHost и меняешь значение с 0.0.0.0 на 127.0.0.1. Сохраняешь: Ctrl+O, Enter, Ctrl+X. Перезапускаешь:

openclaw restart

Шаг 7. API ключи - только правильным способом

Никогда не вставляй ключ в файл в открытом виде и не вводи его напрямую в терминале - он попадёт в историю команд. Ключ вводишь только через onboarding или переменную окружения:

export ANTHROPIC_API_KEY=sk-ant-твой_ключ

Чтобы переменная сохранялась между сессиями, добавь эту строку в конец файла ~/.bashrc. Но не коммить .bashrc в публичный репозиторий.

Шаг 8. Проверяешь что всё живое

openclaw doctor

Встроенная диагностика. Проверит версию Node, конфиги, зависимости. Всё зелёное - поехали в 7.2. Если есть красные строки фиксишь до следующего шага, не тащишь проблему дальше.

Вариант 2) Linux / Mac (локалка)

Что понадобится перед стартом:- Компьютер или ноутбук с Linux (Ubuntu 22.04/24.04) или macOS- Стабильный интернет- API-ключ от провайдера модели- Аккаунт в Telegram и бот от @BotFather- Около 30–60 минут свободного времени

Тут проще всего - никаких прослоек, всё нативное. Ubuntu 22.04 или 24.04 - оптимальный вариант для Linux. На macOS всё работает так же, только вместо apt используется brew для установки дополнительных утилит.

Шаг 1. Обновляешь систему и ставишь утилиты

На Linux:

sudo apt update && sudo apt upgrade -y sudo apt install -y curl gnupg lsb-release jq ufw

На macOS:

brew update && brew upgrade brew install curl jq

brew - пакетный менеджер для macOS, аналог apt в Ubuntu. Если brew не установлен, сначала ставишь его с официального сайта brew.sh.

Шаг 2. Ограничиваешь логи (только Linux)

sudo sed -i 's/^#SystemMaxUse=.*/SystemMaxUse=100M/' /etc/systemd/journald.conf sudo sed -i 's/^SystemMaxUse=.*/SystemMaxUse=100M/' /etc/systemd/journald.conf sudo systemctl restart systemd-journald sudo journalctl --vacuum-size=100M

На macOS этот шаг пропускаешь, там другая система логирования и размер управляется иначе

Шаг 3. Настраиваешь firewall

На Linux:

sudo ufw allow ssh echo "y" | sudo ufw enable

На macOS файрвол настраивается через Системные настройки -> Сеть -> Файрвол. Включи его если ещё не включён - больше ничего для локалки не нужно.

Шаг 4. Ставишь Node.js через nvm

На обоих системах одинаково:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash

На macOS если используешь zsh (по умолчанию в новых версиях), то вместо ~/.bashrc пишешь ~/.zshrc:

source ~/.zshrc

На Linux:

source ~/.bashrc

Дальше:

nvm install 24 nvm use 24 node -v

Должно вернуть v24.x.x.

Шаг 5. Устанавливаешь OpenClaw

curl -fsSL https://openclaw.ai/install.sh | bash openclaw onboard

Шаг 6. Автозапуск (полезно в том случае, если комп всегда включен)

Если хочешь чтобы gateway стартовал автоматически при включении:

openclaw onboard --install-daemon

Эта команда поднимает systemd-сервис (на Linux) или launchd (на macOS) под твоим пользователем. Он будет держать OpenClaw живым и перезапускать при падении.

Шаг 7. Canvas Host и API ключи

Та же история что на Windows:

nano ~/.openclaw/openclaw.json

Меняешь 0.0.0.0 на 127.0.0.1, сохраняешь. Ключи только через онбординг или переменную окружения - никогда в открытых файлах. Надеюсь запомнил.

Шаг 8. Проверяешь

openclaw doctor

Всё зелёное - поздравляю, идёшь в 7.2.

Вариант 3. Windows (VPS)

Что понадобится перед стартом:- Компьютер с Windows 10/11- Арендованный VPS с Ubuntu 22.04 или 24.04 (минимум 2 vCPU, 4 GB RAM, 40 GB SSD)

Hetzner - https://www.hetzner.com/cloud/DigitalOcean - https://www.digitalocean.com/ ,Aeza - https://aeza.net/,Vultr - https://www.vultr.com/или любой другой

- IP-адрес сервера, логин и пароль от него (выдаёт хостинг после создания)- API-ключ от провайдера модели (или OAuth)- Аккаунт в Telegram и бот от @BotFather- Около 30–60 минут свободного времени

VPS - это удалённый Linux-сервер. Ты управляешь им с Windows через SSH. Сам сервер всегда Linux, разница только в том, как ты к нему подключаешься.

Шаг 1. Генерируешь SSH-ключ на своей Windows-машине

Открываешь PowerShell (обычный, не от администратора) и вводишь:

ssh-keygen -t ed25519 -C "openclaw-vps"

-t ed25519 - тип ключа, современный и надёжный алгоритм. -C добавляет комментарий чтобы потом понять какой ключ для чего. Команда спросит куда сохранить - жмёшь Enter (сохранит в C:\Users\твоё_имя\.ssh\id_ed25519). Потом спросит пароль для ключа - можешь поставить или оставить пустым.

Смотришь на содержимое публичного ключа - он понадобится чуть позже:

type $env:USERPROFILE\.ssh\id_ed25519.pub

type - команда для вывода содержимого файла в Windows. Копируешь весь вывод - это твой публичный ключ, длинная строка начинающаяся с ssh-ed25519.

Шаг 2. Подключаешься к VPS по паролю в первый раз

ssh root@IP_твоего_сервера

Заменяешь IP_твоего_сервера на реальный IP из панели хостинга. Система спросит Are you sure you want to continue? - пишешь yes и жмёшь Enter. Потом вводишь пароль который дал хостинг. Пароль не отображается при вводе - это нормально.

Шаг 3. Безопасность перед установкой

Ты сейчас под root - самым привилегированным пользователем. Первое что делаешь это создаёшь нормального пользователя и закрываешь root-доступ.

Обновляешь систему и ставишь утилиты безопасности:

apt update && apt upgrade -y apt install -y curl gnupg lsb-release jq fail2ban ufw

fail2ban - это программа, которая автоматически банит IP-адреса после нескольких неудачных попыток входа. Классическая защита от брутфорса.

Создаёшь нового пользователя:

adduser openclaw --gecos "" --disabled-password usermod -aG sudo openclaw passwd openclaw

adduser создаёт пользователя. --gecos "" пропускает вопросы об имени и прочем. --disabled-password создаёт без пароля - мы зайдём по ключу. usermod -aG sudo добавляет в группу sudo - сможет выполнять команды администратора. passwd openclaw - задаёшь пароль (понадобится в одном месте ниже).

Создаёшь папку для SSH-ключа нового пользователя:

mkdir -p /home/openclaw/.ssh chmod 700 /home/openclaw/.ssh

mkdir -p создаёт папку и все родительские папки если их нет. chmod 700 выставляет права - только владелец может читать и писать. SSH требует именно таких прав, иначе откажется работать.

Открываешь файл для публичного ключа:

nano /home/openclaw/.ssh/authorized_keys

Вставляешь тот длинный публичный ключ который скопировал на шаге 1. Сохраняешь: Ctrl+O, Enter, Ctrl+X.

Выставляешь правильные права:

chmod 600 /home/openclaw/.ssh/authorized_keys chown -R openclaw:openclaw /home/openclaw/.ssh

chmod 600 - только владелец может читать файл. chown -R openclaw:openclaw - передаёт владение всей папкой пользователю openclaw.

Разрешаешь sudo без пароля:

echo "openclaw ALL=(ALL) NOPASSWD:ALL" | tee /etc/sudoers.d/openclaw

Отключаешь вход по паролю и root-логин:

sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config systemctl restart ssh

PermitRootLogin no - root не может зайти по SSH. PasswordAuthentication no - вход только по ключу, пароли не принимаются.

Настраиваешь DNS:

cp /etc/systemd/resolved.conf /etc/systemd/resolved.conf.bak cat > /etc/systemd/resolved.conf <

Ограничиваешь логи:

sed -i 's/^#SystemMaxUse=.*/SystemMaxUse=100M/' /etc/systemd/journald.conf sed -i 's/^SystemMaxUse=.*/SystemMaxUse=100M/' /etc/systemd/journald.conf systemctl restart systemd-journald journalctl --vacuum-size=100M

Настраиваешь firewall:

ufw allow ssh ufw allow 80/tcp ufw allow 443/tcp echo "y" | ufw enable

Порт 18789 (Gateway OpenClaw) не открываешь - доступ к нему только через SSH-туннель.

Настраиваешь fail2ban:

cat < /etc/fail2ban/jail.local [DEFAULT] banaction = ufw maxretry = 3 findtime = 3600 bantime = 86400 [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log EOF systemctl restart fail2ban

maxretry = 3 - банит после 3 неудачных попыток. findtime = 3600 - считает попытки за последний час. bantime = 86400 - бан на 24 часа.

Шаг 4. Переподключаешься под новым пользователем

Открываешь новое окно PowerShell и проверяешь что новый пользователь заходит по ключу:

ssh openclaw@IP_твоего_сервера

Если зашёл без пароля - ключ работает. Старое окно с root-сессией можно закрыть.

Шаг 5. Ставишь Node.js и OpenClaw

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash source ~/.bashrc nvm install 24 nvm use 24 node -v curl -fsSL https://openclaw.ai/install.sh | bash openclaw onboard --install-daemon

--install-daemon на VPS обязателен - поднимает systemd-сервис который держит gateway живым 24/7 и перезапускает при падении.

Шаг 6. Canvas Host - обязательно

На VPS это критично. Открытый порт 18789 в интернете - реальная дыра:

nano ~/.openclaw/openclaw.json

Меняешь 0.0.0.0 на 127.0.0.1. Сохраняешь. Перезапускаешь:

systemctl --user restart openclaw-gateway

Шаг 7. Доступ к dashboard через SSH-туннель

Раз порт закрыт наружу, dashboard открываешь так. На своей Windows-машине в отдельном окне PowerShell:

ssh -N -L 18789:127.0.0.1:18789 openclaw@IP_твоего_сервера

-N - не запускает никакую команду, просто держит туннель. -L 18789:127.0.0.1:18789 - пробрасывает порт 18789 с сервера на твой локальный порт 18789. Пока окно открыто - заходишь в браузере на http://localhost:18789 и видишь dashboard. Закрыл окно - туннель упал.

Шаг 8. Финальная проверка

openclaw doctor systemctl --user status openclaw-gateway

openclaw doctor - диагностика окружения и конфигов. systemctl --user status - показывает статус сервиса, должно быть active (running). Всё зелёное - поздравляю, база поднята.

Вариант 4) Linux / Mac (VPS)

Что понадобится перед стартом:- Компьютер с Linux или macOS- Арендованный VPS с Ubuntu 22.04 или 24.04 (минимум 2 vCPU, 4 GB RAM, 40 GB SSD)

Hetzner - https://www.hetzner.com/cloud/DigitalOcean - https://www.digitalocean.com/ ,Aeza - https://aeza.net/,Vultr - https://www.vultr.com/

- IP-адрес сервера, логин и пароль от него- API-ключ от провайдера модели (или OAuth)- Аккаунт в Telegram и бот от @BotFather- Около 30–60 минут свободного времени

Самый правильный вариант для рабочего контура. Всё то же самое что в Windows-VPS, только подключение и генерация ключа делаются нативно без PowerShell.

Шаг 1. Генерируешь SSH-ключ на своей машине

Открываешь терминал и вводишь:

ssh-keygen -t ed25519 -C "openclaw-vps"

Жмёшь Enter на вопрос о расположении (сохранится в ~/.ssh/id_ed25519). Пароль на ключ - опционально.

Шаг 2. Подключаешься к VPS в первый раз

ssh root@IP_твоего_сервера

Пишешь yes на вопрос о подключении, вводишь пароль от хостинга.

Шаг 3. Безопасность перед установкой

Обновляешь систему:

apt update && apt upgrade -y apt install -y curl gnupg lsb-release jq fail2ban ufw

Создаёшь пользователя:

adduser openclaw --gecos "" --disabled-password usermod -aG sudo openclaw passwd openclaw

Создаёшь папку для ключей:

mkdir -p /home/openclaw/.ssh chmod 700 /home/openclaw/.ssh nano /home/openclaw/.ssh/authorized_keys

Тут вставляешь публичный ключ. На своей машине открываешь новое окно терминала и смотришь его:

cat ~/.ssh/id_ed25519.pub

Копируешь вывод, вставляешь в nano на сервере. Сохраняешь: Ctrl+O, Enter, Ctrl+X.

Выставляешь права:

chmod 600 /home/openclaw/.ssh/authorized_keys chown -R openclaw:openclaw /home/openclaw/.ssh

Sudo без пароля:

echo "openclaw ALL=(ALL) NOPASSWD:ALL" | tee /etc/sudoers.d/openclaw

SSH hardening:

sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config systemctl restart ssh

DNS:

cp /etc/systemd/resolved.conf /etc/systemd/resolved.conf.bak cat > /etc/systemd/resolved.conf <

Логи:

sed -i 's/^#SystemMaxUse=.*/SystemMaxUse=100M/' /etc/systemd/journald.conf sed -i 's/^SystemMaxUse=.*/SystemMaxUse=100M/' /etc/systemd/journald.conf systemctl restart systemd-journald journalctl --vacuum-size=100M

firewall:

ufw allow ssh ufw allow 80/tcp ufw allow 443/tcp echo "y" | ufw enable

Fail2ban:

cat < /etc/fail2ban/jail.local [DEFAULT] banaction = ufw maxretry = 3 findtime = 3600 bantime = 86400 [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log EOF systemctl restart fail2ban

Шаг 4. Переподключаешься под новым пользователем

Новое окно терминала на своей машине:

ssh openclaw@IP_твоего_сервера

Если зашёл без пароля - ключ работает. Можно добавить alias в ~/.ssh/config на своей машине для удобства:

Host openclaw-vps HostName IP_твоего_сервера User openclaw IdentityFile ~/.ssh/id_ed25519

Тогда подключаешься просто:

ssh openclaw-vps

Шаг 5. Ставишь Node.js и OpenClaw

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash source ~/.bashrc nvm install 24 nvm use 24 node -v curl -fsSL https://openclaw.ai/install.sh | bash openclaw onboard --install-daemon

Шаг 6. Canvas Host

nano ~/.openclaw/openclaw.json

Меняешь 0.0.0.0 на 127.0.0.1. Сохраняешь. Перезапускаешь:

systemctl --user restart openclaw-gateway

Шаг 7. SSH-туннель для dashboard

На своей машине в отдельном окне терминала:

ssh -N -L 18789:127.0.0.1:18789 openclaw@IP_твоего_сервера

Или если добавил alias:

ssh -N -L 18789:127.0.0.1:18789 openclaw-vps

Пока окно открыто - dashboard доступен на http://localhost:18789.

Шаг 8. Финальная проверка

openclaw doctor systemctl --user status openclaw-gateway

Статус active (running) и всё зелёное в докторе - база поднята, идёшь в 7.2.

Общее правило для всех четырёх вариантов: не пропускай шаги безопасности и не усложняй на старте. Поднял минимальный рабочий контур, проверил openclaw doctor, убедился что gateway живёт - и только потом добавляешь скиллы, каналы и автоматизации. Иначе при первой же проблеме не поймёшь где именно все нахуярилось.

Не радуйся раньше времени. То что установка завершилась без хуйни и красных строк ещё ничего не значит. Сейчас проверяешь что система реально работает, а не просто притворяется.

Шаг 1. Запускаешь диагностику

openclaw doctor

Это встроенная проверка всего окружения. Она пройдётся по версии Node, конфигам, зависимостям и базовым соединениям. Если всё зелёное, можно с радостью и удовлетворением собой выдохнуть. Если есть красные строки, не идёшь дальше пока не починишь каждую из них. Тащить проблему в настройку это гарантированный пиздец потом.

Шаг 2. Проверяешь что gateway живёт

На локалке:

openclaw status

На VPS:

systemctl --user status openclaw-gateway

Должно быть active (running). Если написано inactive, failed или вообще ничего нет, gateway не поднялся. Смотришь логи чтобы понять почему:

journalctl --user -u openclaw-gateway -n 50

-n 50 показывает последние 50 строк лога. Там будет написано что именно упало и почему.

Шаг 3. Пишешь боту первое сообщение

Открываешь Telegram, находишь своего бота и пишешь что-нибудь простое, хоть «привет». Если ответил, система живая. Если тишина больше минуты, что-то не так с каналом или gateway не держит соединение и надо снова страдать проверяя все.

Шаг 4. Открываешь dashboard

На локалке просто открываешь в браузере http://localhost:18789.

На VPS сначала поднимаешь туннель в отдельном окне терминала:

ssh -N -L 18789:127.0.0.1:18789 openclaw@IP_твоего_сервера

Потом открываешь http://localhost:18789 в браузере. Если видишь интерфейс OpenClaw, всё поднялось как надо.

Прошёл все четыре шага без красных строк и бот ответил? Поздравляю, система живая. Теперь идёшь дальше.

Это не теория. Это конкретные ошибки которые стабильно ловят многие новички при установке. Каждая из них стоила кому-то от 30 минут до нескольких часов. Тебе хватит пары минут чтения чтобы не наступить на те же грабли. Постарался разобрать все возможные.

Ошибка 1. Не та версия Node.js

Самая частая. Ставят Node через apt и получают версию 18 или 20, а OpenClaw требует минимум 22. Выглядит это примерно так:

npm ERR! notsup Required: {"node":">=22.0.0"} npm ERR! notsup Actual: {"node":"18.17.1"}

Фикс простой. Удаляешь старый Node и ставишь через nvm как написано в 7.1:

nvm install 24 nvm use 24 node -v

Проверяешь что вернуло v24.x.x и только потом запускаешь установку заново.

Ошибка 2. Проблемы с PATH

Поставил nvm, поставил Node, вводишь openclaw и получаешь command not found. Это значит терминал не знает где искать команду. Чаще всего лечится одной строкой:

source ~/.bashrc

На macOS если используешь zsh:

source ~/.zshrc

Если не помогло, закрываешь терминал полностью и открываешь заново. В 90% случаев это решает проблему.

Ошибка 3. Onboarding упал посередине

Нажал Ctrl+C в середине openclaw onboard или терминал отвалился по таймауту. Теперь конфиги наполовину заполнены и система ведёт себя странно. Не пытайся чинить руками. Просто запускаешь onboarding заново:

openclaw onboard

Он корректно перезапишет всё что нужно. Onboarding можно гонять сколько угодно раз, ничего страшного не случится.

Ошибка 4. Gateway не стартует

Установка прошла, openclaw doctor зелёный, но gateway не поднимается. Первым делом смотришь логи:

journalctl --user -u openclaw-gateway -n 100

-n 100 показывает последние 100 строк, там обычно видно что именно сломалось. Чаще всего одна из двух причин.

Первая, занят порт 18789. Найди что его занимает и убей процесс:

sudo lsof -i :18789 sudo kill -9 PID_процесса

lsof -i :18789 показывает какой процесс держит порт. В выводе будет колонка PID, это номер процесса. Его и подставляешь в kill -9. -9 это принудительное завершение без вопросов.

Вторая причина, проблема с конфигом. Запускаешь openclaw doctor и смотришь на что именно он ругается.

Ошибка 5. Canvas Host остался на 0.0.0.0

Забыл поменять в конфиге после установки. На локалке это просто плохая привычка. На VPS это реальный пиздец в безопасности, dashboard открыт наружу в интернет. Проверяешь:

cat ~/.openclaw/openclaw.json | grep bind

cat выводит содержимое файла. grep bind фильтрует вывод и показывает только строку с bind. Если видишь 0.0.0.0, идёшь в конфиг и меняешь:

nano ~/.openclaw/openclaw.json

Меняешь 0.0.0.0 на 127.0.0.1, сохраняешь Ctrl+O, Enter, Ctrl+X. Перезапускаешь gateway:

openclaw restart

Или на VPS:

systemctl --user restart openclaw-gateway

Ошибка 6. WSL2 глюки на Windows

Бывает что WSL2 не стартует нормально после обновления Windows или команды зависают без видимой причины. Первый шаг:

wsl --shutdown wsl

wsl --shutdown полностью гасит все WSL-процессы. После этого открываешь Ubuntu заново. Если не помогло, перезагружаешь машину полностью. В 80% случаев это решает все WSL-странности без каких-либо дополнительных манипуляций.

Ошибка 7. Ошибки прав на SSH-файлах

На VPS после настройки ключей не можешь зайти по SSH и получаешь Permission denied (publickey). Почти всегда это неправильные права на файлы. Заходишь на сервер по паролю пока это ещё работает и правишь:

chmod 700 /home/openclaw/.ssh chmod 600 /home/openclaw/.ssh/authorized_keys chown -R openclaw:openclaw /home/openclaw/.ssh

chmod 700 - только владелец может читать и писать папку. chmod 600 означает только владелец может читать файл с ключами. chown -R передаёт владение всей папкой пользователю openclaw. После этого пробуешь снова зайти по ключу.

Иногда проще начать заново. Сам я откатывался 2 раза, и только после этого все успешно установил. Особенно если конфиги поломаны наполовину и непонятно что вообще произошло. Не трать час на отладку того что не понимаешь, снеси и поставь заново по гайду. Установка занимает 30-60 минут, а во второй раз в разы меньше.

Откат на локалке (Linux / Mac / WSL)

Останавливаешь gateway если он запущен:

openclaw stop

Если поднимал через daemon:

systemctl --user stop openclaw-gateway systemctl --user disable openclaw-gateway

stop останавливает сервис. disable убирает его из автозапуска чтобы он не поднялся сам при следующей перезагрузке.

Удаляешь OpenClaw:

npm uninstall -g openclaw

npm uninstall -g удаляет глобально установленный пакет. После этого команда openclaw перестанет работать.

Удаляешь конфиги и все данные:

rm -rf ~/.openclaw

rm -rf удаляет папку со всем содержимым без вопросов и без возможности восстановить. Будь аккуратен с этой командой. Если хочешь сохранить память агента и настройки, сначала делаешь backup:

cp -r ~/.openclaw ~/openclaw_backup

cp -r копирует папку рекурсивно со всем содержимым. После этого можно смело удалять оригинал и ставить заново.

Откат на VPS

Если хочешь переустановить только OpenClaw оставив сервер нетронутым:

systemctl --user stop openclaw-gateway systemctl --user disable openclaw-gateway npm uninstall -g openclaw rm -rf ~/.openclaw

Сервер, пользователь и все настройки безопасности из раздела 7.1 остаются. Сносишь только OpenClaw и его данные. Потом ставишь заново начиная с шага 5 из 7.1.

Если хочешь начать вообще с нуля и снести весь сервер, просто удаляешь его в панели хостинга и создаёшь новый. На VPS за 5-10 евро в месяц это реально самый адекватный вариант когда всё совсем пошло по пизде и непонятно где именно.

Если что-то сломалось и ты уже 30 минут пытаешься починить не понимая причины, не трать ещё час. Сноси и ставь заново по гайду. Ну а мы идем дальше.

Пройдя мощнейший седьмой пункт мы наконец то разберемся с первой пользой. Самая частая беда после установки, это пытаться включить все возможное. Накачать двести миллионов скиллов и пойти общаться с агентом, думая что все круто. Но, было бы все так просто, я бы и не писал эту статью. Сначала собираешь минимально рабочий контур, проверяешь что агент отвечает стабильно и не сыпется на каждом шаге, и только потом расширяешь систему. Этот раздел как раз про такой подход, чтобы в первый день получить реальную пользу, а не ебаться со списком проблем.

Как не утонуть в настройках?

В первый день тебе не нужно знать все, лично я нихуя не знал и изучал все маленькими шагами, чего и вам совету. Поэтому режем все лишнее и оставляем только базу - один агент, одна модель, один канал общения, один простой сценарий. Любая новая настройка добавляется только после проверки предыдущей. Если после изменения стало хуже, откатываешь сразу и не копишь ошибки слоями. Такой режим кажется медленным, понимаю, но это по факту лучший и самый быстрый путь к хорошей и поставленной системе.

Первый минимальный рабочий сценарий

Не начинай с чего-то сложного. Первая задача должна быть простой и понятной, чтобы ты видел что система реально работает, а не просто отвечает на привет и пока. Вот несколько рабочих сценариев с которых удобно стартовать, я стартовал с первого (с ресерча)

Сценарий 1. Ресёрч по теме

Пишешь агенту в Telegram:

Сделай ресёрч по теме [твоя тема]. Мне нужно: краткое объяснение что это такое, 3-5 ключевых тезиса, и список из 3 источников которые стоит почитать. Формат - структурированный текст, без воды.

Агент уйдёт думать, потом вернётся с результатом. Смотришь на качество и структуру ответа. Также можешь поправить совместно с ним. Я например просил писать в моем стиле и формате который мне нужен. Тут все зависит уже от ваших желаний.

Сценарий 2. Черновик поста

Напиши черновик поста для Telegram на тему [твоя тема]. Аудитория — [кто читает]. Тон — [разговорный / экспертный / с юмором]. Длина — примерно 500-800 символов. Без хэштегов.

Здесь сразу видно насколько агент держит стиль и формат. Если ответ похож на шаблонный AI-текст, значит надо прокачивать memory и системный промпт - об этом в разделах 10 и дальше. Как совет, загрузите ему свои посты, чтобы он проанализировал стиль и подачу. После чего повторите вопрос - вы ахуеете от результата (наверное)

Сценарий 3. Утренняя сводка

Это чуть сложнее, но очень показательно. Пишешь:

Каждый день в 9:00 отправляй мне короткую сводку: что нужно сделать сегодня, какие задачи висят с прошлой недели, и один вопрос который поможет сфокусироваться на главном. Данные бери из memory.

Если cron настроен и memory заполнена хоть чем-то, в 9 утра придёт первое автоматическое сообщение. Вот тут обычно люди понимают что это не просто чатик. А уже какой никакой, но помощник.

Запустил один из этих сценариев и получил нормальный результат? Отлично. Система работает, можно идти дальше и усложнять. Если что-то пошло не так, возвращаешься в раздел 7.4 и смотришь на типовые ошибки, я очень надеюсь что у тебя все получилось.

Первые команды и тесты

Вот базовый набор команд которые стоит прогнать сразу после установки. Не потому что это интересно, а потому что это даёт понимание что вообще происходит внутри системы.

Проверка статуса

openclaw status

Показывает запущен ли gateway и в каком состоянии. Если всё ок, увидишь что-то вроде Gateway: running. Если нет, смотришь логи.

Диагностика окружения

openclaw doctor

Уже знаешь эту команду из раздела 7.3. Запускай её каждый раз когда что-то ведёт себя странно. Это первое что нужно сделать перед тем как начинать гуглить проблему.

Просмотр логов в реальном времени

journalctl --user -u openclaw-gateway -f

-f означает follow, то есть лог обновляется в реальном времени пока ты смотришь. Удобно когда отправляешь сообщение боту и хочешь видеть что происходит внутри в этот момент. Выйти из режима просмотра - Ctrl+C.

Перезапуск gateway

На локалке:

openclaw restart

На VPS:

systemctl --user restart openclaw-gateway

Перезапуск нужен после любых изменений в конфиге. Без перезапуска изменения не применяются, классическая ошибка новичков. (у меня такая же была)

Просмотр конфига

cat ~/.openclaw/openclaw.json

Показывает текущий конфиг целиком. Если хочешь посмотреть только конкретную настройку, добавляешь grep:

cat ~/.openclaw/openclaw.json | grep bind cat ~/.openclaw/openclaw.json | grep model

Тест памяти

Пишешь агенту в Telegram что-нибудь личное, например своё имя и чем занимаешься. Потом через минуту спрашиваешь:

Как меня зовут и чем я занимаюсь?

Если ответил правильно, memory работает, ура. Если не помнит, значит что-то с настройкой memory - разбираем это в разделе 10.

Тест web search

Если подключил Brave API, проверяешь что поиск работает:

Найди последние новости про OpenAI за сегодня

Агент должен уйти в поиск и вернуться с реальными свежими данными, а не с тем что у него в голове. Если вернул что-то актуальное, web search подключён и работает.

Что включить сразу?

Как я уже и писал, не нужно включать все подряд. Но вот мой топ вещей, который я рекомендую включить сразу.

Web search через Brave

Это первое что стоит подключить. Без web search агент работает только на том что у него в голове, а голова у него с датой обрезки. С web search он может гуглить, проверять факты и давать актуальные данные.

Идёшь на api-dashboard.search.brave.com, регистрируешься, берёшь бесплатный ключ (выбирай Free, не Free AI). Потом в терминале:

openclaw configure --section web

Onboarding спросит ключ и включит web search. После этого проверяешь тестом из раздела 8.3.

Memory

Memory включена по умолчанию, но её надо настроить чтобы она реально работала. Минимум что нужно сделать сразу - дать агенту базовый контекст о себе. Пишешь в Telegram:

Запомни: меня зовут [имя]. Я занимаюсь [чем занимаешься]. Мои основные задачи это [список]. Мой стиль общения [разговорный / формальный / с матом]. Сохрани это в долгосрочную память.

Агент сохранит это в long-term memory и будет использовать в каждом следующем сеансе. Без этого он каждый раз начинает с нуля как будто видит тебя впервые.

Системный промпт (SOUL.md)

Это файл, который задает характер агента. Если его не трогать, агент будет отвечать как безликий бот, вежливо, шаблонно и без характера. Открываешь файл:

nano ~/.openclaw/SOUL.md

И прописываешь туда базу, что то типо:

Ты мой личный ассистент. Общаешься коротко и по делу. Не используешь воду и шаблонные фразы. Если что-то непонятно — спрашиваешь уточнение, а не додумываешь сам. Перед любым действием описываешь план и ждёшь подтверждения.

Сохраняешь, перезапускаешь gateway и проверяешь что поведение реально поменялось, а не осталось как было.

Что пока не трогать?

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

На этом этапе многие сами себе ломают результат. Ставят первую попавшуюся модель, ждут от нее вообще все подряд, потом удивляются почему все идет по пизде. Запомните, модель это инструмент под конкретную задачу. Если подобрать мозг правильно, агент работает стабильно и дает пользу. Если подобрать криво, ты просто сжигаешь деньги, время и нервы. В пунктах далее я дам личную рекомендацию под модели и задачи, с которыми они справляются лучше всего.

Как выбирать модель под задачу?

Правильно выбрать модель под конкретную задачу это уже половина победы. Я серьезно. Моделей существует бесконечное количество, но вот мой личный топ 3. Начну с наименования трех китов в сфере ИИ и плавно перейду к плюсам/минусам:

ChatGPT - сначала я буду расписывать варианты подключения, а после уже плюсы и минусы как для связки агентов, так и для одиночного. Итак первый вариант - через OAuth от ChatGPT Go/Pro/Plus.Второй вариант - по API ключу, тут объяснять не буду, все что вам нужно это вставить API в терминал и все готово.

В чем же плюсы ChatGPT:

Минусы ChatGPT

Сам подключил ChatGPT для агента и пользуюсь достаточно долго.

Claude - второй кит и, пожалуй, самый мощный инструмент для написания кода на текущий момент. Для Claude один рабочий вариант подключения - anthropic API Key. Генерируете ключ в консоли Anthropic, пополняете баланс и платите только за потраченные токены. OAuth через сессию для Claude официально закрыт с апреля 2026 - используй только API Key, иначе рискуешь получить сломанный воркфлоу

Плюсы Claude:

Минусы Claude:

Если для одиночного агента, то Claude является лучшим кодером и собеседником. В связке же его лучше ставить как некого контроллера.

Третий кит - Gemini. Это мощный инструмент для работы с большими объемами данных. Также от себя отмечу, что это очень сильный инструмент в плане анализа какой либо ситуации. Также два варианта подключения. Первый - Google Gemini API key. Стандартный способ. Необходимо получить ключ в Google AI Studio и вставить его в терминал.Второй - Google Gemini CLI OAuth: Метод авторизации напрямую через Google-аккаунт в консоли.

Плюсы Gemini

Минусы Gemini

Если использовать Gemini для одного агента, то он идеальный для поиска инфы в огромной базе знаний. В связке я бы его использовал как вспомогательного агента для простых и быстрых задач.

Дешево, быстро, умно, где мне найти баланс?

Вот здесь люди чаще всего ловят лютый пиздец ожиданий. Все хотят сразу дешево, быстро и умно, но в живой системе так почти никогда не работает, как ни крути. Обычно ты можешь нормально закрыть только две стороны из трех, третья в любом случае просядет. Дешево и быстро чаще всего дает среднее качество и косяки на длинной дистанции. Умно и быстро почти всегда бьет по бюджету, иногда очень больно. Умно и дешево обычно работает, но медленнее, и если поток большой, начинаешь заебываться от задержек. Поэтому рабочий подход такой, для массовой рутины держишь быстрый и недорогой слой, а для критичных задач, где ошибка стоит денег, времени или репутации, включаешь более сильную модель.

Когда нужна связка моделей?

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

Практические связки под разные кейсы

В контенте и медиа быстрая модель делает структуру, черновик и варианты подач, а сильная доводит смысл, чистит логику и делает финальный текст без мусора. В коде и автоматизации базовая модель пишет каркас, команды и первичную реализацию, а сильная модель делает ревью, проверяет крайние случаи и безопасность, чтобы потом не разгребать продовые косяки. В крипто ресерче легкая модель собирает новости, цифры и первичную сводку, а сильная модель уже формирует выводы, риски и внятную позицию. В саппорте и рутине дешёвая модель закрывает поток типовых запросов, а усиленная включается только на нестандарт, эскалации и чувствительные решения. Главный вывод здесь один, не ищи волшебную универсальную модель, собирай ахуенную систему под любые свои действия.

Давай быстро и по полочкам поясню, почему это важно. Если память не обслуживать, агент со временем начинает тупить, путать контекст и выдавать кривые решения. Сначала это выглядит как мелкая фигня, потом превращается в системный пиздец, где каждое второе действие надо перепроверять руками. Поэтому память надо вести как рабочую систему, а не как свалку заметок. Ниже нормальный и рабочий контур. Часть инфы также беру со своего тгк (так как делал посты об этом). Постараюсь максимально кратко и полезно выдать всю инфу.

Два слоя памяти, long term и daily

Память делится на два уровня и это не обсуждается. Long term это MEMORY.md, туда идет только то, что должно жить долго - правила, ключевые решения, стабильные предпочтения.Daily это файлы вида memory/YYYY-MM-DD.md, туда пишется текущий потокчто сделали, что решили, где были ошибки, что нужно проверить дальше.Если мешать все в одну кучу, агент начинает путать постоянное с временным и потом выдает хуйню.

Структура файлов

Сразу собираешь каркас, чтобы не ебаться потом.

Linux macOS

mkdir -p memory touch MEMORY.md touch memory/$(date -u +%F).md

Windows PowerShell

New-Item -ItemType Directory -Path memory -Force | Out-Null New-Item -ItemType File -Path MEMORY.md -Force | Out-Null $today = (Get-Date).ToUniversalTime().ToString("yyyy-MM-dd") New-Item -ItemType File -Path ("memory/{0}.md" -f $today) -Force | Out-Null

Эта структура дает такой порядок - долгосрочное лежит отдельно, дневной шум отдельно, и агенту легче работать по слоям.

Шаблон записи

Чтобы память реально помогала, запись должна быть одинаковой по форме. Это поможет в том, что ты будешь понимать что имел ввиду через долгое время.

Linux macOS

printf "Контекст:\nРешение:\nПочему:\nСледующий шаг:\n" >> memory/$(date -u +%F).md

Windows PowerShell

$today = (Get-Date).ToUniversalTime().ToString("yyyy-MM-dd") @" Контекст: Решение: Почему: Следующий шаг: "@ | Add-Content -Path ("memory/{0}.md" -f $today)

Готово, ты молодец! Бежим дальше.

Ежедневная рутина обслуживания

Посоветовал бы сначала делать это в ручную, чтобы конкретно разобраться с внутренностями. После чего, берешь и делегируешь эту рутину своему же агенту. Удобно? Удобно.Каждый вечер делаешь короткий, но обязательный проход по памяти. Без этого через пару дней начинается печалька, а именно - важное тонет в мелочи, решения теряются, агент начинает путать старый и новый контекст. Эта рутина занимает 5-10 минут, но именно она держит систему в тонусе и идеальном порядке.

Сначала открываешь daily файл за сегодня и быстро пробегаешь весь день от начала до конца. Смотришь не на все подряд, а на то, что реально влияет на завтра - какие задачи закрыли, какие решения приняли, где были ошибки, какие выводы получили. После этого чистишь мусор, а если конкретнее то - дубли, пустые фразы, эмоциональные заметки без пользы, временные мелочи которые уже не влияют ни на что.

Дальше фиксируешь итог дня в нормальной структуре - контекст, решение, почему так, следующий шаг. Очень важный момент, если по ходу дня вы приняли решение, которое будет жить дольше одного дня, не оставляй его только в daily. Такие вещи отдельно помечаешь как кандидаты на перенос в long term, чтобы потом занести в MEMORY.md и не потерять.

Недельная ревизия

В целом схема такая же, но расписать стоит. Раз в неделю делаешь нормальную чистку, смотришь daily, вытаскиваешь важное в MEMORY.md, находишь дубли и устаревшее.Удаление не делаешь с плеча, сначала показываешь список изменений, потом подтверждение. Быстрая проверка файлов:

Linux macOS

sed -n '1,200p' MEMORY.md sed -n '1,200p' memory/$(date -u +%F).md

Windows PowerShell

Get-Content MEMORY.md -TotalCount 200 $today = (Get-Date).ToUniversalTime().ToString("yyyy-MM-dd") Get-Content ("memory/{0}.md" -f $today) -TotalCount 200

Ошибки памяти, которые убивают качество и твои нервишки

Качество агента чаще всего умирает из за того, что ты начинаешь забивать и вести память через жопу. Сначала это незаметно, но потоооом контекст плывет, стиль скачет, решения противоречат друг другу и тд. Расписал тут пять самых популярных ошибок, не делай так!!!

Вот ты сейчас прочитал и по любому думаешь, такие глупые ошибки, но поверь, совершить их может абсолютно каждый.

Распространенные ошибки памяти.

Если говорить прямо, скиллы это то, что делает из OpenClaw не просто чатик, а рабочий инструмент под конкретные задачи. Но тут же и главный риск, в каталоге дохуя всего, и часть этого добра может быть мутной или просто бесполезной. Поэтому мой рекомендованный подход такой - самые важные штуки собираешь руками, чтобы понимать каждый файл, каждое правило и каждую команду. Тогда ты не надеешься на удачу и не ловишь потом сюрпризы с безопасностью и качеством.

Что такое скилл простыми словами

Скилл это отдельный модуль поведения агента под конкретную работу. По сути ты даешь агенту мини инструкцию, что делать, в каком порядке, с какими ограничениями и в каком формате отдавать результат. Это четкий протокол выполнения задачи. Если протокол кривой, то логично, что и результат будет кривой. Также работает и в обратную сторону.

Из чего состоит скилл?

Нормальный скилл состоит из трех частей:

Linux macOS

cd /home/openclawd/.openclaw/workspace mkdir -p skills/tg-news-digest/references touch skills/tg-news-digest/SKILL.md touch skills/tg-news-digest/references/output-format.md mkdir -p skills/tg-news-digest/scripts touch skills/tg-news-digest/scripts/clean_duplicates.py ls -R skills/tg-news-digest

Windows PowerShell

cd C:\Users\\.openclaw\workspace New-Item -ItemType Directory -Path skills/tg-news-digest/references -Force | Out-Null New-Item -ItemType File -Path skills/tg-news-digest/SKILL.md -Force | Out-Null New-Item -ItemType File -Path skills/tg-news-digest/references/output-format.md -Force | Out-Null New-Item -ItemType Directory -Path skills/tg-news-digest/scripts -Force | Out-Null New-Item -ItemType File -Path skills/tg-news-digest/scripts/clean_duplicates.py -Force | Out-Null Get-ChildItem -Recurse skills/tg-news-digest

Эти команды создают полный каркас скилла и сразу дают проверку структуры, чтобы не ловить потом тупые косяки

Минимум что должно быть видно после проверки:

Где искать скиллы?

Искать можно где угодно, но ставить без проверки нельзя. Для базы смотри официальный каталог скиллов на ClawHub и дополнительно пробивай через мой парсер, так быстрее видно что вообще есть на рынке и где пахнет хуйней. Перед установкой всегда читаешь описание, смотришь что скилл реально делает, какие файлы трогает, какие права просит и нет ли мутных шагов. Если обещаний дохуя, а механика размытая, это красный флаг. Если не понимаешь как это работает, не ставь в боевой контур. Сначала тест в изоляции, потом прод, либо сразу пиши свой скилл руками под задачу (лучший вариант).

Как ставить правильно?

Тут снова много текста и команд, но не пугайся! Постарался расписать подробно и понятно. Я уже не один раз во всей статье упоминал про ошибку ставить пачки скиллов. Читай и запоминай, сначала ставишь один скилл, проверяешь его работу, если все ок то ставишь второй, третий, восемнадцатый и так хоть сколько.

Сначала создаешь структуру скилла как в пункте 11.2. но также продублирую команды и сюда.

Linux macOS

cd /home/openclawd/.openclaw/workspace mkdir -p skills/tg-news-digest/references skills/tg-news-digest/scripts touch skills/tg-news-digest/SKILL.md touch skills/tg-news-digest/references/output-format.md touch skills/tg-news-digest/scripts/clean_duplicates.py

Windows PowerShell

cd C:\Users\\.openclaw\workspace New-Item -ItemType Directory -Path skills/tg-news-digest/references -Force | Out-Null New-Item -ItemType Directory -Path skills/tg-news-digest/scripts -Force | Out-Null New-Item -ItemType File -Path skills/tg-news-digest/SKILL.md -Force | Out-Null New-Item -ItemType File -Path skills/tg-news-digest/references/output-format.md -Force | Out-Null New-Item -ItemType File -Path skills/tg-news-digest/scripts/clean_duplicates.py -Force | Out-Null

Потом заполняешь файлы сразу в чистом формате.

Linux macOS

nano skills/tg-news-digest/SKILL.md nano skills/tg-news-digest/references/output-format.md

Windows PowerShell

notepad skills/tg-news-digest/SKILL.md notepad skills/tg-news-digest/references/output-format.md

В SKILL.md вставляешь рабочий шаблон.

--- name: tg-news-digest description: Собирает новости ИИ за последние 24 часа и выдает короткий Telegram дайджест с источниками. --- # tg-news-digest Перед началом прочитай references/output-format.md Шаги 1. Собери новости только за последние 24 часа 2. Удали дубли 3. Оставь только проверяемые источники 4. Сформируй короткую выжимку 5. Отдай результат в формате из references/output-format.md Жесткие правила - не выдумывать факты - не давать новость без ссылки - не выходить за окно 24 часа

В references/output-format.md фиксируешь единый вид результата.

Дата Источник Что произошло Почему важно Ссылка

После сохранения сразу проверяешь, что структура реально на месте.

Linux macOS

ls -R skills/tg-news-digest

Windows PowerShell

Get-ChildItem -Recurse skills/tg-news-digest

Дальше прогоняешь один живой кейс 2-3 раза и смотришь на повторяемость. Если скилл стабильно выдает нужный результат, оставляешь в бою. Если формат плывет, логика тупит или пользы ноль, правишь и тестишь заново, либо сносишь нахуй без сожалений.

Финально фиксируешь рабочую версию в git, чтобы откат делался за минуту.

git add skills/tg-news-digest git commit -m "Add tg-news-digest skill"

Как проверить что реально установилось?

Вот как раз таки тут многие и проебываются. Увидели что файл создался и думают, что скилл работает. Нет, брат, это только начало. Проверка установки обязательна, так ты проверяешь, что скилл реально в строю и готов ебашить (при этом делает это стабильно и круто). Поехали расскажу.

Сначала проверяешь файловую базу, чтобы не искать потом баги в пустоте. Должны быть три ключевые точки - SKILL.md, references, при необходимости scripts. Если чего-то нет, дальше тестить просто не имеет смысла.

Linux macOS

ls -R skills/tg-news-digest

Windows PowerShell

Get-ChildItem -Recurse skills/tg-news-digest

Дальше делаешь ручную валидацию SKILL.md. Проверяешь глазами без лени вот такие моменты: есть name, есть description, имя в lower-case через дефисы, шаги написаны конкретно, жесткие правила прописаны четко, нет лишних полей и мусора в frontmatter.

Следом проверяешь references/output-format.md. В нем должен быть один стабильный шаблон результата, без разнобоя и фантазий. Если формат плавает, агент начнет каждый раз выдавать разную кашу, и ты задолбаешься это руками выравнивать.

Теперь главный и одновременно интересный этап - тест на реальном запросе (наконец-то бля). Прогоняешь один и тот же сценарий 2-3 раза и смотришь на три критерии: формат ответа одинаковый, правила не нарушены, результат полезный, а не декоративная хуйня.

Если один раз сработало, а два раза дало мусор, считаем что не установилось нормально. Возвращаешься в SKILL.md, правишь шаги и ограничения, тестишь заново.

Когда тест проходит стабильно, фиксируешь рабочее состояние в git, чтобы можно было откатить любой будущий фейл за минуту.

git add skills/tg-news-digest git commit -m "Validate tg-news-digest skill setup"

Все, пиздуем дальше, брат мой.

Как понять что скилл полезный?

Полезность скилла как неудивительно определяется в твоей работе. Если после установки, ты действительно экономишь время и силы для чего либо, то поздравляю, скилл работает круто. Если стало просто сложнее и шумнее, это мусор, даже если выглядит пиздец красиво.

Чтобы фиксировать это не на ощущениях, а по факту, после теста смотри логи и состояние системы

openclaw logs --follow openclaw status

Если скилл показал норм результат и ты оставляешь его в контуре, то вновь фиксируй решение в git

git add . git commit -m "Skill usefulness review passed for tg-news-digest"

Готово, теперь ты знаешь полезный ли у тебя скилл.

В OpenClaw скиллы дают огромную мощность, но вместе с этим дают и огромный риск. Один кривой или вредоносный скилл может залезть туда, куда ему вообще нехуй лезть, утянуть данные, сломать рабочий контур или тихо оставить тебе мину на потом. А я как параноик такой хуйни, безумно этого боюсь и решил поделиться с тобой, о моей гигиене безопасности. Давай читать, изучать и запоминать.

Почему 100 процентов безопасных скиллов не бывает?

Название пункта жесткое и сильное, да? Но, давай быстро объясню, почему я так считаю. Потому что скилл это не статичный текст, а рабочая логика, которая может читать файлы, дергать команды, ходить в сеть и влиять на поведение агента. Как только у тебя есть выполнение действий, у тебя всегда есть риск, вопрос только в масштабе. Поэтому фраза полностью безопасный скилл это миф для меня. Даже если скилл выглядит чисто, риск не исчезает. Автор мог ошибиться, зависимость могла обновиться с сюрпризом, внешнее API могло поменяться и еще куча иных причин. Плюс никто не отменял банальную человеческую херню, когда ты сам даешь слишком широкие права и потом ловишь пиздец из за соей же ошибки.

Что означает suspicious?

Тут уже интереснее. Suspicious это сигнал повышенного риска, что в скилле есть потенциально опасные действия, поэтому ставить его на доверии нельзя. Это не всегда значит вредоносный код, но почти всегда значит, что нужна ручная проверка перед установкой. Обычно такой флаг появляется, когда скилл просит лишние права, запускает системные команды без понятной причины, лезет в чувствительные пути или делает сетевые действия, не связанные с заявленной задачей. И вот если ты такой скилл поставишь на похуй, ойойой сколько же проблем у тебя может быть..

Когда можно ставить force?

Быстренько пройдемся, force это не удобная кнопка, а режим повышенного риска, и включать его можно только когда ты уже сделал ручной аудит, понял каждый подозрительный шаг, протестировал скилл в изоляции и заранее подготовил откат с бэкапом. Если жмешь force на эмоциях или по принципу похуй, поехали, ты сам открываешь дверь в потенциальный пиздец, где потом теряешь время, данные и нервы.

Аудит перед установкой

Перед установкой делаешь короткий, но при этом очень полезный аудит. Сначала смотришь структуру скилла и все файлы руками, чтобы понимать что он вообще запускает и куда лезет.

Linux macOS

cd /home/openclawd/.openclaw/workspace ls -R skills/tg-news-digest sed -n '1,220p' skills/tg-news-digest/SKILL.md sed -n '1,220p' skills/tg-news-digest/references/output-format.md

Windows PowerShel

cd C:\Users\\.openclaw\workspace Get-ChildItem -Recurse skills/tg-news-digest Get-Content skills/tg-news-digest/SKILL.md -TotalCount 220 Get-Content skills/tg-news-digest/references/output-format.md -TotalCount 220

Если есть scripts проверяешь и их, особенно на системные команды, сеть, чтение чувствительных путей и мутные зависимости.

Linux macOS

ls skills/tg-news-digest/scripts sed -n '1,260p' skills/tg-news-digest/scripts/clean_duplicates.py

Windows PowerShell

Get-ChildItem skills/tg-news-digest/scripts Get-Content skills/tg-news-digest/scripts/clean_duplicates.py -TotalCount 260

Песочница для тестов

Отвечу сразу на вопрос, а нахуя она вообще нужна? Любой новый или спорный скилл сначала гоняешь в песочнице, а не в бою. Это железное правило, которое спасает от тупого сценария, когда ты тестишь в проде и сам себе разъебываешь рабочую систему. Я сам так деле ни один раз и был спасен от патери всей системы. Так что, не ленитесь!!

Самый практичный вариант это отдельная папка под sandbox, отдельная ветка git и тестовые входные данные. Тогда любой косяк остается в изоляции, а не в твоем основном workflow.

Linux macOS

cd /home/openclawd/.openclaw/workspace mkdir -p sandbox/skills-test git checkout -b skill-sandbox-test cp -R skills/tg-news-digest sandbox/skills-test/ ls -R sandbox/skills-test/tg-news-digest

Windows PowerShell

cd C:\Users\\.openclaw\workspace New-Item -ItemType Directory -Path sandbox/skills-test -Force | Out-Null git checkout -b skill-sandbox-test Copy-Item -Recurse skills/tg-news-digest sandbox/skills-test/ Get-ChildItem -Recurse sandbox/skills-test/tg-news-digest

Дальше прогоняешь 2-3 тестовых запроса, смотришь логи, проверяешь что скилл не делает лишних действий, не ломает формат и не тянет подозрительные зависимости. Если все четко, переносишь в рабочий контур. Если видишь шум или странное поведение, дорабатываешь в песочнице или сносишь.

После теста фиксируешь результат или откатываешься.

Linux macOS и Windows PowerShell

openclaw status git add . git commit -m "Sandbox test for tg-news-digest skill"

Если тест провален и ветка не нужна

git checkout main git branch -D skill-sandbox-test

Идем дальше...

Минимальные права

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

Перед запуском быстро проверяешь SKILL.md и scripts на лишние команды, пути и доступы.

Linux macOS

sed -n '1,260p' skills/tg-news-digest/SKILL.md sed -n '1,260p' skills/tg-news-digest/scripts/clean_duplicates.py openclaw logs --follow

Windows PowerShell

Get-Content skills/tg-news-digest/SKILL.md -TotalCount 260 Get-Content skills/tg-news-digest/scripts/clean_duplicates.py -TotalCount 260 openclaw logs --follow

Если видишь попытки лезть в лишние директории или делать лишние действия, в работу такой скилл не пускаешь. Вот и все, видишь как все простенько и легко?

Чеклист безопасности на 2 минуты

Перед запуском любого нового скилла всегда прогоняй короткий чек безопасности, чтобы не словить полный ахуй. Если ты понимаешь что делает скилл, видишь что в нем нет мутных действий и лишних прав, то сначала тестишь в песочнице, потом даешь минимальные доступы, после установки проверяешь поведение на живом кейсе через статус и логи, и только после этого фиксируешь рабочее состояние. Ну, а если хотя бы одно из этого не закрыто, то не рекомендую допускать данный скилл к твоему рабочему процессу.

Теперь я распишу в точности, как же идеально создать свой собственный скилл под любую вашу задачу. Очень важные пункты, как в понимании системы внутри, так и в полноценной практике. Я уже писал об этом пост, так что инфа может дублироваться (извините). Читайте, запоминайте, используйте.

Почему ручной способ часто лучше?

Много людей писали мне в личку спрашивая, нахуя мне мучаться, если я могу просто скачать любой понравившийся скилл? Да потому что ручной способ дает тебе полный контроль, а в OpenClaw без контроля очень быстро начинается хуйня. Когда ты берешь готовый скилл, ты видишь красивую обертку, но не всегда понимаешь что внутри реально крутится. Сегодня он твой надежный помощник, а завтра крыса, которая крадет твои данные. Так что лучше всего собирать скилл самому. Ты сам задаешь шаги, сам фиксируешь правила, сам определяешь формат результата и сам решаешь какие права вообще можно давать. В итоге получаешь не универсальную хуйню для всех, а точный инструмент под свой процесс. В этом и вся красота ручной сборки скилла.

Каркас тот же, но смысл здесь немного другой. В этом разделе ты строишь скилл с нуля под свою задачу, а не просто ставишь готовый. База любого скилла: SKILL.md, references, scripts при необходимости.

Linux macOS

cd /home/openclawd/.openclaw/workspace mkdir -p skills/tg-news-digest/references skills/tg-news-digest/scripts touch skills/tg-news-digest/SKILL.md touch skills/tg-news-digest/references/output-format.md touch skills/tg-news-digest/scripts/clean_duplicates.py ls -R skills/tg-news-digest

Windows PowerShell

cd C:\Users\\.openclaw\workspace New-Item -ItemType Directory -Path skills/tg-news-digest/references -Force | Out-Null New-Item -ItemType Directory -Path skills/tg-news-digest/scripts -Force | Out-Null New-Item -ItemType File -Path skills/tg-news-digest/SKILL.md -Force | Out-Null New-Item -ItemType File -Path skills/tg-news-digest/references/output-format.md -Force | Out-Null New-Item -ItemType File -Path skills/tg-news-digest/scripts/clean_duplicates.py -Force | Out-Null Get-ChildItem -Recurse skills/tg-news-digest

В SKILL.md ты фиксируешь операционную логику. Что делать, в какой последовательности, какие ограничения, какой итоговый формат. Короче строишь то, что должен делать скилл, но словесно. Поехали покажу шаблончик.

--- name: tg-news-digest description: Собирает новости ИИ за последние 24 часа и выдает короткий Telegram дайджест с источниками. --- # tg-news-digest Перед началом прочитай references/output-format.md Шаги 1. Собери материалы за 24 часа 2. Удали дубли 3. Оставь только проверяемые источники 4. Сформируй короткую выжимку 5. Отдай результат строго по шаблону Жесткие правила - не выдумывать факты - не давать новость без ссылки - не выходить за окно 24 часа

Вот берешь его и делаешь под себя. Тут все просто, думаю разберется каждый.

В references держишь стабильность результата. Туда кладешь шаблон выдачи, чеклист качества, при необходимости словарь терминов и стиль вывода.

Пример output-format.md

Дата Источник Что произошло Почему важно Ссылка

Scripts же нужны когда в задаче есть повторяемая техчасть, чистка дублей, нормализация, постобработка. Если это можно надежно закрыть текстовой логикой, scripts лучше не плодить.

Ручная проверка валидности

До первого теста проверяешь всю эту тему - frontmatter валиден, имя корректное, references подключены, scripts не падают по синтаксису.

Linux macOS

sed -n '1,220p' skills/tg-news-digest/SKILL.md sed -n '1,120p' skills/tg-news-digest/references/output-format.md python3 -m py_compile skills/tg-news-digest/scripts/clean_duplicates.py

Windows PowerShell

Get-Content skills/tg-news-digest/SKILL.md -TotalCount 220 Get-Content skills/tg-news-digest/references/output-format.md -TotalCount 120 python -m py_compile skills/tg-news-digest/scripts/clean_duplicates.py

Проверил? Все четко? - Кайф, идем дальше.

Типовые ошибки при создании

Тут решил расписать все ошибки, с которыми ко мне обращились в личку. Также добавил решение, если вы столкнулись с какой то из них, просто выполняйте то, что я.

git add skills/tg-news-digest git commit -m "Refine skill logic and constraints"

Если поломал, откат

git restore skills/tg-news-digest

Ну, вот эти 3 наверное были самые популярные в моем лс. Мог бы и разобрать все возможные, но кому это было бы интересно читать? (Кстати все эти ошибки можно было решить просто спросив у агента, если он, конечно, работает)

Первый боевой тест

Как я уже и писал, первый тест на реальной задаче необходимо прогнать 2-3 раза. Глядишь формат, стиль, стабильность и полезность. Если все плохо, возвращайся в SKILL.md и правишь, а дальше все по кругу...

openclaw status openclaw logs --follow

Как версионировать свои скиллы?

Давайте сначала объясню, что это и для чего. Смотри, версионирование это по сути твоя подушка безопасности. Пока скилл один и ты его почти не трогаешь, можно жить и без этого. Но как только начинаешь дорабатывать логику, менять формат, добавлять правила, без git очень быстро начинается каша. В какой-то момент что-то ломается, а ты уже не помнишь, после какой правки это поехало. И вот тут начинается лишняя возня.

Когда скилл в git, ты работаешь спокойно. Всегда видно, что поменялось, зачем поменялось и какая версия была рабочей. Если новая правка дала плохой результат, откатился и поехал дальше. Если все ок, зафиксировал и двигаешься дальше уже от стабильной точки. Давай теперь расскажу, как это делать.

Сначала переходишь в workspace и создаешь отдельную ветку под скилл, чтобы правки не мешались с остальной работой.

Linux macOS и Windows PowerShell

cd /home/openclawd/.openclaw/workspace git checkout -b skill/tg-news-digest-v1

Если ты на Windows с другим путем, просто переходишь в свой workspace и выполняешь те же git команды.

Дальше после каждой нормальной итерации фиксируешь изменения по скиллу.

git add skills/tg-news-digest git commit -m "Create tg-news-digest skill v1"

Потом делаешь доработки, снова тестишь, и фиксируешь следующую версию.

git add skills/tg-news-digest git commit -m "Refine output format and hard constraints"

Чтобы быстро понять, что вообще менялось, смотришь историю и diff.

git log --oneline -- skills/tg-news-digest git diff HEAD~1 HEAD -- skills/tg-news-digest

Если новая правка дала хрень и нужно откатиться, есть два простых варианта. Откатить незакоммиченные изменения

git restore skills/tg-news-digest

Откатить последний коммит целиком

git reset --hard HEAD~1

Когда версия стабильная и все устраивает, пушишь ветку.

git push -u origin skill/tg-news-digest-v1

Теперь ты еще сильнее вкачался благодаря этой статье. Идем дальше.

А вот теперь мы переходим к совершенно новому. Тут уже повышаем уровень работы и делаем целую оркестрацию агентов. Когда задач становится много, схема один агент на все начинает сыпаться. Один бедный агентик просто не справляется :(. Поэтому оркестрация это ахуенный способ держать систему в рабочем состоянии, где каждый агент делает свою часть, а финал собирается по понятному протоколу. Здесь все распизжу от простого к сложному. Начинаем.

Это самый простой рабочий формат оркестрации, когда вся команда агентов живет в одном чате, но у каждого своя роль и зона ответственности. На старте это реально кайф, потому что ты не распыляешься на инфраструктуру, быстро запускаешь процесс и балдеешь. Всю инфу взял и перенес с постов в своем тгк.

Сначала собираешь каркас памяти под роли.

Linux macOS

mkdir -p memory/agents memory/chats workflows logs touch MEMORY.md touch memory/agents/main.md memory/agents/research.md memory/agents/content.md memory/agents/ops.md touch memory/chats/main-chat.md memory/chats/research-chat.md memory/chats/content-chat.md memory/chats/ops-chat.md ls -R memory

Windows PowerShell

New-Item -ItemType Directory -Path memory/agents,memory/chats,workflows,logs -Force | Out-Null New-Item -ItemType File -Path MEMORY.md -Force | Out-Null New-Item -ItemType File -Path memory/agents/main.md,memory/agents/research.md,memory/agents/content.md,memory/agents/ops.md -Force | Out-Null New-Item -ItemType File -Path memory/chats/main-chat.md,memory/chats/research-chat.md,memory/chats/content-chat.md,memory/chats/ops-chat.md -Force | Out-Null Get-ChildItem -Recurse memory

Дальше подключаешь базовые скиллы для оркестрации и диагностики, но не слепо. Важный момент - это быстрый путь, а не отмена правил безопасности из разделов 12 и 13. Любой внешний скилл сначала читаешь и проверяешь, и только потом ставишь. Если не доверяешь модулю, делай ручной аналог по схеме из 13 раздела и будь спокоен.

npx clawhub@latest install summarize npx clawhub@latest install brave-search npx clawhub@latest install openclaw-tavily-search npx clawhub@latest install log-analyzer npx clawhub@latest install healthcheck npx clawhub@latest install session-logs

Проверка после установки скиллов

Linux macOS

ls skills

Windows PowerShell

Get-ChildItem skills

Если какой-то скилл помечен как suspicious, не жмешь установку на автомате. Сначала аудит, потом песочница, и только после этого решение. --force без проверки не ебашь.

Теперь заводишь роли внутри одного чата:

Команды в чат с агентом:

Создай subagent main. Роль маршрутизация и финальная сборкаСоздай subagent research. Роль факты ссылки датыСоздай subagent content. Роль упаковка текста в мой стильСоздай subagent ops. Роль техничка логи фиксыПокажи активных subagents

После этого жестко фиксируешь единый формат ответов для всех, иначе через 20 минут будет каша и несовместимые ответы.

Формат

STATUS ok|fail OUTPUT ... RISKS ... NEXT ...

Команда в чат - передай всем агентам обязательный формат STATUS OUTPUT RISKS NEXT

Рабочий маршрут задачи в этом формате выглядит так:

Публикует только main, остальные не лезут в финальную отправку.

И последнее, ежедневный контроль, без него контекст поплывет.

Linux macOS

sed -n '1,120p' memory/agents/main.md sed -n '1,120p' memory/agents/research.md sed -n '1,120p' memory/agents/content.md sed -n '1,120p' memory/agents/ops.md

Windows PowerShell

Get-Content memory/agents/main.md -TotalCount 120 Get-Content memory/agents/research.md -TotalCount 120 Get-Content memory/agents/content.md -TotalCount 120 Get-Content memory/agents/ops.md -TotalCount 120

Чекаешь дубли задач, потерю роли, утечку контекста между агентами

Этот формат нужен, когда один чат уже не вывозит нагрузку и контекст начинает плыть. Суть простая, ты раскладываешь процесс по отдельным темам в группе и получаешь чистый конвейер без мешанины. Базовый набор тем такой, ORCH, IDEAS, RESEARCH, WRITING, EDIT, PUBLISH. ORCH управляет маршрутом, остальные темы отвечают за свой этап. Базовый набор можешь менять, я пишу так, как делал сам.

Сначала готовишь локальную память под этот формат.

Linux macOS

mkdir -p memory/chats touch memory/chats/orch.md memory/chats/ideas.md memory/chats/research.md memory/chats/writing.md memory/chats/edit.md memory/chats/publish.md ls -R memory/chats

Windows PowerShell

New-Item -ItemType Directory -Path memory/chats -Force | Out-Null New-Item -ItemType File -Path memory/chats/orch.md,memory/chats/ideas.md,memory/chats/research.md,memory/chats/writing.md,memory/chats/edit.md,memory/chats/publish.md -Force | Out-Null Get-ChildItem -Recurse memory/chats

Дальше фиксируешь роли тем. IDEAS это только гипотезы и наброски, RESEARCH только факты и ссылки, WRITING только сборка черновика по входу из RESEARCH, EDIT только редактура и стиль, PUBLISH только финал, ORCH только маршрутизация и контроль этапов. Ключевой момент в том, что каждая тема делает свою часть и не лезет в соседнюю.

В каждую тему закрепляешь два правила.

После этого задаешь единый формат ответа для всех тем, чтобы не получать разношерстные сообщения.

STATUS ok|failINPUT ...OUTPUT ...RISKS ...NEXT ...

Команда для ORCHПередай всем чатовым режимам обязательный формат STATUS INPUT OUTPUT RISKS NEXT

Чтобы не ловить спам и дубли, закрепляешь в ORCH три ограничения, один запрос это один маршрут, одна публикация это один финальный источник, без подтверждения пользователя публикации нет.

Финально делаешь ежедневный контроль памяти тем.

Linux macOS

sed -n '1,120p' memory/chats/orch.md sed -n '1,120p' memory/chats/ideas.md sed -n '1,120p' memory/chats/research.md sed -n '1,120p' memory/chats/writing.md sed -n '1,120p' memory/chats/edit.md sed -n '1,120p' memory/chats/publish.md

Windows PowerShell

Get-Content memory/chats/orch.md -TotalCount 120 Get-Content memory/chats/ideas.md -TotalCount 120 Get-Content memory/chats/research.md -TotalCount 120 Get-Content memory/chats/writing.md -TotalCount 120 Get-Content memory/chats/edit.md -TotalCount 120 Get-Content memory/chats/publish.md -TotalCount 120

Смотришь и чистишь тоже самое, что и в пункте 14.1.

Этот формат нужен, когда ты уже перерос темы и хочешь настоящую боевую схему с разделением по ботам и централизованной маршрутизацией. Суть тут такая, у тебя есть bot_orch как входная точка, и отдельные боты под этапы research, writer, qa, а между ними крутится единый backend с очередью задач. Плюс такого контура в том, что роли физически разделены, нагрузка масштабируется проще, и контроль качества можно сделать реально жестким, а не через надежду и авось. Показываю, как делал лично я.

Сначала поднимаешь каркас проекта. Команды выполняются на сервере или локалке, где будет жить система.

Linux macOS

mkdir -p tg-orchestrator/{apps,workers,schemas,logs} mkdir -p tg-orchestrator/apps/{orch,research,writer,qa} touch tg-orchestrator/.env touch tg-orchestrator/docker-compose.yml touch tg-orchestrator/apps/orch/main.py touch tg-orchestrator/apps/research/main.py touch tg-orchestrator/apps/writer/main.py touch tg-orchestrator/apps/qa/main.py

Windows PowerShell

New-Item -ItemType Directory -Path tg-orchestrator/apps,tg-orchestrator/workers,tg-orchestrator/schemas,tg-orchestrator/logs -Force | Out-Null New-Item -ItemType Directory -Path tg-orchestrator/apps/orch,tg-orchestrator/apps/research,tg-orchestrator/apps/writer,tg-orchestrator/apps/qa -Force | Out-Null New-Item -ItemType File -Path tg-orchestrator/.env,tg-orchestrator/docker-compose.yml,tg-orchestrator/apps/orch/main.py,tg-orchestrator/apps/research/main.py,tg-orchestrator/apps/writer/main.py,tg-orchestrator/apps/qa/main.py -Force | Out-Null

Дальше заполняешь .env, где фиксируешь токены ботов и подключения. Тут не халтурь, один кривой параметр и все поедет нахуй.

Как пример можешь глянуть сноску ниже.

BOT_ORCH_TOKEN=... BOT_RESEARCH_TOKEN=... BOT_WRITER_TOKEN=... BOT_QA_TOKEN=... REDIS_URL=redis://localhost:6379 DB_URL=sqlite:///./orchestrator.db

Теперь поднимаешь Redis, который будет очередью задач между этапами.

docker run -d --name redis-orch -p 6379:6379 redis:7 docker ps

После этого фиксируешь единый протокол сообщений между ботами и backend, чтобы каждый этап возвращал одинаковую структуру.

Пример payload

{ "task_id": "2026-03-27-001", "stage": "research", "status": "ok", "output": "...", "risks": "...", "next": "writer" }

Объясню на пальцах, как это все работает. Ты пишешь задачу в bot_orch, orch создает task_id, кладет задачу в queue:research, потом research отправляет в queue:writer, writer в queue:qa, qa дает ok или fail, а orch либо присылает тебе финал, либо гонит задачу на доработку. Это и есть нормальная оркестрация, где каждый занимается своим, а финальное решение контролируется через единый узел, без хаотичной хуйни между этапами.

Где что настраивать? - Давай объясню.

И обязательно контроль в проде, иначе очередь незаметно уедет в перегруз и ты потом будешь страдать.

docker ps docker logs -f redis-orch redis-cli LLEN queue:research redis-cli LLEN queue:writer redis-cli LLEN queue:qa

Готово. Давай теперь разбираться, какую же оркестрацию лучше выбрать.

Как выбрать формат под себя?

Формат выбирается по текущей нагрузке и требованиям к процессу. Если у тебя стартовый этап и умерный поток задач, достаточно формата 1. Если задач становится больше и контекст в одном чате начинает смешиваться, стоит переходить на формат 2 с разделением по темам. Формат 3 имеет смысл внедрять тогда, когда нужна строгая маршрутизация, ахуенная стабильность и backend с очередями. Вообще, советовал бы затестить каждый формат и выбрать идеальный под себя.

Оркестрация сама по себе ничего не дает, если ее не превратить в повторяемый рабочий поток. Конвейер это как раз такая схема, где каждый этап делает свою часть, результат передается дальше по протоколу, а на выходе ты получаешь готовый итог без ручной ебли на каждом шаге. Решил добавить этот пункт и дать вам сразу готовые шаблоны под контейнеры ниже.

Контент конвейер нужен для одной понятной задачи - делать публикации регулярно и в ровном качестве, которое устраивает именно вас. хема здесь жесткая и именно поэтому рабочая, идеи отвечают за направление, ресерч за фактуру, writing за сборку текста, edit за финальную чистку, publish только за выпуск. Маршрут такой, IDEAS -> RESEARCH -> WRITING -> EDIT -> PUBLISH.

Пример запуска маршрута через ORCH

TASK_ID: 2026-04-02-CONTENT-001 FROM: ORCH TO: IDEAS INPUT: Дай 5 тем под OpenClaw для аудитории новичков OUTPUT_FORMAT: STATUS/INPUT/OUTPUT/RISKS/NEXT CONSTRAINTS: Темы прикладные, без воды DEADLINE: 20m NEXT: RESEARCH

После IDEAS запускаешь RESEARCH с пометкой INPUT from IDEAS, потом WRITING на основе фактуры, потом EDIT на чистку стиля и логики, и только после этого PUBLISH. Главный принцип тут простой, в финал уходит только версия после EDIT и только с подтверждением пользователя.

Чтобы конвейер не разъехался, фиксируй такие минимальные ограничения:

один TASK_ID на одну публикацию один финальный источник для PUBLISH без источников из RESEARCH текст не идет в WRITING без проверки в EDIT публикация блокируется.

Ежедневный контроль конвейера (потом можно будет скинуть на агента, но вначале проверяй в ручную, хотя бы дня 3-4)

Linux macOS

sed -n '1,120p' memory/chats/ideas.md sed -n '1,120p' memory/chats/research.md sed -n '1,120p' memory/chats/writing.md sed -n '1,120p' memory/chats/edit.md sed -n '1,120p' memory/chats/publish.md

Windows PowerShell

Get-Content memory/chats/ideas.md -TotalCount 120 Get-Content memory/chats/research.md -TotalCount 120 Get-Content memory/chats/writing.md -TotalCount 120 Get-Content memory/chats/edit.md -TotalCount 120 Get-Content memory/chats/publish.md -TotalCount 120

Если видишь повтор тем, провал фактуры или несоблюдение роли этапа, правишь максимально быстро, а желательно сразу. Вот так быстро мы сделали контент конвейер, переходим к следующим, брат.

Новостной же конвейер нужен для быстрого сбора актуальной инфы. Супер полезно, сам пользуюсь очень активно (евридей). Маршрут схематично можно показать так SOURCES -> FILTER -> VERIFY -> SUMMARY -> QA -> PUBLISH. Давайте разберу, как же сделать.

Пример стартовой задачи:

TASK_ID: 2026-04-02-NEWS-001 FROM: ORCH TO: SOURCES INPUT: Собери 15 новостей по теме X за 24 часа OUTPUT_FORMAT: STATUS/INPUT/OUTPUT/RISKS/NEXT CONSTRAINTS: Только верифицируемые источники DEADLINE: 30m NEXT: FILTER

Критичные правила для такого конвейера:

Чтобы конвейер жил стабильно, держи как обычно короткий ежедневный контроль:

С таким контуром новости выходят быстро, аккуратно и без лишней хуйни.

Технический конвейер нужен в тот момент, когда у тебя пошли задачи с логами, падениями и непонятными ошибками, и важно реально найти причину и закрыть проблему нормально. Безумно полезный конвейер, но, конечно, не для всех найдется применение. Как обычно пропишу маршрут INTAKE -> TRIAGE -> LOGS -> DIAGNOSIS -> FIX -> VALIDATION -> REPORT. Летим дальше.

Пример запуска

TASK_ID: 2026-04-02-TECH-001 FROM: ORCH TO: TRIAGE INPUT: После обновления сервис отвечает медленно и периодически падает OUTPUT_FORMAT: STATUS/INPUT/OUTPUT/RISKS/NEXT CONSTRAINTS: Не трогать прод-конфиг без подтверждения DEADLINE: 40m NEXT: LOGS

Что по правилам? Да все просто, правила техконтура такие - фикс вносится только после диагностики, изменения делаются по одному параметру за раз, каждое действие фиксируется в логах, после применения любого фикса обязательно проводится проверка результата, а при высоком риске сначала формируется и согласуется план, и только потом выполняются изменения.

База команд контроля

openclaw status openclaw logs --follow

Если нужно зафиксировать стабильную точку после успешного фикса

git add . git commit -m "Tech pipeline fix validated"

Поддержка клиентов это последний конвейер в этой статье и по факту один из самых важных, потому что именно здесь любая кривая коммуникация сразу бьет по доверию. Входящий запрос не должен теряться, ответ не должен быть сырым, а клиент не должен ждать вечность, пока внутри кто-то разберется что делать. Давайте покажу, как это сделать.

INTAKE -> TRIAGE -> CONTEXT -> SOLUTION -> QA -> REPLY наш путь.

Пример запуска

TASK_ID: 2026-04-02-SUPPORT-001 FROM: ORCH TO: INTAKE INPUT: Клиент пишет что после обновления бот отвечает с задержкой OUTPUT_FORMAT: STATUS/INPUT/OUTPUT/RISKS/NEXT CONSTRAINTS: Без выдуманных причин, без финального ответа до QA DEADLINE: 20m NEXT: TRIAGE

Правила конвейера такие - каждый запрос идет как отдельный ticket id, финальный ответ не отправляется без triage и qa, при нехватке данных сначала уточнение, а high priority сразу уходит в эскалацию.

Быстрый контроль после прогона

openclaw status openclaw logs --follow

Если поддержка идет по этой схеме, поток не разваливается, ответы остаются ровными, а клиент получает нормальное решение без лишней хуйни. Все, с конвейерами закончили, идем дальше.

Делегирование работает, когда задачи разделены по риску и цене ошибки. Если не делегировать ничего, OpenClaw превращается в обычный чат, а нахуя нам платить за обычный чат? Нормальный путь такой, что рутину ты отдаешь агенту, критичные решения оставляешь для себя любимого. Дальше расскажу, что можно отдавать сразу, что частично, что лучше не трогать.

Что можно делегировать сразу без раздумий?

Сюда идут множество рутинных задач. Перечислю некоторые: сбор инфы и выжимка, черновики, типовые ответы, напоминания, базовый мониторинг логов, дневные отчеты. Это задачи, которые стабильно съедают время и хорошо автоматизируются.

По скиллам небольшая оговорка, для логики всей статьи лучше делать их руками по разделу 13, потому что так ты контролируешь поведение и не ломаешь модель безопасности из раздела 12. Готовые скиллы это только быстрый путь, но не слепая установка. Прочитай безопасность перед установкой и выполни все по пунктам. И только потом врубай в настоящий процесс.

Если нужен быстрый старт через установку из каталога, команды такие.

npx clawhub@latest install brave-search npx clawhub@latest install openclaw-tavily-search npx clawhub@latest install summarize npx clawhub@latest install log-analyzer npx clawhub@latest install healthcheck npx clawhub@latest install session-logs npx clawhub@latest install scheduler

Также моженшь установить прям через чат с агентом:

Установи скилл brave-search Установи скилл openclaw-tavily-search Установи скилл (---)

Проверка что скиллы реально на месте

Linux macOS

ls skills

Windows PowerShell

Get-ChildItem skills

Проверка в чате с агентиком:

Покажи список установленных скиллов

Если все на месте, ты красавчик! Делегируй рутину сразу, но реализацию держи под контролем, приоритет ручным скиллам и идем дальше.

Что делегировать частично?

Частично делегируй задачи, где агент сильно ускоряет процесс, но финальное решение должно оставаться за тобой. Это обычно финальные тексты под публикацию, ответы клиентам в спорных ситуациях, выводы по аналитике, технические фиксы и любые штуки, где ошибка может стоить репутации или деньжат.

Распишу немного примерчиков. Команды для чата с агентом в этом режиме

Сделай черновик поста по теме X, финал не публикуй без моего подтвержденияСобери факты и источники по теме X, отдельным блоком отметь риски и спорные местаПодготовь ответ клиенту в двух версиях, мягкая и жесткая, отправку не делайи тдтп. Думаю структуру ты понял.

Проверка состояния перед финалом

openclaw status openclaw logs --follow

Зафиксировать черновой результат в git перед правками

git add . git commit -m "Draft prepared for manual approval"

После твоего подтверждения зафиксировать финал

git add . git commit -m "Approved final version after manual review"

Если агентский вариант не устроил и нужен откат

git restore .

Все готово, поздравляю, ты закрыл очередной пункт.

Что лучше не делегировать?

Есть задачи, которые агенту лучше не отдавать полностью, даже если очень хочется ускориться. Это любые решения с высокой ценой ошибки, финансовые действия, юридически чувствительные ответы, финальные публикации без ревью, изменение критичных конфигов в проде и операции с доступами или ключами. Агент может сильно помочь с подготовкой, анализом и черновиком, но финальное решение в таких кейсах должен принимать ты.

Этот раздел про то, как после запуска не сжечь бабосы в ноль и при этом не уронить качество ответов. Когда контур растет, токены начинают улетать из-за кривого процесса, дохуя лишнего контекста, дублей задач и слабой маршрутизации. Давай разберемся, как это исправить.

Где сгорают токены

Токены сгорают в основном там, где процесс сделан через жопу. Главные сливы такие, размытый запрос, лишний контекст, повторные прогоны и тяжелая модель на рутину. Дальше все просто, агент начинает гадать, писать лишнее, ты перезапускаешь задачу по новой и сжигаешь бюджет на пустом месте. Если формат входа и выхода не зафиксирован, начинается вечная переделка одной и той же хуйни. Поэтому проблема обычно не в модели, а в кривой организации работы. Хочешь резать расход, сначала чистишь контекст, делаешь четкие запросы и разводишь задачи по слоям, легкий слой на поток, сильный на сложные кейсы. Все это мы уже разобрали выше, так что, если ты начал читать статью с этого пункта и узнал свою проблему, беги наверх и изучай.

Как резать расходы без потери качества

Чтобы не сжигать токены, нужно сделать одну максимально простую и полезную вещь. Все, что тебе нужно, это разделить задачи по слоям. Рутину и черновики отправляй в легкий слой, а сильную модель включай только на сложные и рискованные задачи. Подробно о таком способе рассказано в пункте 9. Дальше фиксируешь четкий формат запроса, что сделать, в каком виде, с какими ограничениями. Контекст режешь жестко, все что не влияет на текущую задачу, убираешь. В длинных цепочках добавляешь короткие summary между этапами, чтобы не тащить хвост на каждый следующий шаг. И главное, не запускаешь задачу с нуля по три раза. Все на самом деле просто и логично.

Управление контекстом

Управление контекстом является одним из самых важных, чтобы не въебывать бабки на пустом месте. Здесь важно не повторять блок про память из 10 раздела, там речь про хранение, а здесь про то, что ты реально передаешь в каждый запрос. Так че же делать? Вход должен содержать только цель текущего шага, нужные данные, ограничения и формат ответа. Все, что не влияет на решение прямо сейчас, вырезается. Если цепочка длинная, не тащи вперед весь хвост диалога. После каждого этапа делай короткую выжимку и передавай дальше уже summary, а не простыню. Так сохраняется смысл, но не сгорают токены на повторе одного и того же. Контекст должен быть релевантным и коротким, а не полным архивом на всякий случай. Чем чище вход, тем дешевле и стабильнее работает весь контур.

Профили моделей под бюджеты

Про выбор модели под задачу и связки мы уже разобрали в пункте 9. Тут другое, не что выбирать, а как зафиксировать этот выбор в систему. По умолчанию OpenClaw гонит все запросы в одну модель. Хартбиты, саб-агенты, простые вопросы и сложные задачи, все в одну очередь по одной цене. Это и есть главный пиздец который мы щас пофиксим.

Фиксируется это через ~/.openclaw/openclaw.json. Базовый пример с двумя агентами под разные каналы:

{ "agents": { "list": [ { "id": "flow", "name": "Поток", "workspace": "~/.openclaw/workspace-flow", "model": "anthropic/claude-haiku-4-5" }, { "id": "deep", "name": "Сложные задачи", "workspace": "~/.openclaw/workspace-deep", "model": "anthropic/claude-opus-4-6" } ] }, "bindings": [ { "agentId": "flow", "match": { "channel": "whatsapp" } }, { "agentId": "deep", "match": { "channel": "telegram" } } ] }

Поток и рутина это Haiku или Gemini Flash, дешево и быстро. Основная работа это Sonnet или GPT-4o, нормальный баланс. Критичные задачи и сложная логика это Opus или GPT-o1, и только туда. Это просто пример, моделей дохуя и настроить это можно намного гибче, под свои дела.

После правки конфига обязательно перезапускаешь:

openclaw gateway restart

Если не хочешь лезть в конфиг ручками, можно переключать модель прямо в чате командой /model на лету. Но это ручное переключение, профиль надежнее.

Мониторинг расходов

Решил расписать, как же грамотно мониторить расходы. Так как если на них не смотреть, может выйти не очень круто, проснешься - а бабок как ветром сдуло. У самого такое было когда сидел на блядских моделях по апишке. Самый быстрый способ посмотреть что происходит прямо сейчас это написать в чат с агентом:

/status

Выдаст карточку с текущей моделью, сколько контекста занято и сколько стоил последний ответ. Работает только если подключен по API ключу, при OAuth показывает только токены без стоимости.

Если хочешь видеть расходы после каждого ответа автоматически:

/usage full

Отключить обратно:

/usage off

Посмотреть сводку по расходам за последние 7 дней через терминал:

openclaw gateway usage-cost --days 7

Или через dashboard в браузере на http://localhost:18789, там есть вкладка с токенами и стоимостью по сессиям.

Что реально стоит отслеживать? Первое это размер сессий. Чем длиннее сессия, тем больше контекст тащится в каждый следующий запрос. Сессия на 35 сообщений может весить 2-3 MB и жрать сотни тысяч токенов на каждый ответ. Смотришь размер файлов сессий так:

ls -lah ~/.openclaw/agents/main/sessions/

Всё что весит больше 500 KB это уже повод почистить или пересоздать сессию.

Второе это какой агент и какая модель жрет больше всего. Если у тебя несколько агентов, часть из них может незаметно работать на дорогой модели там где это вообще не нужно. Это видно в /status или в dashboard.

Третье это аномалии. Если расходы резко выросли без видимой причины, скорее всего один из этих сценариев: включился режим thinking у модели и она генерирует внутренние рассуждения которые ты не видишь но платишь за них, или какой-то инструмент начал тянуть огромные блоки данных в контекст, или сессия раздулась и тащит мусор из прошлых недель.

Мониторить расходы не надо каждый час, достаточно делать это хотя бы раз-два в день. Ну и раз в неделю бросать глазки на размеры сессий и сводочку по usage. Этого тебе хватит чтобы поймать проблему и решить ее. Идем дальше.

Система может работать неделями без единой проблемы, а потом в какой-то момент что-то тихо ломается и ты не замечаешь. Агент начинает отвечать медленнее, качество плывет, канал перестает отвечать, и ты узнаешь об этом только когда уже все совсем хуево и чинить надо было еще вчера. Чтобы такого не было, нужна минимальная дисциплина по логам и диагностике, о которой я и расскажу тебе в последующих подпунктах.

Что и когда проверять?

Дада, тут нужен контроль ручками, а не агентом (к сожалению). Есть ежедневный контроль на 2-3 минуты и еженедельный на 10-15 минут. Если делать это регулярно, большинство проблем ловишь до того, как все уедет в пиздец.

Каждый день, базовый чек

openclaw status

Показывает состояние gateway, каналы и активность. Если что-то отвалилось, сразу видно.

openclaw logs --limit 50

Последние 50 строк логов. Смотришь на красные строки и ошибки. Если их нет, идешь дальше.

openclaw health --json

Снимок здоровья системы. Если команда падает или возвращает ошибку, значит есть проблема, которую надо разбирать.

Если хочешь видеть что происходит в реальном времени пока агент хуярит за тебя:

openclaw logs --follow

Раз в неделю - чуть глубже:

openclaw status --all

Расширенная диагностика, последний хартбит, тесты подключения каналов со временем ответа, состояние сессий. Хорошо гонять после обновлений или если неделя была нестабильной.

openclaw doctor

Комплексная проверка всей установки, права, конфиги, зависимости, порты, безопасность. Если нашел что-то починяемое, можно запустить с флагом --fix, но сначала читаешь что именно он собирается менять.

du -sh ~/.openclaw/agents/main/sessions/ ls -lah ~/.openclaw/agents/main/sessions/

Смотришь размер сессий. Всё что больше 500 KB это уже потенциальный жор токенов, разбираешь или пересоздаешь, уже обговаривали это.

Вот и все готово, времени уходит на эти дела немного, а профит от этого огромный.

Частые поломки и их фиксы

Помнишь раздел 7.3 где мы разбирали типовые ошибки при установке? Так вот это его старший брат. Там были косяки на старте, здесь поломки которые вылезают уже в работе. Давай по фасту разберу проблемы, с которыми ко мне обращались мои знакомые.

1. Gateway сдох и не отвечает. Это самая наверное базовая проблема.

openclaw status openclaw gateway start

На VPS:

systemctl --user start openclaw-gateway

Если порт занят и ругается на address already in use:

lsof -iTCP:18789 -sTCP:LISTEN -n -P sudo kill -9 PID_процесса openclaw gateway start

2. Отвалился канал. Gateway живой, но сообщения не доходят. Бывает регулярно, ничего страшного:

openclaw channels status --probe openclaw channels logout openclaw channels login --verbose

Готово, прикинь как быстро.

3. Агент завис или отвечает через одно место. Такая же распространенная ошибка, как и другие. Беги смотреть что происходит внутри:

openclaw logs --follow top free -h

Если память на нуле или CPU в 100%, сессия раздулась или инструмент ушел в петлю. Перезапускай:

openclaw gateway restart

4. Одна и та же ошибка в логах. Если ошибка повторяется больше 10 раз подряд это системная хуйня которую надо чинить:

openclaw logs --limit 300 --plain openclaw doctor

И главное правило которое я уже говорил в 7.3 и повторю еще раз, потому что люди всё равно игнорируют. Если смотришь на проблему больше 30 минут и в душе не ебешь где именно сломалось, не копай дальше. Логи, doctor, и только потом решения. Иначе потратишь час чтобы починить то что решалось за пять минут. Идем дальше.

План восстановления после падения

Все упало и пошло по пизде? Да не переживай, в этой статье решение подобных проблем это обычный случай. Повторяй за мной.

Первым делом проверяешь, что именно сломалось:

openclaw status openclaw health --json openclaw logs --limit 100

Далее пробуешь самое простое решение:

openclaw gateway restart

На VPS:

systemctl --user restart openclaw-gateway

Но лично я всегда использую первую команду для рестарта. В 60% случаев этого достаточно. Если помогло, проверяешь что все живое и идешь дальше.

Если не помогло, запускаешь диагностику:

openclaw doctor

Читаешь что он нашел. Если есть починяемые проблемы:

openclaw doctor --fix

Если конфиг сломан, откатываешься на бэкап

cp ~/.openclaw/openclaw.json.bak ~/.openclaw/openclaw.json openclaw gateway restart

Бэкапа нет? Тогда больно, но не смертельно. Заново прогоняешь onboard

openclaw onboard

Если ничего не помогает, сносишь и ставишь заново (это самое плачевное и больное). Подробно это разобрано в пункте 7.4. Установка занимает 30-60 минут, во второй раз намного быстрее.

Ну и финальная проверка что все гудик.

openclaw doctor openclaw status --all

Пишешь боту простое сообщение. Ответил, все живое, выдыхаешь и читаешь статью дальше.

Часть важных вещей по безопасности мы уже закрыли раньше. Про API ключи и токены в разделе 7, про разделение тестового и рабочего контура в разделе 6, про минимальные права в разделе 12. Повторять это нет смысла, там все подробно. Здесь разберем то что осталось, куки и сессионные токены, доступ к внешним сервисам и что делать с личными данными которые агент неизбежно видит в процессе работы.

Куки и риски

Когда агент работает с браузером, он неизбежно касается cookies и сессионных данных. Это не абстрактная угроза, а реальная дыра, через которую можно потерять доступ к аккаунтам, если относиться к этому на похуй.

Обезопасить себя тут очень просто. Для агента создаешь отдельный браузерный профиль, чистый, без сохраненных паролей и личных cookies. Никогда не даешь агенту работать в профиле, где хранятся твои личные логины, карты и другая чувствительная хуйня. Если сессия агента будет скомпрометирована через вредоносный скилл или prompt injection, злоумышленник получит доступ только к изолированному профилю, а не ко всему твоему цифровому контуру.

Второй момент, в OpenClaw нужно разделять токен доступа к gateway и сессионные ключи контекста, но с практической точки зрения правило очень простое, любой, кто может писать агенту в активный контур, потенциально может запускать действия в пределах его прав. Поэтому если агент работает в командах или группах, доступы к критично важным операциям нужно резать максимально жестко, иначе потом будешь разгребать последствия, причем очень сильные.

Доступ к внешним сервисам

Это один из самых недооцененных рисков в OpenClaw и при этом один из самых опасных. Когда подключаешь агента к Telegram, Google, Slack, GitHub или другому сервису через OAuth, ты выдаешь доступ через токен. И тут важный момент, если завтра удалить OpenClaw, выданные доступы не обязаны исчезнуть автоматически. Во многих сервисах они продолжают жить, пока ты сам не отзовешь их вручную. Это не баг OpenClaw, это обычная механика OAuth, но большинство про это не думает, а потом ахуевает.

Так что запомни, подключаешь только то, что реально нужно прямо сейчас. Даешь минимальные права, если нужен только read, не даешь write. И раз в месяц (или хотя бы в два) проходишься по всем подключенным сервисам, смотришь активные OAuth приложения и лишнее отзываешь.

Я уже об этом писал, но напомню, если скилл или интеграция просит права, не связанные с задачей, это красный флаг. Календарный скилл не должен просить доступ к контактам, файлам и лишним данным. Видишь такую хуйню, не ставишь ни в коем случае.

Личные данные и приватность

Агент в процессе работы видит очень много. Переписки, документы, задачи, данные из сервисов. В этом и заключается основная опасность для нас, для обычных пользователей. Это все оседает в сессиях, памяти и служебных файлах в ~/.openclaw/. Эту папку нужно воспринимать как чувствительную зону, где хранится критичный контекст и доступы.

Первое что делаешь, закрываешь права на директорию и ключевые файлы

chmod 700 ~/.openclaw chmod 600 ~/.openclaw/agents/main/agent/auth-profiles.json

Второе, не синхронизируешь ~/.openclaw в Dropbox, Google Drive и похожие сервисы. Там могут лежать токены, память агента и рабочие логи. Одна кривая настройка или случайная публичная ссылка, и данные улетают.

Третье, если агент работает с чувствительными данными, настраиваешь логирование максимально аккуратно. По умолчанию в логах может быть много служебной информации, поэтому регулярно проверяешь что именно пишется и ограничиваешь детализацию, если это необходимо.

Ну и напоследок, prompt injection это реальная угроза, которую нельзя закрыть на 100 процентов одной галочкой. Если агент читает письма, документы или веб-страницы, там может быть вшита вредная инструкция. Решение тут всего одно, максимально логичное и простое, не давать агенту критичные права без необходимости и не разрешать чувствительные действия без подтверждения. Иначе в какой-то момент он может обнаглеть и сделать то, что ты не просил.

Теория и команды это конечно хорошо, но реальная проверка всегда остается одна, как система ведет себя в реальной жизни. Этот раздел я решил посвятить своей истории соприкосновения с Openclaw. Что он делает для меня, как помогает и какие задачи я скидываю на него на постоянке.

День автора с Openclaw

Обычный день с OpenClaw выглядит как управляемый поток, а не хаотичный список дел. Утром агент собирает мне короткую сводку по приоритетам, напоминаниям и зависшим задачам, днем закрывает повторяемую рутину, ресерч, черновики, сводки и базовые проверки, а вечером формирует сжатый итог и план на завтра. Главная польза лично для меня тут в том, что он снимает механическую хуйню и освобождает голову под решения, где мне реально нужна концентрация.

Неделя автора с Openclaw

Лично у меня OpenClaw реально стабилизировал ритм, стало меньше ручных повторов, меньше потерь контекста и меньше тупых мелочей, которые раньше копились в бардак. Я начал лучше видеть что оставляю на ручной контроль. В конце каждой недели он присылает мне сводку с моими выполненными и перенесенными задачами. В общем он мой планер, контроллер и рабочий. Я не стал затягивать этот пункт, он все таки не является юзфул для кого либо, но и не поведать я об этом тоже не мог. Спасибо за прочтение, читай дальше.

Ниже разбор в моем стиле, но важная пометка, часть про NanoClaw, Nanobot, memU и Hermes собрана по материалу моего друга с хорошего канала maloymedika. Обязательно заглядывайте к нему и передавайте приветы от меня. Давайте разберемся.

Openclaw vs обычные ИИ чаты

Если сравнивать с обычными чатами, разница тут простая, чат хорошо и быстро отвечает на разовый запрос, Openclaw строит целую систему и рабочий контур. В чате ты каждый раз стартуешь почти с нуля, вручную держишь контекст, сам контролируешь этапы и проверяешь, что не потерялось по дороге. Openclaw дает память, роли, скиллы, маршрутизацию задач и повторяемый процесс, где рутинная хуйня уходит в автоматизацию.

Быстрый старт Openclaw

npm install -g openclaw@latest openclaw onboard --install-daemon openclaw gateway status openclaw status

Где чаты выигрывают? Быстро спросить, быстро получить ответ, нулевой порог входа.Где Openclaw выигрывает? Длинные процессы, оркестрация, интеграции, контроль, системная работа на дистанции.

Я и сам на постоянке пользуюсь обычными ИИ. Я уже и забыл что такое поисковая строка, если мне нужно получить быстрый ответ, то я спрашиваю в основном у Gemini или Grok.

Openclaw vs no-code автоматизации

No-code платформы отлично закрывают линейные сценарии, такие как триггер, действие, уведомление, запись в таблицу. Но как только появляется живой контекст, ветвления, память, промежуточные решения и необходимость дорабатывать логику на лету, no-code начинает поскрипывать умоляя пощадить. OpenClaw в этом месте гибче, потому что это не только автоматизация, а агентный слой с памятью и ролью.

Минимальный контур автоматизации в Openclaw обычно проверяют так

openclaw status openclaw logs --limit 100 openclaw health --json

Где no-code сильнее? Простые бизнес-процессы, быстрый запуск без кода, понятные интеграции.Где сильнее Openclaw? В сложных цепочках, интеллектуальных задачах, контент/ресерч/оркестрация, работа с длинным контекстом. Идем дальше.

Альтернативы OpenClaw

А вот хорошие альтернативы перечислит как раз таки мой друг maloymedika

NanoClaw

~500 строк кода. Каждое действие агента запускается в отдельном изолированном контейнере - если он перестанет работать или сойдет с ума, то не волнуйся, основную систему он не зацепит.

Плюсы:

Минусы:

Установка:

git clone https://github.com/gavrielc/nanoclaw.git cd nanoclaw claude # → /setup

Nanobot

4 000 строк на Python от университета Гонконга. Весь код можно понять за день. Ты можешь кастомизировать его полностью под себя, с openclaw - это будет сложнее.

Плюсы:

Минусы:

Установка:

git clone https://github.com/hku-dil/nanobot.git cd nanobot && pip install -e . nano ~/.nanobot/config.json

Нужен Python 3.10+ и база данных PostgreSQL.

memU

Не столько прямо “альтернатива Openclaw”, сколько долгосрочная память для агента. Запоминает твои предпочтения, проекты, привычки - и сам предлагает помощь без запроса. Если ты хочешь попасть в “локальное” км и тебе интересно в этом разбираться, то welcome.

Плюсы:

Минусы:

Установка:

git clone https://github.com/memu-ai/memu.git cd memu && pip install -r requirements.txt cp .env.example .env && nano .envХорош как слой памяти поверх другого агента — чтобы помнил твой стиль, темы, предпочтения.

Hermes Agent

Лёгкий агент с поддержкой Telegram, Discord, WhatsApp и командной строки сразу из коробки. Работает с любой языковой моделью. Было дело, тестировал Hermes, очень приятная и легкая альтернатива, которую можно интересно настраивать. По сути, самый приближенный вариант к Openclaw, но легче.

Плюсы:

Минусы:

Установка:

git clone https://github.com/hermes-ai/hermes-agent.git cd hermes-agent && pip install -r requirements.txt cp config.example.yaml config.yaml python main.py

В этом пункте я постарался ответить на частые вопросы, которые регулярно получаю от новичков.

Нужен ли VPS?

Если говорить коротко - нет, но ты об этом пожалеешь. Локалка подходит чтобы потыкать и понять механику. Но как только захочешь нормальную работу - ноутбук уснёт и всё встанет. VPS стоит 5-10 евро в месяц и даёт тебе стабильный аптайм, предсказуемую среду и доступ из любой точки. Один раз поднял, настроил, забыл. Если цель реально работать сразу на VPS, не трать время на локалку.

Можно ли без кода?

Можно, но с небольшими оговорками. Базовую установку по гайду из раздела 7 осилит человек который видел терминал хотя бы пару раз. Там нет ничего сложного, скопировал команду, вставил, запустил. Но как только начнёшь настраивать скиллы, память и оркестрацию, вот тут минимальное понимание что происходит очень сильно хелпует.

Как не словить баны и утечки?

Три правила и они ультра простые. Первое, никогда не держи API ключи в открытых файлах и не вводи их напрямую в терминале, только через onboarding или переменные окружения. Второе, закрой dashboard на 127.0.0.1, не оставляй порт 18789 открытым в интернет, это реальный пиздец. Третье, не ставь скиллы вслепую, сначала аудит кода, потом песочница, потом прод. Вот и все, теперь ты в безопасности.

Финальный блок, который экономит тебе часы. Я постарался собрать все полезные шаблоны и команды, чтобы не вспоминать каждый раз с нуля.

Проверка и запуск контура:

openclaw status openclaw gateway status openclaw gateway restart openclaw health --json openclaw logs --limit 100

Диагностика если что-то пошло криво:

openclaw doctor openclaw doctor --fix openclaw status --all

Проверка установленного стека:

ls skills

Windows:

Get-ChildItem skills

--- name: skill-name description: Коротко и по делу, что делает скилл. --- # skill-name Перед началом прочитай references/output-format.md Шаги 1. Прими входные данные 2. Выполни задачу по этапам 3. Проверь результат на дубли/ошибки 4. Отдай результат в формате references/output-format.md Жесткие правила - не выдумывать факты - не выходить за ограничения задачи - не выполнять критичные действия без подтверждения - если данных не хватает, явно сообщить об этом

Быстрые команды

openclaw status openclaw logs --follow git add . git commit -m "Security checkpoint before skill rollout"

Перед отправкой в канал:

Мини-протокол

STATUS: ok|fail INPUT: ... OUTPUT: ... RISKS: ... NEXT: publish|revise

https://t.me/claudedevolper