Какие задачи доверять AI-агентам, а какие нет?

Если попробовать интуитивно объяснить, что такое AI-агент, можно вспомнить знакомые с детства примеры. Например, Вовка в тридевятом царстве — это наглядная иллюстрация агентного поведения.

Правда, скорее это пример антипаттерна, но к этому мы ещё вернёмся и отдельно обсудим.

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

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

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

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

Однако есть и ограничения. Такая система не видит всей архитектуры целиком. В результате она может фокусироваться не на качестве решения, а на прохождении тестов — так называемый «test hacking». То есть вместо того, чтобы корректно решить задачу, система подстраивается под тесты, что в отдельных случаях может приводить к деградации архитектуры.

Основное преимущество здесь в том, что агент может одновременно работать с большим количеством инструментов и источников, а также обрабатывать задачи в свободной форме. Например: «подготовь отчёт» или «помоги выбрать решение». Система способна собрать данные из множества источников и быстро их обработать.

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

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

Кроме того, такие системы могут быть чрезмерно автономными — вплоть до того, что без участия человека они не способны вовремя остановиться. Поэтому человеческий контроль в таких задачах остаётся необходимым.

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

Однако есть и существенные ограничения. Языковые модели настолько мощные, что иногда начинают находить закономерности там, где их на самом деле нет. Это может приводить к ложным выводам.

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

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

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

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

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

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

Многие уже пробовали собирать MVP и proof of concept на основе языковых моделей и агентов.

Ключевое преимущество здесь — высокая скорость. Такие решения позволяют быстро собирать прототипы и проверять разные гипотезы. Можно делать несколько версий продукта и оперативно сравнивать их между собой.

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

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

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

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

Допустим, ГОС написан на одном языке, какое-то письмо о том, как мы работаем с клиентами, написано на другом. И вот это все собрать, сконцентрировать в себе, и чтобы из этого собрать единый ToV-ответ, который соответствует компании — вот здесь такая система очень хорошо подходит.

Минусы в том, что эта система уверена даже когда она ошибается. То есть вот она сделала ошибку, но все равно говорит, что ничего страшного, все же правильно.
Нам очень важно поймать тот момент, когда система может делать ошибки.

И такая система плоха тем, что здесь происходит быстрое устаревание данных. Если кто-то забыл что-то, какой-то источник обновить, то вот все, что мы строим, оно может работать плохо.

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

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

Кроме того, на ключевых этапах необходима валидация со стороны человека — без этого сложно гарантировать корректность и пригодность сгенерированных данных.

Мы разобрали, какие задачи подходят для агентов, а теперь посмотрим на распространённые ошибки при их использовании.

Один из самых частых антипаттернов — попытка сделать «универсального агента», который решает любые задачи.

Идея в том, что система «сама во всём разберётся». На практике это не работает: без четкой области ответственности и ограничений такие решения становятся неуправляемыми и быстро теряют качество.

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

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

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

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

Часто возникает иллюзия, что любую проблему можно решить «магическим промптом».

Если что-то не работает, пытаются просто переписать запрос — вместо того чтобы пересмотреть архитектуру.

На практике многие задачи не решаются на уровне промптинга. Они требуют изменений в дизайне системы и продуманной архитектуры.

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

Ещё одна ошибка — запуск решения в прод без предварительной валидации.

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

Даже если система работает на демо, это не означает, что она готова к реальной нагрузке. Подход «human-in-the-loop» предполагает, что после запуска человек регулярно проверяет результаты и оценивает корректность работы системы.

Например, избыточное количество инструментов или попытка решить проблему за счёт увеличения числа агентов вместо проработки архитектуры.

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