Скил dispatching-parallel-agents — один агент на каждый домен проблемы
Как скил dispatching-parallel-agents устраняет последовательное расследование независимых ошибок, dispatching-уя изолированных агентов в каждый проблемный домен одновременно и интегрируя их результаты.
Когда после крупного рефакторинга падают шесть тестов в трёх файлах, естественный рефлекс — чинить по очереди. Если падения независимы — разные подсистемы, разные корневые причины — такой последовательный подход тратит время пропорционально числу проблем. Скил dispatching-parallel-agents формализует альтернативу: один изолированный агент на каждый независимый проблемный домен, все запускаются одновременно.
Проверка независимости
Перед любым диспатчингом скил требует проверки независимости. Вопрос в том, может ли исправление одного сбоя повлиять на другой. Если сбои связаны общей корневой причиной или затрагивают одни и те же участки кода, они принадлежат одному агенту. Если они подлинно независимы — например, поток подтверждения инструмента, поведение пакетного завершения и функциональность прерывания — каждый получает своего агента с собственным изолированным контекстным окном.
Скил также требует проверки общего состояния. Агенты, которые редактировали бы одни и те же файлы или использовали одни ресурсы, мешают друг другу и должны работать последовательно. Параллельный диспатчинг — для доменов, где агенты могут работать без координации.
Что нужно каждому агенту
Скил определяет четыре вещи, которые должен содержать хороший промпт агента. Сфокусированный скоуп: один файл тестов или одна подсистема, а не «все сбои». Весь контекст, необходимый для понимания проблемы: сообщения об ошибках, имена тестов и что каждый тест проверяет. Явные ограничения: «не изменять production-код» или «исправлять только тесты». Конкретный формат вывода: резюме корневой причины и что было изменено, а не просто «готово».
Скил называет типичные ошибки с конкретными исправлениями. «Исправь все тесты» — слишком широко, агент теряется. «Исправь agent-tool-abort.test.ts» — правильный скоуп. Передача сообщений об ошибках и имён тестов в промпте — это разница между агентом, который находит реальную проблему, и агентом, который просто увеличивает таймауты.
Реальный пример из скила
Скил документирует конкретную сессию: шесть падений в трёх тестовых файлах после крупного рефакторинга. Три агента были запущены параллельно. Агент 1 исправил проблемы с таймингом в файле тестов прерывания, заменив произвольные таймауты ожиданием на основе событий. Агент 2 нашёл баг в структуре событий в файле пакетного завершения — поле threadId оказалось не на том месте. Агент 3 добавил ожидание асинхронного выполнения инструментов в файле с гонками. Все три исправления оказались независимы, конфликтов при интеграции не возникло, весь набор тестов стал зелёным.
Интеграция и верификация
Когда агенты возвращаются, оркестратор читает каждое резюме, проверяет конфликты, запускает полный набор тестов и точечно проверяет изменения. Скил отмечает, что агенты могут допускать систематические ошибки — если все три применили одно и то же неправильное исправление, точечная проверка ловит это до конца сессии.
Скил явно указывает, когда не использовать этот паттерн. Связанные сбои с общей корневой причиной следует расследовать вместе. Исследовательская отладка — когда ещё неизвестно, что сломано — требует одного агента с полным контекстом. Любая ситуация, где агенты редактировали бы одни и те же файлы, — последовательная, не параллельная.
Полный обзор пайплайна — в посте что такое Datarim; место параллельного диспатчинга агентов в фазе реализации описано в статье о команде /dr-do.