Построение безопасного конвейера доставки для агентов
В большинстве демо-версий агентов упускается жизненно важный вопрос. Как позволить автономной системе отправлять что-либо от вашего имени, не допуская повторных отправлений или передачи несогласованных результатов?
Повторная отправка — это не редкая ошибка. Это поведение по умолчанию для простой очереди, когда воркер завершает работу посреди задачи. Воркер отправляет сообщение, а затем аварийно завершает работу до того, как зафиксирует успех. Система считает, что задача провалена, и дает команду новому воркеру попробовать снова. Клиент получает два письма, а вы — тикет в службу поддержки.
Вы не можете предотвратить каждый сбой. Вы должны проектировать систему с расчетом на сбой в промежутке между действием и записью результата.
Используйте этот шестиэтапный конвейер для любых результатов работы агента, имеющих реальные последствия:
• Produce (Создание): Агент генерирует полный артефакт. Пока ничего не отправляется. • Persist (Сохранение): Сначала запишите намерение и артефакт в надежное хранилище. • Score (Оценка): Прикрепите к результату показатель уверенности (confidence score). • Review (Проверка): Направляйте элементы с низким уровнем уверенности человеку. • Approve (Одобрение): Используйте шлюз с принципом «закрыто по умолчанию» (fail-closed). Система блокирует все отправки, пока человек не даст явное разрешение. • Send and Attest (Отправка и подтверждение): Отправьте объект по аренде (lease), а затем запишите квитанцию-подтверждение.
Каждый этап должен быть отдельным надежным переходом. Состояние должно храниться в вашей базе данных, а не в памяти воркера.
Чтобы предотвратить дубликаты, используйте аренду на уровне строк (row-level leasing). В Postgres используйте SELECT ... FOR UPDATE SKIP LOCKED. Это гарантирует, что в каждый момент времени задачу владеет только один воркер.
Самое важное правило — то, как вы обрабатываете истекшие аренды. Если воркер завершает работу во время отправки внешнего сообщения, не пытайтесь повторить попытку автоматически. Вместо этого оставьте задачу в подвешенном состоянии для проверки человеком. Видимая зависшая задача лучше, чем невидимая повторная отправка.
Вы также должны следовать принципам «закрыто по умолчанию» (fail-closed):
- Отправка выключена по умолчанию. Один флаг должен включать весь исходящий трафик.
- Личность проверяется. Система должна проверять адрес отправителя и безопасность транспорта в момент отправки.
- Каждая операция оставляет квитанцию. Незаписанная отправка — это сбой.
Не стройте это для задач с низкими ставками, таких как внутренние логи. Используйте это, когда ошибка стоит денег, создает юридические проблемы или требует обращения в службу поддержки.
Optional learning community: https://t.me/GyaanSetuAi