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

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

Новая инфраструктура для агентов

ИИ пишет код, чинит ошибки, вызывает инструменты, иногда даже проходит бенчмарки уровня хорошего стажёра. Но обзор Code as Agent Harness предлагает куда более интересный поворот. Авторы утверждают, что код становится операционной средой, через которую агент думает, действует, хранит состояние, проверяет себя и координируется с другими агентами.

Это важно. Если раньше мы спрашивали: «Насколько хорошо модель генерирует программу?», то теперь вопрос звучит иначе: как устроить систему вокруг модели так, чтобы она могла надёжно работать в длинных, многошаговых задачах. И тут код оказывается не целью, а каркасом. Через него агент запускает вычисления, общается с API, сохраняет промежуточные артефакты, читает журналы, обновляет план, проверяет гипотезы тестами и даже делит работу с другими агентами.

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

Главная идея: код как “сцепка” между моделью и миром

Авторы вводят фреймворк, который можно перевести как «код как каркас агента». Под каркасом здесь понимается программный слой вокруг LLM: инструменты, песочницы, память, валидаторы, журналы, разрешения, циклы исполнения и каналы обратной связи. Именно он делает из модели, генерирующей токены, агента, который может что-то делать в мире.

Ключевой тезис обзора в том, что код хорош для этой роли по трём причинам.

Во-первых, он исполнимый. Текстовое рассуждение может звучать убедительно, но код можно запустить и проверить, что он реально делает.

Во-вторых, он наблюдаемый. У кода есть трассы исполнения, значения переменных, ошибки времени выполнения, результаты тестов. То есть система получает не только финальный ответ, но и следы того, как агент пришёл к нему.

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

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

Три слоя всей конструкции

Авторы предлагают рассматривать тему в трёх слоях.

Первый слой — интерфейс каркаса: как именно код связывает агента с рассуждением, действием и представлением среды.

Второй — механизмы каркаса: планирование, память, работа с инструментами, управление циклом «спланировать — выполнить — проверить», а также оптимизация самой обвязки.

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

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

Как код помогает рассуждать, действовать и “видеть” среду

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

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

Код для действия — это уже не «решить задачу», а «сделать шаг во внешней среде». Программа может стать политикой управления роботом, сценарием кликов в интерфейсе, цепочкой вызовов инструментов или временным навыком, который агент написал для себя сам. Здесь код — это способ превратить абстрактное намерение в конкретное исполнимое действие.

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

Почему это важно? Потому что без такого интерфейса агент остаётся существом с короткой памятью и слабой связью с реальностью. Он может красиво объяснять, но плохо действовать. Код делает действия и состояние объектами инженерии, а не только красивого текста.

Механизмы: где агент либо улучшается, либо разваливается

Самый практичный вклад обзора — разбор механизмов, без которых агент не живёт дольше одного хода.

Первый такой механизм — планирование. На длинных задачах мало один раз сгенерировать ответ. Нужно разбить задачу на подшаги, зафиксировать промежуточные цели, понимать зависимости между файлами и действиями, а иногда — исследовать несколько альтернативных траекторий. Авторы показывают эволюцию от линейных планов «шаг 1, шаг 2, шаг 3» к более серьёзным конструкциям: графам зависимостей, поиску по дереву решений и оркестрации нескольких ролей.

Второй — память. И здесь речь не просто о длинном контекстном окне. Память у агента — это управляемый слой состояния: что держать «в голове» прямо сейчас, что извлекать из репозитория, что сохранять как полезный опыт, что сжимать, а что выносить во внешнее хранилище. Для реальных задач это критично. Репозиторий, история запусков, журналы, тесты, найденные подсказки — всё это не влезает в активный контекст, но должно оставаться доступным.

Третий — использование инструментов. Инструмент в этой логике — не просто «модель может вызвать функцию». Это управляемая граница между намерением агента и внешней системой. Какие инструменты доступны? С какими разрешениями? Где выполняется код? Как очищаются результаты? Как записываются в журнал действия? Какой вызов требует участия человека? Именно на этом уровне рождается надёжность или, наоборот, хаос.

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

Это звучит почти тривиально, но именно здесь проходит граница между «демо-агентом» и системой, которой можно доверить хоть что-то серьёзнее игрушечной задачи.

Мультиагентность: код как общее рабочее пространство

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

Код, тесты, журналы, репозиторий, промежуточные патчи, сценарии исполнения — всё это становится общим «полем», где агенты видят работу друг друга, проверяют изменения и синхронизируют состояние. И тут всплывает важный инженерный момент: мультиагентность — это не просто несколько моделей в чате. Это почти задача распределённых систем.

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

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

Где это уже работает на практике

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

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

Во-вторых, агенты для графических интерфейсов и операционных систем. Там код превращает действия по экрану в исполнимые сценарии, а состояние интерфейса — в структурированную среду.

В-третьих, научные агенты. Это особенно интересно: гипотеза, эксперимент, симуляция, анализ и отчёт могут стать одной длинной исполнимой цепочкой. Наука в таком взгляде — почти идеальный «мир программ».

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

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

Главное, что статья делает правильно

Это обзорная работа, а не экспериментальная статья с одной новой моделью и красивой таблицей SOTA. Но именно в этом её ценность. Она не обещает чудо-решение, а собирает разрозненное поле в одну инженерную дисциплину.

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

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

Вывод

Code as Agent Harness — это не статья про ещё один приём для LLM. Это попытка переопределить сам объект разговора. Не «как модель пишет код», а «как код становится средой, в которой агент живёт и работает».

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

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