Systems Design Meditation · Edition 2
После API
Почему MCP сигнализирует о новом инфраструктурном слое
Edward Calderón
Архитектор ПО
API связали программное обеспечение. Агенты вводят ПО, которое должно само решать, к какому ПО подключаться.
Традиционная интеграция начинается со знания: разработчик выбирает endpoint, изучает его схему и пишет вокруг него детерминированный код. Вызывающая сторона знает сервис и обычно знает операцию. Агентное ПО меняет это допущение. Ему может потребоваться обнаруживать возможности, понимать их описания, выбирать среди них и переносить контекст через границу.
От вызова к обнаружению
REST, RPC и потоки событий остаются необходимыми. MCP не делает их устаревшими. Он работает на другом уровне: представляет инструменты, ресурсы и промпты клиентам, управляемым моделями, через общий интерфейс. Базовой операцией по-прежнему может быть вызов API, запрос к базе данных или локальный процесс.
Это различие важно. Обнаружение — это не просто более удобный SDK. Машине, выбирающей возможность, нужны имена и описания, поддерживающие корректные рассуждения, схемы, ограничивающие входные данные, и явные границы безопасности. Неоднозначное описание инструмента — это архитектурный дефект, потому что оно меняет поведение выбора.
Спецификация MCP определяет архитектуру «клиент — хост — сервер» и согласование возможностей. Она также предупреждает разработчиков о необходимости сохранять согласие, конфиденциальность данных и безопасность инструментов. Это подсказки о новом слое: обмен контекстом нельзя отделить от полномочий.
Меня интересует не то, станет ли MCP окончательным протоколом. А то, что взаимодействие агентов с системами стало настолько важным, что потребовало протокольного слоя вообще. Протокол может измениться. Потребность останется.
Управляющий слой вокруг инструментов
Полезной экосистеме агентских инструментов нужно больше, чем каталог. Нужны жизненный цикл и управление. Кто зарегистрировал инструмент? Какая версия активна? Какой tenant может его видеть? Означает ли обнаружение разрешение или лишь осведомлённость? Как результаты помечаются как недоверенные? Что происходит, когда сервер исчезает посреди рабочего процесса?
Это вопросы распределённых систем. Сервисы отказывают независимо. Схемы эволюционируют. Повторные попытки могут дублировать побочные эффекты. Агент может держать устаревший контекст. Вызов инструмента, который выглядит атомарным для модели, может охватывать несколько неатомарных операций под ним.
Представьте операционного агента, выбирающего между инструментами для чтения телеметрии, создания инцидента и изменения мощности. Обнаружение должно раскрывать все три возможности, но авторизация не должна быть одинаковой. Чтение может быть широким. Создание инцидента должно быть идемпотентным. Изменения мощности должны требовать более строгой политики и включать ограниченный диапазон. Общий протокол помогает описать интерфейс; платформа по-прежнему должна обеспечивать соблюдение границы.
Границы между вендорами делают это ещё важнее. Организации будут использовать нескольких поставщиков моделей и сотни внутренних и внешних сервисов. Самописные адаптеры создают связанность в обоих направлениях. Протокольный слой может позволить инструменту развиваться, не заставляя каждый клиент изучать его частную интеграцию, и позволить клиенту меняться без переписывания каждого сервиса.
Стандартизация без мифологии
Важные экосистемы часто ускоряются, когда интерфейсы становятся предсказуемыми. Но аналогии могут скрывать больше, чем объясняют. MCP — это не просто «новый HTTP». HTTP переносит представления между сетевыми компонентами. MCP определяет соглашения для контекста и возможностей, ориентированных на модели, обычно используя существующие транспорты под собой.
Полезное архитектурное утверждение уже. Стандартные интерфейсы сокращают число двусторонних соглашений, необходимых для взаимодействия компонентов. Они создают пространство для инструментария: реестров, шлюзов, движков политик, тестовых сред и наблюдаемости. Они также делают сбои сопоставимыми.
Стандартизация не создаёт совместимость автоматически. Два сервера могут реализовать один и тот же протокол, используя несовместимую семантику. Инструмент с именем `search` может искать в документах клиента, в открытом вебе или в операционной базе данных. Семантическое качество, происхождение данных и доверие остаются системными вопросами.
Это подсказывает многослойный дизайн. Используйте протоколы для обнаружения и обмена. Используйте идентичность и политики для авторизации. Используйте доменные контракты для смысла. Используйте трассировку и аудит для подотчётности. Используйте обычные API и очереди для надёжного выполнения. Ни один слой не должен притворяться, что решает задачи остальных.
Для разработчиков непосредственная ценность MCP — не обещание универсальности. Это практическое давление в сторону разделения клиентов моделей и реализаций инструментов. Это делает эксперименты дешевле, а замену — более обратимой.
Протоколы важны, потому что позволяют системам развиваться независимо.