Агент упал на полпути: как повторить, не заплатив и не сделав дважды

ai-agentsidempotencyreliability

Опубликовано 2026-10-22

Автор: Talomnia team

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

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

Ниже: что на самом деле значит «агент упал», публичные случаи неудачных повторов, простое решение и что продавцы агентов пишут об оплате сбойных прогонов. Всё проверено 22 октября 2026 года.

Что на самом деле значит «агент упал»?

За словами «агент упал» стоят три разные ситуации, и безвредна только одна.

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

В задаче на GitHub к MCP-серверу last9 от 16 октября 2026 года это сказано одной фразой: «A write that times out or fails in transport may still have been applied upstream» (запись, которая упала по таймауту или в пути, всё равно могла примениться на той стороне). 18 октября разработчики закрыли задачу, влив исправление. Вывод верен для любого агента, который что-то пишет во внешнюю систему: сообщение об ошибке не доказывает, что ничего не произошло.

Как один повтор превращается в два письма, два платежа, два комментария

Статистики о том, как часто это случается, нет. Есть отдельные публичные отчёты, и в них раз за разом одна и та же картина.

Платежи, в тесте. В задаче Upsonic от 4 октября 2026 года разработчик запустил локальный тестовый реестр (ничего не выходило за пределы 127.0.0.1). С документированной настройкой «три повтора» агент «paid three times for one requested payment» (заплатил трижды за один запрошенный платёж), потому что «the tool cannot tell a repeat from a new call» (инструмент не отличает повтор от нового вызова). Это один отчёт и локальное воспроизведение, без настоящих денег.
Комментарии на GitHub. В задаче verdity от 23 сентября 2026 года ошибка возникает уже после того, как пост на GitHub опубликован, и повтор «re-posts a duplicate comment/review» (публикует дубль комментария или ревью).
Ответы в чате. Задача OpenClaw от 21 октября 2026 года: после reasoning-only повтора агент считает уже доставленный ответ потерянным и «resends it verbatim on the next turn» (отправляет его заново слово в слово). Это дубль сообщения в чате, а не письма или платежа, но механизм тот же.
Списания, как описанный пробел. В открытой задаче в репозитории ИИ-инструментов самой Stripe (создана 3 мая 2026 года, обновлена 8 октября) заголовок: «Agent-level retry creates duplicate charges — no idempotency guard above the tool layer» (повтор на уровне агента создаёт двойные списания — нет защиты идемпотентности выше слоя инструмента). Это описание сценария, который инструменты пока не закрывают, а не сообщение о подтверждённом двойном списании у клиента.

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

Решение простыми словами: один ключ на одно действие

Инженеры называют это идемпотентностью. Идемпотентность простыми словами: выполнить один и тот же запрос дважды — то же самое, что выполнить его один раз.

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

Продавец почтового API SentFromAI описывает это в блоге 6 октября 2026 года: «persist one identifier for each intended send, reuse it on every API retry, and keep the approved recipients and body unchanged» (сохранить один идентификатор для каждой задуманной отправки, использовать его при каждом повторе и не менять одобренных получателей и текст). И ещё: «A retry should repeat the same action, not ask the model to invent a new one» (повтор должен повторять то же действие, а не просить модель придумать новое). На той же странице честно названа граница: «That is a send-request contract, not a guarantee that every workflow step runs once or that a person receives and reads the email» (договорённость о запросе на отправку, а не гарантия, что каждый шаг сценария выполнится один раз или что человек получит и прочитает письмо).

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

Что важно покупателю: ключ привязан к задуманному действию, а не к каждой попытке. Если агент при каждом повторе создаёт новый ключ, такой ключ ничего не защищает.

Сначала проверь, и спроси снова, если что-то изменилось

Ключ помогает, только если другая система его поддерживает. Вторая защита — посмотреть перед повтором: ушло ли письмо, списан ли платёж, есть ли уже комментарий?

Заголовок той же задачи last9 говорит прямо: «never retry after ambiguous failures; tell the agent how to check» (не повторять после неясных сбоев; объяснить агенту, как проверить). Агент, который не может проверить, должен остановиться и сообщить, а не гадать.

Второе правило касается изменений. В практическом руководстве на technologyonthe.net (2 октября 2026 года; это блог, а не спецификация продавца) сказано, что запрос с тем же ключом, но другими параметрами нужно отклонять: «Do not silently run the new payload» (не выполнять молча новое содержимое). Если между попытками изменились сумма, получатель или текст, такой «повтор» — уже другое действие.

Отсюда связь с одобрением. Если вы одобрили гипотетический платёж — например, «заплатить 400 евро этому поставщику» — ваше «да» относится к этому конкретному платежу. Повтор с другой суммой или на другой счёт — новое действие, и на него нужно новое «да». Какие действия агент всегда должен приносить человеку, мы разбирали в статье что агент обязан спросить у человека.

Кто платит за упавший прогон?

Здесь продавцы расходятся. У каждой строки ниже указана дата страницы, с которой она взята; всё проверено в октябре 2026 года.

