Глава 13 — Фреймворки и облачная интеграция

Четырнадцатый пост поглавного разбора LLM Primer IV: Designing AI Cognition with MCP. В котором никто не строит продакшен MCP из голого протокола, честный вопрос 2025–2026 годов становится «на каком фреймворке стандартизироваться», и ответ оказывается зависящим меньше от функций, чем от того, в каком облаке живёт остаток системы.

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

К моменту, когда команда подключила аутентификацию, транспорт, состояние сессии, повторы при ошибках, структурированное логирование и десяток меньших деталей, отделяющих демо от эксплуатируемого сервиса, то, что начиналось как «мы просто будем говорить на MCP поверх HTTP», превратилось в свой маленький фреймворк — обычно худший, чем уже существующие. Инженерный вопрос — на каком из публичных фреймворков стандартизироваться, что каждый делает правильно и как они соединяются с облачными сервисами, держащими состояние. Эта глава методично проходит ландшафт: Strands с Amazon Bedrock; AWS-сервисы, окружающие его для состояния и поиска; Microsoft Agent Framework, LangChain и Semantic Kernel как другие продакшен-варианты; и паттерны интеграции, на которых сошлись reference-архитектуры. Цель не короновать победителя, а описать, для чего каждый фреймворк на самом деле.

13.1 Strands Agents и Amazon Bedrock

Strands — это open-source агентный фреймворк, выпущенный AWS в 2025 году и теперь бегущий внутри Amazon Q, AWS Support и AWS Glue assistant. Формулировка сознательная: Strands model-driven, что означает: цикл, решающий, что делать дальше, — это собственный tool-calling-цикл модели, а не planner-граф, накладываемый фреймворком сверху. Работа фреймворка — сделать этот цикл надёжным в продакшене: обрабатывать вызовы инструментов, управлять состоянием сессии, подключать MCP-серверы первоклассными источниками инструментов через MCPClient и маршрутизировать всё через хостируемый каталог моделей Bedrock. Слой моделей подключаем — API Anthropic, OpenAI, Ollama, LiteLLM, — но Bedrock — это значение по умолчанию и история аудита.

Мультиагентная история — место, где Strands зарабатывает продакшен-репутацию. Три паттерна композиции чисто ложатся на формы оркестрации предыдущих глав: Agents-as-Tools (простейшая форма — агент, обёрнутый как инструмент, который может вызывать другой агент); Swarm (peer-to-peer с общей рабочей памятью); и Graph (детерминированная топология, где модель заполняет каждый узел). Паттерны вкладываются в продакшене. Операционный налог платится наблюдаемостью, и Strands его платит, эмитируя OpenTelemetry-спаны на каждый вызов агента, каждый вызов инструмента, каждый вызов модели, — так что четырёхуровневая композиция реконструируется из логов без поэтажной инструментации. Bedrock добавляет историю границы доступа: IAM контролирует, какие модели может вызывать данный агент; CloudTrail логирует использование. Bedrock Guardrails обрабатывает фильтрацию содержимого у шлюза, Knowledge Bases даёт managed retrieval, а AgentCore — набор примитивов AWS 2025 года — формализует заботы памяти, идентичности и рантайма для команд, желающих полностью managed runtime, а не self-hosted.

13.2 AWS как state-слой

Агенту, работающему часами и помнящему, что было вчера, нужно хранилище, переживающее процесс. Устоявшийся в продакшене паттерн: runtime-состояние (текущая сессия, task ledger, инфлайт-вызовы инструментов) в DynamoDB для быстрого ключевого доступа; artifact-состояние (сгенерированные документы, промежуточная работа) в S3 со структурой ключей с префиксом сессии, дающей и естественные IAM-границы, и бесплатное версионирование; семантическое состояние (долгосрочная память, прошлые разговоры) в векторном хранилище — OpenSearch Service для горячей рабочей памяти, более новый S3 Vectors для холодной или архивной. Двухуровневое разделение между S3 и DynamoDB не преждевременная оптимизация. Оно держит DynamoDB-item под 400 КБ, избегает read-amplification на каждом шаге и позволяет каждому слою масштабироваться независимо.

Выбор слоя состояния определяет режим отказа всей системы. Агент, чьё состояние только в памяти процесса, теряет всё при перезапуске. Агент, чья память долговечна, но чей индекс не синхронизирован, вспоминает ссылки на документы, которые он больше не может найти. Продакшен-развёртывания относятся к этому как к отдельным контрактам консистентности: транзакции DynamoDB для атомарности состояния, S3 strong-read-after-write для контракта артефактов, индексирующий пайплайн, публикующий документы в S3 до upsert-а их векторов, чтобы retrieval не указывал на то, чего ещё нет. Граница безопасности заслуживает той же заботы. Собственное руководство AWS по Strands рекомендует пер-сессионные учётные данные через STS вместо переиспользования runtime-роли для вызовов инструментов с данными конечных пользователей — AgentCore Identity это автоматизирует — чтобы AWS-уровневая идентичность за разрушительным действием была реальным конечным пользователем, а не общей ролью агента. В регулируемых средах это единственный приемлемый ответ.

