Jak agenci AI faktycznie implementuja umiejetnosci: Kompletne porownanie miedzyplatformowe

Wprowadzenie

Kazdy framework agentow AI staje przed tym samym fundamentalnym pytaniem: jak sprawic, aby LLM byl dobry w czyms konkretnym? Sam model posiada szeroka wiedze ogolna, ale gdy potrzebujesz, aby przeprowadzil przeglad kodu, wdrozyl infrastrukture lub nawigowql po Minecrafcie – potrzebuje specjalistycznych instrukcji, dostepu do narzedzi i kontekstu dziedzinowego.

To jest problem wstrzykiwania umiejetnosci. I kazdy wazny framework rozwiazuje go inaczej.

Niektore platformy wrzucaja wszystko do promptu systemowego z gory. Inne stosuja leniwe ladowanie, ujawniajac mozliwosci dopiero wtedy, gdy agent ich potrzebuje. Kilka wykorzystuje bazy danych wektorowych do wyszukiwania odpowiednich umiejetnosci na podstawie podobienstwa semantycznego. Roznice nie sa akademickie – bezposrednio wplywaja na koszty tokenow, niezawodnosc agentow i liczbe umiejetnosci, ktore agent moze realistycznie obslugiwac.

Przeanalizowalismy 11 glownych platform agentow AI, aby dokladnie zrozumiec, gdzie umiejetnosci laduja w prompcie, kiedy sie laduja, ile kosztuja w tokenach i jak przetrwaja, gdy okno kontekstu sie wypelni. To nie jest powierzchowne porownanie funkcji. Zaglebilismy sie w kod zrodlowy, dokumentacje i diagramy architektury, aby zmapowac dokladne mechanizmy wstrzykiwania kazdej platformy.

Glowna tabela porownawcza

Oto kompletny przeglad, zanim zaglebnimy sie w szczegoly.

Mechanizmy wstrzykiwania: Gdzie, kiedy i jak

Trwalosc, koszt tokenow i zachowanie always-on

Gotowy na rozwój swojej firmy?

Rozpocznij bezpłatny okres próbny już dziś i zobacz rezultaty w ciągu kilku dni.

Poproś o demo Zaloguj się

Co tak naprawde oznacza “wstrzykiwanie umiejetnosci”

Zanim zaglebnimy sie w porownanie, zdefiniujmy przestrzen problemu. Okno kontekstu agenta AI – calkowity tekst, ktory LLM widzi przy kazdym wywolaniu – ma ustalony rozmiar. Kazdy token instrukcji, historii konwersacji, definicji narzedzia i pobranych danych rywalizuje o miejsce w tym oknie.

“Umiejetnosc” w kontekscie agenta to dowolny strukturyzowany pakiet wiedzy eksperckiej, ktory zmienia zachowanie agenta. Moze to byc:

• Instrukcje mowiace agentowi, jak podejsc do konkretnej dziedziny (wytyczne przegladu kodu, listy kontrolne wdrozenia)
• Definicje narzedzi dajace agentowi mozliwosc wywolywania funkcji (integracje API, operacje na plikach)
• Przyklady few-shot pokazujace agentowi, jak wyglada dobre wyjscie
• Pobrana wiedza z baz danych wektorowych lub zewnetrznych dokumentow

Mechanizm wstrzykiwania – gdzie i kiedy ta zawartosc trafia do kontekstu – determinuje trzy kluczowe wlasciwosci:

1. Efektywnosc tokenowa: Ile tokenow zuzywa umiejetnosc i czy ten koszt jest ponoszony nawet wtedy, gdy umiejetnosc nie jest potrzebna?
2. Niezawodnosc: Czy agent bedzie konsekwentnie uzywac umiejetnosci, gdy jest istotna, czy moze przegapic sygnal?
3. Skalowalnosc: Ile umiejetnosci agent moze obsluzyc, zanim rozdecie kontekstu pogorsza wydajnosc?

Kazdy framework dokonuje roznych kompromisow w tych trzech wymiarach. Przeanalizujmy kazdy z nich.

Spektrum wstrzykiwania: Od always-on do na zadanie

We wszystkich 11 platformach podejscia do wstrzykiwania umiejetnosci mieszcza sie w spektrum od “wszystko zaladowane z gory” do “nic nie zaladowane do momentu jawnego zapotrzebowania”.

Na jednym koncu platformy takie jak CrewAI, SuperAGI i CAMEL-AI wstrzykuja pelna zawartosc kazdej aktywowanej umiejetnosci do kazdego wywolania LLM. Agent zawsze ma dostep do pelnej wiedzy eksperckiej. Proste, niezawodne, ale kosztowne w tokenach.

Na drugim koncu Claude Code, LangChain Deep Agents i OpenAI Responses API stosuja stopniowe ujawnianie – agent widzi tylko nazwy umiejetnosci i krotkie opisy przy starcie, a pelna zawartosc laduje sie na zadanie. Efektywne, skalowalne, ale wymaga od agenta rozpoznania, kiedy potrzebuje umiejetnosci.

Posrodku AutoGen Teachability i Voyager uzywaja wyszukiwania semantycznego do wstrzykiwania tylko najistotniejszych umiejetnosci na ture, tworzac dynamiczny, kontekstowo-wrazliwy wzorzec wstrzykiwania.

Istnieja tez unikalne podejscia: DSPy kompiluje zoptymalizowane przyklady few-shot offline i trwale wbudowuje je w prompty modulow. MetaGPT koduje umiejetnosci jako szablony akcji, ktore aktywuja sie tylko wtedy, gdy okreslona rola przechodzi do okreslonej akcji.

