20 июля автор AI LABS показал разработку через несколько одновременных сессий Claude Code и git worktrees. Уже не один ai агент ждёт следующего указания, а человек распределяет независимые куски работы между параллельными ветками. Через неделю до этого инженер команды RL and Agent Infrastructure OpenAI Абхишек Бхардвадж вынес ту же проблему на инфраструктурный уровень в докладе «From fork() to Fleet».
Это не доказательство того, что «флот» стал отраслевым стандартом. Но это важный сдвиг в практическом вопросе: если код могут предлагать несколько агентов одновременно, как не превратить скорость генерации в очередь на ревью, конфликты веток и лишние права в окружении?
Короткий ответ: масштабировать стоит не число чатов, а управляемый workflow. Параллельность полезна, когда задача делится на части с понятным владельцем, проверяемым результатом и изолированным рабочим местом. При плохой декомпозиции параллельность может ускорить координационный шум, а издержки на запуск, синхронизацию и review съесть выигрыш.
Платите в рублях за GPT API без наценки на токены через provod.ai
«Флот» начинается не с количества агентов
Что такое ии агент простыми словами? Это модель, которой поручают не только ответить в чате, но и выполнить цепочку действий в заданных пределах: изучить код, предложить изменение, запустить доступный инструмент, оставить артефакт для проверки.
Один помощник может работать в общей ветке. Команда ии агентов требует другого устройства:
- planner превращает цель в независимые подзадачи и критерии готовности;
- два или три worker-агента получают отдельные worktree или sandbox;
- verifier проверяет результат по заранее заданным тестам и ограничениям;
- человек принимает решение о merge, правах и следующих шагах.
Это и есть практическая оркестрация агентов: не разговор нескольких моделей между собой, а распределение ответственности за конкретные артефакты. Общими должны быть не все контексты, а постановка, границы файлов, критерии приёмки и журнал решений.
В июльском выступлении Бхардвадж разбирал компромиссы между fork/exec, контейнерами, gVisor и microVM, а также persistent storage, snapshots и планирование sandbox-сред. Его тезис инженерный: долгие задачи и ветвление экспериментов требуют сохраняемого состояния, а размещение sandbox зависит в том числе от уже доступных слоёв snapshot. Это не рецепт единственно правильной архитектуры, но хороший ориентир: параллельность становится инфраструктурной задачей раньше, чем кажется из окна чата.
Появление небольших инструментов вокруг параллельного запуска в git worktree, runtime governance и «flight recorder» для агентов подтверждает сам паттерн. Их ранняя вовлечённость не говорит о победителях рынка. Зато показывает, что проблема уже не сводится к качеству одного ответа модели.
Где возникает выигрыш
Параллельная работа оправдана, если все три условия выполнены одновременно.
- Подзадачи слабо связаны. Например, одна ветка готовит тесты, другая обновляет документацию, третья исследует причину ошибки в отдельном модуле. Если две ветки меняют один контракт или один набор файлов, coordination tax быстро съедает выигрыш.
- Результат можно проверить. У каждой задачи есть вход, ожидаемый артефакт и тест или критерий, по которому человек поймёт, что именно сделано. Формулировка «улучши модуль» для флота хуже, чем «добавь тест на сценарий X, не меняя публичный API».
- Среды и права разделены. Агенту, который пишет тесты, не обязательно нужны production-credentials. Агенту, который изучает репозиторий, не обязательно разрешать сетевые действия или доступ к локальным daemon-процессам.
В такой схеме мультиагентные системы могут сократить ожидание между независимыми шагами. Но нельзя обещать линейное ускорение: каждый новый исполнитель добавляет постановку, стоимость запуска, проверку, синхронизацию и риск конфликтов. Самое ценное изменение здесь не «больше агентов», а более строгая формулировка работы.
Поворот: 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 на один рабочий день
Не начинайте с платформы для создания ии агентов и десятка ролей. Проведите ограниченный эксперимент на одной настоящей, но обратимой задаче.
- Выберите работу на один день: например, добавить тесты и исправить изолированный дефект без изменения публичных интерфейсов.
- Назначьте одного человека владельцем задачи и final reviewer.
- Разделите работу на две параллельные ветки с непересекающимися файлами или чёткими контрактами.
- Для каждой ветки задайте отдельный worktree или sandbox, минимальные доступы и жёсткий лимит времени и бюджета.
- Попросите агентов оставить не только diff, но и краткий список команд, тестов, допущений и неразрешённых вопросов.
- Объединяйте результат только после human review и запуска проверок в чистом контексте.
- Зафиксируйте четыре показателя: время до проверяемого результата, стоимость, число ручных исправлений и число дефектов, найденных до merge.
Решение после canary должно быть бинарным только по следующему шагу, а не по всей стратегии. Если две ветки дали качественные и проверяемые результаты без перегруза ревью, повторите workflow на похожей задаче. Если владелец потратил больше времени на координацию, чем сэкономил на реализации, уменьшите число ролей или вернитесь к одному агенту.
Где здесь provod.ai
Когда workflow уже определён, полезно разделять модели по роли: одну проверять на планировании, другую на реализации, третью на review. Через provod.ai можно получать доступ к моделям через единый API и оплачивать использование в рублях.
Но это только слой доступа к моделям и биллинга. provod.ai не создаёт за команду agent fleet, sandbox, worktrees, scheduler, policy engine или систему review. Сначала нужен воспроизводимый 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 к рабочему стеку: форма регистрации · цены на модели · защита данных по 152-ФЗ · инструкция по миграции