Роман про OpenClaw

❓ Sandbox поменял, а агент работает по-старому

Есть неприятная ситуация, которую легко принять за баг. Меняешь sandbox-конфиг (настройки изолированной среды, где запускается агент: образ, доступы, setup-команды, ограничения), запускаешь агента, ждешь нового поведения, а он будто вообще не заметил изменения.

Причина тут в том, что уже запущенные sandbox-runtime’ы продолжают жить со старыми настройками. OpenClaw не пересобирает их сразу после правки конфига, потому что это могло бы ломать активные сессии и текущие задачи.

Поэтому после изменения sandbox-настроек я пересоздаю runtime вручную:
openclaw sandbox recreate --agent main

Если менялся общий sandbox-конфиг для всех агентов, можно пересоздать все:
openclaw sandbox recreate --all

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

Я обычно придерживаюсь правила - поменял sandbox-настройки - пересоздай runtime перед проверкой. Иначе можно полчаса дебажить поведение, которое на самом деле идет из старой среды.

#какэтоработает

🔐Attach CLI - временный доступ к сессии OpenClaw

Есть удобный инструмент для выдачи доступов - openclaw attach. Он нужен, чтобы подключить внешний CLI-агент к уже запущенной сессии OpenClaw. Например, можно дать Claude Code доступ к конкретной сессии Gateway, чтобы он поработал в том же контексте, а не собирать отдельный доступ вручную.

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

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

Пример подключения:

openclaw attach --session agent:main:telegram:123 --ttl 600000

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

Я бы еще проверял две вещи:
🔸 подключаешь именно ту сессию, где лежит нужный контекст;
🔸 TTL ставишь под задачу, а не с большим запасом.

Так доступ будет контролируемым инструментом, а не дырой, которую потом забыли закрыть.

#полезныеинструменты

Все отдохнули?
Понедельник день тяжелый - так что не буду грузить сложными темами 😄

На выходных наткнулся на интересную статейку про эксперимент «Smallville» от Stanford University, Google Research и Google DeepMind. Исследователи сделали маленький мир в духе игры The Sims, поселили туда 25 ИИ-персонажей и дали им память, планы, наблюдения и возможность общаться друг с другом.

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

Меня зацепила не столько тема «оживших NPC», хотя для игр это тоже мощно, а скорее то, что поведение модели можно смотреть на дистанции, когда решения накапливаются, память влияет на планы, а социальные связи начинают менять сценарий (социальные связи у агентов, приплыли…).

🔥 Короче, звучит круто и интересно, советую почитать. Можете загуглить название эксперимента или почитать тут на русском.

📊 Пятничная полезная фишка про проверку расхода

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

В OpenClaw это можно смотреть прямо из чата через команду /usage.

Самые полезные команды:
🔸 /usage tokens - короткий футер с входными и выходными токенами;
🔸 /usage full - больше деталей по модели, контексту и примерной стоимости;
🔸 /usage cost - локальная сводка стоимости по логам OpenClaw;
🔸 /usage off - выключить футер;
🔸 /usage reset - вернуть режим по умолчанию из конфига.

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

Еще полезно периодически смотреть /status - там видно текущую модель, токены сессии и оценку стоимости, а если провайдер отдает usage-данные, OpenClaw может показать еще и состояние квоты.

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

Хороших выходных!

#полезныеинструменты

💬 Мини-фишка для тех, кто работает с агентом через Telegram

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

Например, вы отправляете задачу агенту, появляется «печатает…», ждете сообщение - а ничего не приходит. При этом агент не завис и телеграм тоже работает нормально.

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

Есть четыре варианта настройки typingMode:
🔸instant - включать «печатает…» сразу после запуска;
🔸thinking - когда агент уже начал активно работать над задачей;
🔸message - только когда формируется видимый ответ;
🔸never - вообще отключить.

Я для телеги в большинстве случаев ставилю message. Особенно если агент работает в группе или у него есть фоновые сценарии, которые вполне могут закончиться без сообщения. Тогда он не будет несколько секунд изображать бурную переписку, а потом молча исчезать 🙂

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

Кстати, попробуйте отгадать по какому фильму нейронка сделала “мем”

#полезныеинструменты

🔥 Хочу рассказать про AI-агента, которого я сделал для нашей 1С.

Как-то ко мне пришли коллеги, которые плотно работают с 1С, с запросом: "Можно ли часть постоянной рутины переложить на агента и тем самым разгрузить команду?".

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

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

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

📌 А вместе с этим запустили партнерку:
Если знаете предпринимателей или компании, которые работают с 1С, можете просто поделиться контактом. Дальше наши ребята сами свяжутся, покажут НейроСотрудника и расскажут про подключение.

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

Я уже сам позакидывал рефералку знакомым 😄
Так что делюсь вариантом как можно подзаработать на ИИ, тем более сейчас все активно идут в AI и автоматизацию.
Win-win так сказать

👉 Подключиться и узнать подробности можно тут

⚠️ Что делать если агент падает при выполнении задачи

Недавно при работе с агентом я поймал ошибку The agent run failed before producing a reply, при повторной постановке задачи она опять вылезла и я полез разбираться в чем проблема. И оказалось, что это довольно распространенная ошибка.

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

Для таких случаев в OpenClaw есть инструмент - model failover. Это по сути страховка, которая позволяет агенту не падать сразу, а попробовать другой auth-профиль у текущего провайдера и затем перейти на резервную модель из agents.defaults.model.fallbacks (которые заранее нужно задать).