Przeanalizujmy kazde z nich szczegolowo.

Dołącz do naszego newslettera

Otrzymuj najnowsze wskazówki, trendy i oferty za darmo.

Adres e-mail

Zapisz się

Claude Code: Trzywarstwowe stopniowe ujawnianie

Claude Code implementuje jedna z najbardziej zaawansowanych architektur wstrzykiwania umiejetnosci, wykorzystujac trzywarstwowy system stopniowego ujawniania, ktory rownowazy swiadomosc z efektywnoscia tokenowa.

Warstwa 1: Zawsze w kontekscie

Przy starcie sesji nazwa i opis kazdej dostepnej umiejetnosci sa wstrzykiwane do wiadomosci system-reminder – bloku metadanych, ktory model zawsze widzi. Kosztuje to okolo 250 znakow na umiejetnosc, zuzywajaec okolo 1% budzetu okna kontekstu na wszystkie opisy umiejetnosci lacznie (okolo 8K znakow jako budzet awaryjny, nadpisywalny przez zmienna srodowiskowa SLASH_COMMAND_TOOL_CHAR_BUDGET).

Podobnie odroczone narzedzia – narzedzia, ktorych pelne schematy JSON nie zostaly jeszcze zaladowane – pojawiaja sie jako lista samych nazw w blokach system-reminder. Od Claude Code v2.1.69 nawet wbudowane narzedzia systemowe jak Bash, Read, Edit, Write, Glob i Grep sa odroczone za ToolSearch, redukujac kontekst narzedzi systemowych z okolo 14-16K tokenow do okolo 968 tokenow.

Agent widzi wystarczajaco duzo, by wiedziec, co jest dostepne, bez ponoszenia kosztu tokenow pelnych definicji.

Warstwa 2: Przy aktywacji

Gdy uzytkownik wpisuje komende slash (np. /commit) lub model automatycznie dopasowuje umiejetnosc na podstawie jej opisu, pelna tresc SKILL.md jest ladowana jako wiadomosc konwersacji za pomoca narzedzia Skill. Ta tresc zawiera kompletne instrukcje – czasem tysiace tokenow szczegolowych wytycznych.

Kluczowy szczegol: najpierw uruchamiane jest przetwarzanie wstepne powloki (wszelkie dyrektywy !command w pliku umiejetnosci sa wykonywane, a ich wyjscie zastepuje dyrektywe), a po zaladowaniu tresc umiejetnosci pozostaje w konwersacji przez reszte sesji.

Warstwa 3: Na zadanie

Dodatkowe zasoby – dokumenty referencyjne, skrypty, pliki zasobow – sa odczytywane tylko wtedy, gdy model jawnie zdecyduje sie uzyc narzedzia Read, aby uzyskac do nich dostep. Nigdy nie laduja sie automatycznie.

Zachowanie przy kompakcji kontekstu

Gdy konwersacja zbliza sie do limitu kontekstu i uruchamia sie kompakcja, Claude Code ponownie dolacza ostatnio wywolane umiejetnosci z budzetem 5K tokenow na umiejetnosc i maksymalnie 25K lacznie. Ostatnio wywolane umiejetnosci maja priorytet. Starsze umiejetnosci moga zostac calkowicie usuniete.

Ta trzywarstwowa architektura oznacza, ze agent z ponad 20 dostepnymi umiejetnosciami ponosi minimalny koszt poczatkowy, ale moze uzyskac dostep do pelnej wiedzy eksperckiej w ramach jednej tury.

CrewAI: Pelne wstrzykiwanie do kazdego promptu zadania

CrewAI przyjmuje podejscie przeciwne do stopniowego ujawniania. Gdy umiejetnosc jest aktywowana dla agenta, jej pelna zawartosc jest wstrzykiwana do kazdego promptu zadania, ktore agent wykonuje.

Jak to dziala

Umiejetnosci w CrewAI to samodzielne katalogi, kazdy z plikiem SKILL.md zawierajacym frontmatter YAML (nazwa, opis, licencja, kompatybilnosc, dozwolone narzedzia) i tresc markdown. System umiejetnosci rozroznia umiejetnosci od narzedzi: umiejetnosci wstrzykuja instrukcje i kontekst ksztaltujacy sposob myslenia agenta, podczas gdy narzedzia zapewniaja funkcje do wywolywania akcji.

Podczas inicjalizacji agenta Agent.set_skills() wywoluje discover_skills() w celu skanowania katalogow umiejetnosci na poziomie metadanych, a nastepnie activate_skill() w celu odczytania pelnych tresci umiejetnosci. W czasie wykonywania zadania _finalize_task_prompt() wywoluje format_skill_context() dla kazdej aktywowanej umiejetnosci i dodaje cala sformatowana zawartosc umiejetnosci do promptu zadania.

LLM otrzymuje: [wiadomosc systemowa] + [prompt zadania + WSZYSTKIE tresci umiejetnosci]

Implikacje tokenowe

CrewAI narzuca miekkie ostrzezenie przy 50 000 znakow na umiejetnosc, ale bez twardego limitu. Dokumentacja zaleca utrzymywanie umiejetnosci skoncentrowanych i zwiezlych, poniewaz duze wstrzykniecia promptow rozpraszaja uwage modelu – realne obawy w swietle badan nad degradacja kontekstu.

