TL;DR
MAS-Algorithm — это структура из пяти специализированных ролей, которая разбивает решение сложной задачи на этапы: выбор подхода → поиск знаний → логика → реализация → проверка ошибок. Ключевая механика — роутинг обратной связи: агент-проверщик не просто говорит "неправильно", а решает, нужно ли локально починить баг (FIX) или переосмыслить весь подход с нуля (RETHINK).
Когда LLM решает сложную задачу за один запрос, она смешивает в одну кашу: неправильный выбор метода, логические дыры, ошибки реализации. Исправление "в лоб" часто приводит к тому, что модель латает поверхность, не меняя сломанного фундамента — и ходит по кругу.
Метод разрывает этот круг через три вещи: явное разделение ролей (разные агенты — разные задачи), таксономию ошибок (структурированный чеклист частых провалов для агента-проверщика) и двухуровневый сигнал FIX / RETHINK, который направляет исправление к правильному агенту.
Схема метода
[Отдельные запросы — последовательная цепочка]
ШАГ 1 (Agent1 — Выбор подхода):
Вход: описание задачи
→ Выбрать метод/стратегию из списка кандидатов + обоснование
→ Можно несколько веток (если задача допускает разные подходы)
ШАГ 2 (Agent2 — Поиск знаний):
Вход: задача + выбранный подход
→ Найти и суммировать релевантные знания/референсы
[В оригинале: RAG-пайплайн. В чате: попросить LLM собрать
из памяти или дать контекст вручную]
ШАГ 3 (Agent3 — Логик):
Вход: задача + подход + знания
→ Пошаговый план решения (анализ + шаги, при нужде — псевдокод)
→ В режиме RETHINK: переписать план с учётом фидбека
ШАГ 4 (Agent4 — Исполнитель):
Вход: план + задача
→ Конкретный результат (текст, код, структура...)
→ В режиме FIX: локально поправить конкретную проблему
ШАГ 5 (Agent5 — Проверщик ошибок):
Вход: задача + план + результат + чеклист ошибок
→ Структурированный отчёт: анализ / идентификация ошибки /
рекомендация / сигнал
→ Сигнал: PASS (готово) / FIX (→ Agent4) / RETHINK (→ Agent3)
ЦИКЛ: повторять Agent5 → роутинг до PASS или лимита итераций
Пример применения
Сильная зона метода: сложные задачи с несколькими слоями потенциальных ошибок, где важно разделить "неправильный подход" и "плохое исполнение правильного подхода". Слабая зона — простые задачи с одним очевидным решением.
Задача: Фаундер хочет проверить юнит-экономику своего SaaS-продукта перед встречей с венчурным фондом. Он дал LLM данные и получил таблицу расчётов, но не уверен — правильно ли выбрана модель и нет ли дыр в логике.
Промпт (Agent5 — Проверщик):
Ты — строгий аналитик. Твоя задача — проверить решение задачи и вынести вердикт.
ЗАДАЧА:
Проверить юнит-экономику подписочного SaaS. Продукт: платформа для автоматизации HR.
Тариф: 15 000 ₽/мес. Средний цикл продажи: 45 дней. CAC: 32 000 ₽.
LTV нужно считать с учётом churn 4% в месяц и расходов на поддержку 1 500 ₽/мес на клиента.
ТЕКУЩЕЕ РЕШЕНИЕ:
LTV = 15 000 × 12 = 180 000 ₽
LTV/CAC = 180 000 / 32 000 = 5.6 — хорошо
ПЛАН РАСЧЁТА (от автора):
Считали LTV как фиксированный годовой доход без учёта churn.
ПРОВЕРЬ по чеклисту типичных ошибок:
[ ] Неправильная формула (churn не учтён → LTV завышен)
[ ] Не вычтены переменные расходы (поддержка, транзакции)
[ ] Неверный временной горизонт (годовой vs пожизненный)
[ ] Несоответствие плана и результата
[ ] Граничные случаи: что если churn вырастет до 7%?
Твой ответ — структурированный отчёт:
1. АНАЛИЗ: соответствует ли решение задаче и плану?
2. ОШИБКИ: какие найдены и почему они критичны?
3. РЕКОМЕНДАЦИИ: как исправить?
4. СИГНАЛ: PASS / FIX / RETHINK
— FIX: ошибка локальная, подход верный
— RETHINK: сломан фундаментальный подход, нужно переосмыслить
Результат:
Модель выдаст структурированный отчёт: пройдётся по каждому пункту чеклиста, найдёт конкретную ошибку (LTV без churn — классический завышенный расчёт), объяснит почему это критично для инвестора, и вынесет сигнал FIX — подход (юнит-экономика) правильный, но формула сломана. После этого агенту-исполнителю можно дать конкретную задачу: пересчитать по правильной формуле LTV = ARPU / churn_rate - cost_per_customer.
Почему это работает
Слабость LLM: При попытке решить сложную задачу и сразу проверить себя модель застревает в confirmation bias — она склонна защищать уже написанное, а не критиковать. Когда проверку делает тот же "голос", что писал — она поверхностна.
Сильная сторона LLM: Модель отлично справляется с чётко очерченной ролью. Если промпт говорит "ты — критик, твоя задача найти ошибки по этому чеклисту", она ведёт себя иначе, чем когда говорит "напиши и проверь сам".
Как метод это использует: Разделение ролей убирает конфликт интересов. Каждый агент получает узкую задачу без инструкции "сохрани предыдущий результат". FIX vs RETHINK — это не просто ярлыки. Это инструкция, куда направить итерацию: к исполнителю (локальная правка) или к логику (новый план). Без этого различия модели часто пытаются починить следствие, не трогая причину.
Рычаги управления: - Чеклист ошибок → добавляй под свою область (финансы, тексты, стратегия) - Число итераций → 2-3 цикла для большинства задач; 5+ дают убывающую отдачу - Сигналы роутинга → можно добавить третий сигнал, например ESCALATE — "задача за пределами моих возможностей" - Параллельные ветки в Agent1 → попроси выдать 2-3 разных подхода, запусти параллельно, сравни на Agent5
Шаблон промпта
Самый universally полезный элемент — Agent5 (Проверщик). Используй в любом рабочем цикле:
Ты — строгий проверщик. Твоя роль — найти ошибки, не защищать результат.
ЗАДАЧА:
{опиши что нужно было сделать}
ТЕКУЩИЙ ПЛАН/ПОДХОД:
{опиши какой метод/логика использовались}
ТЕКУЩИЙ РЕЗУЛЬТАТ:
{вставь то что получилось}
ПРОВЕРЬ по чеклисту типичных ошибок для {область задачи}:
[ ] {ошибка 1}
[ ] {ошибка 2}
[ ] {ошибка 3}
[ ] Несоответствие плана и результата
[ ] Граничные случаи: {что может пойти не так в крайних условиях}
Структура ответа:
1. АНАЛИЗ: соответствует ли результат задаче и плану?
2. ОШИБКИ: какие найдены, почему критичны?
3. РЕКОМЕНДАЦИИ: конкретные шаги для исправления
4. СИГНАЛ:
— PASS: результат качественный, можно использовать
— FIX: подход верный, нужно исправить конкретное место → что именно
— RETHINK: фундаментальный подход неверный → что пересмотреть
Плейсхолдеры:
- {опиши что нужно было сделать} → оригинальная задача
- {текущий план/подход} → какую логику или метод использовали
- {текущий результат} → то что получилось (текст, расчёт, план)
- {область задачи} → финансы / маркетинг / юридика / стратегия и т.д.
- {ошибка 1-3} → типичные провалы в вашей области (см. пример выше)
🚀 Быстрый старт — вставь в чат:
Вот шаблон метода MAS-Algorithm (агент-проверщик).
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какие типичные ошибки характерны для твоей области и что именно проверять в чеклисте — потому что без этого сигнал FIX/RETHINK будет пустым. Она возьмёт паттерн из шаблона и адаптирует его под твою конкретную задачу.
Ограничения
⚠️ Итерации с убывающей отдачей: После 3 циклов исправлений прирост резко падает. Оставшиеся ошибки — обычно системные: модель просто не может их решить через подсказки.
⚠️ Самокоррекция не всегда работает: Даже с подробной таксономией ошибок и сигналом RETHINK модель иногда продолжает воспроизводить один и тот же неправильный подход. Исследователи наблюдали это явно — некоторые паттерны ошибок не лечатся итеративными промптами.
⚠️ Agent2 требует инфраструктуры: Шаг поиска знаний в оригинале — это RAG-пайплайн с векторной базой. В чате его можно заменить вручную: подать нужные знания текстом. Но это ручная работа.
⚠️ Полная система не для чата: MAS-Algorithm в оригинале — автоматизированный пайплайн с Docker, JSON-инструментами и API. В чате применяешь принципы (FIX/RETHINK, роли, чеклист), не всю архитектуру.
⚠️ Средние модели выигрывают больше: Крупные модели (235B параметров) получают скромный прирост ~4-5%, потому что уже хорошо справляются в "лоб". Воркфлоу даёт максимум тем, кто без него "плавает".
Как исследовали
Исследователи из Пекинского университета и Alibaba взяли пять моделей семейства Qwen разного размера — от 8B до 235B параметров — и сравнили два режима: прямой запрос ("реши задачу") vs полный воркфлоу MAS-Algorithm. Тестовый датасет — алгоритмические задачи из внутренней базы стажёров Alibaba, дополнительно проверяли на LiveCodeBench-Pro (реальные задачи с соревнований, Q4 2024 — Q2 2025).
Самый любопытный сравнительный эксперимент — против fine-tuning. Ту же модель (Qwen3-Coder-30B) обучили через LoRA на тех же данных. Результат: fine-tuning дал +0.89% к точности. Воркфлоу без обучения дал +6.62%. Это сильный аргумент: структурированный промпт-воркфлоу заменил обучение в условиях одинаковых данных.
Команда также отследила поведение по итерациям. Оказалось, что точность стабильно растёт до 3-й итерации, потом падает — многие решения проходят тестовые примеры, но ломаются на полном наборе тестов. Это инсайт: итерация лечит поверхностные баги, но не глубинные ошибки логики. Самые частые причины провала — неправильная абстракция задачи и непонимание ограничений (сложность алгоритма). И никакой чеклист не помог заставить модели "увидеть" эти ошибки самостоятельно.
Адаптации и экстраполяции
🔧 Техника: только FIX/RETHINK без всего воркфлоу
Самый портативный элемент системы — двойной сигнал обратной связи. Применяй его в любом рабочем цикле:
После получения результата от LLM добавь в следующий промпт: "Найди главную проблему в этом тексте/расчёте/плане. Определи: это FIX (локальная правка без изменения подхода) или RETHINK (нужно переосмыслить с нуля)? Объясни почему."
Это мгновенно повышает качество самокритики — модель вынуждена решить, насколько глубока ошибка, прежде чем предлагать исправление.
🔧 Техника: чеклист ошибок под свою область
Agent5 работает хорошо потому что получает структурированный список того, где обычно ломается. Создай свой чеклист один раз и используй постоянно:
Стандартные ошибки в [маркетинговом тексте / финансовой модели /
юридическом документе / питч-деке]:
[ ] {типичная ошибка 1 для вашей области}
[ ] {типичная ошибка 2}
[ ] Несоответствие заявленной цели и реального содержания
[ ] Отсутствие конкретики там, где читатель ждёт цифры/факты
[ ] Граничный случай: что если {худший сценарий для вашей задачи}?
Попроси LLM составить такой чеклист для твоей области — она сделает 80% работы сама.
Экстраполяция: двухэтапный воркфлоу для сложных решений
Если не хочешь запускать пять агентов, возьми минимальную версию из двух шагов:
ШАГ 1 — ПЛАН:
Ты — стратег. Задача: {описание задачи}.
Не решай сразу. Выбери подход: какой метод/структуру использовать и почему.
Опиши план пошагово. Псевдокодом если нужно.
---
ШАГ 2 — РЕАЛИЗАЦИЯ + ПРОВЕРКА:
Вот задача и план: [вставить из шага 1]
Реализуй план. После реализации — проверь сам по чеклисту:
[ ] Соответствует ли результат плану?
[ ] Есть ли пропущенные граничные случаи?
[ ] Можно ли улучшить без смены подхода?
Сигнал: PASS / нужен FIX (что именно) / нужен RETHINK (что не так в плане)
Разрыв между планированием и исполнением — ключевая механика, которую можно воспроизвести в двух запросах без всей инфраструктуры.
Ресурсы
Статья: MAS-Algorithm: A Workflow for Solving Algorithmic Programming Problems with a Multi-Agent System
Авторы: Yuliang Xu, Xiang Xu, Yao Wan, Hu Wei, Tong Jia
Организации: Peking University, Alibaba Group, Huazhong University of Science and Technology
Связанные методы из статьи: MapCoder, AgentCoder, MetaGPT, AutoGen, Chain-of-Thought prompting
База знаний из исследования: OI-WIKI (oi-wiki.org) — репозиторий алгоритмических знаний