VS Code 1.138: куда поместить Mac после PR Agent? 2026

Симптом: Agent успешно создал Pull Request, но Xcode-сборка на той же машине не воспроизводится или застревает в общей очереди.

Быстрое решение: оставьте изменение кода и создание PR в Agent Host, проверяемые тесты перенесите в CI, а Xcode, подпись и Apple-платформенную регрессию — на отдельный облачный Mac.

Если вы используете VS Code 1.138 Agent для создания PR, не воспринимайте сам факт создания запроса как доказательство готовности к выпуску. Agent Host удобен для подготовки изменений, но окончательное подтверждение должно появляться в независимых слоях: GitHub Actions или другом детерминированном CI, а для iOS и macOS — в отдельной среде macOS с контролируемым Xcode и правами подписи.

Эта схема предназначена для трёх групп:

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

Важно: документация VS Code подтверждает возможность просматривать и создавать Pull Request из сеанса Agent Host, включая выбор чернового состояния и доступных параметров слияния. Она не говорит, что создание PR заменяет обязательные проверки, защиту ветки, человеческое одобрение или настоящую сборку на Mac. Проверяйте эту границу по описанию VS Code 1.138 и документации Agent Host.

Граница между PR и доставкой

В процессе нужно разделять несколько состояний, которые часто ошибочно объединяют:

1. PR создан. Изменения записаны в ветку и оформлены для ревью.
2. Проверки прошли. CI выполнил заявленные тесты, а обязательные статусы вернулись в репозиторий.
3. Код можно выпускать. Проверены целевая платформа, права, подпись, артефакты, правила ветки и решение ответственного человека.

VS Code 1.138 Agent создаёт PR в первом смысле. Это полезная автоматизация границы между рабочей копией и процессом ревью, но она не переносит доказательство выполнения в CI и не даёт Apple-платформе особого статуса.

Для каждого PR сохраняйте как минимум:

• идентификатор коммита и название ветки;
• версию инструмента и описание среды, где Agent изменял код;
• ссылку на запуск CI и его логи;
• собранные артефакты, если они нужны для проверки;
• версию Xcode и параметры симулятора или физического устройства;
• сведения о том, выполнялась ли подпись и каким способом;
• факт ручного одобрения и причину разрешения или остановки.

GitHub описывает отдельное хранение артефактов Workflow, а логи выполнения можно проверять по официальной документации о журналах GitHub Actions. Это важнее, чем отметка в интерфейсе Agent: после отключения сеанса у команды должны остаться независимые следы того, что именно запускалось.

Сценарий кроссплатформенного проекта

Если проект состоит из веб-кода, серверных компонентов или библиотек, которые собираются в контейнере, новый Mac может не понадобиться. Agent Host может изменить файлы, выполнить локальную проверку и создать PR, но окончательный тест должен запускаться в CI с фиксированными командами.

Подход без отдельного Mac оправдан, когда одновременно выполняются следующие условия:

• исходный код не использует Xcode и Apple SDK;
• тесты не зависят от локального состояния Agent-сеанса;
• сборку можно повторить на стандартном Runner;
• секреты подписи, публикации и доступа к производственным системам не нужны;
• обязательные проверки запускаются после публикации PR;
• артефакты и журналы доступны ревьюеру независимо от Agent Host.

У такого решения есть очевидные плюсы:

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

Но есть и ограничения:

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

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

Сценарий Apple-платформы

Когда в задаче появляются Xcode, системные фреймворки, Simulator, физическое устройство или подпись, универсальный Runner уже не является заменой macOS. Apple отдельно описывает запуск приложения на симуляторе и физическом устройстве, поэтому среда должна соответствовать реальному способу проверки.

Здесь есть два варианта размещения.

Agent Host на том же Mac, где выполняется сборка

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

Недостатки:

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

Отдельный облачный Mac как слой сборки

В этом варианте Agent Host передаёт конкретный коммит или ветку независимому Runner. Mac получает исходный код, подготавливает окружение, запускает Xcode и сохраняет результат отдельно от сеанса Agent.

Плюсы:

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

Минусы:

• появляется время ожидания очереди;
• нужно продумать передачу артефактов и логов;
• потребуется отдельное управление версиями Xcode и сертификатами;
• стоимость Mac-слоя нужно сопоставить с реальным временем занятости, а не с числом Agent-сеансов.

Для выбора Runner используйте рекомендации GitHub по месту выполнения задания. Главный критерий здесь не удобство подключения, а возможность воспроизвести проверку с теми же входными данными.

Сравнение сред и границ ответственности

Самое важное решение — не «какая машина мощнее», а «какой слой имеет право считать результат доказанным». Agent Host может инициировать работу. CI может вернуть проверяемый статус. Mac может подтвердить Apple-специфичную сборку. Ни один слой не должен автоматически присваивать себе полномочия следующего.

Сценарий защищённой ветки

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