Kompromis jest prosty: agent zawsze ma dostep do pelnej wiedzy eksperckiej (wysoka niezawodnosc), ale koszt tokenow rosnie liniowo wraz z liczba umiejetnosci na zadanie (niska efektywnosc). Dla agentow z 1-2 skoncentrowanymi umiejetnosciami to dziala dobrze. Dla agentow potrzebujacych szerokiego zestawu mozliwosci szybko staje sie kosztowne.

Brak trwalosci miedzy zadaniami

Kazde zadanie otrzymuje swieze wstrzykniecie. Nie ma akumulacji tresci umiejetnosci miedzy zadaniami – co faktycznie jest zaleta, nie wada. Oznacza to, ze kazde zadanie zaczyna z czystym kontekstem, unikajac problemow z przestarzaloscia, ktore moze tworzyc trwalosc oparta na sesjach.

LangChain Deep Agents: Ladowanie kontrolowane przez agenta przez SkillsMiddleware

LangChain Deep Agents implementuje zaawansowany system umiejetnosci oparty na middleware, w ktorym sam agent decyduje, kiedy zaladowac pelna tresc umiejetnosci – prawdziwy model stopniowego ujawniania, w ktorym agent kontroluje aktywacje.

Trzy warstwy

Warstwa 1 (Indeks): SkillsMiddleware parsuje caly frontmatter SKILL.md przy starcie i wstrzykuje lekki indeks do promptu systemowego. Ten indeks zawiera tylko nazwy i opisy, kosztujac okolo 278 tokenow na umiejetnosc w porownaniu z 3302 tokenami za pelna zawartosc.

Warstwa 2 (Pelna zawartosc): Gdy agent stwierdzi, ze umiejetnosc jest istotna, wywoluje read_file() na sciezce SKILL.md umiejetnosci. To zwykle wywolanie narzedzia – framework nie wstrzykuje tresci; agent podejmuje swiadoma decyzje o zaladowaniu. Pelna zawartosc trafia do historii konwersacji jako wynik narzedzia.

Warstwa 3 (Poglebiona analiza): Materialy pomocnicze, dokumenty referencyjne i skrypty sa dostepne tylko wtedy, gdy agent jawnie je odczytuje.

Efektywnosc tokenowa w praktyce

Przy 12 umiejetnosciach stopniowe ujawnianie redukuje kontekst z okolo 30 000 tokenow (wszystkie zaladowane) do okolo 600 tokenow (tylko indeks), rozszerzajac sie do 2000-5000, gdy odpowiednie umiejetnosci sa ladowane do konkretnego zadania. To potencjalna redukcja o 83-98% w zuzyciu tokenow zwiazanych z umiejetnosciami.

Mozna nakladac wiele zrodel umiejetnosci, a gdy nazwy koliduja, wygrywa ostatnie zrodlo. Pliki powyzej 10 MB sa automatycznie pomijane.

Kluczowa roznica wzgledem Claude Code

Podczas gdy Claude Code uzywa dedykowanego narzedzia Skill do wyzwalania ladowania, Deep Agents wykorzystuje istniejace narzedzie read_file agenta. Oznacza to, ze mechanizm ladowania jest przezroczysty – agent czyta pliki umiejetnosci tak samo jak kazdy inny plik. Wada jest brak specjalnego zachowania kompakcji: zawartosc umiejetnosci, ktora trafia do historii konwersacji, podlega standardowemu przycinaniu wiadomosci LangChain, bez priorytetowego traktowania.

OpenAI Responses API i Agents SDK: Odroczone ladowanie zarzadzane przez platforme

OpenAI implementuje wstrzykiwanie umiejetnosci za pomoca dwoch odrebnych, ale filozoficznie spojnych mechanizmow: typu narzedzia tool_search w Responses API i ToolSearchTool w Agents SDK.

Responses API: tool_search

Typ narzedzia tool_search (dostepny w GPT-5.4+) pozwala deweloperom odroczyc duze powierzchnie narzedzi do czasu uruchomienia. Dostepne sa trzy strategie odraczania:

• Indywidualne odraczanie funkcji: @function_tool(defer_loading=True) – model widzi nazwe i opis funkcji, ale schemat parametrow jest odroczony. Oszczedza tokeny na poziomie parametrow.
• Odraczanie przestrzeni nazw: tool_namespace(name=..., description=..., tools=[...]) – grupuje funkcje pod jedna przestrzenia nazw. Model widzi tylko nazwe i opis przestrzeni nazw, oszczedzajac znacznie wiecej tokenow.
• Odraczanie serwera MCP: HostedMCPTool(tool_config={..., "defer_loading": True}) – odracza calkowite powierzchnie narzedzi serwera MCP.

Gdy model stwierdzi, ze potrzebuje konkretnego narzedzia, wydaje wywolanie tool_search. API zwraca 3-5 odpowiednich definicji narzedzi, wstrzykiwanych na koncu okna kontekstu w celu zachowania buforowania promptow.

Agents SDK: ToolSearchTool

Agents SDK zapewnia programistyczny odpowiednik. Przestrzenie nazw narzedzi sa rejestrowane, ale nie ladowane:

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

W runtime agent widzi tylko nazwy przestrzeni nazw. Wywoluje ToolSearchTool("crm"), aby odkryc i zaladowac pelne schematy, a nastepnie moze wywolywac poszczegolne narzedzia w tej przestrzeni nazw.

Brak trwalosci miedzy zapytaniami

