Многоагентные схемы: когда оправданы, а когда дорогая иллюзия

Есть соблазн, который возникает у всех примерно на третьей неделе работы с агентом. Один агент справляется наполовину; значит, нужно несколько. Архитектор, разработчик, ревьюер, тестировщик — команда. Схема рисуется за пять минут, звучит убедительно и опирается на понятную аналогию: так работают живые инженерные команды.

Аналогия ломается в одном месте, и это место определяет всю главу:

Живая команда — это набор независимых источников знания. Несколько экземпляров одной модели — это один источник, запущенный несколько раз. Разделение труда между людьми уменьшает вероятность общей ошибки, потому что люди учились по-разному. Разделение труда между экземплярами модели её не уменьшает: у них одни веса, одни пробелы и одни любимые заблуждения.

Из этого следует всё остальное. Многоагентная схема покупает вам ровно два ресурса — изоляцию контекста и параллелизм по стенным часам. Она не покупает независимую экспертизу, не покупает проверку и не покупает надёжность. Дальше разбираем: что именно вы получаете, чем платите, где это окупается и где превращается в дорогую имитацию процесса.

Эта глава — про то, как пользоваться такими схемами в своей кодовой базе. Если нужно построить многоагентную систему как продукт — архитектура, протоколы, оценка качества, — это соседний трек: «Многоагентные системы».

Что вообще считать многоагентной схемой

Термин размыт, и половина споров о нём — это спор об определении. Зафиксируем рабочее.

Многоагентная схема — это два и более независимых цикла «наблюдение — действие», каждый со своим контекстным окном, координируемые чем-то внешним. Механику одного такого цикла разбирали в главе «Модель исполнения».

Ключевое слово — «своим окном». Именно это отличает схему от вещей, которые ею притворяются:

Последняя строка важнее прочих. Базой сравнения для любой схемы должен быть не «один агент», а «один агент плюс человек». Человек в контуре есть всегда; вопрос лишь в том, добавляет ли третий, четвёртый и пятый узел что-нибудь сверх того.

Таксономия схем, которые встречаются на практике:

Последняя ветка формально не многоагентная — второй узел вообще не агент. Но именно она делает то, ради чего люди строят остальные четыре. К ней вернёмся.

Единственный ресурс, который вы действительно покупаете

Разберём по пунктам, что меняется физически, когда вместо одного цикла запускается несколько.

Первое: изоляция контекста. У каждого агента своё окно. Это значит, что субагент может прочитать сорок файлов, выполнить grep по всему репозиторию, залить в себя вывод сборки на десять тысяч строк — и всё это не попадёт в ваше главное окно. Вернётся сводка. Механика окна и того, почему мусор в нём вреден, разобрана в главе «Контекст».

Это настоящий и довольно ценный ресурс. Он же — единственный архитектурно новый.

Второе: параллелизм по стенным часам. Если подзадачи независимы, три агента отработают примерно за время самой долгой, а не за сумму. Экономия реальна и ограничена законом Амдала: ускоряется только распараллеленная часть. Если из сорока минут работы тридцать пять уходит на ваше чтение результата, параллелизм срежет пять минут из сорока. Подробнее про сам закон — в главе «Производительность конкурентного кода»; он не знает, что мы обсуждаем агентов, и работает ровно так же.

Третьего пункта нет. «Роли» — это текст в системном промпте. Агент с надписью «ты старший ревьюер» не становится старшим ревьюером; он становится тем же агентом, генерирующим текст в стиле, статистически связанном со словом «ревьюер». Это иногда полезно: формулировка сужает пространство вывода, как разбиралось в главе «Промпт как спецификация». Но это работа промпта, а не архитектуры, и точно такой же эффект достигается одним агентом с той же формулировкой.

Вот картинка того, что происходит с токенами при веерном запуске:

Цена: арифметика, а не ощущение

Самое частое заблуждение звучит так: «разделим задачу на трёх агентов — каждому достанется по трети». Достанется по трети работы, но не по трети контекста. Контекст копируется.

Разложим по статьям. Пусть B — токены общего брифа (правила проекта, карта репозитория, постановка), W — токены собственно работы, S — размер одной сводки, N — число субагентов.

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

