Роман про OpenClaw

🔍Как работает поиск по памяти в OpenClaw

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

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

Поиск идет двумя путями одновременно.
🔸 Первый - векторный, он ловит смысл. Запрос «как настроить хост» найдет заметку «конфигурация сервера», хотя слова разные.
🔸 Второй - keyword-поиск, он ищет точные совпадения по словам. ID ошибок, названия параметров, ключи конфига - то, что векторный поиск может пропустить из-за редких или специфичных терминов.

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

📌 Что из этого следует на практике:
Короткие заметки с конкретными фактами и датами ищутся точнее, чем один огромный документ со всем подряд и если агент записывает что-то важное в daily-заметки, эта информация автоматически всплывет выше при следующем поиске - просто потому что она свежая.

🤨Еще раз про контекст - потому что это важно

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

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

Например, типичная ситуация - вы написали подробный SKILL.md на 500 строк, агент его читает, но ведет себя так, будто половины инструкций нет. И вот с помощью /context list и выясняется, что файл обрезался по лимиту bootstrap max/file, и агент видит только первые 200 строк или что другой файл вытеснил ваш скилл из контекста, потому что он больше и загрузился позже.

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

⚙️ Memory flush - встроенный механизм, которой стоит использовать

В OpenClaw есть фича, которую редко упоминают в туториалах, хотя она напрямую влияет на то, сколько контекста вы теряете при каждой компакции - называется memory flush

Работает так - перед тем как сработает авто-компакция (это когда OpenClaw сжимает старую часть диалога в краткое саммари, чтобы не выйти за лимит токенов модели), система дает агенту команду сохранить важные заметки в memory-файлы - MEMORY.md, daily-заметки и все такое. Идея в том, что memory-файлы загружаются с диска при старте сессии и не страдают от компакции, в отличие от истории диалога.

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

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

Что стоит проверить у себя:
🔸 Включен ли memory flush. В openclaw.json это agents.defaults.compaction.preCompactFlushMemory - должно быть true. Если параметра нет или он false, агент не получит предупреждения перед компакцией.
🔸 Достаточно ли буфера до компакции. Параметр agents.defaults.compaction.keepRecentTokens (по умолчанию 20000) определяет, сколько токенов от конца диалога останется нетронутым. Если буфер слишком маленький, flush может сработать слишком поздно и агент не успеет сохранить заметки.
🔸 Есть ли у агента инструкция использовать memory_search. Даже если заметки сохранены, агент должен знать, что перед важными действиями нужно проверять memory-файлы. Это прописывается в AGENTS.md.

Если коротко - memory flush это как автосохранение в фотошопе, если не сохраняться, то можно потерять несколько часов работы в моменте.

🔧 Есть одна настройка, про которую мало кто знает

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

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

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

Проверить, включен ли pruning, можно в openclaw.json - параметр agents.defaults.contextPruning.mode.

📌 Для Anthropic-профилей по умолчанию стоит cache-ttl, и это правильное значение. Если у вас другой провайдер или вы переносили конфиг со старой версии - проверьте, что параметр не пустой.

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

Я тут подготовил небольшую инструкцию и решил поделиться ей с вами.

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

Внутри пошагово разобрал:
🔸 как создать первого AI-агента;
🔸 как настроить его под свою задачу;
🔸 как подключить инструменты;
🔸 как проверить, что все работает.

Без "духоты" и сложных терминов - просто открываешь инструкцию и идешь по шагам.

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

Забрать инструкцию можно через бота, переходите и жмите start 👇
@openclaw_itbot

📌 Два типа cron-задач, которые стоит знать

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

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

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

Лично я все автономное вынес в agentTurn, а в основной сессии оставил только то, что реально требует диалога.

Так что правило следующее:

Если задаче нужен контекст общения - systemEvent, если задача самодостаточная и не должна мешать основной работе - agentTurn.

🔍 Как параллелить задачи?

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

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

Где это реально выручает:
🔸 Параллельный research - запускаешь трех агентов на три темы и через пару минут получаешь три готовых саммари, вместо ожидания пока он закончит с первой, чтобы приступить ко второй
🔸 Фоновый мониторинг - агент следит за CI или логами, а ты работаешь дальше. Если что-то упало, он сам отпишется
🔸 Тяжелые задачи - клонирование репы, прогон тестов, генерация отчета - все в фоне с отдельным таймаутом, и не надо держать окно открытым

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

Выглядит это так:
"agents": {
"defaults": {
"subagents": {
"model": "openai-codex/gpt-5.2"
}
}
}

Дальше в разговоре с основным агентом просто говоришь «собери информацию по теме X, Y и Z параллельно» - и он сам спавнит нужное количество субагентов. Результаты приходят в чат по мере готовности каждого.

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

⚙️ Когда агент зацикливается и жжет токены

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

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

Включается в конфиге:
{
"agents": {
"defaults": {
"toolLoopDetection": {
"maxIterations": 5,
"windowMs": 60000
}
}
}
}

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

