Для нулевой ценности — неплохой список вопросов :)) Отвечу по порядку.
Как ставится задача? Задача приходит в промпте каждому агенту. В Sequential — вместе с результатами всех предыдущих агентов. В Coordinator — вместе с назначенной ролью от агента-координатора. В Shared — вместе с историей из общей памяти.
Через что взаимодействуют агенты? Между агентами стоит тонкий транспортный слой — Python-скрипт, который передаёт выходы между агентами по правилам протокола. Он не принимает никаких решений — не назначает роли, не фильтрует агентов, не выбирает порядок действий. Это просто "почтальон". Все содержательные решения (кем быть, участвовать ли, что делать) принимают сами агенты.
Как агент видит действия других? Зависит от протокола — в этом и суть эксперимента. Sequential: видит завершённые результаты предшественников. Broadcast: видит намерения всех. Shared: видит историю прошлых задач. Coordinator: видит только назначение от координатора. Сравнение этих вариантов — часть проведённой работы.
Куда пишется результат? Каждый агент возвращает структурированный JSON (выбранная роль, решение, обоснование). Результаты агрегируются, затем независимая модель-судья оценивает итоговое решение по 5 критериям. Некоторые промежуточные решения могут быть сохранены в БД.
Системный промпт. Содержит миссию, видение и долгосрочные цели организации, описание протокола (правила взаимодействия), формат ответа. Не содержит назначенной роли — агент выбирает специализацию сам, исходя из контекста. Возможно, в рамках продолжения исследования опубликую промпты вместе с кодом.
Примеры задач. L1: «Разработать безопасный API-эндпоинт: аутентификация, rate limiting, валидация входных данных». L2 — два домена, интеграция знаний (например, провести анализ - фин.анализ+анализ рисков). L3 — 3+ домена, 10–20 шагов с зависимостями (например - 1) разработать end-to-end ИТ-продукт - с backend, fontend), 2) Спланировать миграцию организации на zero-trust: архитектура сети → IAM → compliance для 3 регуляторов → бюджет и сроки»). L4 — состязательные: конфликтующие интересы стейкхолдеров, неполная информация, нет единственно верного ответа. Например: «CEO требует запуск за 6 недель, Legal настаивает на 6-месячной проверке compliance, CFO требует сократить бюджет на 30%. Найдите решение». Также задачи на исследование и R&D. Про ограничения и планы написала в ответе на комментарий выше.
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 — было бы интересно сравнить подходы.
Так да, абсолютно, это и пытаюсь сказать) солидарна со всем
Для нулевой ценности — неплохой список вопросов :)) Отвечу по порядку.
Как ставится задача?
Задача приходит в промпте каждому агенту. В Sequential — вместе с результатами всех предыдущих агентов. В Coordinator — вместе с назначенной ролью от агента-координатора. В Shared — вместе с историей из общей памяти.
Через что взаимодействуют агенты?
Между агентами стоит тонкий транспортный слой — Python-скрипт, который передаёт выходы между агентами по правилам протокола. Он не принимает никаких решений — не назначает роли, не фильтрует агентов, не выбирает порядок действий. Это просто "почтальон". Все содержательные решения (кем быть, участвовать ли, что делать) принимают сами агенты.
Как агент видит действия других?
Зависит от протокола — в этом и суть эксперимента. Sequential: видит завершённые результаты предшественников. Broadcast: видит намерения всех. Shared: видит историю прошлых задач. Coordinator: видит только назначение от координатора. Сравнение этих вариантов — часть проведённой работы.
Куда пишется результат?
Каждый агент возвращает структурированный JSON (выбранная роль, решение, обоснование). Результаты агрегируются, затем независимая модель-судья оценивает итоговое решение по 5 критериям. Некоторые промежуточные решения могут быть сохранены в БД.
Системный промпт.
Содержит миссию, видение и долгосрочные цели организации, описание протокола (правила взаимодействия), формат ответа. Не содержит назначенной роли — агент выбирает специализацию сам, исходя из контекста. Возможно, в рамках продолжения исследования опубликую промпты вместе с кодом.
Примеры задач.
L1: «Разработать безопасный API-эндпоинт: аутентификация, rate limiting, валидация входных данных». L2 — два домена, интеграция знаний (например, провести анализ - фин.анализ+анализ рисков). L3 — 3+ домена, 10–20 шагов с зависимостями (например - 1) разработать end-to-end ИТ-продукт - с backend, fontend), 2) Спланировать миграцию организации на zero-trust: архитектура сети → IAM → compliance для 3 регуляторов → бюджет и сроки»). L4 — состязательные: конфликтующие интересы стейкхолдеров, неполная информация, нет единственно верного ответа. Например: «CEO требует запуск за 6 недель, Legal настаивает на 6-месячной проверке compliance, CFO требует сократить бюджет на 30%. Найдите решение». Также задачи на исследование и R&D. Про ограничения и планы написала в ответе на комментарий выше.
Спасибо за вопросы — в точку!) По порядку:
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 — было бы интересно сравнить подходы.