ИИ-агенты не справляются не потому что тупые

Сейчас многие компании внедряют ИИ-агентов в свои процессы. И сталкиваются с проблемами. Классический пример: ИИ-агент по продажам самостоятельно пообещал клиенту скидку 50% на которую ему никто не давал разрешения. Явный провал разработчиков ИИ-агентов, хотя на прошлой неделе в демо всё работало идеально.

Мир явно разделился: одни говорят, что агенты готовы к продакшену, другие кричат что это не работает и работать не будет. Энтузиасты показывают впечатляющие демо. Чистые данные, правильные API, никаких сюрпризов. Но продакшен это другой зверь. Отчёт MIT показал, что 95% пилотов генеративного ИИ не достигают ожидаемых результатов. Модели не тупые. Инфраструктура вокруг них не готова.

Я это понял на собственном опыте ^[1], строя своего агента на базе OpenClaw, который отчитывается мне ежедневно в Telegram. Все здесь крайне интересно, но реальные области использования нащупать сложно.

Разрыв, о котором никто не говорит

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

Манвир Чавла, сооснователь Zenith, опубликовал в блоге Composio “три ловушки” которые топят ИИ-агентов в продакшен:

1. Тупой RAG: сваливаем всё в контекст и надеемся что модель разберётся

2. Хрупкие коннекторы: API работают в тестах, ломаются в продакшене

3. Налог на поллинг: 95% API-вызовов уходит на постоянный опрос впустую

Это не проблемы модели. Это проблемы интеграционного слоя. LLM это ядро, но вокруг него нет операционной системы.

На практике спасают явные ограничители. Гейты качества, где агент-редактор отклоняет черновики до того как они дойдут до людей. Жёсткие “ЗАПРЕЩЕНО” в промптах. Блокировки когда параллельные агенты работают с одними данными. Именно это отделяет рабочие системы от красивых демо.

Ловушка первая: тупой RAG

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

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

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

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

Ловушка вторая: хрупкие коннекторы

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

Лимиты запросов меняются без предупреждения. Токены аутентификации истекают. Вебхуки срабатывают не в том порядке или не срабатывают вообще. Сторонние сервисы падают или меняют формат ответов. Агент думает что мир надёжен. А мир не такой.

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

Паттерн который работает: относиться к каждому внешнему соединению как к ненадёжной асинхронной операции. Логика ^[2] повторов. Автоматические выключатели. Плавная деградация. Агент должен уметь сказать “Я не смог достучаться до CRM, вот что знаю без него” вместо полного падения.

Ловушка третья: налог на поллинг

Большинство агентов опрашивают на предмет изменений. “Что-нибудь изменилось?” каждые несколько секунд. Просто, но тратит безумное количество API-вызовов.

Исследование Composio: поллинг сжирает примерно 95% бюджета на API. Переход на event-driven архитектуру сокращает расходы на порядок. Внешняя система сама уведомляет агента когда что-то поменялось, а не агент бесконечно спрашивает.

Конкретные цифры. 10 000 API-вызовов в день по $0.002 за каждый это $20 в день. Event-driven архитектура сокращает до 500 вызовов, $1 в день. Для системы 24/7 разница ощутима.

Иллюзия тестирования

Неудобная правда: агент работает в тестах потому что тесты это не реальность.

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

На саммите Machines Can Think 2026 в Абу-Даби ML-команда Aiphoria показала что провалы агентов в продакшене это не провалы интеллекта ^[3]. Это провалы тестирования. Системы работали потому что никто не тестировал крайние случаи.

Опрос LangChain State of Agent Engineering (1 300+ специалистов) подтвердил: треть назвали качество главным блокером для продакшена.

Решение не в лучших моделях. Оно в лучшем тестировании:

• Стресс-тестирование: намеренно ломайте агента странными входными данными

• Тестовые деплои: запускайте агента параллельно с людьми и сравнивайте результаты до включения автоматизации

• Постепенный раскат: начинайте с задач с низкими ставками, расширяйтесь по мере уверенности

Затраты непредсказуемы

Про это никто не говорит, но именно это ломает всю красивую систему на презентации.

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

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

Все в этой сфере говорят о том, что первый месяц биллинга вышел в 3-5 раз выше бюджета. Никто не был готов.

Фикс тоже архитектурный:

• Бюджет токенов на запрос: ограничьте сколько может потратить одна операция

• Запасные модели: если дорогая модель думает слишком долго, переключаемся на быструю

• Дашборды мониторинга: нельзя контролировать то чего не видишь

• Кастомные инструкции для LLM: умельцы уже пишут кастомные инструкции для LLM по экономии токенов. Вот хороший пример оптимизированного Claude.md ^[4] который учит модель экономить на токенах, эмодзи, лишних символах и длинных объяснениях. Отлично подходит для агентов и пайплайнов с автоматизацией.

Мой агент отчитывается о расходах ежедневно в Telegram. Сначала я перешёл с дорогих моделей на более дешёвые вроде Kimi, но в целом модель с API токенами недешёвая для агентов. Позже я выбрал подписку от MiniMax с фиксированной величиной расходов в 20 долларов в месяц. Если агент утыкается в лимит, то следующие несколько часов он просто не работает.

Что работает: агент как точка интеграции

Команды которые тянут агентов в продакшене перестали относиться к ним как к магической ИИ-способности. Теперь это обычная точка интеграции.

Явные интерфейсы, не магия. Каждый инструмент агента имеет определённый вход, выход и режим отказа. “Агент сам разобрался как это сделать” это баг, не фича.

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

Статус, не только результат. Мой агент сообщает не только что сделал, но и что пытался и где провалился. Для отладки это бесценно.

Аварийные выходы. Когда агент не справляется, он передаёт задачу человеку. Не галлюцинирует ответ. Сделать “я не знаю” валидным выходом сложнее чем кажется, но для продакшена это критично.

Мониторинг с первого дня. Не “добавим потом”. С первого дня, пока ещё помнишь что агент должен делать.

Что меняет 2026 год

Три вещи:

Event-driven становится стандартом. Новые фреймворки закладывают его с самого начала. Поллинг уходит.

Фреймворки оценки взрослеют. WebArena, SWE-Bench и другие дают стандартизированные способы тестировать агентов до деплоя.

Инструменты контроля затрат появились. Роутинг моделей сокращает расходы на 40-60%. Простые задачи в дешёвые модели, сложные в дорогие.

Быстрее всех учатся команды которые с самого начала относились к ИИ-агентам как к инженерной задаче. Не как к магии которой можно делегировать мышление ^[5].

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

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