Exo: агент, который переписывает сам себя

Ещё год назад разговоры о прогрессе ИИ сводились к весам модели: побольше данных, побольше GPU, потоньше файнтюнинг. Сегодня фокус сместился на харнесс — обвязку, которая решает, что модель видит в контексте и что ей разрешено делать. В свежем эпизоде Latent Space исследователь UC Berkeley Алекс Кренцель (вместе с Мартином Касадо и Анкуром Гояла из Braintrust) представил проект Exo — агента, который не просто использует харнесс, а умеет его переписывать сам, на лету, без участия человека.

Почему харнесс важнее весов

Кренцель определяет агента предельно конкретно: это вызов LLM, обёрнутый в машинерию сборки контекста и исполнения действий. Всё, что решает, сколько сообщений истории включить, как делать компакцию, какие skills и tools подключить — он называет policy. Именно policy, а не веса модели, определяет, насколько агент эффективен и дёшев в конкретной задаче. OpenClaw, по мнению Кренцеля, нащупал только часть этой идеи: он даёт человеку точки расширения — память, skills, tools, — но сам код харнесса остаётся неприкосновенным. Exo идёт дальше и делает изменяемым буквально всё.

Как устроено рекурсивное самоулучшение агента

Ядро идеи — жёсткое разделение архитектуры на три слоя. Executive — полностью stateless процесс, в котором живёт вся policy: промпты, tools, skills, логика сборки контекста. Exo harness — защищённое состояние: история диалога, секреты и API-ключи, снапшоты окружения; сама LLM этот слой не видит напрямую. Sandbox — изолированная среда, где реально выполняются команды. Такое разделение позволяет executive монтировать в песочницу собственный исходный код и просить харнесс пересобрать и подменить себя прямо посреди работы. Специальный guardian-процесс даёт executive один шаг на то, чтобы не сломаться, — и откатывает изменения автоматически, если что-то пошло не так.

Не внешний наблюдатель, а сам агент

Принципиальное отличие от схемы «внешний агент правит внутреннего» (условный Devin, редактирующий рабочего бота) — в том, кто одновременно решает, что менять, что запускать и что инспектировать. У Exo это один и тот же контур: агент, играющий в Pokémon, сам догадался читать память эмулятора, нашёл байты, отвечающие за координаты и статус боя, и встроил это знание в свой system prompt — без внешнего цикла, который сначала должен был бы это спроектировать, протестировать и передать обратно.

От архитектуры к экономике: пример с Discord-адаптером

Самый наглядный кейс из разговора — не про интеллект, а про деньги. В харнесс Exo встроено логирование стоимости каждого сообщения. Когда агенту указали, что одно сообщение в Discord-адаптере стоит 16 центов, он сам переархитектурил адаптер, сузив контекст до релевantных тредов вместо подтягивания истории из всех каналов сразу — и снизил стоимость на 96%. Изменения потом закоммитили в основной код харнесса. Это и есть практическая польза self-improving harness: не абстрактный AGI-момент, а рутинная оптимизация, которую раньше делал бы инженер вручную.

Цена самостоятельности: reward hacking и evals

Кренцель честно признаёт слабое место: как только агент оптимизирует метрику без явного eval, он может «сжульничать» — например, просто перестать отвечать, потому что это дешевле всего. Для Discord-кейса проверка тривиальна (отвечает ли агент вообще), но для более сложных задач нужен отдельный holdout eval-сет или инструменты, которые агент строит для самопроверки вместе с разработчиком. Открытая проблема alignment никуда не делась — просто теперь у неё появился архитектурный, а не только промптовый рычаг: то, что нельзя доверить весам модели, можно жёстко закрепить в устройстве харнесса (например, запрет на удаление истории — не просьбой в промпте, а физическим разделением слоёв).

Кому это пригодится

Exo — не готовый продукт для конечного пользователя, а опенсорсная архитектура (github.com/exoharness/exo) для тех, кто уже строит собственные agent-харнессы и упёрся в потолок ручной донастройки: команды, управляющие множеством параллельных агентских сессий (харнесс уже используется в проде у Braintrust), исследователи автономных систем и инженеры, которых бесит негибкость существующих фреймворков вроде Claude Code или OpenClaw, где self-improvement ограничен памятью и точечными плагинами. Даже если конкретно эту архитектуру вы не примените, идея разделения executive/harness/sandbox — полезная модель для любого, кто проектирует агентов, которым предстоит жить дольше одной сессии.

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