Привет, Хабр! На связи Дмитрий Бондарев, я backend-разработчик Авито — занимаюсь проектами на стыке разработки и машинного обучения. В первой части этого материала мы обратились к истокам API и существующим ограничениям интерфейса в работе с агентами.
В этой статье обратимся к архитектуре MCP и ключевым принципам протокола, рассмотрим, как он решает проблемы интеграции с агентами. Обсудим вызовы, которые ИИ бросает нашему мышлению и подходу к разработке и бизнесу. И, наконец, сделаем выводы — так ли нужны агенты в работе и повседневной жизни?
Содержание:
Как MCP решает проблемы интеграции с LLM и создает новые возможности
Как нужно изменить наше мышление, чтобы соответствовать реалиям рынка и нуждам бизнеса
Model Context Protocol: архитектура и решения
MCP — Model Context Protocol, — еще называют USB-C для ИИ-приложений, так как с ним можно быстро соединить сервисы между собой и радоваться жизни. Это открытый стандарт для подключения ИИ-ассистентов к источникам данных и документам, в основе которого лежит протокол JSON-RPC 2.0.
Релиз MCP состоялся 25 ноября 2024 года, и спустя всего несколько месяцев после релиза протокола пользователи создали десятки тысяч MCP-серверов. Они есть буквально для всего: например, можно взять мессенджер, загрузить свой API-ключ, и LLM будет общаться через ваш профиль в Telegram. Можно доставать информацию из Slack и Confluence, делать саммари, даже создавать крутые 3D-модели. Например, на одной конференции ребята из Сбера рассказывали, как они строят CAD-модели, которые используют в инженерии.
Архитектура MCP
В основе MCP лежат три взаимосвязанных модуля, каждый из которых отвечает за отдельный аспект взаимодействия между языковой моделью и внешними системами. Архитектура протокола выстроена так, чтобы разделить ответственность между этими компонентами. Это обеспечивает независимость интеграций от конкретной модели и создать единый способ работы с инструментами, данным и пользовательским контекстом.
Client — компонент на стороне хоста, который устанавливает соединение с MCP-сервером, согласует возможности и вызывает предоставленные сервером функции (tools, prompts и т.д.). Может предоставлять серверу сервисы клиента, например sampling. Знает, как работать с MCP-серверами и поддерживает динамические возможности.
Host — хост-приложение, внутри которого работают клиент и модель. Он оркестрирует сессии, маршрутизирует запросы между моделью и несколькими серверами, изолирует их, контролирует доступ и хранит историю диалога.
Server — это уже самостоятельный процесс, публикующий возможности через MCP и обрабатывающий запросы клиента (вызовы инструментов, доступ к ресурсам, предоставление промптов). Не видит полный контекст диалога — вся координация происходит через хост.
Ключевые принципы дизайна MCP
Серверы должны быть простыми в разработке
Хост-приложение берёт на себя сложную оркестрацию, что позволяет быстро разворачивать MCP-серверы, формировать их с чётко определенными возможностями и с минимальными расходами на организацию.
Композиционность архитектуры
Модульный дизайн позволяет изолировать каждую сервисную функциональность, легко комбинировать разные серверы, независимо развивать различные компоненты и создаёт пространство для масштабирования системы.
Серверы не видят полный контекст диалога
Серверы получают только необходимую контекстную информацию, а полная история разговора остается у хоста. Каждое серверное соединение изолировано, а все взаимодействия между серверами контролирует хост.
Capability Negotiation — согласование возможностей
Это процесс обмена информацией о поддерживаемых функциях между клиентом и сервером при инициализации соединения. Механизм позволяет определить доступные возможности в рамках сессии и оптимизировать взаимодействие между компонентами системы.
При установке соединения клиент отправляет серверу запрос на обнаружение (discovery), а сервер предоставляет структурированное описание всех своих возможностей — какие ресурсы (resources) доступны и какие инструменты (tools) позволяют изменять внешнее состояние (например, отправлять письма или создавать задачи).
Клиенты MCP поддерживают:
sampling — механизм пробной проверки возможностей сервера перед их использование,
notifications — механизм подписки на обновления от сервера (вместо того, чтобы регулярно опрашивать сервер о его возможностях, клиент «запоминает» интерес к определенным типам событий и ждет уведомлений).
Resources
Приложение самостоятельно определяет моменты обращения к ресурсам и использует полученные результаты для своих задач.
Можно использовать:
для сбора данных, необходимых для работы приложения;
для обогащения сообщений дополнительным контекстом.
На скриншоте — пример интеграции Claude с Google Drive. Пользователь хочет добавить файлы в запрос. Приложение запрашивает список доступных файлов, а пользователь выбирает нужные для работы.
Tools
Это механизм вызова функций, который управляется LLM. Позволяет модели:
выполнять необходимые операции в реальном времени,
использовать внешние сервисы и функции,
обрабатывать запросы с помощью специализированных утилит.
Например, мы можем попросить Claude посчитать корень из трёх, используя JavaScript. У Claude есть tools интерпретации JavaScript, который использует этот инструмент для обработки запроса.
Prompts
Шаблоны запросов, которые полностью контролирует пользователь. Он самостоятельно определяет момент их использования в зависимости от своих задач.
Контроль реализован через:
интерактивные команды (slash-команды);
кнопочные интерфейсы;
элементы меню и другие элементы UI.
Промпты применяются для запуска рабочих процессов, автоматизации типовых задач и быстрого выполнения повторяющихся операций.
Способы подключения MCP (Transport Agnostic)
MCP использует гибкие механизмы подключения, адаптированные под разные сценарии использования
Локальное выполнение (STDIO) обеспечивает:
Прямое взаимодействие через стандартные потоки ввода-вывода;
Высокую производительность без сетевых задержек;
Повышенный уровень безопасности благодаря выполнению операций в локальной изолированной среде;
Упрощенную отладку.
Особенности удаленного выполнения (HTTP + SSE):
Поддержка HTTP-запросов для вызова инструментов;
Поддержка корпоративных стандартов безопасности и авторизации;
Server-Sent Events (SSE) для двунаправленной связи;
Высокая масштабируемость;
Возможность построения распределённой архитектуры.
Как MCP решает проблемы интеграции с LLM-агентами?
Решение проблемы MxN: M+N
Архитектура MCP предлагает решение в формате M+N, в котором:
существует единая абстракция для всех инструментов;
есть стандартизированный интерфейс взаимодействия;
унифицирована схема интеграции.
На практике реализация всё же сталкивается с некоторыми ограничениями. Даже продвинутые модели демонстрируют недостаточную эффективность работы с MCP. На сложных задачах точность выполнения операций не превышает 50%, а вероятность ошибок возрастает при увеличении количества шагов.
Однако при всем этом обычный REST в тех же условиях, скорее всего, уже умер бы.
Решение проблемы self-discovery: динамическое обнаружение инструментов
Механизм обнаружения (он же runtime discovery) в MCP реализован через стандартизированные методы, которые позволяют автоматически находить доступные инструменты, получать метаданные о каждом инструменте и определять схемы входных и выходных данных.
// Запрос списка доступных инструментов { “jsonrpc”: 2.0”, “method”: “tools/list”, “id”: 1 } // Ответ с описанием инструментов { “jsonrpc”: “2.0”, “result”: { “tools”: [ { “name”: “create_report”, “description”: “Создает отчет по клиенту”, “inputSchema”: { … } } ] }, “id”: 1 }
Работает runtime discovery следующим образом:
Инициализируется запрос на обнаружение.
Система возвращает список доступных инструментов.
Для каждого инструмента предоставляется уникальное имя, описание функционала, схема вводных параметров и описание входных данных.
Решение проблемы контекста: от stateless к stateful-сессиям
Классические API построены на stateless-принципе, что создает дополнительную нагрузку на LLM-агента, увеличивает вероятность ошибок и время выполнения.
GET /api/tasks?user_id=123&status=active&filter=urgent GET /api/tasks?user_id=123&status=active&filter=urgent&page=2 POST /api/tasks { “user_id”: 123, “title”: “New task”, … }
Stateful-подход в MCP предлагает решение через встроенные контекстные сессии:
Сохраняется контекст диалога;
Есть поддержка длительных взаимодействий;
Управление состояниями автоматизировано;
Оптимизирован обмен данными.
Пример MCP:
// Контекст сохраняется между вызовами 1. “Покажи мои срочные задачи” 2. “Отметь первую как выполненную” // знает о предыдущем списке
Решение проблемы гранулярности: one tool, one human task
Основная проблема классических API — избыточная гранулярность, множество мелких запросов и необходимость множественных вызовов.
Пример REST:
1. GET /user/123 2. GET /user/123/orders 3. GET/orders/456/items 4. POST /reports { user_data, order_data, items_data } 5. PUT /reports/789 { status: “completed” }
Подход MCP ориентирован на высокоуровневые операции, соответствующие человеческим. Характеризуется:
едиными инструментами для выполнения комплексных задач;
человекочитаемыми интерфейсами;
снижением когнитивной нагрузки.
Классический пример рефакторинга API — конвертация 90 отдельных вызовов в 20 высокоуровневых задач.
Пример MCP:
{ “name”: “generate_customer_report”, “description: “Создает полный отчет по клиенту с историей заказов”, “parameters”: { “customer_id”: 123, “period”: “last_month” } }
Решение проблемы выбора инструментов: структурированная организация
Cognitive lead возникает при слишком большом количестве инструментов. Качество выбора падает с ростом числа опций, возникает информационная перегрузка — а это влияет на эффективность работы модели.
// Инструменты организованы по серверам { “filesystem_server”: [“read_file”, “write_file”, “list_directory”], “database_server”: [“query_db”, “update_records”], “email_server”: [“send_email”, “create_draft”] }
Структурированный подход MCP включает:
Иерархическую организацию — группировку инструментов по серверам;
Семантическое описание — понятные для LLM-моделей описания;
Контекстную группировку — объединение по сценариям использования.
Двунаправленная связь и server-initiated messages
Серверы могут инициировать сообщения и уведомления.
// Сервер может отправить progress notification { “jsonrpc”: “2.0”, “method”: “notifications/progress”, “params: { “progressToken”: “report_generation_123”, “progress”: 75, “total”: 100 } }
// Сервер может запросить дополнительную информацию: { “jsonrpc”: “2.0”, “method”: “sampling/createMessage”, “params”: { “messages”: [ { “role”: “assistans”, “content”: “Для создания отчета нужна дополнительная информация. Какой период включить?” } ] } }
Архитектурные сдвиги: от детерминизма к адаптивности
Раньше мы думали как архитекторы. Теперь же настало время мыслить как садовники. Потому что мы выращиваем систему, которая создает пространство политик, в которых может жить наш агент. Модель уже недетерминирована, она — почти как живое существо.
Классическая архитектура предполагает статические графы выполнения.
Предопределенные пути — последовательность вызовов известна при разработке.
Жёсткая логика — if/else-ветки в коде определяют поведение.
Ошибки = баги — неожиданный путь выполнения это ошибка разработчика.
MCP — это высокоуровневые инструменты, мимикрирующие человеческие задачи.
Адаптивные пути — модель выбирает стратегию выполнения в runtime.
Контекстные решения — выбор инструментов зависит от текущей ситуации.
Неопределённость как норма — система должна адаптироваться к новым сценариям.
Мы переходим от программирования алгоритмов к программированию возможностей, а от однонаправленной связи — к двунаправленной.
Классические API подразумевают только request-response, MCP же — встроенную двунаправленность, которая создает более богатое взаимодействие, приближенное к человеческому диалогу, где любая сторона может инициировать сообщение.
Архитектурная метафора: от заводского конвейера к живому организму
Раньше мы работали с «конвейером» — задача шла от этапу к этапу. Теперь же в наших руках что-то очень похожее на человеческий организм. Образно говоря, у модели есть мозг, и нужно, чтобы MCP-сервисы — конечности, органы, — уживались между собой. Различные органы взаимодействуют через общую нервную систему, то есть хоста, а сама модель способна к обучению и эволюции. Мы становимся в какой-то степени творцами этой эволюции, а не проектировщиками заводов. Это требует сдвига мышления — и у архитектора, и у разработчиков.
Практика внедрения: паттерны, безопасность, примеры
Мы не ожидали, что код моделей может стать настолько вероятностным. Непредсказуемость поведения агентов потребовала разработки особых паттернов и создания новых механизмов контроля и защиты, таких как AI Gateway — промежуточного сервиса, служащего единой точкой входа и контроля графика между клиентом и агентом.
Архитектурные паттерны агентов строятся на следующих принципах:
MCP в роли защитного фасада для микросервисов.
REST-вызовы объединяются в высокоуровневые инструменты.
управление транзакционностью реализуется в новой архитектуре.
Централизованный контроль через AI Gateway — важнейший компонент архитектуры. Он выполняет функции обработки MCP-трафика через специализированный слой (например, Azure API Managment), внедрения системы лимитов, валидации аргументов мониторинга и аудита. Кроме того, Gateway контролирует политики и защищает клиент от prompt injection.
Атака ShadowLeak
Эра ИИ привнесла новые, специфические риски. Нередки случаи prompt-injection атак — манипуляций через внедрение вредоносных промптов, и создания фальшивых инструментов-двойников, компрометирующих систему.
Один из самых известных случаев утечки данных произошел в июне 2025 года. На Gmail пользователя пришло инициированное письмо. Пользователь запросил через ИИ-агент саммари всех новых писем, но из-за внедренного в письмо обращения злоумышленников данные пользователя были скомпрометированы.
Схема работает так: к системе, содержащей чувствительные данные (например, к электронной почте) подключен агент. При недостаточной защите агента злоумышленники могут пробраться через уязвимость в системе и, внедрив свой запрос, получить данные пользователя.
Этот инцидент заставил пересмотреть подходы к безопасности. Теперь важно доверять не только разработчику — нужен комплексный контроль поведения агента. Система решений должна функционировать на уровне отдельных инструментов, а непредсказуемое поведение агента важно моделировать ещё на этапе разработки.
Классические bootstrap примеры
Код на GO: MCP server
type Input struct { Name string `json:"name" jsonschema:"the name of the person to greet"` } type Output struct { Greeting string `json:"greeting" jsonschema:"the greeting to tell to the user"` } func SayHi(ctx context.Context, req *mcp.CallToolRequest, input Input) ( *mcp.CallToolResult, Output, error, ) { return nil, Output{Greeting: "Hi " + input.Name}, nil } func main() { // Create a server with a single tool. server := mcp.NewServer(&mcp.Implementation{Name: "greeter", Version: "v1.0.0"}, nil) mcp.AddTool(server, &mcp.Tool{Name: "greet", Description: "say hi"}, SayHi) // Run the server over stdin/stdout, until the client disconnects. if err := server.Run(context.Background(), &mcp.StdioTransport{}); err != nil { log.Fatal(err) } }
Код на Python: MCP server
from mcp.server.fastmcp import FastMCP mcp = FastMCP(name="Tool Example") @mcp.tool() def sum(a: int, b: int) -> int: """Add two numbers together.""" return a + b @mcp.tool() def get_weather(city: str, unit: str = "celsius") -> str: """Get weather for a city.""" # This would normally call a weather API return f"Weather in {city}: 22degrees{unit[0].upper()}"
Делаем выводы
Model Context Protocol, хоть и не целиком, решает главные проблемы интеграции с языковыми моделями и меняет саму парадигму работы с агентами. Это больше не жесткий алгоритм, а среда, в которой ИИ-агент может гибко адаптироваться и принимать решения.
С правильным подходом агент может стать не просто инструментом, а партнером в решении бизнес-задач. Однако реализация требует дополнительных расходов и рисков, при этом не всегда действительно повышает эффективность решения задач. И в большинстве случаев это заставляет задуматься о целесообразности применения агентов.
Когда имеет смысл применять агентов?
Вы не можете заранее определить последовательность шагов и выбираете их в процессе выполнения задачи;
Жёсткая автоматизация не окупится из-за редкости задачи или высокой вариативности сценариев;
Часто меняются данные, политики, приоритеты и стратегии.
В других случаях классического workflow должно быть достаточно.
Кстати, если вам интересна работа в бигтехе — Хабр совместно с ЭКОПСИ проводит большое исследование IT-брендов работодателей. В прошлом году в нём поучаствовали 34 000 специалистов. Если у вас есть опыт — он точно будет учтён.
