Почему LLM-агент не заменяет RPA в 1С ERP: правильная архитектура гибридной автоматизации
Вопрос пользователя
Можно ли показать гибридную автоматизацию не в теории, а на конкретном сценарии: вход идет из Excel, писем и вложений, Claude Sonnet 4.6 выступает как LLM-агент, а Puzzle RPA создает карточки в 1С ERP?
Уточнение по названию технологии
В этой статье корректно использовать название Claude Sonnet 4.6. Именно так Anthropic называет модель. Формулировку «CloudSonnet 4.6» лучше считать разговорной или ошибочной записью названия. Для практического проектирования это важно, потому что дальше речь идет не о некой абстрактной «новой технологии», а о конкретной модели Claude, которую можно встроить в контур автоматизации как смысловой слой.
Можно ли использовать Claude Sonnet 4.6 как LLM-агента
Да, можно. Но с важной оговоркой: Claude Sonnet 4.6 — это не RPA-платформа и не оркестратор. Его правильная роль в 1С ERP и Puzzle RPA — понимать неструктурированный вход, извлекать реквизиты, выбирать маршрут, формировать структурированный JSON и объяснять, почему выбрана именно такая ветка. А уже Puzzle RPA должен брать этот JSON и выполнять детерминированные действия в интерфейсах, файлах, браузере и 1С ERP.
Почему именно такая связка практична
Ваша методология уже предполагает монолитный main, работу через resource-пути, batch/results/log/state, навешивание UI в Studio и дальнейшую оркестрацию. Поэтому Claude Sonnet 4.6 сюда встраивается естественно не как замена main, а как новый смысловой блок внутри общей схемы процесса. Иначе говоря, раньше у вас был каркас «вход → batch → UI → results/log», а теперь появляется более зрелый каркас: «вход → агентный разбор Claude Sonnet 4.6 → batch JSON → UI-исполнение в Puzzle RPA → results/log/state».
Суть проблемы
Вокруг LLM-агентов сейчас возникла типичная управленческая иллюзия. Кажется, что если модель умеет многое, то она должна заменить весь предыдущий стек автоматизации. В презентациях это выглядит красиво: агент прочитал письмо, понял задачу, открыл экран, заполнил поля, отправил письмо, закрыл цикл. Но в промышленной автоматизации 1С ERP такой подход почти всегда приводит к хаосу.
Причина простая. В реальной учетной системе важна не только способность «что-то сделать», а способность сделать это предсказуемо, повторяемо, проверяемо и управляемо. Именно здесь и проходит граница между LLM-агентом и RPA-роботом.
LLM-агент хорошо работает там, где нужно понять смысл. Он силен в разборе свободного текста, в классификации писем, в извлечении реквизитов из PDF и Excel, в определении категории обращения, в выборе подходящей ветки сценария, в формировании структурированного ответа, в объяснении своей логики. Но как только задача требует стабильного и повторяемого прохождения конкретного интерфейса, обработки тайм-аутов, фиксированного журналирования, работы по расписанию, защиты от дублей, сопровождения состояния процесса и безопасного обращения с секретами, на первый план выходит RPA.
В 1С ERP особенно опасно смешивать эти роли. Потому что здесь автоматизация почти всегда проходит не один экран, а целую цепочку: внешний контур → оперативный контур → учетный контур → контрольный контур. Если в одном месте этой цепочки допустить неформализованное поведение, процесс начинает терять управляемость.
Что на самом деле является объектом автоматизации в 1С ERP
Когда говорят «автоматизировать процесс», часто имеют в виду только экранную часть: открыть 1С, найти справочник, нажать кнопку, записать документ. Но по вашей методологии объект автоматизации шире. Это не просто последовательность кликов, а вертикальная прошивка контуров учета. То есть нужно обеспечить, чтобы хозяйственная операция, возникшая в одном месте, гарантированно доехала до другого места в правильной форме и в правильный срок.
Например, поставщик прислал письмо с новым прайсом и новыми позициями. Для бизнеса это еще не факт хозяйственной жизни в 1С ERP. Факт возникнет только тогда, когда номенклатура будет корректно зарегистрирована, обязательные реквизиты будут заполнены, дубли исключены, карточки созданы по правилам, а результаты зафиксированы. Именно здесь возникает потребность в двух слоях: смысловом и исполнительном.
Где в такой архитектуре место LLM-агента
LLM-агент нужен там, где обычное дерево условий становится слишком хрупким или слишком дорогим в сопровождении. Это прежде всего следующие зоны:
- разбор входящего письма или набора писем;
- извлечение данных из приложений, прайсов, PDF, сканов, свободных комментариев;
- нормализация названий, единиц измерения, описаний товаров;
- предварительное сопоставление новой номенклатуры с уже существующей;
- определение признаков неопределенности или конфликта;
- выбор ветки сценария: создать, проверить, эскалировать, отклонить;
- подготовка структурированного JSON, который можно отдать в исполнительный контур;
- генерация понятного объяснения для пользователя или оператора.
Иными словами, LLM-агент — это интерпретатор и маршрутизатор. Он превращает неструктурированный бизнес-вход в структурированное решение.
Где в такой архитектуре место RPA-робота
RPA нужен там, где должна работать дисциплина исполнения. В 1С ERP это чаще всего выглядит так:
- робот получает входной артефакт из папки, почты или промежуточного JSON;
- проверяет наличие файлов, каталогов и ресурсов;
- читает Excel или JSON;
- создает batch-файл на обработку;
- открывает браузер с нужным профилем;
- входит в 1С ERP по подготовленному сценарию;
- переходит в нужное рабочее место или справочник;
- вводит данные и нажимает кнопки в интерфейсе;
- дожидается конкретных элементов и статусов;
- пишет результаты по строкам в results-файл;
- пишет журнал бизнес-событий в log-файл;
- создает state-файлы после ключевых контрольных точек;
- архивирует входной файл;
- завершает процесс, уведомляет ответственных или передает инцидент.
Это уже не «интеллектуальная магия», а промышленная технология доведения процесса до результата.
Почему LLM-агент без RPA не дает промышленной надежности
Самая частая ошибка — наделить LLM-агента ролью одновременно аналитика, диспетчера, исполнителя и контролера. В такой архитектуре один и тот же агент:
- сам читает вход;
- сам решает, что делать;
- сам выполняет действия в интерфейсе;
- сам считает, что всё получилось;
- сам же формирует объяснение результата.
На демонстрации это может работать. В проекте — почти всегда нет. Почему?
Во-первых, пропадает прозрачная граница ответственности. Нельзя понять, на каком шаге произошла ошибка: при чтении входа, в логике выбора, при вводе данных в 1С, при подтверждении записи или уже на этапе формирования отчета.
Во-вторых, становится трудно поддерживать процесс. Когда в 1С ERP меняется форма, элемент интерфейса, бизнес-правило или состав обязательных реквизитов, вы не можете локально исправить участок исполнения. Вам приходится разбираться в смешанной логике, где смысловой разбор и действия по экрану переплетены.
В-третьих, резко падает управляемость исключениями. Агент может «разумно предположить», что поле подходит, что единица измерения совпадает, что найденная карточка — это и есть нужный товар. Но для учетной системы именно такие «разумные предположения» чаще всего и являются источником будущих проблем.
Правильная архитектура: агент над роботом, а не вместо робота
Практически полезная архитектура выглядит так.
На первом слое работает входной контур. Он получает письмо, Excel, PDF, CSV, скан или иной внешний артефакт. Этот слой фиксирует запуск, складывает вход в стандартную папку, присваивает идентификатор, создает служебные файлы состояния.
На втором слое работает LLM-агент. Он получает не весь хаос мира, а четко подготовленный контекст: текст письма, фрагменты вложения, реквизиты, справочные данные, правила извлечения, список обязательных полей, допустимые маршруты. Его задача — вернуть структурированный ответ, а не просто «умное мнение». То есть он должен вернуть JSON, где есть обязательные поля, уровень уверенности, признаки дубля, признаки конфликта, рекомендованная ветка и пояснение.
На третьем слое работает валидация. Это критически важный шаг, который нельзя пропускать. Даже хороший агент не должен сразу вести к созданию карточки в 1С. Между ним и учетной системой должен стоять формальный валидатор: все ли обязательные поля заполнены, совпадают ли типы данных, нет ли противоречий, не нарушены ли правила маршрутизации, нет ли красных флагов.
На четвертом слое работает RPA-робот. Он уже не думает, а исполняет. Он получает готовую структуру, открывает 1С ERP, проходит по стабильным экранным действиям, создает или обновляет объект, пишет результаты по строкам, фиксирует состояние процесса и корректно завершает запуск.
На пятом слое работает человек. Но не как постоянный ручной исполнитель, а как точка ответственной эскалации. Он подключается только тогда, когда кейс по правилам признан сомнительным: возможный дубль, противоречивые реквизиты, отсутствие обязательных данных, риск значимого управленческого решения.
Как это проектировать по вашей технологии
Если разложить это в терминах вашей технологии сборки робота, то получится следующая картина.
Сначала идет диагностика процесса. Здесь важно не просто увидеть повторяющиеся клики, а понять, где именно возникает смысловая неопределенность. Нужно задавать не только вопросы про экранные шаги, но и вопросы про тип входа, типовые исключения, контуры учета, документы, риски, адресатов уведомлений и критерии завершения.
Затем идет проектирование решения. На этом шаге уже нужно отдельно выделить:
- какие части процесса детерминированы и однозначно идут в RPA;
- какие части требуют смысловой интерпретации и идут в LLM-слой;
- какой JSON Main должен связать оба этих слоя;
- где будут контрольные точки;
- какие state-файлы и журналы должны фиксироваться;
- в каких случаях агент имеет право выбирать ветку сам, а в каких — обязан эскалировать.
Дальше формируется монолитный JSON Main. Для гибридного процесса он должен содержать не только UI-блоки и файловые операции, но и отдельные секции смысловой обработки. Типовая логика выглядит так:
INIT → подготовка resource-путей → чтение входа → нормализация → вызов агентного слоя → валидация ответа агента → формирование batch JSON → открытие 1С ERP → UI-исполнение → запись results/log → архив → завершение.
После этого навешиваются UI-привязки, собираются XPASS, выполняются тестовые прогоны, затем процесс при необходимости экспортируется в Python и передается в оркестрацию.
Типичная ошибка в проектах
Очень многие команды делают наоборот. Они сначала собирают обычного робота, а потом сверху «приклеивают» LLM как черный ящик. Получается не архитектура, а латка. Робот не знает, что именно должен вернуть агент. Агент не знает, в каком виде его ответ будет потребляться роботом. В журналировании нет сквозного идентификатора. По state-файлам нельзя восстановить ход процесса. В случае ошибки нет возможности быстро понять, сломался смысловой слой или исполнительный.
Такой подход особенно опасен в 1С ERP, потому что там любая автоматизация рано или поздно упрется в сопровождение. А сопровождать можно только то, что изначально было спроектировано как разделяемая архитектура.
Какой вариант рекомендую именно для ваших проектов
Для ваших ERP- и RPA-проектов я бы рекомендовал такую практическую формулу.
Claude Sonnet 4.6 использовать как внешний LLM-агент через API или через отдельный Python-слой.
Puzzle RPA использовать как основной контур исполнения, где уже живут main, UI, XPASS, state, batch/results/log, тест-кейсы и оркестрация.
То есть не строить архитектуру «Claude сам ходит по 1С ERP», а строить архитектуру «Claude готовит решение, Puzzle RPA исполняет решение». Для ваших задач это и технологичнее, и сопровождать проще.
Решение и рекомендации
Первое. Всегда разделяйте слой понимания и слой исполнения. Даже если технически агент может нажимать кнопки, в промышленной автоматизации это не означает, что он должен быть единственным исполнителем.
Второе. Проектируйте ответ агента как формальный контракт. Не «понял, что это новая номенклатура», а вернул JSON с полями, уровнем уверенности, флагами рисков, рекомендацией по ветке и пояснением.
Третье. Между агентом и 1С ERP обязательно ставьте слой валидации. Это защищает и от галлюцинаций, и от неоднозначных кейсов, и от тихих ошибок нормализации.
Четвертое. Используйте RPA для всего, что требует последовательного прохождения интерфейса, управления ожиданиями, журналирования, повторных запусков, архивирования и оркестрации.
Пятое. Человека не убирайте из архитектуры совсем. Его нужно убирать из рутины, но сохранять в точках ответственной эскалации.
Итог простыми словами
LLM-агент в 1С ERP — это не новый универсальный робот. Это умный слой, который понимает, что пришло на вход и что с этим делать. RPA — это слой, который доводит решение до результата в системе. Если пытаться заставить агента заменить RPA, получится красиво только на демонстрации. Если правильно развести роли, получится управляемая и масштабируемая гибридная автоматизация.
Типичный сценарий правильного использования
Поставщик прислал письмо с вложенным прайсом, где есть новые позиции. Агент разбирает письмо, извлекает наименования, артикулы, единицы измерения, признаки дублей, возвращает структурированный JSON и помечает сомнительные строки. После этого робот создает batch-файл, входит в 1С ERP, проверяет наличие элементов, создает карточки там, где разрешено, а спорные строки уводит на ручную проверку. В результате большая часть работы автоматизирована, а человек занимается только тем, что действительно требует его решения.
Типичный сценарий опасного использования
Команда решает, что агент «и так всё умеет», и дает ему полную свободу. Он сам читает письмо, сам интерпретирует вложение, сам проходит по экрану 1С, сам считает, что нужная карточка найдена, сам сохраняет документ. Пока сценарий простой, это выглядит убедительно. Но как только появляется неоднозначное совпадение, изменение формы, недозаполненный реквизит или новый тип входа, система начинает принимать неочевидные решения без управляемого контроля. Снаружи кажется, что автоматизация работает. Внутри уже накапливается будущий учетный конфликт.