Главное
- Интерфейс автоматизации локален: он находится на собственной машине оператора, а не является размещённой конечной точкой, к которой уходит запрос.
- Два вида доступа решают разные задачи: CDP — для прямой проверки и управления браузером, REST — для операций с профилем и его жизненным циклом.
- Единица изоляции — профиль, а не браузер: один агент, один профиль, собственное состояние браузера и собственное сетевое назначение.
- Локальность делает границу соединения явной. Сама по себе она не авторизует инструмент, не защищает его код и не гарантирует, что конечная точка существует в каждом выпуске.
- Доступно ровно то, что задокументировано для установленной версии, — ничего сверх этого.
Что на самом деле представляет собой интерфейс автоматизации
Когда люди слышат «API автоматизации», они часто представляют облачный сервис, который скрипт вызывает через интернет. Это не то, о чём идёт речь здесь. Agilelogin предоставляет автоматизацию браузера локально: программное управление браузером или профилем через интерфейс на собственном устройстве оператора, а не удалённую конечную точку. Ничто в этом соединении не проходит через сторонний сервер — инструмент и браузер работают на одной и той же машине.
У этой локальной поверхности есть два задокументированных вида. Доступ к Chrome DevTools Protocol (CDP) может поддерживать прямую проверку и взаимодействие с браузером, когда установленное ядро его предоставляет — этот уровень нужен, когда рабочему процессу действительно требуется управление на уровне браузера: наблюдать за страницей или управлять ею так, как это делал бы человек-оператор. Наряду с этим задокументированные REST-эндпоинты могут предоставлять операции с профилем и его жизненным циклом, выбранные для конкретного выпуска, не требуя полного управления на уровне браузера для каждой задачи. На практике эти два способа решают разные задачи: CDP — для прямой проверки и управления браузером, REST — для прикладных операций, которые продукт решил поддерживать. Агенту, которому нужно только запустить профиль или проверить его состояние, не нужна тяжеловесная полноценная сессия CDP; рабочему процессу, которому нужно прочитать, что реально отображается на странице, — нужна.
В обоих случаях ключевое слово — задокументированный. Локальность делает границу соединения явной — агент обращается к собственной машине, а не к размещённому где-то API, которому приходится слепо доверять, — но сама по себе она не авторизует инструмент, не защищает его код и не гарантирует, что данная конечная точка существует в каждом выпуске. Что предоставлено — это ровно то, что задокументировано для установленной версии, ни больше и ни меньше.
Почему единицей измерения служит профиль, а не браузер
Границей, в терминах которой должен рассуждать агент, служит не браузер, а профиль. Изолированный браузерный профиль для AI-агента — это постоянный локальный контекст браузера, назначенный одному одобренному автоматизированному процессу: его состояние браузера и сетевое назначение остаются узнаваемо принадлежащими этому профилю, а сам процесс обращается к нему через описанный выше локальный интерфейс CDP или REST. Профиль создаёт границу управления; сам по себе он не даёт агенту прав сверх тех учётных записей и систем, которые оператор уже авторизовал.
Именно эта граница не даёт работе одного агента просочиться в сессию чужой учётной записи. Куки, хранилище и сетевые допущения остаются привязанными к конкретному профилю, поэтому когда повторяющемуся процессу требуется разрешённое состояние сессии, выделение ему отдельного профиля делает принадлежность состояния и сетевые допущения намного проще проверять, чем если бы несколько процессов использовали общий браузер. Отсюда простое практическое правило: выделяйте процессу собственный узнаваемый профиль, а не переиспользуйте чужую сессию человека или агента. Разрешённый процесс может обращаться именно к этому выделенному профилю, что делает понятнее, какой процесс владеет текущим состоянием браузера и когда это владение заканчивается.
Использовать один профиль на нескольких агентов обычно неверно по умолчанию. Когда агенты работают параллельно или им нужно раздельное состояние, один профиль на каждый одобренный процесс делает куки, хранилище, сетевые допущения и ответственность за сбои гораздо проще анализировать, чем общая сессия. Если двум агентам действительно нужно делить один профиль, это должно быть осознанное, проверенное решение, а не то, что происходит просто потому, что никто не создал второй профиль.
Чего не даёт локальный интерфейс
Соблазнительно считать «локальное» синонимом «безопасного», но это неверное прочтение. Локальный доступ — это граница, а не решение о доверии. То, что интерфейс находится на той же машине, что и агент, говорит лишь о том, где заканчивается соединение; это ничего не говорит о том, стоит ли доверять коду, который его вызывает, и Agilelogin не расширяет полномочия агента сверх того, что уже предоставил оператор. Подключённый агент или скрипт получает только те полномочия, которые дал ему оператор.
Отсюда напрямую следуют две дисциплины. Первая — ограничивать доступ на уровне устройства и сети: проверяйте поддержку версии для интерфейса и ограничивайте, кто и что может обращаться к нему локально, вместо того чтобы оставлять управляющую поверхность доступной для всего, что запущено на устройстве. Ограничение того, кто может запускать программы на устройстве, проверка подключаемых инструментов и защита секретов — это задача оператора, а не то, что происходит автоматически из-за наличия локальной конечной точки. Вторая — использовать только одобренные, задокументированные инструменты: проверяйте код агента, его права, промпты, работу с секретами и путь обновления так же, как вы бы проверяли любое другое ПО с доступом к учётным записям, поскольку учётные данные, промпты, журналы, зависимости и поведение целевого сайта — отдельные риски, которые локальная граница не закрывает.
Третья дисциплина — сверять поведение с фактически установленным выпуском. Сейчас нет опубликованного заявления о готовности интерфейса автоматизации к промышленной эксплуатации. Самое безопасное предположение — считать интерфейсы специфичными для каждого выпуска, пока не появится версионированная документация с поведением аутентификации, ошибками и деталями совместимости для той версии, которую вы используете, — проверяйте это, прежде чем строить процесс, зависящий от существования конкретной конечной точки.
Где это находится сейчас
Ничто из описанного не относится к продукту, который уже можно скачать. У десктопного приложения ещё не было первого публичного выпуска, поэтому устанавливать пока нечего, и ничто в этом тексте не следует читать как утверждение обратного. Задокументирована форма локальных поверхностей CDP и REST, через которые одобренный инструмент будет подключаться после выхода выпуска, и границы вокруг них: профиль как единица изоляции, локальная машина как граница доверия и оператор как источник любых полномочий, которые есть у агента.
Это также значит, что детали — какие конечные точки существуют, что они принимают, как сообщаются ошибки — пока не зафиксированы, и сейчас нет опубликованного заявления о готовности интерфейса автоматизации к промышленной эксплуатации. Воспринимайте написанное здесь и в документации по функциям, на которую оно опирается, как направление, в котором строится интерфейс, а не как застывший эталон. Когда выпуск действительно выйдет, первый шаг для любого, кто подключает к нему агента, будет тем же, что описан выше: проверить версию, прочитать то, что реально задокументировано для этой сборки, и дать агенту не больше полномочий, чем требует процесс.