Вопрос пользователя: У нас уже есть методология сборки RPA-робота: диагностика, вопросник, проектирование решения, JSON Main, навешивание UI, тесты, упаковка и оркестрация. Как туда правильно встроить LLM-агента, не разрушив саму технологию?
Суть проблемы
Почти все неудачные гибридные проекты страдают одной и той же болезнью. Агент появляется слишком поздно. Сначала команда проектирует обычного робота, описывает экранные шаги, собирает монолит, а уже потом вспоминает, что где-то в середине процесса всё-таки нужен смысловой слой. Тогда агент добавляется как внешний «умный помощник», который плохо вписан в основной контур.
В результате в проектировании решения нет формальной границы полномочий агента, нет контракта на его вход и выход, нет требований к журналированию, нет правил валидации ответа, нет критериев эскалации, нет места для state-файлов после смысловых шагов. Такой агент не встроен в технологию — он просто болтается рядом.
Базовый принцип встраивания
LLM-агент должен проектироваться не после робота, а внутри той же технологической схемы, по которой собирается весь процесс. То есть для него должны быть заранее определены:
- цель смысловой операции;
- входной контекст;
- допустимые типы решений;
- формат ответа;
- критерии уверенности;
- признаки обязательной эскалации;
- журналирование;
- место в JSON Main;
- правила передачи данных в исполнительный контур.
Тогда агент становится не «магией внутри проекта», а полноправной частью архитектуры.
Как меняется этап диагностики
На этапе диагностики теперь недостаточно спросить пользователя только про кнопки, формы и документы. Нужно отдельно выявить зоны смысловой работы.
Для этого в диагностике появляются дополнительные блоки вопросов.
Блок 1. Смысловые операции. Что именно сегодня человек понимает вручную? Он распознает тип письма? Сопоставляет свободное описание товара с внутренней номенклатурой? Определяет, является ли строка новой позицией или дублем? Оценивает, хватает ли данных для регистрации?
Блок 2. Источники контекста. Из чего агент должен делать выводы? Из письма, из приложенного прайса, из таблицы Excel, из PDF, из карточек существующей номенклатуры, из справочника единиц измерения, из истории предыдущих запусков?
Блок 3. Результат смысловой операции. Что именно должен вернуть агент? Просто ответ «да/нет» почти всегда недостаточен. В реальном процессе нужен набор структурированных полей: извлеченные значения, признаки риска, вероятный дубль, маршрут, уровень уверенности, пояснение.
Блок 4. Границы полномочий. В каких случаях агент имеет право выбрать ветку сам? В каких случаях обязан отправить кейс оператору? В каких случаях должен вернуть отказ от решения?
Как меняется вопросник
Вопросник для гибридного процесса должен содержать не только классические поля вроде триггера, ключевого события, критериев завершения, тайм-аутов, коммуникаций и артефактов, но и отдельный раздел по агентному слою.
В нем должны быть как минимум такие позиции:
- какой тип неструктурированного входа поступает в процесс;
- какие обязательные реквизиты агент должен извлечь;
- какие справочники и списки допустимых значений используются как контекст;
- какие признаки считаются красными флагами;
- какие поля должны быть заполнены безусловно;
- как обозначается уровень уверенности;
- какие типы ответа допустимы: success, clarification, escalation, reject;
- кто является адресатом ручной эскалации;
- как связать идентификатор запуска агента с идентификатором запуска робота.
Как меняется проектирование решения
На этапе проектирования решения теперь появляется отдельная таблица распределения ролей. Для каждого шага должно быть понятно:
- это делает LLM-агент;
- это делает RPA-робот;
- это делает человек;
- это делает система 1С ERP;
- это делает оркестратор.
Это важно не для красоты. Именно так строится управляемость процесса. Когда потом возникает вопрос «кто отвечает за эту точку», ответ уже есть в архитектуре.
Также в проектировании решения должна быть отдельная секция агентного контура.
В ней фиксируются:
- входные артефакты;
- способ подготовки контекста;
- промпт-контракт;
- формат выходного JSON;
- признаки валидного ответа;
- правила повторного вызова;
- правила отклонения ответа;
- правила журналирования;
- критерии эскалации.
Как меняется JSON Main
Вот здесь начинается самая важная инженерная часть. В монолитном JSON Main агентный слой не должен быть размазан по процессу. Он должен жить в отдельной логической секции, которая стоит до UI-исполнения, но после подготовки входа.
Для гибридного сценария типовая последовательность выглядит так:
INIT → инициализация относительных resource-путей → проверка папок → чтение входных файлов → нормализация и первичная валидация → вызов агентного блока → проверка структуры ответа → формирование batch JSON → архивирование входа → открытие 1С ERP → проход по UI → запись results → запись log → запись state → завершение.
Если процесс сложнее, то агентный слой может быть повторно вызван и внутри цикла по строкам, но даже в этом случае он должен оставаться отдельным блоком с собственным контрактом и журналом.
Почему нужен формальный ответ агента, а не просто текст
Если агент вернет свободный текст вроде «похоже, это новая номенклатура, можно создать», такой ответ бесполезен для промышленной автоматизации. Робот не должен интерпретировать художественный текст.
Правильный ответ агента должен быть структурирован. Например:
- исходное наименование;
- нормализованное наименование;
- артикул;
- единица измерения;
- группа номенклатуры;
- производитель;
- признаки дубля;
- список кандидатов на совпадение;
- уровень уверенности;
- рекомендуемая ветка;
- пояснение;
- список отсутствующих полей.
Тогда этот ответ можно валидировать обычными средствами, логировать, сохранять, тестировать и использовать в повторных запусках.
Как меняется контроль качества
Без отдельного контура контроля качества LLM-слой очень быстро превращается в источник «умных ошибок». Поэтому в технологию нужно добавить как минимум три уровня контроля.
Первый уровень — формальная валидация. Проверяется, что агент вообще вернул корректную структуру, а не поломанный ответ.
Второй уровень — бизнес-валидация. Проверяется, что заполнены обязательные поля, допустимы значения, не нарушены справочные ограничения, не обнаружены конфликтные признаки.
Третий уровень — выборочный контроль человеком. Особенно на пилоте нужна периодическая проверка части кейсов даже там, где агент уверен в ответе. Это нужно не для недоверия, а для настройки архитектуры и границ полномочий.
Как меняется разрезание монолита на процессы
После стабилизации монолитного main его обычно хочется разрезать на более управляемые процессы. В гибридной архитектуре это особенно полезно.
Очень удобная схема такая:
- процесс 1: прием входа и подготовка артефактов;
- процесс 2: агентный разбор и формирование batch;
- процесс 3: UI-исполнение в 1С ERP;
- процесс 4: завершение, отчеты, уведомления, архив.
Тогда смысловой слой и исполнительный слой разделяются не только логически, но и процессно. Это облегчает сопровождение, тестирование и повторные запуски.
Решение и рекомендации
Первое. Встраивайте агент в технологию с самого начала, а не после сборки робота.
Второе. Добавьте в вопросник отдельный блок по смысловым операциям, источникам контекста, формату ответа и границам полномочий.
Третье. Проектируйте ответ агента как строгий контракт, пригодный для JSON Main и валидации.
Четвертое. В JSON Main агентный слой должен быть отдельной секцией, а не набором случайных вставок.
Пятое. После пилота по возможности разделяйте смысловой и исполнительный контур по разным процессам.
Итог простыми словами
Если агент не вошел в диагностику, вопросник, проектирование решения, JSON Main, журналирование и контрольные точки, значит он не встроен в технологию. А если он не встроен в технологию, то он станет не усилением RPA, а новым источником хаоса.
Типичный сценарий правильного использования
Команда еще на этапе проектирования фиксирует, что в сценарии регистрации новой номенклатуры есть отдельная смысловая операция: извлечение и нормализация реквизитов из прайса поставщика. Для нее создается отдельный контракт, отдельная секция в JSON Main и отдельный валидатор. В результате и агент, и робот работают каждый в своей роли.
Типичный сценарий опасного использования
Агент добавлен в последний момент. Его просто вызывают «где-то в середине» процесса и просят вернуть «что-нибудь полезное». Ответ невозможно стабильно распарсить, правила эскалации не описаны, журналирование отсутствует, а ошибки выясняются уже после того, как робот что-то создал в 1С ERP. Это уже не технология, а импровизация.