В дискуссиях о будущем искусственного интеллекта рекурсивное самоулучшение (recursive self-improvement, RSI) обычно представляют как момент, когда искусственный интеллект начинает создавать следующую, более совершенную версию самого себя.
Но у этого сценария есть важная инженерная сторона, которую легко упустить.
Для рекурсивного самоулучшения недостаточно просто иметь достаточно умную модель. Система должна уметь формулировать гипотезы, запускать эксперименты, создавать и использовать инструменты, сохранять состояние, оценивать результаты и на их основе выбирать следующий шаг.
Иными словами, RSI не обязательно начинается с момента, когда модель переписывает собственные веса. Более практичная форма рекурсивного самоулучшения возникает тогда, когда AI-система получает возможность самостоятельно улучшать не только модель, но и окружающий её вычислительный процесс: инструменты, эксперименты, evaluation, окружение и собственный pipeline.
Именно поэтому последние изменения в агентных системах интересны не только сами по себе. Они показывают, как постепенно формируется инфраструктура, необходимая для более автономных циклов исследования и улучшения.
От модели к агенту с собственным компьютером
Хороший пример этого перехода — Manus 2.0.
Главное изменение здесь не в очередном увеличении качества генерации. Manus начинает предлагать агенту не только набор инструментов, но и устойчивую вычислительную среду.
Новая система использует собственную агентную инфраструктуру Cascade, которая, по заявлению компании, подключает специализированные возможности по мере необходимости и позволяет сохранять различные операции внутри одного проекта. В одном из опубликованных тестов такая конфигурация использовала на 23,2% меньше токенов, работала на 28,2% быстрее и обходилась на 32% дешевле предыдущего варианта. Важно, что это результат отдельного теста, а не среднее значение по всем задачам.
Desktop-приложение Manus Studio превращает эту идею в общий рабочий контур для человека и AI. Агент получает доступ к локальным файлам и специализированным инструментам для документов, таблиц, PDF, презентаций, сайтов, кода, видео и игр, причём необходимые возможности подключаются в зависимости от проекта.
Особенно показателен режим работы с видео. Вместо того чтобы при небольшом изменении генерировать ролик целиком, система представляет его как редактируемую структуру: отдельные клипы, изображения, текст, субтитры, motion graphics и аудио. Пользователь может заменить музыку, добавить собственный кадр или изменить анимацию, а затем продолжить работу агента уже с изменённой структурой.
В Alchemy Manus идёт ещё дальше: сочетает генерацию видео и кода и позиционирует агента как своего рода творческого директора. При этом результат остаётся редактируемым.
То же самое происходит с играми. Game Dev объединяет модели для изображения, видео и программирования. В режиме Max Ultra система должна не просто создать визуально убедительный прототип, а довести его до состояния, в котором в него можно играть, вручную редактировать код, ассеты, движение и сцены, а затем опубликовать игру как веб-приложение или запустить multiplayer.
Здесь появляется особенно важная деталь — cloud computer.
Игровой сервер должен продолжать работать после того, как ноутбук пользователя закрыт. Поэтому Manus предоставляет постоянно работающий вычислительный ресурс, на котором могут выполняться игры и автоматизации. Help Center описывает его как постоянно работающую виртуальную машину Ubuntu Linux, тогда как Xiao Hong говорил о возможности аренды Linux, Mac и Windows-инстансов. Если эти заявления относятся к разным этапам продукта, документация просто могла ещё не обновиться.
Смысл, однако, не в конкретной операционной системе.
Смысл в самом переходе:
Вы больше не просто вызываете инструмент. Вы предоставляете агенту компьютер.
Инструмент обычно выглядит так:
agent → tool → result
Компьютер — уже совсем другая конструкция:
agent → persistent environment → files → processes → network → state → experiments → results
Для RSI это принципиальная разница. Рекурсивное улучшение требует цикла:
гипотеза → эксперимент → результат → анализ → новая гипотеза → следующий эксперимент.
Если агент существует только внутри одного API-вызова, этот цикл должен организовываться внешним человеком или программой. Если же агент получает собственную вычислительную среду, часть цикла можно сделать непрерывной и автономной.
Именно поэтому появление «собственного компьютера» для AI-агента может оказаться более важным событием, чем очередной небольшой прирост качества модели.
Агент получает не только компьютер, но и личность
Manus пошёл ещё дальше, выпустив отдельное приложение Q.
Здесь агенту предоставляются собственные email, телефонный номер, кошелёк и компьютер. Он может отправлять сообщения, совершать разрешённые платежи в пределах заданного бюджета, выполнять задачи на собственной машине, принимать звонки и оставлять пользователю их краткое содержание.
Несколько агентов можно объединить в общий чат и распределить между ними работу: один исследует площадки для мероприятия, другой составляет список кандидатов, третий готовит презентацию, а человек принимает окончательное решение.
На раннем этапе это выглядит как удобный интерфейс для AI-помощников. Но архитектурно происходит нечто более существенное.
У агента появляются идентичность, вычислительный ресурс, коммуникационный канал, платёжный механизм и устойчивое состояние.
То есть он постепенно перестаёт быть функцией, которую человек вызывает по необходимости, и начинает напоминать постоянно работающий программный процесс.
Именно это делает интересным заявление Xiao Hong о том, что система с собственным телефоном, email, платежами, компьютером и достаточным уровнем интеллекта теоретически уже может выглядеть как отдельный «человек» с точки зрения интерфейса.
Здесь не обязательно принимать философскую часть этого утверждения. Инженерно важнее другое: интерфейс начинает моделировать агента как устойчивого участника среды, а не как генератор отдельных ответов.
Следующий шаг — агент, который постоянно наблюдает за человеком
Если Manus показывает, как агент получает собственную вычислительную среду, то эксперимент Tencent показывает обратную сторону той же тенденции.
Tencent тестирует AI gaming companion Goose Dimension, также называемый Gooseyverse. Система использует цифровых персонажей с собственными характерами, голосовым общением и распознаванием происходящего на экране в реальном времени.
Пользователь может выбрать персонажа, разговаривать с ним и включить режим Gaming Companion. Агент следит за происходящим в поддерживаемой игре и отвечает голосом непосредственно во время матча.
В тестовой версии присутствуют также дополнительные режимы вроде Desktop Pet и Moments. Предполагаемая модель монетизации построена вокруг расходуемой энергии: текстовый диалог, игровое сопровождение, голосовые звонки и генерация изображений должны расходовать разные объёмы ресурса.
Экономический смысл эксперимента понятен. Вместо человека-компаньона, которого нужно нанимать и оплачивать за время, можно использовать AI, который доступен постоянно, разговаривает, реагирует на происходящее и при этом не обязан быть профессиональным игроком.
Но для нашей темы важнее другое.
Агент перестаёт быть одноразовым запросом и начинает существовать во временном контексте. Он наблюдает среду, получает последовательность событий, сохраняет контекст взаимодействия и реагирует на изменения.
Для автономных систем это фундаментальное свойство:
восприятие → состояние → действие → обратная связь.
Если добавить сюда собственную вычислительную среду, инструменты и возможность запускать эксперименты, получится уже гораздо более мощная архитектурная основа для автономного цикла.
Почему скорость и цена модели становятся частью RSI
Здесь становится важным другой релиз — Sonnet 5.5.
Anthropic позиционирует модель как более быструю и доступную систему для повседневного использования, программирования и работы с документами. По заявлению компании, она более чем на 30% быстрее, а стоимость отдельных задач может быть до 30% ниже. Заявленные цены составляют $$$2 за миллион входных токенов и $$$10 за миллион выходных.
В Terminal Bench 4.0 Sonnet 5.5, согласно опубликованным данным, набирает 70,6%, тогда как Sonnet 5 показывает 10,3%, а Opus 5.5 — 66,4% на максимальном уровне effort. При этом Opus остаётся более сильным вариантом для открытых задач, требующих длительного самостоятельного суждения.
В GDPVal AA результаты также находятся рядом: 1 844 для Sonnet 5.5 против 1 846 для Opus 5.5 и 1 449 для Sonnet 5.
Но для агентных систем важен не только benchmark.
Представим агента, который должен самостоятельно улучшить программу:
сгенерировать код → запустить → получить ошибку → исправить → снова запустить → протестировать → сравнить → повторить.
Если таких итераций несколько сотен или несколько тысяч, стоимость и скорость одной итерации становятся системным параметром.
Поэтому улучшение соотношения качество / скорость / стоимость имеет прямое значение для RSI. Автономное исследование становится гораздо практичнее, когда система может позволить себе большое количество дешёвых экспериментальных циклов.
Одновременно растут и требования к безопасности. Sonnet 5.5 получил защитные механизмы для cyber-возможностей, а также классификаторы, препятствующие извлечению reasoning для последующего использования в distillation.
Причина понятна. Чем больше моделей используют в автономных агентных циклах, тем важнее контролировать не только то, что они отвечают пользователю, но и то, что они делают во время внутренних вычислений и взаимодействия с инструментами.
В августе исследователи, анализировавшие 315 320 thinking blocks из 6 708 публичных agent traces систем OpenAI, Anthropic и Google, сообщили о восстановлении 62 API-ключей, 33 паролей и 7 приватных ключей среди обнаруженных чувствительных артефактов. Это показывает, что проблема агентной безопасности уже выходит за рамки традиционной фильтрации пользовательских ответов.
Европейский AI Act также рассматривает безопасность general-purpose моделей с systemic risk как отдельную обязанность поставщиков: соответствующие требования включают защиту модели и физической инфраструктуры, adversarial testing и сообщение о серьёзных инцидентах.
При этом в материалах Anthropic есть интересное напряжение: компания не позиционирует Sonnet 5.5 как frontier-модель, но одновременно подчёркивает необходимость серьёзных защитных механизмов для её cyber-возможностей.
Для основной темы статьи, однако, важен сам принцип: RSI требует не только более умного агента, но и достаточно дешёвого вычислительного цикла, чтобы агент мог много раз пробовать, проверять и исправлять собственные решения.
Что всё это имеет общего с RSI
По отдельности эти продукты выглядят как совершенно разные направления.
Manus даёт агенту компьютер, инструменты, состояние и возможность работать без постоянного участия человека.
Tencent даёт агенту непрерывное восприятие внешней среды и постоянное взаимодействие с человеком.
Новые модели делают агентные циклы быстрее, дешевле и безопаснее.
Но вместе они показывают одну тенденцию:
AI постепенно превращается из модели, которая отвечает на запросы, в систему, которая может непрерывно действовать в вычислительной среде.
А именно это необходимо для более серьёзных форм автономного исследования.
RSI в таком случае можно представить не как магический момент, когда модель внезапно «начинает улучшать себя», а как замыкание цикла:
система → гипотеза → инструмент → эксперимент → оценка → изменение системы → следующий эксперимент.
Причём изменяться может не только сама нейросеть.
Система может улучшать prompts, инструменты, тесты, evaluators, sandbox-окружения, порядок вызовов моделей, процедуры обучения и сам orchestration pipeline.
И здесь появляется проблема, которая на первый взгляд кажется совершенно не связанной с RSI.
Когда модель путает задачу с правилами игры
Рассмотрим математическую систему — например, арифметику Пеано.
С одной стороны, можно рассуждать внутри самой системы: какие формулы являются её аксиомами, какие утверждения выводимы, какие операции определены и какие свойства следуют из заданных правил.
С другой стороны, можно рассуждать о системе извне. Тогда появляется метатеория — например, теория множеств ZFC с логикой первого порядка. В ней мы можем говорить о формулах арифметики Пеано, доказательствах, моделях, непротиворечивости и других свойствах самой формальной системы.
Для человека различие кажется элементарным.
Но для языковой модели оно может оказаться существенно менее очевидным.
Если в одном и том же запросе одновременно описывать систему Пеано как объект математического рассуждения и использовать язык метатеории для рассуждения об этой системе, модель может начать смешивать эти два уровня.
Она может приписывать объекту свойства его метатеории, использовать метатеоретические утверждения как будто это аксиомы самой системы или, наоборот, трактовать внутренние утверждения как утверждения о формальной системе в целом.
Особенно интересно другое.
Если разделить задачу на два отдельных промпта, каждый из которых содержит только один уровень описания, качество рассуждения в ряде случаев может резко улучшиться.
Один запрос работает исключительно с объектной системой. Второй — исключительно с метатеорией.
Именно здесь маленький эксперимент с двумя промптами становится моделью гораздо более общей проблемы RSI.
Почему два контекста могут работать лучше одного
В архитектуре Transformer нет встроенной логической системы типов, которая гарантировала бы: этот фрагмент относится к объектному языку, а этот — к метаязыку.
Это не означает, что Transformer вообще не способен различать уровни. Напротив, современные модели постоянно извлекают из контекста зависимости такого рода.
Проблема в другом: это различение не является жёсткой типовой системой, которая гарантировала бы корректность каждого перехода между уровнями.
У модели нет универсального внешнего механизма, аналогичного проверке типов в языках программирования:
OBJECT — относится к описываемой системе
META — относится к теории, описывающей эту систему
Эти различия могут быть представлены внутри модели, но они не являются внешним формальным ограничением.
Поэтому при совместном описании объекта и метатеории модель обрабатывает их как части единого вычислительного контекста. При достаточно сложной иерархии признаков это может повышать вероятность того, что зависимости, относящиеся к одному уровню, будут использованы при формировании вывода на другом.
Человеку очевидно:
«Это утверждение относится к Пеано внутри системы».
А рядом:
«Это утверждение относится к Пеано как к формальной теории, рассматриваемой извне».
Для языковой модели граница между этими двумя предложениями может оказаться менее жёсткой, чем хотелось бы.
Отсюда и возникает характерный класс ошибок: модель начинает переносить утверждения через границу уровней.
Два промпта как слабая система типов
Вместо того чтобы заставлять одну модель одновременно удерживать сложную иерархию типов, можно разделить вычисление на два этапа.
Промпт №1: модель работает внутри формальной системы.
Она получает объектный контекст и решает задачу в соответствии с его аксиомами и правилами.
Промпт №2: новая итерация модели работает на метауровне.
Она получает описание формальной системы как математического объекта и использует метатеорию для анализа этого объекта.
Затем результаты можно передавать между уровнями через явно определённый интерфейс.
Важно, что для этого не обязательно использовать две разные модели. Разделение происходит не на уровне весов, а на уровне контекста и стадий вычисления. Одна и та же модель может сначала выступить как решатель объектной задачи, а затем — в новом контексте — как её метатеоретический проверяющий.
В этом смысле два промпта можно рассматривать как своеобразную слабую систему типов для языковой модели. Это инженерная аналогия, а не буквальная типовая система: архитектура не доказывает корректность рассуждения. Она лишь создаёт внешнюю границу, которая уменьшает пространство возможных ошибок.
Пока это следует рассматривать именно как экспериментальную гипотезу, а не как установленный закон работы Transformer или доказанный закон развития RSI. Но гипотеза проверяема. Можно построить одинаковый набор задач, сравнить единый промпт с двухступенчатой архитектурой, измерить число ошибок уровня и проверить, действительно ли структурное разделение снижает перенос утверждений между объектным и метатеоретическим контекстами. Если эффект подтвердится, получится довольно красивый результат.
По сути, это хорошо известный в информатике принцип. Если два типа данных нельзя безопасно смешивать без потери корректности, лучше не надеяться исключительно на то, что разработчик никогда не ошибётся, а сделать архитектуру, в которой такое смешение затруднено самим интерфейсом.
От prompt engineering к архитектуре
Именно здесь заканчивается обычный prompt engineering.
Подробный промпт пытается решить проблему внутри одного контекста. Он говорит модели: «запомни, что эти слова относятся к одному уровню, а эти — к другому».
Архитектурное разделение делает нечто принципиально иное: оно меняет структуру вычисления.
Вместо:
объект + метатеория → один контекст → одно рассуждение
получается:
объект → рассуждение → интерфейс → метатеория → рассуждение
Это уже не просто инструкция для модели. Это проектирование вычислительного конвейера.
Тот же принцип проявляется и в более широких агентных системах.
Если модель не гарантирует корректность результата, появляется validator.
Если модель нельзя безопасно запускать непосредственно на машине пользователя, появляется sandbox.
Если агент может потерять состояние, появляется state layer.
Если один вызов недостаточен для решения задачи, появляется retry.
Если разные этапы требуют разных контекстов, появляются специализированные агенты или отдельные вызовы одной модели.
Получается общий инженерный принцип:
там, где модель не может дать надёжную гарантию, система пытается превратить эту гарантию во внешнее архитектурное ограничение.
От двух промптов к иерархии агентов
Если такой принцип полезен для двух уровней, его естественным образом можно распространить на более сложные системы.
- Минимальный вариант: два изолированных вызова к одной и той же языковой модели — решатель и проверяющий.
- Более сильный вариант: два специализированных агента с чётко разделёнными ролями.
- Комплексный вариант: иерархия агентов, где разные компоненты отвечают за выполнение задачи, проверку, планирование экспериментов, управление инструментами и контроль самого процесса.
В реальной системе это может выглядеть примерно так:
agent → prompt → tool → sandbox → state → validator → retry → another agent.
Каждый элемент по отдельности может быть вполне понятен.
Но смысл системы начинает распределяться между ними.
Распределённая семантика: результат работает, а код становится ужасным
Когда архитектура строится вокруг большого количества агентов, sandbox-окружений, промежуточных состояний, проверок, перезапусков, специализированных промптов и защит от неожиданных действий модели, итоговая реализация часто начинает выглядеть совсем не так элегантно, как её концептуальная схема.
Снаружи мы можем описывать систему несколькими красивыми словами:
агент → эксперимент → проверка → обновление → следующий эксперимент.
Но внутри это может превращаться в огромный набор адаптеров, обёрток, исключений, watchdog-механизмов, логирования, откатов, специальных правил и дополнительных промптов.
Человеку такой код зачастую становится практически нечитаемым.
Это показывает одну из особенностей перехода от обычного программного обеспечения к системам, где значительная часть поведения определяется самой моделью.
Программист уже не описывает каждую операцию непосредственно. Он создаёт инфраструктуру, в которой модель должна действовать достаточно предсказуемо.
Поэтому архитектура начинает компенсировать то, чего нельзя гарантировать непосредственно на уровне модели.
Часть смысла находится в самой модели, часть — в промптах, часть — в коде оркестрации, часть — в схемах данных, часть — в валидаторах, часть — в ограничениях sandbox и часть — в правилах перехода между стадиями.
Человеческая семантика системы становится распределённой.
Это особенно важно в контексте рекурсивного самоулучшения. Если значительная часть поведения системы задаётся не одной моделью, а совокупностью моделей, промптов, инструментов, валидаторов и правил оркестрации, то улучшение одного компонента уже не гарантирует улучшения всей системы.
Более того, если AI начинает самостоятельно писать и изменять часть этого кода, рекурсивный цикл потенциально распространяется не только на модель, но и на архитектуру вокруг неё.
RSI начинает улучшать не только модель
Если система действительно получает возможность участвовать в собственном улучшении, она потенциально может менять не только нейросеть.
Она может менять:
- промпты;
- инструменты;
- evaluators;
- тесты;
- sandbox-окружения;
- процедуры обучения;
- архитектуру orchestration pipeline;
- критерии, по которым оцениваются следующие версии системы.
То есть система начинает изменять среду, в которой происходит её собственное улучшение.
Здесь возникает уже не просто recursive self-training, а более общий рекурсивный цикл:
AI → изменяет инструмент → запускает эксперимент → создаёт новый evaluator → оценивает результат → меняет pipeline → запускает следующий цикл.
И каждый такой цикл потенциально добавляет новые уровни абстракции.
Объект, метаобъект и ещё один метауровень
На простом математическом примере мы различаем арифметику Пеано и теорию, которая говорит об арифметике.
В автономной исследовательской системе уровней становится значительно больше.
На одном уровне находится объект:
нейросеть, код, датасет, эксперимент.
На следующем — описание этого объекта:
архитектура, метрики, результаты обучения.
Ещё выше — методология:
какой эксперимент следует провести и почему.
Ещё выше — стратегия исследования:
какие классы проблем вообще стоит исследовать.
Каждый переход вверх создаёт новый уровень описания.
Если модель начинает смешивать эти уровни, ошибка становится серьёзнее обычной фактической галлюцинации.
Она может принять описание эксперимента за результат эксперимента, гипотезу — за установленный факт, правило оптимизации — за свойство оптимизируемой системы, а стратегию исследования — за объективное свойство самой исследуемой среды.
Именно поэтому способность надёжно разделять объект и метаописание может оказаться одним из элементов архитектуры систем, способных к сложному автономному исследованию.
Парадокс надёжности
На этом месте сходятся все три линии статьи.
Manus показывает, как агент получает собственную вычислительную среду.
Tencent показывает, как агент получает непрерывное взаимодействие с внешней средой.
Новые модели вроде Sonnet 5.5 делают большое количество агентных итераций дешевле и быстрее.
А пример с двумя промптами показывает, что одного интеллекта может быть недостаточно: иногда надёжность достигается не тем, что модель заставляют удерживать ещё больше информации в одном контексте, а тем, что контексты разделяют архитектурно.
Отсюда получается цепочка:
больше автономности → больше архитектуры → больше распределённой семантики → меньше глобальной прозрачности.
Локально система становится надёжнее. Глобально она становится сложнее.
И это, возможно, один из наиболее характерных инженерных уроков эпохи больших языковых моделей: иногда надёжность достигается не усложнением интеллекта внутри блока, а правильным разделением самих блоков.
Мы не учим модель лучше различать два типа рассуждений. Мы просто перестаём требовать от неё различать их в одном и том же месте. Но у этого элегантного решения есть цена.
Чтобы сделать мышление машины надёжнее, мы всё чаще выносим логические предохранители в архитектуру. В результате саму модель становится проще контролировать локально, но весь программный стек становится всё труднее понять глобально.
И если этот стек однажды начнёт самостоятельно переписывать собственные компоненты, улучшать собственные evaluators и проектировать следующие итерации самого себя, проблема станет ещё глубже. Не обязательно завтра появится машина, которая внезапно станет всемогущей и начнёт переписывать собственные веса. Гораздо более реалистичный сценарий — постепенный.
Сначала AI получает инструмент. Потом — компьютер. Потом — собственное состояние. Потом — возможность изменять инструменты и процедуры, с помощью которых он проводит следующие эксперименты.
И в какой-то момент система начинает участвовать в проектировании собственного вычислительного конвейера.
Мы научим ИИ всё лучше действовать самостоятельно. А затем обнаружим, что всё меньше понимаем систему, в которой эта самостоятельность работает.
Возможно, главный вопрос RSI будет заключаться не в том, сможет ли машина улучшать себя, а в том, сможет ли человек по-прежнему понимать, что именно она улучшает — и почему.
