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

Как все начиналось

С момента появления GPT-3 я стараюсь следить за развитием LLM. Когда в ИИ-моделях появилась поддержка function calling — примерно два года назад — я загорелся идеей создать виртуального ассистента. Он должен был стать личным секретарём: напоминать о важных событиях, помогать решать задачи на работе и дома, оповещать о таких вещах, как просроченная страховка и другие бытовые дела.

Function calling — это концепция, которая позволяет LLM использовать внешние инструменты.

Идея казалась простой: есть LLM, есть tools — соединяем и получаем ассистента. Но 1,5 года назад я потерпел фиаско: локальные LLM были настолько слабы, что даже с поддержкой tools часто не могли корректно их вызывать. А полноценных облачных решений в российском сегменте тогда ещё почти не было.

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

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

1. Огромные требования к количеству токенов — каждый запрос сжигал десятки тысяч токенов из-за гигантской базы навыков. Модель терялась в выборе и начинала перебирать инструменты, пока не находила нужный.
2. Полный контроль над системой — по умолчанию действует принцип «разрешено всё, что не запрещено». Это создаёт риски: легко что-то забыть запретить.
3. Куча непроверенного функционала — в GitHub лежат репозитории с тысячами навыков для OpenClaw, почти все они сгенерированы ИИ. Никто толком не знает, что они делают и работают ли вообще.
4. Способность агента модифицировать себя и свои навыки — звучит как эволюция, но нет гарантии, что она пойдёт вам на пользу. Плюс — это сотни миллионов лишних токенов.
5. Утечка авторизационных данных в модель — не просто баг, а критическая дыра в безопасности. Уязвимости OpenClaw подробно разбирали в Лаборатории Касперского.

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

Повозившись с OpenClaw, я начал искать альтернативы: Nanobot, NanoClaw, Moltis, SafeClaw, ZeroClaw. Попробовал все, но ближе всего к моему идеалу оказались Moltis и ZeroClaw. Расскажу только о них — остальные заслуживают отдельной статьи.

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

Последняя капля

В Moltis я столкнулся с финальной проблемой, которая и подтолкнула меня к созданию собственного решения — система tools и skills работает плохо.

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

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

Почему я сделал MicroClaw и что это такое

Я решил написать свой фреймворк, который решал бы эти проблемы. Основные принципы:

Безопасность — модель не должна иметь доступ к данным авторизации и к системе.

Эффективность — минимум лишних вызовов модели.

Простота — код должен быть понятным и легко расширяемым.

Python — популярный, доступный язык, мой основной стек.

Архитектура MicroClaw

MicroClaw построен как каркас с чётким разделением ответственности. В основе — агент, который общается с LLM и вызывает инструменты. Инструменты сгруппированы в тулкиты — логические наборы связанных функций.

Channels — интерфейсы общения

Channels — это то, через что я общаюсь с агентом. Сейчас доступны:

• CLI — для локального общения в терминале,
• Telegram — для общения через бота (поддерживает polling и webhook).

Интерфейс каналов унифицирован, поэтому добавить Slack или Discord займёт пару часов.

Agent Core — мозг агента

Agent Core связывает LLM с инструментами. Использует LangChain для создания и управления агентом. Важно: агент не имеет прямого доступа к системе — может вызывать только те инструменты, которые ему явно разрешены.

Toolkits — инструменты

Ключевая особенность MicroClaw. Вместо набора разрозненных инструментов — логические группы (тулкиты), например:

• CalDAV — работа с календарём: создание, чтение, поиск событий,
• CardDAV — управление контактами,
• Email — отправка и чтение почты (IMAP/SMTP),
• WebDAV — работа с файлами на серверах.

Каждый тулкит — отдельный класс с методами, помеченными декоратором @tool. Они автоматически становятся доступными агенту. Данные для авторизации хранятся в настройках тулкита и никогда не передаются модели.

Session Storage — хранилище диалогов

Отвечает за хранение истории. Доступны два варианта:

• Memory — в оперативной памяти (быстро, но не персистентно),
• Filesystem — в JSON-файлах (медленнее, но персистентно).

Безопасность

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

Авторизационные данные изолированы. Логины и пароли хранятся в настройках тулкитов и не попадают в модель. Агент видит только результат выполнения инструмента, но не знает, как он был инициализирован. Даже если модель попытается «вспомнить» доступы — у неё не будет такой возможности.

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

Возможности из коробки

MicroClaw поставляется с готовыми тулкитами:

Работа с почтой (IMAP/SMTP):

• чтение папок и писем,
• отправка писем с вложениями,
• поиск по критериям,
• управление папками.

Работа с календарём (CalDAV):

• создание событий,
• чтение событий,
• поиск по датам.

Управление контактами (CardDAV):

