Если вы только начали работать с ИИ-агентами, наверное уже встречали в гайдах новые слова: MCP, skills, субагенты, контекстное окно, хуки. Может показаться, что для нормальной работы нужно собрать маленький дата-центр из настроек и подключений. Обычно всё гораздо проще.
Просто сначала нужно понять не «что подключить», а «какую работу я хочу сделать». Уровень задачи сам подсказывает, какой механизм нужен, а какой можно не использовать, чтобы сэкономить время, нервы и, главное, токены.
ВАМ ПРИШЛО ПРИГЛАШЕНИЕ 💌
Приходите к нам в соцсети поделиться своим мнением и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте — шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!
В статье узнаете про четыре уровня работы с агентами: когда хватает обычной задачи в чате, зачем сохранять повторяющийся процесс в skill, для чего нужен MCP и как субагенты помогают в больших задачах. Заодно расскажем про хуки — команду, которую чаще всего понимают неправильно.
Сначала определяем уровень задачи
Начинать лучше с самой простой конфигурации — этот принцип рекомендуют и разработчики агентных систем. Если задачу можно нормально решить одним вызовом модели или одним агентом с базовыми инструментами, дополнительные слои ей будут только мешать.
Но мы писали эту статью не про самый простой способ, поэтому если хотите апгрейдить работу с агентами, выбирайте инструменты под конкретную задачу:
- Задача разовая и укладывается в один запрос — работаете с обычным чатом, донастройка не нужна.
- Процесс повторяется с одинаковой логикой — оформляете его в скилл, чтобы не объяснять контекст заново.
- Нужны данные или действия за пределами текущего чата — своя база, трекер задач, внешний сервис — подключаете MCP.
- Работа распадается на несколько независимых потоков — собираете субагентов под каждый поток.
Эти механизмы спокойно работают вместе. Например, основной агент может получить задачу из Jira через MCP, передать исследование кодовой базы отдельному субагенту, а затем использовать skill с правилами оформления pull request. Поэтому skills, MCP и субагенты лучше воспринимать как разные детали одного конструктора.
Дальше разберём каждый уровень отдельно, с механикой и примерами.
Чем агент отличается от чат-бота
В основе любого чата с нейронкой лежит языковая модель. Она работает как мозг: предсказывает текст и рассуждает над задачей. Сама по себе модель не может открыть файл, зайти в браузер или поменять настройку в проекте — пока к ней не подключат инструменты.
Чат отвечает один раз
В обычном чате модель работает по простой схеме: вы задаёте вопрос, модель даёт ответ, и на этом цикл заканчивается. Если ответ неполный или в нём ошибка, поправить его может только человек — запустить новый цикл.
Модель не может сама сходить проверить факт или что-то изменить. Она опирается на то, что в неё заложили при обучении, а эти знания на момент вашего разговора могли устареть на год или два.
Представьте, что ученого закрыли в комнате без интернета и телефона. Спросить можно что угодно, ответит подробно, но выйти и посмотреть, как дела в реальном мире, он не может.
Агент повторяет цикл, пока не закроет задачу
Первое, что нужно модели, чтобы стать агентом, — инструменты: доступ к файлам, браузеру, возможность редактировать код и запускать команды. Но одного доступа мало, иначе агентом можно было бы назвать любой скрипт.
Главное начинается дальше. Агент — это система, где модель сама выбирает следующий шаг и повторяет один и тот же цикл (agentic loop), пока не закроет задачу:
получил задачу → посмотрел, каких данных не хватает → вызвал инструмент → прочитал результат → решил, что делать дальше → и снова по кругу.
Покажем разницу на примере: попросили чат «найди, какая версия библиотеки сейчас актуальна» — получили текст по памяти. Попросили агента — он открыл нужную страницу, прочитал, при необходимости сходил ещё в два места, сверил и вернулся с ответом. Того же ученого выпустили из комнаты и дали ключи от машины.
Именно этот цикл «действие → результат → следующее решение» и делает модель агентом. Всё остальное, о чём пойдёт речь дальше, — способы расширить или ограничить этот цикл.
Где физически работает агент
Когда первые кодовые агенты стали популярными, их часто запускали из терминала или редактора кода, к 2026 году вариантов стало больше.
Возьмём Claude Code в качестве примера. Один и тот же агентный механизм сейчас доступен через CLI, приложение для компьютера, VS Code, JetBrains, веб-интерфейс и некоторые интеграции. Код при этом может выполняться локально на компьютере или в облачной среде.
В терминале
CLI расшифровывается как command line interface, интерфейс командной строки. Агент — например, Claude Code — запускается прямо в терминале: вы открываете папку проекта, пишете задачу текстом, а дальше он сам читает файлы, редактирует код, запускает команды и возвращает результат в том же окне.
Такой способ не требует ставить ничего поверх обычной рабочей среды и подходит тем, кто и так живёт в консоли.
В редакторе кода
Та же логика работает внутри редактора. В VS Code агент ставится как расширение: открываете папку проекта, устанавливаете расширение, и рядом с кодом появляется отдельная панель для переписки. Внутри неё можно посмотреть и отредактировать план агента до того, как он начнёт что-то менять, упомянуть конкретный файл или диапазон строк через символ @, держать несколько разговоров в разных вкладках и видеть правки как обычный диф.
Меняется только способ взаимодействия: посмотреть diff в редакторе иногда удобнее, чем читать изменения в терминале.
В облаке и других интерфейсах
Агент вообще необязательно должен работать у вас в терминале.
Например, Claude Code поддерживает облачное выполнение задач в среде Anthropic. Есть и Remote Control, при котором интерфейс находится в браузере, а выполнение остаётся на локальной машине.
Поэтому терминал, IDE и веб-интерфейс лучше считать оболочками. Возможности агента определяются моделью, доступными инструментами, разрешениями и средой выполнения.
AI skills: что это и зачем сохранять процесс в файл
Дальше начинается первая настройка. Представьте, что каждую неделю вы объясняете агенту одно и то же. Skill — это способ записать такой процесс один раз и больше к нему не возвращаться.
Как устроен skill
Технически skill — обычная папка с файлом SKILL.md внутри. В начале файла идёт YAML-блок с метаданными, где обязательны два поля: name — имя скилла, и description — короткое описание, когда его применять. Дальше идёт обычный текст с инструкциями, которые агент выполнит.
Рядом с SKILL.md можно положить всё, что нужно процессу: папку scripts/ со скриптами, references/ со справочными материалами, assets/ с шаблонами. Агент подтянет их, когда дойдёт до нужного шага.
my-skill/
├── SKILL.md # обязательный: метаданные и инструкции
├── scripts/ # необязательно: исполняемый код
├── references/ # необязательно: документация
└── assets/ # необязательно: шаблоны и ресурсыПочему сто скиллов не забивают контекст
Тут самое интересное. Скиллы загружаются по принципу progressive disclosure — постепенного раскрытия, в три стадии.
- Discovery. На старте сессии агент подгружает только имя и описание каждого скилла. Буквально пару строк на штуку — достаточно, чтобы понять, что такой скилл вообще существует.
- Activation. Когда задача совпала с описанием, агент читает полный текст
SKILL.md. - Execution. Агент выполняет инструкции и по ходу дела подтягивает нужные файлы и скрипты из папки.
Где лежат скиллы и кто их поддерживает
В Claude Code скиллы живут в трёх местах: ~/.claude/skills/ — личные, доступны во всех ваших проектах; .claude/skills/ в репозитории — проектные, их можно закоммитить и раздать команде; и внутри плагинов. Вызвать скилл можно вручную — командой со слешем и именем папки, — или дать агенту выбрать самому по описанию.
Формат Agent Skills придумали в Anthropic и выложили как открытый стандарт. Его поддерживают Claude Code и claude.ai, Cursor, VS Code с Copilot, Gemini CLI, Codex, OpenCode, Goose и ещё много инструментов. То есть скилл, написанный под один агент, скорее всего заработает и в другом.
Что такое MCP простыми словами
Skills объясняют агенту, как делать работу. MCP отвечает за другое — откуда брать данные и что можно менять снаружи.
Model Context Protocol, или MCP, — открытый протокол, по которому агент подключается к внешней системе напрямую: читает и записывает данные там, где они реально лежат. Рабочий трекер задач, чат команды, CRM, собственная база.
Официальная документация сравнивает MCP с разъёмом USB-C: один стандартный порт вместо отдельного переходника под каждое устройство. Без протокола каждый агент и каждый сервис пришлось бы стыковать вручную и заново.
Кто это придумал
Протокол придумали в Anthropic и открыли 25 ноября 2024 года. В декабре 2025-го Anthropic передала MCP в Agentic AI Foundation — фонд под Linux Foundation, который основали вместе с Block и OpenAI при поддержке Google, Microsoft, AWS, Cloudflare и Bloomberg.
На момент передачи у протокола было около 97 миллионов ежемесячных загрузок SDK и порядка 10 тысяч активных серверов. Актуальная ревизия спецификации на сегодня — от 28 июля 2026 года.
Один и тот же MCP-сервер обслуживает агентов разных вендоров. Написали сервер под свою внутреннюю систему — он работает и в Claude, и в ChatGPT, и в VS Code, а не только в одном продукте.
Как это устроено внутри
Схема простая, тоже из трёх составляющих:
- Хост — приложение, в котором вы работаете. Claude Code, VS Code, десктопное приложение.
- Клиент — то, что хост создаёт под каждое подключение. Одно подключение — один клиент.
- Сервер — программа, которая отдаёт данные и умеет выполнять действия.
Общаются они сообщениями в формате JSON-RPC 2.0. Транспорта два: stdio — когда сервер запущен локально на той же машине и обменивается данными через стандартные потоки ввода-вывода, и Streamable HTTP — когда сервер удалённый и один сервер обслуживает много клиентов.
Сервер может отдавать агенту три вещи: tools — функции, которые агент вызывает, чтобы что-то сделать; resources — данные для контекста, например содержимое файла или схема базы; prompts — готовые шаблоны запросов. Первым делом агент спрашивает у сервера список доступных инструментов, а потом уже вызывает нужный с параметрами.
Готовый MCP-сервер
Подключаются одной командой или галочкой в настройках агента, в зависимости от инструмента. У Anthropic есть каталог проверенных коннекторов, и то, что в нём лежит, работает по тому же протоколу — добавляется в любой совместимый инструмент.
Дальше можно просто попросить агента посмотреть последние задачи в трекере или новые сообщения в канале команды — он сам сходит в сервис через протокол.
Свой MCP под внутренний сервис
Если данные лежат в собственной системе, для которой готового коннектора нет, MCP собирают под конкретный API. Модель получает доступ ровно к тем данным и действиям, которые описаны в сервере, — например к внутренней панели, где лежит статистика по релизам.
После подключения агент обращается к этой системе так же, как к любому готовому сервису.
Когда MCP не нужен и о чём стоит помнить
MCP лучше подключать, когда агенту нужны данные или действия за границами простого текста. Если вся работа укладывается в то, что можно скопировать в чат руками, протокол только добавит лишнюю настройку.
И про безопасность. Инструменты MCP — это выполнение чужого кода на ваших данных. В самой спецификации написано: описания инструментов стоит считать недоверенными, если сервер не проверенный, а пользователь должен явно подтверждать вызов. Плюс сервер, который тянет внешний контент, — потенциальная точка для prompt injection: вредная инструкция приезжает не от вас, а внутри данных, которые агент прочитал. Так что «подключу-ка я двадцать серверов с гитхаба» — не лучший план на вечер.
Субагенты и оркестратор: как распараллелить большую задачу
Если агенту дать одну большую задачу, он по умолчанию решает её последовательно, шаг за шагом. Иногда это нормально. Иногда — двадцать минут ожидания там, где могло быть три.
Как работают субагенты
Субагент — отдельный агент со своим контекстным окном, своим системным промптом, своим набором инструментов и своими правами. Главное: он стартует с нуля, не видит вашу переписку, не знает, какие файлы уже прочитал основной агент, и возвращает только итог.
Настраивается субагент так же скучно, как скилл: markdown-файл с YAML-блоком в начале, где указывают имя, описание, при желании — список разрешенных инструментов и модель.
Отсюда четыре плюса: основной контекст не забивается поиском и логами; субагенту можно выдать урезанный набор инструментов и тем самым ограничить его в правах; конфигурацию можно переиспользовать в разных проектах; на простые задачи можно ставить модель подешевле и побыстрее.
Пример: разбор бэклога багов
Представим сервис, где команда ведёт список открытых багов в таск-трекере. Агентная система читает весь список карточек, по каждой формирует техническое задание, а дальше на каждую карточку запускает отдельный субагент.
Каждый субагент занимается своей карточкой одновременно с остальными. Вместо долгой последовательной разборки правки закрываются за один проход, а в конце собирается общий отчёт о том, что исправлено. Одновременно в одной сессии их может крутиться до двадцати.
Паттерн «оркестратор — исполнители»
Похожий принцип лежит в основе паттерна orchestrator-workers: один агент разбирает задачу, раздаёт её части другим агентам с собственным контекстом, а в конце собирает результаты в одно целое.
Например, при работе над разделом продукта один агент отвечает за структуру текста, другой пишет фрагменты, третий проверяет итог перед сдачей. Каждый видит только свой кусок и не собирает чужой контекст.
Это один из пяти паттернов, которые описывает Anthropic:
- Prompt chaining — цепочка, где результат одного шага становится входом для следующего.
- Routing — маршрутизация: входящие задачи классифицируются и отправляются на профильную обработку.
- Parallelization — параллельный запуск: одну задачу дробят на независимые части или прогоняют несколько раз для надёжности.
- Orchestrator-workers — тот самый оркестратор, который раздаёт работу и собирает итог.
- Evaluator-optimizer — одна модель генерирует результат, другая оценивает и отправляет на доработку по кругу.
Если шаги жёстко прописаны в коде — это workflow, рабочий процесс. Если модель сама решает, что делать дальше, — это агент. Обе конструкции рабочие, просто под разные задачи: workflow предсказуемее, агент гибче.
Большая скидка — 16% на все курсы Практикума
Если вы читаете эту статью, тогда вы точно разбираетесь в технологиях. Стать лучше и зарабатывать больше можно после курсов Практикума — по программированию, анализу данных и искусственному интеллекту.
До 17 сентября на все курсы действует скидка 16%, она применится автоматически при оплате. Потом цены станут выше, поэтому не откладывайте!
Только начали и хотите понять работу с агентом — берите «Вайбкодинг»; дошли до MCP и внешних систем — «Нейросети для разработки»; собираете субагентов и оркестрацию — «ИИ-агентов и автоматизацию» или «ИИ-инженера».
Хуки — агент работает по правилам
А теперь то место, где чаще всего путаются.
Хуки — не точки, где агент останавливается и спрашивает разрешения. Хук — это ваша shell-команда, которую инструмент запускает автоматически в определенный момент своего жизненного цикла. Смысл именно в детерминированности: нужное действие происходит всегда, а не тогда, когда модель захочет его выполнить.
Из чего собирается хук
Хук описывают в файле настроек: событие, при котором он срабатывает, необязательный фильтр (например, только для инструментов правки файлов) и команда, которую надо выполнить.
Событий много, вот основные:
- SessionStart — сессия началась или возобновилась. Удобно, чтобы подгрузить переменные окружения или вернуть в контекст детали после сжатия истории.
- UserPromptSubmit — вы отправили сообщение, но агент ещё не начал его обрабатывать.
- PreToolUse — перед вызовом инструмента. Единственное место, где вызов можно заблокировать.
- PostToolUse — после успешного вызова. Сюда вешают форматтеры, линтеры, автотесты.
- Stop и SubagentStop — агент или субагент закончил работу.
- SessionEnd — сессия завершилась.
Как хук запрещает действие
Скрипт получает на вход JSON с данными о событии, а обратно сообщает решение кодом возврата. Ноль — всё в порядке, работаем дальше. Двойка — действие заблокировано, а текст из stderr уходит агенту как объяснение, что пошло не так.
Классический пример: скрипт на PreToolUse смотрит на команду, которую агент собирается выполнить, находит в ней rm -rf и возвращает двойку. Агент видит отказ и причину и идёт искать другой путь. Если на одно событие повешено несколько хуков, побеждает самый полный ответ: сначала запрет, потом «спросить пользователя» и только потом разрешение.
Есть и вариант ближе к тому, как хуки описывают в популярных гайдах: хук может не запретить действие, а поднять его на подтверждение — тогда решение принимаете вы. А для случаев, где нужно не жесткое правило, а суждение, бывают хуки, которые сами обращаются к модели.
Как собрать своего ИИ-агента: три варианта
Есть три рабочих пути, и у каждого своя цена входа и свой потолок.
Стандартный агент без настройки
Открываете инструмент — тот же Claude Code, — объясняете, что нужно сделать, и поправляете на ходу. Порог входа минимальный, разобраться можно за вечер.
Проблемы начинаются, когда в работе одновременно несколько типов задач и много правил, которые должны соблюдаться постоянно. Агент может забыть договорённости из начала сессии, путаться в выборе инструмента и уходить в лишние действия вместо того, чтобы закончить задачу.
Готовая чужая сборка
На GitHub полно готовых наборов: субагенты, хуки, MCP-серверы, скиллы под конкретные сценарии. Скачал, подключил, поехали.
Быстрый старт, но логика внутри настроена под чужой процесс. Совпало с вашим — отработает отлично. Не совпало — придётся разбираться в чужих правилах и вычищать лишнее, а это иногда дольше, чем собрать своё. Плюс всё, что написано выше про доверие к чужим MCP-серверам, здесь тоже в силе.
Своя архитектура по проверенным паттернам
Здесь речь про то, чтобы разобраться, как агент устроен изнутри: цикл действий, контекстное окно, скиллы, хуки и те самые пять способов соединить шаги в один процесс — от простой цепочки до оркестратора.
Времени на старте нужно больше. Зато окупается, если процессы повторяются регулярно: один раз собранная связка «скилл + пара MCP-серверов + хук на проверку» работает постоянно.
Что в итоге
ИИ-агенты быстро переходят из категории новых инструментов в рутинные. Разобраться в них можно и по бесплатным материалам — документация MCP и Agent Skills открытая. Но если нужен системный разбор с практикой, у Практикума есть курсы, которые подойдут, чтобы быстро начать использовать ИИ-инструменты в работе без погружения в архитектуру агентов. Или варианты для тех, кто хочет собирать агентные системы профессионально.
В ближайшие годы умение работать с агентами, скорее всего, станет такой же привычной частью разработки, как Git, IDE или поиск по документации. Войти в эту тему сейчас проще, пока вокруг неё ещё формируются практики и можно спокойно разобраться.
Советуем дополнительно почитать
Защита API-ключей от утечек: чек-лист разработчика — что делать с ключами, которые вы отдаёте MCP-серверам, и как не отправить их в репозиторий вместе с конфигом.
Закончились токены в Claude Code: 6 репозиториев, как сократить расход — практическая сторона экономии контекста: чем чистить историю и что не пускать в модель.
Эмбеддинги в поиске: векторы, косинусное сходство и RAG — как агент находит нужное в базе знаний, когда данных больше, чем влезает в контекстное окно.
ИИ-навыки разработчика: 10 требований для 2026 — что работодатели понимают под работой с агентами и как этот навык проверяют на собеседовании.
Что такое MLOps — операции машинного обучения для задач ML-разработки — что происходит с агентной системой после сборки: мониторинг, версионирование, отслеживание деградации.
Бонус для читателей
Если вам интересно погрузиться в мир IT и при этом немного сэкономить, держите наш промокод на курсы Практикума. Он даст вам скидку при оплате, поможет с льготной ипотекой или безлимитом на маркетплейсах. Ладно, окей, это просто скидка, без остального, но хорошая.
