MCP (Model Context Protocol)

В последнее время аббревиатура MCP стала все более часто появляться в некоторых статьях и разделах комментариев на arXiv или Daily Papers Hugging Face, которые я просматриваю. Внезапно осознав, что мое представление об этом лишь приблизительное, я решил изучить его более подробно и поделиться с вами.

Single Agent

Давайте сначала рассмотрим архитектуру с одним агентом.

1. Инструменты — это функции, которые определены и вызываются в текущей программе. Определение функции инструментов будет включено в системную подсказку, чтобы позволить LLM понять доступные в настоящее время инструменты.

2. Память делится на две части: текущий поток данных сеанса, включая то, что выполняется на каждом шаге, и каков результат, сохраняется в памяти текущего сеанса и может быть полностью введен в LLM в любое время, чтобы позволить LLM определить, что делать дальше. Долгосрочные данные и база знаний пользователя, такие как данные о предпочтениях пользователя на платформе, контент домена, многораундовый контекст разговора и т. д., будут извлечены из векторной базы данных.

3. Маршрутизатор централизует планирование программы всего процесса, передавая вводимые пользователем подсказки/системные подсказки/память в LLM, а LLM проводит углубленное мышление и выдает конкретные задачи по выполнению, а маршрутизатор вызывает соответствующую функцию действия (function calling).

Это простая и общая архитектура с одним агентом, которая реализует цикл Мысль – План – Действие – Размышление (Мысль) в Агенте, при этом за все отвечает одна модель.

MCP

В приведенной выше архитектуре модуль Tools (Инструменты) имеет некоторые незначительные проблемы: не очень хорошая поддерживаемость и масштабируемость функций инструмента. Сложно управлять, когда их слишком много. Чтобы добавить функции, нужно обновить основную программу. Кроме того, нужно самостоятельно определить спецификацию вызова функции. Некоторые внешние сервисы инструментов, которые будут использоваться, нужно инкапсулировать самостоятельно.

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

Протокол контекста модели (MCP): новый стандарт интеграции в экосистеме ИИ

Протокол контекста модели (Model Context Protocol, MCP) — это открытый стандарт, разработанный и представленный компанией Anthropic 25 ноября 2024 года. Основная цель MCP — создание унифицированного протокола связи между большими языковыми моделями (LLM) и внешними источниками данных и инструментами. Как по мне, MCP появился как естественная эволюция подхода Function Calling, преодолевая его ограничения и расширяя возможности взаимодействия моделей ИИ с внешним миром. Если Function Calling можно рассматривать как точечное решение конкретных задач взаимодействия, то MCP представляет собой комплексный подход к проблеме интеграции, обеспечивая более гибкую, масштабируемую и стандартизированную экосистему.

Сущность MCP

MCP — это не фреймворк или инструмент, а именно протокол, аналогичный:

• HTTP для интернета;

• SMTP для обмена сообщениями;

• LSP (Language Server Protocol) для поддержки языков программирования.

Anthropic точно характеризует MCP как "эквивалент порта USB-C для агентских систем" — универсальный интерфейс, позволяющий стандартизировать взаимодействие между различными компонентами экосистемы ИИ независимо от их производителя.

Как говорится, картинка стоит тысячи слов.

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

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

Исходные вызовы функций инструмента инкапсулируются с помощью MCP Server, и архитектура становится такой:

Отличие от исходного чистого вызова функции заключается в том, что архитектура более гибкая, включая:

1. Кластеризация : разрозненные функции можно объединить в одну службу для удобства управления.

2. Развязка : вызов фактически происходит на соответствующей стороне сервера MCP, а не напрямую вызывается службой Agent. Инструмент расширения развертывания развязывается от проекта Agent.

3. Сплоченность: сам сервер MCP может выполнять некоторые действия слаженно, включая независимое управление ресурсами, независимый контекст и т. д.

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

5. Унификация: вызовы как клиентских, так и облачных инструментов могут быть реализованы с использованием унифицированного протокола MCP.

Архитектура и принцип работы

MCP определяет:

1. Способы взаимодействия клиентов с серверами;

2. Методы обработки серверами инструментов (API, функции);

3. Правила доступа к ресурсам (файлы, базы данных).

В этой архитектуре:

• Модели ИИ выступают в роли клиентов;

• Внешние сервисы и источники данных — периферийные устройства (инструменты);

• MCP — стандартизированный интерфейс (порт) между ними.

Пример

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

1. Как LLM модель взаимодействует с MCP сервером?

2. Как LLM модель вызывает инструменты на стороне MCP сервера?

Реализация собственного MCP-сервера

Создать базовый MCP-сервер достаточно просто. Вот пример сервера для работы с локальными Git репозиториями с использованием FastMCP: GitHub