Перед включением Agent в рабочий процесс проверьте:

1. Какая учётная запись создаёт ветку и Pull Request.
2. Имеет ли она право только создавать ветки или также менять настройки репозитория.
3. Откуда приходит обязательный статус — из доверенного CI или из локального процесса Agent.
4. Может ли тот же субъект, который изменил код, сам подтвердить результат.
5. Разрешены ли черновые PR и кто переводит их в режим ревью.
6. Как блокируется обход правил при ошибке в интеграции.

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

Сценарий удалённого сеанса

Удалённый Agent Host и облачный Mac решают разные задачи. Рабочую копию, состояние задачи и результат сборки нельзя складывать в одно неопределённое место.

Разделите хранение так:

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

Разрыв соединения с клиентом не доказывает, что задача продолжится после переподключения. Проверьте это отдельно:

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

Для долгой Xcode-задачи нужен отдельный пул или очередь. Не оставляйте такую работу на машине, которая одновременно обслуживает генерацию кода. В документации о самостоятельно размещаемых Runner отдельно учитывайте обслуживание, безопасность и жизненный цикл машины: ваш Mac становится частью цепочки поставки, а не просто удалённым терминалом.

Сценарий параллельных PR

При нескольких Agent-сеансах узкое место часто перемещается от генерации кода к установке зависимостей, тестовой очереди и Mac-сборкам. Ошибка планирования — назначать по одному Mac на каждый Agent. Число сессий не равно числу одновременно выполняемых Xcode-задач.

Собирайте по каждому PR четыре временных показателя:

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

Затем принимайте решение:

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

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

Пошаговое внедрение

1. Опишите типы репозиториев. Отдельно отметьте веб-проекты, серверный код, iOS, macOS и репозитории с релизной подписью.
2. Зафиксируйте границу Agent Host. Разрешите изменение ветки и создание PR, но не выдавайте ему ненужные права на настройки защиты, публикацию и сертификаты.
3. Создайте обязательный CI-процесс. Он должен запускаться после PR, проверять конкретный коммит и сохранять логи с артефактами.
4. Добавьте отдельный Mac Runner. Передавайте ему ветку или SHA коммита, а не текущее состояние сеанса Agent.
5. Разделите тестирование и подпись. Сборка для проверки не должна автоматически получать производственные сертификаты.
6. Определите условия остановки. Отсутствие лога, несоответствие SHA, неполный артефакт и неподтверждённая версия Xcode должны блокировать продвижение.
7. Проверьте восстановление. Смоделируйте отключение клиента, остановку Runner и повторный запуск на том же PR.
8. Наблюдайте за очередью. Считайте ожидание, фактическую работу, повторы и ручные задержки раздельно.
9. Пересмотрите защиту веток. Убедитесь, что статусы приходят от ожидаемых проверок и не могут быть заменены локальным действием Agent.
10. Только затем выбирайте масштаб. Сначала оставьте текущую схему, затем вынесите Mac-сборку или добавьте эластичную ёмкость — в зависимости от измеренного ограничения.

Для команды, которая впервые разделяет эти роли, полезно начать с русскоязычного раздела kvmsync, а затем отдельно сверить модель аренды и доступный формат удалённой работы на странице планов kvmsync. Это не заменяет проектирование CI, но помогает не смешивать вопрос доступа к Mac с вопросом доверия к результату сборки.

Три решения для команды

Сохранить текущую схему. Выбирайте её для низкорискового прототипа, если нет Xcode, подписей, долгих задач, производственных секретов и требования к независимой воспроизводимости. Даже здесь CI должен оставаться источником обязательного статуса.

Вынести Mac-сборку. Это базовый выбор для iOS и macOS. Agent Host создаёт PR, CI проверяет общий код, отдельный Mac запускает Xcode и сохраняет доказательства. Подпись и публикацию следует дополнительно отделить, если артефакт может попасть в производство.

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

Текущая схема с общим Mac удобна, но у неё есть три реальных недостатка: рабочая директория Agent может загрязнять сборку, длительный Xcode-процесс блокирует другие задачи, а общие права подписи затрудняют расследование того, кто именно сформировал релизный артефакт. В таком случае аренда Mac через kvmsync обычно даёт более управляемый путь: вы оставляете генерацию кода в Agent Host, а отдельный Mac используете как изолируемый слой для Xcode и пиковых задач. Если вам нужен временный тестовый контур или дополнительная мощность на период релиза, отметьте в таблице выше текущую границу ответственности и подберите размер пула по фактической очереди, а не по числу Agent-сеансов.

Последняя проверка этой схемы выполнена 20 сентября 2026 года по релизным материалам VS Code 1.138, документации Agent Host и правилам защищённых веток GitHub. При изменении статуса Agent Merge, модели разрешений или возможностей удалённого выполнения проверку PR и Mac-сборки нужно повторить в тех же условиях.