Свои агенты и субагенты

Что такое агент и чем субагент отличается от агента

Агент — это не просто чат с моделью. Это связка из трёх вещей: инструкции (системный промпт, который задаёт роль), набора инструментов, которые агент умеет вызывать (поиск в интернете, чтение файлов, запрос к CRM), и цикла, в котором модель сама решает, какой инструмент вызвать дальше, пока не решит задачу или не упрётся в лимит шагов. Обычный чат-бот отвечает один раз на один вопрос. Агент может сделать десять шагов подряд без вашего участия: прочитать файл, найти ошибку, исправить её, проверить результат.

Субагент — это агент, которого вызывает другой агент, а не человек напрямую. У субагента своя роль, свой ограниченный набор инструментов и своё отдельное контекстное окно — то есть он не видит всю историю разговора, только ту задачу, которую ему передали. Здесь работает та же логика, что в делегировании между людьми: главный агент (иногда его называют «оркестратор» или «принципал») ставит задачу, субагент-«исполнитель» её решает и возвращает результат, не отвлекая оркестратора на детали процесса.

В связке эти роли работают так же, как в нашем собственном пайплайне подготовки страниц: Директор ставит задачу, а не пишет текст сам — он делегирует SEO-семантику одному специалисту, исследование другому, копирайтинг третьему, и каждый работает в своей области, не разбираясь в чужой. Дальше в статье будет видно, что это не метафора, а рабочая архитектура, которую можно повторить в своих задачах.

Зачем создавать своего агента, а не пользоваться готовым

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

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

Как создать своего ИИ-агента: шаги и минимальный набор

Порог входа для первого своего агента зависит от того, какой инструмент доступен без обхода блокировок. На август 2026 года из России без VPN и иностранной карты реально работают низкоуровневые конструкторы GigaChat (Сбер) и AI Studio Яндекса: у обоих есть low-code сборка агента через веб-интерфейс, вход по подтверждённому аккаунту (Sber ID у GigaChat), бесплатный лимит запросов и платный API для более серьёзной нагрузки — для юрлиц у GigaChat часть тарифов API доступна только с 16 февраля 2026 года. ChatGPT для этой задачи не подходит: сервис заблокирован для прямого доступа из России, а создание новых кастомных GPT в 2026 году закрыто и для личных аккаунтов за рубежом — доступно только организациям, старые уже созданные боты продолжают работать.

Минимальный набор для первого агента — независимо от платформы — один и тот же:

Пример базового уровня: агент-«помощник по договорам» в GigaChat или AI Studio, который через low-code конструктор проверяет статус договора в CRM по номеру и создаёт задачу в таск-трекере, если статус просрочен. Это не требует кода, работает без VPN и закрывает конкретный повторяющийся процесс — типичная первая точка входа для человека без опыта разработки.

Как настроить и подключить инструменты через MCP

Агент без инструментов ограничен тем, что знает модель «из коробки» — он не может заглянуть в вашу CRM, прочитать файл на диске или сходить в интернет за свежими данными. MCP (Model Context Protocol) — открытый стандарт, который решает именно это: он описывает единый способ подключить агента к внешней системе, будь то GitHub, база данных, Figma или таблица. На август 2026 года в публичном каталоге mcp.so собрано свыше 17 800 готовых MCP-серверов — то есть для большинства популярных сервисов подключатель уже написан, и обычно не нужно писать интеграцию с нуля.

С точки зрения агента MCP-сервер — это просто ещё один инструмент в списке доступных: агент видит его название и описание и решает, когда его вызвать, так же как решает, когда вызвать встроенный поиск. Практическая последовательность подключения одинакова в Claude Code, Cursor и большинстве других сред: находите нужный MCP-сервер в каталоге (или разворачиваете свой), прописываете его в конфигурации проекта, перезапускаете сессию — сервер сам не подхватится «на лету», это частая ошибка новичков, которые ждут появления инструмента без перезапуска, — и проверяете, что агент видит новый инструмент в списке доступных.

Субагенты: как разделить одну задачу на несколько ролей

Когда задача становится многошаговой и разнородной по типу работы — например, «разобраться в коде, спроектировать решение и протестировать его» — одному агенту приходится удерживать в контексте сразу всё, и качество каждого отдельного шага падает. Субагенты решают это разделением: каждый получает свою узкую роль, свой набор инструментов и своё контекстное окно, не засорённое чужими деталями.