Kazde zapytanie API jest niezalezne. Odkryte narzedzia nie sa trwale miedzy wywolaniami. To najbardziej bezstanowe podejscie w naszym porownaniu – czyste, przewidywalne, ale wymagajace ponownego odkrywania przy kazdym zapytaniu, jesli narzedzia sie zmienia.

AutoGen Teachability: Semantyczne pobieranie na ture

Mozliwosc Teachability w AutoGen przyjmuje fundamentalnie inne podejscie niz kazdy inny framework w tym porownaniu. Zamiast wstrzykiwac statyczna tresc umiejetnosci, dynamicznie pobiera odpowiednie “notatki” z bazy danych wektorowej ChromaDB przy kazdej turze.

Petla pobierania na ture

Teachability rejestruje hook na process_last_received_message, ktory przechwytuje kazda przychodzaca wiadomosc uzytkownika, zanim agent ja przetworzy:

1. TextAnalyzerAgent wyodrebnia kluczowe koncepcje z przychodzacej wiadomosci
2. Te koncepcje sa uzywane do odpytywania ChromaDB (domyslnie przy uzyciu embeddingew Sentence Transformer)
3. Top-K najistotniejszych notatek jest pobieranych (konfigurowalne przez max_num_retrievals, domyslnie 10)
4. Pobrane notatki sa dolaczane do tekstu wiadomosci, zanim agent ja zobaczy

Co wazne, zmodyfikowana wiadomosc nie jest propagowana do przechowywanej historii konwersacji – przechowywana jest tylko oryginalna wiadomosc. Zapobiega to narastaniu tresci notatek miedzy turami.

Petla uczenia

Po odpowiedzi LLM drugi hook analizuje odpowiedz pod katem nowej wiedzy:

1. TextAnalyzerAgent identyfikuje nowa wiedze w odpowiedzi
2. Nowe notatki sa wyodrebniane jako pary klucz-wartosc (tekst wejsciowy -> tekst wyjsciowy)
3. Te notatki sa przechowywane w ChromaDB, dostepne dla przyszlych tur i sesji

Tworzy to autentyczna petle uczenia, w ktorej agent gromadzi wiedze ekspercka w czasie.

Trwalosc miedzysesyjna

AutoGen Teachability jest jedna z zaledwie trzech platform w naszym porownaniu (obok Voyager i DSPy), ktore utrzymuja umiejetnosci miedzy sesjami. Baza danych ChromaDB znajduje sie na dysku, co oznacza, ze agent moze uczyc sie z interakcji w poniedzialek i zastosowac te wiedze w piatek.

Parametr recall_threshold (domyslnie 1.5) kontroluje, jak bardzo wiadomosc musi byc podobna do przechowywanej notatki, aby zostala pobrana, a reset_db moze wyczysc cala pamiec w razie potrzeby.

Efektywnosc tokenowa

Poniewaz tylko istotne notatki sa wstrzykiwane na ture (zwykle 3-5), koszt tokenow jest naturalnie ograniczony niezaleznie od tego, jak duza jest baza notatek. Agent z 10 000 przechowywanych notatek nadal placi tylko za garsc najbardziej istotnych dla biezacej tury.

Semantic Kernel: Schematy wtyczek jako zawsze obecne definicje narzedzi

Semantic Kernel od Microsoft przyjmuje proste podejscie: wtyczki to kolekcje obiektow KernelFunction zarejestrowanych w Kernelu, a ich schematy sa eksponowane LLM-owi jako definicje narzedzi function-calling.

Dwie sciezki wstrzykiwania

Function Calling: Gdy ustawione jest ToolCallBehavior.AutoInvokeKernelFunctions, wszystkie zarejestrowane funkcje sa wysylane do LLM jako dostepne narzedzia w kazdym zapytaniu API. LLM decyduje, ktore wywolac; Semantic Kernel obsluguje wywolanie i routing wynikow.

Szablony promptow: Skladnia szablonow Semantic Kernel ({{plugin.function}}, Handlebars lub Liquid) pozwala na wywolywanie funkcji inline podczas renderowania promptu. Wyniki sa osadzane bezposrednio w tekscie promptu zanim trafi on do LLM – forma zachlannej ewaluacji zamiast leniwego wywolywania narzedzi.

Brak stopniowego ujawniania

Schemat kazdej zarejestrowanej wtyczki jest dolaczany do kazdego wywolania API. Nie ma wbudowanego odroczonego ladowania, grupowania przestrzeni nazw ani aktywacji na zadanie. Dokumentacja jawnie zaleca importowanie tylko wtyczek potrzebnych do konkretnego scenariusza, aby zmniejszyc zuzycie tokenow i bledne wywolania.

To sprawia, ze Semantic Kernel jest jedna z najbardziej przewidywalnych platform – zawsze wiesz dokladnie, do czego agent ma dostep – ale ogranicza skalowalnosc. Agent z 50 zarejestrowanymi funkcjami ponosi pelny koszt schematu przy kazdym pojedynczym wywolaniu.

Trwalosc

Rejestracja wtyczek jest per-instancja-Kernela i w pamieci. Nie ma wbudowanego mechanizmu trwalosci umiejetnosci miedzy sesjami.

MetaGPT: Szablony akcji w ramach SOP opartych na rolach

MetaGPT koduje umiejetnosci nie jako samodzielne pakiety, ale jako szablony akcji osadzone w Standardowych Procedurach Operacyjnych (SOP), ktore reguluja zachowanie rol.

Architektura rol i akcji

