Удалённые исполнители

Дайте агенту настоящий компьютер для работы: Linux, macOS или Windows.

Что такое удалённый исполнитель

У агента в Nessie нет компьютера. Он может читать то, что есть в Nessie, общаться с людьми и вызывать подключённые инструменты по сети, но не может открыть файл на ноутбуке, выполнить команду или посмотреть страницу, которая существует только за чьим-то логином. Удалённый исполнитель — это способ дать агенту машину, с которой он будет работать.

Исполнитель — это небольшой демон, который вы устанавливаете на компьютер, которым управляете. Он устанавливает исходящее соединение с вашим экземпляром Nessie, доказывает, какая это машина, ключом, который никогда не покидает хост, и после этого предлагает фиксированный набор именованных операций — и больше ничего. Работа приходит отдельными подписанными командами; результаты возвращаются ограниченными структурированными квитанциями. Машина никогда не принимает входящее соединение от Nessie.

Важно точно понимать, чем исполнитель не является, потому что большинство инструментов удалённого доступа относятся к одному из этих типов, а исполнитель намеренно не является ни одним из них. Здесь нет SSH, нет общей удалённой оболочки, нет подключения к уже открытому терминальному мультиплексору, нет облачного стандартного ввода и нет общего сетевого прокси. Это не MCP-сервер и не контейнер или облачная среда выполнения — у Nessie уже есть такие вещи, и это совсем другое. Исполнитель — это конечная точка с явно выданными полномочиями и закрытым списком операций, и этот список и есть вся её поверхность.

Кому принадлежит исполнитель

Каждый исполнитель создаётся ровно с одной областью действия, и её нельзя изменить потом. Она определяет, кто может вызывать исполнителя и кто им администрирует.

У личного исполнителя всегда должен быть хотя бы один активный администратор-человек. Прямое удаление последнего не пройдёт; если транзакция при увольнении оставит исполнителя без администратора, он перестанет принимать новую работу, завершит уже принятую и отзовёт себя сам. Владелец организации имеет резервный путь только для отзыва: он может завершить исполнителя, которым иначе не управляет, но без просмотра его личного списка, сессий или содержимого — личный доступ никогда не передаётся молча кому-то другому.

Что агент может реально делать с исполнителем

Набор операций фиксирован в коде, а не настраивается для каждого развёртывания. Он делится на две части, и от этого зависит, что нужно установить: часть операций демон выполняет из собственного рабочего каталога без виртуальной машины вообще, а остальные требуют гостевой виртуальной машины на хосте для каждой сессии.

Операции, которым не нужна гостевая среда, входят в пакет рабочей области. Хост, который не может запустить гостевую среду, — это не сломанный исполнитель: он сопрягается как обычно, сообщает свой бэкенд песочницы как none и предлагает только пакет рабочей области и ничего больше. Именно в таком состоянии оказывается версия Windows без Hyper-V или Linux-машина, где пользователь не может использовать /dev/kvm; интерфейс называет это состояние прямо, а не падает невнятно.

Агент никогда не начинает работу с браузером по собственной инициативе. Обычный маршрут привязки одной операции отклоняет browser.open и browser.observe без вариантов; запуск браузера выполняет человек из канала, как один пакет из четырёх операций в новом запуске, и добавить к нему привязки потом нельзя. Управляемые сессии кодирования работают так же.

Ещё две группы существуют в коде и намеренно недоступны. Операции для управления вкладкой Chrome, в которую вы уже вошли, имеют полную локальную реализацию и расширение для native messaging, но управляющая плоскость отказывается их объявлять, пока сервер не сможет подтвердить, что исходная беседа была приватной, и записать, кто что раскрыл. Основа здесь намеренно неактивна, а расширение не входит ни в один установщик. Кроме того, несколько операций кодирования — attach, prompt, interrupt и close — названы в схеме, но не реализованы, поэтому их нельзя выдать.

