Прагматичный OpenClaw: реальная польза без хайпа

Вводные слова

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

Сразу обозначу: не будет «это меняет мир», «я уволил всех сотрудников», «агенты работают вместо меня». Будет сухо, по делу: скучная, но реальная польза без хайпа. У данной статьи есть также видео-версия: VKVideo / YouTube.

Техническая особенность OpenClaw: как вообще работают агенты

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

1. LLM — это преобразование текст → текст. На входе текст, на выходе текст. В этом и есть вся магия: LLM «понимает» запрос и возвращает осмысленный ответ.

2. Потом появился механизм tools: вместе с текстом мы передаём список команд, которые система может выполнить. Например мы говорим LLM, что наша система может ставить напоминания в календарь и для этого нужны поля "названия мероприятия" и "дата+время мероприятия".

3. LLM видит, что в тексте есть «поставь напоминание на завтра», понимает что это как раз та задача в тексте присутствует. После чего формирует JSON‑команду и передаёт системе.

4. Система выполняет команду → возвращает результат LLM → LLM пишет пользователю «напоминание поставлено».

Долгое время агенты строились именно так: мы храним список инструментов, передаём его в модель, и она выбирает, что сделать. Но чтобы такой агент работал, инструменты нужно писать, подключать, отлаживать — и этим занимаются разработчики. Даже с современными AI‑инструментами вроде Cursor или Claude Code это всё равно требует времени и инженерной работы.

OpenClaw ломает эту инерцию.

По сути внутри системы появляется ещё один инструмент, который условно можно назвать «добавь в себя новый инструмент».

То есть всё то, что раньше делали разработчики — написать код инструмента, подключить его, поправить конфиги, перезапустить сервис — теперь может сделать сам агент.

Сценарий примерно такой:

• пользователь просит новую функцию;

• агент смотрит свою документацию;

• понимает какие изменения нужно внести;

• пишет новый инструмент на Python/TS;

• прописывает его в конфиги;

• пересобирает и перезапускает себя.

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

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

Поэтому пользователь по сути говорит: «хочу, чтобы ты умел делать вот это», а дальше агент сам:

1. смотрит документацию,

2. дописывает себе нужную функциональность,

3. продолжает работать уже в обновлённом виде.

Если для нового инструмента нужны какие‑то дополнительные вещи — например API‑ключи, токены доступа или другие параметры — OpenClaw сам это запросит у пользователя. После этого он сохранит всё в нужные конфиги и переменные окружения. При этом секреты хранятся отдельно и не светятся в обычных логах или переписке, то есть система старается обращаться с ними как с чувствительными данными.

Хайп вокруг OpenClaw

OpenClaw доехал до известных разработчиков и блогеров, и начался лавинный эффект. Звёзды на GitHub улетели в космос.

Дальше классика: курсы, «мир никогда не будет прежним», «перепишем правила игры». Какое-то время у меня в любой социальной сети пестрили ролики про то как очередной блоггер уволил весь отдел, заменил одним агентом и теперь живет и наслаждается жизнью. Будущее наступило, не иначе! (спойлер: нет).

Я наблюдаю, как люди делают агентные «офисы» в духе Warcraft — выглядит прикольно, но в реальности не всегда полезно. У меня внутренний IT‑скептик сразу вспоминает историю с метавселенными.

Про Цукерберга и метавселенные

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

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

OpenClaw можно ставить двумя путями. Опасно и безопасно.

1. Опасный путь (локальная команда)

В документации предлагается запустить скрипт, который по сути «прошивает» OpenClaw прямо в вашу систему.

Он автоматически:

• скачает нужную версию Node.js (или обновит установленную);

• скачает сам OpenClaw;

• установит его как системный сервис;

• настроит окружение и зависимости;

• после чего агент будет постоянно работать в фоне.

Звучит очень удобно — одна команда и у вас появляется полноценный ИИ‑ассистент, который интегрирован прямо в ваш рабочий компьютер.

Плюсы такого подхода действительно есть.

Во‑первых, OpenClaw получает доступ к вашей файловой системе. Это значит, что можно давать задачи вроде: «найди договор с клиентом, поправь реквизиты и пришли новую версию». Агент сам найдёт файл, откроет его, внесёт изменения и вернёт результат.

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

