Modele kontra agenty: przesuwająca się granica

Oto wzorzec, który przeżył każdy, kto buduje z agentami AI. Spędzasz tygodnie na inżynierowaniu rusztowania wokół modelu — starannego łańcucha promptów wymuszającego planowanie krok po kroku, warstwy routingu dobierającej właściwe narzędzie, kodu spajającego, który rozkłada duże zadanie na małe. Działa. Wdrażasz to. Potem spada następny model, robi to wszystko natywnie, a Twoje sprytne rusztowanie nagle staje się martwym balastem, który musisz wyrwać.

To dzieje się raz za razem i rodzi naprawdę trudne pytanie architektoniczne — być może to pytanie architektoniczne ery agentowej: w miarę jak modele bazowe wchłaniają coraz więcej z tego, co frameworki agentów miały zapewniać, ile rusztowania wciąż ma znaczenie? Czy warstwa agenta to tymczasowa kula, którą model nieustannie połyka — czy część, która naprawdę kumuluje się w czasie?

To nie jest jałowa debata. Odpowiedź przesądza, gdzie powinieneś teraz lokować swój wysiłek inżynierski. Potraktujmy obie strony poważnie.

Dwie warstwy, jeden stos

Najpierw definicje, bo ta rozmowa tonie w nakładających się terminach — SDK, rusztowanie, framework, harness, agent. Cobus Greyling i inni włożyli realny wysiłek w ich rozplątanie, a istotne rozróżnienie jest proste. Są dwie warstwy:

Model. Surowa zdolność: rozumowanie, wiedza, planowanie, umiejętność wyboru i wywoływania narzędzi. To, co dostajesz z wag.
Rusztowanie wokół niego. Wszystko, co zamienia surowy model w agenta ukierunkowanego na cel — modularne prompty, pamięć, okablowanie narzędzi i orkiestracja, które ZBrain i inni opisują jako „rusztowanie” (scaffolding). To harness i pętla, o których pisaliśmy: niemodelowy runtime, który sprawia, że model niezawodnie robi rzeczy.

Cała debata „modele kontra agenty” to tak naprawdę pytanie o granicę między tymi dwiema warstwami — i co kluczowe, w którą stronę się ona przesuwa. Zdolności nie tkwią nieruchomo po jednej stronie. Migrują. A kierunek migracji to właśnie to, co jest sporne.

Argumentacja za tym, że „model połyka agenta”

Mocna wersja jednej strony, broniona stanowczo m.in. przez DevIQ, mówi, że model połyka agenta. Każda generacja frontierowego modelu wchłania zdolności, które wcześniej wymagały zewnętrznego rusztowania:

Planowanie i dekompozycja. Wczesne agenty potrzebowały rozbudowanych łańcuchów promptów, by zmusić model do rozbicia zadania na kroki. Nowsze modele planują natywnie, w pojedynczym wywołaniu, często lepiej niż ręcznie zbudowany łańcuch.
Wybór narzędzi. Logika routingu decydująca, którego narzędzia użyć, jest coraz bardziej zbędna — model po prostu wybiera poprawnie, mając dobre opisy narzędzi.
Wielokrokowe rozumowanie i wykonanie. Pętla think-act-observe, którą frameworki miały narzucać, staje się czymś, co modele robią wewnętrznie.

Implikacja jest niewygodna dla każdego, kto mocno zainwestował we framework: wiele rusztowania agentowego jest tymczasowych. Istnieje, by kompensować ograniczenie modelu, a w chwili, gdy ograniczenie znika, znika też powód istnienia rusztowania. Z tego punktu widzenia stawianie swojej architektury na rozbudowanym, ręcznie wykonanym procesie to obstawianie przeciwko jedynej rzeczy, która niezawodnie się poprawiała: samemu modelowi.

To realne i powracające zjawisko. Jeśli kiedykolwiek wyrwałeś łańcuch planowania, bo nowy model go nie potrzebował, czułeś przesuwanie się tej granicy. Zignoruj tę stronę, a będziesz dalej budować rusztowanie o okresie półrozpadu jednego wydania modelu.

Argumentacja za harness

Ale istnieje równie poważny kontrargument i to on wydaje nam się bardziej przekonujący co do tego, gdzie naprawdę leży dźwignia.

Pewien nurt prac z 2026 przeformułowuje pytanie jako skalowanie systemu kontra skalowanie modelu. Teza: skalowanie modelu (większe, mądrzejsze wagi) i skalowanie systemu (pamięć, routing, orkiestracja, weryfikacja, zarządzanie) to odrębne osie. To, że model staje się lepszy, samo z siebie nie daje Ci trwałej pamięci w długich przebiegach, koordynacji wielu agentów, śladu audytowego dla decyzji podlegającej regulacjom ani kroku weryfikacji, który wyłapuje pewne siebie błędy modelu. To właściwości na poziomie systemu. Pochodzą z harness, a nie z wag.

A oto część przeciwna intuicji: w miarę jak modele stają się bardziej zdolne i powierzasz im pracę o dłuższym horyzoncie, o wyższej stawce, wymagania na poziomie systemu nie maleją — one rosną. Bardziej autonomiczny agent potrzebuje więcej weryfikacji, nie mniej. Agent wykonujący godziny pracy potrzebuje bardziej wyrafinowanej pamięci i zarządzania kontekstem, nie mniej. Agent podejmujący doniosłe decyzje potrzebuje więcej zarządzania i observability, nie mniej. Argument brzmi, że harness musi wchłaniać zdolność najszybciej właśnie wtedy, gdy model się poprawia.

