Как создать ИИ-агента, который закрывает письмо, а не сочиняет ответ
Письмо в общей почте, тема - "срочно". Внутри три просьбы сразу: пришлите акт, поменяйте реквизиты, объясните, почему не закрыт счёт. Менеджер открывает договор, учёт и журнал заявок и только потом видит, что две просьбы из трёх не его. С такой почты у нас обычно и начинается создание ИИ-агента. Не с выбора модели.
Это не переписка, это три задачи в одном конверте
На первой встрече спросили прямо: что такое ИИ-агент и зачем он, если ответы и так можно собирать из регламента? Пока разницы не видно, всем нужен чат, который красиво пишет.
Определение мы не читали. Положили на стол вчерашнее письмо и спросили, что сотрудник делает руками. Какие окна открывает, что копирует, куда нажимает и в какой момент относит письмо соседу.
Список вышел короткий. Найти договор. Проверить, не заводили ли уже такую просьбу. Завести заявку нужного типа. Если договор не находится или просьбы спорят друг с другом - не угадывать. Отдать человеку пакетом: что уже ясно и чего не хватает.
В рабочей системе агент - это этот цикл. Увидел, выбрал действие, посмотрел на результат, решил, нужен ли ещё шаг, остановился. Нет правила остановки - нет агента. Есть петля, которая уверена в себе дольше, чем вы готовы за ней подчищать.
Красивый ответ, пустой журнал
Первый подход собрали быстро. Длинная инструкция, куски регламента, просьба писать по делу и ничего не обещать. С текстом модель справилась. Письма выходили собранные, без канцелярита, с опорой на пункт договора, если пункт был в переписке.
Журнал не дрогнул. Акт не встал в очередь, смена реквизитов не дошла до того, кому её можно делать, вопрос по счёту не получил номера. Менеджер прочитал черновик, кивнул и пошёл копировать поля. Мы сэкономили абзац. Работу оставили на месте.
Переписка здесь витрина. Сама работа сидит в соседних системах. Пока агент туда не ходит, он пишет рассказ о разборе почты.
Второй заход: пустили в системы и пожалели
На следующей встрече попросили дать доступ. Логика понятная: раз текст умеет, пусть и делает. Поиск по договорам, создание заявки, поля свободные. Тип текстом, статус текстом, комментарий текстом.
До первого кривого письма это даже выглядело победой. Потом модель придумала статус, которого в журнале не существовало. Смену реквизитов и вопрос по счёту склеила в одну заявку: в письме они стояли в одном абзаце. Повторный прогон того же письма завёл вторую заявку. Первая показалась "неполной". Номер договора взяла из подписи, из старого приложения.
Для модели шаги были последовательны. Для людей это был мусор, который разгребать дольше, чем разобрать ящик самим.
В комнате сразу разошлись. Одни хотели дописать инструкцию и ещё жёстче запретить выдумывать статусы. Другие сказали, что модель "просто не обучена на наших заявках". Мы остановили прогон и поставили на третье: забрать свободу там, где она ничего не стоит. Статус, тип, номер договора - не место для сочинения.
Форма с клетками вместо чистого листа
Поиск договора с первого раза не сел. Он возвращал карточку целиком, и в суть заявки протекали лишние поля. Оставили три исхода и почти ничего сверх того: один договор, несколько кандидатов, ничего не найдено. На вход - номер, ИНН или кусок названия. Ответ - короткая фраза, которую можно прочитать как факт: "нашлось двое, нужен номер" или "договор не найден, не выдумывайте его".
Проверку дубля добавили после того самого повторного прогона. Ключ простой: идентификатор письма плюс тип просьбы. То же письмо можно запустить снова после сбоя, вторая заявка не появится. Это не про скорость. Это про привычку жать "ещё раз", когда неясно, доехало или нет.
Создание заявки приняло закрытый список: акт, реквизиты, вопрос по оплате, простой, прочее. Суть - пара предложений, не пересказ письма. Нет договора - нет заявки. Список живёт в схеме действия, не в абзаце инструкции. Появится "сверка" - добавим значение. Инструкцию из-за нового типа не трогаем.
Передачу человеку оформили как действие, не как признание провала. Причины короткие: несколько договоров, нет номера, просьбы противоречат друг другу, тип не узнали, кончились шаги. В пакете уже сделанное и один вопрос. Без пересказа на полстраницы.
Прямой запрос в базу не открывали. Базе всё равно, чья ошибка в условии. Ошибаться лучше внутри формы: её хотя бы видно.
Описания действий вышли длиннее всей системной инструкции. Так и должно быть. Инструкция держит только рамку: не называй сроки, не меняй реквизиты сам, не отправляй письмо наружу. Какой шаг следующий, решается в момент вызова. Фраза "используй, когда нужен договор" пустая. Нужно написать, когда не вызывать, какие поля обязательны и чем три исхода поиска отличаются для следующего шага.
Тексты отказов писали как следующую реплику, не как аварию для дежурного. "Договор не найден" ведёт к передаче, а не к новой попытке перефразировать запрос. "Заявка уже есть" останавливает, а не порождает соседнее "уточнение". "Без договора не создаём" звучит обычными словами, без кодов, которые модель потом цитирует менеджеру.
Лимит шагов поставили после того, как на длинном поводке агент "ещё чуть-чуть поискал" и затёр годное решение. Три просьбы - короткий цикл. Не сложилось - человек. Долгая возня с таким письмом почти всегда про дыру в данных, не про недостаток сообразительности.
Модель выбираем по мусору в журнале
Письма и договоры из этого ящика наружу не уходят. Это оговорили раньше, чем открыли список моделей. Вопрос, какая "самая сильная", дальше не пошёл.
Одну и ту же пачку гоняем по моделям, которые можно держать в российском контуре. Смотрим не на красоту черновика. Разделила ли модель три просьбы. Не взяла ли номер из подписи. Не уехало ли очевидное в "прочее". Остановилась ли, когда поиск вернул двоих.
GigaChat Pro и YandexGPT на одной пачке расходятся. Где-то бережнее реквизиты, где-то ровнее суть и больше путаницы в соседних типах. Следующая пачка может сдвинуть выбор, поэтому чемпиона не объявляем. В журнал пускаем ту, которая сейчас реже врёт в типе и в номере.
Если заказчику тесно даже в российском облаке, схема действий не меняется. Меняется площадка: локальная модель семейства Qwen, описания короче и жёстче. Иначе выбор шага плывёт, и форма снова становится чистым листом.
Публичные таблицы здесь почти ничем не помогают. В них нет нашей заявки и нет нашей почты. Зарубежные модели с ловким выбором действий оставляем для обзора. В рабочий контур письмо контрагента ради более удачного поля не отправляем.
Что поменялось к планёрке
Понятные письма больше не ждут, пока менеджер откроет ящик. К планёрке они уже лежат заявками: тип, договор, суть. Спорные - отдельной пачкой. Не "опять написал странно", а "вот два договора, выберите".
Раньше первая половина дня уходила на раскладку. Теперь она уходит на письма, где и человек с порога не решит. Копировать поля приходится заметно реже. Первые недели ошибки вылезали часто: узкий список типов, цепочка с новым идентификатором и тем же смыслом, исход поиска, которого не хватило. Чинили точечно, в схеме. Инструкцию по ночам не переписывали.
Спорить стали об очереди, не о характере модели. Нужен ли этот тип заявки или мы плодим лишнюю полку. Такой разговор закрывается с руководителем службы за одну встречу. После него агент становится точнее без всякого "дообучения".
Ответ контрагенту наружу не отдали. Черновик по-прежнему читает человек. Нам нужна была раскладка, не голос компании. Голос - отдельное разрешение. К нему возвращаются, когда журналу уже можно верить.
Каждый шаг пишем в PostgreSQL рядом с заявкой: какое письмо, что вернул поиск, почему ушли к человеку. Утром не спорят по памяти. Открывают запись.
Три действия руками, и только потом модель
ИИ-агенты для бизнеса часто заказывают одной фразой: пусть само разбирает почту. Почта ни при чём. Туда просто падают задачи, которые ещё никто не разложил.
Прежде чем создать ИИ-агента, мы просим назвать действия руками. Не роли и не обещание связать все системы. Конкретные действия, закрытые списки и место, где надо остановиться. Список не собирается - начинать рано. Сначала клетки, потом цикл. Модель подключаем к готовой форме, а не вместо неё.
Уберите инструменты и оставьте инструкцию. Снова появится автор писем. В ящике будут складные черновики, в журнале - тишина. Это видно к концу недели, без отдельного отчёта.
С какого вопроса теперь начинаем сами: какие три действия человек делает руками, и какое из них нельзя отдавать, даже если модель очень спокойно просит к нему доступ?
Похожие статьи
- ИИ-агент, который умеет сказать «не знаю»: как мы проектируем передачу задачи человеку при создании ИИ-агента
- Как создать ИИ-агента, когда процесс живёт в голове одного сотрудника: мы сели рядом с закупщиком
- «Нам нужен ИИ-агент», а нужен был скрипт: как мы проверяем задачу перед созданием ИИ-агента
- С чего начать создание ИИ-агента для бизнеса: как мы выбираем первый пилот