По сути получается почти тот самый «джарвис» из железного человека или "компьютер-знайка" из незнайки на луне — помощник, который может напрямую взаимодействовать с вашим рабочим окружением.

Но у такого подхода есть и серьёзные минусы.

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

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

Я видел реальные кейсы, когда модель просто ломала свои же конфиги. Например, нужно было поправить JSON‑файл — модель переписала его, но забыла запятую. В результате конфиг перестал парситься и вся система падала.

Для разработчика это пять минут работы, но для обычного пользователя это превращается в очень странную и непонятную проблему. В итоге получается кладбище крабов свалка нерабочих openclaw, с которыми разобраться могут только разработчики или близкие к IT люди.

2. Безопасный путь (изолированная машина)

Мой вариант — максимально изолировать агента от основной рабочей среды.

• отдельная виртуалка в датацентре;

• в будущем — отдельный ноутбук с Ubuntu;

• полностью отдельное окружение, где агент может делать что угодно.

Сейчас у меня это обычная VPS в датацентре нашей компании. Там крутится Ubuntu, установлен OpenClaw и больше практически ничего нет. Если агент что‑то сломает — он сломает эту виртуалку, а не мой рабочий компьютер. SSH доступов у него никаких никуда нет.

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

Такой подход решает сразу несколько проблем:

1. Безопасность. У меня на основном компьютере есть доступы к разным системам, клиентским данным, серверам и другим вещам, которые я точно не хочу отдавать на управление системе, принимающей решения через внешний API LLM.

2. Контроль. Если агенту нужно что‑то посмотреть в браузере, я могу просто подключиться к этому ноутбуку и открыть нужную страницу. Это иногда быстрее и надёжнее, чем заставлять агента искать её самому.

И самое главное — если что‑то пойдёт не так, пострадает только среда агента. В худшем случае я просто удалю виртуалку и подниму новую.

Стоимость жизни openclaw

Подходим к самому важному. OpenClaw живёт за счёт LLM‑инференса. Это дорого. Все инфоцыгане, рассказывающие про "я уволил штат и заменил одним агентом" умалчивают про стоимость работы LLM. Это все равно, что в начале 20-го века рассказывать про "я перестал ходить пешком и езжу на автомобиле" и совсем не рассказывать про бензин и прочие накладные расходы владения авто.

Я посмотрел реальные логи своих же запросов запросов и собрал несколько примеров:

согласно ценам на gpt-5.2 на openrouter

Скриншоты примеров

Почему так дорого

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

Поэтому даже простая команда вроде «поставь напоминание» на самом деле превращается в длинный диалог под капотом.

1. Агента (Система) отправляет запрос модели: «что мне сделать?»;

2. Модель выбирает инструмент и возвращает JSON‑команду;

3. Система выполняет действие;

4. Снова спрашивает модель: «я сделал вот это, что сказать пользователю?».

Каждый такой шаг — это новый запрос к LLM.

В результате даже маленькая операция может легко сжечь десятки тысяч токенов (пример: $250 за настройку). В моих логах, например, обычный «reset» сессии съедает около 10 000 токенов входного контекста. Простая задача вроде «поставь напоминание через час» уже может уходить в район 40–50 тысяч токенов, потому что агент несколько раз консультируется с моделью, проверяет документацию инструментов и формирует ответ.

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

Если агент работает активно, за час легко уходит 2–3 тысячи ₽. За сутки — десятки тысяч. Особенно при первичной настройке.

Есть ещё функционал cron/heartbeat: агент просыпается по расписанию, делает задачи и сжигает токены, даже если вы ничего не пишете. Люди оставляли OpenClaw на день‑два с автоматизацией — и у них вылетали 5–7 тысяч ₽ за сутки (reddit).

Цена хайпа

Что-то математика вида "я уволил весь отдел и теперь за меня работает только агент" ломается о бетон реальности. Если агент работает нон‑стоп час — это легко может быть 10–20 тысяч ₽.

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

Подписки на провайдеров: дешевле и предсказуемее