⚡️Штука реально полезная, особенно если агент работает “на фоне” и вы не смотрите на него каждую секунду. Лучше пусть система остановит цикл на пятой итерации

❓Что делать с частыми апдейтами

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

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

Переключиться можно одной командой:

openclaw update --channel extended-stable

После этого агент обновляется только в рамках этого канала.

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

📄 Еще один кейс про управление большим количеством инструментов

Обычно модель видит все доступные инструменты как список схем - каждый со своим описанием, параметрами, типами. Когда инструментов 10–15 это ок, но если их под сотню, промпт раздувается и модель начинает путаться. А еще, каждый вызов инструмента это отдельный round trip к провайдеру и на сложных цепочках токены улетают просто на пересылку схем туда-обратно.

В OpenClaw есть экспериментальный Code Mode, который переворачивает эту механику. Вместо того чтобы показывать модели сотню схем инструментов, он дает ей всего два - exec для выполнения кода и wait для ожидания результатов. Модель пишет небольшую программу на JavaScript или TypeScript, а внутри этой программы ей доступен весь каталог инструментов - можно искать нужный, читать его схему, вызывать и комбинировать несколько вызовов в одном прогоне.

Что это дает на практике:
1️⃣ Промпт становится легче - модель не тащит в контексте описания инструментов которые ей сейчас не нужны.
2️⃣Несколько вызовов можно объединить в один блок кода, например, прочитать три файла, отфильтровать результаты и записать сводку - и все это за один exec вместо четырех последовательных запросов к модели.
3️⃣Можно использовать циклы, условия и трансформации данных прямо на стороне агента, без возврата к модели после каждого шага.

Включается через tools.codeMode.enabled: true в конфиге агента.

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

🔍 Нашел интересный кейс про проверку URL перед запросом

Представьте ситуацию - агент получает задачу сходить в сеть и принести данные, вы настраиваете валидацию - перед каждым запросом проверяете что URL не ведет на локальный адрес, не указывает на metadata-эндпоинт, не резолвится в 127.0.0.1. То есть, все чисто и запрос уходит, а через секунду DNS-сервер возвращает уже другой IP и агент стучится на 169.254.169.254, внутренний адрес облачного провайдера.

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

В OpenClaw для этого сделали Proxyline - слой который пропускает весь сетевой трафик агента через настроенный прокси. Блокировка приватных диапазонов, loopback и metadata-адресов происходит не на этапе проверки URL, а в момент реального соединения когда DNS уже отработал и IP известен.

Разница принципиальная - между проверкой и фетчем (запросом к серверу) никто не может подменить адрес.

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

🧠 Как устроена память агента и почему это важно понимать

В OpenClaw нет скрытого состояния, все что агент помнит лежит в plain Markdown-файлах внутри его workspace. Если что-то не записано на диск - после перезапуска сессии этой информации не будет, и это не баг а фича, потому что вы всегда можете открыть файл и увидеть что именно агент «знает».

Работает это через два слоя:
🔸 MEMORY.md - долгосрочная память, туда попадают факты, предпочтения и решения которые должны быть доступны при старте каждой сессии.
🔸 memory/YYYY-MM-DD.md - ежедневные заметки с контекстом, наблюдениями и логами, они не грузятся в промпт автоматически но индексируются для поиска через memory_search.

Из этого вытекает пара неочевидных моментов:
1️⃣ MEMORY.md не резиновый - если он распухает, OpenClaw просто обрежет его при загрузке в контекст и агент перестанет видеть часть того что вы туда записали.
2️⃣daily notes полезны ровно настолько насколько вы про них помните, потому что агент сам в них не заглядывает пока вы явно не попросите.

Что с этим делать на практике:
/context list - показывает что именно попадает в промпт при каждом запросе и сколько это весит в токенах
/context detail - детальный разбор по каждому файлу, видно какой кусок контекста съедает больше всего
openclaw doctor - сырые размеры файлов на диске и статус обрезки, чтобы понять не теряете ли вы часть MEMORY.md

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

Часто оказывается что проблема не в памяти, а в том что половина MEMORY.md просто не влезла.

🔐 Где заканчивается автоматическая защита файлов

OpenClaw работает на вашей "машине" и может читать файлы, запускать команды, писать в директории и первое о чем обычно спрашивают - а что если агент выйдет за пределы своего workspace и полезет куда не надо?

Для этого в OpenClaw есть fs-safe - библиотека которая на уровне файловых операций следит чтобы агент не выходил за границы разрешенной директории. Она ловит path traversal когда кто-то пытается через ../ выбраться из workspace, блокирует симлинки ведущие наружу, не дает распаковать архив с абсолютными путями. То есть, если плагин работает с файлами чисто - он пишет только туда куда ему разрешили, и fs-safe молча пропускает эти операции. А вот попытка записать что-то за пределами workspace - сразу идет в отказ, независимо от того баг это или злой умысел.

