Почему ИИ-агент «то работает, то нет»: что такое дрейф агента

Знакомо? Настроили ИИ-агента, проверили — работает. Через неделю он делает что-то странное. Не упал с ошибкой, не написал «не могу» — а уверенно делает не то. И это не «день на день не приходится». У этого есть имя — дрейф агента. И ровно он лежит под народным «ИИ то работает, то нет».

Что это такое

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

Инструкция стоит на месте, а мир вокруг агента движется.

Агент тот же. Меняется почва под ним.

Почему так происходит

• Мир меняется, инструкция — нет. Сайт переверстали, у сервиса сменился формат ответа, отвалился внешний сервис. Агент настроен под вчерашний мир.
• Среда падает молча. Сломался внешний инструмент — а агент не останавливается, а начинает крутиться вхолостую или импровизировать.
• Теряется рабочая память. Агент перезапустился, забыл, на чём остановился, и продолжил так, будто ничего не было.
• Память распухает. Чем дольше работает, тем больше в ней копится — и старое начинает мешать новому.
• Нет встроенной самопроверки. Агент рапортует «готово», а результата нет. Не потому что «врёт» — просто проверять собственную работу его не научили. Верить его самоотчёту нельзя.

Как это выглядит на практике

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

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

Отчёт ≠ реальность. Программа сообщила «не успела, прервано» — а на деле всё было сделано. Поверишь отчёту — решишь «не сработало» и переделаешь зря. Вывод: проверять по факту, а не по тому, что отрапортовал процесс.

Внутри зелёно — снаружи мёртво. Сервер работал правильно, но то, что видел человек, зависло на вечной загрузке. По всем внутренним признакам «всё ок» — а продукт для пользователя не работает. Проверять надо глазами на стороне клиента, а не только «у нас-то всё в порядке».

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

Заметьте: ни в одном случае дело не сводилось к тому, чтобы «получше сформулировать промпт». Лечило не слово — лечила обвязка вокруг агента.

Где настоящая граница

Инстинкт при дрейфе — «давай подкрутим промпт». Это игра в «заткни дырку»: заткнул в одном месте, через неделю течёт в другом. Промпт настраивает агента под один момент времени, а дрейф — это про изменение во времени.

Дрейф — структурная проблема. И лечится структурно — харнессом: обвязкой вокруг агента, которая ловит расхождение до того, как оно дойдёт до клиента.

• Проверки на выходе — агент не объявляет «готово», пока результат не подтверждён независимой проверкой.
• Стоп-условия — упал инструмент или кончились попытки → остановись, не импровизируй. Именно это мы прописали агенту после той холостой петли.
• Проверка по факту, а не по самоотчёту — любой сценарий закрывается проверкой реального результата на стороне клиента.
• Структура памяти — разделение по контекстам, индекс, протокол записи и чистки. Память без структуры сама становится источником дрейфа. Так мы вылечили «путаницу между проектами» — там, где переписыванием промпта её не вылечить.

Честно про сам харнесс: это не «поставил и забыл». Он тоже требует ухода — мир меняется и для него. Но он делает главное: переводит проблему из невидимой («агент тихо едет не туда») в видимую («система сама сообщила о сбое»). Это и есть разница между «иногда подводит без предупреждения» и «подводит редко и громко».

Промпт — это как агент думает. Харнесс — это что не даст ему тихо съехать.

Надёжность живёт во втором, не в первом.

Как проверить это у себя

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

Вывод

Если ваш ИИ-ассистент «то работает, то нет» — проблема почти никогда не в том, что «надо найти промпт получше». Проблема в том, что вокруг него нет обвязки, которая ловит дрейф.

Правильный вопрос не «как заставить агента не ошибаться» — это невозможно. Правильный вопрос:

Как сделать так, чтобы его ошибка не доехала до клиента незамеченной?

Это и есть инженерия харнесса — слой, который превращает «иногда работает» в «подводит редко и заметно».

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

Частые вопросы и симптомы: почему ИИ-агент исчезает, зависает или барахлит

1. Почему ИИ-агент «ни с того ни с сего» исчезает посреди выполнения задачи?

Внезапное исчезновение автономного агента без внятного сообщения об ошибке — типичный симптом трёх инфраструктурных сбоев:
1) OOM-Killed (Out of Memory): фоновый процесс агента или docker-контейнер превысил лимит оперативной памяти (например, из-за накопления раздутого контекста и логов) и операционная система принудительно убила процесс по сигналу SIGKILL (exit code 137).
2) Превышение контекстного окна модели: по мере выполнения цепочки рассуждений контекст переполнился, языковая модель вернула ошибку превышения лимита токенов, а код агента не содержал обработчика и аварийно завершился.
3) Отсутствие супервизора (watchdog): скрипт запущен напрямую без диспетчера процессов (systemd, PM2, Kubernetes). Любое сетевое прерывание или сбой сокета приводит к молчаливому падению сессии.
Решение: использовать супервизор с автоперезапуском, сохранять рабочее состояние на диске (truth-in-files / SQLite), настроить автоматическую компактизацию контекста и ограничить лимит итераций.

2. Почему у меня агент тупит: то работает идеально, то делает совершенно не то?

Это классический дрейф агента (Agent Drift), вызванный стохастичностью модели в отсутствие внешнего верификационного контура (Verification Gate).
Если агент предоставлен сам себе и оценивает качество работы собственным «мнением», любая случайная микроошибка на шаге N сбивает его рассуждения. На шаге N+1 агент начинает подстраивать логику под свою же ошибку, попадает в цикл галлюцинаций или начинает блуждать кругами.
Решение: жесткие стоп-условия и внешний контур проверки. Агенту запрещено объявлять задачу выполненной без прохождения независимых проверок (assert'ов, тестов, соответствия схеме). При непрохождении проверки агент обязан остановиться или запросить помощь оператора, а не импровизировать.

3. Почему появляется сообщение об ошибке, хотя агент на самом деле продолжает работать?

Этот парадокс возникает из-за рассинхрона между UI-интерфейсом и фоновым воркером агента.
Сложные агентские цепочки (поиск по репозиторию, запуск тестов, пересборка) занимают от 30 секунд до нескольких минут. Если веб-сокет или HTTP-шлюз между клиентом и сервером имеет стандартный таймаут (10–15 секунд), соединение сбрасывается по таймауту и интерфейс показывает ошибку «Агент не отвечает». При этом на бэкенде агент продолжает корректно выполнять поставленную задачу.
Решение: архитектура асинхронных очередей задач с периодической отправкой heartbeat-сигналов и промежуточных статусов в интерфейс пользователя.

4. Что делать, если ИИ-агент останавливается на середине запроса или часто прерывается?

Причинами остановки на полуслове обычно выступают исчерпание лимитов генерации (max_tokens), превышение рейтлимитов провайдера (HTTP 429 Too Many Requests) или таймаут выполнения инструмента (tool call timeout).
Если агент вызвал внешнюю утилиту, а она не вернула ответ вовремя, поток агента зависает в вечном ожидании ответа инструмента.
Решение: индивидуальные таймауты для каждого вызова инструментов, обработка рейтлимитов с экспоненциальным backoff'ом и разделение задач на короткие атомарные подэтапы.