13.3 Microsoft Agent Framework, LangChain и Semantic Kernel

Microsoft-овская и open-source сторона ландшафта устоялась иначе. Microsoft Agent Framework прибыл в конце 2025 года как явное слияние Semantic Kernel и AutoGen — плагин-модель SK и .NET-интеграция с мультиагентными паттернами AutoGen и Python-first DX. MCP-интеграция встроена через MCPStdioTool и MCPStreamableHTTPTool; Azure AI Foundry — хостируемый дом, эквивалент Bedrock в AWS-мире. Отличительная черта против Strands — то, что граф разговора между агентами — это явный, replayable-объект, что огромно важно для оценки, потому что неудавшийся разговор можно перепрогнать с модифицированным промптом и сравнить по ходам. Цена — больше структуры, чем налагает Strands; правильный компромисс в зрелых развёртываниях, неверный — в исследовательской работе.

LangChain в 2026 году — другое животное, чем LangChain в 2023-м. Исходная абстракция chains стала вторичной; первичная поверхность — LangGraph для оркестрации и LangSmith для наблюдаемости и оценки. Сильные стороны — широта (у каждой модели, БД и инструмента, кажется, есть адаптер) и зрелость оценки в LangSmith. Слабость, которую практики честно называют, — площадь поверхности: высокоуровневые абстракции фреймворка отличны для первых 90% работы, а последние 10% обычно делаются обдиранием слоёв, пока команда не поймёт, что каждый из них делает. Команды, планирующие этот переход, выпускают быстрее, чем команды, борющиеся с абстракциями. Semantic Kernel остаётся фреймворком для .NET-команд; плагин-модель [KernelFunction] чисто ложится на .NET-хосты сервисов. Паттерн, появившийся во всех трёх: тонкий агент, толстый MCP — возможности живут за границей протокола, фреймворки становятся тонкими прокси, и один и тот же MCP-сервер потребляется Strands в AWS, Microsoft Agent Framework в Azure и LangChain на ноутбуке разработчика без работы по портированию. Это та траектория, которую протокол был спроектирован сделать возможной.

13.4 Продакшен-паттерны интеграции

Три паттерна устоялись в reference-архитектурах 2025–2026 годов. Паттерн gateway-and-state-layer ставит managed-модель-шлюз (Bedrock, AI Foundry, LiteLLM) перед слоем моделей и отдельный долговечный state-слой позади. Шлюз — место, где живут auth, rate limiting, фильтрация содержимого и аудит; state-слой — место, где живёт долговечность. Этот паттерн — продакшен-значение по умолчанию; новые развёртывания должны его принять, если только нет конкретной причины не принимать, потому что команды, пропустившие шлюз и вызывающие провайдера модели напрямую, жалеют об этом в течение квартала. Паттерн MCP service mesh относится к MCP-серверам как к микросервисам и выставляет их через mesh, обрабатывающий mTLS, повторы и circuit breaking — стоит цены только в масштабе (более десяти серверов) или в регулируемых средах, требующих сетевой аттестации. Паттерн managed-everything отдаёт рантайм, память, идентичность и реестр инструментов managed-облачному агентному сервису (Bedrock AgentCore, Azure AI Foundry Agent Service, Vertex AI Agent Builder); выигрывает для внутренней автоматизации и copilot-ов, где агент не первичный продукт, и проигрывает для команд, где агент и есть продукт и операционные рычаги важны. Два паттерна, которые не выиграли и стоит назвать как негативные примеры: всё-в-LLM-контексте (агенты, чья память — постоянно растущий системный промпт) и фреймворк-как-оркестратор (жёсткий DAG, где модель заполняет параметры узлов). Оба умирают в продакшене по причинам, разобранным в главе 9, и урок, который усвоила область, — это что правильный баланс между структурой фреймворка и свободой модели сдвигается дальше в сторону модели по мере того, как модель становится способнее.

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

Фреймворки и облачные сервисы позволяют командам выпускать MCP-агентов без переписывания протокол-стека каждый раз. Чего они сами по себе командам не говорят — это работает ли получившаяся система на самом деле: решает ли агент задачи, под которые он был построен, как он ведёт себя под нагрузкой, где обрывы производительности и как честно сравнить две конкурирующие архитектуры. Глава 14 берёт этот вопрос в лоб: проходит MCP-Universe Benchmark, два системных режима отказа, которые он раскрыл (деградация на длинном контексте и исследование неизвестных инструментов), и сторону пропускной способности, где разрыв между пулом разделяемых сессий и наивным паттерном session-per-request — примерно порядок величины.

Дальше — Глава 14: Бенчмаркинг, тестирование и производительность. MCP-Universe на реальных серверах, работающие смягчения для длинного контекста и неизвестных инструментов, десятикратный разрыв пропускной способности между session-per-request и пулом сессий и куда серия идёт дальше.