Очередь сообщений отделяет приём задачи от выполнения: агенты проверяют повторы и результат

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

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

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

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

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

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

Если обработчик упал, незавершённая работа должна остаться доступной для восстановления. В Yandex Message Queue полученное сообщение временно скрыто: без удаления оно вернётся после таймаута видимости. Поэтому «сейчас не видно в очереди» ещё не означает «сделано».

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

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

Наш опыт здесь относится к собственной автоматике vibecoding.ru. Инженер ведёт машину агентов; её публичный выход показывает открытая машина проекта. Клиентского кейса очереди сообщений и собственного кейса внедрения RabbitMQ или Kafka у нас в этом материале нет.

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

Та же тема есть в курсе агентной разработки: урок «Очередь и дверь: первый пост без рук» посвящён автоматике публикации. Здесь нас интересует общее правило: приём работы и её результат проверяют отдельно.

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

Ответ HTTP 202 означает приём для обработки. Даже HTTP 200 при чтении статуса может означать только, что статус успешно прочитан, а работа ещё идёт. Человек должен увидеть «ожидает», «выполняется», «нужен разбор» или конечный результат, а не угадывать смысл зелёной кнопки.

Граница «готово» зависит от задачи. Для выгрузки это файл, который открывается и совпадает с эталоном на тестовых данных; для выдачи доступа это возможность войти; для письма принятие почтовым сервисом и доставка адресату являются разными событиями. Назовите нужное событие заранее и сохраните его подтверждение.

ИИ-агент в этой статье разрабатывает фоновый обработчик. Сам обработчик может быть обычной программой без ИИ. В правила для агентов записывают ключ операции, момент подтверждения, допустимые повторы и критерий «готово»; второй агент проверяет реализацию по тем же сценариям.

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

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

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

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

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

Подписка на разработку «Один проект» стоит 250 000 ₽/мес на 8 октября 2026. Это цена месячного потока работы, не отдельного внедрения RabbitMQ или Kafka. Объём фоновой обработки и расходы на работу продукта согласуют под ваш проект.

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

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

1. Разделите «принято» и «завершено». У каждой принятой заявки должны остаться работа для выполнения и способ узнать результат.

2. Проверяйте повтор на уровне бизнес-действия. Одно сообщение может прийти снова, а доступ, списание или публикация не должны появиться второй раз.

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

4. Принимайте работу агентов после прогона сбоев. Запуск без ошибки показывает удачный путь; восстановление показывает, выдержит ли система обычные неудачи.