Автономные ИИ-агенты на долгой дистанции: как мы пересобрали внедрение после того, как агент сорвался на третьем дне

Клиент, крупный поставщик оборудования по 44-ФЗ, попросил простое: «Сделайте так, чтобы ИИ-агент вёл тендер от публикации до итогов, а нам показывал только важное». Обычно наш агент отрабатывал сценарий за один-два прохода — прилетел документ, разобрал, ответил. Здесь же ему предстояло жить внутри одной задачи две-три недели.

Мы это дело недооценили. И к третьему дню автономного прогона агент сорвался.

Почему длинные задачи — это другой жанр

В индустрии одновременно случились несколько показательных релизов. Salesforce представил Agentforce с job-ready агентами, которые заявлены на многодневные и многонедельные горизонты. Databricks в новом Agent Bricks вынес durable execution в отдельную функцию. OpenAI выкатил Agents API в бете — управляемый рантайм для долгоживущих облачных агентов. Все они, если убрать маркетинг, решают одну задачу: как заставить агента не терять себя в течение долгой работы.

Мы шли туда же — только со стороны PostgreSQL, FastAPI и российских моделей. И у нас была отдельная причина: заказчик работал по 44-ФЗ, а значит облачный managed harness от зарубежного вендора никак не подходил.

Настройка ИИ-агента, который отрабатывает за один вызов, и настройка агента, который живёт две недели, — это два разных инженерных упражнения. Мы это осознали не сразу.

Первый прогон: где именно всё поехало

Первая версия была прямолинейной. Агент раз в час просыпался, ходил в ЕИС, сверял состояние тендера, при появлении вопросов участников готовил проект ответа, при публикации протокола снимал результат. Контекст мы просто складывали в память процесса и восстанавливали при рестарте из последней записи в базе.

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

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

Что мы поменяли в архитектуре

Мы сели и переписали настройку ИИ-агента вокруг явного жизненного цикла. Фазы прописали руками: мониторинг публикации, период вопросов и разъяснений, подготовка заявки, приём результатов, разбор итогов. Каждая фаза — отдельный набор инструментов, отдельный системный промпт, отдельные критерии перехода дальше.

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

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

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

Второй прогон: продержались дольше, но поймали новое

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

Дальше выяснилось банальное. Правила закупок компании мы зашили в системный промпт первой версии, а во второй, короткой, они частично потерялись. Промпт-инженерия при делении на фазы — отдельная работа, которую мы просто не доделали. Разложили роли и инструменты, а декларативные правила бизнеса — нет.

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

Про подтверждения и границы автономии

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

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

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

Что изменилось в итоге

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

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

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

Что мы вынесли для себя

Автономные ИИ-агенты на длинной дистанции ломаются не там, где ждёшь. Не в модели, не в MCP-сервере, не в API площадки. Они ломаются в том, чего у одноразовых агентов просто нет: в границах между фазами, в устойчивом состоянии, в декларативных правилах, которые нужно применять в каждой новой сессии.

Если вы планируете внедрение ИИ-агентов не под задачи вида «ответь на письмо», а под задачи вида «веди процесс, пока он не закончится», — закладывайте на архитектуру состояния и жизненного цикла столько же внимания, сколько на модель и промпты. Мы, судя по трём итерациям, потратили примерно поровну.

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

Похожие статьи

• «Хочу ИИ-агента прямо на ноутбук, как у Perplexity»: разбираемся, какие есть ИИ-агенты для ПК и что реально стоит покупать
• ИИ-агент для 1С после сентябрьских атак: как мы переписали правила доступа, не сломав рабочие сценарии
• Купили кодинг-агента, половину задач всё равно писали сами: где ИИ-агент в разработке нужен, а где хватает ассистента
• Пять человек вместо одного оператора: как мы пересобрали курс по ИИ-агентам под управление в 2026