Единственное известное мне опубликованное число о накладных расходах самой схемы — из инженерного блога Anthropic про их исследовательскую многоагентную систему: How we built our multi-agent research system. Там говорится, что агенты расходуют примерно вчетверо больше токенов, чем чат, а многоагентные системы — примерно в пятнадцать раз больше, чем чат. Оговорки обязательны: это текст производителя, это их собственная исследовательская нагрузка (поиск информации, а не изменение кода), и множитель полностью зависит от того, сколько раз копируется бриф. Не переносите цифру — перенесите форму рассуждения.

Форму удобно записать как маленькую модель, которую вы можете подставить своими числами:

from dataclasses import dataclass


@dataclass(frozen=True)
class Разбиение:
    """Оценка токенов для одной задачи, решаемой одним агентом или веером."""

    бриф: int          # правила проекта, карта репозитория, постановка
    работа: int        # чтение файлов и генерация, суммарно по задаче
    сводка: int        # средний размер отчёта одного субагента
    агентов: int       # N; 1 означает «без веера»
    доля_общего: float # какая часть «работы» всё равно читается каждым (0..1)


def токены(р: Разбиение) -> int:
    """Оценка суммарного расхода. Сложность O(1) по времени и памяти —
    считать нечего, вся суть в том, ЧТО умножается на N, а что нет."""
    if р.агентов == 1:
        return р.бриф + р.работа

    общее = int(р.работа * р.доля_общего)          # читают все
    личное = int(р.работа * (1 - р.доля_общего))   # делится честно
    return (
        р.агентов * р.бриф                          # бриф копируется
        + р.агентов * общее                         # общие файлы копируются
        + личное                                    # только это делится
        + р.агентов * р.сводка                      # отчёты в главное окно
    )


базовый = Разбиение(бриф=8_000, работа=60_000, сводка=1_500, агентов=1, доля_общего=0.3)
веер = Разбиение(бриф=8_000, работа=60_000, сводка=1_500, агентов=4, доля_общего=0.3)

print(токены(базовый), токены(веер))   # 68000 152000
print(токены(веер) / токены(базовый))  # 2.23 — за то же самое

Числа в примере выдуманы — подставьте свои, замерив реальные сессии. Полезен здесь не результат, а структура: множитель N стоит перед константной частью, а не перед переменной. Отсюда прямое правило: веер тем выгоднее, чем больше личной работы у каждого субагента по сравнению с общим брифом. Три субагента на задачу, где у каждого две минуты работы, — это оплата брифа втрое ради ничего.

Полный разбор экономики, включая кэширование префикса и то, как считать стоимость сессии, — в главе «Цена работы с агентом».

Шов: где именно теряется информация

Между двумя агентами нет разделяемой памяти. Есть текст. Всё, что первый агент знал, но не написал, для второго не существует.

Разберём, что именно теряется, потому что типология здесь полезнее общих слов.

Потеря неявного решения. Агент постоянно принимает мелкие решения, которые не считает решениями: какой из двух похожих модулей взять, как назвать поле, что считать ошибкой. В сводке этого нет — сводка написана про результат. Ровно эту мысль формулирует команда Cognition в заметке Don’t Build Multi-Agents: каждое действие агента несёт в себе неявное решение, а конфликтующие неявные решения дают несогласованный результат. Их вывод радикален — держать один линейный поток и разделять контекст, а не агентов. Он спорный, и я с ним не согласен целиком: для read-only разведки веер работает хорошо. Но в части записи кода они правы, и практика это подтверждает.

Потеря уверенности. Агент, который что-то предположил, в сводке напишет это утвердительно. Маркеры вида verified / derived / assumed / unchecked из REASONING-DISCIPLINE.md нашего пакета products/workbench/templates/memory/ придуманы ровно против этого: они заставляют помечать статус каждого утверждения. На шве между агентами это перестаёт быть гигиеной и становится необходимостью — потому что второй агент не может переспросить.

Потеря отрицательных результатов. «Я проверил гипотезу X, она не подтвердилась» почти никогда не доходит до следующего агента. В итоге второй агент проверяет X заново. Это не ошибка, это чистая трата.

Потеря шва как объекта проверки. Здесь работает закон из нашего же пакета COMPOSITION-AND-LAWS.md:

LAW-01. Композиция проверена ровно настолько, насколько проверен её самый узкий шов. Если две проверенные части соединены, утверждение о целом остаётся выводом, а не проверенным фактом, пока сам шов не прогнан.

