TL;DR
Исследование сравнило четыре «ступени» одной и той же задачи: один запрос к модели без агентов, один агент, два агента и полноценная мультиагентная цепочка. Лучшая точность чаще всего получалась на самой простой ступени. На пяти задачах разработки (генерация кода, поиск технического долга, поиск уязвимостей, разбор логов, анализ логов) простой запрос выиграл по точности в четырёх. Мультиагентная схема выиграла только в поиске уязвимостей.
Боль знакомая: вы строите команду из «программиста, ревьюера и тестировщика», а она работает в среднем в 6 раз дольше и жрёт в 6 раз больше ресурсов, чем один запрос. В худших случаях разница достигала 160 раз. Точность при этом почти не растёт. Каждый новый агент добавляет круг обмена текстом, а длинные контексты и повторные вызовы умножают стоимость. Качество они умножают не всегда.
Вывод для практики: двигайтесь по лесенке снизу вверх. Сначала один хороший запрос и проверка на своих примерах. Следующую ступень берите, только если видите в цифрах, что она даёт прирост именно на вашей задаче. Модель и формулировка промпта при этом влияют сильнее, чем число агентов. Одна смена стратегии промпта подняла точность разбора логов с 3,4% до 54,3%.
Схема метода
В статье нет промпта-шаблона. Это сравнение конфигураций, и вывод сводится к порядку выбора:
СТУПЕНЬ 0: один запрос, одна модель, без агентов → замерить точность на 10–20 своих примерах
СТУПЕНЬ 1: один агент (с проверкой или инструментом) → замерить; лучше ступени 0 на вашей задаче?
СТУПЕНЬ 2: два агента (исполнитель + проверяющий) → замерить; оправдывает ли рост времени?
СТУПЕНЬ 3: мультиагентная цепочка → брать только при явном приросте на вашей задаче
Остановка: как только следующая ступень не даёт заметного прироста, остаёмся на предыдущей. Параллельно подбираем промпт и модель под задачу: у них эффект сильнее, чем у числа агентов.
Пример применения
Сильная зона вывода: типовая рабочая задача, где можно быстро проверить результат. Например, разбор логов.
Задача: Команда небольшого маркетплейса на Wildberries-API разбирает ночные логи сервиса оплаты. Нужно вытащить из сырых строк структуру: время, сервис, код ошибки, ID заказа. Кто-то предлагает «сделать красиво»: агент-парсер, агент-проверяющий и агент-аналитик. Вместо этого проходим по лесенке.
Промпт (ступень 0, один запрос):
Ты разбираешь логи сервиса оплаты интернет-магазина.
Для каждой строки лога верни JSON с полями:
timestamp, service, level, error_code, order_id, message_template.
Переменные части (ID заказа, суммы в рублях, IP) замени в
message_template на плейсхолдеры , , .
Если поле не найдено, пиши null. Ничего, кроме JSON, не выводи.
Примеры:
2025-03-14 02:11:07 payment-gw ERROR E402 order=88231 sum=1490 timeout
→ {"timestamp":"2025-03-14 02:11:07","service":"payment-gw","level":"ERROR","error_code":"E402","order_id":"88231","message_template":"order= sum= timeout"}
Логи:
{строки_логов}
Результат: Модель выдаст JSON по каждой строке, шаблоны сообщений будут с плейсхолдерами. Дальше возьмите 20 строк, где правильный ответ вы знаете, и сравните. Если точность устраивает, останавливайтесь: вы получили результат в разы быстрее и дешевле цепочки агентов. Если нет, сначала меняйте формулировку и примеры, потому что эффект промпта в исследовании был самым большим. Только потом добавляйте второго агента-проверяющего и снова замеряйте.
Почему это работает
Слабость. Каждый дополнительный агент — это ещё один круг генерации текста. Контекст растёт, вызовов становится больше, время и стоимость идут вверх почти пропорционально: энергия и задержка в исследовании сцеплены почти идеально. Качество же растёт не обязательно. Агенты могут пересказывать друг другу ту же ошибку или «исправлять» верный ответ.
Сильная сторона. Современные модели часто решают задачу за один проход, если правильно поставить задачу и показать формат. Поэтому большая часть выгоды лежит в промпте и выборе модели, а не в оркестровке.
Как метод использует это. Лесенка заставляет платить за сложность только там, где вы её измерили. Мультиагентность в исследовании оказалась полезной в поиске уязвимостей. Там второй взгляд действительно находит то, что первый пропустил. Вывод: прирост зависит от задачи, и «агенты — это всегда лучше» не работает.
Рычаги управления: - Число агентов: убирайте по одному, пока точность не начнёт падать. - Стратегия промпта: пробуйте разные формулировки на одной выборке, разброс может быть огромным. - Модель: универсального победителя нет, перепроверяйте под каждую задачу. - Размер проверочной выборки: 10–20 примеров с известным ответом уже дают ориентир.
Шаблон промпта
В статье готовых промптов нет. Ниже наш рабочий инструмент по логике её вывода, а не авторский метод. Он помогает решить, нужны ли агенты.
Я хочу решить задачу: {задача}.
Критерий правильного ответа: {критерий}.
Мои тестовые примеры (с известным ответом): {примеры}.
Помоги пройти «лесенку сложности»:
1. Напиши лучший однозапросный промпт для этой задачи (без ролей и агентов).
2. Напиши вариант с одним проверяющим шагом («проверь свой ответ по критерию»).
3. Напиши вариант с двумя ролями: исполнитель и независимый проверяющий.
4. Для каждого варианта дай таблицу: ожидаемое время, число вызовов, на что смотреть при сравнении.
5. Скажи, при каком результате на моих примерах стоит остановиться на более простом варианте.
Не предлагай более сложную схему, если простая справляется.
Плейсхолдеры: {задача} — рабочая задача, {критерий} — как отличить верное от неверного, {примеры} — 10–20 образцов с эталоном.
🚀 Быстрый старт — вставь в чат:
Вот шаблон лесенки сложности. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про критерий правильного ответа и про тестовые примеры, потому что без них нельзя честно сравнить ступени. Остальное она возьмёт из шаблона.
Ограничения
⚠️ Модели не самые новые: тестировали открытые модели семейств Gemma, Qwen и DeepSeek-Coder. Как всё это выглядит на современных закрытых моделях и на моделях с «длинным рассуждением», статья не показывает.
⚠️ Нет универсального ответа: мультиагентность помогла в поиске уязвимостей. Если ваша задача из того же класса «найди то, что легко пропустить», проверяйте второго агента на практике, не отбрасывайте заранее.
⚠️ Измеряли энергию, а не вашу стоимость: прямой перенос на токены и рубли в API вероятен, но цифры 6× и 160× относятся к их оборудованию и задачам.
⚠️ Узкий набор задач: пять задач разработки и четыре набора данных. Для текстов, продаж и поддержки вывод разумен, но в статье не проверялся.
⚠️ Нет готовых промптов: авторы дают принципы дизайна, а не инструкции для агента. Чтобы применить, придётся измерять самим.
⚠️ Неполный текст: описание конфигураций и двух стратегий промпта в доступной части обрывается, поэтому детали конкретных агентных ролей здесь не разобраны.
Как исследовали
Команда из норвежского SINTEF и университетов Сингапура и Турции взяла пять рабочих задач разработчика. Задачи проверяли на четырёх наборах данных: HumanEval, MLCQ, PrimeVul и логи HDFS. Для каждой задачи построили четыре ступени сложности: один запрос, один агент, два агента и мультиагентная цепочка. Прогнали их через шесть открытых моделей, две стратегии промпта и три вида железа: рабочую станцию и два мощных сервера, один с 8 видеокартами H100. Всего получилось 1840 запусков. Измеряли точность, время ответа и потреблённую энергию.
Главный приём анализа — «фронт Парето». Это набор конфигураций, которые нельзя улучшить по одному показателю, не ухудшив другой. Из 66 таких «разумных» конфигураций лишь одна оказалась мультиагентной, 36 были вообще без агентов, 59 — лёгкими (без агентов или с одним). Мультиагентные схемы в среднем в 6,36 раза дороже по энергии и в 6,07 раза медленнее.
Удивили два результата. Во-первых, энергия и время почти идеально связаны (коэффициент 0,987), так что экономия одного означает экономию другого. Во-вторых, выбор промпта оказался сильнее выбора архитектуры: в разборе логов точность прыгала от 3,4% до 54,3%. Железо важно для тяжёлых схем: на мультиагентной конфигурации мощный сервер был в 3,4 раза быстрее рабочей станции.
Адаптации и экстраполяции
🔧 Техника: добавить критерий остановки → агент не усложняет сам себя
В файл инструкций агента (CLAUDE.md, AGENTS.md) можно добавить правило по духу вывода статьи. Это наша адаптация, в исследовании её не проверяли:
Сначала реши задачу самым простым способом: один проход, без делегирования подзадач.
Подключай субагентов или дополнительные проверки, только если задача явно разбивается на независимые части
или первый проход не прошёл проверку. Объясни одной строкой, зачем нужна дополнительная ступень.
Прирост от такого правила нужно проверить на ваших задачах.
Ресурсы
- Engineering Sustainable Agents: A Systematic Comparison of Agentic LLMs for Developer Workflows. Авторы: Merve Astekin, Yan Naing Tun, Arda Goknil, Erik Johannes Husom, Lwin Khin Shar, Hasan Sözer, Ratnadira Widyasari, Hui Song. Организации: SINTEF (Норвегия), Singapore Management University, Ozyegin University (Турция).
- Наборы данных из статьи: HumanEval, MLCQ, PrimeVul, LogHub (HDFS).
- В тексте упомянута работа Xia et al. о том, что неагентный трёхшаговый подход (локализация, исправление, проверка патча) может обходить сложные агенты на SWE-bench Lite.