Починайте з найпростішого рівня паралельності
Multi-agent workflow не означає автоматично швидшу роботу. Спочатку визначте, чи задача справді має незалежні частини, чи можна розподілити відповідальність і як перевірити кожен результат.
Якщо частини сильно залежать одна від одної, краще уточнити специфікацію та залишити одну сесію. Кількість агентів не є метрикою ефективності.
| Рівень | Коли застосовувати | Особливість |
|---|---|---|
| Одна сесія | Невелика послідовна зміна | Найменші витрати координації |
| Plan mode | Потрібно дослідити код до редагування | Режим тієї самої сесії |
| Subagent | Ізольоване дослідження або перевірка | Повертає висновки в основний контекст |
| Нова сесія | Незалежний погляд на diff | Зменшує упередження автора |
| Worktree | Паралельні зміни у файлах | Ізолює branch, каталог і Git-стан |
| Фонова сесія | Незалежна асинхронна робота | Потрібен явний контроль статусу |
| Agent team | Кілька незалежних напрямів | Найвищі витрати синхронізації |
Пʼять питань перед запуском
- Чи існують справді незалежні робочі потоки?
- Чи можна розподілити відповідальність за файлами, модулями або шарами?
- Чи має кожен результат окремий критерій перевірки?
- Чи доступні тести або інший safety net?
- Чи є час переглянути проміжні результати та ухвалити рішення?
Компроміси паралельності
| Потенційний виграш | Нова ціна |
|---|---|
| Менше wall-clock часу | Більше handoff і координації |
| Незалежні погляди | Повторне пояснення контексту |
| Паралельне дослідження | Більше diff-ів для review |
| Ізольовані експерименти | Конфлікти та обслуговування гілок |
| Розподіл великої задачі | Додаткові токени й когнітивне навантаження |
Практичний процес вибору
- Зафіксуйте коротке рішення щодо паралельності.
- Опишіть масштаб, незалежні потоки, власників, ризик і доступні перевірки.
- Оберіть найпростіший достатній рівень.
- Для паралельних редагувань додайте ізольовані worktree.
- Після появи другого потоку ведіть єдиний список статусів і рішень.
- Завершіть перевіркою diff-ів, тестів і результатів усіх ролей.
Приклади вибору
Друкарська помилка в кнопці → одна сесія
Пошук entry point metrics API → plan mode
Незалежне ревʼю Orders API → нова reviewer-сесія
Порівняння двох реалізацій → окремі worktree
Backend + frontend + тести → team лише за чітких межКанонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush