Глава 8 — Архитектурные раскладки развёртывания
Восьмой пост поглавного разбора LLM Primer IV: Designing AI Cognition with MCP. В котором две системы с идентичной логикой оркестрации в продакшене ведут себя очень по-разному, потому что вопрос «где на самом деле работает модель» отвечается тремя разными способами, и каждый ответ выставляет свой потолок латентности, стоимости и безопасности.
Почему существует эта глава
Главы 6 и 7 специфицировали, как агенты координируются. Они молчали по вопросу, решающему столь же значимую часть реального поведения системы: где работает каждый агент и как языковые модели, MCP-серверы и инструменты разложены по сети? Архитектурные решения этой главы трогают каждый запрос и каждый доллар. К 2025–2026 годам в MCP-экосистеме проявились три широко различных раскладки, и ни одна из трёх не является универсально верной. Каждая оптимизирована под разную комбинацию ограничений, и выбор имеет последствия, которые инженеры должны уметь сформулировать до того, как сделают его.
8.1 Reusable AI agent: модель упакована с сервером
Первая раскладка упаковывает языковую модель вместе с MCP-сервером и выставляет это сочетание как одну чёрноящичную возможность. Клиент вызывает «отревьюй этот pull request» так же, как вызвал бы инструмент; под капотом на серверной стороне крутится полный агентный цикл, вызывающий модель, дёргающий внутренние инструменты и возвращающий только финальный вывод. Паттерн появился, когда организации строили специализированных агентов — research, code-review, financial-analysis, — которых хотели выставить многим разным хост-приложениям без того, чтобы каждое понимало внутренности.
Сильные стороны реальны. Инкапсуляция позволяет авторам агента менять модели или перестраивать оркестрацию без видимых клиенту изменений. Переиспользуемость через хост-приложения означает, что один агент обслуживает Claude Code, корпоративное приложение и клиентский чат-бот через один интерфейс. Цены тоже реальны. Непрозрачность затрудняет дебаг: когда агент принимает неверное решение, клиент не видит, почему. Латентность складывается, потому что серверный цикл крутится на каждый вызов. И двойное бюджетирование структурно: оператор агента платит за свои вызовы модели, а клиент — за свои, и общая стоимость на взаимодействие может быть выше, чем каждая сторона изначально осознаёт.
Multi-tenant-вариант — один процесс агента, обслуживающий многие клиентские организации — существенно улучшает операционную экономику, амортизируя фиксированные расходы по арендаторам. Он же вводит межарендаторскую утечку данных как режим отказа первого класса. Несколько раскрытых инцидентов 2025 года были именно об этом, и операторам стоит проектировать tenancy в рантайм, а не полагаться на code review для отлова утечек между запросами.
8.2 Strict MCP purity: модель в клиенте
Вторая раскладка строго помещает языковую модель в клиент. MCP-серверы выставляют только данные и инструменты — никакого инференса. Хост запускает модель, принимает решения оркестрации и вызывает серверы, чтобы собирать контекст и выполнять действия. Мотивация — исходный проектный мотив протокола: MCP существует, чтобы решить проблему интеграции N на M, предоставляя единообразный интерфейс между моделями и инструментами, и серверы, гоняющие собственные модели, заново вводят проблему, которую протокол должен был решить.
Сильные стороны — контроль и прозрачность. Каждый вызов модели наблюдаем инструментарию клиента. Клиент выбирает модель под запрос, может фолбэкаться между провайдерами и несёт всю стоимость модели напрямую — никакого двойного бюджетирования, потому что в цепочке нет второй модели. Для регулируемых отраслей, где аудит-логи на клиенте обязаны захватывать полную цепочку рассуждения, strict purity удовлетворяет требование без неоднозначности.
Цены столь же ясны. Каждый кусок интеллекта должен переизобретаться каждым клиентом, что реальная нагрузка для организаций с многими хост-приложениями. Некоторые возможности — многошаговое исследование, итеративная доводка — неуклюже факторятся как single-shot-инструменты, и их выставление либо толкает сложную оркестрацию в клиент, либо тихо нарушает чистоту, позволяя серверу гонять собственную модель. И клиент обязан уметь крутить оркестрацию, что на практике означает опираться на Strands, LangChain, Semantic Kernel или Microsoft Agent Framework, а не катить цикл с нуля.
8.3 Hybrid: клиентская оркестрация с серверным исполнением
Третья раскладка делит разницу. Клиент оркестрирует и крутит основной инференс; отдельные MCP-серверы гоняют собственные вызовы модели для специализированных подзадач. Самый ясный пример — долгий deep-research-инструмент. Клиенту, которому нужно вплести результат исследования в более широкий workflow, не хочется управлять каждым шагом исследования; ему хочется вызвать «исследуй X и расскажи, что нашёл» и получить синтез. Исследование многошаговое, многосорное и выигрывает от собственной внутренней оркестрации.
Гибридный паттерн работает, когда граница проведена по осмысленному шву — подзадача с ясными входами и выходами, достаточно самодостаточная, чтобы серверный интеллект мог её завершить без координации клиента, и достаточно специализированная, чтобы её прогон чёрным ящиком бил прогон через общий оркестратор. Research, code analysis, document synthesis подходят под профиль. Общий разговор — нет.
Цена — архитектурная сложность. Теперь интеллект работает в двух местах, наблюдаемость должна покрывать границу, а атрибуция стоимости сидит между двумя чистыми паттернами. Полезная дисциплина — ограничивать число интеллектуальных серверов и держать каждый сфокусированным на хорошо определённой возможности. Два-три эксплуатируемы; двенадцать становятся федерацией, которую ни одна команда не понимает. Гибридные развёртывания также склонны эволюционировать к одному из чистых концов спектра со временем, и архитекторам стоит честно сказать себе, является ли их гибрид устойчивым проектом или переходным состоянием.
Что подготавливает глава 8
Три главы части III прошли пространство дизайна мультиагентных систем с точки зрения механизма. Чего они пока не покрывают — подложку под ними: контекст, который получает каждый вызов модели, и память, переживающую через вызовы. Эффективность агента зависит от того, что он может видеть, когда действует, и что он может вспомнить о том, что делал раньше. Окно контекста конечно. Архитектура памяти должна быть спроектирована. Паттерны управления бюджетом внимания, использования черновика, эпизодической и семантической памяти — это подложка, превращающая координированный набор агентов в систему, делающую полезную работу часами, днями и дольше.
Дальше — Глава 9: Управление бюджетом внимания. Почему окно в миллион токенов — потолочное значение, а не рабочая точка, что съедает бюджет и как MCP, RAG и дообучение каждый подходят к разной форме пробела.