Платить за токены "as-you-go" — риск внезапно улететь в минус. Когда агент работает активно, счётчик может крутиться буквально на глазах: несколько десятков тысяч токенов за операцию, потом ещё один шаг, потом ещё. В какой‑то момент вы просто обнаруживаете, что за пару часов экспериментов сожгли несколько тысяч рублей.

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

Сводная таблица:

Ниже сводная таблица подписок в разных LLM-провайдерах. Блок "на сколько хватит" я заполнил субъективно из своего опыта работы с опенкло:

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

У Anthropic нормально полноценно живучие тарифы около $200 — они действительно дают уже рабочий объём, но цена получается довольно высокой. При этом Anthropic не очень любит, когда их подписку используют не через их собственные инструменты, а через сторонние системы вроде агентных фреймворков, и иногда аккаунты могут банить.

GLM‑модели в целом неплохие и стоят дешевле, но по моему субъективному ощущению до уровня GPT‑5.2 всё‑таки немного не дотягивают.

Что использую я

Зачем он вообще нужен?

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

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

Он не делает магию и не заменяет мне мозг. Он просто ускоряет задачи, которые я и так умею делать. Это как хороший терминал, IDE или скрипты автоматизации — инструмент, который снимает рутину. В свое время таким ускорителем как раз для меня стал bash-autocompletion или IDE вроде WebStorm.

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

Именно поэтому я стараюсь внедрять его не как «автономного работника», а как помощника в конкретных задачах: там где он экономит время, но не создаёт риска что‑то сломать. Ниже расскажу про примеры задач, которые я уже решал с его помощью, где он был очень полезен.

Кодерский агент через голосовые

Один из самых полезных кейсов, который я сделал — это кодерский агент через Telegram и голосовые сообщения.

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

Я настроил отдельного агента в Telegram. С ним можно общаться обычным чатом или голосовыми сообщениями.

Он умеет:

• принимать голосовые;

• расшифровывать их в текст (или сразу работать с текстом);

• понимать задачу;

• вносить правки в проект;

• создавать Merge Request;

• отправлять мне ссылку на MR.

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

В итоге процесс выглядит примерно так:

1. Я отправляю голосовое или текстовое сообщение с просьбой внести правку.

2. Агент находит нужный репозиторий и вносит изменения.

3. Создаёт Merge Request и ставит его на меня.

4. Присылает ссылку на MR.

5. Я открываю MR, смотрю изменения и оставляю комментарии — ровно так же, как если бы это сделал обычный разработчик.

6. Говорю агенту поправить замечания.

7. Он вносит правки и обновляет MR.

8. Когда всё нормально — я сам мержу изменения.

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

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

С компьютера я бы починил это за две минуты. Но когда ты на телефоне, без IDE, без нормального доступа к проекту — это превращается в мучение. И вот в таких ситуациях как раз и помогает такой агент: можно просто надиктовать голосовое, он внесёт правку, сделает MR, а дальше я спокойно проверю изменения и смержу их.

Как я настраивал кодерского агента

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

Шаг 1. Создать отдельный чат для разработки

Сначала я начал писать в основной канал general и удивился, что бот ничего не отвечает. Потом выяснилось, что в групповых чатах OpenClaw по умолчанию реагирует только если его упомянуть через @mention. После этого всё заработало.

Попытки достучаться и пояснения агента

Шаг 2. Настроить системный промпт

Дальше я привязал к этому чату отдельный системный промпт. В нём я описал роль агента:

• он выступает как разработчик;

• работает только с определённым проектом;

• вносит изменения через merge request;

• не имеет доступа к продакшену.

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

Настройка системного промпта происходит в файле openclaw.json. Вот такой блок у меня по пути channels.telegram.accounts.amorevbot.groups:

"groups": { "*": { "requireMention": true }, "-123123123123 (ид чата)": { "requireMention": false, "groupPolicy": "allowlist", "enabled": true, "topics": { "23": { "requireMention": false, "enabled": true, "systemPrompt": "Ты отдельный агент для проекта ai-provider. Всегда работай в репозитории /home/ubuntu/.openclaw/workspace-amorevbot/ai-rpovider. Все указания по работе с проектом читай тут /home/ubuntu/.openclaw/workspace-amorevbot/projects/markus-coding/ai-provider/AI_RULES.md и всегда следуй этим правилам!" } } } }

