Агент на 30 шагов при 1% сбоев падает в каждой четвёртой задаче: как довести его до прода

Агент в демо ведёт себя идеально: 10 шагов из 10, все довольны. В проде он выполняет тысячи задач, и вылезает всё сразу: модель путает инструменты, контекст забит мусором, поиск не находит нужное, процесс падает посреди задачи. Вторая часть серии на Habr посвящена тому, что с этим делать. Разберём главное.

Арифметика, из-за которой демо не равно проду

Представьте, что задача состоит из 30 шагов, и каждый шаг падает раз из ста: моргнула сеть, API ответило «перегружено». Тогда до конца задача дойдёт в 74% случаев. Каждая четвёртая упадёт. При 3% сбоев на шаг доберутся только 40%. Автор честно оговаривается, что это условный расчёт: он предполагает независимые временные сбои. Если провайдер лёг целиком, три быстрых повтора не помогут, нужна длинная пауза или запасной провайдер.

Инструменты и контекст: меньше, но точнее

Модель знает об инструменте только имя, описание, схему параметров и то, что он вернул. Поэтому инструмент для агента пишут иначе, чем API для программиста. Не делайте по инструменту на каждый эндпоинт: вместо list_users, list_events и create_event лучше один schedule_event, который сам найдёт время и создаст встречу. Ответы делайте короткими и с понятными именами вместо uuid. В примере Anthropic краткий режим Slack-инструмента вернул 72 токена вместо 206. Ошибки пишите для модели: фраза «дата нужна в формате 2026-11-09, пришло 09.11» исправится на следующем ходе сама, голый код 400 ничего не скажет.

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

RAG: сначала решите, нужен ли он

Если база знаний меньше 200 тысяч токенов (около 500 страниц), её можно целиком положить в промпт и закэшировать. Поиск тогда не нужен. Если база больше, по замерам Anthropic помогает связка: поиск по смыслу плюс поиск по словам (BM25), контекст из 50–100 токенов к каждому куску перед индексацией и переранжирование. Доля провалов, когда нужный кусок не попал в 20 лучших, упала с 5,7% до 1,9%. Поиск проверяйте отдельно от ответа: заведите вопросы с известным местом ответа и считайте, как часто кусок попадает в выдачу. Иначе непонятно, виноват поиск или модель.

Цикл под контролем: ходы, деньги, ретраи

Начинайте с цепочки, а не с агента: агент платит за свободу задержкой и деньгами. Если он всё же нужен, задайте три ограничителя: лимит ходов, бюджет в долларах и таймаут на всю задачу. Цена растёт быстрее числа ходов, ведь каждый ход заново читает историю. По расчёту автора задача на 30 ходов стоит $0,51, а застрявший агент на 100 ходах обойдётся в $2,68: ходов в 3,3 раза больше, денег в 5,3 раза. Заранее решите, куда уходит задача, когда попытки кончились: запасная модель, простая цепочка или человек.

Повторять стоит только временные сбои вроде 429, 500, 504 и 529, с растущей паузой. Тонкость в том, что 429 бывает и при исчерпанном месячном лимите трат (код enforced_spend_limit_reached). Тогда повтор бесполезен, а ретрай без различения будет долбить API часами.

Опасно не падение, а повтор

Представьте инструмент send_email: письмо ушло, но ответ потерялся, обвязка повторила вызов, и клиент получил два письма. С charge_card так же дважды спишутся деньги. Решение известно из Stripe: ключ идемпотентности. Сервер запоминает ответ на первый запрос с ключом и на повтор отдаёт сохранённый. У агента такой ключ уже есть, это id вызова инструмента, который не меняется при повторе. Передавайте его дальше во внешнюю систему. Но если процесс упадёт между отправкой и записью результата, локальная проверка дубль не поймает. Действия без поддержки ключа на стороне внешней системы, а также отправку, платёж и удаление, отдавайте человеку на подтверждение.

Если упал сам процесс, повторять нечего: история и результаты лежали в памяти. Тут нужно устойчивое выполнение, например Temporal. Цикл агента живёт в workflow, а вызовы модели и инструментов становятся activities, события пишутся в журнал, и другой воркер продолжает с места падения. Условие: код workflow детерминирован, а activities идемпотентны. Цена вопроса: падение на 25-м ходе с перезапуском с нуля даёт $0,93 вместо $0,51, то есть +81%.

Что делать на практике

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

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