Действие с откатом: как ИИ-агенты для бизнеса научились сначала показывать, а потом делать

Есть момент, который отделяет чат-бота от настоящего агента: когда он впервые что-то пишет во внешнюю систему. Не отвечает вежливо, не пересказывает документ, а сам заводит контрагента, сдвигает срок, отправляет письмо. С этого шага начинается пугающая часть — потому что теперь ошибка модели не остаётся у неё в голове, она уходит в 1С, в CRM, в почту клиента.

Мы столкнулись с этим на одном из внедрений, когда наш агент на GigaChat Pro впервые «пошёл» в 1С не читать, а писать. По ТЗ он должен был помогать менеджеру заводить входящие заявки: разобрать почту, вытащить контрагента, сумму, номенклатуру, оформить документ. На тесте всё выглядело прилично. А потом коллега из отдела продаж прислал письмо, где один и тот же клиент был написан двумя разными способами — с ООО и без, с пробелами и без — и агент честно завёл двух контрагентов вместо одного.

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

Почему «просто сделай» — это ловушка

Когда мы говорим про создание ИИ-агента, обычно представляем себе диалог: пользователь спросил — агент ответил. В этой картине всё симметрично, и цена ошибки — переспросить.

Но ИИ-агенты для бизнеса живут не в диалоге. Они дёргают инструменты, а инструменты меняют состояние систем. У «отправить письмо» нет кнопки «отменить»: получатель уже увидел. У «создать документ» есть, но только пока никто не поставил печать. У «списать со склада» — обычно нет вообще.

Модель ошибается не так, как ошибается человек. Она уверенно сгенерирует правдоподобный ИНН, если ей не хватило данных. Она склеит две задачи в одну, если промпт неоднозначен. Человек в этот момент остановился бы и переспросил. Языковая модель — не всегда.

Первая попытка: подтверждение на каждое действие

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

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

Это классическая история про модальные окна. Если просить подтверждение слишком часто, ты не защищаешь пользователя — ты приучаешь его игнорировать защиту.

Что мы сделали вместо: предпросмотр и фиксация

Мы разделили жизнь действия на две фазы. Первая — предпросмотр: агент собирает намерение, оформляет его в виде объекта («создать контрагента такого-то, приложить документ такой-то, ссылка на источник — вот эта строка в письме») и возвращает его в ответе. Ничего в 1С при этом ещё не происходит.

Вторая фаза — фиксация. Отдельным вызовом инструмента, с идентификатором конкретного намерения. Пока пользователь не сказал «зафиксировать», состояние снаружи не меняется.

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

Почему это оказалось лучше подтверждений

Разница неочевидна, но принципиальна. Раньше мы спрашивали: «сделать это?». Теперь мы показываем: «вот что получится». И это меняет поведение человека по ту сторону.

Во-первых, план — это документ, а не всплывашка. В нём видно, откуда взялись данные, какой пункт письма стал ИНН, к какому договору привяжется документ. Менеджер не подтверждает намерение — он проверяет черновик. А черновики люди читают гораздо внимательнее, чем модалки.

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

В-третьих, между plan и commit мы вставили автоматические проверки. Это уже не «нейросеть решила», а обычная бизнес-логика: дубли контрагентов, отрицательные суммы, ссылки на архивные договоры. Если валидатор ругается, план возвращается пользователю с пометкой — а не проваливается тихо в базу.

Что делать, когда откатить всё-таки нужно

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

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

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

Как это меняет ответ на вопрос «ИИ-агент что это»

Когда клиент спрашивает, чем разработка ИИ-агентов отличается от чат-бота, мы теперь начинаем не с моделей и не с промптов. Мы рассказываем именно про это: агент — это система, у которой есть право что-то менять во внешнем мире, и вся инженерия вокруг него про то, как это право не превратить в проблему. Свежие consumer-агенты вроде Meta Muse, которые бронируют поездки и отправляют письма без подтверждения на каждом шаге, эту разницу только подсвечивают: в B2B такую вольность себе позволить нельзя.

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

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