OpenClaw nodes — это подключение удалённого узла к Gateway через допуск устройства и отдельное согласование доступных команд. Для рабочего сценария дополнительно нужны политика Gateway, локальные разрешения на выполнение и права самой операционной системы. Сопряжение открывает путь к соединению; право запуска требует последующих согласований. Такая схема нужна команде, которая хочет дать агенту ограниченное действие на конкретном устройстве и сохранить проверяемый маршрут от запроса до отзыва.
Граница узла
У OpenClaw узел проходит два допуска: устройство получает право соединиться с Gateway, затем оператор согласует объявленную поверхность команд. Выполнение ограничивают дополнительные правила.
Удалённый node host выполняет команды на своём устройстве. Gateway принимает подключение и решает, какие объявленные возможности попадут в рабочую поверхность. В официальном описании сопряжения эти решения разделены: device pairing допускает соединение, а node capability approval управляет объявленными возможностями и командами. При расширении поверхности Gateway создаёт запрос на новое согласование. До его разрешения новые команды остаются закрытыми.
Для проекта сначала назовите устройство, владельца и допустимую задачу. Пример будущего пилота: агент получает возможность прочитать техническое состояние тестового компьютера после явного допуска. Запись в реестре должна связывать физическое устройство, рабочую роль и ответственное лицо. Для действий с файлами или оболочкой потребуется отдельный перечень разрешённых операций. Языковая модель может предложить описание задачи, а администратор проверяет границы действия по фактической конфигурации.
Путь запроса к Gateway относится к входу клиента и каналов. Здесь фокус на удалённом исполнителе: что именно способен открыть уже подключённый узел. Права нескольких агентов внутри одного Gateway тоже решают другую задачу. Важно проследить цепочку до конкретной команды и устройства. Общие принципы ограничений раскрывает разбор прав ИИ-агентов; для nodes их применяют к поверхности команд и локальной машине.
Два согласования
Подготовьте отдельные записи для допуска устройства и для согласования команд. При ручном маршруте администратор просматривает запрос устройства, сверяет его назначение и решает вопрос о подключении. После соединения узел объявляет доступные команды; оператор рассматривает новый запрос на поверхность. Идентификаторы этих запросов различаются, поэтому решение по устройству нельзя подставлять в форму согласования возможностей.
- Опишите тестовое устройство, допустимого оператора и единственную проверяемую задачу. Уберите из сценария реальные рабочие файлы и чувствительные данные.
- Сверьте запрос допуска устройства в Gateway и подтвердите только известный node host. Сохраните запись о решении и о лице, которое его приняло.
- Просмотрите объявленную поверхность через список ожидающих узлов. Сопоставьте весь набор команд с задачей, затем согласуйте поверхность либо отклоните запрос и сузьте перечень на узле.
- Проверьте статус узла и выполните разрешённое контрольное действие после отдельной проверки локальных ограничений. Зафиксируйте результат и путь отказа.
Документация показывает для ручной проверки команды `openclaw devices list`, `openclaw nodes pending` и `openclaw nodes status`. Они помогают развести два решения и проверить итоговое состояние. Сценарий с установочным кодом имеет особенность: код администратора может сразу одобрить устройство вместе с первой объявленной поверхностью. Поэтому перед его применением проверьте локальные правила исполнения и состав объявленных команд. Позднее расширение возможностей всё равно требует отдельного рассмотрения.
Заявка на поверхность может сохраняться после разрыва связи с узлом. Проверка только текущего соединения поэтому оставит незамеченное ожидающее решение. Назначьте владельца очереди согласований и сверяйте основания запросов после обновления node host. Для учётной записи оператора задайте минимальные полномочия, соответствующие нужному типу команды.
Команда и ОС
Одобрение поверхности открывает лишь объявленные возможности в пределах политики Gateway. Согласно официальной политике команд, команда должна присутствовать в метаданных подключённого узла, входить в утверждённую поверхность и проходить список допустимых команд Gateway. После этого для локального исполнения продолжают действовать разрешения node host и права операционной системы. Получается последовательность самостоятельных фильтров доступа.
| Контроль | Что проверять | Признак отказа |
|---|---|---|
| Устройство | Одобренная роль узла | Соединение ожидает решения |
| Поверхность | Объявленная команда согласована | Команда скрыта до одобрения |
| Политика Gateway | Команда проходит правила допуска | Вызов блокируется политикой |
| Локальная машина | Разрешение исполнения и права ОС | Операция отклонена на устройстве |
Для системных команд отдельно настройте локальные согласования. Документация по запуску команд на узле описывает список разрешённых исполняемых файлов для конкретного node host. Если рабочая задача требует только просмотра состояния, оставьте команды изменения за пределами утверждённой поверхности. Разрешение на работу с экраном, камерой или файлами требует проверки возможностей устройства и прав ОС; наличие имени команды в Gateway само по себе оставляет доступ закрытым.
Перед передачей команды человеку полезно видеть устройство назначения, действие и ожидаемые данные на выходе. Серверная политика проверяет право запроса и утверждённую поверхность, локальный механизм проверяет допустимость исполнения. Для чувствительного действия владелец процесса добавляет отдельное подтверждение сотрудника. Текст промпта может напомнить о таком шаге, но действительный допуск обеспечивает система.
Какие команды вашему узлу можно разрешить для пилота?
Отказ и отзыв
Контрольный отказ нужен до расширения доступа. В проектном тесте подключите разрешённый узел, оставьте выбранную команду вне одобренной поверхности и проверьте, что агент получает отказ без выполнения действия на устройстве. Затем проверьте сценарий с одобренной поверхностью, где команду блокирует политика Gateway. Отдельно испытайте локальное ограничение node host. Запишите слой отказа, запрос и ответственное лицо, сохранив секреты вне журнала.
Такой порядок показывает, где именно возникла граница. Ошибка сопряжения устройства, отсутствие согласования команды и отказ операционной системы требуют разных действий администратора. Языковая модель может сгруппировать сообщения и предложить гипотезы причины. Факты берут из журнала и конфигурации, а доступ меняет уполномоченный сотрудник после сверки. Массовую выгрузку событий разбирает парсер или скрипт, поскольку полный набор записей требует воспроизводимой обработки.
Отзыв планируйте как часть жизненного цикла узла. Официальная документация описывает `openclaw nodes remove --node ...`: команда отзывает роль узла в записи устройства и разрывает соответствующие соединения. Для устройства с несколькими ролями другие роли могут сохраниться, поэтому администратор отдельно сверяет итоговую запись и оставшиеся права. Дополнительно проверьте локальные разрешения, которые выдавались на машине для пилота.
После отзыва повторите безопасную попытку подключения и проверьте отсутствие доступной поверхности. Зафиксируйте решение в журнале проекта и обновите перечень доверенных устройств. Такой тест даёт доказательство закрытия удалённого исполнения. Сценарии проверки ИИ-агентов помогают оформить отказ и возврат к исходному состоянию в рамках подготовки будущего пилота.
Пилот и приёмка
Предложите будущий пилот на тестовом node host с заранее выбранной командой чтения и явным владельцем устройства. Подготовьте карту прав: кто допускает устройство, кто согласует поверхность, кто подтверждает конкретный вызов и кто отзывает доступ. Для каждой роли укажите путь проверки в Gateway и на локальной машине. Согласуйте журнал, в котором остаются идентификатор узла, тип решения и результат вызова.
Критерии приёмки сформулируйте через наблюдаемые состояния. Разрешённая команда проходит все согласования на тестовой машине. Запрос вне утверждённой поверхности блокируется. Изменение набора команд снова требует решения. Отзыв роли узла прекращает его доступ. Оператор способен восстановить цепочку по журналу и объяснить причину каждого отказа. Эти пункты описывают ожидаемую проверку; фактические показатели появятся после испытания.
Техническую карту дополните местными правилами ОС. Пользователь устройства проверяет, какие разрешения реально выданы процессу, а администратор сопоставляет их с задачей. Если приёмка выявит более широкие полномочия, верните настройку на доработку до расширения сценария. Документируйте используемую версию OpenClaw: поверхность команд и доступные способы согласования могут меняться при обновлении.
Стоимость такой работы зависит от числа устройств, состава команд, нужных подтверждений и требований к журналу. Тариф и смету обсуждают по конкретной карте доступа после описания пилота. Если команде нужен маршрут согласований с владельцами и контрольными отказами, его можно спроектировать в рамках автоматизации бизнес-процессов. Итогом проектирования станет проверяемое решение о допуске каждого узла с ограниченным исполнением после сопряжения.