Философия Unix или 1001 велосипед в GenAI решениях

Последние 3 года я наблюдаю небывалый бум GenAI решений. Последний год особенно, с появлением концепции Skill.md. Все пишут скилов и агентов, а затем их объединяют в фабрики. Наличие приставки "dark" зависит от уровня наглости автора - я в свою добавляю, что напоминает мне о том куда я стремлюсь. Сегодня этим постом хочу поделиться об еще одной приставке, которую изобрели инженерные мужи в 1960х-70х годах, доказавшую свою эффективность.

Концепция SKILL.md в ее современном понимании как открытого индустриального стандарта для ИИ-агентов появилась относительно недавно - в конце 2025 года. 

GPT: Октябрь 2025 года: Компания Anthropic впервые представила внутреннюю архитектурную фичу Agent Skills (Навыки агентов) в рамках экосистемы своих ИИ-помощников (в частности, для терминального интерфейса Claude Code). Суть фичи заключалась в том, чтобы упаковать конкретную техническую инструкцию или рабочий процесс в изолированную папку, ядром которой являлся стандартизированный файл метаданных и правил - SKILL.md.   

Декабрь 2025 года: Anthropic вывела этот формат в публичное поле, опубликовав его как открытый стандарт (Open Specification) на ресурсе Agent Skills Specification. 

Начало 2026 года: Концепция пережила настоящий взрыв популярности. Буквально за несколько месяцев спецификацию SKILL.md начали нативно поддерживать и распознавать десятки ведущих инструментов автоматизации разработки и ИИ-клиентов от других технологических гигантов и стартапов: OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI и фреймворки вроде LM-Kit.NET. Концепция также глубоко интегрировалась с протоколом MCP (Model Context Protocol) от Microsoft и Anthropic.

Но придумали ли инженеры что-то новое? Скорее нет, чем да. История идет по спирали и мы наблюдаем очередной ее виток. 

GPT: Философия Unix зародилась на рубеже 1960-х и 1970-х годов в недрах компании Bell Labs (официальной точкой отсчета принято считать 1969 год, когда Кен Томпсон, Деннис Ритчи и их коллеги начали работу над первой версией ОС Unix).

Сам подход формировался годами, а его текстовое описание впервые четко сформулировал Дуглас МакИлрой (изобретатель Unix-пайплайнов) в 1978 году в техническом журнале Bell System Technical Journal. 

Сухая выжимка от Дугласа МакИлроя (другие можно посмотреть на странице в википедии): 

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

Я не ослышался? - "...которые работают с текстовыми потоками..." Последние три года мы то и делаем, что работаем с текстовыми потоками. Любой бинарник с помощью текстов программ и написанных ранее бибилиотек превращается в текст, который обрабатывается моделями, чтобы получить другой текст, который затем запаковывается снова в бинарник (docx, mp4, pptx, pdf - я сейчас про любой формат файлов), используется as is как результат или передается по цепочке дальше. 

Но это не все. Любой программист последние лет 20 (это я за себя сейчас говорю, а так - то конечно же и раньше) каждый день делал в своих проектах одно и то же - добавляя новую функцию он задавался вопросом "а мне эту функцию добавить в какой сервис, какого пакета, какого модуля, какого проекта?". Уровень гранулярности который интересен тут в контексте - пакеты/package. Что такое пакет и что общего у него с tools/skills? 

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

В их основе лежит один и тот же архитектурный паттерн - высокое внутреннее сцепление (High Cohesion) при слабой внешней связанности (Low Coupling).

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

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

Формула трансформации

1. Кодовый пакет + CLI-обёртка = Unix Tool. Если у вас есть библиотека (пакет) для работы с JSON, и вы пишете для неё консольный интерфейс, принимающий строки на stdin и выдающий результат в stdout, вы получаете jq - классический Unix tool.
2. Unix Tool + Семантическое описание (Markdown/Промпт) = AI Skill. Если вы берете утилиту grep, пишете для ИИ-агента файл skill.md, где объясняете: «Этот инструмент ищет подстроку. Передай туда файл и паттерн, на выходе получишь строки», - для большой языковой модели (LLM) этот инструмент становится полноценным «навыком» (Tool/Skill), который она может вызывать через Tool Calling.

Эволюция ИТ-архитектуры идет по спирали. Мы начали с изоляции программ в операционной системе (Unix), перешли к изоляции кода внутри одного приложения (пакеты), а теперь изолируем контекст и поведение для искусственного интеллекта (skill.md).

В чем же тогда разница?

GPT: Разница только в «потребителе» (Consumer) этого интерфейса:

• Пакет потребляет компилятор/интерпретатор (язык программирования).
• Unix-тул потребляет человек в терминале или скрипт автоматизации (bash/zsh).
• Skill потребляет искусственный интеллект (LLM), которому вместо строгой типизации часто нужна семантическая документация на естественном языке, чтобы понять, зачем и когда этот инструмент запускать.

Вы нащупали крутую концепцию. Проектируя логику один раз в виде "чистой функции" (пакета), вы автоматически получаете и тул, и скилл. 

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

Берем любую dark factory которых сейчас пруд-пруди, из нее достаем любые пару Skills и задаемся вопросом. Какова вероятность, что я буду использовать их на своем проекте? Если мне проще свою сырую идею превратить в код скила через 5 минут с любой моделью. А изучение других скилов займет больше. Потому что надо понять что у меня в руках, потом допилить под свои нужды. В этом причина 1001 велосипеда в каждом отдельном продукте.

В Unix (независимо от операционки и версии сборки) тула grep дна и ту же, написанная каким-то инженером (и затем поддерживаемый группой энтузиастов) в свободное от работы время потому что он мог и это решало какую-то проблему, которая не решалась до него. В рождении skill.md пока нет такого порядка и философии. Я начал следовать этой концепции при создании своей фабрики. Она у меня состоит из bricks (те самые skills, у которых больше нагрузки в виде контрактов которые они должны соблюдать передо мной). Но философия unix уже заразила меня - бери brick и переиспользуй отдельно как skills, потому что каждый отдельный brick - это своя завершенная идея, полезная сама по себе, с возможностью конфигурирования "на все случаи жизни" насколько я успел ее заложить. 

Философия Unix - моя путеводная звезда. C реализацией конечно же есть трудности. Как минимум потому что до появления первого пользователя надо позаботиться о маркетинге, а с появлением новых пользователей появляется и необходимость реализовать обратную совместимость, убедиться что навайбкодженый новый инструмент работает так же при добавлении новой фичи как раньше. Но их постепенно научаюсь решать.

И мне все равно будете ли ты использовать RAG для data проектов, или для ведения своего персонального блога или еще как-то. Если появилась задача построить RAG на коленке, я проектирую независимый тул, как если бы он был в моей операционной системе и я просто его переиспользовал. 

В общем руткос свалки одноразовых решений в отсутствии Unix philosophy в производстве skill.md.