Supervisor–worker, context engineering и спор о multi-agent

Паттерн supervisor–worker

Supervisor (руководитель, он же orchestrator) принимает запрос, решает, какому исполнителю его отдать, передаёт и затем проверяет и собирает результат. Worker (исполнитель, sub-agent) делает узкую работу со своими tools (инструментами) и меньшим context (всем, что модель видит за вызов). Для поддержки клиентов банка: supervisor направляет запрос в worker по картам (блокировка, перевыпуск, лимиты), по спорам (открыть, отследить) и по продуктам (RAG, поиск по документам тарифов).

Anthropic в «Building effective agents» называет пять родственных паттернов, их стоит знать по именам: prompt chaining (фиксированные шаги подряд), routing (классифицировать и отдать одному обработчику), parallelization (части параллельно, потом свести), orchestrator–workers (наш supervisor) и evaluator–optimizer (одна модель делает, другая критикует, по кругу).

Context engineering: почему вообще делят

Anthropic определяет context engineering как набор стратегий, чтобы держать в context модели оптимальный набор tokens (кусков слов) на каждом шаге. Причина — context rot (порча длинного context): чем больше tokens в окне, тем хуже модель вспоминает нужное из него. У модели есть «attention budget» (бюджет внимания): каждый token может смотреть на каждый, это n² пар, и каждый лишний token этот бюджет тратит. Принцип статьи: найти наименьший набор tokens с высоким сигналом.

Для длинных задач статья даёт три приёма. Compaction (сжатие): когда окно почти заполнено, свести разговор в сводку и продолжить с неё; самая лёгкая форма — убрать старые результаты tools. Structured note-taking (заметки вне окна): агент пишет заметки в файл и читает их, когда нужно. Sub-agent architectures (под-агенты): узкая задача решается в чистом context, а руководителю возвращается сжатая сводка, по статье обычно 1 000–2 000 tokens. Последний приём — и есть главный довод за multi-agent: не «больше умов», а чистый context у каждого.

Сторона против: Cognition, «Don't Build Multi-Agents»

Статья Walden Yan (Cognition, июнь 2025) формулирует два принципа:

1. «Share context, and share full agent traces, not just individual messages» — делись context и полными журналами работы агента, а не отдельными сообщениями.
2. «Actions carry implicit decisions, and conflicting decisions carry bad results» — каждое действие несёт неявные решения, а конфликтующие решения дают плохой результат.

Пример оттуда: задачу «сделай клон Flappy Bird» делят на двух под-агентов. Один рисует фон, другой птицу. Первый понял задачу не так и нарисовал фон в стиле Super Mario Bros., второй сделал птицу, которая не подходит ни по стилю, ни по движению. Финальному агенту остаётся склеивать несовместимое. Вывод Cognition: самый простой способ соблюсти оба принципа — single-threaded linear agent (один агент, идущий по задаче последовательно), у которого context непрерывен. Для очень длинных задач они предлагают отдельную модель, которая сжимает историю в ключевые решения, и признают, что это трудно сделать хорошо.

Сторона за: Anthropic, multi-agent research system

Статья Anthropic (июнь 2025) описывает систему для исследовательских запросов по схеме orchestrator–worker: lead agent (ведущий агент) планирует и запускает несколько subagents, которые ищут параллельно. Ведущий на Claude Opus 4, исполнители на Claude Sonnet 4. На внутренней оценке исследовательских задач система обошла одиночный Claude Opus 4 на 90,2%. Цена тоже названа: агенты тратят примерно в 4 раза больше tokens, чем чат, а multi-agent — примерно в 15 раз. На BrowseComp (оценка поиска трудной информации в вебе) три фактора объяснили 95% разброса результатов, и один расход tokens — 80%. Там же честная граница: плохо подходят задачи, где всем агентам нужен общий context или много взаимных зависимостей; в большинстве задач программирования по-настоящему параллельных частей меньше, чем в исследовании.

Как примирить: обе стороны говорят одно

Спор меньше, чем кажется. Исследование хорошо делится: под-агенты читают разные источники, ничего не меняют в мире и возвращают находки, которые не конфликтуют друг с другом. Программирование и любые связанные действия делятся плохо: каждое действие принимает неявные решения, и их надо видеть целиком. Правило: делить можно чтение вширь, нельзя — связанные решения.

Пример бюджета: чат-ответ стоит 5 000 tokens. При 10 000 запросах в день это 50 миллионов tokens. Тот же поток через multi-agent при множителе 15× — около 750 миллионов tokens в день. Такой рост окупается только там, где задача ценна и действительно параллельна; для справки о тарифе он не окупается.

Суждение и оценка

Начинай с одного агента. Дели, только когда измеренная причина этого требует (context переполняется, tools слишком много, права надо разделить) и части независимы. Где намерения чёткие (карты / споры / продукты), routing делают правилами или маленьким classifier (классификатором), а LLM — только для неоднозначных запросов: меньше случайных шагов — стабильнее система. Ещё один плюс разделения — узкие права: worker по продуктам физически не может заблокировать карту. Если всё же делишь, лечи главную болезнь, потерю context при handoff (передаче задачи), по первому принципу Cognition: worker получает не одну строку «сделай фон», а бриф — цель всей задачи, уже принятые решения (стиль, ограничения, формат), границы своей части и формат ответа. Чем больше связанных решений приходится пересказывать в брифе, тем сильнее довод не делить вовсе. И отчёт worker — это утверждение, а не факт: supervisor проверяет его, а не верит на слово.

Оценивают три уровня: routing отдельно (верный ли worker для каждого запроса — простая accuracy, доля верных, на размеченном наборе), каждый worker на своих задачах, система целиком. Если результаты нестабильны, первым смотри routing: один шаг, который меняется между прогонами, раскачивает весь путь.