В учётной системе уже есть получатель, адрес, грузовые места и выбранный способ доставки. Чтобы оформить отправление, логист снова вводит эти сведения в кабинет перевозчика. У нужного тарифа нет подходящего API, а форма периодически меняется. Агент, работающий с интерфейсом, может помочь с переносом, если заранее определить, что он оформляет и как подтверждается результат.
В Gemini 3.5 Flash предусмотрен Computer Use — работа с интерфейсами на основе визуального контекста. Ниже — предлагаемая архитектура такого помощника для одного кабинета перевозчика. Она требует разработки исполнителя действий и связи с вашей системой; готовую универсальную интеграцию для любых транспортных компаний модель не предоставляет.
Проверьте, действительно ли нужен Computer Use #
Сначала выясните, доступны ли API, импорт файла или штатный модуль обмена для нужного сценария. Эти варианты обычно дают более явный контракт: какие поля принимает система, как возвращает ошибки и где искать созданный заказ. Отсутствие одной кнопки интеграции на главной странице ещё не означает отсутствия подходящего способа обмена.
Если форма стабильна и действия однообразны, может быть достаточно обычной браузерной автоматизации. Computer Use стоит рассматривать там, где исполнитель должен распознавать состояние экрана и выбирать следующий шаг при допустимых изменениях интерфейса. При редких отправлениях ручное оформление тоже может оставаться разумным вариантом.
Google представила встроенный Computer Use в Gemini 3.5 Flash 24 июня 2026 года. Модель получает визуальный контекст и помогает выбирать действия. Открытие страницы, выполнение действий и получение следующего состояния организует приложение вокруг модели. Поддержка Computer Use сама по себе не подтверждает пригодность конкретного кабинета перевозчика.
Передавайте подтверждённый пакет отправления #
Сформируйте пакет до открытия формы: отправитель, получатель, контакт для доставки, адрес, количество мест, вес, размеры, услуга, плательщик и допустимые дополнительные опции. Для каждого значения должен быть известен источник. Модель не должна дополнять адрес по памяти или угадывать вес по названию товара.
Приведите единицы измерения к требованиям кабинета. Если источник хранит размеры в миллиметрах, а форма ждёт сантиметры, преобразование лучше выполнить обычным кодом и сохранить оба значения для сверки. Выбор упаковки перевозчика и объявленная стоимость также требуют определённого бизнес-правила.
Пакет должен иметь внутренний идентификатор и редакцию. Если состав заказа изменился во время оформления, прежнее подтверждение параметров становится неактуальным. Создавать отправление по одному набору сведений, а возвращать номер к уже изменённому заказу нельзя без явного сопоставления.
Ограничьте рабочую сессию одним кабинетом #
Исполнителю нужна отдельная браузерная сессия с доступом к разрешённому кабинету. Вход, подтверждение второго фактора и CAPTCHA должны иметь предусмотренный ручной маршрут. Нельзя считать способность читать экран разрешением обходить такие проверки.
На старте зафиксируйте допустимые страницы и действия: создать черновик, выбрать услугу, заполнить поля, открыть итоговую форму, найти результат по своему заданию. Настройка аккаунта, изменение реквизитов плательщика и оформление других отправлений не входят в этот сценарий.
Каждый переход должен возвращать наблюдаемое состояние: открыта нужная форма, поле принято, появилась ошибка адреса, выбран тариф. Если экран не соответствует ожидаемым вариантам, задание приостанавливают с причиной. Продолжение серии кликов после неизвестного предупреждения делает итог трудно проверяемым.
До отправки формы сохраните сводку фактически выбранных параметров. Она может отличаться от исходного пакета: кабинет нормализовал адрес, предложил другой пункт выдачи или добавил услугу. Показывать сотруднику нужно именно итоговые значения, включая стоимость, плательщика и дополнительные условия.
Подтверждение относится к этой сводке и её версии. Если после него поменялся тариф или одно грузовое место, требуется новое решение по изменившимся параметрам. Это правило приложения, которое исполняет действия; одной фразы в инструкции модели недостаточно.
В анонсе Google описаны механизмы подтверждения чувствительных действий и остановки при подозрении на косвенную подмену инструкций. Для логистического процесса дополнительно нужны собственные границы: какие условия допустимы автоматически и где сотрудник принимает конкретное решение.
После команды оформления интерфейс должен дать подтверждение результата: номер заказа или другое устойчивое обозначение перевозчика. Исчезновение кнопки и переход на следующую страницу ещё не доказывают, что отправление создано с нужными сведениями.
Что делать после зависания страницы #
Предположим, кнопка оформления нажата, но ответ не появился. Немедленно нажимать ещё раз опасно: первый запрос мог завершиться. В задании нужен отдельный статус «результат выясняется», при котором новая попытка оформления заблокирована.
Проверьте список заказов и доступные способы поиска по собственной ссылке или признакам отправления. Совпадение только адреса и даты может быть недостаточным: в один день клиенту могут идти несколько грузов. При неоднозначности передайте найденные варианты сотруднику.
Если кабинет не позволяет надёжно установить исход операции, такой участок нельзя объявлять полностью автономным. Помощник может подготовить форму и передать финальное оформление логисту. Это полезная граница пилота: она сохраняет автоматизацию переноса данных без обещания решения того, что интерфейс не позволяет проверить.
Верните результат в исходную систему #
После подтверждения сохраните номер заказа перевозчика, выбранную услугу, итоговые параметры, дату оформления и ссылку на задание. Отдельно укажите, где номер относится к заказу, а где — к конкретному грузовому месту. Эти сущности у разных перевозчиков могут различаться.
Сверка после оформления должна показать, что получатель, адрес и состав груза соответствуют подтверждённой сводке. Если перевозчик изменил данные или вернул предупреждение, задача остаётся на разборе. Не стоит отмечать весь исходный заказ как отправленный только потому, что создана транспортная заявка.
Скриншоты и журнал действий помогают восстановить ход оформления. Сохраняйте необходимые участки и ограничивайте доступ к ним: на экране могут находиться сведения о получателе. Срок хранения выбирается под процесс разбирательства, а не по принципу «записывать всё навсегда».
Как принимать первый маршрут #
Испытайте на разрешённом тестовом или согласованном рабочем сценарии обычное отправление, уточнение адреса, смену тарифа, истёкший вход и потерю ответа после оформления. Для каждого случая нужен ожидаемый исход и понятный способ продолжения.
Сравнивайте время сотрудника на принятый результат, ошибки переноса полей, повторные заказы и долю заданий, остановленных по делу. Скорость отдельных кликов не показывает полезность процесса. Если кабинет регулярно меняет структуру и требует сложных ручных решений, расходы на сопровождение должны входить в оценку варианта с Computer Use.
NetLabCS поможет связать источник отправлений и кабинет перевозчика в проекте автоматизации бизнес-процессов вашей компании. Для обсуждения маршрута подготовьте состав полей, доступные способы обмена и пример обычного оформления без учётных данных: проверим альтернативы, границу подтверждения и способ возвращать результат в вашу систему.
