Подагенты Codex: как распараллелить работу без конфликтов
Подагенты полезны, когда сложную задачу можно разложить на независимые исследования или изолированные изменения.
Краткий ответ
Подагенты полезны, когда сложную задачу можно разложить на независимые исследования или изолированные изменения. Они разгружают главный контекст и сокращают время ожидания, но расходуют дополнительные ресурсы и создают координационные риски при одновременной записи.
Подагенты полезны, когда сложную задачу можно разложить на независимые исследования или изолированные изменения. Они разгружают главный контекст и сокращают время ожидания, но расходуют дополнительные ресурсы и создают координационные риски при одновременной записи.
Что делегировать параллельно
Хорошие bounded-задачи:
- один агент строит карту backend-потока;
- второй ищет frontend-потребителей контракта;
- третий изучает тестовые пробелы;
- отдельный reviewer проверяет безопасность готового diff;
- несколько агентов анализируют независимые наборы логов.
Плохое разделение: «оба исправьте одну и ту же функцию». Агенты читают меняющееся состояние, принимают разные решения и могут перезаписать результат друг друга.
Роль главного агента
Главный поток сохраняет:
- исходную цель и ограничения;
- принятые продуктовые решения;
- общий контракт между частями;
- статус зависимостей;
- интеграцию и финальную проверку.
Подагенту передаётся только необходимый контекст и конкретный формат возврата. Вместо необработанного лога он возвращает выводы с файлами, доказательствами и открытыми вопросами. Это снижает загрязнение основного диалога.
Контракт делегирования
Исследуй только 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:
- агент 1 — correctness и гонки;
- агент 2 — security и права доступа;
- агент 3 — пробелы тестирования и миграции.
Всем задайте read-only режим и одинаковую базовую ветку. Попросите вернуть только замечания с серьёзностью, сценарием отказа и ссылкой на код. Главный агент должен удалить дубли и отсортировать итог по риску.
Частые вопросы
Всегда ли подагенты работают быстрее?
Нет. Они ускоряют независимые ветви. Если результат одной ветви нужен для начала другой, параллелизм увеличивает координацию без выигрыша.
Можно ли дать подагенту всю исходную переписку?
Можно, но полезнее передать минимально достаточный контекст и чёткую подзадачу. Избыточная история повышает риск, что агент займётся соседней проблемой.
Кто отвечает за финальные тесты?
Главный агент, который интегрирует результат. Подагенты проверяют свои области, но только общий прогон доказывает совместимость частей.
Что важно запомнить
- Параллельте независимые исследования и изолированные области.
- Главный поток хранит решения, зависимости и общий критерий готовности.
- Подагент возвращает сжатые доказательства, а не шумный журнал.
- Параллельные записи требуют разных файлов или отдельных worktree.
https://yadro-code.ru/lessons/without-university/codex-agent-workflows/codex-agent-11