Зачем агенту кнопка «проверить»

В типичном процессе поддержки сотрудник открывает обращение, ищет историю клиента в CRM, сверяется с правилами, готовит ответ и меняет статус заявки. Модель может прочитать контекст, найти нужную инструкцию и предложить черновик. Но если у неё сразу есть право отправлять письма, обещать компенсацию и менять карточки, ошибка в одном шаге превращается во внешний бизнес-результат.

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

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

Разделите действия по последствиям

До разработки разложите операции на три группы.

  • **Можно автоматизировать в пилоте:** классифицировать обращение, извлечь номер заказа, составить резюме, подготовить черновик ответа, предложить категорию или назначить задачу по фиксированному правилу. Эти шаги сами не отправляют сообщение и не меняют деньги или права доступа.
  • **Нужно явное подтверждение:** отправка внешнего письма, обещание срока или скидки, смена ответственного с влиянием на SLA, возврат или списание, публикация текста, закрытие обращения с важными последствиями.
  • **Не давать как инструмент:** произвольный SQL, массовое удаление, изменение ролей доступа, перевод денег и любые операции, для которых в компании предусмотрен отдельный процесс или двойной контроль.

Это не универсальная юридическая классификация. Уровень контроля определяют последствия, обратимость и действующие полномочия. Черновик можно пересоздать; уже отправленное клиенту обещание отменить гораздо труднее.

Схема: предложить, проверить, выполнить

Стройте поток как явные состояния, а не как один длинный промпт.

1. **Получить задачу и контекст.** Интеграционный слой проверяет права пользователя и получает только нужные поля CRM. Для поиска по регламентам добавьте RAG: агент получает релевантные выдержки с источником и датой документа, а не весь архив.
2. **Подготовить структурированное предложение.** Например, поля `action`, `customer_id`, `draft_text`, `reason`, `source_ids` и параметры действия. Свободный текст не должен напрямую становиться командой к CRM.
3. **Проверить предложение кодом.** Валидатор проверяет схему, клиента, допустимые поля, лимит скидки, статус заявки и актуальность записи. Неизвестное действие или нарушенное условие означает отказ либо запрос уточнения.
4. **Остановиться на проверке.** Человек видит, что будет сделано, кому, на основании каких данных и что изменится. Он может подтвердить, исправить или отклонить предложение.
5. **Повторно проверить после подтверждения.** Сервер удостоверяется, что сотрудник аутентифицирован и вправе выполнить действие. Затем проверяет бизнес-правила ещё раз: данные могли измениться во время ожидания.
6. **Выполнить узкую команду.** Предпочтительны отдельные операции вроде `save_reply_draft`, `send_approved_reply` и `set_ticket_category`, а не универсальное `update_record(any JSON)`. Исполнитель получает минимальные права и параметры только из одобренной версии.
7. **Записать итог и безопасно восстановиться.** Храните ID заявки, автора подтверждения, одобренные параметры, результат CRM и время. При сбое не повторяйте действие вслепую: проверьте прошлую попытку, используйте ключ идемпотентности или запросите ручную сверку.

В OpenAI Agents SDK чувствительный вызов инструмента может приостановить запуск и продолжиться после решения с сохранённым состоянием. В LangGraph для паузы, checkpoint и возобновления предусмотрены `interrupt` и persistence. Это примеры механизмов, а не требование выбирать определённый стек.

Карточка подтверждения — часть контроля

Если сотрудник видит только «Агент просит разрешение», ему трудно заметить ошибку. Покажите:

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

Подтверждение относится к конкретному действию и параметрам. Если после согласования модель может поменять текст, сумму или получателя, это уже другое действие. Существенная правка должна возвращать запрос на проверку.

Минимальная архитектура

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

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

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

Где нужен RAG — и где он бессилен

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

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

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

Риски и защита от повторов

Пауза снижает риск, но сама по себе не обеспечивает безопасность. Нужны серверные контроли:

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

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

Как оценить пилот

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

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

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

План первого запуска

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

Что взять руководителю

Не спрашивайте сразу: «Может ли модель сама отвечать клиентам?» Сначала определите, что она может только предложить, что сотрудник должен подтвердить и где требуется отдельный контроль. Затем дайте агенту один небольшой участок процесса с измеримым результатом и журналом решений.