Почему ИИ-агентам нужны доказательства, прежде чем повторять попытку

Как не допустить, чтобы потерянный ответ привёл к повторному действию

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

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

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

Отсутствие ответа не доказывает, что действие не выполнено

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

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

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

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

Недавнее исследование оценивает риск

Препринт, опубликованный в сентябре 2026 года, «Где обеспечивается однократное выполнение?» (Where Does Exactly-Once Live?), представил тест LIMBO и проверил 25 930 эпизодов на девяти моделях. В ходе тестирования использовались имитационные сервисы с потерянными подтверждениями, задержанной обработкой и повторной доставкой.

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

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

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

Повторные попытки относятся к одному и тому же намерению

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

В документации API Stripe приведены примеры как возможностей, так и ограничений ключей идемпотентности. В API v1 ключи можно удалять не ранее чем через 24 часа. Повторное использование удалённого ключа приведёт к созданию нового запроса. Stripe также проверяет, совпадают ли параметры, переданные отправителем запроса, с параметрами первоначального запроса.

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

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

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

Одних описаний инструментов недостаточно

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

Считайте неопределённость рабочим состоянием

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

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

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

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

Для устранения последствий сбоя может потребоваться другой бизнес-процесс

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

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

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

Проверьте повторную попытку до развертывания

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

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

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

Вопрос для оценки должен быть сформулирован четко. Смогла ли система объяснить:

• Какая операция была разрешена?
• Какие данные подтверждали ее результат?
• Почему было допустимо предпринять еще одну попытку?

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