Как это работает

Соединение всегда исходящее

Демон устанавливает исходящие соединения HTTPS и WSS только с вашим API Nessie и ни с чем другим. Nessie никогда не обращается к ноутбуку, не хранит его адрес и не считает ни один эндпоинт каталога транспортом до машины. Поэтому исполнитель работает из домашней сети, за NAT, в корпоративном VPN, без проброса портов и без правила входящего файрвола — и поэтому остановка демона означает полное и немедленное отключение.

Источник (origin) API должен быть HTTPS. Единственное исключение — loopback-адрес для тех, кто запускает Nessie на собственной машине; он включается отдельной переменной окружения. Никакой обычный флаг не переводит производственный источник на открытый HTTP.

Сопряжение подтверждает машину, а человек подтверждает её

Сопряжение — это двустороннее доказательство. Уполномоченный человек создаёт исполнителя в Nessie с его областью, и Nessie выдаёт регистрационный код (enrolment): случайный 256-битный вызов, от которого сохраняется только верификатор SHA-256. Он действителен десять минут и используется один раз.

На машине демон генерирует пару ключей Ed25519, хранит её в защищённом средствами ОС хранилище, доступном только владельцу, и записывает точный подписанный запрос на диск до любого сетевого вызова — чтобы при потере ответа повторить попытку с тем же подготовленным ключом, а не сопрягаться дважды. Затем он отправляет идентификатор регистрации, вызов, свой открытый ключ и подпись доказательства. Nessie сохраняет открытый ключ и его отпечаток. Закрытый ключ Nessie никогда не хранит.

Затем Nessie показывает этот отпечаток человеку, и тот его подтверждает. До этого подтверждения и последующего доказательства владения ключом исполнитель остаётся офлайн. Сопряжение нельзя завершить из текста чата или стенограммы терминала: нужно осознанное действие человека в веб-интерфейсе или в интерфейсе настольного приложения.

Машина, потерявшая ключ, не может вернуть свою запись исполнителя. Её отзывают и регистрируют заново как нового исполнителя. Ротация ключа, напротив, — это одна транзакция, подписанная и старым, и новым ключом.

Дескриптор — это подписанное утверждение машины о самой себе

Сопряжённый демон публикует дескриптор: подписанное утверждение, которое только повышает свою ревизию и содержит только структурные факты — какие схемы операций он поддерживает, его лимиты ресурсов и сети, платформу и дайджест его локальной политики. Он не содержит путей на хосте и не создаёт никаких полномочий в облаке.

Новая ревизия никогда не активируется сразу по получении. Её сохраняют как ожидающую проверки, и уполномоченный человек должен её увидеть и подтвердить, прежде чем она повлияет на доступное. Это предотвращает тихую выдачу новых прав при обновлении возможностей: новая объявленная операция начинается запрещённой.

Будьте точны в том, что доказывает подпись. Дескриптор, подписанный ключом сопряжённого исполнителя, доказывает, что этот ключ сделал утверждение. Он не доказывает, что хост не скомпрометирован, и интерфейс обязан это говорить.

Диспетчеризация: кандидат, привязка, команда, квитанция

Агент никогда не называет исполнителя. Прежде чем запуск сможет его использовать, Nessie превращает логическую операцию в непрозрачный, краткоживущий кандидат доступности. Ответ не содержит идентификатора исполнителя; база данных хранит только дайджест маркера вместе с тем, кто и для чего его получил. Модели и клиенты получают маркер, а не машину, которую можно выбрать.

Доступность определяет один резолвер, который одинаково используют API, воркер, интерфейс и помощник:

available(operation, human, agent, immutableRunContext) =
  human may discover executor
  ∩ exact executor-agent-operation grant allows operation
  ∩ stable logical tool grant allows operation
  ∩ scope matches immutable run context
  ∩ executor is online and descriptor is approved
  ∩ local policy permits operation

