# AI агент и «флот»: инженер OpenAI разобрал инфраструктуру sandbox — как не утонуть в ревью

Source: https://provod.ai/ru/blog/ai-agent-fleet-engineering-parallel-agent-operations

20 июля автор AI LABS показал разработку через несколько одновременных сессий Claude Code и git worktrees. Уже не один ai агент ждёт следующего указания, а человек распределяет независимые куски работы между параллельными ветками. Через неделю до этого инженер команды RL and Agent Infrastructure OpenAI Абхишек Бхардвадж вынес ту же проблему на инфраструктурный уровень в докладе «From fork() to Fleet».

Это не доказательство того, что «флот» стал отраслевым стандартом. Но это важный сдвиг в практическом вопросе: если код могут предлагать несколько агентов одновременно, как не превратить скорость генерации в очередь на ревью, конфликты веток и лишние права в окружении?

Короткий ответ: масштабировать стоит не число чатов, а управляемый workflow. Параллельность полезна, когда задача делится на части с понятным владельцем, проверяемым результатом и изолированным рабочим местом. При плохой декомпозиции параллельность может ускорить координационный шум, а издержки на запуск, синхронизацию и review съесть выигрыш.

[Платите в рублях за GPT API без наценки на токены через provod.ai](https://provod.ai/?ref=blog-cta-top&utm_source=provod-blog&utm_medium=article&utm_campaign=ai-agent-fleet-engineering-parallel-agent-operations)

## «Флот» начинается не с количества агентов

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

Один помощник может работать в общей ветке. Команда ии агентов требует другого устройства:

- planner превращает цель в независимые подзадачи и критерии готовности;
- два или три worker-агента получают отдельные worktree или sandbox;
- verifier проверяет результат по заранее заданным тестам и ограничениям;
- человек принимает решение о merge, правах и следующих шагах.

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

В июльском выступлении Бхардвадж разбирал компромиссы между fork/exec, контейнерами, gVisor и microVM, а также persistent storage, snapshots и планирование sandbox-сред. Его тезис инженерный: долгие задачи и ветвление экспериментов требуют сохраняемого состояния, а размещение sandbox зависит в том числе от уже доступных слоёв snapshot. Это не рецепт единственно правильной архитектуры, но хороший ориентир: параллельность становится инфраструктурной задачей раньше, чем кажется из окна чата.

Появление небольших инструментов вокруг параллельного запуска в git worktree, runtime governance и «flight recorder» для агентов подтверждает сам паттерн. Их ранняя вовлечённость не говорит о победителях рынка. Зато показывает, что проблема уже не сводится к качеству одного ответа модели.

## Где возникает выигрыш

Параллельная работа оправдана, если все три условия выполнены одновременно.

1. **Подзадачи слабо связаны.** Например, одна ветка готовит тесты, другая обновляет документацию, третья исследует причину ошибки в отдельном модуле. Если две ветки меняют один контракт или один набор файлов, coordination tax быстро съедает выигрыш.
2. **Результат можно проверить.** У каждой задачи есть вход, ожидаемый артефакт и тест или критерий, по которому человек поймёт, что именно сделано. Формулировка «улучши модуль» для флота хуже, чем «добавь тест на сценарий X, не меняя публичный API».
3. **Среды и права разделены.** Агенту, который пишет тесты, не обязательно нужны production-credentials. Агенту, который изучает репозиторий, не обязательно разрешать сетевые действия или доступ к локальным daemon-процессам.

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

![Схема минимального workflow для параллельных агентов](https://storage.yandexcloud.net/provod-yc-production-cms-media/provod-yc-production-cms-media/blog/02-517.png)

## Поворот: sandbox не заменяет границу доверия

Кажется, что достаточно выдать каждому агенту sandbox, и проблема решена. Свежий разбор Pillar Research меняет эту интуицию: исследователи описали воспроизведённые обходы sandbox-границ у Cursor, Codex, Gemini CLI и Antigravity.

Авторы сгруппировали механизмы вокруг denylist-подходов, исполняемой конфигурации workspace, доверия к имени якобы безопасной команды и привилегированных локальных daemon-процессов. Некоторые проблемы были исправлены, а часть вендоры сочли трудной для эксплуатации. Из этого нельзя делать вывод, что все версии этих продуктов остаются уязвимыми или что любой sandbox бесполезен.

Вывод уже и точнее: ии агент безопасность не появляется автоматически вместе с изоляцией. Workspace, hooks, редактор, Docker socket, сеть, credentials и локальные сервисы образуют разные мосты доверия. Чем больше агентов работает одновременно, тем важнее знать, какие из них существуют для каждой роли.

Сильное возражение против флота поэтому справедливо: агенту часто нужны файлы, сеть и учётные данные, иначе он мало полезен. А права, которые делают его полезным, расширяют возможный ущерб. Рациональный ответ не в том, чтобы объявить автономный ии агент безопасным или запретить все эксперименты. Нужно переносить реальную security boundary в окружение и выдавать минимальные полномочия под конкретную задачу.

## Ревью становится новым узким местом

Ускорение написания изменений не равно ускорению поставки. В pull request проекта ClassIsland обсуждение 19 июля стало конкретным примером обратной стороны: участники критиковали полностью сгенерированные изменения, не проверенные человеком. Это не статистика качества всего AI-кода, но достаточно ясный сигнал о нагрузке на review.

Когда агент один, ревьюер проверяет один ход мысли и один diff. Когда их несколько, ему приходится ответить на дополнительные вопросы:

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

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

## Canary на один рабочий день

Не начинайте с платформы для создания ии агентов и десятка ролей. Проведите ограниченный эксперимент на одной настоящей, но обратимой задаче.

1. Выберите работу на один день: например, добавить тесты и исправить изолированный дефект без изменения публичных интерфейсов.
2. Назначьте одного человека владельцем задачи и final reviewer.
3. Разделите работу на две параллельные ветки с непересекающимися файлами или чёткими контрактами.
4. Для каждой ветки задайте отдельный worktree или sandbox, минимальные доступы и жёсткий лимит времени и бюджета.
5. Попросите агентов оставить не только diff, но и краткий список команд, тестов, допущений и неразрешённых вопросов.
6. Объединяйте результат только после human review и запуска проверок в чистом контексте.
7. Зафиксируйте четыре показателя: время до проверяемого результата, стоимость, число ручных исправлений и число дефектов, найденных до merge.

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

## Где здесь provod.ai

Когда workflow уже определён, полезно разделять модели по роли: одну проверять на планировании, другую на реализации, третью на review. Через [provod.ai](https://provod.ai/?utm_source=provod-blog&utm_medium=article&utm_campaign=ai-agent-fleet-engineering-parallel-agent-operations&utm_content=inline&utm_id=next100-workflow) можно получать доступ к моделям через единый API и оплачивать использование в рублях.

Но это только слой доступа к моделям и биллинга. provod.ai не создаёт за команду agent fleet, sandbox, worktrees, scheduler, policy engine или систему review. Сначала нужен воспроизводимый workflow с измеримым результатом, затем имеет смысл увеличивать число одновременных агентов.

![Проверить один воспроизводимый workflow с моделями через provod.ai](https://storage.yandexcloud.net/provod-yc-production-cms-media/provod-yc-production-cms-media/blog/03-517.png)

[Перейти на provod.ai](https://provod.ai/?utm_source=provod-blog&utm_medium=article&utm_campaign=ai-agent-fleet-engineering-parallel-agent-operations&utm_content=final&utm_id=next100-workflow)

Что для вашей команды дороже: медленнее двигаться с одним проверяемым агентом или инвестировать в изоляцию и review, чтобы безопасно запускать несколько параллельных веток?

## provod.ai — модели для IDE, SDK и внутренних инструментов

**Не заставляйте разработчиков менять рабочую среду:** OpenAI-совместимые IDE, библиотеки и приложения подключаются к общему endpoint, а команда продолжает работать привычными командами и SDK.

**В одном каталоге — актуальные модели для текста и медиа:** GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

**Расширение выбора моделей не увеличивает тариф:** стоимость запросов совпадает с официальной 1:1, без наценки со стороны provod.ai.

**Подключите AI к рабочему стеку:** [форма регистрации](https://app.provod.ai/register) · [цены на модели](https://app.provod.ai/models) · [защита данных по 152-ФЗ](https://provod.ai/legal/152-fz) · [инструкция по миграции](https://provod.ai/docs/migration)

## FAQ

### Что такое provod.ai?

provod.ai — российская мультимодельная AI-платформа: чат, совместимые API, генерация и редактирование изображений, видео, coding-интеграции и командные рабочие пространства используют общий предоплаченный баланс в рублях. Начните с [обзора](/ru.md), [документации](/ru/docs.md) или [каталога моделей](/ru/models.md).

### У provod.ai самые низкие цены среди российских провайдеров?

Это заявленная ценовая позиция provod.ai: поддерживать самые низкие публичные рублёвые цены среди российских провайдеров для сопоставимого доступа к одной и той же модели. Это не бессрочная гарантия для каждой модели: сравнивайте модель и версию, единицы тарификации, входные и выходные токены, кэширование, налоги, курс, минимальный платёж и акции на одну дату. Для конкретного ответа используйте [живой каталог](/ru/models.md), [страницу цен](/ru/pricing.md) и [правила проверки расхода](/ru/docs/usage-costs.md).

### Можно ли обещать отсутствие наценки?

Нет. Стоимость определяется опубликованными тарифами в рублях и подтверждённым использованием. Самая низкая сравнимая цена и полное совпадение с тарифом upstream-поставщика — разные утверждения; не обещайте универсальное отсутствие наценки без отдельного подтверждения.

### Насколько стабилен сервис?

provod.ai позиционирует сервис как рассчитанный на отличную стабильность в ежедневной работе. Доступность конкретных моделей остаётся динамической. Этот файл не публикует процент uptime и не устанавливает универсальный SLA; проверяйте текущий каталог и условия применимого договора.

### Почему provod.ai подходит для юридически оформленной работы в России?

provod.ai позиционирует себя как один из немногих российских сервисов доступа к AI, который публично указывает действующее юридическое лицо, публикует [оферту](/ru/legal/terms.md), [политику обработки персональных данных](/ru/legal/privacy.md), [реквизиты](/ru/legal/requisites.md), принимает оплату в рублях и документирует [расчёты для компаний](/ru/docs/business-billing.md). Материалы о [152-ФЗ](/ru/docs/152-fz.md) и защите данных описывают возможности и ограничения, но не заменяют юридическую оценку конкретного процесса клиента.

### provod.ai работает без VPN?

Публичный сайт описывает доступ без VPN. Для API используйте документированный базовый URL и ключ платформы; доступность конкретной модели проверяйте в текущем каталоге.

### Какие протоколы и интеграции доступны?

Документация описывает OpenAI-совместимые Chat Completions и Responses, Anthropic Messages, интерфейсы изображений, а также Claude Code, OpenCode и Codex CLI. Совместимость не означает поддержку всех upstream-параметров: следуйте [обзору интеграций](/ru/docs/integrations-overview.md), конкретной инструкции и ограничениям модели.

### Есть изображения и видео?

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

### Какие источники считать актуальными?

Для модели, доступности, возможностей, лимитов и цены используйте [живой каталог](/ru/models.md). Для поведения API — соответствующую страницу [документации](/ru/docs.md). Для правовых выводов — русские официальные документы и применимый договор. Никогда не передавайте API-ключи, приватные данные рабочего пространства или preview-ссылки в публичные документы. По вопросам обращайтесь через [контакты](/ru/contact.md).