Переведём на язык этой главы: два агента, каждый из которых «сделал свою часть», не дают вам сделанной задачи. Стык между их работой не проверил никто — ни первый, у которого не было второй части, ни второй, у которого не было первой. Это тот же интеграционный шов, что и в обычной разработке («Интеграционное тестирование»), только возникает он теперь не между командами, а между двумя сессиями, разделёнными двадцатью минутами.

Кто хочет более формального взгляда: любая многоагентная схема — это распределённая система с ненадёжными узлами и лоссовым текстовым протоколом. Все обычные грабли применимы («Модели отказов», «Координация»), плюс один новый класс: сообщение может быть корректно доставлено, синтаксически безупречно и при этом ложно. Ни один протокол консенсуса от этого не защищает — консенсус гарантирует согласие узлов, а не истинность того, о чём они согласились.

Иллюзия проверки: почему второй агент — не независимый эксперт

Это центральная часть главы, и здесь важно быть точным, а не риторичным.

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

Это не новая мысль и не мысль про ИИ. В 1986 году Джон Найт и Нэнси Левесон поставили эксперимент над предположением, лежавшим в основе многоверсионного программирования: если несколько команд независимо напишут одну программу, их ошибки будут независимы, и голосование по большинству даст надёжность. Двадцать семь версий, написанных разными людьми в разных университетах, показали, что ошибки статистически коррелированы: разные версии падали на одних и тех же входах, потому что сложные места задачи сложны для всех. Работа An experimental evaluation of the assumption of independence in multiversion programming — обязательное чтение для всех, кто собирается строить надёжность через дублирование.

Если независимость не выполняется у людей, писавших код независимо, то у двух запусков одной модели она не выполняется тем более. Слепые зоны у них не «похожи» — они те же самые.

Есть и прямой замер на самих моделях. Работа Large Language Models Cannot Self-Correct Reasoning Yet (Huang et al., ICLR 2024) показывает: если попросить модель проверить и исправить собственный ответ без внешней обратной связи, качество в среднем не растёт, а на части задач падает — модель уверенно «исправляет» верные ответы. Оговорка честная: как только появляется внешний сигнал (тест упал, компилятор ругнулся, оракул сказал «неверно»), самокоррекция начинает работать. Именно сигнал делает работу, а не второй проход.

Обратная сторона тоже существует, и её надо назвать. Работа Improving Factuality and Reasoning in Language Models through Multiagent Debate (Du et al., 2023) показывает выигрыш от того, что несколько экземпляров обсуждают ответ и сходятся. Похожий эффект даёт self-consistency — сэмплировать несколько цепочек рассуждения и брать ответ большинством. Оба приёма реально работают, и оба имеют условие применимости, которое в нашей задаче почти никогда не выполняется: ответы должны быть сравнимы между собой. «Сколько будет по этой формуле» сравнить можно. Два дифа на четыреста строк, решающие задачу по-разному, — нельзя. Голосовать не над чем.

Отсюда практический вывод, который стоит держать как правило:

Одобрение агента-ревьюера — не доказательство. Это второе мнение из того же источника. Оно полезно как фильтр грубых промахов и бесполезно как гарантия. Единственные по-настоящему независимые проверяющие — прогон и человек.

Что считать по-настоящему независимым узлом:

• компилятор и система типов — не рассуждают, не соглашаются, просто отказываются собирать;
• тесты, написанные до работы агента — свойства зафиксированы человеком заранее, см. «Проверяемость»;
• property-based тесты и фаззер — генерируют входы, которых не было ни в чьём воображении (COMPOSITION-AND-LAWS.md, правило про закон как тест);
• человек, знающий историю системы — единственный, кто помнит, почему вот эта странная проверка появилась после инцидента;
• прод-метрики и трассировка — «Наблюдаемость».

Конструктивная схема, которая из этого следует, известна как LLM-Modulo: генератор предлагает, внешний верификатор отбраковывает, цикл повторяется (Kambhampati et al., 2024). Обратите внимание на асимметрию: верификатор там не модель. Как только верификатором становится вторая модель, схема превращается в двух согласных собеседников.

Где схема оправдана

Теперь позитивная часть. Есть четыре сценария, где несколько агентов дают реальный выигрыш, и все четыре имеют общий признак: вы покупаете изоляцию контекста или время, а не мнение.

Сценарий 1: параллельная разведка (read-only веер). Самый защитимый случай. «Найди все места, где мы создаём соединение с БД напрямую, минуя пул» — это задача, которая распадается на независимые куски по каталогам, требует прочитать много и вернуть мало, а результат имеет вид списка путь:строка, который вы проверяете за минуту открытием файла. Субагенты жгут свои окна, ваше остаётся чистым. Права — только чтение, поэтому цена ошибки нулевая.

