MCP, Skills, Tools и Subagents: в чём разница и как меняется стек ИИ-агентов в 2026

Сразу вывод: Tools, MCP, Skills и Subagents — не четыре взаимозаменяемых названия продуктов, а четыре разных слоя в стеке агентов 2026 года. Tools — это вызываемые контракты, которые видит модель (имя + JSON Schema). MCP — протокол обнаружения и вызова между Host и внешними процессами инструментов. Skills — процедурные плейбуки по запросу (как делать работу). Subagents — делегированные агенты с собственным контекстом. Свести их к одному модному слову — значит отлаживать не тот слой.

Текст актуален на 11 сентября 2026. Мы уже разобрали что такое MCP, JSON-поток данных Agent и JSON Schema как контракт. Здесь только ответы на: что принадлежит каждому слою, как они складываются и куда сходится стек 2026.

Четыре слоя одним взглядом

Когда говорят «добавить агенту инструмент», часто имеют в виду четыре разные вещи. Сопоставьте фразу с этой таблицей:

Одной фразой: Tools — «что можно вызвать»; MCP — «откуда берутся инструменты»; Skills — «как делается эта работа»; Subagents — «кто делает и в каком контексте». JSON Schema проходит через Tools и MCP; Skills и Subagents в основном управляют промптами, политикой и границами сессий.

Tools: контракт вызова перед моделью

Tool (или Function) — наименьшая вызываемая единица, которую видит модель. Названия у вендоров различаются — OpenAI Tools / Function Calling, Anthropic Tool Use, Gemini Function Declarations — но форма одна: вы объявляете инструменты; модель возвращает структурированные tool_calls; Host выполняет их и записывает результаты обратно в чат.

Определение инструмента обычно выглядит так:

{
  "type": "function",
  "function": {
    "name": "validate_json",
    "description": "Validate JSON text and return parse errors.",
    "parameters": {
      "type": "object",
      "properties": {
        "text": { "type": "string" }
      },
      "required": ["text"],
      "additionalProperties": false
    }
  }
}

Поведение реально ограничивает JSON Schema: имена полей, типы, required, additionalProperties. Модели можно менять; Schema не должна «плыть» вместе с ними. См. почему Tool Calling зависит от JSON Schema про дисциплину валидации. Здесь главное простое: текстовое описание инструмента без Schema в 2026 уже не считается продакшен-контрактом.

Граница слоя Tools жёсткая: он не решает, работает ли реализация в том же процессе или удалённо, и не решает, как дробить многошаговую работу. Это зоны MCP и Skills / Subagents.

MCP: межпроцессный сокет инструментов

MCP (Model Context Protocol) отвечает на вопрос, как инструменты и контекст обнаруживаются и вызываются вне процесса Host. Сообщения — JSON-RPC 2.0; типичные методы — tools/list, tools/call, плюс Resources / Prompts. MCP Client внутри Host (Cursor, VS Code, Claude Desktop, …) подключается к MCP Server и переводит открытые инструменты в массив Tools, понятный модели.

Правильный стек:

1. MCP Server описывает каждый tool через inputSchema (всё ещё JSON Schema);
2. Host вызывает tools/list и мапит результат в Tool-объявления модели;
3. Модель эмитит tool_calls;
4. Host шлёт tools/call на Server и пишет result обратно в диалог.

Называть MCP «ещё одним Function Calling» — самое частое заблуждение 2025–2026. Function Calling живёт на границе API модели; MCP — на границе Host ↔ Server. Актуальная спецификация — 2026-07-28: без session handshake; запросы несут _meta. Подробности: гайд по MCP и гайд по миграции.

Когда MCP не нужен: один процесс, инструменты зашиты в Host, нет переиспользования между приложениями — достаточно Tool Calling. Когда нужен: один и тот же Server в IDE / десктопах, изоляция процессов, динамическое обнаружение списка инструментов.

Skills: переиспользуемые плейбуки «как делать»

Skill — это не ещё один tool, а процедурное знание, которое агент может подгрузить по запросу: когда включать, какие шаги, что проверять, какими инструментами можно пользоваться. В инженерной форме чаще всего это SKILL.md в репозитории (или эквивалентный пакет правил): заголовок, условия триггера, чеклист, запреты, пути связанных скриптов.

Сравнение с Tools / MCP:

В 2026 IDE-агенты считают Skills гражданами первого класса: короткие задачи — встроенные возможности; длинные потоки, командные нормы и ops-плейбуки живут в Skills, чтобы не вставлять весь справочник в system prompt каждый раз. Skill может направлять, какие Tools вызывать, и задавать гейты вроде «сначала проверь JSON, потом submit» — но обычно это не JSON-RPC-метод.

Частая путаница: упакованный shell-скрипт называют и Skill, и Tool. Правило большого пальца — если модель вызывает его один раз через Schema и получает структурированный результат, это Tool; если документ говорит агенту «сделай эти пять шагов, при необходимости вызывай инструменты», это Skill.

