VS Code 1.144 продолжает сеанс разработки за пределами открытого ноутбука

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

VS Code 1.144 вышла как стабильная версия 28 октября 2026 года. Примечания к выпуску объединяют непрерывность сеансов агентов и удалённое управление с функциями, имеющими собственные пометки Preview или Experimental. Облачные сеансы работают на инфраструктуре GitHub, поэтому выполнение может продолжаться, пока ноутбук разработчика отключён от сети. Официальные примечания к выпуску.

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

Официальный снимок экрана Remote Environments в Visual Studio Code 1.144. Used with permission from Microsoft. Источник изображения · Лицензия и сведения об изображении.

Закрыть окно и остановить исполнителя — разные события

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

Обзор Universe от Microsoft от 28 октября описывает Agent Host как независимый процесс, управляющий сеансами, исполнительными оболочками, моделями, файлами и терминалами. В нём сказано, что Agent Host Protocol достиг версии 1.0 и подключает клиентов к сохраняющемуся состоянию сеанса. Это полезное архитектурное различие для оценки того, что на самом деле означает «продолжать работу».

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

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

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

Авторское объяснение разделения ответственности клиента и хоста на основе обзора VS Code Universe. Это упрощённая модель планирования, а не сетевая топология.

AHP синхронизирует сеанс, на который смотрят интерфейсы

Официальный сайт Agent Host Protocol, проверенный 2 ноября, описывает AHP как двунаправленный протокол отображения, основанный на состоянии. Клиенты работают с общим состоянием сеанса; хост рассылает действия и разрешает конфликты. Повторное подключение может доставить пропущенные действия или текущий снимок, чтобы интерфейс догнал актуальное состояние.

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

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

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

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

Стабильный выпуск и предварительная функция — отдельные обозначения

Страница VS Code 1.144 обозначает выпуск как Stable, тогда как Cloud Automations, генерация изображений и коннекторы Copilot сохраняют пометки Preview; управление компьютером и функции рабочего набора отмечены Experimental. Облачным сеансам нужен платный тариф Copilot, и на них распространяются правила организации. Статус выпуска и функций, 28 октября, проверено 2 ноября.

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

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

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

Три иллюстративные задачи показывают, где помогает непрерывность

Разработчик может передать ограниченное исправление и проверить его позже

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

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

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

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

Сопровождающий может исследовать отдельные проблемы, не смешивая файлы

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

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

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

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

Команда может испытать повторяющуюся облачную задачу до доверия расписанию

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

Статус Preview у Cloud Automations важен здесь, потому что повторяющаяся работа добавляет операционную ответственность. Задаче, приемлемо выполнившейся один раз, ещё могут потребоваться ограничения частоты, ответственный и ясная реакция на сбой до запуска по расписанию. Проверяйте эти требования отдельно от качества языкового ответа.

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

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

Незакоммиченная работа требует явной передачи

Примечания к выпуску 1.144 указывают, что облачные сеансы используют отдельное рабочее пространство и не копируют локальные незакоммиченные изменения автоматически. Из окна Chat или Agents пользователь может выбрать Cloud, указать репозиторий GitHub, отправлять уточнения, отвечать на запросы разрешений и проверять изменения; существующие сеансы можно вновь открыть из списка. Инструкции облачных сеансов.

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

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

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

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

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

Десятиминутная экскурсия доказывает меньше, чем одна полная задача

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

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

1. Обновите приложение и проверьте установленный выпуск. Используйте проверку обновлений VS Code и подтвердите версию. Изучите пометки отдельных функций в официальных примечаниях.
2. Выберите разрешённую среду выполнения. Подтвердите доступ к репозиторию, соответствие тарифу и правила организации. Решите, относится ли задача к локальному, удалённому или облачному хосту.
3. Запишите исходное состояние. Отметьте репозиторий и ревизию. Сохраните локальные изменения и определите входные материалы, нужные выбранному пространству.
4. Дайте ограниченную инструкцию. Назовите желаемое поведение, объём и команду проверки. Определите материал, который ожидаете проверять.
5. Испытайте передачу. Покиньте клиент и подключитесь снова через доступный поддерживаемый интерфейс. Проверьте статус того же сеанса, ожидающие разрешения и новую работу.
6. Вернитесь к коду. Изучите изменения и доказательства проверки. Подтвердите, что проверки относятся к рассматриваемой ревизии.
7. Запишите результат и оставшиеся ограничения. Разделяйте успешное подключение, завершённую задачу и принятое изменение. Это связанные этапы с разными доказательствами.

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

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

Постоянный сеанс должен облегчать понимание ответственности

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

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

Источники

• Примечания к выпуску Visual Studio Code 1.144, стабильный выпуск 28 октября 2026 года; проверено 2 ноября 2026 года.
• VS Code Wrapped: GitHub Universe 2026, 28 октября 2026 года.
• Microsoft Agent Host Protocol, спецификация v1.0.0 и обзор общего состояния, проверено 2 ноября 2026 года.

Сохраняйте материалы, на которых основано решение

Telli.sh — один из вариантов хранения разрешённых исходных материалов рядом с проверенными вами заметками. Создать пространство заметок.