Openclaw от А до Я

Всех рад приветствовать на начале моего самого масштабного лонгрида. Посвятить его я решил именно Openclaw. Тема только набирает обороты и статья будет актуальна на старте вашего пути абсолютно всегда.

Долго копался во всей инфе + тестил сам. И наконец то решил вывалить это все в единую статью. (Схемы в статье генерировал Claude)

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

Ознакомься с оглавлением:

0. Введение

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

Зачем вообще появилась эта статья?

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

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

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

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

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

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

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

Как читать статью, если ты новичок?

Для полного понимания от А до Я (как написано в названии) я бы советовал прочитать все от начала и до конца. Не пропускай блоки про архитектуру, память и безопасность - именно они чаще всего определяют, будет система полезной или развалится нахуй через неделю.
Ну, а практические команды и шаблоны лучше сразу тестировать у себя по ходу чтения. Так что удачи!

Как читать статью, если ты уже подкован в теме?

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

1. Что такое OpenClaw

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап Warelay

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

Этап Clawdbot

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

Этап Moltbot

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

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

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

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

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

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

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

3. Философия OpenClaw

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

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

Self hosted подход

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

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

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

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

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

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

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

4. Архитектура системы

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

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

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

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

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

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

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

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

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

Скиллы

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

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

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

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

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

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

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

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

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

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

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

5. Кому подходит OpenClaw

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

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

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

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

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

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

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

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

6. Подготовка к установке

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

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

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

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

Для базового старта 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 -> Безопасность -> План отката -> Старт

7. Установка OpenClaw с нуля

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

Полноценный гайд установки

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

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

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 (локалка)

Тут проще всего - никаких прослоек, всё нативное. 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)

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 <<EOF
[Resolve]
DNS=9.9.9.9 8.8.8.8 1.1.1.1
FallbackDNS=
EOF
systemctl restart systemd-resolved

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

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 <<EOF > /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)

Самый правильный вариант для рабочего контура. Всё то же самое что в 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 <<EOF
[Resolve]
DNS=9.9.9.9 8.8.8.8 1.1.1.1
FallbackDNS=
EOF
systemctl restart systemd-resolved

Логи:

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 <<EOF > /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 минут пытаешься починить не понимая причины, не трать ещё час. Сноси и ставь заново по гайду. Ну а мы идем дальше.

8. Первый запуск и первая польза

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

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

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

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

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

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

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

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

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

Сценарий 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 и проверяешь что поведение реально поменялось, а не осталось как было.

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

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

9. Модели и выбор мозга агента

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

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

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

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

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

• Скорость, ответы приходят за 1-2 секунды даже на какие то сложные промпты.
• Экономия, в том случае если вы подключились по OAuth, будет выходить очень даже дешево.
• Экосистема, легко комбинировать с другими моделями
  

Минусы ChatGPT

• Рассуждение, очень слаб в сложной логике/дебаге (codex в дебаге норм)
• Требует хорошего и стабильного интернета. Тормозит под нагрузкой.

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

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

Плюсы Claude:

• Логика и кодинг, Claude на голову выше ChatGPT в дебаге и понимании сложных архитектурных задач.
• Человеческий стайл, ответы Claude менее шаблонные, он лучше пишет текста и реже использует нейросетевые клише.
  

Минус Claude:

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

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

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

Плюсы Gemini

• Большой контекст. Поддерживает от 1 до 2 млн токенов. Можно загружать супер огромные данные.
• Скорость обработки информации и ответов. Отвечает крайне быстро (но все зависит от объема запроса конечно)
  

Минусы Gemini

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

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

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

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

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

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

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

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

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

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

Два слоя памяти, 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

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

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

1. В память пихают все подряд и превращают ее в свалочку, где полезная инфа тонет в мусоре, а агент начинает цепляться за случайные детали и нести хрень.
2. Не отделяют временное от постоянного, и в итоге однодневные задачи внезапно выглядят как долгосрочные правила, а реально важные договоренности теряются в ежедневной рутине.
3. Не фиксируют дату и контекст, из за чего через неделю уже непонятно, почему решение приняли, в каких условиях оно работало и актуально ли оно вообще, а без этого агент начинает гадать и регулярно проебывается.
4. Не делают регулярную чистку, и даже нормальная система зарастает дублями, устаревшими кусками и мертвыми заметками, после чего качество падает само по себе, просто потому что память захламлена.
5. Правят long term с плеча без safe mode, без черновика и без подтверждения, а потом одной кривой правкой разъебывают рабочий контекст и чинят это неделями.

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

11. Скиллы, сердце расширяемости

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

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

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

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

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

1. SKILL.md как мозг поведения
2. references как шаблоны формата и вспомогательные правила
3. scripts если нужно автоматизировать куски руками не закрывающиеся.

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\<you>\.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

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

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