Kazda Role w MetaGPT ma prefiks persony wstrzykiwany do promptow i zestaw klas Action. Kazda Action zawiera proxy LLM wywolywane przez aask(), ktore uzywa szablonow promptow w jezyku naturalnym do strukturyzowania wywolania LLM.

Gdy Role._act() sie uruchamia, wspiera trzy tryby react:

• "react": LLM dynamicznie wybiera akcje w petlach think-act
• "by_order": Akcje wykonuja sie sekwencyjnie w z gory okreslonej kolejnosci
• "plan_and_act": Agent najpierw planuje, a nastepnie wykonuje akcje zgodnie z planem

Waskie okno wstrzykiwania

Tylko szablon biezacej akcji jest aktywny w danym momencie. Agent nie widzi szablonow innych akcji – widzi tylko swoj prefiks roli plus kontekst konkretnej akcji. To najwezsze okno wstrzykiwania ze wszystkich przeanalizowanych frameworkow.

Funkcje parsowania kontekstu w klasach Action wyodrebniaja istotne informacje z danych wejsciowych, wiec kazda akcja otrzymuje wyselekcjonowany podzbioor dostepnego kontekstu zamiast pelnej historii konwersacji.

Trwalosc jednoturowa

Szablon jest renderowany na nowo przy kazdym wykonaniu akcji. Nie ma akumulacji ani trwalosci miedzysesyjnej. Utrzymuje to kazda akcje w skupieniu, ale oznacza, ze agent nie moze budowac na wczesniej zaladowanej tresci umiejetnosci w ramach jednego workflow.

Voyager: Pobieranie umiejetnosci oparte na embeddingach dla uczenia calozyciowego

Voyager, agent eksploracji Minecraft od NVIDIA i Caltech, implementuje jedna z najbardziej eleganckich architektur wstrzykiwania umiejetnosci: rosnaca biblioteke zweryfikowanych programow pobieranych przez podobienstwo embeddingowe.

Biblioteka umiejetnosci

Gdy Voyager pisze kod, ktory przechodzi samo-weryfikacje (wygenerowany JavaScript Mineflayer faktycznie dziala w grze), kod i jego docstring sa przechowywane w bazie danych wektorowej. Embedding docstringa staje sie kluczem wyszukiwania.

Pobieranie na zadanie

Przy kazdym nowym zadaniu zaproponowanym przez automatyczne curriculum:

1. Opis zadania i feedback ze srodowiska sa zamieniane na embeddingi
2. Wyszukiwanie podobienstwa kosinusowego wzgledem wszystkich przechowywanych embeddingew umiejetnosci
3. Top-5 najistotniejszych umiejetnosci jest pobieranych
4. Pobrany kod umiejetnosci jest wlaczany do promptu agenta akcji jako przyklady few-shot

Prompt wyglada tak:

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

Wygenerowany kod moze wywolywac pobrane umiejetnosci po nazwie, umozliwiajac kompozycyjne budowanie umiejetnosci – zlozrone zachowania konstruowane z prostszych, zweryfikowanych prymitywow.

Dozywotnia trwalosc

Biblioteka umiejetnosci jest podstawowym mechanizmem “uczenia calozyciowego”. Rosnie przez caly czas zycia agenta, a nowe umiejetnosci buduja na starych. W przeciwienstwie do wiekszosci frameworkow, gdzie umiejetnosci sa tworzone przez ludzi, umiejetnosci Voyagera sa generowane, weryfikowane i przechowywane przez samego agenta.

Koszt tokenow jest naturalnie ograniczony: niezaleznie od tego, czy biblioteka zawiera 50 czy 5000 umiejetnosci, kazde zadanie placi tylko za 5 najistotniejszych pobranych.

DSPy: Skompilowane przyklady few-shot jako zamrozone umiejetnosci

DSPy przyjmuje radykalnie inne podejscie niz kazdy inny framework. Zamiast wstrzykiwac umiejetnosci w runtime, DSPy kompiluje optymalne demonstracje few-shot offline i trwale wbudowuje je w prompty modulow.

Proces kompilacji

Dwa glowne optymalizatory obsluguja kompilacje:

BootstrapFewShot: Uzywa modulu nauczyciela do generowania sledzen przez program. Sledzenia, ktore przejda metyke zdefiniowana przez uzytkownika, sa zachowywane jako demonstracje. Kazdy modul dspy.Predict w programie otrzymuje wlasny wyselekcjonowany zestaw demonstracji.

MIPROv2 (Multi-prompt Instruction Proposal Optimizer v2): Trzyfazowy proces:

1. Bootstrap: Generowanie zbiorow kandydujacych demonstracji
2. Propose: Generowanie kandydujacych tekstow instrukcji swiadomych zarowno rozkladu danych, jak i demonstracji
3. Search: Optymalizacja bayesowska w polaczonej przestrzeni instrukcji x demonstracji we wszystkich modulach

Parametry takie jak max_bootstrapped_demos (wygenerowane przyklady) i max_labeled_demos (z danych treningowych) kontroluja, ile przykladow trafia do promptu kazdego modulu.

Ustalone po kompilacji

Po kompilacji demonstracje sa przechowywane w atrybucie demos kazdego modulu Predict i formatowane w prompt przy kazdym wywolaniu LLM. Nie zmieniaja sie w runtime – “umiejetnosc” jest zamrozona.

Oznacza to, ze umiejetnosci DSPy sa najbardziej przewidywalne w naszym porownaniu: koszt tokenow jest znany po kompilacji, nie ma wariancji miedzy turami, a agent zawsze widzi te same demonstracje. Wada jest brak elastycznosci – aby zmienic umiejetnosci, trzeba ponownie skompilowac.

