Переосмысляя IWE: от набора инструментов к дистрибутиву

Я рассматриваю IWE по аналогии с “железным человеком”, Тамагочи, Аватаром, Мастерской или Букварь из Алмазного века. Но что это будет с технической точки зрения? Кто-то называет это просто, другие говорят о наборе скриптов для работы с ИИ, третьи – экзоскелет мышления с памятью и протоколами. Все три ответа были верными, но ни один не передавал главного: почему это именно система, а не просто инструмент.

Можно говорить, что IWE — это по сути скиллы и MCP-серверы. Но скорее есть другое слово – дистрибутив.

Здесь есть интересная аналогия. Если вы работаете с Linux, знаете разницу между ядром и дистрибутивом. Ядро Linux написал Линус Торвальдс и тысячи разработчиков по всему миру. Это мощная основа, но в чистом виде она мало пригодна для повседневной работы. Ubuntu — это не ядро. Ubuntu — это набор решений о том, как жить с этим ядром: какой файловый менеджер по умолчанию, как настроена безопасность, как выглядит установка, как происходит обновление. Ubuntu использует ядро как основу и делает его пригодным для жизни конкретной группы людей с конкретными задачами.

Claude (Anthropic) — это ядро. Claude Code, Telegram-бот, VS Code — это разные интерфейсы. IWE — это дистрибутив, который живёт поверх этих интерфейсов и делает ИИ пригодным для конкретного способа интеллектуальной работы. Дистрибутив включает: единый способ открывать рабочую сессию и закрывать её; память о прошлых решениях и контексте, которая сохраняется между сессиями; протоколы для стандартных рабочих ситуаций; Pack-систему для хранения доменных знаний; агентов, которые берут на себя рутинные задачи.

Разница от «просто скиллов и MCP» принципиальная. Можно взять чистый Claude без IWE и работать. Как можно взять ядро Linux без дистрибутива и работать, если умеешь. Но дистрибутив — это не надстройка над инструментами. Это решения о том, как инструменты сочетаются, как они настроены, какие умолчания заложены и для кого.

Уточнение по аналогии. У классического Linux-дистрибутива есть жёсткое свойство, которого у IWE нет: Ubuntu намертво связана с ядром Linux, её нельзя поставить на ядро BSD без полного переписывания. У IWE другой замысел: один и тот же дистрибутив работает поверх Claude, GPT, собственного runtime, через явный контракт между дистрибутивом и хостом. Поэтому слово «дистрибутив» здесь уместно в смысле bundle (согласованный комплект протоколов, скиллов, Pack-ов и адаптеров), а не в смысле жёсткой связки с одним ядром. Точнее это portable runtime в духе JVM плюс POSIX-подобный контракт хоста. Аналогия с Ubuntu работает на уровне «не набор скриптов, а единое решение», но не работает на уровне «привязки к ядру».

Архитектура от общего к частному

Чтобы эта метафора не осталась красивой фразой, нужно посмотреть на полную схему.

Слой Что это Аналогия Кто строит
0. Базовая модель Claude, GPT, Gemini Процессор Anthropic, OpenAI, Google
1. Агентный runtime Оркестратор агентов, управление задачами Ядро ОС Команда или вы
2. Протокол инструментов MCP (стандарт Anthropic) Шина данных (USB-C) Anthropic
3. Интерфейс-хост Claude Code, Telegram-бот, VS Code Устройство (ноутбук) Anthropic или Microsoft
4. Дистрибутив (IWE) CLAUDE.md, скиллы, хуки, Pack-система Ubuntu Вы
5. Контент-слой Пакеты знаний, программы, цифровой двойник Прикладные программы Aisystant
6. Персональный инстанс Ваши репозитории, стратегия, история Ваша установленная система Конкретный человек
7. Экосистема Сообщество, клуб, обмен методами Интернет вокруг вашей машины Сообщество

Индустрия агентных систем сейчас движется к чёткому разделению Runtime (слои 0-3) и Application (слои 4-7). Это тот же паттерн, что произошёл с Linux в девяностых: ядро отделилось от дистрибутивов и стало использоваться десятками разных команд. Те, кто строит свой дистрибутив сейчас, получат возможность работать на любом будущем Runtime, будь то Claude, или следующая модель, или совсем другой провайдер.

