В базовой спецификации MCP все сообщения между клиентом и сервером должны соответствовать JSON-RPC 2.0 — локальный запуск процесса ещё не доказывает, что внешний инструмент действительно доступен. (modelcontextprotocol.io)

Симптом: удалённый Mac открывает веб-страницы, но DeepSeek Harness не вызывает модель, Git, зависимости или MCP-инструмент.
Быстрое решение: принимайте не «доступ в интернет», а четыре независимые цепочки с доказательствами DNS, TLS, учётной записи, прокси и поведения после краткого обрыва связи.

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

Сначала зафиксируйте границы приёмки

Не составляйте универсальный список разрешённых доменов «для DeepSeek Harness». Набор внешних целей зависит от выбранного поставщика модели, кода, реестра пакетов, конкретного MCP Server и корпоративной архитектуры. На дату 19 августа 2026 года официальные материалы подтверждают работу Harness с моделью, рабочей областью, командами и внешними инструментами, но это не превращает разные проекты в одинаковую сетевую конфигурацию.

Перед тестом составьте карту зависимостей:

  • модельный API и способ передачи ключа;
  • адреса и протоколы удалённого Git;
  • реестр пакетов, архивы релизов и вспомогательные загрузчики;
  • транспорт MCP — локальный процесс, HTTP или другой вариант, предусмотренный вашей реализацией;
  • внутренние DNS-имена, адреса исключений из прокси и корпоративные центры сертификации;
  • пользователь и постоянный процесс, от имени которого запускается Harness.

Для каждой цели запишите не только «доступно / недоступно», но и этап отказа:

  1. имя не разрешается через DNS;
  2. TCP-соединение не устанавливается;
  3. TLS-проверка цепочки или имени не проходит;
  4. прокси отклоняет запрос;
  5. сервер отвечает ошибкой авторизации;
  6. сервер отвечает ошибкой приложения;
  7. Harness не передаёт запрос дальше или неправильно обрабатывает ответ.

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

Важно: не отключайте проверку TLS и не добавляйте исключения «на время приёмки». Если корпоративный сертификат нужен, его следует установить в утверждённое хранилище и проверить цепочку доверия штатными средствами macOS. Apple описывает проверку имени, срока действия, подписи и доверенного центра как часть оценки сертификата. (developer.apple.com)

Проверьте DeepSeek API минимальным безопасным запросом

Объект теста: от удалённого Mac до настроенной конечной точки DeepSeek API — DNS, TLS, прокси, авторизация и ответ верхнего уровня.

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

Пример заготовки для журнала:

date -u
id
scutil --dns
env | grep -Ei '^(HTTP|HTTPS|NO)_PROXY=' | sed 's#=.*#=<set>#'

Последняя команда показывает наличие переменной, но не раскрывает её значение. Для запроса используйте только официальный способ аутентификации, предусмотренный вашим провайдером. В документации DeepSeek API указан Bearer-токен; сам ключ не должен попадать в командную историю, вывод диагностики или архив приёмки. (api-docs.deepseek.com)

В доказательстве сохраните:

  • время и часовой пояс;
  • хост удалённого Mac или его внутренний идентификатор;
  • исполняемую учётную запись;
  • результат DNS без секретных параметров;
  • факт успешной TLS-проверки;
  • код ответа и обезличенное тело ответа;
  • идентификатор запроса, если его безопасно хранить;
  • отдельный результат Harness, а не только ответ команды curl.

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

Разделение отказов:

  • DNS-ошибка означает проблему резолвера, внутренней зоны или политики выхода.
  • Ошибка TLS указывает на сертификат, доверие, имя узла, инспекцию трафика или несовместимый маршрут.
  • Ответ 401/403 обычно относится к ключу, проекту, квоте или полномочиям, а не к отсутствию сети.
  • Ошибка 429 требует отдельного анализа лимитов и повторов.
  • Ответ 5xx или тайм-аут после успешного TLS нужно сравнить с состоянием upstream-сервиса и политикой прокси.

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

Примите Git-путь отдельно от браузерного доступа

Объект теста: обнаружение репозитория, чтение ссылок, получение ограниченной ветки и контролируемая проверка отправки без передачи содержимого заказчика в отчёт.

Открывающаяся страница кода не доказывает, что Git работает. Браузер использует собственное хранилище сессий и сертификатов. Фоновый Git может идти через HTTPS с одним набором полномочий, через SSH с другим маршрутом или вообще не наследовать настройки прокси.

Проверяйте в таком порядке:

  1. получить URL удалённого репозитория из согласованного тестового проекта;
  2. выполнить git ls-remote и убедиться, что читаются ссылки;
  3. сделать неглубокий клон или получить небольшой тестовый объект;
  4. проверить git fetch после удаления локальной ссылки;
  5. выполнить контролируемую отправку в отдельную тестовую ветку;
  6. удалить ветку и рабочую копию согласно процедуре организации.

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

Для SSH отдельно проверьте:

ssh -T -v -o IdentitiesOnly=yes <git-user>@<git-host>

Флаг подробного режима применяйте только в очищенном выводе: диагностический журнал может содержать имена файлов ключей, внутренние адреса и служебные заголовки. Если корпоративный шлюз блокирует стандартный SSH-маршрут, официальный документ Git-хостинга описывает вариант SSH через порт 443, но прокси всё равно может вмешаться в соединение. (docs.github.com)

Требуемое доказательство:

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

Условие отказа: браузер открывает страницу, но ls-remote не работает; либо чтение возможно, а контролируемая отправка требует ручного ввода секрета в интерактивном терминале.

Восстановите зависимости после очистки кэша

Объект теста: установка Harness, обновление расширений и загрузка зависимостей проекта через постоянный, документированный маршрут.

Проверка «пакет уже установлен» слишком слабая. Она может проходить за счёт локального кэша, заранее подготовленного образа или временной прокси-переменной. Для поставки важнее доказать воспроизводимую установку после очистки кэша.

Сценарий:

  1. запишите версии Node.js, пакетного менеджера и Harness;
  2. сохраните контрольные суммы lock-файла;
  3. выполните установку в чистой рабочей директории;
  4. удалите только разрешённые кэши тестового проекта;
  5. повторите установку;
  6. установите или обновите один тестовый плагин;
  7. запустите минимальную команду Harness под постоянным процессом;
  8. сравните итоговое дерево зависимостей и журналы ошибок.

Для npm-подобной цепочки проверьте, откуда берутся proxy, https-proxy, noproxy и registry. Официальная документация указывает, что прокси может задаваться конфигурацией или переменными HTTP_PROXY/HTTPS_PROXY, а NO_PROXY определяет адреса, которые обходят прокси. (docs.npmjs.com)

На новых версиях Node.js поведение прокси также зависит от включённой поддержки переменных окружения и от того, наследует ли их конкретный процесс. Документация Node.js описывает HTTP_PROXY, HTTPS_PROXY и NO_PROXY как параметры встроенной поддержки прокси, но это не означает, что любой старый клиент или дочерний процесс будет вести себя так же. (nodejs.org)

Состояние проверки Что это доказывает Решение
Установка проходит только с кэшем На узле уже есть артефакты Не принимать как воспроизводимую доставку
Чистая установка проходит в терминале Интерактивный пользователь имеет рабочий маршрут Проверить фоновый процесс
Чистая установка проходит после перезапуска Маршрут и настройки переживают перезапуск Можно переходить к контрольной установке
Работает только с вручную экспортированной переменной Зависимость от временной сессии Отклонить до оформления постоянной конфигурации
Ошибка сертификата при загрузке Нет доверия к цепочке или неверна инспекция Исправить доверие, не отключать TLS

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

Разберите путь MCP Server по трём независимым участкам

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

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

  1. Harness видит MCP Server;
  2. клиент получает список инструментов;
  3. выбранный инструмент принимает тестовые аргументы;
  4. ответ возвращается в Harness и корректно отменяется при остановке.

В MCP для обнаружения инструментов используется запрос tools/list, а для вызова — tools/call. Спецификация также требует явной обработки ошибок и предусматривает механизм отмены запроса. (modelcontextprotocol.io)

Не путайте три разных состояния:

  • Harness → MCP: процесс не найден, транспорт не установлен, локальный порт недоступен, неверна команда запуска или формат конфигурации.
  • MCP → внешний источник: сервер стартовал, но не разрешает имя, не проходит TLS, не получает ответ через прокси или не может обратиться к API данных.
  • Полномочия: сеть рабочая, но ключ, OAuth-сессия, область доступа или разрешение инструмента неверны.

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

Для длинных операций заранее определите ожидаемое поведение после отмены. В официальном расширении MCP Tasks отмена описана как кооперативная: сервер подтверждает намерение, но не всегда способен немедленно остановить работу. Для нестабильных соединений также предусмотрены состояния задачи и последующее получение результата, если клиент и сервер поддерживают это расширение. (modelcontextprotocol.io)

Условие отказа: инструмент найден, но его внешний источник недоступен; либо после тайм-аута Harness повторяет небезопасный вызов без подтверждения идемпотентности.

Ответьте на типичные вопросы до подписания акта

Удалённый Mac открывает сайты, но DeepSeek API не подключается

Сначала не меняйте ключ. Повторите минимальный запрос из фонового процесса и сохраните этап сбоя. Затем сравните DNS, TLS и маршрут прокси с интерактивным терминалом. Если TLS успешен, а сервер возвращает 401 или 403, это уже проверка учётной записи и разрешений. Если соединение завершается до ответа сервера, причина находится в маршруте, прокси, DNS или сертификатах.

Какие внешние соединения действительно нужны DeepSeek Harness

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

Как принимать AI Agent в корпоративном прокси