Потребление кандидата создаёт привязку под блокировкой базы данных, которая заново проверяет все эти ограничения и продвигает монотонный счётчик (fence). Диспетчеризация проверяет их ещё раз. Из этого следует, что отозванное право, суженная политика или отозванный исполнитель между двумя шагами останавливают работу, а не замечаются постфактум — и повтор никогда не может попасть на другую машину, чем та, к которой был привязан запуск.

Сама команда идёт по обычной очереди задач Nessie и жизненному циклу вызова инструмента, а не по собственной второй очереди. Демон опрашивает работу через свой аутентифицированный канал управления; ему никогда ничего не отправляют. Команда проходит четыре квитанции и никакие другие:

leased → accepted → started → result-acknowledged

Каждый кадр связывает идентификатор команды, происхождение запуска, счётчик привязки, ревизию возможностей, срок действия, ключ идемпотентности и дайджесты аргументов и полезной нагрузки. Демон отклоняет несовпадение, устаревшую политику, повтор или второй результат для команды, которую он уже завершил. Аргументы и итоговые результаты шифруются при хранении алгоритмом AES-256-GCM; база данных хранит ограниченный шифротекст и канонические дайджесты, а не содержимое.

Если подтверждение потеряно, Nessie не считает, что операция прошла успешно. Команда записывается как результат с неизвестным исходом, и запуск идёт по обычному пути восстановления; демон, который журналирует каждую доставленную команду локально до начала работы, не повторит побочный эффект. Поздняя квитанция всё ещё может честно разрешить неопределённость.

Граница доверия

Установка и сопряжение исполнителя

Установите CLI для Mac через Homebrew, приложения для Mac — через casks Homebrew, CLI для Linux — через APT или DNF, а исполнитель для Windows — через WinGet. У каждой сопряжённой команды свои права, которые хранятся на компьютере. Nessie управляет доступом внутри команды, но не может менять локальные ресурсы.

В руководстве по установке и сопряжению есть точные команды, двусторонний поток с восьмизначным кодом, локальные настройки, запуск, обновления и удаление.

Насколько подтверждена работа каждой платформы

Состояние трёх гостевых песочниц различается, и это различие существенно. macOS — бэкенд с работающим, проверенным на практике путём гостевой среды. Бэкенд Firecracker на Linux и бэкенд Hyper-V на Windows реализованы и покрыты тестами на стороне хоста — последовательность запуска, дисковые образы, транспорты управления и выхода в сеть, протокол черновиков, — но ни одна гостевая среда пока не загружалась на реальном железе в непрерывной интеграции проекта, потому что для этого нужна машина с KVM или Hyper-V, а задачи, которые это подтвердили бы, такой машины никогда не имели. Пакет рабочей области, которому гостевая среда не нужна, полностью проверен на Windows с реальным контуром управления. Считайте операции с гостевой средой на Linux и Windows непроверенными, пока не проверите их на собственном железе. Экран сопряжения в Nessie говорит то же самое своими словами.

Безопасность и изоляция

Один корень рабочей области, и его путь остаётся на машине

При сопряжении выбирается ровно один канонический корень рабочей области: один каталог, а не набор папок и никогда не их ближайший общий родитель. Nessie сообщают базовое имя корня, чтобы человек мог узнать границу в интерфейсе; полный путь остаётся в доступном только владельцу локальном состоянии машины и никогда не загружается. Сменить корень можно, но только после удаления всех локальных черновиков и песочниц, и это создаёт новую ревизию дескриптора, которая проходит ту же проверку человеком, что и любое изменение политики. Он никогда не может тихо расшириться до родительского каталога.

Файловые операции принимают только относительные пути. Они отклоняют обход путей и любой компонент-символическую ссылку, заново проверяют, что настроенный корень всё ещё является обычным каталогом, и возвращают ограниченные структурированные результаты без пути на хосте.

Записи идут в копию, и продвигать их может только человек

