09. Оркестрация: зависимости важнее параллельности
← Предыдущий модуль · Оглавление · Следующий модуль →
Если сейчас только читаете: русский разбор ситуации без запуска программ. После него ответьте на вопросы самопроверки модуля; практическое упражнение можно отложить.
Результат модуля: вы умеете выбрать порядок работы и объединить результаты без потери требований. Оркестрация в этом модуле — инженерная организация процесса, а не отдельная обещанная кнопка продукта.
Официальная документация подтверждает, что субагентам можно поручать независимые части и собирать их результаты. Конкретная схема распределения файлов, контрольные точки и критерии объединения ниже — рекомендации курса. Не переносите механизм hosted ChatGPT Work на локальный Windows-проект без проверки доступных инструментов и разрешений. Официальный обзор субагентов.
Три схемы работы
Последовательная схема подходит, когда следующий шаг использует результат предыдущего: исследование → план → исправление → проверка → ревью. Начинать исправление до выяснения контракта рискованно: тогда готовая реализация начнёт определять требования задним числом.
Параллельное исследование подходит для независимых вопросов. Один помощник изучает документацию API, второй — покрытие тестами. Основной агент сопоставляет выводы и разрешает противоречия. Не нужно просить обоих «найти всё»: одинаковые широкие задания создают дубли и усложняют проверку.
Параллельная реализация требует исключительного владения файлами. Если один исполнитель меняет общий интерфейс, второй сервер, третий клиент, интерфейс сначала нужно согласовать. Если двоим нужен один конфигурационный файл, изменения в нём лучше выполнить последовательно одним владельцем.
Карточка независимой части
Записывайте задачу так, чтобы её можно было выполнить без всей переписки:
Название: проверить пустое состояние списка
Зависит от: согласованного контракта ответа API
Владелец: один исполнитель
Область: tests/ui и чтение соответствующего компонента
Запрещено: менять API и общий конфиг
Вход: ссылка на требование и ревизия ветки
Выход: подтверждённые пробелы и предлагаемые проверки
Готово: каждое утверждение имеет ссылку на код или тест
Ссылка на ревизию существенна. Результаты двух проверок могут противоречить друг другу просто потому, что агенты смотрели разные коммиты. Перед объединением определите единое состояние исходников. На Windows полезно сохранить короткую сводку Git:
git branch --show-current
git rev-parse HEAD
git status --short
git diff --name-only
Эти команды читают состояние. Они не создают рабочую копию и не обеспечивают изоляцию. Несколько агентов в одной папке видят одни и те же незакоммиченные изменения. Если необходимы независимые записи, используйте принятый в проекте порядок отдельных worktree и веток; не копируйте рабочую папку вместе с чужим состоянием вслепую.
Как объединять результаты
Сначала проверьте выполнение контрактов отдельных частей. Затем проверьте стыки: совпадают ли имена полей, единицы измерения, обработка ошибок, соглашения о пустых значениях. В конце проверьте пользовательский сценарий целиком. Успех каждого модуля по отдельности не означает успех системы: клиент может ожидать items, а сервер возвращать rows.
Упражнение
Возьмите задачу добавления нового фильтра, но ограничьтесь планированием. Разбейте её на требования, контракт, UI, тесты и документацию. Нарисуйте зависимости текстовыми стрелками. Затем удалите лишнюю параллельность: всё, что требует ещё не принятого решения, должно ждать. Не запускайте исполнителей только для красивой схемы.
Оцените возможный выигрыш: сколько независимого чтения можно выполнить одновременно и сколько времени потребуется основному агенту на объединение. Если оцениваете эффективность экспериментом, сравнивайте одинаковое задание и одинаковые критерии качества. Записывайте время, полезные замечания, ложные тревоги и повторы. Количество агентов само по себе показателем качества не является.
Готово, когда: зависимости названы; на каждый изменяемый файл есть один владелец; общие решения приняты до зависимых правок; проверены стыки; итог удовлетворяет исходному пользовательскому сценарию.
Самопроверка:
- Почему независимое чтение обычно проще распараллелить, чем запись?
- Как убедиться, что два рецензента проверяли один и тот же код?
- Какой дефект может сохраниться, если проверки отдельных компонентов прошли?