Сценарий 2: изоляция грязного контекста. Иногда единственная задача субагента — не загадить главное окно. Разобрать лог на двадцать тысяч строк и вернуть три подозрительных места. Прогнать сборку и вернуть первые ошибки компилятора. Прочитать чужой SDK и вернуть сигнатуру нужного метода. Здесь «многоагентность» вырождается до одноразового рабочего, и это хорошо: у него нет состояния, которое можно потерять.

Сценарий 3: свежий взгляд на диф. Агент-ревьюер с чистым контекстом, видящий только диф и требования, действительно ловит часть дефектов лучше автора — не потому, что умнее, а потому, что у него нет истории «я это уже обосновал». Механика тут ровно как у человеческого ревью: автор читает то, что хотел написать. Оговорка из предыдущего раздела в силе: одобрение такого ревьюера ничего не гарантирует, находки — гипотезы, которые надо проверять. Полезно как генератор мест для внимания, вредно как основание для мержа. Что читать в дифе в первую очередь — в главе «Ревью кода от агента».

Сценарий 4: независимые треки с непересекающимися файлами. Три бага в трёх модулях, между которыми нет общих файлов. Здесь параллелизм честный, но обеспечивается он не схемой, а изоляцией: каждый агент работает в своём git worktree, в своей ветке, со своей проверкой.

# Физическая изоляция параллельных агентов: отдельный рабочий каталог на трек.
# Общий .git, разные рабочие деревья — конфликты становятся невозможны до момента слияния.
git worktree add ../wt-fix-auth   -b fix/auth-timeout
git worktree add ../wt-fix-export -b fix/export-encoding
git worktree add ../wt-fix-cache  -b fix/cache-invalidation

# Каждый агент запускается со своим cwd и своей командой проверки.
# Ни один не видит чужих изменений — это ровно то, чего мы хотим.

# Слияние делает человек, по одному, с прогоном после каждого:
git switch main
git merge --no-ff fix/auth-timeout && make test
git merge --no-ff fix/export-encoding && make test

git worktree remove ../wt-fix-auth   # убрать за собой

Ветвление и слияние подробно разобраны в главах «Ветвление» и «Конфликты» трека git. Здесь важна одна мысль: параллельная запись в один рабочий каталог несколькими агентами — это гонка данных, а не многоагентность. Файловая система не даст вам транзакций, а агент не знает, что файл поменялся между чтением и записью.

Где это дорогая иллюзия

Пять антипаттернов, каждый из которых я видел вживую и в каждом участвовал.

Театр ролей. Пять агентов с названиями должностей, каждый пишет свой раздел документа, оркестратор склеивает. Выглядит как процесс, стоит как пять сессий, даёт результат, который один агент выдал бы за одну — потому что все пять генерировались одной моделью из почти одинакового контекста. Диагностический вопрос: если склеить все системные промпты в один и запустить одного агента, изменится ли результат по существу? Если нет — ролей не было, был театр.

Ревьюер-штамповщик. Второй агент, чья задача — «проверить работу первого», в подавляющем большинстве случаев отвечает «выглядит корректно». Ему не за что зацепиться: диф правдоподобен, объяснение автора связно, внешнего сигнала нет. Вы получаете зелёную галочку с нулевой информационной ценностью и с ненулевой ценой. Лечится это не запретом ревьюера, а требованием: ревьюер обязан завершиться прогоном, а не мнением.

Цепочка испорченного телефона. Три и более передач подряд: аналитик → архитектор → разработчик → тестировщик. Каждый шов теряет часть информации и добавляет часть выдумки; к четвёртому агенту исходное требование узнаётся с трудом. Если строите конвейер — считайте швы и помните, что каждый из них надо чем-то проверять.

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

Оркестратор без бюджета. Агент, которому разрешено порождать субагентов по своему усмотрению, будет их порождать. Он не платит за токены и не читает дифы. Без жёсткого потолка на число субагентов и глубину вложенности вы получаете дерево, стоимость которого растёт как произведение ветвлений. Потолок должен быть детерминированным и внешним — не просьбой в промпте, а ограничением схемы.

