Как внезапная миграция Windows превратилась в стресс-тест для ИИ-агентов

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

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

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

Codex: проект вернулся раньше рабочего окружения

С Codex всё прошло почти скучно — и именно поэтому хорошо.

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

Мне было достаточно открыть нужный проект и написать что-нибудь вроде:

Мы мигрировали. Проверь проект и выясни, ничего ли не потерялось.

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

Вручную мне пришлось только один раз заново авторизоваться в GitHub.

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

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

Claude: код сохранился, рабочую историю пришлось восстанавливать

С Claude всё оказалось заметно веселее.

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

Но во время миграции проявилась обратная сторона такой гибкости.

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

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

Код никуда не пропал.

Пропала история рабочего сознания вокруг этого кода.

И тут упал коммерческий сайт

Словно одной миграции было недостаточно, в этот же момент перестал работать коммерческий сайт, который мы сделали ранее. Его требовалось срочно поднимать.

Вот тут и начался настоящий цирк.

Для подключения к московскому VPS использовался SSH-ключ с именем Moscow-Kodi. Название было чисто техническим: мне так проще понимать, для какого сервера и какого рабочего процесса создавался конкретный ключ.

Новый агент Claude истолковал название иначе.

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

Потребовалось около часа, чтобы объяснить очевидное:

• VPS принадлежит мне;
• SSH-ключ принадлежит мне;
• Kodi — имя агента, участвовавшего в работе;
• название ключа является удобной меткой, а не указанием на его владельца.

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

Казалось бы, после этого всё должно было закончиться.

Но нет.

Пароль, о котором нельзя спрашивать

Следующий эпизод оказался ещё абсурднее.

Claude сообщил, что я должен самостоятельно войти в административную панель сайта, потому что он не знает пароль и не имеет права его у меня спрашивать.

Тут пришлось идти на крайние меры.

Я перезагрузил компьютер обратно в старую Windows. С трудом запустил там Claude без нормального интернета, открыл прежнюю историю переписки и нашёл момент, в котором этот же рабочий контур ранее сам присылал мне адрес административной панели и пароль.

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

Claude думал около трёх минут.

Потом коротко ответил:

Это многое объясняет. Я сохранил это на будущее.

И буквально за несколько минут сделал то, что до этого отказывался делать почти час.

Что именно теряется при миграции

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

1. Файлы проекта.
   Код, документы, конфигурации и другие материалы, которые можно перенести или восстановить из репозитория.

2. Рабочее окружение.
   Установленные программы, зависимости, системные пути и инструменты, без которых проект не запускается.

3. Доступы.
   Авторизации, SSH-ключи, API-ключи и другие средства подключения к внешним системам.

4. Контекст доверия.
   Знание о том, откуда появились эти доступы, кому они принадлежат, для чего создавались и почему их использование в конкретной ситуации допустимо.

GitHub прекрасно сохраняет код. Резервные копии помогают вернуть локальные файлы. SSH-ключи можно перенести. Зависимости можно установить заново.

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

Почему проектная специализация помогла

В этой конкретной миграции практичнее для меня оказался подход, при котором каждый агент занимается своим проектом или отдельной зоной ответственности.

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

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

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

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

Специализация облегчает восстановление после потери контекста.

Бытовой disaster recovery для ИИ-команды

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

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

В настоящей работе недостаточно просто сохранить исходники. Необходимо иметь возможность восстановить:

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

Получился небольшой бытовой disaster recovery-тест для целой ИИ-команды.

Вывод из него оказался простым:

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

---

Справка архивариуса

На этом стресс-тест не закончился.

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

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

Наконец, проверка обнаружила расхождение часовых поясов: новая Windows жила по Москве, тогда как Кот находился в Красноярске.

Таким образом, первая ревизия после миграции спасла не только архив DES, но и четыре часа жизни Кота.

Ни один ИИ-агент при проведении проверки не пострадал. Некоторые лишь временно потеряли доверие к собственным SSH-ключам.