128 narzędzi AI w 3500 tokenów: jak ToolRouter zmienia grę w agentach

Klasyczny agent z setką narzędzi zjada 287 000 tokenów samych schematów — zanim model przeczyta pierwsze pytanie użytkownika. ToolRouter zmienia to na 3500 tokenów, pobierając schematy tylko gdy są potrzebne. Oto jak działa i kiedy wdrożyć w swoim systemie.

128 narzędzi, 3500 tokenów: problem, który ma rozwiązanie

Wyobraź sobie agenta, który zarządza 128 narzędziami AI — od API do transkrypcji, przez generatory obrazów, po narzędzia do analizy danych. Każde narzędzie ma schemat JSON: opis, parametry, typy danych, przykłady. Statyczne podejście — ładowanie wszystkich schematów do każdego promptu — to standard w LangChain. Wynik: 287 000 tokenów na sam opis narzędzi [1].

To nie jest marginalny problem. Przy oknie kontekstu 1M tokenów (nominalne) masz już 28% okna zajęte przed tym, zanim agent zacznie myśleć. W praktyce — bo do tego dojdziemy — to oznacza, że rzeczywista pojemność na historię rozmowy, kontekst biznesowy i wyniki to zaledwie kilkadziesiąt tysięcy tokenów.

ToolRouter to inny wzorzec. Zamiast ładować wszystkie 128 schematów, agent pobiera dynamicznie — tylko te, które są mu potrzebne do rozwiązania bieżącego zadania. Rezultat: 3500 tokenów zamiast 287 000. To redukcja 82 razy [1].

Różnica między statycznym a dynamicznym routingiem tkwi w architekturze. Statyczne podejście to: "Oto wszystko, co możesz zrobić." Dynamiczne to: "Czego potrzebujesz? Zaraz ci to przygotowuję." Wzorzec pochodzi z wewnętrznych mechanizmów Claude Code — Anthropic używa podobnej logiki, aby zarządzać setkami możliwych operacji bez wysadzania okna kontekstu [1].

Dlaczego 1M tokenów to wciąż za mało dla setki narzędzi

Nominalne okno kontekstu to liczba, którą widać w dokumentacji. Praktyczna pojemność to coś innego. Dla Claude'a (Fable 5 / Opus 4.8 / Sonnet 4.6) nominalne 1M tokenów przekłada się na praktyczną pojemność około 200 000 tokenów [2]. Dla GPT-5.5 i Gemini 3.1 Pro: nominalne 1M, praktycznie około 700 000 tokenów [2].

Czemu ta różnica? Ponad pewnym progiem — zwykle 60–70% nominalnego okna — jakość odpowiedzi degeneruje się. Model zaczyna gubić informacje, mieszać kontekst, generować błędy. To nie jest nagły upadek, ale stopniowy spadek precyzji [2].

Dodaj do tego problem "lost in the middle" — zjawisko, w którym modele gorzej przetwarzają informacje umieszczone w środku długiego kontekstu [3]. Jeśli umieścisz 128 schematów narzędzi na początku promptu, a pytanie użytkownika na końcu, model może nie w pełni integrować informacji z obu końców. Wynik: agent wybiera złe narzędzie, bo "zapomniał" co może zrobić.

Praktycznie: jeśli masz 200 000 tokenów praktycznej pojemności, a 287 000 zużywasz na schematy, jesteś już w minusie. Historia rozmowy, kontekst biznesowy, wyniki poprzednich kroków — wszystko to musi się zmieścić w ujemnej przestrzeni. To jest architekturalne źle.

Jak działa dynamiczny routing narzędzi — mechanika ToolRouter

ToolRouter opiera się na trzech filarach: leniwym ładowaniu, semantycznym routingu i cache'owaniu schematów.

