O czym jest ten film
- Główna teza: pytanie nie brzmi „który model jest najlepszy”, tylko „który model do którego zadania” — jeden uniwersalny model marnuje cenny limit na rutynie.
- Prosty model mentalny: trzy warstwy zadań — szybka (podstawowe czynności), zrównoważona (codzienna praca) i głęboka (złożone rozumowanie).
- W Hermes są trzy mechanizmy doboru modeli: model główny ustawiony na poziomie profilu, modele pomocnicze dla czynności wewnętrznych oraz delegacja (podagenty albo tablica Kanban).
- Modele pomocnicze — kompresja kontekstu, wybór umiejętności, tytuły sesji, narzędzia MCP — można oddać tanim lub lokalnym modelom i od razu oszczędzać tokeny.
- Nowa wtyczka Advanced Delegation (wymaga Hermes 22.5) odblokowuje dynamiczny routing: agent nadrzędny sam przydziela każdemu podagentowi model z przygotowanej mapy.
- Autor buduje trasę hybrydową: lokalna Gemma 4 26 A4B (szybka), lokalny Qwen 3.8 27B (zrównoważony) i chmurowy GPT-6 Astra z limitem intensywności rozumowania (głęboka).
- Test: trzy niezależne podagenty odpowiadają na to samo pytanie badawcze o bezpieczeństwo osobiste wobec ataków AI; czasy pracy to odpowiednio ok. 16, 19 i 2 minuty.
- Najlepszy raport dał model głęboki, drugi zrównoważony (znalazł dodatkowe dowody o MFA i odzyskiwaniu kont), a najsłabszy szybki — z zawyżoną tezą opartą na nieprecyzyjnym odwołaniu.
- Trasy profilowe pozwalają delegować do „specjalisty” z własnym modelem, umiejętnościami i kluczami, ale bez jego pamięci — pełny profil z kontekstem uruchamia dopiero Kanban, który dodatkowo zapewnia trwałość pracy.
- Na koniec: opcja „mieszanki agentów” (kilka modeli równolegle plus agregator) oraz drzewo decyzyjne — kiedy sięgnąć po modele pomocnicze, podagenty, profile, Kanban albo rady modeli.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Nie szukaj najlepszego modelu — zestaw modeli do klas zadań
Na czym polega: Potężny model rozwiązujący trudne zadania jest przerostem w rutynowej pracy. Zamiast jednego „mistrza wszystkiego” autor dzieli pracę na warstwę szybką, zrównoważoną i głęboką, a każdą obsługuje inny model.
Jak stosować: Zanim zaczniesz konfigurować cokolwiek, wypisz swoje typowe zadania i przypisz je do jednej z trzech warstw. Dopiero potem dobieraj modele — chmurowe, lokalne albo mieszane.
Na co uważać: Granice warstw muszą wynikać z twojej realnej pracy, nie z rankingów modeli. Sprzęt, priorytety (szybkość, koszt, prywatność) i rodzaj zadań sprawiają, że cudza konfiguracja u ciebie nie zadziała.
2.Pierwszy krok: modele pomocnicze
Na czym polega: Agent domyślnie używa modelu głównego także do czynności wewnętrznych — np. wybierania umiejętności czy kompresowania kontekstu po długiej rozmowie. W Hermesie każdą z nich można przypisać osobnemu, tańszemu modelowi, bez tworzenia nowych agentów.
Jak stosować: W ustawieniach modeli pomocniczych przełącz kompresję, hub umiejętności, tytuły sesji i identyfikację narzędzi MCP na mały model lokalny. To najprostszy sposób na odciążenie limitu chmurowego.
Na co uważać: Zbyt słaby model przy kompresji może zatrzeć szczegóły długiej rozmowy. Przetestuj go na własnych, naprawdę długich sesjach, zanim uznasz konfigurację za domyślną.
3.Opis „kiedy używać” decyduje o jakości routingu
Na czym polega: W wtyczce Advanced Delegation każda trasa modelowa ma pole opisujące, kiedy z niej korzystać (np. „szybkie wyszukiwania i wstępna analiza”). Agent nadrzędny podejmuje decyzje o przydziale właśnie na podstawie tych opisów.
Jak stosować: Pisz kryteria krótko i jednoznacznie: „jakość ważniejsza niż szybkość, ale wciąż zwięzle”, „złożone rozumowanie, tematy wieloznaczne”. Uniknych ogólników typu „mniejsze zadania”.
Na co uważać: Dziedziczenie ustawień od agenta głównego jest przy trasach wyłączone — trzeba świadomie ustawić dostawcę, model, intensywność rozumowania i szybkość dla każdej trasy osobno.
4.Drogi model rozumowania — oszczędnie i z limitem
Na czym polega: Autor trzyma agenta głównego na GPT 6.1 Soul (ok. jedna piąta kosztu Astry), a na trasę głęboką deleguje do GPT-6 Astry — dodatkowo z limitem intensywności rozumowania, żeby zlecenie nie „rozpędziło się” i nie pochłonęło całego limitu.
Jak stosować: Drogi model włączaj tylko przez wyraźnie opisaną trasę głęboką i ograniczaj poziom rozumowania do faktycznie potrzebnego.
Na co uważać: Zbyt niski limit obniży jakość dokładnie tam, po co sięgałeś po mocny model. Trzeba znaleźć próg, a nie ustawiać wartości na sztywno raz na zawsze.
5.Hybryda lokalne plus chmura: co może czekać, niech czeka
Na czym polega: Modele lokalne są darmowe i prywatne, ale wolne — w teście raport powstawał 16–19 minut, wobec 2 minut w chmurze. Dlatego dobrze sprawdzają się w pracy w tle, np. gdy agent-bibliotekarz nocą rozbudowuje twoją wiki.
Jak stosować: Zadania bez presji czasu (budowanie bazy wiedzy, nocne przebiegi, porządkowanie plików) wysyłaj na modele lokalne; pilne i wymagające głębi zostaw chmurze.
Na co uważać: Nie dawaj modelom lokalnym zadań na wczoraj — jeśli wynik potrzebujesz za minutę, wolny model zniweczy całą oszczędność. Wyjątek: gdy prywatność jest bezwzględnym priorytetem.
6.Równoległe, niezależne analizy podnoszą jakość
Na czym polega: Trzy podagenty na tym samym pytaniu poszły innymi ścieżkami — już same zapytania wyszukiwawcze były różne. Porównanie wyników działa jak dodanie krytyka do procesu badawczego: widać, co się pokrywa, a co jest zaszumione.
Jak stosować: W poleceniu dla agenta nadrzędnego zapisz wprost: podagenty pracują niezależnie, po zakończeniu agent porównuje raporty obok siebie i dopiero potem syntetyzuje.
Na co uważać: Modele zbyt do siebie podobne mogą powielać te same błędy — różnorodność modeli w mapie jest tu wartością samą w sobie.
7.Szybkim modelom bliżej do nadinterpretacji
Na czym polega: Najsłabiej wypadł model szybki: mniej szczegółów i „ważne zawyżenie tezy” — teza oparta na nieokreślonym odwołaniu i przesadzona względem tego, co realnie wynika ze źródeł.
Jak stosować: Wyniki szybkiej trasy traktuj jako materiał wstępny. Sprawdzaj kluczowe odniesienia, zanim coś z nich wyciągniesz albo przekażesz dalej.
Na co uważać: Overclaim bywa trudny do wychwycenia gołym okiem, bo raport brzmi pewnie. Jeśli weryfikacja nie wchodzi w grę, rozważ poniższą radę modeli.
8.Rada modeli: dwa słabsze w równoległości zamiast jednego lepszego
Na czym polega: Opcja „mieszanki agentów” (mixture of agents) łączy się nie z pojedynczym modelem, lecz z ich zestawem: kilka modeli odpowiada jednocześnie, a wyniki trafiają do agregatora. Dwa modele niższej klasy, pracujące niezależnie i porównane przez agregator, mogą zbiorowo zbliżyć się do jakości droższego modelu.
Jak stosować: Tam, gdzie szybka trasa zawodzi (jak przy above overclaim), ustaw np. Gemmę i model typu Qwen jako dwa równoległe „głosy”, a jako agregator trzeci model. To też sposób na podniesienie jakości pracy lokalnej bez sięgania po chmurę.
Na co uważać: Poprawa nie jest gwarantowana — autor sam podkreśla, że to kierunek do własnych eksperymentów, a nie sprawdzony przepis.
9.Profil zamiast modelu, gdy potrzebne są narzędzia i klucze
Na czym polega: Trasa profilowa pozwala orkiestratorowi delegować do podagenta-profilu (np. badacza), który wnosi własny model, umiejętności, klucze i łączniki — choćby dostęp do bazy artykułów przez Consensus MCP.
Jak stosować: Jeśli zadanie wymaga specjalistycznych narzędzi, wybierz profil, nie sam model. Opisz w trasie, kiedy dany profil ma być używany — analogicznie jak przy trasach modelowych.
Na co uważać: Podagent-profil nie dostaje pamięci ani kontekstu tego profilu — z dokumentów przekazywane są co do zasady tylko pliki konfiguracyjne. Wszystko, czego podagent ma potrzebować, musi przekazać orkiestrator. Do jednorazowych zadań to wystarcza; gdy liczy się pamięć, potrzebny jest Kanban.
10.Kanban, gdy liczy się trwałość — ale pilnuj kosztów triage’u
Na czym polega: Praca podagentów znika razem z sesją — do zakończonego agenta nie da się wrócić. Tablica Kanban uruchamia pełne profile z pamięcią i kontekstem, a każdy krok zapisuje jako kartę w osobnej bazie, więc historię można przejrzeć w każdym momencie.
Jak stosować: Wieloetapowe procesy z wyzwalaczami, porównaniami i zależnymi krokami buduj w Kanbanie. Jego najdroższe operacje — automatyczna klasyfikacja i dekompozycja zadań — przypisz tanim lub lokalnym modelom z niską intensywnością rozumowania.
Na co uważać: W testach autora to właśnie automatyczna dekompozycja zadań pochłaniała najwięcej tokenów. Pozostawiona na drogim modelle, potrafi zjeść budżet szybciej niż sama praca merytoryczna.
Redakcyjne tłumaczenie
Jeden model do wszystkiego? Lepiej dobierz model do zadania
Wszyscy pytają o najlepszy model. A właściwie po co w ogóle używać jednego modelu do wszystkiego? Modele faktycznie się różnią — i dobrze, bo nie muszą być wszechstronne. Potężny model świetnie sprawdzi się w zadaniu wymagającym głębokiego rozumowania, ale w rutynowej pracy to strzelanie z armaty do muchy: zużywamy cenny limit na czynności, które niczego takiego nie wymagają, a potem brakuje go tam, gdzie naprawdę jest potrzebny. Zamiast tego można poskładać zestaw modeli dopasowany do pracy, którą faktycznie wykonujemy.
Callum, znany w sieci jako Wanderloots, opowiada o routingu modeli — automatycznym kierowaniu zadań do właściwych modeli — oraz o delegowaniu pracy między agentów. Demonstruje to na Hermesie (Informacja dodatkowa: Hermes — aplikacja do pracy z agentami AI, z systemem profili, podagentów i tablicy zadań Kanban), ale sama zasada dotyczy każdego agenta. Najłatwiejszy sposób myślenia o tym podziale to trzy warstwy: szybka — do prostych czynności, zrównoważona — do codziennej pracy, i głęboka — na momenty, gdy trzeba więcej rozumowania. Modele mogą pochodzić od różnych dostawców, działać lokalnie albo stanowić dowolną mieszankę obu światów. Plan odcinka: przegląd opcji routingu w Hermesie, konfiguracja trzech tras, test na tym samym pytaniu badawczym z modelami lokalnymi i chmurowymi, porównanie wyników oraz wskazówki, jak całość dopasować do własnych potrzeb — wraz z dobrymi praktykami i bardziej zaawansowanymi przepływami pracy.
Warstwy modeli zna każdy, kto korzystał z ChatGPT, Claude’a czy Gemiego. Różnica jest taka, że przy routingu nie jesteśmy skazani na jednego dostawcę ani same modele chmurowe — do gry można wpuścić modele lokalne. Autor na przykład uruchamia je przez narzędzie Lemonade na osobnym komputerze i łączy je z modelami chmurowymi, sam wybierając, które są dostępne do jakich zadań. Co działa u niego, niekoniecznie zadziała u ciebie: sprzęt, rodzaj zadań i to, czy ważniejsza jest szybkość, jakość, koszt czy prywatność, przesądzą o tym, które modele mają sens w twoim przepływie pracy. Nie chodzi więc o to, który model jest najmocniejszy, lecz o to, która kombinacja modeli naprawdę dowiezie robotę. Celem odcinka jest pokazanie, jak te elementy składają się w całość, żeby każdy mógł przeprowadzić własne eksperymenty i znaleźć konfigurację dla siebie.
Trzy drogi: model główny, modele pomocnicze, delegacja
W Hermesie pierwszą opcją jest oczywiście zwykły wybór modelu głównego na dolnym pasku — można wskazać model oraz poziom rozumowania i szybkości. To samo sterowanie znajdziemy w ustawieniach, gdzie definiujemy model główny każdego profilu oraz tam, gdzie można zmienić dostawcę, także listę modeli zapasowych — przydatną zwłaszcza przy niestabilnym internecie albo pracy lokalnej, bo gdy jeden model odpuści, wchodzi drugi.
Istotne jest co innego: podczas zwykłej rozmowy wybieramy tylko jeden model naraz — albo chmura, albo lokalnie. Dopiero routing wykraczający poza model główny daje większą swobodę: decydujemy, skąd modele pochodzą, na jakim poziomie działają i jak współpracują. W sumie mamy trzy mechanizmy. Model główny — ustawiany na poziomie profilu. Modele pomocnicze — drobne zadania sterowane per akcja, każde konfigurowane niezależnie. I wreszcie delegacja — przez podagentów (z routingiem modeli albo profilowym) albo bezpośrednio przez Kanban.
Podłączamy modele lokalne
Zanim zaczniemy cokolwiek delegować, potrzebujemy po prostu większej liczby modeli, więc autor podłącza do systemu kolejny model lokalny — po to, żeby zbudować hybrydową konfigurację chmura plus lokalnie. W profilu badacza Hermes potrafi od razu uruchomić lokalny model dopasowany do możliwości komputera, a wbudowana paczka llama.cpp (silnik napędzający lokalne modele) sprawia, że widać, co realnie zadziała na danym urządzeniu. Lokalne modele robią się zresztą coraz lepsze. Ale autor nie korzysta dziś z wbudowanej opcji — dodaje nowy, własny punkt końcowy. Jeden, przez Ollamę, działa już na jego Macu Studio; nowy uruchomi przez Lemonade na urządzeniu AMD Halo. Po kliknięciu „nowy endpoint”, nazwaniu go „Halo lemonade” i zapisaniu system potwierdza, że punkt jest osiągalny i widzi wszystkie modele pobrane na urządzeniu. Autor wybiera dość szybką Gemmę 4 26 A4B. Od tej chwili — obok subskrypcyjnych modeli chmurowych — ma dostęp do wszystkiego, co serwuje serwer Lemonade na Halo. Więcej modeli znaczy więcej opcji routingu.
Modele pomocnicze: tanie wnętrze agenta
Pierwsza możliwość routingu dotyczy zadań pomocniczych — takich, które domyślnie wykonuje model główny. Chodzi o codzienne, wewnętrzne czynności agenta. Nie ma sensu, żeby frontierowy model chmurowy palił tokeny na wyszukanie dostępnej umiejętności (ang. skills — gotowe pakiety możliwości, które agent dobiera do zadania). Można to przepiąć np. na Gemmę 4 26 A4B i od tej pory przy doborze umiejętności pracuje model pomocniczy, a nie główny.
Bardzo pomocna okazuje się też kompresja kontekstu. Wystarczy naprawdę mały model — autor wskazuje Qwen 3.5 z 9 miliardami parametrów — który pracuje błyskawicznie. Gdy rozmowa robi się długa i trzeba streścić kontekst, zamiast drogiego modelu chmurowego robi to model lokalny, praktycznie za darmo. Limit zostaje zachowany na właściwą pracę, a nie na jej streszczanie. Podobnie można zlecić lokalnemu modelowi nadawanie tytułów sesji czy identyfikowanie narzędzi MCP (Informacja dodatkowa: MCP — Model Context Protocol, otwarty standard pozwalający agentom AI korzystać z zewnętrznych narzędzi i źródeł danych), a także uruchamianie podagenta-recenzenta. To najprostszy wstęp do routingu: czynności, które agent wykonuje nieustannie i które kosztują, schodzą na tańszy lub szybszy model — bez tworzenia żadnych nowych agentów. Co wybrać: chmurę, lokalnie czy mieszankę — sprawa indywidualna, ale warto przejrzeć całą listę zadań pomocniczych, bo to jeden z najlepszych sposobów na realną oszczędność tokenów, a czasem i na podniesienie jakości pracy.
Podagenty i wtyczka zaawansowanej delegacji
Czas na delegację właściwą. Podagenty to szczególny jej rodzaj: agent nadrzędny zleca pracę agentom podrzędnym, a te oddają mu postępy. W domyślnym trybie — wbudowanym narzędziu delegowania zadań — podagenty działają albo na modelu agenta głównego, albo na jednym, wskazanym z góry modelu. Kontrola jest więc minimalna. Dopiero nowa wtyczka Advanced Delegation odblokowuje prawdziwy, dynamiczny routing: definiujemy listę, a właściwie mapę modeli, i agent nadrzędny sam przydziela każdyemu podagentowi właściwy model. Druga droga to trasy profilowe — podagent uruchamiany jako jeden z profili, na przykład badacz, który wnosi pełnię swoich możliwości badawczych.
Instalacja wtyczki jest banalna — wystarczy kliknąć „instaluj” (warto przy tym zajrzeć do katalogu wtyczek w sekcji możliwości, żeby zobaczyć opis: Hermes zyskuje tryby doboru modeli do typów zadań, jak szybki, głęboki czy enkoder). Warunek: Hermes w wersji 22.5 lub nowszej, bo dopiero ona udostępnia wtyczkowego dostawcę delegacji. Wtyczka powstała dosłownie kilka dni wcześniej i jest oficjalna — pochodzi od Nuke’s Research, co dodaje autorowi spokoju. Po instalacji w profilu badacza i restarcie bramki w sekcji podagentów pojawiają się opcje tras modelowych i profilowych. Uwaga: nie da się używać obu naraz — orkiestrator nie może delegować jednocześnie modeli i profili, przynajmniej na razie. Trzeba też pamiętać o włączeniu samego narzędzia delegowania zadań, bo to ono zostaje rozszerzone przez wtyczkę.
Trzy trasy: szybka, zrównoważona, głęboka
Pierwsza trasa: nazwa „szybka”, opis użycia — szybkie wyszukiwania, streszczenia, wstępna analiza. Jako dostawca — serwer Halo, jako model — testowana już Gemma 4 26 A4B. Druga: „zrównoważona” — kiedy jakość jest ważniejsza niż szybkość, ale wciąż chcemy działać sprawnie; tu z Hala schodzi znacznie mocniejszy Qwen 3.8 z 27 miliardami parametrów. Trzecia: „głęboka” — jakość, złożone rozumowanie, tematy wieloznaczne, dokładność; w celu pokazania hybrydy autor wskazuje tu ChatGPT i model Astra. Całość wygląda tak: agent główny pracuje na GPT 6.1 Soul, który kosztuje około jedną piątą ceny Astry, a gdy naprawdę potrzebne jest głębokie rozumowanie, przechodzi na Astrę — z limitem intensywności rozumowania ustawionym na „high”, żeby zlecenie nie rozpędziło się do trybu najszybszego i nie pochłonęło ogromnej części limitu. Trzy trasy gotowe: rutyna i codzienna praca lecą na modele lokalne i oszczędzają kredyty, a jakość głęboka czeka na wyraźne zapotrzebowanie.
Test: trzy podagenty, jedno pytanie o bezpieczeństwo
Test polega na tym, że badacz ma wypluć z siebie trzech podagentów działających równocześnie w trybie zaawansowanej delegacji. Pytanie badawcze: jakie kroki może podjąć przeciętny człowiek, żeby lepiej chronić się przed przyszłymi atakami z użyciem AI? Temat jest ostatnio głośny po kilku poważnych włamaniach, a autor chce zrozumieć, czego spodziewać się na styku AI i cyberbezpieczeństwa, żeby podjąć realistyczne działania już teraz. Polecenie: trzej agenci — szybki, zrównoważony i głęboki — pracują całkowicie niezależnie, z instrukcją, jak szukać relevantnych artykułów naukowych; agent nadrzędny czeka na raporty, ocenia je niezależnie od siebie, a na koniec przedstawia porównanie obok siebie i syntezę.
Już na starcie widać działanie modelu pomocniczego: tytuł sesji zmienia się z „bez nazwy” na „porównanie modeli badających osobiste bezpieczeństwo AI” — dokładnie ta czynność, którą też można by przepiąć na model lokalny. Delegacja rozchodzi się zgodnie z mapą: zadanie pierwsze dostaje Gemma 4, drugie Qwen 3.8, trzecie GPT-6 Astra. Warto dodać, że autor używa własnej umiejętności zbudowanej dla agenta-badacza (rozdawał ją w wcześniejszym materiale o ulepszaniu zespołu agentów).
Wątek sponsora: Consensus MCP
Póki podagenty pracują — oba modele lokalne właśnie zaczęły przeszukiwanie bazy — czas na sponsora odcinka. Consensus pozwala autorowi i jego agentowi przeszukiwać miliony artykułów naukowych i wyciągać te najbardziej relevantne i wiarygodne. Consensus MCP to darmowe narzędzie z dwiema funkcjami: wyszukiwanie zwraca ranking artykułów w jednym zapytaniu, po czym agent czyta je i pisze odpowiedź; natomiast „wątki” (threads) oddają całe pytanie badawcze wyspecjalizowanemu agentowi Consensus. Autor równolegle do podagentów odpala właśnie taki wątek — jego Hermes tworzy go, bada i generuje raport, dobierając najlepsze źródła do konkretnego pytania. Wątek widać obok, można do niego wrócić bezpośrednio w aplikacji Consensus, zapisać go do biblioteki i obejrzeć wizualizację artykułów wraz z ich powiązaniami. Jego zdaniem to znakomity sposób na podniesienie jakości agentów lokalnych przez lepszą jakość informacji, którą potrafią wydobyć. W testowanym układzie podagenty korzystają z funkcji wyszukiwania i same robią syntezę ze znalezionych artykułów. Narzędzie jest darmowe, więc łatwo sprawdzić, ile daje samo dodanie go jako łącznika w Hermesie czy innym agencie.
Czternaście minut lokalnie: koszt szybkości, zysk prywatności
Po powrocie podagenty wciąż liczą — minęło około trzynastu minut, co przy modelach lokalnych nie dziwi. I to jest właśnie argument za systemem hybrydowym: pracę, która może się odbywać w tle, odsyła się na modele lokalne i wraca po raport. Przykład: agent-bibliotekarz, który co noc sprawdza, czy pojawiły się nowe pliki, i dalej rozbudowuje twoją wiki — tego nie trzeba pilnować. Autor w tym czasie robi coś innego.
Ciekawie wygląda drzewo uruchomionych agentów (dostępne po kliknięciu w agentów na dole). Widać w nim, że zapytania wyszukiwawcze różnią się między modelami: jeden szukał „indywidualnych zabezpieczeń przed socjotechniką i deepfake’ami z użyciem AI”, drugi — „ataków phishingowych i socjotechnicznych napędzanych generatywną AI”. Różne modele inaczej patrzą na ten sam problem, więc routing z późniejszym porównaniem daje elastyczność — to trochę jak wprowadzenie krytyka do procesu badawczego: zamiast jednego wyniku masz dwa, zestawione obok siebie, co pomaga upewnić się co do jakości.
Szybka trasa kończy jako pierwsza, a zrównoważony Qwen 3.8 okazuje się niewiele wolniejszy — gdyby autor powtarzał test, sięgnąłby po szybszy model na trasie szybkiej. Kompletny czas przebiegu: około 16,1 minuty, 19,1 minuty i 2 minut. Różnica między chmurą a lokalnie widać gołym okiem — ale z drugiej strony: można przecież wysłać pomysł na raport, zająć się czymś innym i wrócić po godzinie. Lokalny model jest darmowy i prywatny (dane nie opuszczają urządzenia), płaci się za to szybkością. Dlatego warto budować trasy tak, by lokalne modele pracowały tam, gdzie to możliwe, a chmura pozostawała w zanadrzu — optymalna jest hybryda, chyba że prywatność wymaga pełnej lokalności.
Werdykt i synteza
Agent nadrzędny (GPT 6.1 Soul) przegląda raporty, porównuje je i ocenia. Werdykt: agent C — głęboki — przygotował najmocniejszy raport, z najlepszym doborem dowodów, najczytelniejszym rozdzieleniem ustaleń od wnioskowania i najbardziej użytecznymi poradami dla przeciętnej osoby, do tego w najkrótszym czasie. Porównanie nie jest do końca uczciwe, bo to był GPT-6 Astra, jeden z najlepszych modeli na świecie — ale o to chodziło: o dobry punkt odniesienia dla modeli lokalnych. Agent B — zrównoważony — wszedł na drugie miejsce, bo odkrył dodatkowe dowody dotyczące MFA (uwierzytelniania wieloskładnikowego) i odzyskiwania kont. Agent A — szybki — był trzeci, z uboższymi szczegółami i zawyżoną tezą opartą na jednym ze źródeł. Wszyscy trzej wystartowali równolegle i jedyną różnicą była przydzielona trasa modelowa.
Ciekawostka: raporty B i A, a także B i C, częściowo pokrywały się artykułami — czyli model zrównoważony trafił na część tych samych źródeł co model stanu sztuki, czego modelowi szybkiemu się nie udało. Głównym grzechem szybkiej trasy było właśnie „ważne zawyżenie”: nieokreślone odwołanie i przesada wobec czegoś, co w rzeczywistości ma charakter raczej matematyczny.
Co z tego wynika dla zwykłego człowieka
Finalna synteza — co ma zrobić przeciętna osoba? Część rad wydaje się oczywista, ale warto je sobie przypomnieć w dobie głośnych włamań: zabezpiecz pocztę e-mail; dokładnie weryfikuj wnioski o charakterze konsekwencyjnym — wszystko, co dotyczy pieniędzy, haseł i kodów logowania; wyeliminuj używanie tych samych haseł w wielu miejscach; włącz automatyczne aktualizacje (to duży temat — po ostatnim ataku na PHP absurdalnie wiele systemów stało się podatnych, ale jeśli hosting aktualizował się sam, проблема została zażegnana niemal natychmiast); rób kopie zapasowe; i wreszcie ograniczaj niepotrzebną ekspozycję oraz uprawnienia AI. To ostatnie zdaniem autora będzie coraz ważniejsze, bo agenci będą robić za nas coraz więcej — powinny działać na zasadzie ścisłego „wiem, co muszę wiedzieć, i mam dostęp tylko do tego, co potrzebne”. Nie dawaj agentowi dostępu do wszystkiego.
A co dalej z samym eksperymentem? Autor następnym razem przetestowałby szybszy model na trasie szybkiej, bo 16 minut to wciąż niewiele szybciej niż zrównoważone 20 minut, które zresztą dały przyzwoity efekt. Gdy już wiadomo, co realnie poprawia jakość i tempo, można zdecydować, czy drogi model głęboki jest potrzebny przy każdym przebiegu — czy może lepiej eskalować: gdy dwa raporty są ze sobą w konflikcie, posłać sprawę do trzeciego agenta, który je zaudytuje, mniej więcej tak, jak zrobił to tutaj agent oceniający.
Trasy profilowe: specjalista z własnym modelem, ale bez pamięci
Druga opcja do przetestowania to trasy profilowe. Zamiast wywoływać podagentów z różnymi modelami, orkiestrator może wywołać podagenta będącego jednym z profili — wyspecjalizowanego badacza, bibliotekarza czy agenta do kodu. Idea jest spokrewniona z trybem botów, w którym agenty komunikują się ze sobą w zespołach i czatach grupowych; tutaj jednak to orkiestrator uruchamia podagenta-profil badacza, a kluczowe jest to, że badacz wnosi własny model główny, własne umiejętności i klucze — na przykład własny łącznik Consensus MCP. Konfiguracja wygląda podobnie do tras modelowych: wskazujemy listę profili, jako które podagenty mogą wystartować (badacz, bibliotekarz prowadzący wiki…), i opisujemy, kiedy ich używać.
Jest jednak zasadnicze ograniczenie: podagent-profil nie wnosi własnego kontekstu. Dostaje „duszę” badacza — konfigurację jego osobowości i sposobu pracy — ale nie jego pamięci. Cały kontekst, poza — o ile autor dobrze pamięta — plikami agents.md i soul.md, musi przekazać orkiestrator. Jeśli zadanie jest jednorazowe i wystarczy nam „jakiś badacz”, taki delegowany podagent w zupełności wystarczy. Gdy jednak potrzebujemy prawdziwej pamięci profilu budowanej miesiącami, wchodzimy w Kanban.
Kiedy zamiast podagentów — Kanban
Kanban to finalna forma delegacji: pełnoprawna orkiestracja, w której — na przykład — agent orkiestrator deleguje do konkretnych profili, ale każdy z nich działa jako kompletny profil, ze wszystkimi wspomnieniami i kontekstem danego pracownika, w obrębie systemu Kanban. Sprawdza się tam, gdzie potrzebnych jest więcej powiązanych akcji: rozmaite wyzwalacze, wyniki, porównania.
Kanban ma jeszcze jedną przewagę nad pojedynczymi podagentami: trwałość. Gdyby Hermes przerwał teraz pracę, dorobek testowego podagenta przepadłby — nie ma trwałego zapisu. W Kanbanie każda czynność tworzy kartę, a postęp ląduje w osobnej bazie danych; do zakończonego podagenta nie da się już wrócić (w sekcji agentów zostaje tylko lista), natomiast w Kanbanie można przejrzeć każdą pojedynczą akcję i każdy raport. Przy bardziej złożonych przepływach pracy to rzeczywiście ma znaczenie.
Najdroższe kroki Kanbanu przepisz tanim modelom
Wróćmy na moment do modeli pomocniczych — tym razem tych konkretnie dla Kanbana. Klasyfikator zadań (triage specifier) to wyspecjalizowany agent, który rozpoznaje zadania na tablicy i rozdziela je do właściwych profili; dekompozytor zadań rozbija trzaskane zadanie na podzadania i deleguje dalej. W praktyce wygląda to tak: włączamy automatyczną dekompozycję zadań z triage’u, dodajemy nową kartę — i dekompozytor sam wskazuje, kto odpowiada za jej realizację. W poprzednich testach autora to właśnie automatyczna dekompozycja okazała się największym pożeraczem tokenów. Zamiast marnować je na model frontierowy, można tę czynność przypisać podłączonemu modelowi lokalnemu: nawet gdy orkiestrator pracuje na Astrze, klasyfikację może prowadzić tani i szybki model (np. Luna) z niską intensywnością rozumowania — i to oszczędza mnóstwo kredytów.
Rada modeli zamiast pojedynczego głosu
Ostatnia funkcja: „mieszanka agentów”. Zamiast łączyć się z jednym modelem, łączymy się ze swego rodzaju radą modeli — kilka z nich odpowiada jednocześnie, a wyniki wracają do orkiestratora. Najciekawsze możliwości autor widzi w połączeniu z modelami lokalnymi: zamiast jednego świetnego modelu w rodzaju GPT 6.1 Soul można postawić dwa słabsze, które pracują niezależnie i krzyżowo weryfikują swoją pracę — a to zbiorowo może podnieść jakość tego, co trafia do agregatora.
Przykład zastosowania: główną wadą szybkiej trasy było ważne zawyżenie tezy przez nieokreślone odwołanie. Zamiast trzymać na trasie szybkiej samą Gemmę 4 26 A4B, można zbudować mieszankę agentów: pierwszy głos — Gemma, drugi — model typu Qwen albo Bonsai, a agregator — Gemini 4, ponownie wersja 26-miliardowa. Szybka trasa odpala się wtedy równolegle w dwóch wariantach, a wyniki porównuje się po fakcie. Autor zastrzega, że to przykłady do własnych testów, ale to realny kierunek, żeby lokalne modele zyskały na jakości przez samą zmianę trasy na mieszankę agentów.
Drzewo decyzyjne: co wybrać
Na koniec krótkkie drzewo decyzyjne.
Pytanie pierwsze: czy to praca wewnętrzna? Jeśli tak — modele pomocnicze. Zacznij od kompresji kontekstu, hubu umiejętności, a przy Kanbanie także od klasyfikatora i dekompozytora zadań. Kilka takich czynności przepisanych na modele lokalne albo tanie potrafi realnie odciążyć budżet, a niekiedy i skrócić pracę.
Pytanie drugie: czy potrzebny jest trwały, wieloetapowy przepływ pracy? Jeśli tak — Kanban, z jego kartami i profilami współpracującymi na tablicy. Trwałość jest kluczowa: karty zapisują się w osobnej bazie, więc do każdej akcji i raportu można wrócić także po zakończeniu operacji. Podagent w tym czasie po prostu znika.
Pytanie trzecie: czy zadanie wymaga specjalisty z własnymi umiejętnościami, narzędziami lub kluczami? Jeśli tak — trasy profilowe zamiast modelowych. Orkiestrator deleguje do profilu badacza i tym samym dostaje dostęp do dodatkowych wtyczek i łączników, choćby Consensus MCP. Ale jeśli potrzebna jest pamięć badacza, rozbudowywana z czasem — znowu Kanban, bo tylko on uruchamia pełny profil z całym kontekstem.
Pytanie czwarte: czy niezależna analiza poprawi wynik? Jeśli tak — zwykła delegacja albo mapa modeli z wtyczki zaawansowanej delegacji: kilka agentów w równoległości, a agregator lub agent nadrzędny krzyżowo porównuje ich wyniki.
Dopiero na końcu dochodzi kwestia prywatności: lokalnie, w chmurze czy hybrydowo? Tak czy inaczej można oszczędzać limit i ustalać priorytety — to, co nie musi powstać szybko, może pójść na wolniejsze modele lokalne, zachowując prywatność i zerowy koszt. Kwestia gustu i testów.
Zakończenie
Cel nie polega na tym, żeby używać najmocniejszego modelu do wszystkiego. Cel to właściwa inteligencja do właściwej pracy — i kombinacja, która rozwiązuje twoje własne problemy. Autor przypomina o darmowym artykule towarzyszącym (link w pierwszym komentarzu), w którym opisuje modele z odcinka, swój sposób myślenia o routingu modeli i profilowym oraz to, jak odnieść te wybory do różnych wielkości pamięci RAM. Wybór modelu to jednak dopiero początek: trzeba jeszcze zdecydować, jaki kontekst dostanie każdy profil, żeby miał wszystko, czego potrzebuje do zadania. W następnym odcinku autor zajmie się właśnie kontekstem — jego poziomami i sposobem, w jaki warto go porządkować, by przepływ pracy agentów był bardziej efektywny. Na koniec podziękowania dla widzów i członków, dzięki którym materiały mogą pozostawać darmowe.