Проблема не в кнопке «Одобрить»

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

Это не описание конкретного инцидента, а типовая ситуация для проектирования. Чем дольше агент ждёт человека, тем больше вероятность, что исходные данные и полномочия изменятся. Поэтому безопасное согласование — не диалоговая фраза «да, можно», а запись о том, кто одобрил какую именно операцию над какой версией объекта и до какого времени.

Что даёт пауза в графе, а чего она не даёт

В документации LangGraph `interrupt()` останавливает выполнение, сохраняет состояние через checkpointer и позволяет продолжить его после внешнего решения. Для возобновления нужен тот же `thread_id` и значение, переданное через `Command(resume=...)`. Официальная схема LangGraph показывает путь «модель — человек — исполнитель инструмента»: человек стоит перед внешним действием, а не наблюдает его постфактум.

Но остановка сама по себе не является разрешением. Документация также предупреждает: при возобновлении код узла до `interrupt()` выполняется заново. Если до паузы он успел отправить письмо или обновить CRM, повторный запуск может повторить побочный эффект. Внешнюю запись надо отделить от подготовки предложения, а повторяемые операции — защищать идемпотентностью. LangGraph предоставляет механизм паузы и состояние; срок действия решения, сверка прав и блокировка дублей остаются обязанностью приложения.

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

Минимальная схема для одной операции

Для пилота возьмём изменение поля сделки в CRM, а не денежный перевод или массовое удаление. Поток можно разделить на шесть явных шагов:

1. Агент читает разрешённые данные и формирует **предложение**, но не вызывает метод записи.
2. Приложение сохраняет структурированный план: идентификатор сделки, поле, старое и новое значение, версию записи, инициатора, источник данных и уникальный номер операции.
3. Менеджер видит именно эти значения и деловой контекст; интерфейс показывает, что будет изменено, а не только красивое резюме модели.
4. Согласование сохраняется отдельно: кто нажал кнопку, на какую версию плана, при каких полномочиях и до какого срока оно действительно.
5. Перед записью исполнитель повторно проверяет права, срок, совпадение плана и текущую версию сделки. Изменившийся объект возвращается человеку на новое решение.
6. После условной записи система сохраняет результат и идентификатор операции, чтобы повторный запуск не выполнил ту же команду второй раз.

Хеш или подпись плана полезны как способ заметить изменение параметров между показом и исполнением, но не заменяют авторизацию. Для CRM, поддерживающей условное обновление по версии или ETag, используйте его: простая проверка «прочитал, затем записал» оставляет окно гонки. Если API не умеет условную запись, риск нужно явно ограничить меньшим набором операций, дополнительной проверкой или ручным исполнением.

Какие данные и инфраструктура потребуются

Нужен не только LLM-сервер. Требуются проверенная учётная запись инициатора, матрица прав на действие, неизменяемая запись предложения, долговременное хранилище состояния паузы, очередь уведомлений менеджеру, исполнитель с минимальными правами к CRM и журнал «предложено — одобрено — выполнено/отклонено». Для локального контура все эти компоненты должны оставаться внутри разрешённой сети; саму модель можно заменить без изменения правила согласования.

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

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

Экономика и ограничения

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

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

Проверка за короткий пилот

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

Если эти проверки проходят, можно оценивать качество самой модели и время, которое она экономит. Если нет, увеличивать автономность преждевременно. Самый полезный вывод для руководителя: согласовывать нужно конкретное и актуальное действие, а не намерение агента «что-то поправить в CRM».