Глава 1 — Кризис интеграций ИИ и подъём агентной архитектуры
Первый пост поглавного разбора LLM Primer IV: Designing AI Cognition with MCP. О том, как доминирующий в 2024 году паттерн — длинный системный промпт, горстка инструментов, единственное окно контекста, от которого требуют делать всё, — отказывает в узнаваемой последовательности, и о том, как этот отказ указывает на протокольный слой, к которому область тихо шла всё это время.
Почему существует эта глава
Примерно два года стандартный рецепт LLM-приложения звучал так: написать длинный системный промпт, прицепить горстку инструментов, назвать это агентом. Рецепт выпускал демо. Он же, предсказуемо, ломался по мере роста поверхности. Промпты переползали за шесть тысяч токенов. Инвентари инструментов перерастали за сорок. Команда патчила, аудировала, регрессионно тестировала и в какой-то момент замечала, что добавление функций стало экспоненциально дороже, чем раньше. Диагноз — не лень и не плохая инженерия. Это архитектура, прогоняющая каждую заботу через один общий ресурс — контекст модели, — и более глубокая комбинаторная проблема, прячущаяся под ней.
Глава проходит режимы отказа в том порядке, в котором команды реально с ними встречаются, называет каждый, а затем формулирует архитектурный выход. Выход — это протокольный слой, позволяющий моделям и инструментам находить друг друга без штучного клея, и дисциплина — context engineering, — относящаяся к взгляду модели как к управляемому бюджету, а не свободному текстовому полю. Обе идеи задают остаток книги.
1.1 Монолитный агент и почему его системный промпт в конце концов ломается
Первое поколение продакшен-приложений на LLM было архитектурно простым по форме. Системный промпт на несколько тысяч токенов описывал роль, инструменты, ограничения, тон и граничные случаи. Это работало на узких поверхностях. По мере того как команда добавляла функции по абзацу за раз, промпт становился самым длинным единичным артефактом в кодовой базе, редактируемым в основном по принципу добавления — потому что удалить что-либо казалось рискованным.
Что этот промпт делал внутри, лучше всего понимается через внимание. Трансформер вычисляет веса внимания по каждому токену в своём контексте, включая каждый токен системного промпта. Промпт в шесть тысяч токенов не пробегается — он усредняется. Чем длиннее промпт, тем больше масса внимания размазывается по инструкциям, нерелевантным текущему шагу. У явления есть названия: размывание контекста, столкновение инструкций, дрейф способностей. Команда видит регрессию и не может локализовать причину, потому что причина — взаимодействие трёх новых правил с пунктом, добавленным два спринта назад.
Связанный отказ возникает на уровне инструментов. С десятью инструментами модель выбирает правильно; с сорока точность выбора падает, иногда резко. Команда патчит, добавляя дизамбигуирующие формулировки, удлиняющие промпт и ещё больше размывающие внимание. Система оказывается в петле обратной связи с самой собой.
1.2 Специализация и кривая поддержки, изгибающаяся не туда
Под проблемой промпта сидит более глубокая. Фронтирные модели общего назначения сильны как универсалы, но универсальная производительность — это среднее по огромной поверхности, и средние прячут обрывы. Юридический ревью контрактов, структурированное медицинское кодирование, финансовая сверка — у каждого внутренний словарь, внутренние правила и допуск к ошибке, под которые общее обучение не оптимизирует. Инстинкт — специализировать через промптинг; цена — больше бюджета внимания при меньшей отдаче. Настоящая специализация хочет собственного компонента с собственным сфокусированным контекстом, которому в монолитном агенте просто негде разместиться.
Поддержка масштабируется так же не туда. У монолитного агента с пятьюдесятью инструментами в четырёх доменах не в десять раз больше нагрузки на поддержку, чем у такого же с пятью инструментами и одним доменом — у него больше, потому что каждая функция взаимодействует с каждой другой через общий промпт. Скорость команды задаётся стоимостью поддержания связности существующей поверхности, а не стоимостью построения новой возможности. Стоимость инференса масштабируется с длиной контекста, поэтому экономическое давление сократить промпт и инженерное давление его нарастить тянут в противоположные стороны.
1.3 Проблема интеграций N на M
Согласитесь с аргументом в пользу декомпозиции. Теперь у вас N модельных компонентов и M интеграций с инструментами. Без общего протокола стоимость интеграции — N на M: каждой модели нужен штучный адаптерный код под каждый инструмент, со всеми причудами каждой модели, перемножаемыми с причудами каждого инструмента. Релиз новой модели означает перетестирование каждого инструмента. Новый инструмент означает написание N адаптеров.
У истории вычислений есть имя для этой формы и имя для решения. До LSP (2016) каждому редактору нужна была интеграция с каждым языком — редактор на язык. LSP ввёл протокол; матрица сжалась до аддитивной стоимости. До USB у каждой категории периферии был свой порт и каждая ОС поставлялась со своими драйверами. После USB — один хост, одно устройство, один общий протокол между ними. Model Context Protocol — тот же ход, применённый к моделям и инструментам. Он не устраняет адаптеры; он их стандартизирует. Первая интеграция медленнее; сотая гораздо быстрее; тысячная по сути бесплатна, потому что инструментарий накопился. Вся игра в накопительной кривой.
Протокол с обнаружением сворачивает и вторую, более тихую матрицу — матрицу описаний. Модели больше не нужно перечисление каждого инструмента в системном промпте на старте; она может спросить у протокола «что доступно прямо сейчас?» и получить структурированный каталог из авторитетного источника — самого сервера.
1.4 От prompt engineering к context engineering
Сдвиг словаря отслеживает архитектурный. В 2022–2023 годах дисциплиной был prompt engineering — поиск формулировок, подталкивающих модель к нужному поведению. К 2025 году промпт был одним входом среди многих. Модель также видит найденные документы, описания инструментов, прежние ходы, результаты инструментов, заметки на черновике, фрагменты памяти. Что именно должно быть в этом контексте на каждом шаге — отвечается уже не формулировкой. Отвечается архитектурой, которая решает за каждый ход, на что модель должна смотреть.
Устоявшийся термин — context engineering. Он относится к окну контекста как к управляемому бюджету. Современные длинноконтекстные модели рекламируют окна в миллион токенов, но производительность деградирует нелинейно с заполнением контекста — феномен, иногда называемый context rot. Модель, получившая контекст в миллион токенов с ответом, погребённым в нём, часто работает хуже той же модели, получившей десять тысяч тщательно отобранных токенов. Важен не размер окна; важна плотность полезного сигнала внутри того, что реально оказалось перед моделью.
MCP отчасти и есть инфраструктура, делающая context engineering возможным. Протокол даёт хосту механизм спрашивать, какие инструменты и какие источники данных доступны, доставать релевантные в нужный момент, согласовывать, какие возможности модель может вызывать. Хост строит контекст динамически, под каждый ход, исходя из того, что текущая задача реально требует.
Что подготавливает глава 1
Диагноз состоит из трёх частей: монолитные агенты отказывают, потому что длинные промпты размывают внимание; специализированная способность не может жить внутри общего промпта; под обоими лежит проблема интеграций N на M. Каждый режим отказа указывает в одном направлении — слой под моделью, опосредующий, как модели и инструменты находят друг друга, описывают друг друга и согласовывают, что они могут делать. Глава 2 вводит этот слой: три роли, которые определяет MCP, небольшой набор концептуальных примитивов и жизненный цикл сессии, открывающийся явным согласованием возможностей.
Дальше — Глава 2: Знакомство с Model Context Protocol. Что такое MCP, что на самом деле означает сокращение «USB-C для ИИ», трёхролевое разделение Host, Client и Server и почему динамическое обнаружение и двунаправленный обмен сообщениями заставляют MCP вести себя иначе, чем REST API, в случаях, где это имеет значение.