Subagents: делегирование с изолированным контекстом

Subagent — дочерняя сессия, которой делегирует родитель: обычно своё окно контекста, более узкий system prompt, более жёсткий allowlist инструментов и summary, возвращаемый родителю. Это не «ещё одна функция»; это борьба с загрязнением контекста и параллельное исследование.

Типичные применения:

• Изолированный поиск — потомок роется в репозитории или логах; родитель оставляет только вывод.
• Параллельная работа — правки фронтенда, тесты и перевод текстов идут без борьбы за один контекст.
• Узкие роли — security review, обход кода, диагностика CI — у каждого свой prompt и набор инструментов.

На практике Subagent часто открыт родителю как особый Tool (например Task / spawn_agent): аргументы — описание и тип задачи; возврат — финальный ответ потомка. Это не значит Subagent = Tool. Tool — поверхность вызова; Subagent — другой stateful цикл рассуждения.

Граница со Skills: Skill говорит «как»; Subagent решает «открыть другую сессию, чтобы сделать». Skill может требовать «сложный triage обязан запустить CI Subagent»; тот Subagent затем грузит свои Skills и Tools.

Как складываются четыре слоя

В реальной задаче часто задействованы все четыре. Пример: «написать пост в блог и задеплоить» (иллюстрация, не внутренний протокол этого сайта):

1. Родитель загружает Skill — «чеклист публикации блога»: тело, локали, sitemap, IndexNow.
2. Родитель вызывает Subagent, чтобы исследовать исторические шаблоны статей и не тащить десятки HTML в основной контекст.
3. Основная сессия правит фронтенд через Tools (чтение/запись файлов, shell); если инструменты живут вне процесса, обнаружение и вызовы идут через MCP.
4. Где появляются структурированные параметры, JSON Schema по-прежнему фиксирует поля — особенно для того, что уходит с машины.

Поток данных в одну строку:

User → Host / parent agent
      → Skills (pick the workflow)
      → Subagents (optional delegation)
      → Tool declarations (for the model)
      → optional MCP Client ↔ MCP Server
      → results written back into the dialogue

Шпаргалка по отладке: модель зовёт не тот инструмент → Tools / Schema; процесс инструмента не коннектится → MCP; шаги постоянно пропускаются → Skill; контекст раздувается или загрязняется → Subagent.

Что меняется в стеке агентов 2026

По сравнению с «запихнуть функции в prompt» 2024 года, 2026 сжимается в пять сдвигов:

Ещё одна линия — слияние структурированных выходов с аргументами инструментов: бизнес-JSON, аргументы tools и MCP inputSchema живут под одной Schema-дисциплиной. См. что такое structured output и сравнение OpenAI vs Gemini.

На стороне продукта IDE-агенты больше не «чат + автодополнение»: в дефолтном стеке есть tool calling, MCP-коннекторы, каталог Skills и порождаемые субагенты. Для разработчиков это значит: вы поставляете не только API, а обнаруживаемые инструменты (MCP/Tools) + соблюдаемые процессы (Skills) + роли, которые можно делегировать при необходимости (Subagents).

Что выбирать и писать сейчас

• Сначала Schema, потом экспозиция инструмента. Поставьте additionalProperties: false, заполните required; проверьте примеры arguments в браузере инструментами этого сайта.
• Оборачивайте в MCP Server только когда инструменты нужно переиспользовать между приложениями. Один скрипт, вшитый в один Host, MCP не требует.
• Повторяющиеся командные процессы кодируйте как Skills. Публикация, миграция, triage, security review — если шаги стабильны, перестаньте полагаться на «не забыть напомнить модели».
• Дробите Subagent, когда контекст разрастается. Делегируйте exploratory, read-only и шумные задачи; решения и финальные патчи оставляйте родителю.
• Не подменяйте Schema Skill’ом и MCP — Subagent’ом. Процесс ≠ контракт ≠ транспорт. Смешение даёт «в доке написано валидировать», а в проде проверка никогда не бежит.

Для локальных JSON-проверок сохраните inputSchema, примеры arguments модели и примеры result от MCP tools/call, затем используйте JSON-валидатор и JSON Diff. Ничего не уходит из браузера — тот же on-device-first подход к приватности.

FAQ

Итог

Tools определяют, что модель может вызвать; MCP — как инструменты обнаруживаются и вызываются из внешних процессов; Skills — как работа делается по книге; Subagents — как контекст изолируется и делегируется. Стек агентов 2026 сходится от «одного чата + ad-hoc функций» к этим четырём слоям плюс поясу контрактов JSON Schema.

Наращивайте стек изнутри наружу. Сначала доведите Schema и Tools; затем добавляйте MCP, Skills или Subagents под давлением переиспользования, процесса или контекста. Прогоните примеры локально до релиза — модели можно менять; имена полей и required — нет.