CorpClaw-Lite или как я сделал безопасный аналог OpenClaw

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

Предыстория

В начале года сильно захайпился проект OpenClaw (он же ClawdBot, он же MoltBot), весь ИИ рынок до сих пор сходит от него с ума, создавая свои форки, добавляя его в свои контуры, продавая подписки для работы с ним и даже обучая специализированные LLM для работы с ним.

И интерес ^[1] от части можно понять: это по-сути первый крупный проект, который позволяет автоматизировать задачи с помощью LLM, объединяя в себе все актуальные фичи, такие как MCP, Skills, и другие, при этом ставший родителем соцсети для ИИ (Moltbook). Но если разобрать проект на составные части, он по своей сути не является чем-то инновационным и новым, скорее он первый (по крайней мере в масштабе того охвата который он получил) кто объединил все в одном месте и позволил действительно автоматизированно, без постоянного вмешательства пользователя, решать задачи с помощью LLM.

Но с самого начала этого хайпа у меня было несколько вопросов:

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

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

3. Что по работе с локальными LLM?
   Облачные модели, это конечно, круто, но что если хочется подключить свою модель?

Первый вопрос от части решается запуском проекта в Docker.
Второй по-сути архитектурное ограничение.
Третий в целом уже закрыт официальной поддержкой Ollama. Но это все еще не означает, что локальная модель размером 4-8 миллиардов параметров сможет уверенно справляться со всеми задачами.

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

Так я и приступил к реализации CorpClaw-Lite. Проекта, который должен позволить тем, кому нужно сохранять безопасность и конфиденциальность как ключевые принципы, внедрить современные LLM для автоматизации рутинных задач, не беспокоясь о том, что ИИ что-то удалит или «сольет».

---

В чем особенность CorpClaw?

1. Строгая контейнерная изоляция и запрет на доступ к сети

Каждый пользователь работает в своем изолированном Docker-контейнере. Его файлы доступны только ему и он никак не может взаимодействовать с файлами и пространством других пользователей. Контейнеры запускаются с network_mode: none — полный запрет сети. Все операции, требующие доступа в интернет (например, web_fetch), вынесены на хост (можно и вовсе вынести на удаленные MCP на стороннем хосте).

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

Коммуникация между хостом и контейнером защищена HMAC-SHA256 подписью и защитой от replay-атак. Контейнер даже при компрометации не сможет получить доступ к данным других пользователей — каждый workspace монтируется только в свой контейнер.

2. RBAC (ролевая модель)

В проект заложена логика ^[2] доступов по департаментам, за счет чего каждый пользователь имеет доступ только к тем инструментам, которые соответствуют его деятельности, а добавление нового пользователя не требует ручного управления выдачей доступов к необходимым инструментам.

Сейчас реализовано 10 департаментов, каждый со своим набором доступных инструментов и бюджетными лимитами (количество итераций, tool calls, время выполнения). Секретарь из HR не сможет запустить exec_script, а бухгалтер не увидит search_files по чужому workspace.

3. ToolGuard

Проверка доступности выполнения инструмента выполняется ДО каждого вызова инструмента. Даже если пользователь как-то уговорит модель выполнить rm -rf — команда должна будет заблокироваться ещё до факта её выполнения.

• 20+ YAML-правил с regex-паттернами на аргументы инструментов.

• Правила разделены по severity: CRITICAL (автоблок), HIGH (запрос подтверждения), MEDIUM (запрос подтверждения), INFO (логирование).

Плюс есть Smart Approvals — вместо слепого «разрешить/запретить» LLM оценивает реальный риск команды. Если операция безопасна — выполняется автоматически. Если неоднозначная — пользователю приходит inline-кнопка в Telegram с запросом подтверждения. Подтверждения и блокировки также реализованы на уровне UI бота — агент физически не может выполнить заблокированную операцию.

4. Упор на работу с локальными LLM

Агенты работают по принципу классического ReAct, при этом шаблоны и промпты максимально отлажены под условия работы с локальными моделями. Это означает, что стабильность выполнения даже многошаговых задач очень высокая, но при этом никто не запретит вам пользоваться облачной моделью. И уж если локальная справляется (стабильность на Qwen3.5 9B в Q4_K_M очень хорошая), то у облачной вообще проблем быть не должно.

Для локальных моделей без нативного function calling реализован XML Tool Calling — парсинг tool call из ответа модели:

<invoke><name>read_file</name><arguments>{"path": "report.xlsx"}</arguments></invoke>

Двухуровневый парсинг: native SDK → XML fallback → JSON repair loop. Это должно дать стабильную работу инструментов на моделях, которые формально не поддерживают function calling.

Также реализован LLM Router — можно маршрутизировать разные задачи на разные модели. Vision-задачи на модель со зрение ^[3], консолидацию на локальную поменьше, агентные цепочки на модель покрупнее. Всё через простой YAML-конфиг.

И есть система калибровки — можно использовать облачную модель, которая проанализирует, как локальная справляется с типовыми сценариями, и автоматически правит системные промпты, описания инструментов и few-shot примеры. После калибровки облако больше не нужно — всё работает на локальной модели. Калибровка правит только YAML/Markdown конфиги, никогда не трогает Python-код.

5. Дополнительные системные инструкции разных уровней + личные предпочтения

Реализовано несколько уровней инструкций помимо общих:

• COMPANY — правила компании

• SOUL — общая логика поведения ^[4] агента

• BEHAVIOR — поведение ^[5] и ограничения

• инструкции департаментов

• личный набор данных о пользователе (имя, отдел, предпочтительный формат общения, наиболее часто выполняемые задачи)

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

6. Система памяти и контроля контекста

Также реализована логика контроля контекста и долгосрочной памяти ^[6]:

– Консолидация — каждые 50 сообщений делается общее саммари через LLM, чтобы сократить накопленный контекст, но в целом сохранить понимание работы. Есть cooldown и защита от консолидации во время активного workflow.

– Сжатие — при превышении 80% порога от максимального контекста. Трёхуровневое: обрезка старых tool results → санитизация → LLM-суммаризация middle с сохранением head и tail.

– БД фактов — хранение долгосрочных фактов в SQLite, в которую агент может писать и читать данные о фактах связанных с пользователем (как расширение личных инструкций).

7. Skills, MCP, плагины, субагенты и инструменты

Динамическое подключение через Hot-reload (скиллы — 5с, плагины и MCP — 10с), расширение по единым стандартам внутри проекта.

18 встроенных инструментов: файловые операции (read/write/edit/list/search), выполнение скриптов (exec_script с таймаутом), веб-запросы (web_fetch с SSRF-защитой), работа с данными (table_query — SQL через DuckDB, chart_generate — графики, convert_format, normalize_excel, pdf_reader), обработка изображений (read_image — отдельный vision-вызов), сравнение текстов (diff_text), память (memory_store/recall), отправка файлов (send_file) и делегирование субагентам (dispatch_subagent).

7 скиллов: code_reviewer, content_writer, doc_writer, translator, excel_normalizer, meeting_summary, data_analyst — с TF-IDF семантическим матчингом и двуязычными стоп-словами (RU+EN).

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

---

Субагенты в CorpClaw

Логика субагентов строится на изоляции контекста, определенном наборе доступных инструментов и инструкций с подключением скилов. Логика такого решения строится на том, что локальная модель ограничена в качестве понимания, стабильности и объеме контекста. Нет смысла грузить в нее все инструменты, MCP, докидывать все это скилами — модель просто «захлебнется». Крупные облачные модели, вероятно, справятся, хотя даже им не рекомендуется подключать много MCP одновременно, но у локальной точно с этим будут проблемы. Поэтому я пошел по пути оркестрации:

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

Сейчас реализовано 5 субагентов:

Плюсы: скорость работы локальной модели, экономия 60–80% контекстного окна.

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

---

Как с этим всем работать?

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

Команды бота

Важное решение по UX: удаление файлов — только через интерактивный UI с inline-кнопками и подтверждением. Агент не может удалять файлы через LLM — даже если «захочет». Это защита от галлюцинаций.

Во время выполнения инструментов бот показывает прогресс:

• 📂 Читаю файл...

• 🌐 Ищу информацию...

Пользователь видит, что бот не завис, а работает.

Что внутри

• ~16 600 LOC Python 3.12+ (strict typing, pyright)

• 806 тестов, ~75% покрытие

• 18 инструментов, 7 скиллов, 5 субагентов

• Apache 2.0 License

Стек: asyncio, Pydantic, OpenAI SDK, Anthropic SDK, python-telegram-bot, Docker SDK, DuckDB, matplotlib

---

Ревью

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

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

Сейчас это первая вполне стабильная версия, которую я пометил как «Бета», так как часть уже реализованного функционала еще до конца не отлажена, так как все тестирования я проводил лично и мог что-то упустить. Но уже в текущем состоянии агент при работе с Qwen3.5 9B стабильно выполняет цепочки с выполнением 2-3 задач и вызовом 5-10 инструментов за 1 пользовательский ввод, что на мой взгляд уже вполне хороший результат.

Интересный факт

Проект называется CorpClaw-Lite, так как исходная версия CorpClaw в процессе исследований и улучшений стала неспособной к дальнейшему развитию и рефакторингу. CorpClaw-Lite стало перерождение с чистого листа и с более глубоким пониманием на опыте ^[7] реализации исходного CorpClaw.

Ссылка на репозиторий: https://github.com/Mage212/corpclaw-lite ^[8]