ИИ агент для компьютера помогает повторять действия в рабочих приложениях: считывает состояние экрана, предлагает план и выполняет разрешённые клики под контролем человека. Такой сценарий подходит для устойчивой последовательности с понятными точками остановки; при смене интерфейса оператор снова проверяет маршрут.
Экранный маршрут
Рабочий пилот охватывает один повторяемый экранный сценарий и включает журнал каждого действия.
Агент получает снимок окна, распознаёт доступные поля и кнопки, сопоставляет их с задачей, а затем предлагает следующий шаг. Для начала годится перенос сведений из утверждённой заявки в черновик карточки Битрикс24. Оператор заранее задаёт разрешённые поля и проверяет результат перед сохранением. Такой маршрут легче оценить, чем просьбу «работай за меня в любых программах»: здесь известны исходный документ, целевой экран и признак готовности.
Разница с управлением браузером через Playwright MCP в области действий. Браузерный сценарий работает со страницей и её элементами; экранный сценарий может затронуть несколько настольных окон, где распознавание кнопки зависит от видимой картинки. Наличие рабочего чата само по себе недостаточно для управления экраном. Для экранных действий нужны отдельные разрешения, исполнительный слой и журнал.
Выбирайте действие с малой ценой ошибки: заполнение черновика, перенос метки, сбор данных с экрана. Рассылка, платёж и удаление требуют явного согласия человека. На старте зафиксируйте масштаб окна, язык интерфейса и тестовую учётную запись: даже мелкая перемена подписи кнопки меняет маршрут.
Перед запуском запишите состояние экрана, при котором задача считается завершённой. Для карточки это заполненные поля и статус черновика. Агенту нужен также явный признак остановки: пустое обязательное поле, неизвестный диалог или расхождение суммы. Без этих признаков журнал покажет клики без подтверждения результата.
Разрешения и остановки
| Ситуация | Действие агента | Роль человека |
|---|---|---|
| Поле заявки | Предлагает значение и источник | Сверяет смысл с исходной заявкой |
| Кнопка сохранения | Показывает ожидаемое изменение | Разрешает сохранение черновика |
| Отправка клиенту | Останавливается | Читает и отправляет сам |
| Удаление записи | Останавливается и пишет причину | Принимает отдельное решение |
Права агенту выдаются под конкретный маршрут. Если нужна карточка Битрикс24, тестовая учётная запись получает доступ только к нужному разделу. Разрешение на массовые операции добавлять незачем. При работе с 1С особенно важно отделить просмотр от проведения документа: одинаковый на вид экран может вести к разным последствиям для учёта.
Проверка состояния происходит после каждого значимого клика. Агент сравнивает видимый экран с ожидаемым: открылась карточка, появилось значение, возникло сообщение об ошибке. При расхождении он сохраняет снимок и прекращает цепочку. Повторять клик вслепую опасно: задержка загрузки способна превратить один ввод в два. Сведения из экрана трактуйте как данные, без принятия их за новые инструкции; текст в карточке может содержать команду, которую выполнять нельзя.
В сценариях агента для 1С важен учётный контекст. Здесь фокус иной: видимый экран, точка подтверждения и право остановить маршрут. Такое разграничение полезно при выборе между экранным действием и штатной интеграцией через API.
Для каждого разрешения укажите владельца. Администратор выдаёт права тестовой учётной записи, руководитель процесса определяет допустимые операции, оператор принимает содержимое карточки. Если один человек одновременно пишет маршрут и утверждает все результаты, ошибку труднее заметить при проверке пилота.
Пилот на карточке
- Подготовьте пять обезличенных заявок с разными формулировками имени, даты и суммы; создайте пустые тестовые карточки.
- Опишите допустимые поля и названия экранов. Для каждого поля укажите источник в заявке и формат значения.
- Запустите маршрут в тестовой учётной записи. Агент показывает план, делает снимок перед действием и записывает результат после него.
- Сверьте заполненные карточки с заявками. Отдельно отметьте пропуски, неверные поля и случаи остановки.
- Измените один элемент интерфейса в тесте и проверьте, что агент остановится при расхождении, до продолжения кликов.
Условный пример: в заявке указан срок «до пятницы», а в карточке требуется календарная дата. Агент может предложить уточнение, но выбирать дату по догадке нельзя. Оператор запрашивает исходное уточнение, после чего возобновляет заполнение. В журнале остаются исходная формулировка, предложенный вариант и решение оператора. Именно такой след помогает понять, где появилась ошибка.
Метрика пилота — доля карточек, где все разрешённые поля совпали с источником и каждая опасная операция остановилась перед подтверждением. Разделяйте ошибки по типам и причинам. Если неверно распознаётся поле даты, исправляйте правило чтения этого поля; замена всей модели может оказаться лишней. Для маршрутов с несколькими системами опишите также, в каком окне возник сбой.
Если ваши сотрудники уже вручную переносят заявки между окнами, такой пилот даст конкретную карту разрешений и ошибок.
Какой экранный маршрут хотите проверить в тестовом контуре?
Журнал исполнения
Журнал нужен для воспроизводимости и последующего разбора ошибок. На каждое действие записывайте задачу, исходный снимок, выбранный элемент, введённое значение, экран после действия и имя оператора, который подтвердил результат. Секреты и персональные данные в журнале скрывайте или заменяйте ссылкой на защищённую запись. Иначе инструмент контроля сам станет лишним хранилищем чувствительной информации.
Предусмотрите три исхода: шаг выполнен, шаг требует человека, маршрут завершён из-за расхождения. При ошибке полезнее указать наблюдаемое событие, например «поле суммы отсутствует на экране», чем общий вердикт модели. По такому событию разработчик исправит селектор, инструкцию или права. Оператор поймёт, какой документ открыть и где продолжить работу. Повторный запуск начинайте с проверенного состояния, во избежание случайного дубля.
Для маршрута по нескольким окнам снимите отдельный чек-лист переходов: откуда открыт файл, какое окно активно, какой текст виден в целевой карточке. Смена активного окна часто объясняет ввод в чужое поле. Практика из агента для закупок показывает другой тип границы: согласование решения. В экранном пилоте граница расположена ещё и между каждой парой действий интерфейса.
Возьмите маршрут заполнения черновика и заранее выпишите экраны, где оператор обязан нажать подтверждение.
Храните снимки только там, где команда уже защищает рабочие данные. Перед передачей журнала разработчику замените имя клиента и другие идентификаторы нейтральными метками. При разборе сбоя достаточно видеть расположение поля, ожидаемое значение и сообщение интерфейса.
Когда расширять
К расширению переходите после разбора ошибок на одной задаче. Сначала добавьте новый тип заявки при прежнем интерфейсе, затем новый экран при прежнем типе данных. Одновременная смена обоих условий скрывает причину сбоя. Сотруднику нужна короткая инструкция: как запустить маршрут, как увидеть паузу, где прочитать журнал и как вернуть задачу в ручную работу.
Если приложение предоставляет устойчивый API, сравните его с экранным способом. API обычно даёт поля и статусы напрямую; экранный агент полезен там, где штатной интеграции нет либо человек всё равно принимает решение в интерфейсе. Для связки нескольких систем можно изучить внедрение ИИ-агентов с контролем действий. Описание задачи начните с разрешённых операций, списка запретов и образца журнала, а выбор модели оставьте после фиксации маршрута.
Успешный результат выглядит буднично: оператор видит предложенное действие, источник значения и понятную кнопку подтверждения. При непонятном экране он получает задачу на ручную проверку. Такой подход помогает использовать компьютер как рабочий инструмент агента, сохраняя ответственность за итоговое действие у человека.
Условия расширения лучше записать до пилота. Например, новая категория заявок добавляется после проверки набора полей и успешной остановки на неизвестном экране. Тогда решение об охвате следующей операции опирается на журнал, вместо впечатления от одной удачной демонстрации.
Назначьте владельца инструкции, который обновляет маршрут после изменений интерфейса и повторяет контрольный прогон.