Więc obie rzeczy są prawdziwe naraz, i to czyni to naprawdę trudnym: model połyka niskopoziomowe rusztowanie (łańcuchy planowania, klej routingu), podczas gdy systemowy harness (pamięć, orkiestracja, weryfikacja, zarządzanie) staje się ważniejszy, nie mniej ważny. Granica nie przesuwa się jednorodnie w jedną stronę. Przesuwa się w górę stosu — pożerając warstwę mechaniczną, odsłaniając architektoniczną.

Konkretny przykład czyni ten podział oczywistym. Dwa lata temu skłonienie modelu, by niezawodnie rozbił „zrefaktoryzuj ten moduł” na uporządkowane podkroki, wymagało ręcznie zbudowanego promptu planującego — czystego rusztowania, dokładnie tego rodzaju, który model już połknął. Ale skłonienie trzech agentów, by zrefaktoryzowały trzy moduły równolegle, podzieliły się tym, czego każdy się nauczył, pogodziły sprzeczne edycje i wytworzyły ślad audytowy, któremu recenzent może potem zaufać? Żadne ulepszenie modelu nie daje Ci tego za darmo. To orkiestracja i weryfikacja — projekt systemu, który budujesz, który się kumuluje i którego regulowany klient będzie coraz częściej wymagał. Prompt planujący był jednorazowy. Orkiestracja to aktywo.

Soczewka Gorzkiej Lekcji

Najgłębsze ujęcie tego napięcia pochodzi od Ethana Mollicka, nawiązującego do słynnej „Gorzkiej Lekcji” (Bitter Lesson) Richa Suttona. Gorzka Lekcja, wyciągana wielokrotnie w historii AI, mówi, że ogólne metody wykorzystujące obliczenia i uczenie ostatecznie biją podejścia ręcznie zaprojektowane przez człowieka. Zastosowana tutaj: czy ogólne uczenie modelu ostatecznie pobije starannie zinżynierowane rusztowanie agenta?

Szczera odpowiedź Mollicka brzmi, że właśnie się tego dowiemy — i stawia to jako otwarte pytanie chwili: czy proces ma znaczenie? Jeśli Gorzka Lekcja obowiązuje do samego dna, to rozbudowany proces agentowy jest przegrywającym zakładem przeciwko skali, a model połyka niemal wszystko. Jeśli nie obowiązuje — jeśli istnieje nieredukowalna warstwa projektu systemu, której żadna ilość skali modelu nie wytwarza za darmo — to harness jest miejscem, gdzie żyje trwała wartość.

Nasz odczyt: Gorzka Lekcja jest realna i będzie dalej kasować niskopoziomowe rusztowanie, ale działa ona wewnątrz systemu, który wciąż trzeba zaprojektować. Lepiej wyuczony model czyni dobrze zinżynierowaną pętlę lepszą; nie pisze pętli, nie definiuje „skończone”, nie gwarantuje, że dane są poprawne, ani nie decyduje, co agentowi wolno robić. Gorzka Lekcja pożera sprytność. Nie pożera inżynierii.

Praktyczna reguła kciuka

Jeśli dziś podejmujesz decyzje architektoniczne, oto reguła, która z tego wszystkiego wypada: buduj rusztowanie tanie do usunięcia i inwestuj trwale w części, które przeżywają aktualizacje modelu.

Konkretnie:

Traktuj niskopoziomowe rusztowanie jako jednorazowe. Łańcuchy planowania, logikę routingu, promptową gimnastykę dla wymuszenia zachowania — buduj je lekko, oczekuj, że je wyrzucisz, i nie pozwól im skostnieć w Twojej architekturze. Każde z nich to zakład przeciwko następnemu modelowi, a ten zakład często przegrasz.
Inwestuj mocno w warstwy, które się kumulują. Ewaluacje, jakość danych, weryfikacja, architektura pamięci, observability i zarządzanie nie stają się przestarzałe wraz z wydaniem modelu — stają się bardziej wartościowe, w miarę jak powierzasz agentom więcej. Prace McKinseya nad skalowaniem agentowego AI w przedsiębiorstwie lądują w tym samym miejscu: trwałe fundamenty są organizacyjne i systemowe, a nie tkwią w konkretnym modelu czy frameworku.
Używaj soczewki trójwarstwowej. Jak argumentowaliśmy w naszym wpisie o loop engineeringu: adoptuj harness, inżynieruj loop, skaluj orkiestracją. Harness się utowarawia, model poprawia się pod Tobą — Twoja trwała przewaga to warstwa środkowa i górna, zaprojektowane z założeniem, że model będzie się dalej poprawiał.

Zespoły, które się parzą, to te, które budują fosę z modelo-kompensującej sprytności. Zespoły, które się kumulują, to te, których inwestycja staje się bardziej wartościowa za każdym razem, gdy model się poprawia.

Podsumowanie

Modele kontra agenty to nie pytanie z jednym zwycięzcą — to przesuwająca się granica, a umiejętnością jest wiedza, po której jej stronie budujesz. Model naprawdę połyka niskopoziomowe rusztowanie agentowe i będzie to robił dalej; obstawianie przeciwko temu to obstawianie przeciwko najbardziej niezawodnemu trendowi w tej dziedzinie. Ale systemowy harness — pamięć, orkiestracja, weryfikacja, zarządzanie — nie jest połykany. Staje się ważniejszy, bo zdolność, której nie możesz zaufać, zaudytować ani zatrzymać, nie jest zdolnością, którą możesz wdrożyć.

Buduj pod to. Uczyń swoje rusztowanie tanim do usunięcia, a swoją weryfikację, dane i orkiestrację trwałymi. Stawiaj na warstwy, które przeżywają następny model — bo zawsze będzie następny model.

To dokładnie ten rodzaj decyzji architektonicznej, w których pomagamy zespołom trafić w Inference Loops. Jeśli decydujesz, gdzie zainwestować w swój stos agentowy — i co zostawić jednorazowym — porozmawiajmy.