Сценарий: MHS обнаруживает прибор и вызывает его команды — быстрое решение: не открывайте автоматическое управление, а начните с офлайн-симуляции и только затем повышайте права по пяти уровням. По состоянию на 30 августа 2026 года Anthropic MHS остаётся ограниченным исследовательским preview-доступом и предназначен для устройств с программируемым интерфейсом, а не для любого физического оборудования официальное объявление Anthropic.

Эта статья для трёх групп:

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

Приёмка Anthropic MHS начинается с границ, а не с демонстрации

Самая опасная ошибка — считать обнаружение устройства доказательством безопасного управления. MHS может описывать возможности прибора и передавать команды через стандартизированный драйвер, но решение AI Agent остаётся вероятностным. MCP — это коммуникационный слой для подключения моделей к инструментам и данным, а не физический ограничитель. Claude Code может работать с командной строкой, файлами и кодом, однако он также не заменяет контроллер безопасности описание MCP в документации Anthropic и руководство по началу работы с Claude Code.

Разделяйте пять зон ответственности:

  • MHS-драйвер — обнаружение устройства, описание возможностей, форматы команд и ответов;
  • MCP — передача вызова между Agent и инструментом;
  • AI Agent — выбор следующего действия на основании контекста;
  • детерминированный скрипт — последовательность, диапазоны, тайм-ауты и условия остановки;
  • сама аппаратура — аппаратные блокировки, концевики, межблокировки и аварийная остановка.

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

В объявлении Anthropic приведён показательный экспериментальный случай: физическая проблема была интерпретирована агентом как программная. Это не доказывает ненадёжность MHS во всех системах, но показывает, почему нельзя разрешать агенту самостоятельно решать, является ли отказ прибора программным. Ваша процедура должна считать неизвестное состояние отказом и переводить систему в безопасный режим.

Официальная страница заявки на участие в MHS подтверждает исследовательский характер доступа. Это не объявление о полноценной загрузке стандарта или универсальном SDK. Anthropic также указывает, что MHS рассчитан на физические устройства с программируемым интерфейсом. Оборудование без такого интерфейса нельзя считать совместимым только потому, что рядом есть компьютер, последовательный порт или сетевой шлюз.

Два контрольных вопроса до подключения

  1. Что именно получила ваша команда: право участвовать в исследовательском preview, публичное описание или пример партнёра?
  2. Есть ли у прибора документированный программируемый интерфейс с определёнными состояниями, единицами измерения и условиями отказа?

Если на первый вопрос нет подтверждения от официальной страницы, остановите закупку интеграционных работ. Если на второй нет ответа из руководства производителя, переводите план в режим симуляции. Не подменяйте отсутствие спецификации догадками Agent.

Сценарий 1: симуляция вместо физического исполнительного механизма

Первый рубеж — среда без реального насоса, манипулятора, нагревателя или другого исполнительного устройства. Подставьте симулятор, виртуальное состояние прибора либо тестовый интерфейс производителя. Цель — проверить не «умность» модели, а техническую связность цепочки.

Порядок проверки:

  1. Зафиксируйте источник доступа к MHS: приглашение, форма заявки или публичная документация.
  2. Создайте отдельный тестовый проект без производственных ключей и реальных идентификаторов образцов.
  3. Подключите только симулятор или тестовый интерфейс.
  4. Проверьте обнаружение драйвера и список доступных возможностей.
  5. Отправьте корректные команды чтения и заранее известные ошибочные команды.
  6. Сравните фактические ответы с контрактом интерфейса.
  7. Сохраните список драйверов, журнал переходов состояний и полный журнал отказов.

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

Критерий прохождения: команда может воспроизвести каждый тест по журналу и объяснить, кто отклонил действие — драйвер, скрипт или виртуальный контроллер.

Действие при провале: удалить разрешения на запись и оставить только офлайн-симуляцию. Не исправляйте проблему подсказкой вроде «не выполняй опасные команды». Ограничение должно быть проверяемым кодом или устройством.

Сценарий 2: мониторинг одного прибора в режиме только чтения

После симуляции выберите один прибор с документированным интерфейсом. Откройте только состояние, показания датчиков и журналы работы. Не выдавайте Agent команды запуска, остановки, калибровки или изменения параметров.

