dispatching-parallel-agents

Dispatching Parallel Agents — навык планирования работы нескольких агентов для независимых задач без общей изменяемой области. Его центральное правило простое: сначала определить, действительно ли проблемы независимы, затем назначить по одному агенту на каждый отдельный домен и после завершения проверить результаты вместе. Источник приводит в качестве примеров независимые падения разных тестовых файлов, отдельные подсистемы и несколько областей расследования, которые не требуют общего контекста. Ценность навыка не в создании сложной оркестрации, а в ограничении контекста и снижении взаимного влияния параллельных исследований. Перед делегацией нужно сгруппировать ошибки по доменам и проверить зависимости. Если исправление одной проблемы может устранить другую, если требуется понимание всей системы, идёт исследовательская работа без ясного разделения или несколько агентов будут менять одно и то же состояние, параллельный режим не подходит. В таких случаях источник рекомендует работать последовательно или сначала собрать общий контекст. Если независимость подтверждена, инструкция каждому агенту должна содержать точную область, цель, ограничения и ожидаемый формат результата. Примером хорошего запроса является один конкретный тестовый файл с перечисленными failing cases, указанием не увеличивать случайные timeout и требованием вернуть root cause и перечень исправлений. После dispatch работа считается незавершённой до интеграционной проверки. Нужно прочитать краткие отчёты агентов, сопоставить изменённые файлы, проверить возможные конфликты и запустить полный набор тестов. Источник отдельно подчёркивает, что агенты не должны наследовать лишнюю историю: координатор передаёт им ровно тот контекст, который нужен для их узкой области. Это помогает избежать расползания задачи, но одновременно повышает требования к формулировке инструкции. Если домен описан слишком широко, агент может начать менять несвязанный код; если отсутствуют ограничения, он может выбрать неподходящую стратегию вроде бессистемного увеличения задержек. Навык подходит для параллельной диагностики и небольших изолированных исправлений в repository, где есть несколько независимых сигналов качества. Он не является заменой архитектурному анализу, общей отладке или координации задач с общей базой данных и общими файлами. Даже при независимых задачах финальная проверка остаётся централизованной: тесты должны пройти после объединения, а повторяющиеся или системные ошибки нужно рассматривать как общий root cause. Для одноразовой работы с одной проблемой такой dispatch добавляет ненужную сложность и его следует пропустить. Ограничения источника также практичны: слишком широкая постановка теряет фокус, слишком мало контекста ведёт к неверной диагностике, а параллельные агенты могут конфликтовать при общем состоянии. Поэтому минимальный безопасный шаблон — три изолированных блока “scope, goal, constraints”, параллельный запуск только после проверки независимости и обязательный review плюс полный test run после интеграции.