Вчера на конференции, будучи уже немного под шафе на афтерпати, участвовал в дискуссии про нашу любимую троицу: MCP, Skills и CLI.

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

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

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

Этот большой пласт творчества и развлечений с чатиком привёл нас к ролям и агентам, описывающим подробное поведение моделей, но уже не для для развлекательных, а для прикладных задач. Например для создания "агенства" из моделей моделей которые синхронно или асинхронно, или в виде графа решали те или иные задачи, а так же всякие кривые и косые low-code системы яро выдающие себя за no-code системы.

Изначально проблему вызова внешних систем решали через регулярки и логиты, потом появились идеи использовать JSON, а из этого уже выросла идея Function Calling, далее FC (лето 2023), и впоследствии Structured Output, далее SO (2024), для описания тулов работы с внешними системами.

Одновременно с этим очень ярко подсветилась проблема малого максимального контекста, оказалось, что условные 4k-8k-16k токенов это норм для чатика, но совершенно недостаточно для решения более сложных задач и для работы с множеством тулов, да и модели не умели работать с несколькими тулами, но прогресс не стоят на месте.

Тогда же частично эту проблему научились обходить через RAG (Retrieval-Augmented Generation), благодаря ей вместо того чтобы пихать в контекст всё подряд, в него подкладывали только "релевантные" куски, найденные поиском по векторной базе. Модель получала как бы шпаргалку ровно под вопрос, а не всю библиотеку разом. Костыль, конечно, но на тех куцых контекстах он серьёзно расширил круг решаемых задач, однако, добили этот подход рост максимального контекстного окна до сотен тысяч, а потом и миллионов токенов.

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

Параллельно с этим появляются более прикладные агентные решения, агентные в том смысле в котором мы понимаем их сегодня, от вызывающих внешние системы по API, типа deep (re)search, до скриптов и шелов которые работают с файловой системой и например генерят код по описанию, и начинается их массовое внедрение.

Тут же возникает проблема, как нам дать пользователям возможность расширять агента, чтобы агент мог, при этом чтобы ему не нужно было лезть в исходники кодового агента и примерно в это время (конец 2024) начинают появляться первые ласточки в виде FC моделей и чуть позже концепция MCP (Model Context Protocol) которая эксплуатирует подход FC.

Изначально MCP появились потому что модели не умели вызывать консольные тулы и нужен был какой-то простенький формат, пусть даже того же JSON, который будет помогать моделям правильно реагировать на сообщения пользователя и насыщать контекст.

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

Существует путаница из-за трёх стандартов MCP: в качестве локального бинаря по stdio, через сеть по Streamable HTTP и через сеть по SSE. Поэтому далее когда я будут говорить про MCP, то буду иметь ввиду сервер доступный через сеть по Streamable HTTP.

Как правило люди когда критикуют MCP и говорят, что Skills лучше, имеют ввиду stdio режим работы MCP, с чем я полностью согласен, однако, я желаю удачи всем хейтерам MCP при попытке разлить скил с секретными токенами к защищённой системе по сотне другой агентов, ИБ (а если у вас нет ИБ, то хацкеры) будут очень рады этой идее.

Плюсы MCP в том, что тулы всегда висят в контексте, модель не жжёт токены на то чтобы сообразить как эту систему вообще дёргать по API, а секреты и токены живут на сервере, клиенту их знать не надо, что для энтерпрайза и всякой ИБ-шной истории, и единый транспорт и переносимость, централизованное обновление, так как один и тот же сервер цепляется к разным агентам.

Но были и минусы, сотня-другая тулов это сотня-другая жирных JSON-схем, которые мёртвым грузом висят в контексте. Получается тот самый "зоопарк тулов", который не то чтобы хорошо масштабируется.

Скилы (Agent Skills) Anthropic выкатила осенью 2025, скил это папка, в которой лежит файл SKILL.md с инструкцией и рядом скрипты, ассеты и примеры. Код при этом крутится локально, в песочнице самого агента, а не где-то на удалённом сервере как у MCP.

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

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

И вот тут кроется то, из-за чего скилы и MCP это не конкуренты, а разные слои. MCP отвечает на вопрос "откуда взять доступ к внешней системе", а скил на вопрос "как именно с этим работать по правилам конкретного проекта". Скил спокойно оркеструет и MCP-тулы, и вызовы CLI, прописывая когда что дёргать, а заодно умеет накапливать удачные решения, то есть работает для агента чем-то вроде долгосрочной памяти, из которой он потихоньку сам себя достраивает.

Тут забавно, потому что CLI это самая древняя из всей троицы штука, консольные утилиты старше многих читателей этого поста. gh, git, ffmpeg, yt-dlp, aws-cli и ежи с ними, спокойно жили в терминале десятилетиями, так что новизна не в самом CLI, а в том что кодовые и файловые агенты научились им пользоваться.

Популяризацию подтолкнули сами CLI-агенты, сначала aider, потом взлетели Claude Code (начало 2025), следом Codex CLI и Gemini CLI, и понеслось. Харнес из плагина к IDE переехал в терминал, а раз агент уже сидит в шелле, то любой консольный тул для него это просто ещё одна команда, которую он и так знает как звать, потому что весь гитхаб, стековерфлоу и маны с --help он видел на обучении.

И вот тут CLI красиво закрывает ту самую беду MCP с зоопарком тулов. Вместо сотни жирных JSON-схем в контексте у агента один единственный тул "запусти команду", а нужную команду он либо и так помнит, либо подсматривает через --help или поиск. Условные десять тысяч эндпоинтов какого-нибудь гитхаба это не десять тысяч MCP-тулов, а один cli вокруг их API плюс поиск по командам.

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

Сентенцию о том, что спор какая из этих трёх штук лучше это спор ни о чём, всё равно что выяснять что в машине важнее, руль, двигатель или колёса. MCP, Skills и CLI не конкуренты, а разные слои одной системы, и каждый закрывает слабое место соседа.

MCP это про доступ, когда внешнюю систему надо дёргать часто и по-взрослому, с токенами на сервере и тулом, который всегда под рукой в контексте. CLI это про грубую силу и массовость, редкие тяжёлые операции и тысячи эндпоинтов, которые не хочется тащить зоопарком тулов. А Skills это дирижёр, который поверх того и другого прописывает как именно работать по правилам конкретного проекта, да ещё и запоминает удачные ходы.

Так что выбирать тут нечего, надо брать все три и грамотно раскладывать по задачам. В качестве финального аргумента вспомнил цитату из сериала Зачарованные (олды помнят):

Это "заклинание" было произнесено в первой серии сериала и по какой-то странной причине мне запомнилось.

Выкинь любой из трёх и агент потеряет шарм, без MCP больно с защищёнными системами, без CLI имеем зоопарке тулов, без Skills у агента нет ни памяти, ни нормальных сценариев. А вместе они дают ровно то, ради чего всё и затевалось, агента, который и до внешнего мира дотянется, и контекст не спалит, и по твоим правилам сыграет.