Технологии
MCP становится бессессионным и изменяет способ работы предприятий с удалёнными серверами агентов
Спецификация Model Context Protocol за июль убирает обязательные сессии, привязку маршрутов и инициализирующее рукопожатие. AWS заявляет, что это изменение делает безсерверное развертывание естественным решением, хотя командам необходимо сохранить совместимый режим для старых клиентов.
Автор: Лео У ·
Протокол контекста модели убрал обязательные сеансы протокола, изменив инфраструктуру, необходимую для работы удалённых серверов инструментов для AI-агентов. Согласно спецификации от 28 июля 2026 года, инициализирующее рукопожатие и заголовок Mcp-Session-Id исчезли. Каждый запрос содержит свою версию протокола и контекст клиента, что позволяет любому работающему экземпляру сервера отвечать. AWS теперь рекомендует командам переходить от привязки к маршрутизации и общим хранилищам сеансов после того, как их старые клиенты будут выведены из эксплуатации.
Изменение носит архитектурный характер, а не косметический. Ранее серверы MCP часто привязывали разговор к одному экземпляру или размещали состояние сессии в DynamoDB или ElastiCache. Эта механика существовала, потому что последующие запросы зависели от контекста, установленного во время инициализации. Stateless MCP помещает информацию, необходимую для понимания вызова, в сам запрос, что ближе к обычной практике HTTP. Горизонтальное масштабирование становится проще, потому что экземпляр может выйти из строя, не забирая с собой свои сессии.
Без состояния не означает, что приложение не может сохранять состояние. Инструмент может хранить задачу, документ или транзакцию и возвращать идентификатор. Модель включает этот идентификатор в последующих вызовах. Состояние остается в базе данных приложения, в то время как протокол явно передает ссылку. Это различие важно, потому что команды иначе могут удалить хранилище, которое поддерживает реальное бизнес-непрерывность, а не инфраструктуру, которая только компенсировала старое рукопожатие.
Безсерверные решения переходят от временного обходного пути к использованию по умолчанию
AWS Lambda естественным образом предполагает, что запрос приходит, выполняется и заканчивается без постоянного соединения с одним процессом. Сессионный MCP мог бы работать там, но разработчикам приходилось выносить состояние рукопожатия и управлять непрерывностью. Новый ядро соответствует платформе: запрос — вход, ответ — выход. Для всплесков трафика агентов это может уменьшить простаивающую инфраструктуру и устранить хранилище сессий, единственной целью которого было поддержание протокола в активном состоянии.
AWS оценивает, что небольшое двухузловое хранилище сессий ElastiCache стоит около 23 долларов в месяц, но прямой счет — не главная экономия. Удаление состояния зависимости сокращает количество патчей, мониторинг, возможные ошибки и работу на вызове. На более крупном масштабе также «липкая» маршрутизация тратит ресурсы, потому что нагрузка следует за сессиями, удерживаемыми каждым экземпляром, вместо того чтобы распределяться равномерно по всем серверным узлам.
В спецификации добавлен метод server/discover, который показывает поддерживаемые версии протокола, возможности и идентичность. Клиентам не нужно вызывать его перед каждой задачей, но серверы обязаны его реализовать. Обнаружение (Discovery) предоставляет шлюзам более чистый путь согласования и помогает организациям инвентаризировать, что удалённая конечная точка может делать, прежде чем агент будет её использовать. Метаданные возможностей всё ещё следует рассматривать как утверждение и проверять в соответствии с политикой.
Маршрутизация и управление загрузкой теперь могут использовать HTTP-заголовки Mcp-Method и Mcp-Name вместо разбора тела запроса. Это позволяет шлюзам применять управление раньше и дешевле. Также это делает важным контролировать целостность заголовков. Сервер должен проверять, что метаданные маршрутизации соответствуют фактическому запросу, а не просто доверять клиенту, который может пометить опасный вызов инструмента как безвредную операцию чтения.
Повторные попытки становятся обязанностью инструментов проектирования
Протокол больше не полагается на возобновление потока для прерванного ответа. Клиент повторно отправляет вызов, что означает, что инструменты, вызывающие побочные эффекты, должны быть идемпотентными. Создание того же счета, отправка того же сообщения или изменение той же записи дважды не может быть допустимым поведением при повторной попытке. Разработчикам нужны ключи операций, дедупликация и четкие запросы статуса, чтобы сетевой сбой не превращался в дублированную работу.
Запросы с несколькими кругами ответа заменяет шаблон, при котором сервер возвращал вопрос клиенту во время удерживаемого открытого вызова. Сервер, которому требуется подтверждение или дополнительная информация, возвращает input_required с набором запросов и непрозрачным токеном requestState. Клиент собирает ответ и повторно отправляет исходную операцию. Любой экземпляр может продолжить работу, поскольку токен несет непрерывность, необходимую протоколом.
Этот дизайн чище для распределённых систем, но токен продолжения становится чувствительным. Он может предоставлять доступ или раскрывать часть незавершённого рабочего процесса. Токены нуждаются в защите целостности, ограничении срока действия и правилах повторного использования. Модель может рассуждать об явном идентификаторе, что полезно, но всё, что помещено в контекст модели, также может быть подвержено инъекции подсказок или случайному раскрытию. Приложениям следует хранить токен в непрозрачном виде и ограничивать его область одним действием.
Наблюдаемость улучшается через W3C Trace Context передается в метаданных запроса, позволяя вызовам подключаться к системам, совместимым с OpenTelemetry. Сквозные трассировки имеют решающее значение, когда агент проходит через шлюз, сервер инструментов, базу данных и внешний API. Командам следует избегать помещения секретов или необработанных чувствительных запросов в атрибуты трассировки. Лучшая корреляция не требует сбора каждого фрагмента содержимого.
Миграция не может произойти за один шаг удаления. Спецификация сохраняет канал совместимости для клиентов, использующих протокол 2025 года, и этим клиентам по-прежнему необходима инфраструктура сеансов. Операторы должны вести журнал версии протокола, публиковать дату прекращения поддержки и удалять «фиксацию маршрутизации» только после того, как старый трафик достигнет нуля. Преждевременная очистка создаст сбои, которые будут выглядеть как периодические, потому что только некоторые клиенты зависят от устаревшего пути.
Несколько функций теперь имеют график устаревания. Roots, Sampling, протокол Logging и HTTP плюс SSE имеют как минимум 12-месячный срок до удаления, с самым ранним сроком — июль 2027 года. Командам следует перемещать директории в параметры инструментов или URI ресурсов, напрямую вызывать поставщиков моделей вместо Sampling, использовать стандартное логирование и мигрировать транспорт на Streamable HTTP.
Проверки безопасности должны пересмотреть предположения, основанные на идентификаторах сессии. Некоторые шлюзы использовали сессию как удобную границу для лимитов частоты, группировки аудита или аннулирования. Удаление протокольной сессии не снимает эти бизнес-требования. Для них нужны явные замены, основанные на пользователе, клиенте, операции или состоянии приложения. Бессостояный транспорт должен улучшать архитектуру, а не стирать контроля, которые случайно были прикреплены к старому механизму.
Кэширование вводит аналогичную нюансировку. Новые поля свежести позволяют серверам указывать время жизни и область кэша, снижая количество повторных вызовов списков инструментов или ресурсов. Ответ, который безопасно использовать в пределах сессии одного пользователя, может быть небезопасен для всей организации. Серверам необходимо консервативно определять область и включать авторизацию в ключи кэша. Прирост производительности не стоит того, чтобы возвращать метаданные или данные одного клиента другому.
Управляемые шлюзы могут скрывать часть миграции. AWS заявляет, что Bedrock AgentCore Gateway управляет протоколом и обеспечивает обратную совместимость для клиентов, использующих сервис. Это удобство переносит ответственность за реализацию на провайдера, но не снимает ответственность. Операторам по-прежнему необходимо знать, какие версии используют их клиенты, как шлюз повторяет побочные эффекты и какая телеметрия доступна при сбое вызова.
Тестирование на соответствие должно стать частью развертывания. Сервер может работать с одним хостом, но неправильно обрабатывать обнаружение, продолжение или ошибки при взаимодействии с другим. Официальный пакет тестов может выявить нарушения протокола, но команды должны добавлять случаи использования приложения для авторизации, повторяющихся запросов и прерванных процессов. Интероперабельность — это причина использовать стандарт; тестирование только успешного сценария лишает этого преимущества.
Пересмотр может ускорить развитие более крупного рынка небольших специализированных удалённых инструментов, поскольку разработчики могут развертывать их без управления инфраструктурой сессий. Это снижает стоимость интеграции и расширяет цепочку поставок, которую предприятие должно оценивать. Реестры, подписи, происхождение и проверка разрешений становятся более важными, так как один агент составляет инструменты из множества операторов. Более простое размещение не должно означать автоматическое доверие.
Беспартийная ревизия делает MCP менее особенным в полезном смысле. Инструменты удалённых агентов теперь соответствуют знакомым шаблонам балансировки нагрузки, безсерверной архитектуры, трассировки и повторных попыток. Эта знакомость снижает стоимость развертывания, но также устраняет оправдания для слабой инженерии. Как только сессии перестают скрывать непрерывность, состояние, авторизацию и идемпотентность необходимо проектировать явно. Протокол стал проще; ответственность каждого инструмента остаётся одинаково серьёзной.
Темы: Протокол контекста модели, MCP, AWS, AI-агенты, безсерверная архитектура