Глава 7 — Продвинутые совместные и динамические паттерны

Седьмой пост поглавного разбора LLM Primer IV: Designing AI Cognition with MCP. Когда топологию нельзя нарисовать на этапе проектирования — когда правильный следующий шаг зависит от того, что нашёл предыдущий, — паттерны главы 6 перестают быть достаточными.

Почему существует эта глава

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

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

7.1 Group chat и roundtable: maker-checker, мультиучастниковый консенсус

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

Честные режимы отказа — три. Сговор — когда maker и checker делят модель и промпт, checker одобряет всё. Защита — настоящая дифференциация ролей, в идеале разные модели. Не-завершение — строгий checker отвергает каждого кандидата; оркестратор должен принять best-seen или эскалировать. Дрейф checker-а — в общем roundtable-контексте checker начинает одобрять то, что отверг бы раньше, потому что оправдания maker-а накапливаются. Полевое наблюдение конца 2025 года контринтуитивно: самые надёжные системы maker-checker не дают checker-у видеть, как был произведён кандидат. Stateless-checker-ы — получающие только кандидата и рубрику — увеличивают долю верных отказов на 30–50%. Общий контекст — инструмент, а не значение по умолчанию.

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

7.2 Handoff и маршрутизация: динамическая делегация

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

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

Два других режима отказа формируют продакшен-дизайн. Петли handoff — специалист A отправляет к B, B отправляет назад к A — защита через детектирование повторных handoff-ов и принудительное иное разрешение. Потеря контекста — каждая сводка handoff-а с потерями, и следующий специалист может попросить информацию, которую пользователь уже дал, — защита через хранение полного разговора вне контекста любого специалиста, со сводкой как основным payload и полной историей по запросу. По мере роста числа специалистов плоские маршрутизаторы становятся хрупкими; паттерн, проявившийся в 2025 году, — иерархическая маршрутизация: грубый маршрутизатор выбирает категорию, маршрутизатор внутри категории выбирает специалиста. Два уровня — sweet spot в продакшене.

7.3 Magentic-оркестрация: планы, строящиеся по мере разворачивания работы

Для задач, чья декомпозиция неизвестна на старте — «выяснить, почему БД медленная», «дебагать незнакомую систему», «исследовать сложную тему», — ни один из предыдущих паттернов не достаточен. Magentic-оркестрация, названная по фреймворку Microsoft Magentic-One, — это семейство паттернов, где менеджер-агент держит task ledger и обновляет его по мере хода работы. У ledger есть явные слоты: первоначальная цель, текущее понимание (которое может уточняться), открытые подзадачи с приоритетами, закрытые подзадачи с результатами, открытия, могущие требовать пересмотра плана, и условие остановки. Менеджер читает ledger на каждом шаге, решает следующее назначение и интегрирует результаты обратно.

Сила — настоящая открытость. «Выясните, почему БД медленная» нельзя декомпозировать заранее — следующая подзадача зависит от того, окажется ли узким местом сеть, план запроса или горячая строка. Никакой фиксированный пайплайн не справится; никакая статическая handoff-топология не сможет правильно маршрутизировать, не зная заранее, какие специальности будут актуальны.

Стоимость — самая суровая в этой главе по каждому измерению: латентность, токены, инженерные усилия, операционный риск. Расход токенов растёт сверхлинейно, потому что ledger читается на каждом ходе. Каталогизированные режимы отказа остры. Ускользающее планирование — менеджер открывает подзадачи быстрее, чем закрывает, ledger растёт без ограничений. Дрейф цели — учась, менеджер переформулирует цель в сторону от намерения пользователя. Churn плана — каждое новое открытие запускает пересмотр плана, ни одно обязательство не держится достаточно долго, чтобы был прогресс. Появившийся паттерн — ограниченная magentic-петля: бюджеты на открытые подзадачи, общее число вызовов worker-ов и wall-clock-время, с эскалацией при достижении любого предела. Продакшен magentic-системы без границ иногда сжигают сотни долларов на задачах, которые менеджер не смог решить ни в каком практическом бюджете.

7.4 Выбор среди паттернов

Три вопроса выбирают между ними. Известна ли топология заранее? Если да — оставайтесь со статическими паттернами главы 6. Выигрывает ли работа от итерации против внешней проверки? Если да — петля maker-checker правильное добавление, встраиваемое внутрь любого другого паттерна. Насколько открыто планирование? Если границы ясны — handoff или последовательная справится; если по-настоящему эмерджентно — magentic необходимо, принимается со своими издержками.

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

Что подготавливает глава 7

Главы 6 и 7 специфицируют, как агенты координируются. Они не специфицируют, где агенты бегут, как языковая модель co-located с инструментами и как выглядит топология развёртывания на уровне процессов, машин и сетевых границ. Две системы с идентичными паттернами оркестрации могут быть развёрнуты драматически по-разному — разные профили латентности, разные структуры стоимости, разные позиции безопасности. Глава 8 покрывает это измерение.

Дальше — Глава 8: Архитектурные раскладки развёртывания. Три широко разных способа физически развернуть MCP — модель-с-сервером, модель-в-клиенте, гибрид — с реальными компромиссами по латентности, стоимости, операционной сложности и видам отказов, к которым каждый предрасполагает.