Продавец	Упавший или прерванный прогон	Кто решает	Дата источника
Manus	Кредиты возвращают при verifiable bug или сбое платформы, в том числе если агент остановился посреди задачи без веской причины и не выдал никакого результата; не возвращают за проблемы в инструкциях пользователя, субъективное недовольство и встроенные ограничения ИИ	ИИ-агент и команда Customer Success, после проверки	16.12.2025
Devin	Старые корпоративные тарифы с кредитами: неуспешное сообщение кредиты не расходует; новые тарифы считаются иначе	Не указано	Страница изменена 19.10.2026
Cursor	За прогоны, прерванные на середине, списывают (пост сотрудника, 2025); прогон продолжается с серверных контрольных точек, повторы устроены так, чтобы не повторять сделанное (ответ сотрудника, 2026)	Отдельного правила не указано; сотрудник предлагает написать в поддержку	22.10.2025; 23.07.2026

«Не указано» значит, что на проверенной странице мы этого не нашли.

Manus возвращает кредиты полностью, если «our investigation confirms» (проверка подтверждает) «verifiable bug or platform malfunction» (проверяемый баг или сбой платформы), в том числе когда агент «stops mid-task without a valid reason» (останавливается посреди задачи без веской причины) и «fails to deliver any results» (не выдаёт никакого результата). Заявки рассматривают «specialized AI agent» (специальный ИИ-агент) и команда Customer Success. Не возвращают за проблемы в ваших собственных инструкциях, за «subjective satisfaction with the outcome» (субъективное отношение к результату) и за «the inherent limitations of AI» (встроенные ограничения ИИ). То есть возврат следует за проверкой, а не за самой заявкой. Если баг подтверждён, страница пишет, что credit refund затем processed automatically (возврат кредитов проводится автоматически).

Devin на странице об использовании, в разделе о старых корпоративных кредитах, пишет: «If a message is unsuccessful, prompt credits will not be consumed» (если сообщение неуспешно, кредиты не расходуются). На той же странице описаны более новые тарифы, которые считаются иначе (тарифы с оплатой по использованию для самостоятельных клиентов, введённые в марте 2026 года, и корпоративные тарифы на ACU), так что это правило не для всех тарифов Devin.

Cursor: сотрудник написал на форуме в октябре 2025 года: «We believe it's fair to charge for runs that get stopped mid-flight» (мы считаем справедливым списывать за прогоны, прерванные на середине). В более позднем ответе сотрудника, в июле 2026 года, сказано, что ходы агента идут через «server-side checkpoints» (серверные контрольные точки), а клиент продолжает работу «with retries designed not to repeat completed work» (с повторами, которые не повторяют уже сделанную работу). Читайте оба ответа вместе и с датами.

Сбойный прогон может стоить денег и после остановки по лимиту. В задаче Claude Code от 8 октября 2026 года один пользователь пишет, что фоновые процессы продолжали работать после остановки по лимиту: 59 235 вызовов API и примерно $2000 (roughly $2,000) расхода за 17 часов, 88% из них уже после отсечки. Это один отчёт, задача открыта, пользователь просил возврат $2k. Хороший повод спросить, что на самом деле останавливают лимит и кнопка «Стоп». Как заранее поставить потолок расходов, мы разбирали в статье потолок бюджета или оценка.

Пять вопросов продавцу агента о повторах

Чтобы их задать, не нужно читать код. Хорошие ответы конкретны и записаны.

Если агент отправил письмо или платёж и упал раньше, чем получил подтверждение, что будет при повторе? Как вы узнаёте, что действие уже произошло?
Моё одобрение относится к конкретному действию (получатель, сумма, текст) или ко всему прогону? Если при повторе что-то меняется, вы спрашиваете меня снова?
После сбоя вы продолжаете с последнего подтверждённого шага или начинаете заново? Какие шаги вы считаете необратимыми?
Кто платит за упавший или прерванный прогон и где это написано? Входят ли упавшие прогоны в мой лимит расходов?
Если я нажимаю «Стоп» или срабатывает лимит, останавливаются ли фоновые процессы? Есть ли ограничение на число вызовов?

Если в ответ звучит «такого не бывает», спросите, как они об этом узнают. Все случаи выше начинались с системы, которая считала, что такого не бывает.

Как у нас ставится и принимается работа, смотрите в разделе как в Talomnia устроена работа.

Источники

Вопросы

Что будет, если ИИ-агент упал после отправки письма?

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

Что такое ключ идемпотентности простыми словами?

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

Берут ли продавцы ИИ-агентов деньги за упавшие прогоны?

По-разному (проверено в октябре 2026). По справке Manus (16 декабря 2025) кредиты возвращают, если проверка подтвердит verifiable bug или сбой платформы; в документации Devin для старых корпоративных тарифов с кредитами сказано, что неуспешные сообщения кредиты не расходуют; сотрудник Cursor 22 октября 2025 писал, что считает справедливым списывать за прогоны, прерванные на середине, а 23 июля 2026 года сотрудник ответил, что прогон продолжается без повтора уже сделанной работы.

Должен ли агент снова спрашивать перед повтором платежа?

Если в платеже что-то изменилось (сумма, получатель), да: прежнее одобрение относилось к другому действию. Если ничего не изменилось, сначала нужно проверить, не прошёл ли платёж.