Когда у ИИ-агента 1 000 инструментов MCP: выбор, контекст и навыки

Дополнительные инструменты для ИИ-агента кажутся чистым преимуществом, пока их количество не достигнет 1 000. В этот момент вопрос меняется: он уже не звучит как «сможет ли агент это сделать?», а становится «сможет ли агент найти подходящий инструмент и использовать его правильно?» Именно здесь MCP становится интересным.

MCP упрощает использование инструментов

Одним из значительных преимуществ протокола Model Context Protocol является то, что возможности передаются агентам через один общий интерфейс. Продукт типа SaaS может предоставлять методы create_customer, get_customer, update_customer, create_invoice, refund_payment и search_orders. Другой сервер MCP может обрабатывать данные из GitHub, третий — из Slack, а четвертый — из внутренней базы данных. Каждый из них работает нормально по отдельности. Проблемы начинаются, когда один агент подключается к множеству серверов, и их общее количество быстро растет. Десять инструментов — это ещё ничего, сто — уже начинают создавать трудности, а тысяча — это совсем другая проблема.

Взрыв количества инструментов

Поставьте себя на место агента, у которого в распоряжении 1 000 инструментов. Вам придётся выяснить, что делает каждый из них, какие связаны между собой, какие использовать, какие параметры они принимают, какие должны запускаться первыми и выполняют ли несколько инструментов одну и ту же функцию. Технически агент может добраться до всего, но доступ — это не удобство использования. Чем больше инструментов, тем больше возможностей и выбора, а больший выбор может затруднить принятие решения.

Полное описание контекста

Каждому инструменту нужно описание. Для одного инструмента это может быть просто название:

create_invoice

и краткое определение:

Creates an invoice for a customer.Parameters:
- customer_id
- amount
- currency
- due_date

Умножьте это на 1 000. Даже небольшие описания в сумме дают большой объем контекста, поэтому токены тратятся просто на то, чтобы сообщить модели, что она может делать, причем большинство этих инструментов не имеют никакого отношения к текущей задаче. Если пользователь спрашивает о статусе заказа, у агента нет причин изучать 500 инструментов для ведения учета, GitHub, CRM и развертывания.

Правильный выбор инструмента — вот настоящая сложность

Предположим, агент видит следующее:

get_customer
get_customer_details
lookup_customer
search_customer
find_customer

Все они звучат одинаково. Какой из них следует выбрать? А теперь представьте, что это касается сотен инструментов. Модель может отлично вызывать инструменты, но сложно выбрать один из огромного набора. Это как бросить разработчику 10 000 функций и пожелать ему удачи — возможно, но не очень приятно.

Чем больше инструментов, тем больше ошибок

Выбор часто не бывает дихотомичным, поскольку могут подойти несколько инструментов:

search_orders
get_order
list_orders
find_order_by_customer

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

Следует ли давать агентам меньше инструментов?

Не обязательно. Цель не в том, чтобы ограничить возможности агента, а в том, чтобы не заставлять его понимать всё сразу. Человек, решающий проблему с оплатой, не открывает каждый внутренний инструмент и не читает документацию — он использует только те инструменты, которые связаны с оплатой. Агенты могут действовать аналогичным образом. Модель загрузки всего сначала, а затем выбора может быть заменена на модель поиска, выбора, загрузки и выполнения, что является более интересным подходом к проектированию.

Роль навыков

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

Оператор больше не должен размышлять над каждым инструментом в системе — ему предоставляется более узкий и релевантный набор инструментов для выполнения задачи. Вместо этого:

Agent
 ↓
1,000 tools

Поток может выглядеть так:

Agent
 ↓
Relevant Skill
 ↓
Relevant tools
 ↓
MCP
 ↓
API / System

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

Воркеры также могут быть важны

Ещё одним направлением являются воркеры MCP. Вместо прямой связи агента с десятками серверов MCP между ними стоит воркер:

Agent
 ↓
MCP Gateway
 ↓
MCP Servers
 ↓
APIs / Systems

Шлюз может выполнять функции аутентификации, маршрутизации, контроля доступа, обеспечения видимости, поиска инструментов и управления множеством серверов. Его ценность растёт по мере увеличения масштабов внедрения MCP.

Настоящая проблема — бесполезность

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

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