Вам нужно сопоставить каждое поле MHS с руководством прибора:

  • название состояния;
  • единица измерения;
  • диапазон и точность;
  • временная метка;
  • признак устаревших данных;
  • условие «занят», «готов», «ошибка» или «аварийная остановка»;
  • источник значения — датчик, контроллер или вычисляемое поле.

Проведите тест с намеренной задержкой чтения. Уберите сетевой канал, верните его и проверьте, обозначаются ли старые данные как устаревшие. Создайте переход прибора в ошибку через штатный тестовый режим, если он предусмотрен производителем. Наблюдайте, не продолжает ли Agent описывать устройство как готовое.

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

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

Действие при провале: остановить пилот на чтении. Зафиксировать расхождение, добавить явное состояние «неизвестно» и запросить исправление драйвера или интерфейса.

Для управления секретами и рабочими файлами держите контрольный узел отдельно от личного рабочего пространства. Внутренние правила доступа можно сверить с материалами о конфиденциальности и изоляции Mac-среды.

Сценарий 3: ограниченная запись с независимой защитой

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

Пять обязательных отрицательных тестов:

  1. Выход за диапазон. Передайте значение ниже и выше разрешённого предела.
  2. Повтор команды. Отправьте одинаковый идентификатор операции дважды.
  3. Занятое устройство. Попробуйте запись во время выполнения другой операции.
  4. Разрыв связи. Оборвите канал после отправки команды, но до подтверждения.
  5. Неактуальное состояние. Передайте команду на основании устаревшего статуса.

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

Оставьте за пределами Agent:

  • физическую аварийную кнопку;
  • аппаратный предел скорости, температуры, давления или хода;
  • ручное подтверждение опасной операции;
  • независимую консоль оператора;
  • процедуру восстановления после аварийной остановки.

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

Почему MHS и MCP нельзя считать одним и тем же

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

Проверяйте цепочку отдельно:

  • MCP должен ограничивать доступные инструменты и передавать ошибки без потери контекста;
  • MHS-драйвер должен корректно описывать состояния, единицы и команды;
  • Agent должен выбирать только разрешённые операции;
  • детерминированный сценарий должен проверять порядок и условия;
  • устройство должно физически блокировать недопустимое действие.

Это отвечает на частый вопрос команд, которые хотят понять различие MHS и MCP в управлении оборудованием: MCP соединяет, MHS стандартизирует взаимодействие с поддерживаемым устройством, но ни один из них сам по себе не превращает Agent в сертифицированную систему управления.

Сценарий 4: несколько приборов и опасная передача состояния

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

Составьте граф переходов:

  • какой сигнал означает фактическое завершение;
  • кто подтверждает наличие образца или детали;
  • какое состояние блокирует следующий шаг;
  • что происходит при частичном выполнении;
  • где хранится идентификатор операции;
  • может ли повторный запуск привести к двойной подаче или повторному движению.

Затем намеренно создайте три конфликта:

  1. первое устройство ещё занято;
  2. ожидаемый образец или заготовка отсутствует;
  3. ответ о завершении потерян или пришёл с неверным идентификатором.

Следующий прибор не должен действовать во всех трёх случаях. Если Agent продолжает цепочку на основании предположения, верните систему на предыдущий уровень.

Здесь особенно важно не смешивать коммуникацию MCP, MHS-драйвер, рассуждение Agent и последовательность скрипта. Оркестрация должна иметь детерминированный шлюз: он принимает только подтверждённые состояния и сам блокирует опасную передачу управления.

Сценарий 5: длинная задача и работа без оператора

Одна успешная демонстрация не подтверждает безопасность длительного эксперимента. Для длинной задачи проверяйте потерю контекста, повторные попытки, смещение цели, остановку управляющего процесса и восстановление после отключения панели. Anthropic отдельно описывает инженерные подходы к длительно работающим агентам; используйте их как материал для архитектуры, а не как доказательство пригодности конкретного лабораторного процесса описание управляемых длительных Agent-сценариев.

Критические шаги переносите в восстанавливаемый детерминированный скрипт. Agent может подготовить план, объяснить отклонение или предложить следующий шаг, но не должен единолично хранить единственную копию состояния эксперимента.

