РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-12
Подтверждение действий AI-агента: как согласовать конкретную операцию
Практический порядок согласования записи, отправки и удаления: от подготовленного предложения до проверенного результата.
Подтверждение человеком должно относиться к конкретной операции: кому отправляется сообщение, какие записи меняются и с какими параметрами. Подготовьте предложение, сохраните его версию, покажите последствия и только после ответа проверьте полномочия и актуальность. Согласие на старую версию не переносится на изменённый адрес или сумму. В интерфейсе различайте ожидание решения, отклонение, выполнение и неизвестный исход: кнопка «Подтвердить» сама по себе не доказывает результат.
1. Определите операции, требующие решения
Составьте правила для инструментов: чтение справки, подготовка черновика, отправка сообщения, изменение записи, удаление файла. Не заставляйте человека подтверждать каждое чтение: это создаёт привычку соглашаться автоматически. Для существенного действия задайте точные границы — получателя, объект, разрешённые поля и срок действия. Модель предлагает операцию, а прикладной код определяет, требуется ли решение по этой политике.
2. Подготовьте понятное предложение
Покажите прежнее и новое значение, адрес назначения, содержание сообщения и ожидаемые последствия. Например: «Отправить клиенту этот текст по указанному адресу», с полным текстом и вложениями. Сохраните идентификатор предложения и версию параметров. Если агент изменил документ после просмотра, прежнее согласие становится непригодным: пользователь должен увидеть новую редакцию. Изложение намерения без конкретных параметров недостаточно.
3. Сохраните ожидание без побочных эффектов
Состояние ожидающей операции должно переживать перезапуск приложения. LangGraph поддерживает остановку через interrupt и продолжение с сохранённым состоянием; при возобновлении узел запускается сначала. Поэтому действия до точки остановки могут повториться. В собственном процессе также отделите подготовку от исполнения: не отправляйте письмо перед созданием карточки согласования и не полагайтесь на память браузерной вкладки.
4. Проверьте согласие перед исполнением
На сервере проверьте пользователя, его право на объект, версию предложения, срок и состояние операции. Одобрение и отклонение должны иметь однозначный переход состояния. Двойной клик, повторный HTTP-запрос и возобновление после сбоя не создают дополнительную отправку. Если внешний сервис поддерживает ключ идемпотентности, используйте его согласно документации; локальная блокировка сама по себе не гарантирует однократный внешний эффект.
5. Покажите проверенный итог
После ответа внешнего сервиса сохраните его идентификатор и фактический результат. При таймауте не пишите «отправлено» и не повторяйте вслепую: выясните состояние по журналу или адресу объекта. Проверьте сценарии отказа, истечения срока, изменения прав, повторного подтверждения и падения после внешнего действия. Завершение процесса согласования и успешное выполнение — разные события, которые полезно показывать отдельными статусами.
Частые вопросы
Достаточно ли попросить модель всегда спрашивать разрешение?
Нет. Инструкция помогает поведению, но сервер должен ограничивать выполнение инструментов. Проверка происходит по фактическим аргументам операции, а не по обещанию в ответе.
Можно ли исправить параметры при согласовании?
Да, если интерфейс явно показывает исправление. Сохраните новую версию, повторите проверку прав и выполняйте именно её. Не подменяйте предложение после того, как человек его одобрил.
Что делать, если человек не ответил?
Оставьте действие ожидающим или завершите его по заранее заданному сроку. Отсутствие ответа не считается одобрением. Возобновление должно сохранять идентификатор исходного предложения.
Как проверить процесс без реальной отправки?
Используйте инструмент-заглушку с журналом вызовов. Проверьте двойной клик и перезапуск, затем отдельно согласуйте ограниченную интеграционную проверку внешнего эффекта. Заглушка не доказывает надёжность реальной доставки.