Шаг 3. Дать доступ к репозиторию

Следующий шаг — доступ к Git.

Я создал отдельного пользователя в GitLab специально для агента. Это тоже вопрос безопасности: если что‑то пойдёт не так, этот аккаунт можно просто отключить.

Дальше я:

• создал SSH‑ключ;

• добавил его в GitLab;

• выдал агенту токен доступа.

  
  Передача токена прямо в чате

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

Шаг 4. Первый тестовый запрос

После настройки я дал ему первую простую задачу.

Агент:

1. скачал репозиторий;

2. разобрал структуру проекта;

3. добавил нужные файлы;

4. сделал commit;

5. создал merge request.

Через пару минут у меня уже была ссылка на MR.

Шаг 5. Работа через обычный code‑review

Дальше процесс выглядит ровно так же, как с обычным разработчиком. Я открываю MR, смотрю изменения и пишу комментарии:

• здесь поправь;

• здесь не тот файл;

• тут лучше сделать по‑другому.

Агент читает комментарии, вносит изменения и обновляет MR. Тут ничего нового.

Помощник для написания постов в Telegram

Ещё один кейс, который у меня неожиданно хорошо зашёл — помощник для написания постов в мой Telegram‑канал.

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

Поэтому я решил попробовать использовать OpenClaw как редактора и помощника по подготовке постов.

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

Как я формировал промпт

• как я формулирую мысли;

• какие обороты использую;

• как обычно строю структуру постов;

• где добавляю шутки или иронию.

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

Дальше процесс выглядит очень просто. Я могу надиктовать голосовое сообщение или написать несколько тезисов вроде:

• "рассказать про новый инструмент";

• "объяснить почему он интересный";

• "добавить пару практических выводов".

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

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

Для небольшого канала это оказалось неожиданно полезно. Посты готовятся быстрее, а барьер "сесть и начать писать" практически исчезает.

Как я подключал распознавание голосовых сообщений

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

У OpenClaw из коробки есть поддержка голосовых через модели вроде Whisper. Он сам установит локально виспер, настроит его и будет распознавать на мощностях сервера или через облачный (для этого ему надо будет передать api token от openai).

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

Архитектура получилась примерно такая:

1. Telegram‑бот принимает голосовое сообщение.

2. Файл отправляется в сервис транскрибации.

3. Сервис превращает аудио в текст.

4. Текст передаётся обратно агенту.

5. Агент уже работает с ним как с обычным текстовым запросом.

У нашего сервиса есть несколько уровней обработки. Сначала используется основная модель распознавания. Если она не справляется или что‑то падает — есть fallback на другие модели. В итоге система довольно надёжно превращает голос в текст.

Самым "магическим" было то, как я подключал "клешню" к сервису транскрибации. Я попросил другого агента посмотреть как реализована интеграция с нашим провайдером в другом реальном проекте и описать мне все детали (как кидать запрос в очередь, поллить результат, куда слать токен) в виде одного MD файла.

Агент все сам настроил, спросил у меня токен доступа, прописал его куда нужно, добавил hook для обработки голосовых сообщений все магически заработало!

Фактически это превращает Telegram‑чат в голосовой интерфейс для разработки и автоматизации, что оказалось намного удобнее, чем постоянно печатать длинные сообщения.

Промежуточные итоги

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

1. Это точно не «магический ИИ‑сотрудник».

Все истории из интернета про то, что агент полностью заменяет людей, сильно преувеличены. Экономика и надёжность пока просто не позволяют так работать. Агент может делать отдельные задачи, но оставлять его полностью без контроля — довольно рискованная идея.

2. Это очень хороший усилитель продуктивности.

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

3. Самое важное — правильно ограничивать агента.

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

• кодерский агент не имеет доступа к продакшену;

• агент работает в отдельной виртуалке;

• все изменения проходят через MR и ручную проверку.

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

4. Лучше всего работают очень конкретные задачи.

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