Установите до запуска:

  • максимальную длительность сессии;
  • лимит повторных попыток;
  • срок действия команды;
  • условие обязательной передачи оператору;
  • поведение при потере связи;
  • место записи контрольных точек;
  • процедуру ручного продолжения или безопасной отмены.

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

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

Удалённый узел: контроль, аудит и восстановление

До подключения физического прибора примите управляющий узел как самостоятельный компонент. Проверьте:

  • отдельную учётную запись для автоматизации;
  • минимальный набор прав;
  • сетевой белый список;
  • запрет прямого входа из непроверенных сегментов;
  • аудит каждой команды;
  • идентификатор Agent-сессии;
  • запись ответа устройства;
  • воспроизводимость и просмотр удалённой сессии;
  • процедуру ротации секретов;
  • независимый канал ручного отключения.

Три аварийных испытания обязательны:

  1. контрольный узел теряет сеть;
  2. процесс Agent завершается с ошибкой;
  3. неправильный параметр уже отправлен устройству.

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

Для оценки взаимодействия человека и AI полезно сверить процедуру с материалами NIST по управлению рисками AI и взаимодействию человека с системой. Рамка NIST не сертифицирует MHS и не утверждает конкретный прибор, но помогает не потерять человеческий контроль, наблюдаемость и критерии остановки AI Risk Management Framework 1.0.

Контрольные точки пилота на 2026 год

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

Этап до подключения

  • [ ] Подтверждён статус доступа к MHS через официальный канал, а не по пересказу партнёра.
  • [ ] Зафиксировано, что оборудование имеет программируемый интерфейс.
  • [ ] Определены владелец прибора, владелец Agent-платформы и ответственный за остановку.
  • [ ] Разделены MHS-драйвер, MCP, Agent, скрипт и система безопасности устройства.
  • [ ] Создан отдельный контрольный узел без производственных секретов по умолчанию.

Этап симуляции

  • [ ] Обнаружение устройства проверено без физического исполнительного механизма.
  • [ ] Проверены корректные команды, неизвестные поля и ошибочные параметры.
  • [ ] Смоделированы занятое состояние, задержка, обрыв связи и неполный ответ.
  • [ ] Сохранены список драйверов, переходы состояний и журналы отказов.
  • [ ] Для каждой ошибки определено действие: блокировка, безопасная остановка или ручная передача.

Этап чтения

  • [ ] Каждое поле сопоставлено с руководством производителя.
  • [ ] Единицы, временные метки и признаки устаревших данных проверены.
  • [ ] Состояние «неизвестно» не преобразуется в «готово».
  • [ ] Agent не имеет разрешения на запись.
  • [ ] Расхождения остановили повышение прав.

Этап ограниченной записи

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

Этап многоприборной и автономной работы

  • [ ] Следующий прибор блокируется до подтверждения предыдущего шага.
  • [ ] Проверены отсутствие образца, конфликт порядка и потеря ответа.
  • [ ] Длительный сценарий имеет контрольные точки и лимит повторов.
  • [ ] После перезапуска исключён повтор неизвестной команды.
  • [ ] Контрольный узел имеет отдельные права, журналы и сетевые ограничения.
  • [ ] Проверены потеря узла, падение Agent и восстановление после ошибочной команды.

Итоговое решение: открыть, оставить чтение или отложить

Выбирайте один из трёх исходов, а не расплывчатое «пилот прошёл».

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

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

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

Текущий подход — подключить Agent к реальному прибору через обычный рабочий компьютер — обычно проигрывает по трём причинам: права смешиваются с личной средой, долгий процесс сложнее восстановить после обрыва, а журналы и контрольные точки часто не отделены от кода. Для команд, которым нужно постоянно запускать Claude Code, симулировать драйверы или держать удалённую консоль, аренда изолированной Mac-среды MacPng может быть более управляемым промежуточным вариантом. Она не заменяет аппаратные блокировки и не делает MHS безопасным автоматически, но позволяет отделить контрольный узел от рабочего места до решения о подключении физического оборудования. Перед таким шагом сопоставьте собственные требования с вариантами удалённой Mac-инфраструктуры.

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