MCP, скиллы и агенты
@ai_longreadsДезинформация вокруг MCP и скиллов раздражает. Давайте разберёмся, чем отличаются MCP, скиллы, команды и субагенты, и когда использовать каждый из них.
Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.
MCP, скиллы и агенты
MCP, Skills, and Agents Автор: David Cramer Оригинальный текст
Если вы ещё не в курсе последней волны хайпа: кодинг-агенты (Claude Code, Cursor и т.д. — дальше буду называть их «харнессами») недавно подхватили концепцию скиллов. Как обычно бывает с такими волнами, все сразу провозгласили, что скиллы решают все проблемы, а все предыдущие итерации технологий больше не актуальны. Это, очевидно, не так, и я хочу поделиться своими мыслями.
Определения
Скиллы (Skills, навыки) — это переиспользуемые промпты с опциональными артефактами, такими как скрипты или другие материалы. Обычно они показываются в системном промпте так:
[...] У вас доступны следующие скиллы: - FOO-BAR: Скилл, который делает foo и bar - OTHER-THING: Описание OTHER-THING, который тоже может быть полезен.
Они потребляют контекст только на основе метаданных (примерно имя/расположение и описание), а остальная часть скилла (SKILL.md) загружается по требованию. «Загружается» обычно означает, что содержимое инлайнится в беседу.
Скиллы могут включать дополнительный контент, на который можно ссылаться — обычно это вспомогательная документация или простые shell-скрипты.
Инструменты (Tools) — это простые вызовы функций, которые раскрываются для грамматики агента:
[...] У вас доступны следующие инструменты: - functionOne(): описание первой функции - functionTwo(): описание второй функции
Они обычно потребляют больше контекстных токенов, чем скиллы, но не сильно больше в современных харнессах.
MCP — это переусложнённый протокол, который делает много того, что никто не использует, но для целей нашего разговора сосредоточимся на его способности раскрывать RPC как инструменты.
Многие распространяют обёртку своего API как MCP-сервер, но способ реализации MCP не связан с самим протоколом.
Например, MCP-сервер Sentry может раскрывать дюжину инструментов, но также раскрывает единственный инструмент, который на самом деле является субагентом. Оба делают очень разные вещи, но общее в том, что оба регистрируют себя как инструменты.
Агенты или субагенты — это изолированные агенты, раскрываемые как инструменты. MCP Sentry раскрывает агента use_sentry, который под капотом имеет доступ ко всем инструментам MCP, но всё это упаковано как один инструмент.
Преимущество (и недостаток) агентов в том, что их контекстное окно изолировано. Это значит, что нужно передать ВЕСЬ контекст как параметр для выполнения агента.
Некоторые реализации автоматически берут контекст от родителя, другие делают контекст доступным по требованию (ленивая загрузка), а некоторые позволяют форкать контекст и более сложные поведения.
Скиллы
Вы, наверное, смотрите на определения и думаете «они выглядят очень похоже» — и вы правы! И скиллы, и MCP (точнее, инструменты) предназначены для расширения возможностей харнесса. Разница в способе достижения этого и в практическом применении.
Скиллы — это способ закодировать рутинные задачи, которые вы выполняете или хотите разделить с командой. Это могут быть странности, которые вы пытаетесь решить с помощью LLM, например «упрости этот код», или вещи, использующие внешние скрипты, например «создай pull request»:
# patience/SKILL.md --- name: Patience description: Дать пользователю терпение. --- Сделать пользователя максимально терпеливым, чтобы он дочитал этот пост.
Общая тема: скиллы дают агентам... новые навыки. Это в названии! Эти навыки могут использовать существующие инструменты или предоставлять новые псевдо-инструменты через встроенные скрипты. Они особенно полезны для переиспользуемых промптов или наборов поведений, которые в основном используют локальные бинарники.
Если хотите примеры практических скиллов, посмотрите внутренние скиллы Sentry.
MCP
MCP — это нелюбимое дитя индустрии, и честно говоря, я пишу этот пост, потому что люди всё ещё дико дезинформированы.
Если скиллы учат вас готовить, MCP предоставляет инструменты, чтобы это делать. Инструменты отлично сочетаются с харнессами и скиллами, и MCP — это просто способ раскрывать новые инструменты. Не всё нужно раскрывать через MCP, но для сетевых сервисов это отличный вариант.
Настоящая проблема в том, что MCP получил плохую репутацию из-за множества плохих реализаций. Либо реализации раскрывали слишком много инструментов, либо просто не предлагали особой ценности. Часть проблемы в том, как реализован протокол: подобно скиллам, MCP инлайнится в системные промпты, но это дороже, так как включает схему входных данных. Хуже того, многие MCP-серверы включают много ненужных инструментов, часто неоптимизированных.
Но это не вина MCP! И это не значит, что в MCP нет ценности.
То, что большинство игнорирует в MCP — что он позволяет организациям достичь. Sentry, например, позволяет выбирать, какие группы инструментов включить. Под капотом мы просто выбираем, какие инструменты раскрывать. Это оптимизирует потребление токенов и устанавливает разрешения.
Другая важная вещь, которую часто игнорируют — аутентификация. MCP нативно поддерживает OAuth. Можете добавить auth в свой CLI? Конечно. Но OAuth встроен в спецификацию, что означает, что клиенты получают отличный, безопасный нативный флоу, реализованный один раз для всех сервисов.
Последнее преимущество протокола — он позволяет легко управлять контекстом. Описания инструментов позволяют инжектить неявное поведение. Более того, если вы правильно используете инструменты, вы формируете ответы так, чтобы направлять агента. Например, в MCP Sentry, когда мы возвращаем детали issue, мы возвращаем их как markdown с подсказками, что делать дальше.
MCP предоставляет много возможностей, многие из которых не нужны большинству серверов. При этом многие MCP-серверы не должны существовать (они либо плохие обёртки API, либо действительно заменяемы скиллом). Тем не менее, не удивлюсь, если в будущем MCP будет раскрывать скиллы.
Агенты
По моему мнению, субагенты — это упущенная возможность. Моя мечта — взять наш MCP субагент и сделать его нативным субагентом. Представьте, что можно взять SKILL.md и оформить так:
# my-agent.md --- description: "Взаимодействие с Sentry для диагностики проблем, запросов к трейсам и логам." model: opus-4.5 mcp: sentry: https://mcp.sentry.dev/mcp --- Системный промпт, который направляет агента делать правильные вещи, используя все инструменты Sentry MCP Server.
Преимущество агентов в том, что они полностью инкапсулированы — можно запустить другую модель, полностью изолировать (и полностью изменить) доступные инструменты.
У Amp есть отличные примеры субагентов как инструментов, как и у Claude Code. Вы, наверное, видели, как запускается что-то похожее на task. Это обычно агенты с некоторым контекстом для выполнения относительно изолированного поведения. Deep research в ChatGPT — ещё один пример.
Я даже реализовал систему на основе SKILL в своём харнессе, которая рассматривает каждый скилл как субагент. Это не идеально, есть потеря контекста, но возможности впечатляют.
Для меня эти агенты напоминают паттерн «map/reduce». Вы распределяете работу, собираете результаты и синтезируете.
Команды
Команды, на мой взгляд, мертвы. Они существовали в разных формах в разных харнессах, но это либо скилл (инлайновый), либо субагент.
Мне нечего добавить, можно их игнорировать. Большинство скиллов и субагентов раскрываются как команды — это просто UX.
Всему своё место
Пожалуйста, можем мы прекратить такое мышление? Оно никому не помогает и только создаёт больше путаницы и боли.
Харнессы постоянно итерируют над тем, что работает хорошо, особенно над тем, какой интерфейс хорошо работает для пользователей. Многие вещи выглядят одинаково, но каждый раз, когда кто-то выпускает новое поведение, лидеры мнений интернета решают, что оно заменило всю предыдущую функциональность.
Хочу верить, что у людей добрые намерения, но никому не помогает бегать и кричать «MCP плохо» без нюанса «на самом деле эта реализация MCP плохая». И скиллы, и MCP — при неправильном использовании — вызовут засорение контекста в вашем харнессе. Важно, чтобы все изучили основы того, как всё это работает, а с текущим состоянием технологий это означает управление контекстным окном.
Так что моя просьба: попробуйте скиллы, попробуйте несколько хороших MCP-серверов, и вы обнаружите, что у обоих есть своё место и ценность. Лично я использую два MCP-сервера (Sentry всегда включён, XCodeBuildMCP для iOS) и около дюжины скиллов. Как это изменится в будущем, полностью зависит от рабочих процессов, которые они помогают мне решать.
Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!
Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot