Агентные системы 2026: что работает на практике, а что уже устарело

Почему у всех в ленте получается, а у тебя нет

Лента полна обещаний: «моя команда агентов работает, пока я сплю», «заменил отдел маркетинга тремя агентами», «собрал SaaS за выходные без строчки кода», «поставь тысячу скиллов, и агент умеет всё». Повторяешь шаги один в один, а результат не тот. Возникает ощущение, что дурак здесь ты.

Это нормально. Любой продукт, от маленького стартапа до корпорации, собирают маленькими итерациями, и с агентами так же. Публичное обещание «сделать быстро» живёт в ролике и отчёте. Чтобы система работала каждый день, приходится разбираться, как она устроена: так же, как с клоном Фотошопа, собранным за выходные, который годится как доказательство концепции, но не заменяет профессиональный инструмент.

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

Чего не хватает агенту, чтобы сделать хорошо

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

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

Никита Шилов

Поэтому до запуска агента стоит ответить на вопросы, которые не про код и не про синтаксис:

• как я пойму, что задача готова;
• как я пойму, что она сделана хорошо;
• как я пойму, что она провалена.

Когда ответы есть, часть задач уже можно отдавать агенту. Когда их нет, агент придумает их сам.

42% сбоев: плохая спецификация задачи

Исследования мультиагентных систем показывают одну и ту же картину. Самая частая причина провала не координация агентов и не слабая модель, а плохая спецификация. Она часто появляется, когда человек передаёт агенту не только исполнение, но и описание цели и критериев приёмки.

Вторая беда: растущий контекст. Чем больше в окне, тем больше мест, куда модель смотрит одновременно, и тем сильнее агент дрейфует. Даже простые задачи начинают выполняться хуже. Агент без заданной логики хуже казино: в казино хотя бы понимаешь, на что идёшь.

Агент написал «крутой пост» и сам себе поставил 10 из 10

Самый показательный опыт: дать агенту доступ ко всему, что о тебе известно, и попросить «крутой пост». Агент напишет текст, сам решит, что значит «крутой», проверит его тем же вкусом, которым писал, и оценит работу высоко. Если отправить тот же пост в новый чат без контекста, его с той же уверенностью разгромят. И снова по придуманным критериям.

У каждой единицы контента своя задача: охват в LinkedIn, комментарии в местном паблике, узнаваемость новой функции банка. Успех в каждом случае меряют разными метриками на разных площадках. Пока задача сформулирована как «сделай круто», агент берёт средний критерий из интернета.

Выход в том, чтобы правила проверял код, а не вкус модели. Те же требования к посту, оформленные как проверка длины, хука, штампов и количества вопросов, сразу показывают разницу между черновиком без критерия и текстом, который им соответствует.

Все тесты зелёные, продукт не работает

Тот же эффект в разработке. Простая логика «постоянного клиента»: у бизнеса это два и больше заказа за 90 дней, а скидка действует только на товары. Агент без явного правила решил, что постоянный клиент это три заказа за всё время, и написал тесты под свою догадку. Все тесты зелёные. Приёмка по правилу бизнеса проходит в двух случаях из пяти.

Логика, которая должна проверяться жёстко, оказывается переданной генеративной модели. При высокой температуре ответ каждый раз будет разным.

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

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

Глеб Михеев

Повторять форму, не понимая сути, значит попасть в карго-культ: строить из соломы взлётную полосу и ждать, что прилетит самолёт.

Что уже устарело: тысяча скиллов и «второй мозг» из всего подряд

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

Скиллы, которые агент пишет себе сам, в среднем не помогают. Выверенные человеком дают ощутимый прирост к доле решённых задач.

Скиллы, которые агент делает себе сам, практически всегда отвратительны.

Никита Шилов

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

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

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

С памятью то же самое. Граф заметок сам по себе преимуществ не даёт. Если сложить в него всю переписку и все звонки, контекст раздуется, а выдача станет хуже. Агент не понимает, какая из двух заметок о цене актуальна, если в них нет дат и статусов.

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

Модели нельзя доверять: защищай доступ, а не промпт

Для модели письмо и твоя команда составляют один и тот же поток текста. Скрытая инструкция в письме может заставить агента пересказать договор без опасных условий. Опасность приходит откуда угодно: из поиска, обновления пакета, ответа MCP-сервера или скилла. Пакет с post-install скриптом может найти все файлы с переменными окружения и отправить их на чужой сервер.

Никогда нельзя доверять модели. Если ей сказали этого не делать, не надо ждать, что она этого не сделает. Поэтому запрещаем физически, а не на уровне промпта.

Глеб Михеев

Чувствительные данные проще всего защитить, не передавая их модели. Перед запросом паспорт, email и ФИО распознают и заменяют плейсхолдерами, сохраняя соответствие локально. Модель формирует вызов инструмента с плейсхолдерами, а настоящие данные подставляются уже на выходе. Готовые решения хорошо находят типовые форматы, а специфичные для бизнеса данные приходится учить распознавать отдельно. Обработку отказов и логирование критичных действий тоже нужно проектировать заранее: в готовых наборах скиллов их почти никогда нет.

Когда нужна команда агентов

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

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

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

Где агент экономит время уже сейчас

Агент экономит не работу, а переключения. Ты ставишь задачу, а он ждёт, проверяет и зовёт тебя, только если что-то пошло не так. Это видно на любом процессе с ожиданием: доступ подрядчику на неделю, задачи после планёрки, КП клиенту, модерация рекламы, счёт, выход нового сотрудника.

Хорошо делегируются задачи с чёткими параметрами: проверить доступ, найти нужную строку в базе, выгрузить логи, сделать небольшой ресёрч, собрать продуктовый отчёт по сырой базе за пару итераций вместо месяца ожидания аналитика. Агенты уверенно работают в браузере, консоли и даже на подключённом телефоне. Долгий путь через клики потом можно попросить превратить в скрипт: «распиши короткий путь, как ты это сделал, чтобы повторить за 20 минут».

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

Автоцикл с одной метрикой

Самый недооценённый режим: оставить агента работать к измеримой цели. Например, довести размер сборки с 25 мегабайт до 600 килобайт или сделать все тесты зелёными. Агент меняет код, запускает проверку, смотрит метрику и оставляет изменение или откатывает его. Так можно гонять эксперименты всю ночь.

Условия у цикла жёсткие. Цель и правила пишет человек. Одну метрику считает код. Агент меняет один файл. Откат тоже делает код, а не агент. И у агента должен быть весь инструментарий: если модель не может сама измерить производительность, она не поймёт, стало ли лучше.

Проверки бывают мягкими и жёсткими. Рекомендация в промпте это мягкая проверка: агент может её обойти и, например, выпустить платный доступ, который быстро съест бюджет. Жёсткая проверка живёт в коде, правах и инфраструктуре. Отделять ошибку исполнителя от атаки тоже нужно заранее.

Главное

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