В Claude Code кастомный субагент оформляется одним файлом Markdown с YAML-заголовком в папке проекта — там указываются имя, описание роли и разрешённый список инструментов, при желании — конкретная модель под задачу (например, более быстрая и дешёвая модель для read-only поиска по коду, более мощная — для архитектурных решений). Главный агент решает, кому делегировать конкретный кусок работы, читая именно поле с описанием роли субагента — из этого следует практический вывод: расплывчатое описание вроде «помогает с кодом» приводит к тому, что оркестратор либо не делегирует вообще, либо делегирует не туда, и со стороны это выглядит так, будто агент «игнорирует» инструкцию, хотя причина — в формулировке роли.

Из готовых субагентов Claude Code, например, есть read-only «Explore» для быстрого поиска по кодовой базе без права на запись и «Plan» для сбора контекста на этапе планирования — оба нарочно ограничены в правах, чтобы не могли случайно что-то изменить, пока их задача — только смотреть и докладывать. В Cursor похожий принцип реализован через файлы правил проекта с собственным описанием и условиями применения, а также через фоновые агенты, которых среда сама распределяет по независимым кускам задачи.

Субагентов можно вызывать последовательно (один заканчивает — начинает следующий) или параллельно, если задачи не зависят друг от друга: например, пока один субагент ищет по коду, второй одновременно готовит план тестов. Параллельный запуск ускоряет работу, но требует, чтобы задачи субагентов действительно не пересекались по данным — иначе возникают риски, которые разберём в разделе про типичные проблемы.

Мультиагентные системы и оркестрация: когда агентов становится много

Мультиагентная система — это уже не пара «главный плюс один субагент», а полноценный конвейер, где несколько ролей идут друг за другом или параллельными группами, а результат каждого шага становится входом для следующего. Оркестрация — это то, как устроена передача задач и результатов между этими ролями: кто кого вызывает, в каком порядке, что происходит, если какой-то шаг завершился с ошибкой.

Наглядный пример такой архитектуры — собственный пайплайн подготовки страниц агентства «Термос Беспалова»: Директор-оркестратор не пишет текст и не делает вёрстку сам, а последовательно и параллельно распределяет задачи между ролями — сначала разведка темы, затем одновременно SEO-семантика и исследование фактов, потом копирайтинг, затем реклама, затем параллельно анимация и визуальный блок, потом сборка страницы, публикация и на последнем шаге параллельно QA-проверка и SEO-аудит. Каждая роль получает узкую задачу и не видит внутреннюю кухню остальных — ровно та же логика, что описана выше для субагентов Claude Code, только развёрнутая на весь процесс, а не на одну задачу внутри разговора.

Промежуточная ступень к такой архитектуре — не код, а no-code оркестрация: в n8n или Make.com можно собрать цепочку без единой строчки кода — триггер (например, новая заявка), вызов модели для классификации намерения, условное ветвление по результату, запись в таблицу и уведомление в мессенджер. На август 2026 года n8n реалистично разворачивать на своём сервере (self-host) — это работает из России без ограничений; облачная версия n8n и Make.com требуют оплаты иностранной картой, что для аудитории из России остаётся барьером входа. Это ещё не «настоящие» субагенты в смысле отдельных контекстных окон и делегирования по описанию роли, но уже переход от одного бота к последовательности шагов с автоматическим ветвлением.

Типичные проблемы мультиагентных систем и как их избежать

Чем больше агентов в системе, тем выше цена ошибок координации между ними. Разберу проблемы, которые встречаются чаще всего, по мере роста сложности системы.

Оверинжиниринг с первого дня. Частая ошибка — сразу строить систему из пяти-десяти агентов там, где хватило бы одного с двумя-тремя субагентами. Сложность оркестрации должна расти вместе со сложностью задачи, а не опережать её: начинайте с одного агента, добавляйте роли по мере того, как реально упираетесь в ограничения одной роли.

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

Бесконечные циклы правок. Паттерн «один агент пишет — другой проверяет — третий исправляет» может зациклиться на взаимных правках без внешнего ограничения числа попыток. Явный лимит итераций — обязательная часть архитектуры, а не опция «на всякий случай».

Ложный консенсус. Несколько агентов «соглашаются» друг с другом и выдают гладкий уверенный результат, который маскирует реальную ошибку. Это опаснее явного отказа системы, потому что доверие подрывается позже — когда ошибка всплывает уже в готовом результате, а не на этапе проверки.

Конкуренция за общие ресурсы. Агенты с доступом к одним и тем же файлам, базе данных или API могут конфликтовать друг с другом без явной защиты — блокировки файлов, очередь задач, фиксированный порядок операций. Без этого возникают гонки состояний: два агента одновременно правят один и тот же файл, и один результат перезаписывает другой.