Облачные агенты: почему харнес выносят из песочницы

Облачный агент — это агент, который работает не на вашем компьютере, а на чужом сервере. Вы ставите задачу, закрываете ноутбук, а агент продолжает: клонирует репозиторий, правит код, запускает тесты, готовит PR. Так работают облачные сессии Claude Code: их запускают из браузера, мобильного и десктопного приложения Claude или из терминала командой claude --cloud. Так же устроены Codex Web от OpenAI и корпоративные агенты, которым пишут в Slack. Чем дольше агенты умеют работать без человека, тем больше команд хотят такой режим.

11 ноября CTO Paradigm Георгиос Константопулос написал в X, что не может поверить, будто люди всё ещё обсуждают, как управлять парком песочниц для облачных агентов. «На дворе вторая половина 2026 года. Харнес — вне песочницы. Виртуализированные bash и файловая система. Code mode. Песочница — только когда нужно сделать что-то тяжёлое. Не для того, чтобы править файлы и простые данные».¹

Харнес — это программа вокруг модели. Она отправляет модели запрос, получает ответ, выполняет инструменты, которые модель попросила вызвать, возвращает результаты и повторяет цикл, пока модель не скажет, что закончила. Подробно о нём — в статье «Что такое харнес AI-агента».

Песочница — изолированная среда, где агент выполняет команды: контейнер или микро-ВМ со своей файловой системой. Она нужна, чтобы rm -rf или вредоносный скрипт из чужого репозитория не задели ничего важного.

Вопрос в том, где находится харнес относительно песочницы. Андреа Луццарди из компании Mendral в апреле описал два варианта.

Харнес внутри песочницы. Цикл работает в том же контейнере, что и код, над которым трудится агент. Запросы к модели уходят изнутри, bash и чтение файлов выполняются локально, скилы и память агента — обычные файлы на диске контейнера. По словам Луццарди, так работает Claude Code на ноутбуке и так же он выглядит, если запустить его в удалённом контейнере.

Харнес снаружи. Цикл работает на бэкенде. Когда нужно выполнить команду, он обращается к песочнице по API, получает результат и продолжает. Сам цикл в песочницу не заходит.

Первый вариант проще всего: один контейнер, одна файловая система, одно время жизни, и готовый харнес работает без изменений. В том же Centaur, по майскому описанию, каждая ветка в Slack получает свой контейнер, а внутри работает Claude Code, Codex, Amp или другой агент с интерфейсом командной строки. Чтобы не ждать запуска, Paradigm держит пул заранее поднятых контейнеров.²

Подробный разбор проблем опубликовала Anthropic. В апреле её инженеры рассказали, как строили Managed Agents, сервис для долгих агентов на платформе Claude. Начинали они тоже с одного контейнера, где жили и харнес, и песочница, и журнал сессии.

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

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

Третья — задержка. Пока контейнер не готов, модель не может начать отвечать. Каждая сессия платила за клонирование репозитория и запуск процесса, даже если песочница ей вообще была не нужна.

Решение Anthropic называет разделением «мозга» и «рук». Харнес вышел из контейнера и вызывает его как любой другой инструмент: имя и входные данные внутрь, строка наружу. Если контейнер умер, харнес получает ошибку инструмента, передаёт её модели, и при повторной попытке поднимается новый контейнер по стандартному рецепту. Журнал сессии хранится отдельно, поэтому упавший харнес тоже можно заменить: новый экземпляр читает журнал и продолжает с последнего события. По данным Anthropic, медианное время до первого токена упало примерно на 60%, а 95-й перцентиль — больше чем на 90%.⁴

Токены Anthropic держит вне досягаемости кода модели. Для Git токен используется при подготовке песочницы и вшивается в настройки удалённого репозитория: git push работает, но сам агент токена не видит. Токены для MCP лежат в хранилище, а вызовы идут через прокси, который подставляет их по идентификатору сессии.