• skills/tg-news-digest/SKILL.md
• skills/tg-news-digest/references/output-format.md
• skills/tg-news-digest/scripts/clean_duplicates.py.
  

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

Искать можно где угодно, но ставить без проверки нельзя. Для базы смотри официальный каталог скиллов на 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\<you>\.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"

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

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

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

• Первый критерий это время. Берешь одну повторяемую задачу и сравниваешь до и после. Если раньше делал 30 минут, а теперь 10-15 без потери качества, это уже сильный сигнал. Если разницы нет, значит ты просто добавил слой лишней хуйни.
• Второй критерий это ошибки. Нормальный скилл должен уменьшать количество косяков, а не плодить новые. Если после установки меньше ручных доправок и меньше откатов, значит он усиливает контур.
• Третий критерий это повторяемость. Прогоняешь один и тот же тип запроса 2-3 раза и смотришь, держит ли скилл уровень. Полезный скилл будет выдавать предсказуемый результат шаблонно.
• Четвертый критерий это операционный шум. Хороший скилл не требует перед каждым запуском танцев с бубном. Запустил, пошел пить чай, получил результат, радуешься и рекомендуешь эту статью всем кентам.

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

openclaw logs --follow
openclaw status

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

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

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

12. Безопасность скиллов

В 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\<you>\.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\<you>\.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 минуты

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

13. Как создать свой скилл руками

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

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

Много людей писали мне в личку спрашивая, нахуя мне мучаться, если я могу просто скачать любой понравившийся скилл? Да потому что ручной способ дает тебе полный контроль, а в 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\<you>\.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

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

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

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

• Размытые шаги в SKILL.md. Вместо конкретных действий пишут общие фразы вроде собери информацию или сделай качественно. Агент начинает додумывать, и каждый запуск дает разный хуевый результат.
  Решение тут максимально простое. Каждый шаг делай конечным и проверяемым. Не собрать данные, а собрать новости только за 24 часа. Не улучшить текст, а сократить до N пунктов и оставить только источники с ссылками.
• Нет жестких ограничений. Эту проблему определить потяжелее, так как формально то скилл работает, но в пограничных случаях улетает в фантазии, нарушает временное окно, тащит непроверенные источники и выдает кашу.
  Решение. В каждом скилле должен быть блок жестких правил, где прямо запрещены критичные вещи, приведу пример (у вас может быть другое):не выдумывать факты, не давать результат без ссылок, не выходить за заданный период, при нехватке данных писать об этом явно.
• Не фиксируют изменения и откат. Это пиздец как важно бро. Каждую рабочую итерацию фиксируй в git:

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

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

14. Оркестрация от простого к сложному

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

Формат 1, роли в одном чате

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

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

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 без проверки не ебашь.

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

• main принимает задачу и собирает финал, он тут самый крутой
• research дает факты, ссылки, даты
• content упаковывает в твой стиль
• ops ловит баги, риски и техкосяки.

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

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

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

Формат

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

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

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

1. передай в research собрать факты и ссылки
2. передай результат в content на упаковку
3. передай в ops на проверку рисков
4. main собирает финал и показывает на подтверждение

Публикует только 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

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

Формат 2, темы в группе

Этот формат нужен, когда один чат уже не вывозит нагрузку и контекст начинает плыть. Суть простая, ты раскладываешь процесс по отдельным темам в группе и получаешь чистый конвейер без мешанины. Базовый набор тем такой, 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 только маршрутизация и контроль этапов. Ключевой момент в том, что каждая тема делает свою часть и не лезет в соседнюю.

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

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

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

STATUS ok|fail
INPUT ...
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.

Формат 3, разные боты + backend

Этот формат нужен, когда ты уже перерос темы и хочешь настоящую боевую схему с разделением по ботам и централизованной маршрутизацией. Суть тут такая, у тебя есть 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 либо присылает тебе финал, либо гонит задачу на доработку. Это и есть нормальная оркестрация, где каждый занимается своим, а финальное решение контролируется через единый узел, без хаотичной хуйни между этапами.

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

• apps/orch/main.py - прием входа, генерация task_id, маршрутизация, финальный ответ
• apps/research/main.py - только факты, ссылки, даты
• apps/writer/main.py - только упаковка текста по входным данным
• apps/qa/main.py - проверка формата и фактов, вердикт ok fail.

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

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 с очередями. Вообще, советовал бы затестить каждый формат и выбрать идеальный под себя.

15. Практические конвейеры

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

Контент конвейер

Контент конвейер нужен для одной понятной задачи - делать публикации регулярно и в ровном качестве, которое устраивает именно вас. хема здесь жесткая и именно поэтому рабочая, идеи отвечают за направление, ресерч за фактуру, 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

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

• Никаких новостей без ссылки
• Никаких старых новостей вне окна
• Никаких повторов одного и того же события
• Если источник сомнительный, помечаем риск
• Финал без QA не публикуется.

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

