Content is user-generated and unverified.

MapReduce как паттерн для мультиагентных систем кодинга — путеводитель 2026

TL;DR

  • MapReduce — полезная, но дырявая метафора для LLM-агентов. Форма fan-out/fan-in аккуратно ложится на «embarrassingly parallel» задачи: ревью N файлов, поиск по N веткам кода, генерация N вариантов. Anthropic именно так и реализовал свою фичу Research — lead-агент + параллельные Sonnet-воркеры, +90.2% к одиночному Opus на внутренних эвалах, но при ~15× стоимости в токенах относительно чата. Метафора ломается в момент, когда нужно сходиться на записи: LLM недетерминированы, у «shuffle» нет чистого аналога, когда промежуточные выходы — это интерпретации на естественном языке, а не (key, value) кортежи, и reduce (синтез) часто оказывается самой сложной частью всей работы.
  • Индустриальный консенсус 2025–2026 уже́ — чем хайп. После «Don't Build Multi-Agents» от Cognition (июнь 2025) и их апрельского follow-up «Multi-Agents: What's Actually Working» практики в основном согласны: параллельные read-субагенты (поиск, исследование, ревью) — реальный win; параллельные writer-агенты без единого источника истины — всё ещё хрупкие. Доминирующий рабочий паттерн теперь — map-reduce-and-manage: один writer, один оркестратор, плюс read-only intelligence-агенты, которые поставляют контекст (Advisor от Anthropic, Devin Review, Oracle в Amp, planners-and-judges в Cursor — всё это инстансы одной идеи).
  • Практическая эвристика: параллелить, когда (а) подзадачи действительно независимы, (б) результаты можно reduce'нуть кодом или judge-агентом со свежим контекстом, и (в) ценность × success-rate оправдывает 4–15× счёт за токены. По умолчанию — один агент с длинным контекстом, пока нет доказательств бутылочного горлышка. Чем умнее модели (Opus 4.6/4.7, GPT-5.x), тем выше планка «нужно несколько агентов» — Boris Cherny отмечает, что «стафф, который раньше был обвязкой, всё больше уезжает внутрь самой модели».

Ключевые находки

  1. Два лагеря опубликовали противоположно звучащие манифесты в один и тот же день в июне 2025. «How we built our multi-agent research system» от Anthropic и «Don't Build Multi-Agents» от Cognition разошлись в тактике, но сошлись в подлежащей правде: главная проблема — это context engineering, и наивные мультиагентные архитектуры падают, потому что фрагментируют контекст и принятие решений.
  2. К апрелю 2026 поле сошлось на более узком паттерне. Follow-up Walden Yan «Multi-Agents: What's Actually Working» прямо благословляет то, что он называет «map-reduce-and-manage» — менеджер декомпозирует, дети исполняют, менеджер синтезирует — и отвергает неструктурированные swarm'ы. Общее правило: дополнительные агенты должны вкладывать интеллект, а не действия; запись остаётся однопоточной.
  3. У метафоры MapReduce есть и глубокое совпадение, и глубокое расхождение с LLM. Совпадает на embarrassingly parallel exploration, где у каждого шарда — свой контекст. Ломается, потому что LLM-овский reduce требует синтеза в условиях неопределённости, ретраи не дают идентичных выходов (нет идемпотентности), и нет автоматического shuffle по ключу.
  4. «Agent harness» теперь считается важнее модели. Boris Cherny (Claude Code), Erik Schluntz (Anthropic), эксперимент Carlini с C-компилятором, разбор harness engineering от OpenAI — все говорят одно и то же: цикл, верификатор и контекстная обвязка вокруг LLM определяют, выйдет ли из всего этого полезная работа.
  5. Реальные бенчмарки существуют — и они отрезвляющие. Research-система Anthropic «Opus-lead + Sonnet-воркеры»: +90.2% на breadth-first research, ~15× токенов по сравнению с чатом. Advisor tool от Anthropic (апрель 2026): Sonnet+Opus advisor +2.7pp на SWE-bench Multilingual при −11.9% стоимости; Haiku+Opus advisor — прыжок 19.7% → 41.2% на BrowseComp. Эксперимент Carlini с C-компилятором: 16 параллельных Claude-агентов, ~2,000 сессий, ~$20,000, 100K-строчный рабочий компилятор (но медленнее, чем GCC -O0). Эксперимент Cursor с «browser swarm» на 1M строк подвергся жёсткой критике за то, что итоговый репозиторий даже не собирался чисто — полезное напоминание: объём токенов ≠ работающий софт.
  6. Почти каждый крупный coding-агент сейчас имеет фичу параллельных субагентов, но реализации различаются в важных деталях (лимиты конкурентности, шаринг контекста, механизм изоляции, контроль модели на агента). Конкретные инвокации — в следующих секциях.

