Из этой статьи вы узнаете:

Спецификация MCP теперь поддерживает «агентные» возможности: возобновляемые потоки (для сохранения непрерывности сессии), elicitation (запрос пользовательского ввода), sampling (обращение за помощью к ИИ) и уведомления о прогрессе (для обновлений в реальном времени). Эти функции можно сочетать, чтобы создавать сложные Agent-to-Agent системы.

Многие разработчики, изучающие инструменты с «агентным» поведением, считают, что MCP непригоден для построения межагентного взаимодействия. Так как первые примеры использования Model Context Protocol были построены по простой схеме запрос–ответ.

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

Эти возможности можно комбинировать, создавая сложные «агентные» и многоагентные системы — все они работают по протоколу MCP.

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

Важно, что и сами хост-приложения тоже являются агентами: они координируют задачи, хранят состояние и принимают интеллектуальные решения о маршрутизации. Это и создаёт настоящую модель «агент–агент»: оркестраторы (хосты) взаимодействуют с узкоспециализированными агентами (инструментами).

Главная особенность таких инструментов, делающая их «агентными», — способность удовлетворять инфраструктурные требования, которые мы рассмотрим ниже.

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

Чтобы поддерживать такое поведение, инструментам MCP необходимы четыре ключевые инфраструктурные возможности. Ниже мы разберём каждую из них, приведём примеры использования и покажем, как MCP их реализует.

Агентам нужны механизмы для информирования пользователей о прогрессе (для наблюдаемости, отладки и укрепления доверия), а также возможность отправлять промежуточные результаты, чтобы реагировать и корректировать выполнение на основе частичных данных.

MCP поддерживает эти возможности и передает статус в реальном времени; при этом рассматриваются предложения по расширению возможностей потоковой передачи частичных результатов и улучшению механизма уведомлений о прогрессе.

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

Для долгоживущих агентов важно сохранять непрерывность выполнения задач при сетевых сбоях, чтобы клиенты могли переподключаться и продолжать работу с того же места, а не терять прогресс или запускать сложные операции заново. На данный момент механизм передачи данных MCP StreamableHTTP поддерживает возобновление сессий и повторную доставку сообщений.

Для возобновления сессий серверы должны реализовать EventStore, чтобы воспроизводить события при повторном подключении клиента. Сообщество также обсуждает внедрение независимых от протокола передачи данных потоков возобновления, чтобы расширить эту возможность за пределы StreamableHTTP.

Механизм передачи данных MCP StreamableHTTP и хранилище событий позволяют без потерь возобновлять сессии: если клиент отключается, он может переподключиться, передать данные сессии (идентификатор сессии и последний идентификатор события), и сервер воспроизведёт пропущенные события, продолжив выполнение задачи без потери прогресса.

Долгоработающим агентам необходимо сохранять состояние, которое переживает перезапуск сервера и позволяет проверять статус или результаты вне основной сессии. Это дает возможность отслеживать прогресс между сессиями. В MCP протоколе такая функциональность реализуется через Resource Links: в ответ на вызов инструмента он может создать ресурс, сразу вернуть ссылку на него и продолжить обработку в фоновом режиме, обновляя связанный ресурс. Клиенты могут опрашивать этот ресурс или подписываться на него, чтобы получать обновления о статусе и результатах.

Постоянный опрос ресурсов или подписка на обновления при больших объёмах данных может приводить к значительным затратам. В сообществе MCP обсуждается использование механизмов webhooks и триггеров, которые позволят серверам самостоятельно уведомлять клиентов об изменениях, снижая нагрузку в сценариях с высоким трафиком.

Инструменты MCP теперь могут возвращать Resource Links, которые клиент может опрашивать или на которые может подписаться, чтобы получать уведомления. Это обеспечивает стабильный доступ к результатам работы инструментов.

Агентам нередко требуется дополнительный ввод во время выполнения задачи — уточнение или подтверждение от человека при принятии важных решений, а также сгенерированный ИИ-контент или ответы для сложных подзадач. Model Context Protocol поддерживает такие сценарии через механизмы elicitation (запрос пользовательского ввода) и sampling (запрос генерации ответов LLM через клиента), что позволяет агентам динамически получать нужную информацию в процессе выполнения вызова инструмента.

В этой статье мы подготовили репозиторий с полной реализацией долгоработающих агентов на основе MCP Python SDK с использованием механизма StreamableHTTP для возобновления сессий и повторной доставки сообщений. Эта реализация демонстрирует, как возможности MCP можно комбинировать, чтобы создавать сложное поведение, характерное для «агентов».

Наш пример кода демонстрирует, как хост-приложение может подключаться к серверу с несколькими инструментами. В нём реализованы два основных агента:

Оба агента показывают обновления прогресса в реальном времени, поддерживают интерактивные подтверждения и позволяют возобновлять сессии.

Архитектурная заметка

Наша реализация уже демонстрирует межагентное взаимодействие. Хост-приложение выступает в роли агента-оркестратора, который взаимодействует с пользователями и направляет запросы специализированным агентам (агенту по бронированию путешествий, агенту-исследователю) на MCP сервере.

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

Чтобы масштабировать работу хост-агента (оркестратора) в схему взаимодействия с удалёнными агентами MCP на нескольких серверах, его можно дополнить следующими возможностями:

Обладая такими возможностями, один агент-оркестратор сможет координировать работу множества специализированных агентов на разных серверах, используя те же примитивы MCP протокола, что и в нашем примере с одним сервером.

Расширенные возможности MCP протокола — уведомления о прогрессе, механизмы elicitation/sampling, возобновляемые потоки и постоянные ресурсы — позволяют реализовывать надёжные многоагентные системы и сложное агентное взаимодействие.