Проверяйте не только переменные текущего shell. Зафиксируйте пользователя, родительский процесс, службу запуска, окружение, хранилище сертификатов и правила NO_PROXY. Затем перезапустите службу, выполните все четыре сценария и убедитесь, что в журналах нет секретов. Доступ, который исчезает после выхода из терминала, не является поставляемым.

MCP Server не отвечает: сеть или конфигурация?

Сначала проверьте локальный запуск и рукопожатие. Затем отдельно подтвердите DNS и TLS внешнего источника от имени процесса MCP. После этого проверьте полномочия только тестовым чтением. Если первый участок успешен, второй завершается тайм-аутом, а третий ещё не запускался, менять JSON-конфигурацию клиента преждевременно.

Выполните сквозную проверку после короткого обрыва

Объект теста: реакция Harness и внешних инструментов на временное исчезновение сети.

Не тестируйте обрыв на операции, которая создаёт платеж, удаляет данные или отправляет изменения в продуктивное окружение. Используйте минимальный запрос модели, чтение Git и безопасный MCP-вызов.

Последовательность:

  1. запустите каждый тест с уникальным локальным идентификатором;
  2. во время ожидания кратко заблокируйте тестовый маршрут по согласованной процедуре;
  3. зафиксируйте, получил ли клиент тайм-аут, ошибку или обрыв потока;
  4. восстановите сеть;
  5. дождитесь повторной попытки либо остановите задачу;
  6. проверьте, не возник ли дубликат побочного действия;
  7. перезапустите Harness и повторите контрольный вызов;
  8. сравните журналы до и после перезапуска.

Для MCP нельзя считать разрыв транспорта равным отмене: спецификация указывает, что отключение может произойти из-за сети и само по себе не должно интерпретироваться как отмена запроса. Отмену нужно передавать явно, если это поддерживается реализацией. (modelcontextprotocol.io)

Цепочка Минимальный тест Что записать Причина отказа
DeepSeek API Безопасный запрос модели DNS, TLS, статус, обезличенный ответ Работает только из браузера или ручной сессии
Git ls-remote, получение и тестовая отправка Тип транспорта, права, код завершения Нет фоновой аутентификации
Зависимости Установка после очистки кэша Реестр, версия менеджера, результат сборки Успех зависит от кэша или временного прокси
MCP Server tools/list, чтение, отмена Три участка маршрута, состояние задачи Локальный старт принят за внешнюю доступность
Восстановление Краткий обрыв и повтор Поведение задачи, повторный эффект Неясно, был ли вызов выполнен дважды

Соберите комплект доказательств для передачи

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

  • дату и время каждой проверки;
  • идентификатор удалённого Mac и тип целевой среды;
  • исполняемую учётную запись;
  • версию Harness, Node.js и пакетного менеджера;
  • обезличенную карту внешних целей;
  • результаты DNS, TLS и прокси;
  • статусы Git-операций;
  • результат чистой установки зависимостей;
  • результат tools/list, чтения и отмены MCP;
  • реакцию на сетевой обрыв;
  • действие отката для каждого отказа.

Не включайте API-ключи, OAuth-токены, приватные ключи, содержимое клиентского репозитория, полные URL с секретами, корпоративные адреса прокси и сертификаты. Для проверки достаточно отпечатка, типа объекта, статуса и ссылки на закрытое хранилище доказательств, если такая ссылка предусмотрена вашей политикой.

В акте приёмки сформулируйте три обязательных условия:

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

Если не выполнено хотя бы одно условие, фиксируйте не «частично принято», а конкретный блокирующий дефект: например, «Git HTTPS проходит вручную, но не наследуется процессом Harness» или «MCP стартует локально, внешний источник недоступен через корпоративный DNS».

Для выбора площадки сначала сравните варианты удалённых Mac в MACCOME, а затем попросите выполнить именно эту матрицу на целевом узле. Если требуется сравнить доступность разных регионов, используйте страницы Mac mini в Virginia и Mac mini в Singapore, но не заменяйте реальную проверку предположением о географии.

Текущий вариант или Mac для временной среды

Если вы сейчас запускаете Harness на личном компьютере, общей виртуальной машине или разрозненном облачном сервере, типичные недостатки уже заметны: прокси живёт только в профиле одного пользователя, кэш скрывает проблемы повторной установки, а после перезапуска никто не проверяет наследование сертификатов и переменных окружения. При работе через удалённый Windows- или Linux-хост дополнительно приходится учитывать отличия SSH-агента, хранилища доверия и фоновых служб.

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

Перед переносом реального репозитория и рабочих ключей скачайте или скопируйте пустую матрицу доказательств и сначала прогоните четыре минимальные цепочки: API, Git, зависимости и MCP. Если одна из них зависит от ручного прокси или раскрывает секреты в логах, остановите миграцию. Для следующего этапа используйте руководство по приёмке облачного Mac под DeepSeek Harness и проверке среды непрерывного запуска: сначала устраните сетевой блокер, затем переносите рабочие данные.