Я строю свою dark factory и пока что она dusk но шаг за шагом приближаюсь к решению.
В прошлом я создавал AttractorAI как фреймворк на котором можно делать пайплайны. Это был 2024й год. И тогда небыло никакого массового Agent Loop. Мне удалось построить фреймворк на java который позволял строить пайплайны и встраивать в них как детерминированные трансформеры (я их так назвал, не путать с GPT трансформерами), так и трансформеры эксплуатирующие модели. Там же я независимо начал пробовать закидывать в модельку не только промпты, но и сами трансформеры, чтобы она сама выбирала что ей хочется заранать.
Потом я создал другой фреймворк MCPyrex. Начало 2025го. Там главная идея была в том, чтобы юзера сами себе вайбкодили инструменты и потом под видом MCP использовали их сразу же. Фреймворк давал рейки и рамки, чтобы не надо было изобреать колеса разной формы. И давал буст. Но использовал MCP и очень ограничивал меня текстовыми форматами и невозможностью делать что-то вне контекста модели - все что делается через MCP модель видит, хочу я того или нет. Плюс токены, их утекало много. Прочтение файла одним тулом, отправка его через другой тул, прочтение результата. Везде токены.
Сейчас в 2026м в моем новом фреймворке все базируется на скилах. Почему скилы? Потому что все поторопились с MCP. Была попытка сделать USB кабель для агентных систем, но он заставил всех владельцев бекенда писать рядом со своим старым добрым RestAPI сервисом еще один - MCP. Зачем? Ко-то подумал и сказал. Давайте будем делать скриптик, и снабдим его небольшой маркдаун прозой как им пользоваться и пусть моделька ранает его себе. А скриптик будет тоненьким клиентом, который будет стучаться на удаленный бекенд и через старый добрый RestAPI получать что-то в контекст.
Но концепции скила мне не было достаточно. Я добавил несколько новых обязательств, и объединил их в концепцию Brick.
Во-первых мне надо было тестировать как-то эти новые скилы. Я не вижу что юнит тестами модели хорошо оперируют. Потому я придумал на базе snapshot testing отдельный brick который может взять маркдаун, специально размеченный и заранать его как интеграционный тест. В тексте маркдауна есть как команды которые надо вызвать в терминале, так и аутпут этой компаны после запуска. Так же там есть и проза, которая помогает модели и читателю уяснить, что мы ранаем и зачем. Более того тест OS agnostic и запускается в докере на конкретном имадже с конкретным скриптом для пред-установки операционки. Один сандарт описанный в брике тестирования и в каждой папке других бриков появляется папка test с четкой структурой.
Во-вторых я решил, что каждый брик у меня будет состоять из sub-skill каждый из которых будет решать что-то детерминированно внутри новой концепции которую дает брик. Почему? Я не хочу чтобы модель читая skill.md в корне брика и понимая его концепт каждый раз изобретала скрипты, которым обслуживает эту идею. Сабскилы делают это. То есть брик это композит из сабскилов. Но это не все. Каждый сабскилл имеет не только CLI интерфейс, но так же один или несколько публичных методов, которые выглядывают наружу. Зачем? Я могу сделать один брик зависимым от другого не только через agent loop и файлы skill.md но так же я могу заимпортить один сабскилл в теле другого, используя всю мощь детерминированого package import. По сути у меня брик - это микросервис, а сабскилл это пакеты этого микросервиса. CLI интерфейс + skill.md делают их скилами. А публичный метод выглядывающий наружу дает мне все преимущества package из детерминированного мира до времен GenAI. Так что в папке scripts у меня идет серия папок, каждая из которых имеет свою структуру.
У меня есть отдельный брик, который дает возможность писать проверяторы для контрактов бриков, чтобы модель могла перепроверить а правильно ли она сделала тот или иной компонент. Проверяторы - это тоже сабскилы, но они дополнительно отвечают еще некоторым другим контрактам, так чтобы брик проверки мог их интегрировать в сложные конфиги.
Вообще идея конфигов очень важна. Каждый брик и subskill преследуют концепцию unix philosophy. То есть сделайте тул, который делает что-то одно, и делает это хорошо, а так же общается через текстовый ввод и вывод. Заниматься чем-то хорошо - быть конфигурируемым. Чтобы пользователю базово через конфиг (или параметры CLI) можно было кастомизировать работу.
Есть брик, который отдельно дает возможность для любых сабскилов брика делать MCP интерфейс, причем можно создавать разные конфиги и разные наборы под разные нужды. Этот брик лежит себе и не знает ничего про другие, но конфиг то место которое объединяет его с другими скриптами (их публичными методами) в прикладном смысле.
Есть брик, который обвязывает cli агентов (copilot, claude, etc) и дает более простой способ вызвать их внутри какой-то одной задачи через промпт, на какой-то модели. Их использую как сабагентов, если надо обвязать что-то быстро. Ну то есть не то чтобы моделька не справится с copilot cli, но она будет каждый раз что-то городить чтобы сделать это. А у меня уже есть сабскилл брика делающий основные па.
Есть брик для оборачивания гита при работе с некоторыми количеством репозиториев, каждый из которых должен быть в определенной ветке и с поределенными branching моделями.
Есть брик, который делает RAG. Да там все уже за юзера, в докерах ранается векторная база. Но для экспериментов когда нужен хоть какой раг этого вполне достаточно.
Есть брик, который оборачивает Graphify.
Есть брик, который описаывает что такое брик.
Есть брик который описывает как я хочу создавать инструкции/скилы.
Есть брик, который дает возможность коучить юзера по какой-то программе тренинга. При этом добавляется в каждому брику новая папка и артефакт.
Есть брик, который дает возможность сделать UI скрин для этого брика. И потом все UI собираются воедино когда ты поднимаешь его.
Есть брик для оркестрирования сабагентов с детерминированным sdlc-flow (который тоже отдельный брик).
Есть брик, который занимается voice to text, text to voice и делает это с локальным wisper, а так же делает в докере ffmpeg для работы с видео и аудио.
Есть брик, который использует chrome devtool апи для управления браузером.
Есть брик, который делает какой-то небезопасный рисерч сабагентом внутри докера, чтобы если там есть какой-то недоброжелательный контент или prompt injection это осталось внутри докера.
Есть брик телеметрии.
И еще пару десятков таких бриков. Каждый брик добавляет новое измерение в систему с целью синергии. Он не знает про наличие других бриков, но исследует их всех на наличие конкретной для этого брика папки, где есть контент с которым он вкурсе что делать. Решая какую-то задачу, упираясь в ограничения agent loop я не пытаюсь решить ее узко каким-то скилом, который будет одноразовым. Я думаю о том какую абтрактную задачу я могу решить 1 раз, что все пользователи системы будут рады. Бери любой брик (и его брики-депенденси) и используй на проекте как skill и будет тебе счастье. А все вместе они составляют фабрику.
Как-то так.
Сообщения
