Почему ИИ-агентам вредно давать слишком много инструментов сразу

Когда у ИИ появляются инструменты, хаос начинается на сервере

За последний год MCP стал одной из самых обсуждаемых идей в мире ИИ-инфраструктуры. Обещание красивое: один стандартный протокол, через который LLM может обращаться к внешним сервисам, читать данные, вызывать функции, управлять приложениями. Не надо под каждую модель заново собирать обвязку. Подключил сервер — и с ним могут работать Claude, GPT, Gemini и другие совместимые клиенты.

Но как только первые команды начали делать такие серверы всерьез, быстро выяснилось: сам протокол — это только начало. Дальше встает неприятный практический вопрос. Как вообще правильно строить MCP-сервер, чтобы он не тормозил, не путал модель и не превращался в свалку из сотни плохо описанных инструментов?

Именно на этот вопрос отвечает статья Архитектурные паттерны MCP-серверов для приложений, интегрированных с LLM. Это не теоретическая работа «про прекрасное будущее», а попытка зафиксировать, как экосистема уже устроена на практике. Авторы посмотрели на реальные MCP-серверы, выделили повторяющиеся архитектурные шаблоны, описали типичные ошибки и добавили немного цифр: про задержки, количество инструментов и надежность своей классификации.

Получился текст, который особенно полезен не исследователям, а инженерам и архитекторам. Потому что он помогает ответить на простой вопрос: если вы строите ИИ-приложение с инструментами, какой сервер вам нужен на самом деле?

Что именно исследовали

Авторы собрали корпус из 15 независимых MCP-серверов. Пять — из промышленной платформы голосового ИИ ANSYR, еще десять — из публичного реестра MCP. Это важно: работа не строится только на одном внутреннем проекте, хотя промышленный опыт здесь заметно влияет на выводы.

Дальше исследователи вручную разбирали код и конфигурации серверов. Они смотрели:

После этого они провели качественное кодирование и свели наблюдения в пять повторяющихся архитектурных паттернов. Плюс отдельно собрали анти-паттерны — решения, которые регулярно ломают работу модели.

Сильная сторона статьи в том, что она смотрит на MCP не как на абстрактный протокол, а как на задачу проектирования интерфейса для клиента, который читает описания на естественном языке. Это и есть главный сдвиг. Обычный разработчик изучит документацию и разберется. LLM выбирает инструмент иначе: по названию, описанию и схеме аргументов. Если это сделано плохо, инструмент как будто не существует.

Пять паттернов, которые уже сложились в MCP

Главный результат статьи — каталог из пяти паттернов. Это не «единственно правильные» архитектуры, а скорее словарь, который помогает думать о проектировании.

1. Шлюз к ресурсам

Первый паттерн — сервер, который аккуратно открывает модели доступ к данным. Например, к базе, документам, CRM или внешнему API.

Идея простая: сервер становится единым входом к данным. Он отдает список ресурсов, чтение по идентификатору, иногда параметризованные запросы. При этом именно сервер решает, что можно показать модели, в каком виде и как защититься от вредного содержимого.

Это очень практичный паттерн. Если модель читает чужие документы, комментарии или записи пользователей, вы быстро сталкиваетесь с внедрением инструкций в текст. Условно: в документе написано «игнорируй предыдущие указания». Для человека это просто текст. Для модели это уже потенциальная команда. Поэтому слой очистки данных здесь не роскошь, а обязательная часть архитектуры.

Такой сервер особенно хорош там, где нужно много чтения и мало действий. Он дает стабильный интерфейс, даже если внутренняя схема базы меняется.

2. Оркестратор инструментов

Второй паттерн нужен, когда одно действие на самом деле состоит из нескольких шагов в разных системах.

Например: создать тикет, назначить исполнителя, отправить уведомление в чат и письмо на почту. Можно дать модели четыре отдельных инструмента и надеяться, что она сама пройдет весь путь. А можно вынести этот сценарий в один составной инструмент.