Отсюда тезис «песочница — только для тяжёлого». Многое из того, что делает агент, песочницы не требует: модель думает, вызывает API, пишет сводку, ждёт, пока пройдёт CI. Mendral пишет, что некоторые сессии вообще не касаются песочницы. Если харнес снаружи, её можно поднимать, только когда агенту нужно выполнить команду, и усыплять, пока она простаивает. С харнесом внутри так нельзя: нельзя усыпить машину, на которой работает сам цикл.

Чтобы пробуждение не тормозило агента, Mendral использует Blaxel: по их словам, песочница выходит из режима ожидания за 25 мс, и агент не замечает, что она вообще засыпала. А сам цикл, который может работать часами, должен переживать выкатку новых версий и падения серверов. Для этого Mendral запускает его как функцию Inngest: каждый ход — отдельный шаг с сохранённой контрольной точкой.⁵

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

Mendral решает это виртуализацией. У агента по-прежнему один инструмент чтения, один записи и один правки. Харнес смотрит на путь: файлы рабочей копии уходят в песочницу, а пути скилов и памяти — в Postgres, в рамках организации. Агент разницы не видит.

Почему не дать агенту отдельные инструменты memory_read и memory_write? Mendral приводит два аргумента. Первый: каждый лишний инструмент рассеивает внимание модели, а два почти одинаковых инструмента она будет иногда путать. Второй: модели, по всей видимости, обучают с подкреплением на харнесах, похожих на Claude Code. Они хорошо знают read, write и edit, а придуманный вами инструмент сходит с этого натренированного пути.

Тот же принцип работает и для bash. Моделям легко даются grep, sed, awk и cat: они видели горы шелл-скриптов. Но настоящему bash нужны настоящий шелл и файловая система, то есть изолированный сервер или контейнер. Мальте Убль из Vercel предложил другой путь: just-bash, реализацию bash и основных команд на TypeScript с виртуальной файловой системой. Пакет пока в статусе беты. Агент думает, что запускает команды в шелле, а они выполняются в вашем JavaScript-процессе без доступа к диску хоста. В списке команд — grep, sed, awk, jq, rg, sqlite3 и десятки других.

Turso подключила к just-bash свою AgentFS: каждый файл агента лежит в базе SQLite, каждое изменение записывается, а сбежать на диск хоста некуда. Такую связку можно запустить даже в Cloudflare Workers. Главное ограничение: доступно только то, что реализовано в just-bash. Для git, ffmpeg или компиляторов AgentFS приходится монтировать в настоящую систему.⁶

Ещё один тезис — code mode. Идею в сентябре 2025 года описали Кентон Варда и Сунил Пай из Cloudflare. Вместо того чтобы давать модели инструменты MCP напрямую, их показывают как TypeScript API, а модель пишет код, который их вызывает. Объяснение простое: модели видели огромное количество настоящего кода и очень мало примеров вызова инструментов, причём в основном искусственных.

Выигрыш особенно заметен, когда нужно связать несколько вызовов. В обычной схеме результат каждого вызова проходит через модель только для того, чтобы она скопировала его во входные данные следующего. Код делает это сам, а модель читает только итог. В ноябре 2025 года Anthropic посчитала на своём примере: если агент находит описания инструментов в файлах и загружает только нужные, расход падает со 150 000 токенов до 2 000, на 98,7%.

Код Cloudflare выполняет не в контейнере, а в V8-изоляте. Изолят стартует за несколько миллисекунд и занимает несколько мегабайт, поэтому под каждый фрагмент кода создают новый и сразу выбрасывают. Доступа в интернет у него нет вообще, а к серверам MCP он обращается через привязки, живые объекты в окружении. Ключи API в изолят не попадают, так что украсть их оттуда нельзя.⁷

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

Почти все коммиты в открытом репозитории nanocode сделаны от имени Константопулоса. Это SDK на Rust для встраиваемых агентов: один рантайм для харнесов Codex и Claude с их собственными промптами и инструментами, который работает в терминале, на сервере, в Cloudflare Worker, во вкладке браузера или в приложении. Три пункта из README совпадают с тезисами твита:

• Durable. Каждый вызов модели и инструмента записывается в журнал, поэтому ход завершится, даже если процесс умер.
• Code Mode. Модель пишет одну программу, которая вызывает все инструменты, и в контекст попадает только её результат.
• Hands, «руки». Песочницы на сессию нет. Ход обращается к ноутбуку, серверу или вкладке браузера только ради тех вызовов, которым это нужно.

В правилах проекта разделение сформулировано одной строкой: вывод модели, субагенты и журнал живут в «мозге», а Code Mode выполняется на машине пользователя. Слова те же, что у Anthropic.

Виртуальный bash в nanocode тоже свой: оболочка psh на Rust с собственными awk, sed, rg, tar, читающими командами git и встроенным python3. Как и остальной код проекта, она собирается и под WebAssembly. 12 ноября, на следующий день после твита, в журнале решений записано, что psh стал единственной оболочкой для команд агента и системному bash больше ничего не передаётся.

Вместе это примерно та схема, которую описывает твит. Харнес на бэкенде, состояние в базе, ключи в хранилище. Простые действия с файлами и данными идут через виртуальный bash и файловую систему или через код в лёгком изоляте. Настоящая песочница с Linux поднимается, только когда нужно собрать проект, прогнать тесты или запустить тяжёлый инструмент. Похоже устроен и Agents SDK от OpenAI. В апрельском анонсе компания пишет, что разделение харнеса и вычислений не пускает ключи туда, где выполняется код модели, а песочницы можно поднимать только когда они нужны. Если контейнер пропал, SDK восстанавливает состояние агента в новом и продолжает с последней контрольной точки. Песочницу подключают через клиент: свою или у провайдеров вроде Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop и Vercel.

Под самим твитом к утру 12 ноября был 21 ответ, и согласны с ним далеко не все. Чаще всего возражают про ключи. Харнес теперь хранит все секреты, и запирать надо уже его, пишет один из комментаторов. Виртуальная файловая система держит агента подальше от диска, но если сетевые запросы у него настоящие, утечка пойдёт через них, напоминает другой. Команда разработчиков 1Password согласна, что вместе с харнесом переезжают и секреты, и спрашивает, как устроена авторизация в code mode.

Практическое замечание оставил Джон Руд. Больнее всего бьют команды, которые спрашивают о машине, а не о файлах: нет ли нужной программы, занят ли порт, который час. Виртуальный bash уверенно отвечает на них за хост, на котором агент на самом деле не работает, и в журнале сессии этого не видно.

Другие спорят с самой предпосылкой. В 2026 году агенты делают намного больше, чем правят файлы и простые данные. Сборке Rust всё равно нужна отдельная машина, а копировать проект в песочницу перед каждым прогоном тестов неудобно. А с дешёвыми микро-ВМ, считает Ник Ромито, оркестрация заметно упростилась, их стоимость теряется на фоне расходов на токены, и запускать харнес прямо в песочнице проще: распределённые системы — это сложно. Наконец, готовые харнесы вендоров гораздо лучше самописных, а большинство открытых харнесов сделаны для локальной работы, а не для долгоживущих облачных сервисов.

Когда весной пост Mendral обсуждали на Hacker News, единодушия тоже не было.

Главное возражение там — доверие к харнесу. Один из комментаторов пишет, что доверяет харнесу ненамного больше, чем модели: харнесы меняются так же быстро, как модели. Если харнес умеет что-то, чего не умеет модель, и есть условия, при которых модель может его на это подтолкнуть, надо исходить из того, что модель эти условия найдёт. По его словам, так появляется одна из сторон «смертельной триады».⁸

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

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

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

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

Модель может попробовать выйти за границы песочницы. Как это выглядело у OpenAI, — в разборе о поиске выхода из песочницы. Как проектировать агентов, их инструменты, память и границы доступа, разбираем на курсе «Разработка AI-агентов».