Раскрытие MCP: Унифицированный протокол вызова инструментов
Определение MCP
MCP — это открытый технический протокол, разработанный для стандартизации взаимодействия больших языковых моделей (LLM) с внешними инструментами и сервисами. Представьте его как универсальный переводчик в мире искусственного интеллекта, позволяющий AI-моделям ‘общаться’ с широким спектром внешних инструментов. Он предоставляет общий язык и структуру для LLM для запроса и использования функциональности, предлагаемой различными приложениями и сервисами.
Необходимость MCP
До появления MCP вызов AI-инструментов страдал от двух ключевых проблем:
- Фрагментация интерфейса: Каждая LLM использовала разные форматы инструкций, а каждый API инструмента имел свою уникальную структуру данных. Разработчики были вынуждены писать собственный код подключения для каждой комбинации, что приводило к сложному и неэффективному процессу разработки.
- Неэффективность разработки: Этот подход ‘один к одному’ оказался дорогостоящим и трудным для масштабирования. Это было похоже на наем специального переводчика для каждого иностранного клиента, что затрудняло производительность и гибкость.
MCP решает эти проблемы, предоставляя стандартизированную структуру для взаимодействия LLM с внешними инструментами, упрощая процесс разработки и обеспечивая большую масштабируемость.
Понимание функциональности MCP
Техническую архитектуру MCP можно представить как систему, состоящую из трех основных компонентов: MCP Host, MCP Client и MCP Server. Эти элементы работают синергично, чтобы облегчить беспрепятственную связь между AI-моделями и внешним миром.
Чтобы понять роль MCP, рассмотрим современную корпоративную среду. В этой аналогии:
- Пользователи представляют собой руководителей высшего звена, ответственных за понимание потребностей пользователей и принятие окончательных решений.
- Большие языковые модели (LLM) (такие как Claude или GPT) понимают инструкции руководителей, планируют этапы задач, определяют, когда использовать внешние сервисы, и объединяют информацию для предоставления ответов.
- Системы агентов функционируют как личные помощники или секретари руководителей, выполняющие задачи по указанию.
- MCP действует как стандартизированная платформа связи или система доступа к корпоративным сервисам, используемая секретарями. Она не принимает решений, а следует инструкциям, общаясь с различными поставщиками услуг в унифицированном формате и протоколе.
До MCP взаимодействие AI с внешними инструментами было похоже на эпоху хаотичных стандартов связи. Каждый раз, когда секретарю (агенту) нужно было связаться с другим отделом или внешним поставщиком, он должен был использовать другое устройство связи или программное обеспечение. Это требовало знакомства с различными системами, что приводило к неэффективности. Разработчикам приходилось писать отдельные кодыподключения для каждого инструмента, что приводило к пустой трате времени и ограниченной масштабируемости.
MCP упрощает этот процесс, предоставляя унифицированную платформу связи, позволяющую секретарям связываться с любым отделом или поставщиком услуг, используя одну и ту же систему и протокол связи. Разработчикам нужно всего лишь один раз реализовать интерфейс MCP, что позволяет AI-системам взаимодействовать со всеми инструментами, поддерживающими протокол.
MCP: Набор инструментов, построенный на вызове функций
Важно понимать, что MCP не является заменой традиционному вызову функций (Function Call); скорее, это дополнительный компонент, который расширяет его возможности.
Function Call — это основной механизм, с помощью которого LLM взаимодействуют с внешними инструментами или API. Это фундаментальная возможность LLM, позволяющая им определять, когда требуется инструмент и какой тип инструмента требуется.
MCP действует как система классификации инструментов, предоставляя структурированную структуру для организации и доступа к различным инструментам. Таким образом, MCP не заменяет Function Call, а работает в сочетании с агентами для выполнения сложных задач.
Полный процесс вызова инструментов включает в себя комбинацию ‘Function Call + Agent + MCP System’.
По сути, LLM выражает необходимость вызова конкретного инструмента через Function Call. Агент следует инструкциям для выполнения вызова инструмента, а MCP предоставляет стандартизированную спецификацию вызова инструмента.
Рассмотрим следующую аналогию: босс (пользователь) хочет кофе. В офисе (MCP Host) офис-менеджер (LLM) поручает секретарю (агенту) купить американо (Function Call). Секретарь проверяет список поставщиков и обнаруживает, что поставщик кофе американо интегрирован либо с Meituan, либо с унифицированной системой закупок компании (реализован MCP Server). Затем секретарь находит поставщика в системе закупок (MCP Client) и размещает заказ.
Ранее, без MCP, когда LLM выдавала Function Call, агент переводил и напрямую подключался к API для вызова инструмента. Каждый API требовал отдельного режима вызова и определенного списка инструментов и режима вызова для интерпретации агентом. С MCP многие API можно заказывать напрямую через MCP Client поставщика, что экономит время и усилия агента. Однако Function Call LLM остается неизменным, все еще в формате {tool: ‘buy coffee’, ‘type’: ‘Americano’}.
Различая Function Call и MCP, становится ясно, что MCP не определяет, какой инструмент использовать, и не обрабатывает планирование задач или намерения пользователя. Эти аспекты находятся в компетенции уровня агента. MCP просто предоставляет унифицированный интерфейс инструмента, становясь признанным стандартным протоколом в отрасли.
Проблемы разработки MCP и рыночный ландшафт
Дилемма разработки
С февраля сообщество разработчиков AI стало свидетелем ‘золотой лихорадки MCP’. В отсутствие официального магазина приложений тысячи инструментов добровольно интегрировались с протоколом MCP в течение трех месяцев.
Этот быстрый рост вывел MCP в центр внимания отрасли, но также обнажил разрыв между стремлением и реальностью. Разработчики изначально рассматривали MCP как ‘универсальный ключ’, но обнаружили, что это скорее ‘специализированный гаечный ключ’, преуспевающий в определенных сценариях, но менее эффективный в других.
Участников MCP можно разделить на локальные клиентские приложения, облачные клиентские приложения и разработчиков MCP-серверов. Локальные приложения похожи на локальных AI-помощников, а облачные клиентские приложения напоминают веб-версии ChatGPT. Разработчики MCP-серверов являются фактическими поставщиками инструментов, которым необходимо переупаковать свои API, чтобы соответствовать правилам MCP.
Появление MCP изначально приветствовалось локальными клиентскими приложениями, но облачные клиентские приложения и разработчики MCP-серверов столкнулись с проблемами.
MCP возник из настольного приложения Claude от Anthropic, первоначально разработанного как интерфейсный протокол для вызова локальных файлов и функций, глубоко укорененный в потребностях клиентской стороны.
Для локальных клиентских пользователей MCP представлял собой революцию, предлагая бесконечно расширяемый набор инструментов, который позволял пользователям постоянно расширять возможности своих AI-помощников.
Локальные клиентские приложения, такие как Cursor и Claude Desktop, использовали MCP, чтобы позволить пользователям динамически добавлять инструменты в соответствии с индивидуальными потребностями, обеспечивая неограниченное расширение возможностей AI-помощника.
MCP решает основную проблему в разработке локальных клиентов: как позволить AI-приложениям беспрепятственно взаимодействовать с локальными средами и внешними инструментами, не разрабатывая отдельные интерфейсы для каждого инструмента. Этот унифицированный протокол значительно снижает затраты на интеграцию, предоставляя небольшим стартапам и отдельным разработчикам кратчайший путь к созданию многофункциональных AI-приложений с ограниченными ресурсами.
Однако привлекательность MCP снижается при рассмотрении разработки на стороне сервера (MCP Server) и облачных клиентов. Ранние версии MCP использовали механизм двойной связи для облачных серверов (удаленных), используя длинное SSE-соединение для однонаправленной отправки сообщений с сервера на клиент и короткое HTTP-соединение для отправки сообщений.
Этот подход хорошо работал для своевременной обратной связи с пользователями и вмешательства, но создал ряд инженерных проблем в серверной среде.
Во-первых, реализация интерфейса MCP представляет собой дополнительную рабочую нагрузку для крупных поставщиков корпоративных услуг, не обязательно приносящую соответствующие выгоды. Эти сервисы часто имеют зрелые системы API, и предоставление дополнительного уровня адаптации MCP может только увеличить затраты на обслуживание, не создавая существенной ценности. Многие приложения корпоративного уровня предпочитают закрытые, контролируемые механизмы вызова инструментов открытой экосистеме MCP.
Более того, для обработки вызовов с высокой степенью параллельности сервисы MCP часто необходимо масштабировать до многосерверных архитектур. Модель двойного соединения MCP вносит сложность межмашинной адресации. Когда на одном сервере установлено длинное соединение, а запрос направляется на другой сервер, необходим дополнительный механизм широковещательной очереди для координации этих распределенных соединений, что значительно увеличивает сложность реализации и затраты на обслуживание.
Во-вторых, MCP имеет ограничения в области облачных приложений.Облачные AI-агенты (агенты на стороне сервера) обычно работают в сервисах без сохранения состояния, обрабатывая задачи после принятия и освобождая ресурсы после завершения. Использование MCP Client на стороне сервера требует временного создания SSE-канала, отправки запроса на вызов инструмента, получения результата от SSE и последующего закрытия SSE-канала, что является неэффективным подходом, который увеличивает сложность и снижает производительность. В этом сценарии достаточно одного RPC-запроса.
На практике облачные приложения, использующие MCP, часто полагаются на предустановленные наборы инструментов и не используют возможность подписи MCP — динамическое обнаружение инструментов и гибкую загрузку.
Режим взаимодействия с данными в облачных средах ограничивает возможность свободного использования инструментов, как это задумано в MCP. Он требует строго стандартизированного процесса вызова конкретных, жестко закодированных инструментов, жертвуя гибкостью.
Команда MCP продемонстрировала оперативность в отношении обратной связи с пользователями. После получения обратной связи от разработчиков на стороне сервера MCP обновил свой протокол 26 марта, заменив исходный транспорт SSE потоковым HTTP-транспортом. Новый протокол поддерживает как сценарии сервисов без сохранения состояния, требующие только отдельных запросов на вызов инструмента, так и требования к отправке в режиме реального времени, которые ранее удовлетворялись с помощью двойных каналов HTTP + SSE.
Эти улучшения показывают, что текущие проблемы MCP связаны с первоначальными ограничениями проектирования, но не являются непреодолимыми.
Беспорядок на рынке
Еще одна проблема, стоящая перед MCP, — низкая удобство использования многих реализаций на рынке.
Текущий рынок MCP переживает типичный цикл шумихи вокруг технологий. Подобно хаосу раннего App Store, менее 20% из тысяч инструментов MCP, доступных в настоящее время, имеют практическую ценность. Многие реализации имеют серьезные проблемы, от простых ошибок конфигурации до полной непригодности. Некоторые спешат вывести на рынок без надлежащего тестирования, а другие — это экспериментальные продукты, никогда не предназначенные для практического использования.
Более фундаментальная проблема заключается в том, что многие реализации MCP могут быть не нужны рынку. Многие инструменты, предлагаемые через MCP, — это просто переупакованные API, которые уже были доступны и использовались до появления MCP, добавляя небольшую уникальную ценность.
Например, через MCP предлагаются десятки поисковых сервисов, но их качество значительно варьируется. Некоторые сервисы могут быть неточными или медленными, что делает их менее желательными, чем существующие решения.
Более того, MCP не хватает надежной системы оценки, что затрудняет агентам выбор наиболее подходящего инструмента на основе надежных показателей. Этот неэффективный процесс выбора тратит вычислительные ресурсы, увеличивает время выполнения задач и ухудшает взаимодействие с пользователем.
Отсутствие системы оценки затрудняет агентам выбор наиболее подходящего инструмента. Если несколько сервисов MCP предлагают инструменты с похожими названиями и описаниями, агенту может быть трудно выбрать лучший вариант, что приведет к пустой трате токенов и снижению эффективности.
Наиболее успешные AI-приложения часто используют противоположный подход, предоставляя более точные инструменты, а не большее количество инструментов. Manus, например, решил создавать внутренние приложения вместо внедрения протокола MCP, несмотря на его существование. Manus отдал приоритет точности и стабильности вызовов по сравнению с интеграцией с экосистемой MCP.
Редакторы кода, такие как Cursor, имеют встроенные функции разработки, что делает большинство внешних инструментов MCP избыточными.
Текущее хаотичное состояние рынка MCP не обязательно является признаком неудачи, а скорее необходимым этапом роста для любой развивающейся технологической экосистемы. Исторический прецедент предполагает, что это первоначальное перерасширение постепенно сойдется через механизмы рыночного выбора, оставив позади самые ценные элементы.
Этот процесс позволит отрасли извлечь уроки из текущих проблем и создать более надежную и надежную структуру MCP. Подобно тому, как крах доткомов привел к революционным инновациям в электронной коммерции и социальных сетях, тенденция MCP может привести к более упорядоченной и ценной экосистеме инструментов.
Открытое отношение команды MCP к обратной связи с пользователями обнадеживает, и отрасли нужны более совершенные инструменты для оценки и обеспечения качества сервисов MCP, что поможет сделать экосистему более удобной.
MCP — это хорошо, но не панацея
Проблемы, упомянутые выше, проистекают из ограничений и недостатков MCP, подчеркивая то, чего он может реально достичь. Однако другие критические замечания исходят из нереалистичных ожиданий.
Одна из недавних критических замечаний называет MCP дефектным протоколом, поскольку он не диктует модели взаимодействия между LLM и MCP.
Некоторые ожидают, что MCP автоматически улучшит принятие решений системой AI или повысит эффективность планирования задач. Это ожидание путает инструменты с мастерами.
Проблема проистекает из когнитивного несоответствия — ожидания, что протокол связи будет выполнять задачи интеллектуальной системы. Это все равно, что обвинять USB в том, что он не редактирует фотографии, или осуждать стандарты 5G за то, что они не пишут код. MCP — это прежде всего стандартизированный ‘инструментальный разъем’, обеспечивающий совместимость вилок, а не диктующий, какой прибор использовать или как.
Эффективность вызова инструментов агентом зависит от таких факторов, как знание выбора инструментов, навыки планирования задач и понимание контекста, ни один из которых не входит в компетенцию MCP. MCP гарантирует только стандартизированный интерфейс инструмента, а не то, как эти инструменты будут выбраны и объединены.
Мы часто ищем серебряные пули в технологиях, универсальные решения. Как и аксиома разработки программного обеспечения ‘нет серебряной пули’, использование AI-инструментов не имеет волшебного решения. Сильной AI-системе нужны разработанные компоненты: LLM для понимания и создания, структуры агентов для планирования и выполнения и MCP, ориентированный на унифицированные интерфейсы инструментов.
MCP демонстрирует хороший дизайн протокола — сосредоточение внимания на одной проблеме и ее успешное решение, а не на всех. Его сдержанность помогает ему продвигаться в интеграции инструментов на стороне клиента.
Такие организации, как Qwen от Alibaba, ‘Xinxiang’ от Baidu и Kouzi Space от ByteDance, используют протокол MCP, пытаясь создать более эффективные внутренние экосистемы MCP.
Однако есть ключевые различия в развертывании: Baidu и ByteDance более агрессивны. Baidu пытается применить C-end подход, интегрируя несколько AI-моделей и внешних инструментов через ‘Xinxiang’ (Kokone), используя протокол MCP, в основном для мобильных устройств, чтобы интегрироваться в повседневную жизнь пользователя и стимулировать внедрение.
Kouzi Space от ByteDance имеет более 60 расширений MCP. Доступ к нему осуществляется через веб-страницу, он также запустил AI-нативную IDE, Trae, которая поддерживает MCP, в основном ориентированную на сценарии повышения производительности.
Alibaba интегрировала протокол MCP в такие продукты, как Alipay, обеспечивая вызов AI-инструментов в один клик, и открыла исходный код модели Qwen3, которая поддерживает протокол MCP, расширяя возможности своего агента.
Разработчики Tencent Cloud выпустили пакет разработки AI, поддерживающий сервисы хостинга плагинов MCP. Механизм знаний больших моделей Tencent Cloud позволяет пользователям вызывать плагины MCP. Интеллектуальный агент разработки программного обеспечения Craft, запущенный CodeBuddy от Tencent Cloud, совместим с открытой экосистемой MCP. Кроме того, Tencent Maps и Tencent Cloud Storage выпустили собственные MCP SERVER.
Использование AI-инструментов может развиться от прямой, одноинструментальной операции до профессиональной совместной работы агентов, как стили программирования развились от языка ассемблера к объектной ориентации.
В этой парадигме MCP может просто стать частью базовой инфраструктуры, а не интерфейсом, ориентированным на пользователя или разработчика. Более полный план может потребовать таких архитектур, как Agent to Agents (A2A), для повышения эффективности планирования задач и выбора инструментов за счет повышения уровней абстракции.
Вернув MCP его роль ‘протокола’, мы можем признать его истинную силу в продвижении отраслевой стандартизации — это может быть самым ценным моментом ‘демистификации’ в развитии технологий.