• Сколько новостей отсекли как мусор
• Сколько прошло верификацию
• Где чаще всего проваливается качество, на FILTER, VERIFY или SUMMARY.

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

Технический конвейер

Технический конвейер нужен в тот момент, когда у тебя пошли задачи с логами, падениями и непонятными ошибками, и важно реально найти причину и закрыть проблему нормально. Безумно полезный конвейер, но, конечно, не для всех найдется применение. Как обычно пропишу маршрут 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

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

16. Делегирование, что реально отдавать агенту

Делегирование работает, когда задачи разделены по риску и цене ошибки. Если не делегировать ничего, 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 .

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

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

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

17. Производительность и стоимость

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

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

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

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

Чтобы не сжигать токены, нужно сделать одну максимально простую и полезную вещь. Все, что тебе нужно, это разделить задачи по слоям. Рутину и черновики отправляй в легкий слой, а сильную модель включай только на сложные и рискованные задачи. Подробно о таком способе рассказано в пункте 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. Этого тебе хватит чтобы поймать проблему и решить ее. Идем дальше.

18. Логи, диагностика, стабильность

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

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

Дада, тут нужен контроль ручками, а не агентом (к сожалению). Есть ежедневный контроль на 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

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

19. Безопасность данных и доступа

Часть важных вещей по безопасности мы уже закрыли раньше. Про 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 процентов одной галочкой. Если агент читает письма, документы или веб-страницы, там может быть вшита вредная инструкция. Решение тут всего одно, максимально логичное и простое, не давать агенту критичные права без необходимости и не разрешать чувствительные действия без подтверждения. Иначе в какой-то момент он может обнаглеть и сделать то, что ты не просил.

20. Openclaw в реальной жизни

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

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

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

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

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

21. Сравнение 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 строк кода. Каждое действие агента запускается в отдельном изолированном контейнере - если он перестанет работать или сойдет с ума, то не волнуйся, основную систему он не зацепит.

Плюсы:

• Безопасный по умолчанию
• Весь код читается за 8 минут
• Работает даже на слабом железе
• Поддержка WhatsApp
• Можно запускать несколько агентов одновременно

Минусы:

• Работает только с Claude
• Почти нет расширений
• Нет визуального интерфейса

Установка:

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

Nanobot

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

Плюсы:

• Помнит разговоры между сессиями
• Умеет искать в интернете
• Запускает подзадачи параллельно
• Работает в Telegram и WhatsApp
• Поддерживает разные языковые модели

Минусы:

• Нужна отдельная база данных
• Всего два мессенджера (Telegram и WhatsApp)
• Нет визуального интерфейса

Установка:

 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

22. Часто задаваемые вопросы

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

Нужен ли VPS?

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

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

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

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

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

23. Приложения

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

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

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

 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

Шаблон SKILL.md

---
name: skill-name
description: Коротко и по делу, что делает скилл.
---

# skill-name

Перед началом прочитай references/output-format.md

Шаги
1. Прими входные данные
2. Выполни задачу по этапам
3. Проверь результат на дубли/ошибки
4. Отдай результат в формате references/output-format.md

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

Шаблон memory daily

# YYYY-MM-DD

## Контекст
Что было в работе сегодня

## Сделано
- ...

## Решения
- ...

## Почему так
- ...

## Риски
- ...

## Следующий шаг
- ...

## Кандидаты в MEMORY.md
- ...

Чеклист безопасности

• Перед установкой/запуском нового скилла:
• Прочитал SKILL.md полностью
• Проверил references и scripts
• Нет лишних доступов и мутных действий
• Протестировал в песочнице
• Критичные действия только с подтверждением
• Есть точка отката в git

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

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

Чеклист публикации контента

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

• Факты и ссылки проверены
• Дубли убраны
• Тон и стиль соответствуют формату канала
• Заголовок цепляет, но без кликбейтной хуйни
• Финал утвержден
• Пост готов к публикации в один заход

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

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

Глоссарий простыми словами

• Gateway - сервис-связка, через него живет весь контур
• Skill - модуль поведения под конкретную задачу
• References - шаблоны и правила формата результата
• Scripts - автоматизация рутинной техчасти
• Orchestration - маршрутизация задач между ролями/этапами
• Prompt injection - вредная инструкция, спрятанная во входных данных
• OAuth - вход через внешний сервис с выданным доступом
• Long-term memory - долговременная память с устойчивыми правилами
• Daily memory - ежедневный рабочий слой
• Fallback model - резервная модель, если основной слой недоступен
• Safe mode - режим сначала черновик, потом подтверждение, потом действие

24. Финальный вывод

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

Мои ресурсы:
Канал - https://t.me/SLtowl
Парсер скиллов - https://slopenclawskills.ru/
Видео на YouTube - https://youtu.be/YyhBJMpaWAE?is=RNvGuGs538jyDcdh