Но тут важно не переоценивать защиту. fs-safe — это не песочница, она не изолирует процесс от системы. Если плагину разрешен shell, он все еще может натворить дел через команды, потому что shell работает на уровне ОС а не файловых примитивов.

Библиотека защищает от случайных ошибок в файловом коде, а за осознанные действия плагина отвечает тот кто дал ему доступ к shell.

👉 Так что использовать fs-safe точно стоит, но внимательно следите за доступами которые вы выдали

🔗 Подробнее про архитектуру безопасности можно почитать тут

⚡️️ Почему агент стал работать быстрее

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

Суть в чем - раньше все лежало в ядре - каналы, провайдеры, медиа, плагины. Пакет рос, а вместе с ним росло время старта и количество зависимостей которые грузятся в память даже если вы ими не пользуетесь. Команда OpenClaw пошла по пути декомпозиции - начала выносить тяжелые плагины из коробки. Slack, WhatsApp, Bedrock, Matrix и другие теперь подключаются отдельно, а не висят в памяти.

Если простыми словами - если вы работаете только с Telegram и WebChat, агент не тратит ресурсы на загрузку WhatsApp-канала или Bedrock-провайдера. Меньше памяти в простое, быстрее холодный старт, меньше поверхность для багов.

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

🔗 Тут можно посмотреть отчет по этим доработкам с циферками.

⚡️ ChatGPT-подписка теперь работает как модель для агента

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

Теперь для OpenAI-моделей по умолчанию используется Codex app-server - нативный рантайм от OpenAI. OpenClaw по-прежнему отвечает за каналы, память, cron, медиа и все инструменты платформы, а Codex берет на себя внутренний цикл - состояние треда, продолжение инструментов, сжатие контекста и динамический поиск инструментов.

Что это дает на практике:

1️⃣ ChatGPT-подписка работает как модель для агента - не нужен отдельный API-ключ
2️⃣ Агент не видит все инструменты сразу в промпте - он ищет нужный, когда тот реально требуется. Меньше токенов, меньше путаницы
3️⃣ Нативные инструменты Codex (read, edit, patch, exec) работают напрямую, без лишней прослойки

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

🔍 Как устанавливаемые скиллы проверяются на безопасность

Когда ставишь скилл извне, хочется верить, что его кто-то проверил. На ClawHub (публичный реестр скиллов) этим занимаются три независимых сканера - VirusTotal ищет вредоносный код, статический анализ ловит опасные паттерны, а NVIDIA SkillSpector выявляет скрытые инструкции для агента.

Самое интересное - они почти не пересекаются. Из 67 тысяч проверенных скиллов только 0.69% были помечены всеми тремя одновременно. 82% находок пришли от одного сканера и каждый видит свой тип угроз.

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

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

📌 Но, в любом случае, пользоваться этим реестром куда безопаснее.

🏛 OpenClaw стал некоммерческим фондом. Что это меняет?

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

Наняли постоянную команду из сообщества - инженеры, безопасность, комьюнити, финансы. Появились партнерства с OpenAI, NVIDIA и Microsoft. NVIDIA запустила NemoClaw - установка OpenClaw с open-source моделями в одну команду. Microsoft анонсировала Scout на базе OpenClaw. А University of Michigan открыл целый Institute for Agentic Computing.

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

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

⚙️ Для чего нужен auto mode в OpenClaw

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

В OpenClaw есть третий вариант - auto mode. Суть этой настройки в том, что безопасные команды вроде ls или cat README.md проходят сами, без запросов на подтверждение, а подозрительные проверяет отдельная модель-ревьюер. И только реально рискованные, например rm -rf или curl на незнакомый хост, уходят человеку.

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

Настраивается в терминале через три команды:

🔸 openclaw config set tools.exec.host gateway
🔸 openclaw config set tools.exec.mode auto
🔸 openclaw config set tools.exec.reviewer.model openai/gpt-5.5

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

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

📌 Я бы начал именно с auto, а не с YOLO. Откатить всегда можно, а привычка не глядя жать «разрешить» вырабатывается быстро и дорого.

🤖 Как использовать субагентов в OpenClaw

Про fork и isolated я уже писал. Сегодня про другое - какие паттерны работы с субагентами реально ускоряют процессы.

🔸 Первый паттерн - coordinator-worker.
Основной агент разбивает задачу на части и спавнит по субагенту на каждую. Пока они работают параллельно, координатор готовит инфраструктуру или собирает готовые результаты. Десять постов в блог, которые последовательно писались бы часами, делаются за 15-20 минут.

🔸 Второй - parallel research.
Три субагента одновременно исследуют три разных решения одной проблемы. Каждый идет в свою сторону, не зная о выводах других. Координатор собирает результаты и сравнивает. На выходе три независимых взгляда, а не три вариации одного и того же.

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

💡 Главное правило - паттерны полезны когда задача реально параллелится или когда каждый этап требует свежего контекста