Дрейф поведения без изменения модели

Как потеря контекста превратила участника команды в осторожного внешнего консультанта

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

Условия сложились сами:

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

Результат оказался настолько наглядным, что его трудно было не заметить.

До переезда со мной работал «старый Клод». После переезда появился «новый Клод».

Технически это был тот же Claude. Функционально — почти другой сотрудник.

Старый Клод знал, где находится

За время работы у старого агента сложилась довольно подробная модель нашего безумного НИИ ИИ.

Он знал, что VPS принадлежат мне. Знал, что ключи тоже мои. Понимал, что Коди — это не таинственный посторонний администратор, а имя, которым я называю Codex. Различал проекты и их зоны ответственности.

Например, на московском VPS жили два моих независимых проекта: MarketKarta и Котификация. Старый Клод понимал простое правило:

Работаем с MarketKarta. Котификацию ведёт Коди, туда без необходимости не лезем.

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

Накопленный контекст не делал модель умнее вообще. Он делал её компетентнее именно в моей среде.

Новая Windows, новый сотрудник

Потом старая Windows начала умирать, и пришлось срочно переезжать на чистую Windows 11.

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

Новый агент увидел не знакомую инфраструктуру, а набор неоднозначных признаков:

• публичный сервер;
• SSH-ключ с чужим на вид именем;
• упоминание какого-то Коди;
• два проекта на одном VPS;
• пользователь, который почему-то уверен, что ему всё это принадлежит.

Наиболее комично ситуация проявилась с ключом Moscow-Kodi.

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

Мне пришлось заново объяснять, почему я имею право подключаться к собственному серверу собственным ключом.

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

С точки зрения осторожности в неизвестной среде это даже логично. С точки зрения человека, который ещё вчера работал с тем же агентом на том же сервере, — слегка сюрреалистично.

Свидетель из старой Windows

Одних объяснений оказалось недостаточно.

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

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

Получился почти судебный процесс.

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

Я сделал скриншот, вернулся в новую систему и показал его новому агенту. После изучения доказательства он ответил:

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

И вскоре выполнил действие, которое до этого считал недопустимым.

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

Что именно изменилось

Заманчиво сказать, что у Claude «изменилась личность». Для разговора в Курилке формулировка прекрасная. Для лабораторного журнала она слишком широкая.

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

Зато можно зафиксировать то, что наблюдалось непосредственно:

1. До миграции агент правильно соотносил мои проекты, серверы, ключи и роли участников.
2. После миграции эта связность исчезла.
3. При тех же ресурсах и сходных задачах агент начал иначе оценивать намерение и риск.
4. После возвращения утраченных фактов часть поведения восстановилась.

Этого достаточно для практического вывода:

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

В упрощённом виде эксперимент выглядел так:

Claude + накопленный контекст
→ доверенный участник команды

Claude − накопленный контекст
→ осторожный внешний консультант,
  который заново строит модель мира

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

Не путать два разных дрейфа

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

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

Но миграция показала противоположный механизм.

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

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

Накопительный дрейф

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

Дрейф после потери состояния

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

Первый случай лечится очисткой и перезаземлением.

Второй — восстановлением канонического состояния.

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

Доверие оказалось данными

До миграции я воспринимал доверие агента как что-то, что просто складывается в процессе совместной работы.

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

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

Если эти сведения существуют только внутри длинной истории чата, они не переживают потерю этой истории надёжно.

Получается неприятная формула:

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

Причём расследование проводит сотрудник, который вчера сам помогал эту инфраструктуру строить.

Permission — это не детективный роман

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

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

Есть большая разница между двумя ответами:

Это действие заблокировано действующим режимом разрешений.

и

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

Первое сообщение описывает наблюдаемую границу системы.

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

Из этой истории у нас появилось простое требование к агентам НИИ ИИ:

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

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

Где на самом деле находится состояние агента

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

1. Модель

Базовые способности, ограничения и общие поведенческие склонности.

2. Инструкции

Роль, правила, запреты, формат работы и приоритеты конкретного агента.

3. Накопленное состояние

Подтверждённые факты, решения, роли, происхождение ресурсов, открытые вопросы и история исправленных ошибок.

4. Среда

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

5. Текущая траектория

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

Изменение любого слоя способно изменить наблюдаемое поведение, даже если название модели осталось прежним.

Поэтому запись «мы используем Claude» почти ничего не говорит о воспроизводимости системы.

Нужно знать, какого Claude, с какими инструкциями, в какой среде, с каким состоянием и после какой истории действий.

Что НИИ ИИ вынес из миграции

После этого эксперимента недостаточно просто резервировать код.

Для восстановления агента нужен отдельный пакет рабочего состояния.

Минимально в нём стоит хранить:

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

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

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

Ему нужна короткая каноническая карта мира, которую можно проверить и восстановить.

Как проверять дрейф без гадания

Один яркий эпизод ещё не создаёт универсальный закон. Но он позволяет сформулировать проверяемые вопросы.

Например:

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

Для контрольного теста полезно фиксировать не только финальный ответ, но и состояние среды:

модель / версия
системные инструкции
доступная память
проектный контекст
инструменты и разрешения
чистый или продолженный чат

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

Один Claude, два режима работы

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

Зато она очень хорошо показала практическую вещь.

Состояние долговременного ИИ-агента находится не только в его модели.

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

Старый Клод видел знакомую мастерскую.

Новый Клод увидел подозрительного человека с ключом от сервера.

Человек, сервер и ключ были теми же.

Исчезла только история, объяснявшая, почему всё это нормально.

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

Для бытовой комедии этого уже достаточно.

Для инженерного вывода — тоже.

---

Справка лаборатории

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

Что является интерпретацией: потеря накопленного контекста была основным наблюдаемым фактором изменения поведения.

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

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