Детали

1. Метафора MapReduce: откуда она и почему соблазняет дизайнеров агентов

MapReduce, представленный Jeffrey Dean и Sanjay Ghemawat в Google на OSDI 2004 («MapReduce: Simplified Data Processing on Large Clusters»), — это модель программирования с очень специфичными инвариантами:

  • Map: stateless, детерминированная функция (k1, v1) → list(k2, v2), применяемая независимо к каждому шарду.
  • Shuffle: рантайм группирует промежуточные значения по ключу — это автоматически, нетривиально и не пишется пользователем.
  • Reduce: функция (k2, list(v2)) → list(v3), применяемая на ключ.
  • Fault tolerance через re-execution: любой упавший mapper или reducer можно перезапустить на другой машине и он обязан выдать тот же ответ. Это требует детерминированных функций без сайд-эффектов.

Последнее свойство — то, которое LLM-аналогия тихо роняет. Форма fan-out/fan-in выживает, но все остальные инварианты слабеют:

Инвариант MapReduceРеальность LLM-агентов
Stateless, детерминированные mapper'ыСтохастическая генерация; ретраи расходятся
Shuffle по ключуАвтоматического ключа нет — синтез сам по себе LLM-вызов
Reduce как чистая функция над числами/строкамиReduce — это интерпретация естественного языка
Fault tolerance через re-executionRe-execution стоит денег; результаты варьируются
Стоимость ~ CPU·sec, диск, сетьСтоимость ~ токены (4× для одиночного агента vs чата, ~15× для мультиагента, по данным Anthropic)
State — это шардируемые данные«State» — это разговор/контекст, не нарезается без семантической потери

То есть, когда вы слышите «давайте просто MapReduce'нем по файлам», на самом деле заимствуется форма fan-out и предположение, что подзадачи независимы. Чем дальше ваша задача от настоящей независимости, тем сильнее метафора будет уводить.

Исторический ход внутри LLM объясняет, почему метафора стала модной именно сейчас:

  • CoT (Chain-of-Thought, Wei et al. 2022) научил модели рассуждать вслух перед ответом.
  • ReAct (Yao et al. 2022) проинтерливил рассуждение с tool calls — прототип «agent loop».
  • Tool use / function calling (2023) превратил цикл в нечто, чем модели могли управлять сами.
  • Single-agent harness'ы (2024) — Claude Code, Composer в Cursor, Aider, SWE-Agent — показали, как далеко может уехать одна модель в плотном tool-цикле (Schluntz пушнул Sonnet 3.5 с 33.4% до 49.0% на SWE-bench Verified намеренно минималистичным harness'ом).
  • Multi-agent (середина 2024 – 2025) появился, когда single-agent контекст стал бутылочным горлышком на определённом классе задач, а фреймворки AutoGen, CrewAI, OpenAI Swarm и LangGraph популяризовали паттерны.
  • 2026: пост-хайповая консолидация. Поле оседает на гибридных паттернах — оркестратор + read-only специалисты + один writer, плюс эскалация по уровням модели (advisor strategy).

2. State of the art в coding-агентах (апрель 2026)

Claude Code (Anthropic)