Trwalosc

Skompilowane programy serializuja sie do JSON, w tym wszystkie demonstracje. Sa w pelni trwale i ladowalne miedzy sesjami, co czyni DSPy jednym z najtrwalszych mechanizmow przechowywania umiejetnosci.

SuperAGI: Rejestracja toolkit z gory

SuperAGI uzywa tradycyjnego wzorca toolkit, w ktorym wszystkie narzedzia sa rejestrowane przy inicjalizacji agenta.

Kazdy toolkit rozszerza BaseToolkit o:

• atrybuty name i description
• metode get_tools() zwracajaca liste instancji BaseTool
• get_env_keys() dla wymaganych zmiennych srodowiskowych

Toolkity sa instalowane z repozytoriow GitHub za pomoca menadzera narzedzi SuperAGI. Przy inicjalizacji agenta BaseToolkit.get_tools() zwraca wszystkie narzedzia, a ich kompletne schematy sa eksponowane LLM-owi jako definicje function-calling.

Nie ma odroczonego ladowania, stopniowego ujawniania ani filtrowania na ture. Schemat kazdego zarejestrowanego narzedzia jest obecny w kazdym wywolaniu. To najprostszy model wstrzykiwania i dziala dobrze dla agentow z skoncentrowanymi, malymi zestawami narzedzi, ale nie skaluje sie do agentow potrzebujacych dziesiatek mozliwosci.

CAMEL-AI: Rejestracja narzedzi ChatAgent

CAMEL-AI podaza za podobnym wzorcem rejestracji z gory. Narzedzia z roznych toolkitow (np. MathToolkit, SearchToolkit) sa przekazywane jako lista do ChatAgent(tools=[...]) przy inicjalizacji.

Framework podkresla, ze niestandardowe funkcje potrzebuja jasnych nazw argumentow i kompleksowych docstringow, aby model mogl zrozumiec uzycie – schemat narzedzia jest jedyna trescia “umiejetnosci”, ktora model widzi. Nie ma oddzielnego mechanizmu wstrzykiwania instrukcji.

Ostatnie dodatki obejmuja obsluge MCP (Model Context Protocol) przez MCPToolkit, pozwalajaca ChatAgent na polaczenie z serwerami MCP i rejestracje zewnetrznych narzedzi. Rozszerza to dostepna powierzchnie narzedzi, ale nie zmienia modelu wstrzykiwania – wszystkie odkryte narzedzia MCP sa nadal rejestrowane z gory.

Porownanie miedzyplatformowe

Kiedy umiejetnosci sa wstrzykiwane

Modele trwalosci

Przetrwanie kompakcji kontekstu

Wzorzec stopniowego ujawniania

Najistotniejszy trend architektoniczny wsrod tych platform to przyjecie stopniowego ujawniania – koncepcji zapozyczonej z projektowania interfejsow, gdzie informacje sa ujawniane stopniowo w oparciu o potrzeby.

Dlaczego stopniowe ujawnianie ma znaczenie

Naiwne podejscie do wstrzykiwania umiejetnosci – ladowanie wszystkiego z gory – tworzy dwa problemy:

1. Marnowanie tokenow: Wiekszosc umiejetnosci nie jest istotna na wiekszosci tur. Ladowanie 20 pelnych tresci umiejetnosci, gdy tylko 1-2 sa potrzebne na ture, marnuje ponad 90% tokenow zwiazanych z umiejetnosciami.
2. Rozpraszanie uwagi: Badania nad degradacja kontekstu pokazuja, ze LLM-y dzialaja gorzej, gdy ich kontekst zawiera duze ilosci nieistotnych informacji. Wiecej umiejetnosci w kontekscie moze faktycznie pogorszyc jakosc stosowania umiejetnosci.

Stopniowe ujawnianie rozwiazuje oba problemy, utrzymujac lekki indeks dostepnych umiejetnosci, a ladujac pelna zawartosc tylko w razie potrzeby.

Warianty implementacji

Claude Code uzywa dedykowanego systemu: metadane umiejetnosci w wiadomosciach system-reminder, narzedzie Skill do aktywacji i ToolSearch do odroczonych schematow narzedzi. Framework zarzadza wstrzykiwaniem automatycznie z priorytetowa kompakcja.

LangChain Deep Agents uzywa istniejacych mozliwosci czytania plikow agenta: SkillsMiddleware wstrzykuje indeks, a agent laduje pelna zawartosc przez read_file(). Jest to bardziej przezroczyste, ale oferuje mniej optymalizacji na poziomie frameworka.

OpenAI Responses API uzywa grupowania opartego na przestrzeniach nazw z wyszukiwaniem zarzadzanym przez platforme: przestrzenie nazw narzedzi zapewniaja wysokopoziomowe opisy, a tool_search zwraca odpowiednie schematy. Platforma obsluguje logike wyszukiwania w calosci.

Oszczednosci tokenow w praktyce

Liczby sa przekonujace. Przy 12 umiejetnosciach:

• Wstrzykiwanie always-on (styl CrewAI/SuperAGI): ~30 000 tokenow
• Tylko indeks stopniowego ujawniania: ~600 tokenow
• Indeks + 2 aktywowane umiejetnosci: ~2000-5000 tokenow

To redukcja o 83-98% w zuzyciu tokenow zwiazanych z umiejetnosciami na ture. W dlugiej sesji z setkami tur oszczednosci narastaja dramatycznie.