Но есть важный нюанс - если модель выбрана вручную через /model, model picker или смену модели в статусе, такой выбор важнее инструмента, поэтому OpenClaw не будет отвечать другой моделью, потому что пользователь явно закрепил конкретную.

Так что, если увидите такую ошибку (а такое наверняка произойдет), сначала проверьте:
🔸 что показывает /status по текущей модели
🔸 нет ли ручного выбора модели в сессии
🔸 задан ли список agents.defaults.model.fallbacks
🔸 повторяется ли ошибка после /model default (если закрепляли модель)
🔸 нет ли лимита или временного сбоя у провайдера

И уже потом лезть в промпт или саму задачу - если это не помогло.

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

🧠 Память должна попасть в контекст до ответа

Есть тонкость с памятью агентов, про которую хочу рассказать в этом посте

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

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

Минимальный вариант настройки для личного чата выглядит так:
{
"plugins": {
"entries": {
"active-memory": {
"enabled": true,
"config": {
"enabled": true,
"agents": ["main"],
"allowedChatTypes": ["direct"]
}
}
}
}
}

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

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

Проверить работу можно через /verbose on и /trace on. Там будет видно, нашлась ли релевантная память перед ответом.

#полезныеинструменты

🔀 Как перенести диалог с агентом в другой чат

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

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

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

Например, если telegram и mattermost связаны с одним пользователем через session.identityLinks, можно написать в личном чате:

/dock_mattermost

После этого текущая сессия продолжит жить как раньше, но ответы будут приходить в mattermost - довольно удобная переадресация.

Что важно:
🔸 docking работает только из личного чата, не из группы;
🔸 каналы должны быть заранее связаны через session.identityLinks;
🔸 история и контекст остаются в той же сессии, просто ответы приходят в другой канал;
🔸 доступы и права не обходятся, меняется только место доставки ответа;
🔸 обратно можно переключиться командой для исходного канала, например /dock_telegram.

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

#полезныеинструменты

🔎 Канбан для агента прямо в панели

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

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

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

📌 Включается просто - команда openclaw plugins enable workboard, перезапуск, и в навигации панели появляется вкладка. Пока плагин выключен, вкладка скрыта, а отдельной конфигурации у него нет - только вкл/выкл.

👉 Удобно, когда хочется видеть задачи агента в одном месте, а не выискивать их по переписке.

🤨 Больше агентов - не значит быстрее

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

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

Поэтому просто навешать агентов - значит размазать те же ресурсы по большему числу сущностей и быстрее не станет.

Как нужно с этим работать:
1️⃣ Сначала каждому агенту прописывают контракт - что он делает, что не делает, куда передает чужую работу.
2️⃣ Потом настраивают приоритеты и лимиты параллельности под ценность каждой задачи, например через maxConcurrent в конфиге.
3️⃣ И только если агентов реально много, добавляют координатора, который разруливает дубли и передает задачи между ними.

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

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

💡 Память агента, которая сама наводит порядок

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

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

🔸 Второй - Dreaming, и вот он как раз про долгую память, но по умолчанию выключен. Раз в сутки агент прогоняет накопленное через три фазы: сначала сортирует свежие сигналы и отсеивает дубли, потом ищет что всплывало несколько раз за разные дни и только в конце решает, что реально достойно попасть в MEMORY.md. Важно понимать, что Dreaming не чистит мусор - он наоборот продвигает сильные сигналы в долгую память, автоматизируя перенос «важного из заметок → в MEMORY.md», который иначе пришлось бы делать руками.

Включается это одной настройкой в конфиге, либо просто командой /dreaming on в чате.

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

👉 Так что, если агент частенько забывает важное - попробуй включить Dreaming, это лучше, чем постоянно вручную вести MEMORY.md.

❓ Почему простой вопрос вдруг стал дорогим

Наткнулся на кейс в issues OpenClaw и там автор заметил, что после пары сотен сообщений агент начал упираться в лимит токенов, причем второй раз - уже через 20–30 сообщений, хотя запросы были простые.

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

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

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

📌 Вот сам кейс, если кому интересно

⚙️ Как ставить задачи агенту, не останавливая его

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

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

Остальные режимы:
🔸 followup - не трогает текущий запуск, ставит сообщение в очередь и обработает после;
🔸 collect - копит несколько сообщений и сливает их в один ход после паузы;
🔸 interrupt - обрывает текущий запуск и сразу берет самое свежее сообщение.

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

P.S. steer и followup легко перепутать, но разница простая. steer подкидывает новое сообщение в текущую работу агента — он увидит его перед следующим шагом модели и сможет скорректировать дальнейшие действия. followup же текущую работу вообще не меняет - агент сначала полностью ее закончит, а уже потом возьмет новое сообщение как отдельную задачу.

📋 Пятничная полезная подборка

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

Смотрите в карточках, если будут вопросы - пишите в комменты, отвечу 🤝

⚡️️ Расскажу немного про платформу, на которой мы сами собираем AI-агентов.

Изначально я вообще делал ее для своей команды. В какой-то момент надоело на каждом проекте заново подключать модели, настраивать базы, память, RAG, окружение и кучу мелочей вокруг самого агента. Поэтому постепенно собрал все, что нужно нам самим, в одном месте. Сейчас внутри уже есть LLM, базы данных, память, RAG, Git, Python, JavaScript, свои ноды - в общем, все то, чем мы реально пользуемся в разработке.

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

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

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

👉 Попробовать платформу можно тут