Gdy agent AI ma 1000 narzędzi MCP: wybór, kontekst i umiejętności

MCP ułatwia dostęp do narzędzi

Jedną z głównych zalet Model Context Protocol jest to, że funkcje są dostępne dla agentów przez jeden wspólny interfejs. Produkt typu SaaS może publikować metody create_customer, get_customer, update_customer, create_invoice, refund_payment oraz search_orders. Inny serwer MCP może obsługiwać GitHub, trzeci Slack, a czwarty wewnętrzną bazę danych. Każdy z nich funkcjonuje dobrze samodzielnie. Problemy pojawiają się, gdy jeden agent łączy się z wieloma serwerami, a ich liczba szybko rośnie. Dziesięć narzędzi to nic, sto już stanowi problem, a tysiąc to zupełnie inna kategoria wyzwań.

Eksplodacja narzędzi

Postaw się w sytuacji agenta, który ma do dyspozycji 1000 narzędzi. Musiałbyś ustalić, co każde z nich robi, które są ze sobą powiązane, które należy użyć, jakie parametry przyjmuje każde, które powinny zostać uruchomione pierwsze oraz czy kilka narzędzi pełni takie same zadanie. Technicznie agent może dotrzeć do wszystkiego, ale dostęp nie równa się użyteczności. Więcej narzędzi oznacza większe możliwości oraz więcej opcji, a większa liczba opcji może utrudnić wybór.

Uzupełnianie kontekstu

Każde narzędzie wymaga opisu. W przypadku jednego narzędzia może to być nazwa:

create_invoice

i krótka definicja:

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

Umnoż się to przez 1000. Nawet krótkie opisy składają się na dużą ilość kontekstu, więc tokeny są wydawane już na samo poinformowanie modelu o tym, co może zrobić, a większość tych narzędzi nie ma nic wspólnego z aktualnym zadaniem. Jeśli użytkownik pyta o stan zamówienia, nie ma powodu, aby agent musiał przetwarzać 500 narzędzi do fakturowania, GitHuba, CRM i wdrażania.

Prawdziwym wyzwaniem jest wybór odpowiedniego narzędzia

Załóżmy, że agent widzi te:

get_customer
get_customer_details
lookup_customer
search_customer
find_customer

Wszystkie brzmią podobnie. Które powinno zostać wybrane? A teraz rozszerzmy to na setki narzędzi. Model może doskonale wybierać narzędzia. Trudno jest natomiast wybrać jedno z ogromnej bazy narzędzi. To jak rzucenie 10 000 funkcji programiście i życzenie mu powodzenia – możliwe, ale nieprzyjemne.

Więcej narzędzi, więcej błędów

Wybór często nie jest binarny, ponieważ kilka narzędzi może zadziałać:

search_orders
get_order
list_orders
find_order_by_customer

Agent może wybrać ważny narzędzie i używać go nieskutecznie, wywołać kilka narzędzi tam, gdzie wystarczyłoby jedno, lub wywołać je w niewłaściwej kolejności. Cały proces obejmuje dostępność narzędzi, ich wybór, uporządkowanie oraz wykonanie. MCP przede wszystkim pomaga w pierwszym etapie. Reszta zależy od agenta oraz architektury, która go otacza.

Czy agenci powinni mieć mniej narzędzi?

Niekoniecznie. Celem nie jest ograniczenie możliwości agenta, lecz uniknięcie zmuszania go do rozumienia wszystkiego jednocześnie. Osoba naprawiająca problem z płatnościami nie otwiera każdego narzędzia wewnętrznego i nie czyta dokumentacji – wybiera tylko te związane z płatnościami. Agenci mogliby postępować w ten sam sposób. Model ładowania wszystkiego, a następnie wyboru mógłby zostać zastąpiony procesem odkrywania, wybierania, ładowania i wykonywania, co stanowi ciekawszy projekt.

Gdzie pasują umiejętności

Umiejętności są ze sobą bezpośrednio powiązane. Jedna umiejętność może dostarczyć kontekstu dla określonego rodzaju zadania. Na przykład umiejętność obsługi rachunków klientów może poinstruować pracownika, aby znalazł klienta, sprawdził subskrypcję, przejrzał niespłacone faktury, podjął decyzję co do właściwego działania związанego z fakturowaniem, poprosił o zatwierdzenie w razie potrzeby, a następnie użył odpowiedniego narzędzia.

Pracownik nie musi już rozważać każdego narzędzia w systemie – otrzymuje mniejszy, bardziej istotny zestaw narzędzi do wykonywania zadania. Zamiast tego:

Agent
 ↓
1,000 tools

Przepływ mógłby wyglądać w ten sposób:

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

Umiejętności nie zastępują MCP, ponieważ rozwiązują różne problemy. MCP łączy agenta z możliwościami, a umiejętności mogą nauczyć go, jak je wykorzystywać. Koncepcja umiejętności zamiast MCP jest nadal eksperymentalna i w fazie rozwoju, więc lepiej traktować ją jako kierunek rozwoju niż ustaloną architekturę.

Gateways również mogą być ważne

Kolejnym kierunkiem jest gateway MCP. Zamiast łączyć agenta bezpośrednio z dziesiątkami serwerów MCP, gateway znajduje się pomiędzy nimi:

Agent
 ↓
MCP Gateway
 ↓
MCP Servers
 ↓
APIs / Systems

Brama mogłaby pełnić funkcje autoryzacji, routingu, kontroli dostępu, umożliwiać monitorowanie, odkrywanie narzędzi oraz zarządzanie wieloma serwerami. Staje się to tym cenniejsze, im większe są implementacje MCP.

Prawdziwym problemem jest bezużyteczność

Problemem nie jest sama liczba 1000 narzędzi, lecz 1000 narzędzi bezużytecznych. Jeśli do wykonania zadania faktycznie potrzeba tysiąca narzędzi, niech tak będzie. Jeśli potrzeba ich tylko dwunastu, a agent musi przetworzyć tysiąc, by je znaleźć, to jest to niepotrzebna złożoność. Zasada jest taka: agenci nie muszą mieć dostępu do wszystkiego, tylko do tego, co jest aktualnie ważne.

To prawdopodobnie stanie się kluczowym problemem w architekturze MCP w miarę jak agenci łączą się z coraz większą liczbą systemów. MCP rozwiązało pierwsze pytanie – jak zapewnić agentom standaryzowany dostęp do narzędzi. Kolejnym pytaniem jest to, jak inteligentnie zarządzać wszystkimi tymi narzędziami, a to wydaje się znacznie trudniejsze. Zapewnienie agentom narzędzi stało się proste. Kluczowym wyzwaniem jest dostarczenie im odpowiednich narzędzi we właściwym czasie.