Wzorce architektoniczne i kompromisy

Patrzac na wszystkie 11 platform, wyodreBniaja sie cztery wyrazne wzorce architektoniczne:

Wzorzec 1: Wstrzykiwanie always-on

Uzywany przez: CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

Jak dziala: Pelna zawartosc umiejetnosci lub schematy narzedzi sa obecne w kazdym wywolaniu LLM.

Zalety:

• Maksymalna niezawodnosc – agent zawsze ma pelna wiedze ekspercka
• Najprostsza implementacja – nie potrzeba logiki aktywacji
• Przewidywalne koszty tokenow – takie same na kazdej turze

Wady:

• Koszt tokenow rosnie liniowo wraz z liczba umiejetnosci
• Rozpraszanie uwagi przy wielu umiejetnosciach
• Nie skaluje sie powyzej ~5-10 umiejetnosci na agenta

Najlepszy dla: Skoncentrowanych agentow z 1-3 kluczowymi umiejetnosciami, ktore sa zawsze istotne.

Wzorzec 2: Stopniowe ujawnianie

Uzywany przez: Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

Jak dziala: Lekkie metadane zawsze obecne; pelna zawartosc ladowana na zadanie.

Zalety:

• Skaluje sie do dziesiatek lub setek dostepnych umiejetnosci
• Minimalny koszt tokenow, gdy umiejetnosci nie sa potrzebne
• Zachowuje bufor promptow, gdy pelne schematy sa dolaczane na koncu

Wady:

• Agent moze przegapic sygnal do aktywacji istotnej umiejetnosci
• Dodatkowe opoznienie z kroku aktywacji
• Bardziej zlozona implementacja frameworka

Najlepszy dla: Agentow ogolnego przeznaczenia, ktorzy potrzebuja dostepu do wielu mozliwosci, ale uzywaja tylko kilku na zadanie.

Wzorzec 3: Wyszukiwanie semantyczne

Uzywany przez: AutoGen Teachability, Voyager

Jak dziala: Zapytania do bazy danych wektorowej wydobywaja istotne umiejetnosci/wiedze na podstawie podobienstwa semantycznego do biezacego kontekstu.

Zalety:

• Naturalnie ograniczony koszt tokenow niezaleznie od rozmiaru biblioteki
• Istotnosc tresci poprawia sie z czasem w miare rozrastania biblioteki
• Uczenie i akumulacja miedzysesyjna
• Nie wymaga jawnej aktywacji – istotnosc jest obliczana automatycznie

Wady:

• Jakosc wyszukiwania zalezy od jakosci modelu embeddingowego
• Ryzyko pobrania przestarzalych lub subtelnie blednych informacji
• Wymaga infrastruktury bazy danych wektorowej
• Mniej przewidywalne – rozne tury laduja rozna zawartosc

Najlepszy dla: Agentow uczacych sie z doswiadczenia, ktorzy musza gromadzic wiedze dziedzinowa w czasie.

Wzorzec 4: Skompilowane/statyczne wstrzykiwanie

Uzywany przez: DSPy, MetaGPT

Jak dziala: Umiejetnosci sa kompilowane w ustalona zawartosc promptu (DSPy) lub aktywowane przez sztywne szablony akcji (MetaGPT).

Zalety:

• Najbardziej przewidywalne zachowanie – ta sama zawartosc za kazdym razem
• Optymalizacja moze byc wykonana offline (kompilacja DSPy)
• Brak narzutu runtime na wybor umiejetnosci
• Udowodniona skutecznosc dla dobrze zdefiniowanych, powtarzalnych zadan

Wady:

• Brak elastycznosci – zmiana umiejetnosci wymaga rekompilacji (DSPy) lub zmian w kodzie (MetaGPT)
• Nie moze adaptowac sie do nowych sytuacji poza skompilowanymi przykladami
• Proces kompilacji DSPy sam wymaga wielu wywolaw LLM

Najlepszy dla: Produkcyjnych pipeline’ow z dobrze zdefiniowanymi zadaniami, gdzie niezawodnosc wygrywa z elastycznoscia.

Praktyczne implikacje dla tworcow agentow

Wybor odpowiedniego wzorca

Odpowiednia architektura wstrzykiwania umiejetnosci zalezy od profilu agenta:

Jesli agent ma waska, dobrze zdefiniowana role (np. bot do przegladow kodu, agent obslugi klienta dla jednego produktu), wstrzykiwanie always-on (wzorzec CrewAI/SuperAGI) jest najprostsze i najbardziej niezawodne. Koszt tokenow 2-3 zawsze obecnych umiejetnosci jest do opanowania, a unikasz zlozonosci logiki aktywacji.

Jesli agent potrzebuje szerokich mozliwosci, ale uzywa tylko kilku na interakcje (np. asystent dewelopera, agent automatyzacji ogolnego przeznaczenia), stopniowe ujawnianie (wzorzec Claude Code/Deep Agents) jest zdecydowanym zwyciezca. Oszczednosci 83-98% tokenow w skali sa zbyt znaczace, aby je ignorowac.

Jesli agent musi uczyc sie i doskonalic z interakcji (np. osobisty asystent, ekspert dziedzinowy gromadzacy wiedze), wyszukiwanie semantyczne (wzorzec AutoGen Teachability) zapewnia petle uczenia, ktorej brakuje innym wzorcom. Upewnij sie tylko, ze masz kontrole jakosci nad tym, co trafia do bazy wiedzy.