Агент никогда не пишет в ваши файлы. file.write создаёт ограниченное дерево с копированием при записи в собственном каталоге состояния демона, привязанное к запуску; последующие чтения и списки для этого запуска видят черновик. Работа в гостевой среде, включая сессии кодирования, использует то же копирование при записи.

Применение черновика к рабочей области — это одна операция, workspace.promote, и это единственная запись на хост во всей системе. У неё вообще нет схемы для модели: ни агент, ни помощник, ни путь, переданный вызывающей стороной, не могут превратить черновик в запись на хосте. Вместо этого человек открывает Ваши проверенные черновики, нажимает Проверить продвижение и подтверждает действие текущим паролем. Затем сервер заново проверяет подтверждённый дайджест проверки, дайджест манифеста, исходный запуск, пользователя и агента, ревизию авторизации, грант операции и активную локальную политику, прежде чем создать команду. На машине демон сам пересобирает манифест и отклоняет дайджест, который изменился, — поэтому правка, сделанная после проверки, не может пройти под одобрением этой проверки.

Само применение основано на дескрипторах и журналируется. Нативный помощник получает корень рабочей области и черновик как уже открытые дескрипторы каталогов, а не как пути; он проверяет каждый компонент операциями без следования по ссылкам, отклоняет символические и жёсткие ссылки, специальные файлы и пересечения точек монтирования и ведёт журнал «всё или восстановление»: при сбое либо завершается проверенный манифест, либо восстанавливается исходное состояние, прежде чем запускается что-либо ещё.

У гостевой среды нет сети, а выход наружу принудительный

Когда операции нужна гостевая среда, это микро-ВМ Linux на каждую сессию: без домашнего каталога хоста, без сокета Docker, без SSH-агента, без унаследованного окружения и без монтирования хоста, кроме общего доступа к рабочей области. Исполняемый монтаж среды выполнения доступен только для чтения; записываемый монтаж рабочей области запрещает исполнение, поэтому всё запускаемое берётся из проверенного пакета среды выполнения, а не из того, что записал агент. Гость переходит к непривилегированной учётной записи, прежде чем открыть хоть один сокет, а общий каталог, принадлежащий root, прерывает загрузку вместо того, чтобы оставить привилегированную нагрузку работать.

Самое важное: у гостевой среды нет сетевого интерфейса. В Linux последовательность запуска намеренно никогда не настраивает сеть, и TAP-устройство не создаётся; в Windows виртуальный сетевой адаптер, который Hyper-V добавляет по умолчанию, удаляется при установке. Единственный маршрут гостя с машины — это loopback-прокси внутри него, туннелируемый через виртуальный сокет к мосту на хосте, который передаёт байты собственному шлюзу демона — слушателю локального сокета, доступному только владельцу, без TCP-слушателя и без режима общей переадресации. Именно там применяются политики HTTP, CONNECT, WebSocket, перенаправлений, источников, загрузок и выгрузок, и используется существующий в Nessie механизм закреплённых запросов (pinned fetch), а не вторая реализация тех же правил. Ни NAT-моста, ни прямого DNS-резолвера нет: альтернативный DNS, сырой TCP, QUIC и обход прокси запрещены.

Список источников, который обеспечивает этот шлюз, настраивается на машине её владельцем и намеренно никогда не загружается. Интерфейс прямо называет это отсутствие, а не делает вид, что Nessie — редактор политики источников: чтобы узнать, к каким адресам может обращаться браузерный исполнитель, спросите человека, которому принадлежит машина.

Учётные данные

Никакое хранилище учётных данных хоста никогда не монтируется в гостевую среду. Ни связка ключей, ни ~/.codex или ~/.claude, ни глобальный токен CLI, ни переменная окружения с ключом API. Единственный поддерживаемый вход для управляемой сессии кодирования — приватный для владельца файл аутентификации, содержимое которого читает только контролируемый владельцем построитель initrd — никогда не Nessie, никогда не дескриптор, никогда не журнал и не аргумент команды — и который один раз переносится в приватный домашний каталог внутри гостя и уничтожается вместе с ВМ. Этот гость может обращаться ровно к одному источнику.

