agent-swarm-orchestration

Навык TerminalSkills посвящён координации нескольких AI-агентов вокруг одной сложной задачи. Его область — routing, handoff, consensus, обмен памятью и quality gates для pipeline-, hierarchical-, hub-and-spoke- и других swarm-систем. Исходник начинает с практической причины: один агент быстрее заполняет контекст, хуже сохраняет специализированный фокус и остаётся единственной точкой отказа, тогда как несколько узких исполнителей могут работать параллельно, проверять результат друг друга и повторять неудачную подзадачу. Это архитектурная инструкция, а не готовый runtime или гарантия качества конкретной модели. Самый простой вариант — последовательный pipeline: задача проходит через Agent A, Agent B и Agent C, например путь specification → code → test → deploy. Такой топологии достаточно, когда этапы зависят друг от друга. Hierarchical-схема добавляет Orchestrator и отдельных coder, tester и reviewer; она подходит для декомпозиции сложных работ на специализированные роли. Hub-and-spoke использует Router, который выбирает specialist A, B или C по классу задачи. Источник прямо рекомендует начинать с pipeline и добавлять сложность только при подтверждённой необходимости. В примере Orchestrator задача имеет id, role, input_data, output_data, status, retries и max_retries. Агент получает роль и вход, выполняет свою работу, сохраняет результат и переводит задачу в completed. Исключение переводит её в failed; если число retries ещё не достигло max_retries, оркестратор увеличивает счётчик и повторяет вызов. Такой минимум делает retry ограниченным и наблюдаемым: в guidelines обычно предлагается предел 3, чтобы ошибка не превратилась в бесконечный цикл. Конкретную стратегию backoff, хранение очереди и отмену skill не навязывает — их нужно выбрать по среде исполнения. Router строит список доступных агентов с именем и description, передаёт задачу классификатору и ожидает JSON с выбранным агентом, confidence и reasoning. Затем запрос направляется соответствующему specialist. В примере поддержки перечислены Billing, Technical, Account, Feature Requests и Escalation; если confidence ниже 70 процентов, задача передаётся generalist или эскалируется человеку. Порог является правилом исходного примера, а не универсальной метрикой для любого домена: перед production нужно проверить routing accuracy на реальных тикетах и решить, что считать низкой уверенностью. SharedMemory предназначен для того, чтобы агенты не повторяли одну и ту же работу и не противоречили друг другу. В демонстрационной структуре отдельно хранятся facts, decisions и artifacts. Факт добавляется с именем агента, текстом и confidence; решение сохраняет автора, формулировку и reasoning. При подготовке context для очередного исполнителя выбираются последние записи в пределах max_items, после чего они объединяются в компактный текст с указанием автора. Это позволяет передавать полезный контекст без бесконтрольной загрузки всей истории. Число элементов и правила разрешения конфликтов остаются настройкой приложения. QualityGate ставится между стадиями, чтобы unchecked output не переходил дальше. Результат проверки содержит name, passed, details и severity со значением blocking или warning; gate считается пройденным, если все blocking-проверки успешны. В примере code-stage проверяются синтаксис, наличие тестов и отсутствие секретов, review-stage проверяет глубину ревью, а test-stage — успешность test_results. Такой набор показывает направление контроля, но не утверждает, что трёх проверок достаточно для каждого репозитория. В разделе examples показаны pipeline для code review с Analyzer, Security Reviewer и Style Checker, research swarm с разными источниками и Synthesizer, а также support routing с повторным обучением классификатора. Guidelines требуют логировать каждое решение и handoff, держать контекст specialist небольшим и сфокусированным, использовать shared memory и quality gates, а также ограничивать retries. Ограничения важны: skill не запускает агентов сам, не проверяет безопасность инструментов, не выбирает права доступа и не гарантирует, что parallelism дешевле последовательной работы. Перед внедрением нужно определить границы ролей, формат артефактов, политику эскалации, журналирование, лимиты стоимости и проверяемые критерии качества.