• создание контактов,
• чтение контактов,
• поиск по имени или email.

Работа с файлами (WebDAV):

• загрузка файлов,
• скачивание файлов,
• управление директориями.

Написание своих тулкитов

Создать свой тулкит просто. Пример:

Методы с декоратором @tool автоматически становятся доступными агенту. Данные из MyToolkitSettings не попадают в модель.

Почему Python

Почему не Rust, как у ZeroClaw? Потому что для такого проекта скорость не критична. Важнее:

1. понятность кода — Python проще и популярнее,
2. простота разработки — новый тулкит можно написать за 10 минут,
3. экосистема — огромное количество готовых библиотек для интеграций.

Код MicroClaw написан человеком. Я делал ставку на читаемость, структурированность и поддерживаемость. Я не гонюсь за минимальным количеством строк — важнее архитектура и чистота кода.

Планы на будущее

Мультиагентность

Сейчас в MicroClaw один агент с доступом ко всем тулкитам. В будущем планирую реализовать систему мультиагентности: отдельные агенты с разными задачами и инструментами.

Например:

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

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

Постоянная память

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

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

Это сделает взаимодействие более персонализированным и естественным.

Изолированный запуск инструментов

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

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

Всем привет! Меня зовут Юрчик Олег, на данный момент я — старший Python-разработчик вCloud.ru. Несмотря на то, что в университете я изучал и матанализ, и статистику, и теорвер, и даже моя дипломная работа была связана с нейросетями, к сожалению, я очень далек от глубокого понимания ML и Data Science, так как мой основной род деятельности уже на протяжении 6 лет — это backend разработка. Поэтому прошу специалистов из этих областей, если вдруг увидите в моих рассуждениях что-то ошибочное, пожалуйста, укажите об этом в комментариях или в личные сообщения на Хабре. Заранее благодарю!

Как все начиналось

С момента появления GPT-3 я стараюсь следить за развитием LLM. С момента появления поддержки function calling в ИИ-моделях (это было примерно 2 года назад) я загорелся идеей создать виртуального ассистента, который мог бы быть личным секретарем: напоминать о важных событиях, помогать в решении различных вопросов на работе и дома, а также оповещать о событиях типа просроченной страховки и т.д.

Function calling — это концепция, которая позволяет LLM использовать внешние инструменты.

Идея казалась простой: есть LLM, есть tools — соединяем и получаем ассистента. Но 1,5 года назад я потерпел фиаско: локальные LLM были настолько плохи, что даже с возможностью использования tools очень часто не могли вызвать их корректно, а полноценных облачных LLM в российском контуре еще особо не было.

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

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

1. Огромные требования к количеству токенов— каждый запрос к агенту сжигал десятки тысяч токенов впустую из-за возможности делать любые действия по гигантской базе навыков. Модель просто теряется и не знает, что ей выбрать из огромного ассортимента возможностей и начинает перебирать инструменты, пока не найдет то, что решает проблему.
2. Нужно дать полный контроль над системой, в которой он работает.Конечно, можно поставить ограничения, но из коробки система работает по принципу «разрешено все, что не запрещено», соответственно нет уверенности, что ты не забыл что-то запретить в настройках.
3. Куча непроверенного функционала— вGitHubлежат репозитории с сотнями и тысячами навыков (skills) для OpenClaw и почти все они сделаны нейросетями, никто толком не знает, что они делают, как работают и работают ли вообще.
4. Возможность самостоятельно модифицировать самого себя и свои навыки— звучит круто, получается естественная эволюция агента. Но есть ли у вас уверенность, что эта эволюция будет вам на пользу? Плюс это дополнительные сотни миллионов токенов трат.
5. Все авторизационные данные утекают в ИИ-модель— это уже не просто баг, а дыра в безопасности.Подробноразбиралиуязвимости OpenClaw в Лаборатории Касперского.

С одной стороны, развязанныеклешнируки у агента — это фишка OpenClaw, которая и придала ему популярность, и именно это открыло новый этап развития агентных систем на базе ИИ. Но с другой стороны — агент становится очень опасным инструментом, причем не для окружающих, а для самого пользователя. Повозившись с ним, я начал искать аналоги, в которых бы эти проблемы были решены. Их, действительно, существует очень много:Nanobot,NanoClaw,Moltis,SafeClaw,ZeroClaw.

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

ZeroClaw — отличный проект. Написанный полностью на Rust, работает исключительно с tools (нет системы навыков), за счет чего происходит экономия токенов, чистота диалогов и точность вызова инструментов. Но с ZeroClaw была сложность: tools для него надо писать на Rust и их очень тяжело добавить в работающий контейнер (надо с нуля пересобирать образ). Поэтому решил попробовать Moltis.

Последняя капля

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

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

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

Почему я сделал MicroClaw и что это такое

Я решил написать свойфреймворк, который решал бы эти проблемы. Основные принципы были просты:

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

Эффективность— минимальное количество лишних вызовов модели.

Простота— код должен быть понятным и легко расширяемым.

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

Архитектура MicroClaw

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

Channels — интерфейсы общения

Channels — это то, через что я общаюсь с агентом. Сейчас есть два канала:

• CLI— для локального общения в терминале,
• Telegram— для общения через бота (поддерживает polling и webhook).

Каналы реализуют общий интерфейс, поэтому добавить новый. например Slack или Discord, — дело пары часов.

Agent Core — мозг агента

Agent Core — это то, что связывает LLM с инструментами. Он использует LangChain для создания агента и управления его выполнением. Важно, что агент не имеет прямого доступа к системе — он может вызывать только те инструменты, которые я ему явно дал.

Toolkits — инструменты

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

• CalDAV— работа с календарем: создание событий, чтение задач,
• CardDAV— управление контактами,
• Email— отправка и чтение почты (IMAP/SMTP),
• WebDAV— работа с файлами на WebDAV-серверах.

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

Session Storage — хранилище диалогов

Session Storage отвечает за хранение истории диалога. Есть два варианта:

• Memory— хранение в оперативной памяти (быстро, но не персистентно),
• Filesystem— хранение в JSON-файлах (медленнее, но персистентно).

Безопасность

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

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

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

Возможности из коробки

MicroClaw идет с несколькими готовыми тулкитами:

Полноценная работа с почтой через IMAP и SMTP. Агент может:

• читать папки и письма,
• отправлять письма с вложениями,
• искать письма по критериям.
• управлять папками.

Работа с календарем, например Nextcloud, Google Calendar через CalDAV:

• создание событий,
• чтение событий,
• поиск по датам.

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

• создание контактов,
• чтение контактов,
• поиск по имени или email.

Работа с файлами на WebDAV-серверах:

• загрузка файлов,
• скачивание файлов,
• управление директориями.

Вы можете развернуть MicroClaw на своем компьютере или в облаке. В Cloud.ru, например, есть вся необходимая для этого инфраструктура: можно использовать сервисFoundation Modelsдля запросов к ИИ-модели иContainer Appsдля запуска самого MicroClaw. Это позволит платить исключительно за время работы сервиса, а не месячную цену за аренду виртуальной машины. Ну а я расскажу для начала, как запустить MicroClaw локально.

Самый простой способ — использовать uv. Для этого у вас должен быть установлен Python и, соответственно, сам uv (pip install uv):

Или можно запустить через Docker Compose:

Конфигурация

Центром настройки MicroClaw является файл конфигурации. Создайте файлconfig.yaml, как в примере ниже:

И рядом файл.env:

Написание своих тулкитов

Написать свой тулкит очень просто. Вот пример:

Методы, помеченные декоратором@tool, автоматически становятся доступными агенту. Данные изMyToolkitSettingsне попадают в модель.

Почему Python

Вы можете задаться вопросом: «Почему не Rust, как у ZeroClaw? Он же быстрее!».

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

1. понятность кода— Python семантически более простой и более популярный язык,
2. простота разработки— написать новый тулкит на Python можно за 10 минут,
3. экосистема— куча готовых библиотек для всего, на основе которых можно построить свои тулкиты.

Код MicroClaw написан человеком (то есть мной). Я старался, чтобы код был понятным, структурированным, расширяемым и легко поддерживаемым. Я не гонюсь за уменьшением количества строк (LoC), которыми аргументируют другие агенты, — мне кажется, намного важнее архитектура и чистота кода.

Планы на будущее

Мультиагентность

Сейчас в MicroClaw один агент, который имеет доступ ко всем подключенным тулкитам. Но что, если у вас есть разные задачи, требующие разных наборов инструментов? Например, один агент как личный секретарь с доступами к календарю и почте, другой — разработчик с доступами к git репозиториям, третий — исследователь Хабра в поисках интересных статей?

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

Постоянная память

На данный момент MicroClaw хранит историю диалога в сессии, но не имеет постоянной памяти о пользователе. Это значит, что если вы скажете агенту «мой день рождения 15 мая», он запомнит это только в рамках текущей сессии.

Постоянная память позволит хранить важную информацию о пользователе между сессиями:

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

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

Изолированный запуск инструментов

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

Заключение

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

GitHub:https://github.com/OlegYurchik/microclaw

Кстати, 9 апреля будет большая конференция про ИИ и облака — GoCloud 2026. Если будете на ней офлайн,запишитесь на воркшопы. Про агентов будет две темы: как легко и просто создать enterprise-ready агентов и как работает AI-агент внутри контейнерной безопасности.