Браузерный исполнитель ещё строже: каждая сессия получает новый приватный профиль браузера и отказывается от профиля, подготовленного рабочей областью, поэтому стартует без cookies, без расширений и без неявного состояния входа.

Сырые локальные данные могут попасть к поставщику модели только внутри явного, ограниченного запуска. Nessie сохраняет только очищенные манифесты, дайджесты аргументов и политик, дайджесты результатов и структурированный статус. Содержимое файлов, вывод терминала, DOM браузера, учётные данные и факторы аутентификации запрещено записывать в записи базы данных, аудиторские записи, журналы, события реального времени и отчёты об ошибках.

Что даёт оператор и как он это отзывает

Разрешение на использование исполнителя — это не один переключатель. Агент может вызвать операцию, только если у него есть грант на этого исполнителя и на эту операцию, и обычная логическая политика инструментов это разрешает, и область запуска совпадает, и собственная локальная политика машины это позволяет. Поэтому выдача одному исполнителю операции не разрешает ничего на другом, а обновление возможностей не может ничего расширить, потому что новые операции приходят запрещёнными.

Доступ агентов и общий доступ вступают в силу сразу на самой странице, без продолжения через подтверждение, запрос пароля или новый шаг аутентификации. На вкладке исполнителя Агенты управляющий включает или выключает доступ агента к машине напрямую; на вкладке Общий доступ он даёт человеку право «Может использовать» или «Администратор» либо расширяет использование на проект или на всех в текущей команде — так же напрямую. В вашем личном диалоге с помощником — только там, никогда в общем канале, в запланированной задаче или в запуске другого агента — помощник может вместо этого подготовить изменение доступа агента или назначения; оно публикует карточку подтверждения в этом диалоге, и ничего не меняется, пока вы не нажмёте «Разрешить доступ» на ней. Текст чата никогда не считается подтверждением.

Три изменения по-прежнему требуют повторного ввода текущего пароля в момент подтверждения: активация ревизии дескриптора; подготовленное помощником назначение, которое даёт машину человеку, а не агенту; и постоянная политика, позволяющая коллегам запускать на ней команды от имени её владельца — политика неконтролируемой работы с задачами. Отключение или удаление машины намеренно не требует ни того, ни другого, поскольку выключатель не должен быть труднее доступным, чем то, что он останавливает. Продвижение проверенного черновика требует пароля всегда. Журнал аудита отдельно записывает действующего человека и участие помощника.

Исполнитель проходит небольшой, явно заданный набор состояний:

pending_pairing → online ↔ offline
        │             ↓
        └──────────→ draining → revoked
                         ↓
                       error

Меню Компьютер в шапке — это место, где управляющий готовит каждое изменение жизненного цикла: приостановить, возобновить после паузы, отключить или удалить. Пауза оставляет исполнителя в сети, но он перестаёт принимать команды. Отключение аннулирует его клиентские сертификаты и все невыполненные маркеры кандидатов и не может быть отменено — отключённый исполнитель сопрягается заново как новый. Удаление делает то же и дополнительно убирает исполнителя из списка; в отличие от отключения, оно доступно вне зависимости от состояния исполнителя, включая ожидающее сопряжение и уже отключённого, потому что это единственный способ выйти из списка. Дренаж — то есть завершение уже принятой работы перед тем, как перестать принимать новую, — это настоящее третье состояние протокола, и интерфейс может показать компьютер в нём, но ничто здесь его не запускает: это делает только прямой вызов API. Каждое подтверждённое изменение доступа, проверка дескриптора и переход жизненного цикла, включая дренаж, также продвигает эпоху соединения демона, поэтому его следующий опрос управления — не позже чем через секунду — завершается отказом и останавливает все живые гостевые среды до того, как демон сможет переподключиться. Отзыв — это не просьба, которую машина вправе проигнорировать.

