Оркестрация агентов и маршрутизация моделей

Проверено: 20 июля 2026 года.

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

Ролевой конвейер

Explorer / Library scout ──► Planner ──► Worker ──► Test runner ──► Reviewer
   Terra, read-only           Sol          Terra       Terra          Sol
   краткая выжимка            план         код          факты          гейт

Текущая рекомендуемая карта на июль 2026 года:

Роль	Модель и reasoning	Задачи
Planner / architect	gpt-5.6 (Sol), high или выше	Неясные требования, архитектура, миграции, декомпозиция и риск
Security/review lead	gpt-5.6 (Sol), high	Независимый review, auth, данные, конкуренция, сложные дефекты
Explorer / library scout	gpt-5.6-terra, low–medium, read-only	Большое чтение, поиск паттернов, сравнение библиотек, первичный triage
Worker	gpt-5.6-terra, medium	Хорошо специфицированная реализация, тесты и локальный рефакторинг
Test/log analyst	gpt-5.6-terra, medium, обычно read-only	Запуск проверок, анализ логов и сводка причин сбоев
Bulk transformer	gpt-5.6-luna, low	Явные повторяемые преобразования без архитектурных решений

Названия моделей изменчивы. Перед настройкой сверять их с текущим руководством моделей и официальным manual Codex. Семантические роли важнее конкретных slug.

Как экономить без потери качества

• Не заставлять Planner читать тысячи сырых строк: Explorer возвращает краткую выжимку с путями, строками, неизвестными фактами и противоречиями.
• Planner обязан открыть ключевые первичные файлы сам перед архитектурным решением, а не доверять summary вслепую.
• Worker получает утверждённый контракт, список допустимых файлов и команды проверки; он не пересматривает архитектуру молча.
• Reviewer не должен быть тем же проходом, который написал код. Для высокого риска использовать Sol/high даже если реализация сделана Terra.
• На дешёвую модель переносить объём, а не ответственность: финальный гейт остаётся у сильной модели и человека.

Когда повысить модель

Перевести работу с Terra/Luna на Sol, если:

• требования противоречат друг другу или требуют продуктового выбора;
• затронуты auth, платежи, персональные данные, криптография или границы trust;
• меняются схема БД, публичный API, инфраструктура или порядок deploy;
• Worker дважды предложил неработающее решение одной причины;
• тесты нестабильны, ошибка конкурентная или воспроизводится только в сложном окружении;
• библиотечное решение требует серьёзного компромисса по безопасности, лицензии или совместимости.

Не повышать модель только из-за большого числа файлов: сначала разделить read-heavy исследование между Explorer-агентами.

Когда использовать субагентов

Хорошие кандидаты:

• независимое чтение разных модулей;
• поиск существующих реализаций и библиотек;
• отдельный анализ security, тестовых пробелов и производительности;
• запуск независимых проверок или анализ разных логов;
• сравнение нескольких решений с единым форматом ответа.

Плохие кандидаты:

• одновременная запись в общие routes, config, lock-файл или миграцию;
• параллельные тесты на одной общей БД;
• несколько агентов, самостоятельно меняющих один контракт;
• рекурсивное размножение агентов без ограниченного результата.

Начинать с 2–4 параллельных workers. В Codex текущий default agents.max_threads равен 6, а agents.max_depth — 1; глубину обычно не увеличивать, потому что fan-out быстро умножает токены и координацию. Для write-heavy задач использовать отдельные worktrees и назначать одного владельца общих файлов.

Контракт субагента

Каждое делегирование должно задавать:

• один конкретный вопрос или артефакт;
• корень проекта и применимые инструкции;
• read-only или точный список файлов для записи;
• запрет на production и внешние побочные эффекты;
• способ проверки;
• формат короткого возврата: вывод, доказательства, риски, неизвестное.

Возвращать summary и ссылки на файлы, а не полный лог. Это защищает основной контекст от context pollution и context rot.

Проектные custom agents

Codex поддерживает файлы .codex/agents/*.toml. Минимальный пример Planner:

name = "planner"
description = "Планирует сложные изменения; не редактирует код."
model = "gpt-5.6"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
Исследуй факты, перечисли варианты и риски, затем дай проверяемый план.
Не изменяй файлы и не выдавай предположение за факт.
"""

Explorer обычно настраивается на gpt-5.6-terra, medium и read-only; Reviewer — на gpt-5.6, high, read-only; Worker — на Terra/medium с границами записи родительской сессии. Проектный config загружается только для доверенного репозитория. Live permissions родительского turn применяются и к потомкам, поэтому до делегирования выбрать безопасный режим.

Новые возможности июня—июля 2026

• Browser Developer mode: отдавать web-debugging отдельному агенту, который анализирует CDP network, console, runtime errors и DOM; full CDP требует отдельного approval.
• Record & Replay: демонстрируемый стабильный workflow превращать в skill, затем вычитывать и сужать сгенерированные инструкции.
• Chat handoff: переносить длинную работу на подходящий host вместе с Git state; использовать отдельный worktree и повторно проверять среду.
• Work mode / Goal mode: применять для многочасовых целей с наблюдаемыми этапами и человеческими гейтами, а не для неограниченной автономии.
• Scheduled tasks: автоматизировать только стабильные read-only проверки; исправление, merge и deploy оставлять отдельным подтверждаемым шагом.

Источник возможностей и текущей модели Sol/Terra/Luna — What's new и Subagents.

Что измерять

Раз в несколько задач сравнивать не только токены:

• долю задач без переделки;
• число циклов «исправить исправление»;
• время до первого доказанного результата;
• дефекты, найденные независимым review;
• стоимость и время на роль;
• объём raw output, попавшего в основной контекст.

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