TechCrunch · AI · 11 ч назад
Самый важный протокол ИИ становится немного проще в использовании
В новой системе протокол будет использовать более свободный, «без сохранения состояния» подход к идентификаторам сеансов на стороне сервера, аналогичный тому, как уже работают большинство обычных веб-сайтов.
Подробности
Протокол контекста модели (MCP) является одним из основных строительных блоков совместимости ИИ, предоставляя моделям ИИ безопасный способ доступа к внешним источникам данных и сервисам. Это система, которая позволяет чат-боту получить доступ к вашему календарю, базе данных или вашим внутренним инструментам, вместо того, чтобы инженеры создавали собственные каналы для каждого соединения. На следующей неделе этот протокол получит значительное обновление, и хотя оно может быть незаметно для конечных пользователей, оно может иметь большое значение в развитии экосистемы.
Официальная спецификация новой версии была опубликована с мая, но в понедельник утром мы получили необычайно четкое объяснение изменений от ребят из Arcade — двухлетнего стартапа, который построил весь свой бизнес вокруг работы над тем, чтобы агенты ИИ действительно функционировали внутри реальных компаний, позволяя им безопасно подключаться и действовать с помощью таких инструментов, как Gmail, Slack и Salesforce.
В июне Arcade собрала 60 миллионов долларов, основываясь на идее, что большинство агентов ИИ терпят неудачу не потому, что базовые модели слабы, а потому, что инфраструктура вокруг них еще не готова, и это то, что пытается решить это обновление. По сути, MCP меняет способ обработки идентификаторов сеансов — маленьких токенов, которые серверы используют, чтобы запомнить «ах, это тот же разговор, что и пять секунд назад» — чтобы серверам было легче работать в большем масштабе.
[В текущей системе] Когда клиент MCP, такой как Клод, впервые подключается к серверу, он отправляет «привет»: я Клод, вот моя версия, вот мои возможности. Сервер отвечает своими возможностями и возвращает идентификатор сеанса… С этого момента клиент отправляет этот идентификатор сеанса при каждом запросе, чтобы сервер знал, что это один и тот же разговор. Иногда срок действия идентификатора истекает, поэтому клиенту приходится это заметить, запросить новый и продолжить….
Представьте себе реальное развертывание. У вас есть сервер для миллионов пользователей с балансировщиком нагрузки, вся работа которого заключается в маршрутизации каждого запроса на любой свободный сервер фермы, иногда в другом регионе. Теперь каждая из этих машин должна знать идентификатор сеанса, переданный какой-то другой машиной. Это не невозможно, но это серьезная проблема, и она борется с балансировщиком нагрузки, а не работает с ним.