Subagents в Codex полезны в конкретном случае: когда задача распадается на независимые read-heavy подзадачи, которые можно вести параллельно. Разведать execution path, найти риски безопасности, оценить покрытие тестами - это разные линии внимания, и вести их одновременно быстрее, чем последовательно. Но у параллельности есть цена, о которой легко забыть: каждый агент расходует отдельные токены и создаёт стоимость координации, поэтому число workers не является метрикой качества.
Это стоит повторить, потому что соблазн велик: больше агентов не значит лучше результат. Стая агентов - это множитель расхода, и запускать её ради задачи, которая линейно решается одним проходом, дороже и глупее. Параллельность оправдана там, где подзадачи реально независимы и каждая выигрывает от отдельного контекста. Там, где хватает одного rg и чтения пары файлов, дробление на агентов только добавляет координацию и токены, ничего не ускоряя.
Для write-heavy работы порядок обратный: сначала определяют ownership, потом параллелят. Два агента, меняющие один файл или контракт, часто медленнее одного - они исходят из разных картин, и результаты не сходятся в merge. Поэтому запись распределяют так, чтобы у каждого агента была своя область, за которую отвечает только он. Параллелят независимые знания и ownership, а не стадии одного изменения, которые по определению зависят друг от друга.
Самый предсказуемый способ применить subagents - это разведка несколькими read-only ролями. Полезно один раз увидеть такую декомпозицию. Ниже - запрос на три параллельных subagent: explorer строит карту execution path, reviewer ищет проблемы корректности и безопасности, test analyst - пробелы в покрытии. Никто не меняет файлы, а в конце их результаты собирают в один дедуплицированный список evidence. Разведка идёт параллельно и дёшево, а меняет файлы потом только один.
Ключевое в такой декомпозиции - минимальный контекст и явный ожидаемый выход у каждого worker. Каждому агенту дают узкую задачу, определение готовности и формат результата, а не весь репозиторий "на всякий случай". Это и дешевле, и точнее: subagent возвращает сжатую сводку, а не сырой дамп, и оркестратор собирает из этих сводок общую картину. Широкий контекст, розданный всем, - это трата токенов и размывание фокуса, а не помощь.
Управление параллельной работой идёт через отдельные инструменты просмотра. В CLI команды /agent или /subagents показывают threads - что каждый агент делает и в каком состоянии. Отсюда рождается практичный контроль: видно, кто чем занят, кто заблокирован и чей запрос на подтверждение ждёт ответа. Без такого обзора параллельность превращается в набор непрозрачных процессов, за которыми уже не уследить, - а видимость состояния и есть то, что делает многоагентную работу управляемой.
Результаты параллельной работы принимают вместе, а не по отдельности. Дедуплицированный список evidence от нескольких разведчиков - это вход для решения, а не готовое решение: findings проверяют тем же способом, что и любое утверждение. Слияние изменений выполняет человек или отдельная интеграционная задача после общего теста, а не каждый worker сам по себе. Смысл многоагентной работы - собрать больше evidence параллельно, а не размножить хаос несогласованных правок.
Типичные провалы многоагентной работы предсказуемы. Считать число агентов метрикой качества и плодить workers без нужды. Пустить двух агентов на один файл или контракт без ownership и получить merge-конфликт вместо ускорения. Раздать всем широкий контекст вместо узких задач. И принимать результаты по отдельности, а не после интеграции. Параллельте независимое, определяйте ownership заранее, давайте каждому worker минимальный контекст и собирайте evidence в один проверяемый список.
Используй три subagents параллельно:
1. explorer - только карта execution path;
2. reviewer - correctness и security risks;
3. test analyst - coverage gaps.
Никто не меняет файлы. Дождись всех и верни один deduplicated список evidence.
# просмотр threads: /agent или /subagents