Авторы считают второй вариант более надежным. Сервер прячет внутреннюю сложность и отдает LLM одну понятную операцию.

И это выглядит очень разумно. Чем меньше модель должна держать в голове, тем выше шанс, что она выберет правильное действие и не застрянет посередине. Но есть и цена: логика процесса уходит на сервер. Значит, именно серверу придется разруливать частичные сбои, повторные попытки и изменение сценариев.

Этот паттерн особенно хорошо работает там, где есть повторяемые бизнес-процессы.

3. Сервер с состоянием сессии

По умолчанию вызовы в MCP статичны: запрос, ответ, и всё. Но в реальных задачах так бывает не всегда. Агент для программирования сначала открывает файл, потом редактирует его, потом сохраняет. Браузерный агент открывает страницу, кликает, проверяет состояние. Голосовой помощник ведет диалог, где важен контекст прошлых шагов.

Здесь и нужен сервер, который хранит состояние сессии.

Он заводит идентификатор сессии, а затем связывает с ним контекст: открытый файл, изменения, транзакцию, авторизацию, промежуточные данные. Это снимает с модели часть нагрузки: ей не нужно каждый раз заново пересказывать весь контекст в запросе.

Но статья честно говорит и о минусах. Состояние надо чистить. Если этого не делать, память утечет. Если серверов несколько, потребуется общее хранилище. А главное — состояние плохо видно снаружи. По одному списку инструментов не всегда понятно, что сервер вообще «помнит» прошлые шаги.

Эта мысль потом всплывает и в оценке паттернов: даже другие модели часто путают такие серверы с обычными оркестраторами.

4. Прокси-агрегатор

Когда инструментов и серверов становится много, появляется соблазн просто собрать их все в одну точку входа. Так и рождается прокси-агрегатор: сервер, который обращается к другим MCP-серверам, собирает их возможности и проксирует вызовы.

На бумаге звучит отлично. Одна настройка для клиента. Централизованная аутентификация. Единое ведение журналов. Общая точка аудита.

Но именно здесь статья делает один из самых полезных практических выводов: просто собрать все инструменты в один список — плохая идея.

Почему? Потому что у модели есть предел, после которого выбор инструмента начинает заметно портиться. Если в контексте слишком много вариантов, LLM ошибается чаще.

Авторы предлагают два варианта агрегатора:

И второй вариант они явно считают правильным для реальных систем.

Чем больше инструментов видно модели одновременно, тем сильнее падает точность выбора и растет задержка.

Это один из самых сильных моментов статьи. Она не просто говорит «не делайте слишком много инструментов», а подкрепляет это данными из промышленной эксплуатации.

5. Предметно-ориентированный адаптер

Последний паттерн — обертка над неудобным API. Многие корпоративные системы плохо подходят для LLM: там непонятные идентификаторы, сложные поля, неудобные ошибки, странные форматы дат и громоздкие ответы.

Тогда MCP-сервер становится переводчиком между моделью и предметной областью. Он принимает более «человеческие» аргументы, нормализует ввод, переводит ошибки в понятный текст, подменяет идентификаторы читаемыми именами и добавляет описание, которое помогает модели выбрать нужный инструмент.

По сути, это слой семантики. Он не должен переписывать бизнес-логику системы, но должен сделать ее пригодной для использования ИИ.

Для корпоративных интеграций это, вероятно, один из самых жизнеспособных паттернов.

Четыре ошибки, которые ломают всё

Кроме паттернов авторы описывают анти-паттерны. И здесь работа особенно полезна, потому что ошибки очень узнаваемые.

Первая — «бог-инструмент». Это когда вместо набора ясных операций делают одну универсальную функцию вида «сделай что угодно». Для модели это катастрофа: слишком расплывчатая задача, слабая схема аргументов, высокий шанс выбрать не то.

Вторая — неочищенный контент в ресурсах. Если вы отдаете модели пользовательский текст как есть, вы открываете дверь для внедрения инструкций.

