Понятное объяснение того, как ИИ-агенты переходят от ответов на вопросы к выпуску работающих приложений: что на самом деле делает Model Context Protocol, как токены с ограниченной областью действия держат агентов под контролем, какой именно цикл агент проходит, чтобы создать, проверить и опубликовать приложение, и чем agent-native платформы отличаются от наспех адаптированных.
Основатели, разработчики и операционные специалисты, которые хотят понять или использовать агентов, способных строить и поддерживать настоящий софт, а не только вести беседу.
- Простая ментальная модель MCP и причина, по которой его приняли все крупные ИИ-лаборатории
- Честная картина модели безопасности: что токен с ограниченной областью действия разрешает, а что нет
- Цикл из шести шагов, который агент проходит от брифа до опубликованного приложения
ИИ-агент, который отвечает на вопросы, полезен. Агент, который собирает работающее приложение, подключает его к базе данных и публикует на настоящем домене, относится к совершенно другому классу инструментов. Мостом между ними служит небольшой и намеренно скучный стандарт под названием MCP плюс модель разрешений, которая делает всю конструкцию достаточно безопасной для реального использования. Вот как это устроено на самом деле, без модных слов.
MCP, то есть Model Context Protocol, представляет собой открытый стандарт, который позволяет ИИ-агенту пользоваться внешними инструментами. Сервис публикует меню действий, которые он умеет выполнять: создать приложение, отредактировать файл, запустить проверку. Любой агент с поддержкой MCP может прочитать это меню и вызывать эти действия. Его часто называют USB-C для ИИ: один разъем, который работает с любыми моделями и сервисами, вместо отдельного кабеля для каждой пары.
Языковая модель сама по себе умеет только порождать текст. У нее нет рук: она не может обратиться к базе данных, вызвать API или опубликовать сайт. Anthropic выпустила MCP как открытый стандарт в конце 2024 года именно для того, чтобы дать ей руки стандартным способом, и распространение оказалось необычайно быстрым. За два года его поддержали все крупные ИИ-лаборатории, публичный реестр перевалил за несколько тысяч серверов, а SDK скачивали десятки миллионов раз в месяц.
Причина такого распространения экономическая, а не техническая. До общего протокола подключение N моделей к M сервисам означало создание и поддержку N умножить на M кастомных интеграций. С единым стандартом сервис выпускает один MCP-сервер и сразу работает с каждым способным агентом, а агент получает доступ ко всем сервисам в тот день, когда начинает говорить на этом протоколе. Та же математика когда-то двигала USB, и закончилось все так же: разъем победил.
Первая здравая реакция на машину, которая умеет создавать и публиковать программы, вполне понятна: настороженность. И честный ответ таков: безопасность целиком зависит от модели разрешений. Механизм, который делает все это управляемым, называется токеном с ограниченной областью действия, и его стоит понять точно, потому что именно он отделяет делегирование от безрассудства.
Подключая агента к платформе, вы не отдаете ему свой аккаунт. Вы создаете токен, ключ с конкретными и ограниченными разрешениями, и агент действует строго внутри этой ограды. Все, что он делает, привязано к этому токену, а границы ограды рисуете вы.
Основатель хочет, чтобы агент починил форму регистрации в его приложении для бронирования. Он выпускает токен, привязанный к этому единственному приложению, с правами на редактирование и проверку, но без публикации. Агент вносит правку и запускает валидацию; основатель просматривает дифф, публикует изменение сам и отзывает токен. Итоговая площадь риска: одно приложение, два разрешения, двадцать минут. Так выглядит делегирование с оградой.
Агент, который строит настоящий софт, не выдает все целиком одной героической генерацией. Он крутит цикл, очень похожий на то, как работает аккуратный инженер, только сжатый с дней до минут.
Модель всегда может выдать код, который выглядит правильным. Доверие к софту, собранному агентом, создает проверка после каждого изменения: настоящий шлагбаум, который говорит либо что все работает, либо что именно сломалось. Без него агенты уверенно уплывают в сломанные состояния. С ним ошибки ловятся внутри цикла, ровно так же, как хорошие инженеры-люди не выпускают их в продакшен.
Немало продуктов прикрутили MCP-сервер к интерфейсу, спроектированному для людей, кликающих по кнопкам. Технически это работает, но это не то же самое, что платформа, построенная для агентов. Их разделяют три признака.
Быстрее всего работает тест на симметрию: на agent-native платформе агент с корректно ограниченным токеном может делать по сути все, что человек делает через интерфейс: создать приложение, менять его файлы, проверять, версионировать, публиковать. Если агенту оставлена узкая боковая дверь с половиной возможностей, платформа относится к автоматизации как к демо-функции, и этот потолок вы почувствуете уже в первый месяц реальной работы.
Когда превращение описанной потребности в работающий софт перестает требовать человека, кликающего по конструктору, экономика малого софта меняется. Операционная команда может получить внутренний инструмент в тот же день, когда сумела его описать, а не через квартал после победы в борьбе за приоритеты. Основатель может вечером отдать агенту черновой бриф и утром просмотреть работающую первую версию. Бизнес может позволить себе софт, скроенный точно под один рабочий процесс, потому что такая подгонка больше не стоит дороже самого процесса.
Ничто из этого не отменяет человеческое суждение. Кто-то по-прежнему решает, что стоит строить, просматривает результат и отвечает за него. Меняется цена расстояния между ясным описанием и работающим продуктом. Раньше это расстояние измерялось неделями и счетами. Теперь оно измеряется минутами и одним ревью, и бизнесы, которые усвоят это раньше других, просто будут иметь больше софта, лучше подогнанного под их работу, чем те, кто продолжит ждать.
Model Context Protocol представляет собой открытый стандарт, который позволяет ИИ-агентам находить и вызывать инструменты сервиса: создать приложение, отредактировать файл, запустить проверку. Благодаря этому любой способный агент может работать с любым сервисом, опубликовавшим MCP-сервер.
Да, если платформа дает ему настоящие инструменты со шлюзом валидации: агент создает проект, выстраивает модель данных и страницы, проверяет после каждого изменения, исправляет то, что поймала проверка, и публикует. Надежность обеспечивает цикл с верификацией, а не одна гигантская генерация.
Токен с ограниченной областью действия, под которым он работает. Вы ограничиваете его конкретными приложениями и конкретными действиями, каждый вызов записывается, и вы можете отозвать токен мгновенно. Агент с токеном на редактирование и проверку одного приложения не сможет удалить другие проекты или опубликовать что-то без вас.
Примените тест на симметрию: может ли агент с корректно ограниченным токеном делать по сути все, что делает человек, то есть создавать, редактировать, проверять, версионировать и публиковать? Если агенту доступно лишь узкое подмножество человеческого интерфейса, автоматизацию добавили по остаточному принципу, и в этот потолок вы упретесь быстро.