Jesli agent uruchamia dobrze zdefiniowane pipeline’y (np. przetwarzanie danych, generowanie raportow, standaryzowane workflow), skompilowane wstrzykiwanie (wzorzec DSPy) daje najbardziej przewidywalne, zoptymalizowane zachowanie.

Podejscie hybrydowe

Dla produkcyjnych zespolow agentow, gdzie agenci musza dzialac od razu, zalecamy podejscie hybrydowe:

Kluczowe umiejetnosci (1-2 na agenta, definiujace ich glowna wiedze dziedzinowa): zawsze wstrzykiwane do promptu systemowego, w stylu CrewAI. To nienegocjowalne mozliwosci, ktorych agent potrzebuje na kazdej turze.

Rozszerzone umiejetnosci (dodatkowe mozliwosci, ktorych agent moze potrzebowac): tylko metadane w prompcie systemowym, ladowane przez mechanizm wyszukiwania/ladowania w razie potrzeby, w stylu Deep Agents. Rozszerzaja zestaw mozliwosci agenta bez ponoszenia kosztu tokenow, gdy nie sa istotne.

Nauczona wiedza (skumulowana wiedza dziedzinowa): przechowywana w bazie danych wektorowej i pobierana semantycznie na ture, w stylu AutoGen. Pozwala to agentowi doskonalic sie z czasem bez recznego tworzenia umiejetnosci.

Ta warstwowa architektura mapuje sie naturalnie na sposob budowania promptu systemowego: data -> persona -> instrukcje systemowe -> kluczowe umiejetnosci -> indeks umiejetnosci -> kontekst roli/zespolu. Kluczowe umiejetnosci i indeks dodaja przewidywalny, zarzadzalny koszt tokenow, podczas gdy pelne tresci umiejetnosci pojawiaja sie tylko w razie potrzeby.

Najlepsze praktyki budzetu tokenow we wszystkich frameworkach

Niezaleznie od tego, ktory wzorzec wstrzykiwania stosujesz, te strategie zarzadzania tokenami maja uniwersalne zastosowanie:

Kolejnosc przyjazna buforowaniu

Umieszczaj niezmienna zawartosc (instrukcje systemowe, schematy narzedzi) na poczatku promptu. U dostawcow obslugujacych buforowanie promptow, buforowane tokeny kosztuja o 75% mniej. Claude Code i OpenAI wstrzykuja odkryte schematy narzedzi na koncu kontekstu specjalnie w celu zachowania trafien bufora na statycznym prefiksie.

Odciazanie

Podsumowuj odpowiedzi narzedzi zamiast trzymac pelne wyniki w kontekscie. Przechowuj kompletne dane w zewnetrznych referencjach, ktore agent moze odczytac na zadanie. Jest to szczegolnie wazne dla agentow wykonujacych wiele wywolaw narzedzi na sesje.

Redukcja

Kompaktuj historie konwersacji przez podsumowywanie. Wyodrebniaj kluczowe fakty z dlugich wymian w skondensowane reprezentacje. Kazdy framework z trwaloscia oparta na sesjach korzysta z agresywnego zarzadzania historia.

Pobieranie zamiast wstepnego ladowania

Dynamicznie pobieraj istotne informacje w runtime zamiast ladowac wszystko z gory. Dotyczy to umiejetnosci, baz wiedzy, a nawet historii konwersacji. Badania pokazuja, ze moze to zmniejszyc rozmiar promptow nawet o 70%.

Izolacja

Uzywaj podagentow do konkretnych zadan, aby kontekst kazdego agenta pozostal skoncentrowany. Zamiast dawac jednemu agentowi 20 umiejetnosci, stworz zespol 5 agentow z 4 umiejetnosciami kazdy. Kazdy agent utrzymuje szczuple okno kontekstu, a zespol lacznie pokrywa pelny zestaw mozliwosci.

Podsumowanie

Sposob, w jaki frameworki agentow AI wstrzykuja umiejetnosci do kontekstu, jest jedna z najbardziej konsekwentnych decyzji architektonicznych w projektowaniu agentow – a jednak rzadko jest omawiany na tym poziomie szczegolowosci.

Branra wyraznie zbiera sie w kierunku stopniowego ujawniania jako preferowanego wzorca dla agentow ogolnego przeznaczenia, przy czym Claude Code, LangChain Deep Agents i OpenAI niezaleznie doszli do podobnych architektur trzywarstwowych. Tymczasem specjalistyczne wzorce, takie jak wyszukiwanie semantyczne (AutoGen, Voyager) i skompilowane wstrzykiwanie (DSPy), obsluguja wazne nisze, ktorych samo stopniowe ujawnianie nie adresuje.

Dla praktytkow budujacych systemy agentowe dzisiaj, kluczowy wniosek jest taki, ze wstrzykiwanie umiejetnosci nie jest problemem jednorozmiarowym. Odpowiednie podejscie zalezy od roli agenta, liczby potrzebnych umiejetnosci, tego, czy musi uczyc sie z czasem, oraz tolerancji na kompromisy miedzy kosztami tokenow a niezawodnoscia.

Najbardziej solidne systemy produkcyjne prawdopodobnie polacza wiele wzorcow – always-on dla kluczowych mozliwosci, stopniowe ujawnianie dla rozszerzonych umiejetnosci i wyszukiwanie semantyczne dla skumulowanej wiedzy – tworzac agentow, ktorzy sa zarowno efektywni, jak i ekspertami.