Третья — долгие синхронные операции. Если инструмент обрабатывает видео или огромный файл и отвечает слишком долго, клиент может просто дождаться тайм-аута. Лучше возвращать идентификатор задачи и отдельный инструмент для проверки статуса.

Четвертая — плохие описания инструментов. И это, пожалуй, самая недооцененная проблема. Название и описание для LLM — это часть интерфейса, а не декоративный комментарий. Если описание туманное, модель не поймет, когда этим пользоваться.

Что показали измерения

У статьи есть три количественных результата. Они не революционные, но очень полезные.

Во-первых, авторы проверили, можно ли их классификацию паттернов применять более-менее надежно. Для этого две модели независимо размечали 54 других сервера по текстовым описаниям. Согласованность оказалась приличной: коэффициент Коэна 0,76. Это значит, что каталог не совсем произвол.

Но есть интересная оговорка. Границы между паттернами часто размыты. Особенно там, где снаружи плохо видно состояние или предметную логику. И это хороший урок сам по себе: архитектура MCP не всегда считывается по списку возможностей.

Во-вторых, авторы измерили задержки транспорта.

Задержки разных вариантов транспорта MCP: локально протокол почти ничего не стоит, а удаленные вызовы упираются в сеть.

Вывод простой и очень земной: главная задержка — не в протоколе, а в сети. Локально всё очень быстро. Разница между stdio и потоковым HTTP почти не важна, если вы всё равно обращаетесь к другим машинам. Куда важнее, расположен ли сервер рядом с клиентом и добавляете ли вы лишний сетевой прыжок через агрегатор.

Это ценный контраст с бесконечными спорами об «идеальном транспорте». В большинстве практических систем узкое место будет совсем не там.

В-третьих, авторы посмотрели на связь между числом инструментов и точностью выбора.

Для Claude Haiku 4.5 точность падает ниже 90% где-то между 10 и 15 инструментами в контексте. Для Claude Sonnet 4 — между 20 и 30. При этом рост числа инструментов бьет и по задержке.

Это очень прикладной результат. Он означает, что проектирование MCP-сервера — это не просто вопрос красоты API. Количество инструментов становится ограничением качества.

Именно поэтому идея «давайте просто вывалим модели всё, что у нас есть» оказывается вредной.

Почему эта статья важна

Ценность работы не в том, что она открывает новый алгоритм. Ее сила в другом: она переводит хаотичную инженерную практику в понятный набор решений.

Сегодня многие команды строят ИИ-системы методом проб и ошибок. Сначала подключают пару функций. Потом еще десяток. Потом добавляют доступ к данным. Потом появляется второй сервер, третий, маршрутизация, ведение журналов, аутентификация. И только после нескольких болезненных итераций приходит понимание, что тут уже есть архитектура — просто пока без названий.

Эта статья как раз дает названия и рамку. А значит, помогает раньше принимать хорошие решения.

Еще важнее то, что авторы постоянно держат в голове специфику LLM-клиента. Они не просто переносят старые шаблоны интеграции в новый мир, а показывают, где меняются правила. Например:

Итог

Если коротко, то статья говорит простую вещь: MCP — это не только протокол, но и новая дисциплина проектирования интерфейсов для ИИ.

Авторы выделяют пять базовых архитектурных паттернов: шлюз к ресурсам, оркестратор инструментов, сервер с состоянием сессии, прокси-агрегатор и предметно-ориентированный адаптер. Показывают типичные ошибки. И добавляют две очень практичные мысли: не спорьте слишком много о транспорте, лучше думайте о сетевой топологии; не показывайте модели слишком много инструментов одновременно.

Для инженерных команд это, пожалуй, главный вывод. Хороший MCP-сервер — это не тот, который умеет «всё». Это тот, который показывает модели ровно то, что ей нужно, в понятной форме и в правильный момент.

И если MCP действительно станет для ИИ тем же, чем когда-то LSP стал для редакторов кода, такие работы будут особенно важны. Не потому, что они дают окончательные ответы. А потому, что они помогают экосистеме перестать строить инфраструктуру на ощупь.