Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Проверка компьютерных агентов в ERP показала: удачная навигация и сохранение формы не означают, что в учётной системе остались верные данные. В препринте ERPBench, который не прошёл рецензирование и опирается на замеры самих авторов, агент сохранял форму в 85% запусков, но записывал правильные данные лишь в 3%. Для внедрения таких агентов недостаточно оценивать скриншоты и последовательность действий — результат нужно сверять с базой.
Почему сохранённая форма ещё не означает выполненную задачу
Обычный тест компьютерного агента проверяет, открыл ли он нужный экран, нажал ли правильную кнопку и получил ли сообщение об успехе. В ERP этого мало: интерфейс может принять действие, хотя введённое значение не связалось с полем, не сохранилось или заменило другие данные.
Такой сбой опаснее заметной ошибки. Агент завершает задачу без предупреждения, а неверная запись остаётся в системе и влияет на закупки, склад, финансы или работу с клиентами. По журналу действий запуск выглядит успешным, хотя фактическое состояние бизнеса изменилось не так, как требовалось.
ERPBench проверяет это на локально развёрнутой ERPNext. Агент видит только скриншоты и управляет мышью и клавиатурой по координатам: дерево доступности, структура страницы и API ему недоступны. После завершения задачи отдельный модуль читает целевые поля через API и сравнивает их с ожидаемыми значениями.
Границы проверки заданы достаточно узко: в набор вошли 30 задач, каждую запускали пять раз на шести закрытых моделях и моделях с открытыми весами. Задачи охватывают изменение одного поля, создание записи с несколькими полями и цепочки связанных документов на разных экранах ERPNext. Это тест надёжности в конкретной ERP, а не общая оценка способности агента работать с любым корпоративным программным обеспечением.
Как проверка по базе показывает место сбоя
ERPBench делит выполнение на последовательные этапы: переход к нужной записи, работа с элементами формы, сохранение и проверка базы. Итоговый успех засчитывают только тогда, когда все целевые поля содержат ожидаемые значения. Для составных записей и цепочек документов бенчмарк также даёт частичный результат, чтобы показать, где именно остановился агент.
Это разделяет внешне похожие ошибки. Агент может не найти запись, выбрать не тот элемент, правильно ввести значение, но не сохранить его, либо нажать сохранение и оставить в базе неверные данные. Последние два случая особенно трудно обнаружить по скриншоту: интерфейс уже вернулся в устойчивое состояние и не обязательно показывает проблему.
Среда запуска устроена так же, как предлагаемый авторами контур внедрения. Агент сначала предлагает действие и присваивает ему уровень риска, а система передаёт его на одобрение. Безопасные действия можно пропускать автоматически, тогда как сохранение, отправка документа и необратимые операции требуют явного подтверждения человека.
Во время тестов человека заменяет автоматическое одобрение, поэтому модели проходят задачи без помощи оператора. Такое разделение важно для воспроизводимости: один и тот же исполнительный контур можно использовать сначала для автономных замеров, а затем для работы с ручным шлюзом перед рискованными действиями.
Что ERPBench меняет в планах внедрения
Claude выполнил 94% простых задач и все составные цепочки. Лучшие модели с открытыми весами достигли 34% на простых операциях и не превысили 3% на самых сложных. Значит, переносить результаты общих GUI-бенчмарков на бухгалтерские, складские и закупочные процессы пока нельзя.
Высокий результат Claude тоже не превращает задачу в обычную интеграцию. На длинной цепочке модель расходовала около 2 млн входных токенов за запуск. Команде придётся проверять не только успешность, но и задержку, стоимость и то, насколько стабильно агент проходит собственные формы, справочники и правила доступа.
Практический план должен разделять два контроля. Шлюз перед действием ограничивает риск: человек может остановить удаление, отправку или сохранение. Проверка после действия отвечает за корректность: система читает изменённые поля и подтверждает, что агент действительно выполнил поручение. Ручное одобрение клика не заменяет такую проверку, потому что оператор тоже видит интерфейс, а не итоговую запись в базе.
Для пилота разумнее выбрать операции с однозначным ожидаемым состоянием и доступной автоматической сверкой. Общий GUI-бенчмарк можно оставить предварительным фильтром моделей, но решение о запуске должно опираться на задачи из собственного процесса. Если постусловие нельзя проверить программно, агенту не стоит самостоятельно фиксировать изменение в ERP.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