Эталонная имплементация. Субагенты — first-class:

  • Tool Task (переименован в Agent в v2.1.63) — это то, что триггерит субагента. Каждый субагент получает свежий контекст, свой allowlist инструментов, и в родителя возвращается только финальный текст. Родитель никогда не видит промежуточных tool calls субагента.
  • .claude/agents/*.md хранит project-level определения субагентов; ~/.claude/agents/ — user-level. Определение — это YAML frontmatter (name, description, tools, model) плюс markdown system prompt.
  • Встроенные субагенты: Explore (быстрый, read-only поиск по кодовой базе с уровнями quick / medium / very thorough), Plan (исследование в plan mode) и general-purpose (tools-in-a-loop по умолчанию). Субагенты не могут спавнить других субагентов — это жёсткое правило, чтобы избежать бесконечной вложенности.
  • Forked субагенты (экспериментально, CLAUDE_CODE_FORK_SUBAGENT=1, v2.1.117+) наследуют родительский разговор вместо старта с нуля — полезно, когда нужен полный контекст, но шум tool calls хочется держать вне основного thread.
  • Параллельная инвокация происходит, когда модель эмитит несколько Task/Agent tool calls в одном assistant-блоке. Промпт, идущий с Claude Research, дословно говорит: «You MUST use parallel tool calls for creating multiple subagents (typically running 3 subagents at the same time) at the start of the research, unless it is a straightforward query.»
  • Per-subagent выбор модели через env-переменную CLAUDE_CODE_SUBAGENT_MODEL; типовой паттерн — Opus на оркестратор, Sonnet на воркеры (дешевле, часто лучше изолированы).
  • Worktrees (claude -w) дают каждому агенту свою файловую систему, чтобы параллельные writer'ы не наступали друг другу.
  • Headless mode (claude -p "prompt") и Claude Agent SDK делают всё это скриптуемым; собственные паттерны Anthropic из «Building Effective Agents» (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer) — это reference-имплементации в Claude cookbook.
  • Внутренняя практика Cherny: десятки Claude-сессий конкурентно, в основном на Opus 4.6/4.7. Его команда code-review спавнит несколько субагентов на поиск проблем, потом — вторую волну, специально натасканную тыкать дыры в находках первой. «В итоге результат огненный — он находит все настоящие проблемы без ложных».

Полезная цитата Cherny о том, что на самом деле происходит: «Claude Code — это не один AI, это система оркестрации. Ваша основная сессия — это "центральный AI", который координирует специализированных субагентов. Качество вашей работы зависит от того, насколько хорошо вы научили этот центральный thread делегировать.»

OpenAI Codex (cloud-агент 2025-го, не модель 2021-го)

  • Каждая задача исполняется в своём изолированном cloud-сэндбоксе, в котором уже залит ваш репо. Несколько задач параллельно — by design; это headline-фича.
  • Codex CLI, IDE-расширение и Codex desktop-приложение (macOS, потом Windows в начале 2026) делят один harness; desktop-апп прямо позиционируется как «центр управления для агентного кодинга, [где] агенты работают параллельно через проекты, выполняя недели работы за дни».
  • Sub-agents в Codex (multi-agent v2 workflows, конец 2025) используют читаемые path-based адреса вроде /root/agent_a со структурированным inter-agent messaging.
  • Worktrees — first-class для управления независимыми задачами в одном репо.
  • AGENTS.md — Codex-аналог CLAUDE.md.
  • Модели: GPT-5.4 / GPT-5.4-mini (лёгкая опция для субагента) / GPT-5.3-Codex-Spark (research-preview, low-latency) — выставляется per-thread или per-subagent через --model.
  • Codex Cloud-задачи по умолчанию идут на фиксированной модели (по состоянию на апрельский changelog 2026 — переопределить cloud-модель per-task пока нельзя).

Cursor 2.0+ (с октября 2025)

  • До 8 параллельных агентов на один промпт, изолированных через git worktrees или удалённые машины. Позиционируется как ансамбль: «Иметь несколько моделей, пытающихся решить одну проблему, и выбирать лучший результат — значительно улучшает финальный output.»
  • Composer — MoE-модель Cursor для кодинга, RL-тренированная внутри agent harness под низколатентное использование инструментов; цель — ~30 сек/turn.
  • Plan Mode in Background: один агент планирует, другой (или несколько) исполняет — явное разделение.
  • Эксперимент Cursor «scaling agents» (январь 2026) — поучительный кейс: 1M строк кода, ~1000 файлов, иерархия «planners → workers → judges», якобы строящая web-браузер. Реакция публики разделилась: Fortune назвал это «прямым результатом того, что мы непрерывно толкаем границы возможностей моделей», а множество разработчиков, включая Simon Willison (поначалу впечатлённый) и авторов emsh.cat, показали, что итоговый репо fastrender не проходил даже cargo build чисто. Урок: объём токенов — не прогресс.

Aider — split «архитектор/редактор»

Самый простой two-agent паттерн в продакшене. Режим --architect отправляет промпт в сильную reasoning-модель (изначально под o1-preview, теперь — Claude/GPT-5.x), которая предлагает изменение plain text'ом. Отдельный --editor-model (часто более дешёвая, дисциплинированная по формату модель) транслирует предложение в search-replace edit'ы. Бенчмарк-прирост на момент релиза был существенным (o1-preview architect + DeepSeek/o1-mini editor вытолкнул code-edit benchmark на тогдашние 85% SOTA). Функционально это идентично паттерну «Smart Friend» от Cognition и Advisor tool от Anthropic — но в user space, два LLM-вызова на turn.

Cline / Roo Code / Kilo Code

Это форк-линия: Cline (оригинал) → Roo Code → Kilo Code. Все три живут как VS Code расширения, model-agnostic, BYOK.

  • Orchestrator mode — киллер-фича Roo и Kilo. Оркестратор декомпозирует задачу и роутит подзадачи в специализированные режимы: Architect (планирует, не редактирует), Code (редактирует), Debug, Ask. Переключение через slash-команды /architect, /code, /debug, /orchestrator или биндинг.
  • Поддерживается per-mode выбор модели (например, big model на Architect, small model на Code).
  • Roo Code Inc. объявили шатдаун всех Roo-продуктов к 15 мая 2026; рекомендованные преемники — Cline (оригинал) или Roomote.
  • Kilo'вский «Memory Bank» персистит архитектурные решения в repo-markdown, чтобы новые сессии не стартовали с нуля.

GitHub Copilot — coding agent + /fleet

Две разные поверхности:

  • Copilot coding agent (cloud): ассайнить GitHub-issue на @copilot. Открывается ветка + draft PR, бегает в эфемерном GitHub Actions окружении, исполняет цикл plan → code → tests → checks, постит PR на ревью. Несколько issue идут параллельно как отдельные сессии. «Mission control» (web UI) — view оркестрации.
  • Copilot CLI /fleet (Q1 2026): slash-команда в локальном CLI, спавнит sub-agent'ов параллельно — оркестратор декомпозирует, диспатчит независимые айтемы как background sub-agent'ов, поллит на завершение, синтезирует. У каждого sub-agent — свой контекст, но общая файловая система. Ограничения: нет file locking (последний writer выигрывает молча), sub-agent'ы не видят историю оркестратора (надо передавать в промпте), inter-agent коммуникация — только через оркестратора.

Прямая рекомендация GitHub: «Для строго линейной работы по одному файлу обычные Copilot CLI промпты проще и так же быстры. /fleet добавляет накладные расходы на координацию — он окупается, когда есть реальная работа для распараллеливания.»

Devin (Cognition)

Оригинальный «AI software engineer». Архитектурно:

  • Devin 2.0 (апрель 2025) сместился с фрейминга «полностью автономный» на «agent-native IDE»: несколько параллельных Devin'ов, каждый в своей cloud VM, с human-in-the-loop руления.
  • Devin Review — канонический пример мультиагента, который реально работает: отдельный агент с чистым контекстом ревьюит PR'ы Devin'а. Ловит ~2 бага/PR на внутренних данных, 58% — серьёзные. «Часто система зацикливается через несколько code-review итераций, находя новые баги каждый раз… Сегодня мы заставляем Devin и Devin Review нативно итерировать друг против друга, так что большинство багов уже решены к моменту, когда человек открывает PR.»
  • Manager Devin → child Devin'ы через внутренний MCP (апрель 2026): «Manager Devin может разломать большую задачу на куски, заспавнить child Devin'ов на работу над ними и координировать их прогресс через внутренний MCP.»
  • DeepWiki subagent для контекста кодовой базы (приобретён вместе с покупкой Windsurf в июле 2025).

Replit Agent 4

  • Manager + Editor + Verifier — каноническая декомпозиция по ролям (LangChain написал это раньше всех). Verifier явно фолбэчит в разговор с пользователем, а не в гадание — необычное и недооценённое дизайн-решение.
  • Agent 4 (Pro/Enterprise) поддерживает параллельное исполнение задач: независимые задачи форкаются в sub-agent'ы, рекомбинируются через специализированные merge-sub-agent'ы.

Amp (Sourcegraph)

Построен вокруг четырёх именованных субагентов с разными ролями (Beyang Liu, ноябрь 2025): Finder (поиск по кодовой базе), Oracle (глубокое рассуждение, code review — «второе мнение»), Librarian (библиотеки/зависимости), Kraken (рефакторинг/transforms). У каждого — фокусированный контекст и специализированные возможности. Манул Ampcode: «Субагенты работают в изоляции — они не могут общаться друг с другом, вы не можете направлять их посреди задачи, они стартуют с нуля без накопленного контекста вашего разговора, и main-агент получает только их финальный summary.» Это явное, честное декларирование констрейнта.

Goose (Block, теперь под Linux Foundation Agentic AI Foundation)

  • Recipes (YAML workflows), Sub-recipes (композиция), Subagents (запуск sub-recipe'ов параллельно отдельно от main-recipe). MCP-native. Open-source, model-agnostic. Паттерн ближе к workflow-runner'у, чем к чат-агенту.

OpenCode (sst/anomalyco)

  • Субагенты декларируются как markdown-файлы с YAML frontmatter; mode: primary | subagent | all; permission.task glob-правила для контроля, какой субагент кого может звать. Ручная инвокация @subagent-name в TUI. Внутри использует TaskTool, идентичный по духу claude-code'овскому.

3. Фреймворки и SDK с явной поддержкой map-reduce форм

  • LangGraph (Send API). Самая прямая map-reduce примитива в мире агентов. Нода возвращает [Send("worker", {item: x}) for x in items] для fan-out на N параллельных вызовов воркера с кастомным per-item state. Reducer'ы стейта (Annotated[list, operator.add]) собирают fan-in. Количество веток определяется в рантайме, не в момент построения графа. Конфиг max_concurrency ограничивает параллелизм. Это учебниковая имплементация map-reduce в LLM-агентном графе.
  • OpenAI Agents SDK (продакшн-преемник Swarm). Две примитивы: handoff() (передать разговор другому агенту) и agent.as_tool() (вызвать специалиста как саб-рутину, которая возвращает контроль). Sandbox-агенты (v0.14+) гоняют агентов внутри изолированных workspace. SDK явно различает handoff (специалист владеет следующим ответом) и agent-as-tool (специалист — помощник main-агента). Под map-reduce обычно используется as_tool с родителем, диспатчащим несколько параллельных sub-runs.
  • Microsoft Agent Framework (1.0, 7 апреля 2026). Преемник AutoGen и Semantic Kernel. Пять паттернов оркестрации шипают как first-class: sequential, concurrent, handoff, group chat и Magentic-One. «Concurrent» паттерн — это map-reduce форма.
  • CrewAI. Process.hierarchical с manager_agent — очевидно map-reduce-ароматный паттерн. Caveats: на конец 2025 / начало 2026 у hierarchical-режима хорошо документированные баги вокруг делегирования (manager часто исполняет задачи сам, вместо диспатча). Process.sequential остаётся более безопасным дефолтом. CrewAI Flows (event-driven) добавляют ещё один слой оркестрации.
  • Pydantic AI. Agent delegation реализована как «агенты, вызывающие других агентов как инструменты». Multi-agent паттерны: agent delegation, programmatic hand-off, граф-управляемый control flow (через pydantic-graph) и Deep Agents (pydantic-deep, по образцу LangChain'овского deepagents).
  • Mastra. Replit'овский Agent 3/4 на самом деле генерирует Mastra-агентов динамически — к апрелю 2026 Replit harness создаёт «тысячи Mastra-агентов в день», используя контейнер-нативную архитектуру и event-based исполнение Mastra.
  • AutoGen. На начало 2026 — в режиме maintenance; существующие пользователи v0.7.x могут оставаться, новые проекты редиректит в Microsoft Agent Framework. Community-форк AG2 сохраняет GroupChat-стиль из v0.2.

4. Дебаты Anthropic vs Cognition — и как они сошлись

Это определяющий аргумент 2025–2026 в дизайне агентов. Оба поста — must-read.

Anthropic («How we built our multi-agent research system», июнь 2025):

  • Архитектура: lead researcher (Opus 4) → спавнит параллельных субагентов (Sonnet 4) с собственными контекстами → CitationAgent финализирует.
  • Headline-результат: +90.2% к одиночному Opus на внутреннем research-эвале; cracking BrowseComp задач, которые одиночные агенты не вытягивали (например, «найди всех членов советов директоров S&P 500 IT-компаний» через параллельную декомпозицию).
  • Честная стоимость: «Агенты обычно используют примерно в 4 раза больше токенов, чем чат-интеракции, а мульти-агентные системы — примерно в 15 раз больше токенов, чем чаты. Для экономической жизнеспособности мульти-агентные системы требуют задач, ценность которых достаточно высока, чтобы оплатить прирост в качестве.»
  • Честное ограничение скоупа: «Некоторые домены, где требуется, чтобы все агенты делили один контекст, или где много зависимостей между агентами — не подходят для мульти-агентных систем сегодня. Например, большинство задач кодинга включают меньше истинно параллелизуемых частей, чем research, и LLM-агенты пока не очень хороши в координации и делегировании другим агентам в реальном времени.»
  • Это последнее предложение Cognition вытащил уже на следующий день.

Cognition / Walden Yan («Don't Build Multi-Agents», 13 июня 2025):

  • Два принципа:
    1. Шарьте контекст агрессивно — между всеми агентами, вовлечёнными в задачу.
    2. Действия несут имплицитные решения — когда N агентов делают write-action'ы параллельно, их имплицитные решения по стилю, edge case'ам и паттернам кода будут конфликтовать.
  • Мысленный эксперимент Flappy Bird: субагент 1 строит зелёные трубы в Mario-стиле, субагент 2 строит не-flappy птицу, оркестратор получает мусор для мёрджа.
  • Вывод: большинство мульти-агентных систем хрупки. Однопоточные агенты с хорошим context engineering на практике обходят их в задачах кодинга.

Follow-up Cognition («Multi-Agents: What's Actually Working», 22 апреля 2026) — это синтез, который Walden написал после 10 месяцев дополнительных продакшн-данных:

  • «В Cognition мы начали деплоить мульти-агентные системы, которые реально работают на практике. Наши изначальные наблюдения всё ещё в силе для swarm'ов параллельных writer'ов… Но мы нашли более узкий класс паттернов, которые работают: сетапы, где несколько агентов вкладывают интеллект в задачу, при том что записи остаются однопоточными.»
  • Два паттерна, явно благословлённых:
    1. Generator-Verifier loop («code-review-loop, который настолько туп, что не должен работать»). Devin Review ловит 2 бага/PR в среднем, 58% — серьёзные. Контринтуитивная находка: ревьюер не должен делить контекст с writer'ом. Чистый контекст позволяет ревьюеру рассуждать назад от имплементации, задавать вопросы, которые оригинальный агент пропустил, и обходить «Context Rot» (деградация интеллекта модели на длинных контекстах). Коммуникационный мост — как Devin фильтрует фидбэк Devin Review против intent'а пользователя — это и делает loop пригодным.
    2. «Smart Friend» / Advisor. Маленькая executor-модель ведёт, эскалирует на бо́льшую модель в трудных решениях. Инвертирует обычное «большая модель оркестрирует малых». Anthropic выкатил ровно этот паттерн как Advisor tool 9 апреля 2026 (advisor_20260301, beta-header advisor-tool-2026-03-01). Эмпирика: Sonnet+Opus advisor +2.7pp на SWE-bench Multilingual при −11.9% стоимости; Haiku+Opus advisor — 19.7% → 41.2% на BrowseComp. Cognition пробовал это с их SWE-1.5 / SWE-1.6 как primary; работает хорошо между двумя сильными frontier-моделями (например, Claude как primary, GPT как advisor), но ломается, когда primary слишком слаба, чтобы понять, что она застряла.
  • Резюмирующая строчка: «Мы думаем, что unstructured-swarm подход — произвольные сети агентов, договаривающихся друг с другом — в основном отвлекает. Практическая форма — это map-reduce-and-manage: менеджер расщепляет работу, дети исполняют, менеджер синтезирует и репортит обратно.»

Это предложение — самое близкое, что есть к индустриальному консенсусу 2026 по теме. Эксперимент Anthropic «Building C Compiler» (Carlini, февраль 2026) — следствие: 16 параллельных Claude'ов в Docker-контейнерах + GCC-как-оракул для верификации, без центрального оркестратора, агенты клеймят задачи через lock-файлы в общем git-репо. Сработало (100K-строчный компилятор, который собирает Linux 6.9), но Carlini подчёркивает: урок про дизайн harness'а, не про мульти-агенты: «Мне приходилось постоянно напоминать себе, что я пишу этот test harness для Claude, а не для себя.»

5. Decision-фреймворк — когда тянуться к MapReduce-стилю

Честная версия вопроса: учитывая мою задачу, оправдывают ли затраты мульти-агентов (счёт за токены, координационный overhead, фрагментация контекста) достаточный прирост качества или скорости, чтобы предпочесть их альтернативе — одному агенту с длинным контекстом?

Тянуться к MapReduce-стилю мульти-агентов, когда выполнены ВСЕ из:

  • Подзадачи действительно независимы (ревью N файлов, поиск по N веткам кода, summarize N документов, оценить N кандидатных планов).
  • Output каждой подзадачи можно reduce'нуть — кодом (конкатенация, голосование, ранжирование) или judge-агентом со свежим контекстом — без необходимости заново выводить контекст из каждого шарда.
  • Вы упёрлись либо в context window (объединение контекстов подзадач превышает то, что один агент может удержать), либо в wall-clock (пользователь выигрывает от параллельного speedup).
  • Per-task экономическая ценность оправдывает ~4–15× стоимость одиночного чата.
  • Вы можете верифицировать корректность — тесты, типы, оракулы, схема, ground truth.

Избегать, когда выполнено ХОТЯ БЫ ОДНО из:

  • Задачи имеют скрытые зависимости друг от друга (большинство реальной кодинг-работы — даже «изолированный» file change часто подразумевает кросс-файловые конвенции).
  • «Reduce» на самом деле означает taste-call между N вариантами. Один агент со всем контекстом обычно сделает это лучше, чем synthesis-pass.
  • Дебаг или exploration, где сам loop и есть ценность — вы хотите одного агента, который учится из ранних наблюдений.
  • Вы не можете написать верификатор, которому агенты доверяют. Carlini: «Важно, чтобы верификатор задачи был почти идеальным, иначе Claude будет решать неправильную проблему.»

Эвристика Cognition: однопоточные записи, мульти-агентные чтения. Code-review субагенты, search-субагенты, exploration-субагенты — fine. Пул независимых writer'ов на одной кодовой базе — почти всегда плохая идея, если только разбиение (например, один агент на файл в гигантском rename) не пуленепробиваемо.

6. Альтернативные паттерны, которые надо знать

Они не взаимоисключают MapReduce; они — другие формы под другие задачи.

  • Single agent + длинный контекст (предпочтительный дефолт Cognition для большинства задач кодинга). Современные frontier-модели спокойно держат 200K–1M токенов; с разумным сжатием контекста и «plan mode» (рекомендация Cherny: 15–20 минут pre-coding context-building, потом один хорошо сформированный промпт) один агент часто обходит несколько на synthesis-heavy работе.
  • Pipeline / sequential handoff. Каждый агент владеет стейджем; output стейджа N становится input'ом стейджа N+1. Aider'овский architect/editor, handoff() в OpenAI Agents SDK, replit'овский manager → editor → verifier — все инстанцируют это. Лучше всего, когда у стейджей разные оптимальные модели или разные инструментальные потребности.
  • Supervisor-worker / orchestrator-worker. Один умный агент декомпозирует и диспатчит; воркеры исполняют и возвращают результаты. Research-система Anthropic; supervisor-паттерн в LangGraph; CrewAI hierarchical; Orchestrator mode в Roo/Kilo. Сильнее всего, когда декомпозиция динамическая и определяется в рантайме.
  • Generator-verifier loop. Один агент пишет, с-чистым-контекстом агент ревьюит. Devin Review, review-with-rebuttal у Cherny, evaluator-optimizer паттерн Anthropic. Самый чистый «MapReduce, сводящийся к двум» кейс.
  • Advisor / smart-friend / capability router. Маленький executor + большой advisor (Anthropic Advisor tool, Cognition Smart Friend, Aider architect/editor с асимметрией моделей). Находка Cognition: между двумя одинаково-сильными frontier-моделями паттерн становится capability routing (одни модели лучше дебажат, другие лучше пишут тесты), а не эскалацией.
  • Plan-and-execute. Один агент пишет markdown-план; другой (или тот же в другом режиме) исполняет шаг за шагом. Plan Mode в Claude Code, Plan Mode в Cursor, Architect mode в Roo. Сжимает мутную задачу в верифицируемый to-do список.
  • Tree-of-thoughts / debate / self-consistency. Запустить N вариантов параллельно, потом голосовать, судить или выбрать лучший. «Ансамбль из 8 агентов выбирает лучший результат» в Cursor 2.0 — это по сути оно. Полезно, когда у вас есть дешёвый верификатор и дорогое рассуждение.
  • Reflection loops. Single-agent вариант: сгенерировать, покритиковать собственный output, перегенерировать. Недооценено и дёшево.
  • Actor model / blackboard. Теоретические альтернативы, обсуждаемые в research-литературе; редки в продакшн coding-агентах, потому что координационный overhead не оправдывается против graph-based оркестратора.

7. Harness важнее модели — и более умные модели не всегда вознаграждают больше агентов

Идея «agent harness» (loop, определения инструментов, верификаторы, контекстная обвязка вокруг LLM) теперь рассматривается как доминирующая переменная. Три источника сходятся на этом:

  • Результат Erik Schluntz на SWE-bench Verified (Sonnet 3.5, октябрь 2024): намеренно минималистичный harness — просто tools-in-a-loop без хитрой prune-логики — обошёл специально-построенные мульти-агентные SWE-фреймворки. «Чем умнее модели, тем меньше нужна вся эта дополнительная обвязка.»
  • Boris Cherny о внутренностях Claude Code: agentic search обходит RAG, когда модель достаточно хороша, чтобы навигировать через простые glob и grep. «Harness» — это то, что учит центральный thread, когда делегировать.
  • Разбор harness engineering от OpenAI (упомянутый Hamel Husain): они зашипали миллион-строчный продукт силами трёх инженеров за пять месяцев, инвестируя в harness — тесты, спецификации, телеметрию — а не добавляя больше агентов.

Следствие: чем умнее модели, тем выше планка для мульти-агентов. Claude Opus 4.6 / 4.7 (и Mythos-class модели на горизонте, по утечкам roadmap'а Anthropic и референсам Cognition) держат в одном контексте то, что раньше требовало оркестрации. Walden Yan, апрель 2026: «Модели стали гораздо более естественно "agentic". Они интуитивно понимают использование инструментов, свои собственные лимиты контекста и как дистиллировать свой контекст для коллабораторов.» Cherny в феврале 2026: «Граница того, под что нужен plan mode, отодвинулась чуть-чуть. Раньше нужно было планировать, теперь не нужно. И я думаю, это общий тренд — стафф, который раньше был обвязкой, при более продвинутой модели уезжает внутрь самой модели.»

Контр-сила — стоимость. Frontier-интеллект становится более умелым, но и более дорогим (и более медленным) на токен. Поэтому существуют паттерны вроде Advisor / Smart Friend — они позволяют платить frontier-цены только в по-настоящему трудные моменты.

8. Практические эвристики дизайна reduce-шага

Большинство фейлов в map-reduce стиле на практике — это фейлы reduce-шага. Заметки от практиков:

  • Reduce'ьте кодом, когда можно. Конкатенация, голосование, ранжирование по скору, валидация по схеме — всё детерминированное — обходит позволение LLM синтезировать в свободной форме.
  • Когда reduce должен быть LLM, дайте ему чистый контекст. Это самая контринтуитивная находка Cognition: синтезирующий/ревьюящий агент не должен делить контекст с writer'ами. Меньше размытия внимания, лучше суждение.
  • Сделайте контракт явным. Output каждого субагента должен соответствовать схеме или шаблону. Чем больше вы можете сделать жизнь reducer'а похожей на десериализацию, тем лучше.
  • Жёстко лимитируйте fan-out. Промпт Anthropic говорит «обычно 3 субагента». Их ранний баг системы спавнил 50 субагентов на тривиальные запросы. Больше — не лучше.
  • Верифицируйте перед reduce. Гоните тесты, type checks, оракулы. Относитесь к неверифицированному выходу субагента как к подозрительному.
  • Бюджетируйте заранее. Anthropic явно рекомендует «extended thinking как контролируемый scratchpad» для lead-агента, чтобы он спланировал, сколько субагентов спавнить, перед тем как спавнить.

Caveats

  • Многие мульти-агентные бенчмарк-цифры приходят от вендоров, которые эти системы и построили. 90.2% от Anthropic, внутренние цифры Codex, цифры Composer от Cursor, статистика Devin Review от Cognition — все полезные сигналы, но ни один не независим. Где независимые воспроизведения существуют (Cursor browser swarm, C-компилятор), картина смешаннее.
  • Million-line browser-эксперимент Cursor — поучительный кейс. Как разобрано в анализе emsh.cat и обсуждении на Hacker News, итоговый репо fastrender не проходил cargo build чисто на момент выхода поста. Throughput агента — не то же самое, что работающий софт. Относитесь к любым «смотрите, сколько строк!» с скепсисом, если нет воспроизводимого build-артефакта.
  • Словарь нестабилен. «Subagent», «sub-agent», «child agent», «worker agent», «specialist», «delegate» — все ссылаются примерно на одну вещь у разных вендоров, но с разной конкретной семантикой (изоляция контекста, наследование инструментов, parallel-vs-sequential, может-ли-спавнить-субагентов). Не переносите ментальные модели без чтения доки.
  • «Multi-agent» как термин делает слишком много работы. Покрывает всё, от «двух агентов в pipeline» (Aider, Advisor) до «16 агентов на общем репо через lock-файлы» (компилятор Carlini) до «сотен planners + workers + judges» (browser Cursor'а). Это не одно и то же и часто имеет инверсные cost/benefit профили.
  • Земля движется. Advisor tool от Anthropic (9 апреля 2026), Microsoft Agent Framework 1.0 (7 апреля 2026), «What's Actually Working» от Cognition (22 апреля 2026), мульти-агентный UX в Codex desktop от OpenAI (начало 2026) — все приземлились примерно за последние шесть недель периода, который покрывает этот отчёт. Полураспад любого текста про «состояние мульти-агентного кодинга» — около двух месяцев.
  • Кодинг-задачи необычно враждебны к наивному мульти-агенту. У большинства продакшн-кодинг задач есть скрытые зависимости и требование архитектурной когерентности — ровно тот failure mode, который Cognition флагнул. Research, customer support и information-retrieval задачи параллелятся гораздо чище. Если вы читаете это для дизайна coding-агента, weight'ьте перспективу Cognition; если для дизайна research-assistant'а, weight'ьте Anthropic.
  • «MapReduce как паттерн» — полезный фрейм, но дырявый. Настоящая техническая изоморфия слабая (нет детерминизма, нет shuffle, нет fault-tolerance через re-execution). Что выживает — это форма fan-out / fan-in и инвариант независимости-или-смерти. Используйте как набросок на доске, а не как гарантию того, что реальная математика MapReduce переносится.
Content is user-generated and unverified.
    MapReduce for Multi-Agent AI Systems: 2026 Guide | Claude