Систематизированный взгляд на отказы таких систем есть в работе Why Do Multi-Agent LLM Systems Fail? (Cemri et al., 2025). Авторы разбирают трассировки реальных многоагентных фреймворков и группируют отказы в три крупные категории: дефекты спецификации и устройства системы, рассогласование между агентами (потеря контекста, игнорирование чужого результата, расхождение в понимании задачи) и отказы верификации и завершения (работа объявляется законченной без проверки). Что важно для практика: большая часть отказов происходит не внутри агента, а между агентами — то есть в том самом шве.

Как это делать, если делаете: контракт субагента

Если решение принято, схема должна быть максимально скучной. Скучная схема отлаживается, интересная — нет.

Жизненный цикл одной делегированной подзадачи:

Обратите внимание на два перехода. Первый: подзадача отклоняется до запуска, если у неё нет команды проверки — это тот же критерий проверяемости шага, что разбирался в главе «Планирование». Второй: состояние «на проверке» не имеет исходящей стрелки к другому агенту. Проверка результата — это шов, и человек в нём обязателен.

Формализовать контракт удобно файлом в репозитории — так он попадает в ревью и живёт вместе с кодом:

# .agents/subtask-contract.yaml — что обязано быть в задании субагенту.
# Отсутствие любого поля — причина не запускать, а не «уточнить по ходу».

задача:
  цель: "Найти все прямые вызовы psycopg2.connect в обход фабрики соединений"
  область:                       # границы жёсткие: за них выходить нельзя
    - "src/**/*.py"
    - "scripts/**/*.py"
  запрещено:
    - "любая запись в файлы"     # разведка read-only
    - "сетевые вызовы"
    - "порождение других субагентов"

права:
  инструменты: [read, grep, glob] # write и bash не выданы физически,
                                  # а не запрещены просьбой в промпте

бюджет:
  токенов: 60000                  # жёсткий потолок сессии
  минут: 10

формат_ответа:                    # проверяемость важнее красоты
  тип: "список находок"
  поля: [путь, строка, фрагмент, уверенность]
  уверенность: [verified, derived, assumed]   # маркеры из REASONING-DISCIPLINE.md
  запрещено_в_ответе:
    - "оценки и рекомендации"     # разведка не решает, что делать
    - "пересказ содержимого файлов"

приёмка:
  - "каждая находка открывается по пути и строке"
  - "случайные три находки проверены человеком вручную"
  - "находки со статусом assumed перепроверяются до использования"

Правила, которые к этому прилагаются:

1. Один интегратор, и это человек. Слияние результатов — не задача агента. Агент не видел, откуда взялся чужой кусок, и разрешит конфликт правдоподобно.
2. Агенты не разговаривают друг с другом напрямую. Всё общение — через артефакты: файлы, ветки, комментарии в PR. Артефакт можно прочитать, продиктовать заново и положить в историю; реплику в чате между агентами — нет. Это же даёт наблюдаемость.
3. Права режутся физически. Разведчику не выдан write. Не «попросили не писать», а не дали инструмент. Разница принципиальная и разбирается в главе «Безопасность»; там же — почему субагент, читающий чужой контент, это отдельная поверхность для инъекции.
4. Возврат — ссылки, а не пересказ. src/db/pool.py:142 проверяется за пять секунд. «Я обнаружил, что соединения создаются напрямую в нескольких местах» не проверяется никак.
5. Бюджет на схему, а не только на агента. Потолок числа субагентов, глубины вложенности (обычно 1) и суммарных токенов задаётся снаружи.
6. Что запомнено — то в репозитории. Знание, добытое субагентом, живёт не в его окне, а в заметке или тесте. Что стоит хранить, а что вредно — в главе «Память агента» и в MEMORY-PROTOCOL.md нашего пакета.

Решение: нужен ли здесь второй агент

Перед запуском полезно пройти по короткому дереву. Оно намеренно смещено в сторону «не надо» — потому что ошибка «сделал сложно там, где хватало просто» дороже обратной.

Ветка «упёрся в качество» — самая важная и самая игнорируемая. Если один агент выдаёт плохое решение, второй агент того же семейства выдаст плохое решение с другой формулировкой. Помогает не количество узлов, а изменение входа: более точный контракт (глава 3), написанный заранее тест (глава 10) или человек, который знает предметную область.

Отладка многоагентного прогона

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

Минимум, который стоит логировать с первого дня:

• идентификатор задачи, общий для всех агентов прогона — иначе ленты не сшиваются;
• точный текст, ушедший субагенту — не «отправлено задание», а полный промпт;
• точный текст, вернувшийся обратно — это и есть содержимое шва;
• список файлов, которые агент прочитал и изменил — восстанавливается из инструментов;
• какой прогон и с каким результатом завершил каждую подзадачу;
• суммарные токены и время по каждому агенту — иначе оптимизировать нечего.

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

Мини-итог

• Многоагентная схема покупает два ресурса: изоляцию контекста и время по стенным часам. Ни независимой экспертизы, ни надёжности она не покупает.
• «Роли» — это текст в промпте, а не архитектура. Проверочный вопрос: изменится ли результат, если склеить промпты и запустить одного агента.
• Токены умножаются на числе агентов там, где копируется бриф и общий контекст. Делится только личная работа. Внимание человека не делится вообще.
• Шов между агентами — текстовый и лоссовый. Теряются неявные решения, статус уверенности и отрицательные результаты. По LAW-01 из нашего пакета, соединение двух проверенных частей не даёт проверенного целого, пока не прогнан сам шов.
• Второй экземпляр той же модели — не независимый проверяющий. Корреляция ошибок при дублировании была измерена ещё Найтом и Левесоном на людях; у одинаковых весов она заведомо выше. Самокоррекция без внешнего сигнала не улучшает результат (Huang et al.).
• Настоящие независимые узлы: компилятор, типы, заранее написанные тесты, фаззер, прод-метрики и человек с историей системы. Схема «генератор плюс внешний верификатор» работает именно потому, что верификатор не модель.
• Четыре оправданных сценария: read-only разведка веером, изоляция грязного контекста, свежий взгляд на диф, независимые треки в отдельных worktree.
• Пять антипаттернов: театр ролей, ревьюер-штамповщик, цепочка испорченного телефона, параллельная запись в общее, оркестратор без бюджета.
• Если делаете — делайте скучно: жёсткий контракт подзадачи, физически урезанные права, ответ ссылками, один интегратор-человек, внешний потолок на число агентов, общение через артефакты.
• Отладка стоит отдельно. Корреляционный идентификатор, сохранённые промпты и сводки, учёт токенов по агентам — с первого дня, а не после первого разбора.

Что дальше

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

Цена работы с агентом: токены, время и внимание человека

Источники

• An experimental evaluation of the assumption of independence in multiversion programming — Knight & Leveson, IEEE TSE, 1986. Классический эксперимент, показавший корреляцию ошибок между независимо написанными версиями.
• Large Language Models Cannot Self-Correct Reasoning Yet — Huang et al., ICLR 2024. Самокоррекция без внешней обратной связи не улучшает результат.
• Why Do Multi-Agent LLM Systems Fail? — Cemri et al., 2025. Таксономия отказов многоагентных систем по реальным трассировкам; большинство проблем — на швах.
• LLMs Can’t Plan, But Can Help Planning in LLM-Modulo Frameworks — Kambhampati et al., 2024. Генератор плюс внешний верификатор как рабочая асимметрия.
• Improving Factuality and Reasoning in Language Models through Multiagent Debate — Du et al., 2023. Аргумент в пользу спора нескольких экземпляров; читать вместе с условием сравнимости ответов.
• Self-Consistency Improves Chain of Thought Reasoning in Language Models — Wang et al., 2022. Голосование по сэмплам; работает там, где ответы сравнимы.
• Don’t Build Multi-Agents — Cognition, 2025. Позиция «делите контекст, а не агентов»; спорная, но аргументы про неявные решения сильные.
• How we built our multi-agent research system — Anthropic. Откуда взято число про кратность расхода токенов; текст производителя, читать с поправкой.
• Building effective agents — Anthropic. Разбор схем оркестратор-рабочие и генератор-оценщик; там же прямая рекомендация начинать с простейшего решения.
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, 2025. Расхождение между ощущаемой и измеренной продуктивностью.
• Фредерик Брукс, «Мифический человеко-месяц» — про то, что добавление исполнителей в опаздывающий проект увеличивает издержки на связь. Агенты не имеют самолюбия, но швы у них есть, а связь стоит токенов.
• products/workbench/templates/memory/ — наш пакет: COMPOSITION-AND-LAWS.md (LAW-01 про самый узкий шов и правило «закон — это тест»), REASONING-DISCIPLINE.md (маркеры verified / derived / assumed / unchecked, обязательные в сводке субагента), AGENT-MEMORY-CONTRACT.md (что агент обязан искать и цитировать до начала работы).