Важная деталь про слои 2 и 3. Это не IWE. MCP — стандарт Anthropic. Claude Code — продукт Anthropic. IWE использует их, но не владеет ими. Если Anthropic изменит интерфейс, IWE должен адаптироваться, ровно как Ubuntu адаптируется к новым версиям ядра. Это нормально. Путаница начинается тогда, когда дистрибутив строят так, что он намертво привязан к конкретному интерфейсу и при его изменении ломается целиком.

Разные люди описывают IWE по-разному именно потому, что видят разные слои. Разработчик инфраструктуры смотрит на уровни 1-3 и говорит: «это скиллы и MCP». Пользователь смотрит на уровень 5 и говорит: «это программа развития». Методолог смотрит на уровень 4 и говорит: «это протоколы и форматы». Все они правы по своему уровню наблюдения.

Где сегодня IWE не соответствует этой схеме

На сегодня IWE слишком привязан к Claude Code. Когда я открываю рабочую сессию, я открываю Claude Code. Когда сессия закрывается, закрывается Claude Code. Если Anthropic изменит поведение интерфейса, часть протоколов придётся переписывать. Это значит, что дистрибутив ещё не отделён от конкретного хоста так, как должен быть.

Вторая проблема: runtime-цикл IWE нигде формально не задокументирован как спецификация. Реальный цикл работает так: сессия открывается — агент загружает контекст — скилл вызывает MCP — результат записывается в память — закрытие синхронизирует репо. Этот цикл существует, он работает, но он нигде не зафиксирован как инвариант системы, на который могут опираться другие компоненты.

Куда двигаться

Главное архитектурное направление — это сделать IWE по-настоящему независимым от конкретного хоста. Не «настройки для Claude Code», а «дистрибутив, который может запускаться через Claude Code, или через другой интерфейс». Это означает: явный контракт между дистрибутивом и хостом, адаптеры для разных хостов, тесты, которые проверяют поведение дистрибутива независимо от хоста.

Второе направление — Hermes как собственный runtime-слой (уровень 1). Сейчас runtime по сути встроен в Claude Code. Выделение отдельного runtime-слоя даёт независимость: агенты могут запускаться автономно, не только через интерактивный чат, и координироваться между собой через явный протокол.

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

3 лайка

У вас клод стал ядром, хотя он ядром не является, это скорее на MacOs похоже с учётом вендор лок. Мак собственно ядро линукса тоже взял, среди прочих. Всмысле ИИ, правильным ядром была бы любая агентная ИИ. А вот рабочий стол из того же убунту, это как раз только обёртка. Хотя тот же убунту поддерживает разные рабочие столы, т.е. даже набор программ и как это будет выглядеть визуально к дистрибутиву гвоздями не прибито. Я могу на Debian поставить рабочий стол от убунты Gnome, а могу KDE и ещё целую пачку. Тот который ровно мне удобен в силу каких-то моих предпочтений. Поэтому какой плагин в итоге VS Code открывается, плагин от клода или от любого другого ИИ, это как раз вторично. Но и сам VS Code по-хорошему вторичен, потому что у Codex и Cursor свои IDE, свои интегрированные рабочие столы. Оно всё равно всё Environment (desktop, development, etc).

Из нынешнего (если ещё не вчерашнего) IWE реализует harness. Но опять же надо ли новыми страшными словами пугать людей, не знаю. Аналогии полезны, но не точны. Можно было бы IWE по-модному назвать операционной системой для ИИ? Да можно, но проблемы те же, и похоже и не очень. Вы фактически архитектуру задаёте через IWE, чтобы система вот этого личного рабочего конвейера с ИИ на моём ноутбуке с обязательным доступом в интернет (и прочими ограничениями) работала получше, не превращалась в хаос, в легаси, в мусорку, не тупила… Это набор архитектурных правил, которые в том числе реализуются уже неживыми штуками в той или иной мере автоматизированно, а где-то полу-автоматизированно с живым человеком.

3 лайка