Эксплуатация исполнителя

Проверка работоспособности

Собственный ответ Nessie — это проверка живости (liveness). Демон подписывает heartbeat, и исполнитель, чья последняя аутентифицированная активность старше шестидесяти секунд, сразу и надёжно помечается офлайн, прежде чем его можно будет показать в списке, выбрать или отправить ему работу. Исполнитель, который показан как онлайн, подтвердил себя в течение последней минуты.

На самой машине нет эндпоинта проверки состояния — демон по замыслу не слушает ни одного порта для оператора. На macOS и Linux спросите CLI напрямую:

nessie-executor status                # every paired executor, plus linger state
nessie-executor status <executorId>
systemctl --user status nessie-executor@<executorId>

На macOS статус показывает launchd-агент каждой команды. Команда systemctl относится только к Linux. В Windows значок в трее — ответ «на первый взгляд»: его меню называет причину, а журнал службы содержит подробности. На обеих платформах вкладка Обзор исполнителя в Nessie показывает одобренные профили, границу данных, время последнего появления и любое ожидающее проверки предложение локальной политики.

Журналы

Туда попадает каждый отказ, который человек может исправить: неподписанная или подменённая среда выполнения, каталог состояния, который не удаётся защитить, исполнитель, который не запустился при загрузке. Туда никогда не попадают вызов сопряжения, ключ или вывод дочернего процесса. Нет настройки уровня журнала, которую можно поднять, потому что более подробного режима просто нет.

CLI для Mac записывает журнал службы каждой команды в ~/Library/Logs/NessieExecutor/<executorId>.log.

Обновление

Обновляйте CLI через Homebrew, APT или DNF, затем перезапускайте службу каждой команды: сначала disable, потом enable. WinGet обновляет исполнитель для Windows. Установщики Nessie Desktop предлагают подписанные обновления внутри приложения; установки MSI и Debian используют свой менеджер пакетов. Сопряжения и локальные права переживают обновления.

Остановка и удаление

Остановка — это корректный путь, которым управляет демон, а не убийство процесса. Демон получает сигнал завершения, останавливает все гостевые сессии, освобождает свою аренду и завершается. В Linux юнит ждёт пятнадцать секунд при бюджете на завершение в десять секунд и намеренно никогда не эскалирует до неперехватываемого убийства — потому что демон, убитый посреди завершения, оставляет микро-ВМ и оверлей рабочей области без процесса, который их очистит. Зависшая остановка поэтому видна в systemctl --user status, а не проходит молча, и эскалация — это явное решение человека.

Чтобы удалить пакет Linux:

nessie-executor disable <executorId>   # stops and disables the service
sudo apt remove nessie-executor
loginctl disable-linger                # only if your user manager should stop running at boot too

В Windows msiexec /x останавливает и удаляет службу, её записи реестра и запись автозапуска трея. На обеих платформах сопряжённое состояние намеренно остаётся: ~/.local/state/nessie-executor/ в Linux и %ProgramData%\Nessie Executor в Windows. Сопряжение — это ключ машины и подписанная ревизия политики, а удаление программы не означает просьбы их уничтожить; при переустановке они находятся на месте. Чтобы забыть сопряжение, удалите каталог вручную, а чтобы завершить его с другой стороны, отзовите исполнителя в Nessie.

И трей Windows, и настольный компаньон предлагают действие Забыть сопряжение на этом компьютере: оно останавливает локальный демон, удаляет ключ машины и выбор папки и после одного нативного подтверждения безвозвратно удаляет локальные копии черновиков — при этом серверный исполнитель и история его аудита остаются владельцу, который решает: сохранить их или отозвать.

Частые сбои