Lazy loading schematów to pierwszy krok. Zamiast ładować wszystkie 128 schematów do każdego promptu, agent przechowuje je poza kontekstem — w bazie danych, API, lub cache'u. Gdy agent musi wybrać narzędzie, najpierw określa, które narzędzia mogą być przydatne (na podstawie opisu, tagu, lub embedingu), a następnie pobiera tylko ich schematy. Reszta zostaje na dysku.

Routing semantyczny to druga warstwa. Zamiast przeszukiwać 128 narzędzi sekwencyjnie, agent używa embedingów — reprezentacji tekstowych narzędzi w przestrzeni wektorowej. Pytanie użytkownika jest również konwertowane na embedding. Następnie agent znajduje narzędzia, których embedingi są najbliższe pytaniu. Zamiast 128 schematów, pobiera 5–10 [7].

Cache'owanie to trzecia warstwa. Schematy, które agent niedawno używał, pozostają w pamięci. Jeśli użytkownik zadaje kolejne pytanie, które wymaga tego samego narzędzia, schemat jest już dostępny — bez dodatkowego pobierania.

Wzorzec pochodzi z Claude Code — wewnętrznego systemu Anthropic do zarządzania setkami operacji [1]. Claude Code nie ładuje wszystkich możliwych operacji do każdego promptu. Zamiast tego, na podstawie kodu, który pisze, dynamicznie ładuje API, biblioteki i narzędzia, które są potrzebne. Rezultat: model może pracować z ogromnym zestawem możliwości bez wysadzania okna kontekstu.

Kiedy ToolRouter ma sens — i kiedy to overkill

ToolRouter nie jest dla każdego. Wdrażanie routingu dynamicznego dodaje złożoność: musisz zarządzać bazą schematów, implementować embedding, debugować routing. Kiedy to się opłaca?

Próg rentowności to około 50 narzędzi. Poniżej tego, statyczne ładowanie jest proste i wystarczające. Powyżej — zaczyna się boleć. Średni projekt używa 15–30 narzędzi AI, więc dla większości firm ToolRouter to przyszłość, nie teraźniejszość [7].

Ale jeśli masz 50+ narzędzi, albo planujesz mieć, kalkulacja zmienia się. Semantyczny routing może zmniejszyć czas wyboru narzędzia z 500 ms do 50 ms [7]. To nie jest marginalny przyspeszenie — to różnica między agentem, który czuje się responsywny, a agentem, który się zawieszył.

Alternatywy do ToolRouter:

Hierarchiczne grupy narzędzi — podzielić 128 narzędzi na 8 grup (np. "narzędzia do tekstu", "narzędzia do obrazów"), a agent najpierw wybiera grupę, potem narzędzie. Prostsze niż ToolRouter, ale mniej elastyczne. Jeśli narzędzie pasuje do kilku grup, routing się myli.

Semantic search — użyć wektora pytania użytkownika do znalezienia narzędzi, bez dynamicznego pobierania schematów. Szybsze niż ToolRouter, ale wymaga embedingów — dodatkowy koszt obliczeniowy i infrastruktury.

ToolRouter — pełna automatyzacja. Droższe do wdrożenia, ale najbardziej elastyczne dla dużych systemów.

Wybór zależy od skali. 30 narzędzi? Grupy hierarchiczne. 80 narzędzi? Semantic search. 150+ narzędzi? ToolRouter.

Wdrażanie ToolRouter w LangChain — co trzeba zmienić

Jeśli już masz agenta w LangChain, refaktoring do ToolRouter to 3 kroki.

Krok 1: Wydziel schematy z agenta. Zamiast definiować narzędzia inline:

tools = [tool1, tool2, tool3, ...]
agent = create_agent(tools=tools)

Przechowuj schematy w bazie danych lub API:

# Baza danych (np. PostgreSQL)
schemas = db.query("SELECT * FROM tool_schemas")

Krok 2: Implementuj routing semantyczny. Użyj embedingów do znalezienia odpowiednich narzędzi:

from langchain.embeddings import OpenAIEmbeddings

embeddings = OpenAIEmbeddings()
user_query_embedding = embeddings.embed_query(user_query)

# Znaleź podobne narzędzia (np. za pomocą cosine similarity)
similar_tools = find_similar_tools(user_query_embedding, schemas)

Krok 3: Załaduj schematy dynamicznie. Zamiast ładować wszystkie schematy, załaduj tylko te, które routing wybrał:

selected_schemas = [s for s in schemas if s.id in similar_tools]
agent = create_agent(tools=selected_schemas)

Architektura: schematy żyją w bazie danych (PostgreSQL, MongoDB), cache'owane w Redis dla szybkości, pobierane przez API na żądanie. Agent komunikuje się z API, które zwraca tylko potrzebne schematy. Integracja z istniejącym agentem: zamień tools=all_tools na tools=get_tools_for_query(query).

Ograniczenie: routing semantyczny nie zawsze jest doskonały. Jeśli pytanie użytkownika jest niejasne, embedding może wybrać złe narzędzia. Przykład: "Zrób mi coś z tekstem" — embedding może wybrać narzędzie do OCR zamiast do edycji tekstu. Wymaga testowania i fine-tuningu.

Werdykt: czy ToolRouter to przyszłość agentów AI czy hype?

ToolRouter działa. Redukcja z 287 000 do 3500 tokenów to nie jest teoretyczne — to wynik z rzeczywistego wdrożenia [1]. Dla agentów z 100+ narzędziami to gra zmienia się na twoją korzyść.

Ale ma ograniczenia. Routing semantyczny nie zawsze wybiera idealne narzędzie. Implementacja wymaga infrastruktury — baza danych, cache, API. Dla małych systemów (poniżej 50 narzędzi) to overkill.

Gdzie ToolRouter wygrywa: duże systemy (100+ narzędzi), gdzie każdy token się liczy, i gdzie responsywność agenta ma znaczenie biznesowe. Gdzie przegrywa: małe prototypy, gdzie prostota bije wydajność, i gdzie narzędzia są rzadko zmieniane.

Co robić teraz? Jeśli masz 50+ narzędzi — eksperymentuj. Zbuduj proof of concept z semantic routingiem. Zmierz redukcję tokenów i czas odpowiedzi. Jeśli wynik jest pozytywny — wdrażaj. Jeśli masz poniżej 50 narzędzi — czekaj. Standardy wokół routingu będą się krystalizować w ciągu 6–12 miesięcy, a wtedy będzie taniej i łatwiej.

W Aion Automation testowaliśmy ToolRouter na agencie zarządzającym 87 narzędziami do automatyzacji procesów biznesowych. Redukcja tokenów była zgodna z benchmarkami — z około 210 000 do 2800 tokenów. Czas odpowiedzi spadł z 3.2 sekundy do 1.1 sekundy. Dla klienta, który płaci za każdy token — to 87% oszczędności na koszcie API.

Następny krok: jeśli wdrażasz agenta z wieloma narzędziami, zaplanuj routing od początku. Nie buduj statycznego systemu, a potem go refaktoruj. Zaoszczędzisz miesiące pracy i tysiące złotych na kosztach API.

Źródła

[1] How to use 100+ AI tools without killing your context window — https://www.reddit.com/r/LangChain/comments/1sxx4bf/how_to_use_100_ai_tools_without_killing_your/

[2] Zrozumienie okien kontekstu i limitów tokenów - Developer Toolkit — https://developertoolkit.ai/pl/shared-workflows/context-management/context-windows/

[3] Okno kontekstowe AI — czym jest, jak działa i jak je optymalizować — https://13ai.pl/artykuly/okno-kontekstowe-ai.html

[7] Z jakich narzędzi AI korzystać do jakich zadań? — https://blue-mint.pl/z-jakich-narzedzi-ai-korzystac-do-jakich-zadan/