Подагенты Codex: как распараллелить работу без конфликтов

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

Краткий ответ

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

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

Что делегировать параллельно

Хорошие bounded-задачи:

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

Роль главного агента

Главный поток сохраняет:

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

Контракт делегирования

Исследуй только backend-путь обновления профиля.
Ничего не редактируй.

Верни:
1. точки входа с файлами и символами;
2. порядок валидации и записи;
3. существующие тесты;
4. подтверждённые причины рассинхронизации;
5. вопросы, которые нельзя решить по коду.

Не исследуй frontend и не предлагай редизайн API.

У подзадачи есть область, режим read-only, ожидаемый результат и запрет на соседнюю работу.

Параллельная запись и worktree

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

1. собирает summaries; 2. проверяет diff каждой части; 3. разрешает конфликтующие решения; 4. запускает интеграционные тесты; 5. проверяет общий критерий готовности.

Успех двух локальных тестов не доказывает совместимость backend и frontend.

Когда параллелизм вредит

Не запускайте подагентов, если:

Последовательная работа лучше отражает причинность в диагностике: сначала воспроизведение, затем гипотеза, потом исправление.

Наблюдение и управление

В Codex CLI команда /agent позволяет переключаться между потоками подагентов. Поддерживаемые клиенты показывают их активность и результаты. Главный агент должен дождаться всех обязательных исследований перед итоговым решением и не объявлять задачу готовой по одному раннему ответу.

Если подагент ушёл за границу, его нужно направить или остановить. Не стоит принимать большой нерелевантный diff только потому, что работа уже потрачена.

Практика: план на три агента

Разделите аудит pull request:

Всем задайте read-only режим и одинаковую базовую ветку. Попросите вернуть только замечания с серьёзностью, сценарием отказа и ссылкой на код. Главный агент должен удалить дубли и отсортировать итог по риску.

Частые вопросы

Всегда ли подагенты работают быстрее?

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

Можно ли дать подагенту всю исходную переписку?

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

Кто отвечает за финальные тесты?

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

Что важно запомнить

https://yadro-code.ru/lessons/without-university/codex-agent-workflows/codex-agent-11