TL;DR
EvoTeam — подход к мультиагентным системам. Он хранит библиотеку команд: для каждого типа задачи свой состав агентов и свои правила взаимодействия (кто кому передаёт результат и когда можно останавливаться). Под новую задачу система выбирает подходящую команду или собирает новую. После выполнения отдельные «рефлекторы» (LLM-разборщики) смотрят протокол работы и правят три вещи: состав команды, правила этой команды и навыки отдельных агентов.
Главная находка: правила передачи работы, выученные на одном типе задач, ломают другой тип. Пример из статьи: правило «агент-исследователь файлов передаёт находки планировщику и завершает» хорошо работало для диагностики. Когда его унаследовала задача на реализацию кода, система останавливалась до написания кода и тестов. Агенты при этом были умелые. Сломалась организация работы: чужое правило задало неверную передачу и неверное условие остановки.
Поэтому EvoTeam разделяет то, что переносится, и то, что нет. Навыки агентов («как делать X») общие для всех команд. Правила координации («кому передавать и когда заканчивать») живут только внутри команды с похожим разделением труда. В статье такая схема стабильно обгоняет подходы, которые накапливают опыт в одной общей куче, особенно когда задачи разнородные.
Схема метода
ДЛЯ КАЖДОЙ ЗАДАЧИ:
ШАГ 1: Выбор команды
Selector сверяет задачу с описаниями команд в библиотеке
→ подходит одна из команд ИЛИ Composer собирает новую из общего пула агентов
ШАГ 2: Набор исполнителей
Chairman берёт из состава команды только нужных агентов
→ меньше лишних участников и токенов
ШАГ 3: План
Chairman разбивает задачу на подзадачи и раздаёт агентам
→ кто за что отвечает (без заранее прописанной переписки)
ШАГ 4: Выполнение
Агенты работают со своими навыками; правила ЭТОЙ команды лежат в контексте как мягкая подсказка
→ агент сам выбирает подходящее правило по описанию и ситуации
→ Chairman перераспределяет подзадачи, если работа встала
ШАГ 5: Рефлексия (три отдельных разбора по протоколу)
Team Reflector → правит состав команды и её описание
Rule Reflector → добавляет / правит / удаляет правила ТОЛЬКО этой команды
Agent Reflector → правит навыки агента (общие для всех команд)
В статье это код с несколькими вызовами LLM. Принцип можно перенести вручную в файл инструкций агента, и ниже показано как.
Пример применения
Задача: Вы ведёте магазин на Wildberries и ведёте разработку интеграции с API маркетплейса в Cursor или Claude Code. Задачи двух типов. Первый тип: «диагностика» («почему вчера не выгрузились остатки»). Второй тип: «реализация» («добавь выгрузку цен с учётом акций, с тестами»). Раньше в AGENTS.md лежало общее правило: «исследователь собирает находки, отдаёт планировщику, и работа завершена». Для диагностики это идеально. На задачах реализации агент выдаёт отчёт и останавливается, не написав код.
Промпт (фрагмент файла инструкций агенту):
Задачи «почему сломалось / что происходит»: нужен разбор причин, код менять не требуется.
Исследователь_логов, Исследователь_кода, Планировщик
Исследователь передаёт находки Планировщику. Планировщик формулирует причину и предлагает исправление. Работа завершена после отчёта.
Задачи «добавь / доработай / отрефакторь»: нужны изменения в коде и проверка тестами.
Планировщик, Разработчик, Тестировщик, Ревьюер
Планировщик делит задачу. Разработчик пишет код и отдаёт Тестировщику. Тестировщик запускает тесты и возвращает ошибки. Работа завершена, только когда тесты проходят.
Ревьюер проверяет изменения до финала. Замечания возвращаются Разработчику.
Перед началом работы выбери команду по описанию задачи. Применяй ТОЛЬКО правила выбранной команды. Правила другой команды игнорируй.
Задача: добавь выгрузку цен на Wildberries с учётом акций, с тестами.
Результат: Агент сначала назовёт выбранную команду («Реализация») и применит только её правила. Он будет передавать код на тестирование и вернётся к правкам, если тесты не проходят. Он не остановится на отчёте. Для задачи-диагностики он выберет другую команду и закончит отчётом, как раньше.
Почему это работает
Слабость. Модель хорошо следует правилам, которые лежат в контексте, но плохо оценивает, подходят ли они к текущей задаче. Если в инструкции есть «после отчёта заверши работу», агент так и сделает, даже когда задача требует кода. Чем больше разнородных правил свалено в одну кучу, тем выше шанс, что сработает чужое. В статье это показано: накопленный опыт с других типов задач ухудшал результат по сравнению с обучением только на целевых.
Сильная сторона. Модель хорошо выбирает из короткого списка с описаниями и хорошо работает в заданной роли. «Вот три команды, выбери по описанию задачи» для неё простая операция.
Как метод это использует. Выбор команды становится явным первым шагом, и правила попадают в контекст только из выбранной команды. Навыки отдельных агентов («как писать тесты») при этом общие, потому что они не зависят от того, кто кому что передаёт.
Рычаги управления:
- Описание команды (
Шаблон промпта
Это адаптация принципа в виде инструкции агенту. В статье эти шаги выполняет код с отдельными LLM-вызовами.
Ты Chairman — координатор команды агентов. Ты не выполняешь работу сам: выбираешь команду, набираешь исполнителей, раздаёшь подзадачи.
{для каких задач подходит эта организация работы}
{агенты_через_запятую}
{кто кому передаёт результат; когда работа считается завершённой}
{ещё одно правило этой команды}
{для каких задач подходит}
{агенты}
{передача и остановка}
{агент_1}: {навыки и процедуры — общие для всех команд}
{агент_2}: {навыки}
1. Team Selection: сравни задачу с каждой команды. Назови выбранную. Если подходящей нет — опиши, какая команда нужна, и предложи состав из агентов в .
2. Agent Recruitment: из выбранной команды возьми только тех, кто нужен этой задаче.
3. Intra-Team Planning: разбей задачу на подзадачи, назначь каждую агенту. Порядок общения не фиксируй заранее.
4. Team Execution: применяй ТОЛЬКО правила выбранной команды как мягкую подсказку. Выбирай правило по описанию и текущей ситуации. Если работа встала, переназначь подзадачу.
5. Reflection: после завершения ответь на три вопроса.
- Team: подходил ли состав команды? Что поменять?
- Rules: какое правило передачи или остановки сработало плохо? Предложи правку ТОЛЬКО для этой команды.
- Skills: какая процедура агента оказалась полезной или ошибочной? Предложи правку навыка.
Задача: {задача}
Что подставлять: типы ваших задач (2–3 штуки) и для каждого состав ролей и правила «кто кому передаёт и когда конец». Навыки агентов описывайте отдельно и один раз.
🚀 Быстрый старт — вставь в чат:
Вот шаблон EvoTeam (команды агентов с правилами, привязанными к команде). Адаптируй под мою задачу: {опиши свою работу и 2-3 типа задач, которые ты даёшь агентам}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие типы задач у вас бывают, какие роли нужны в каждом, кто кому передаёт результат и по какому признаку работа считается законченной. Это нужно, чтобы правила передачи и остановки привязались к конкретной команде, а не оказались общими. Модель возьмёт структуру из шаблона и заполнит её под вашу работу.
Ограничения
⚠️ Полный метод требует кода: автоматическая эволюция (библиотека команд, Composer, три рефлектора, допуск новых команд) собрана как программа с множеством вызовов LLM. В чате или в
AGENTS.mdвы получаете только принцип, и обновлять правила придётся вручную по итогам разбора.
⚠️ Нужен точный выбор команды: вся схема держится на том, что Selector угадывает тип задачи по описанию. Если описания размытые, система выберет не ту команду и применит не те правила.
⚠️ Дорого по числу вызовов: отдельные роли для выбора, набора, планирования и трёх рефлексий добавляют запросы. Для простых задач одного агента это перебор.
⚠️ Слабая отдача на части задач: в таблице результатов на ряде подзадач EvoTeam не лучший. Например, на реализации в LoCoBench его обошёл Meta-Team, а в BeyondSWE выигрыши небольшие. Выигрыш сильнее там, где типы задач сильно различаются.
⚠️ Обрезанный текст: в доступной версии статьи нет результатов абляций и анализа стоимости. Какой из компонентов даёт больше всего, по этому тексту не проверить.
Как исследовали
Сначала авторы проверили гипотезу о проблеме. Они взяли готовую эволюционирующую систему Meta-Team и дали ей накопить опыт на чужих задачах, а потом дообучиться на целевых. Выходило хуже, чем если учить её только на целевых задачах. Это было верно даже когда шаблон команды совпадал. Протоколы работы объяснили причину: команда, заточенная под веб-поиск (GAIA), не умела организовать написание и тестирование кода. А правило диагностики «отчитайся и заверши» не давало системе дойти до реализации.
Затем они построили EvoTeam и сравнили с семью базовыми подходами: одиночный агент (ReAct), обычная мультиагентная система, OWL, AgentSquare (поиск по производительности), ReCreate, Skill-MAS и Meta-Team. Тестировали на четырёх бенчмарках: веб-задачи (GAIA), реализация и рефакторинг кода (LoCoBench), работа с приложениями через MCP (LOCA-Bench) и поддержка репозиториев (BeyondSWE). Два режима: опыт копится на каждом бенчмарке отдельно или на смеси всех четырёх.
Результаты. Отдельно EvoTeam получил лучший средний балл (58,85 против 58,30 у Meta-Team). На GAIA отрыв пять пунктов (78 против 73). Главное проявилось на смеси: EvoTeam вырос до 59,58, а Meta-Team упал с 58,30 до 55,55. Опыт одной общей кучи ухудшает результат, а опыт, разложенный по командам, нет.
Отдельно проверили перенос между моделями (GPT и DeepSeek): команды и правила, выращенные на одной модели, помогали и на другой. Максимальный прирост на GAIA составил +18 пунктов у DeepSeek, который эволюционировал на GPT. Для практика это значит, что правила координации модельно-независимы и их можно переносить между LLM.
Адаптации и экстраполяции
🔧 Техника: добавить обязательный выбор команды вслух → видны ошибки диагностики задачи
Добавьте в шаблон: «Первой строкой ответа напиши: Выбранная команда: …, потому что …». Если агент выбрал не ту команду, вы это сразу заметите, и правила не сработают втихую.
🔧 Техника: условие остановки через результат → меньше преждевременных остановок
Замените в правилах «работа завершена после отчёта» на «работа завершена, когда {проверяемый результат}». Это прямо закрывает проблему из статьи.
Экстраполяция: ручной «Rule Reflector» после каждой неудачной сессии
Вот протокол последней сессии агента: {протокол}.
Команда была: {название_команды}.
Какое правило передачи работы или остановки из этой команды сработало плохо?
Предложи: добавить, изменить или удалить правило. Правки только для этой команды, остальные не трогай.
Ресурсы
- Работа: EvoTeam: Multi-Agent Collaboration via Evolving Teams
- Авторы: Qinuo Cao, Xin He, Dianxuan Fu, Lizhi Zhang, Zhaoqing Xing, Jiapu Wang, Xin Wang, Na Zou, Yi Chang, Qinggang Zhang
- Организации: Jilin University, Nanjing University of Science and Technology, Shanghai AI Lab
- Код: https://github.com/DEEP-JLU/EvoTeam
- Бенчмарки из статьи: GAIA, LoCoBench, LOCA-Bench, BeyondSWE
- Связанные подходы: Meta-Team, Skill-MAS, ReCreate, AgentSquare, OWL