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

Аннотация

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

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

Pₜ = (Iₜ, Mₜ, Bₜ)

Здесь Iₜ — архитектурно заданная идентичность агента, Mₜ — его приватная долговременная память, а Bₜ — версионируемое программное тело. Иными словами, модель и инфраструктура могут меняться, но «ядро личности» агента, его история и кодовая родословная остаются под контролем.

Среда развертывания описывается отдельно:

Eₜ = (Rₜ, Hₜ, Dₜ)

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

Aₜ = Pₜ ▷ (Eₜ, Sₜ)

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

Инварианты непрерывности и протокол миграции

Работа формулирует шесть инвариантов непрерывности и предлагает последовательность миграции: quiesce → checkpoint → validate → bind → rehydrate → resume. Агент сначала переводится в согласованное состояние, затем создаётся контрольная точка, данные проверяются, привязываются к новой среде, восстанавливаются и только после этого выполнение продолжается.

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

Реализация Enoch

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

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

Проверка и ограничения

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

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

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

Материалы

• Страница статьи на arXiv
• PDF-версия статьи
• Эталонная реализация Enoch и связанные артефакты

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