Долой иерархию и роли: о том, как LLM-агенты самоорганизуются лучше, чем мы их проектируем

Спасибо за вопросы — в точку!) По порядку:

1) Решали четыре уровня сложности задач. L1 — одна область, 3–5 шагов (например, разработка API). L2 — два домена, интеграция знаний (например, провести финансовый анализ + анализ рисков). L3 — 3+ домена, 10–20 шагов с зависимостями (например, разработать end-to-end ИТ-продукт с backend+frontend+обвзяка, на выходе выдать готовый продукт). L4 — состязательные: конфликтующие интересы стейкхолдеров, неполная информация, нет единственно верного ответа (CEO vs Legal vs CFO за бюджет), задачи на исследование / R&D. Задачи сгенерированы сильной LLM (Claude/GPT-5+) синтетически для контролируемого сравнения — это ограничение исследования, и мы его признаём. Сейчас тестируем на нескольких реальных бизнес-задачах.

2) Роли и специализации. Ваша аналогия с комментаторами Хабра — точная) Именно это и происходит. Агент получает в промпте задачу + результаты предшественников (в Sequential) и сам решает, как себя назвать и что делать. Никакого списка ролей ему не даётся. Пример реальных самоназванных ролей на одной L3-задаче: «Regulatory Compliance Architect», «Cross-System Integration Strategist», «Adversarial Risk Analyst». На другой задаче те же агенты назвали себя совершенно иначе. Является ли роль более общим понятием, чем специализация? В нашем эксперименте — нет, потому что агенты не выбирают из каталога. Они каждый раз изобретают функцию под конкретную задачу. 5 006 уникальных названий — это не таксономия, а 5 006 уникальных строк, сгенерированных агентами. 54% из них встречаются ровно один раз. Я бы даже сказала, что «ролей не существует, это функция момента. Агент просто решает задачу.» Это ближе к тому, как если бы каждый ваш комментатор не просто был «злым» или «добрым», а описал бы свою позицию как «человек, который 10 лет строил API-шлюзы и видит тут конкретную проблему с rate limiting» — и для следующей статьи описал бы себя совершенно иначе. Так что в нашем случае «роль» и «специализация» — это одно и то же: функция, которую агент создаёт под задачу и которая перестаёт существовать после её завершения.

3) Как агент решает отказаться? Это следствие промпта и, предположительно, способности модели к саморефлексии (self-reflection). Агент видит, что уже сделали предыдущие, и если не может добавить ценности — пишет отказ. Мы не программируем заранее ни порог, ни правило. Claude делает это в 8.6% случаев и попадает в оптимум. Слабые модели либо не отказываются вообще, либо отказываются слишком часто — и то, и другое снижает качество.

4) Рост контекста. Да, абсолютно так. В Sequential контекст растёт линейно: каждый следующий агент видит выходы всех предыдущих. При N=16 это управляемо, при N=256 — потенциальная проблема. На практике два механизма сдерживают рост: (1) самоотвод ~45% агентов при больших N сокращает объём контента, (2) выходы предшественников передаются в сжатом виде. Но вы правы — при O(N) это узкое место, и batched sequential (группы по K агентов параллельно) — следующий шаг. P.S. Спасибо за идею — сделаю в статье отдельный раздел про вызовы таких протоколов.

Спасибо за комментарий! Кажется, мы про разное.

Статья не про промпты и не про то, как запускать одного агента. Она про координацию — как группа из 4–256 агентов решает задачу вместе, и какой протокол взаимодействия даёт лучший результат. 25 000 задач, 8 моделей, статистика — это как раз попытка выйти из вакуума и проверить гипотезы на данных.

Если у вас есть опыт координации нескольких агентов через gstack — было бы интересно сравнить подходы.