O czym jest ten film
- Model AI sam w sobie to „mózg w słoju”: nie pamięta, nie widzi plików, nie działa i nie sprawdza efektów. Realną pracę wykonuje jego otoczka — tzw. harness (dosłownie „uprząż”).
- Claude Code i Codex to nie modele, lecz uprzęże: Anthropic opakowuje w nią rodzinę Claude (m.in. Mythos, Fable, Opus, Sonnet, Haiku), OpenAI — modele serii ChatGPT (GPT-6, GPT-5).
- Ten sam model w różnych uprzężach wypada zupełnie inaczej — badania pokazują duże przyrosty wydajności bez dotykania samego modelu.
- Zwykłe okno czatu to również uprząż — najprostsza z możliwych; większość dzisiejszych narzędzi AI wyrosła właśnie z okienek rozmowy.
- Postęp AI biegnie dwoma torami naraz: inteligencja modeli i jakość uprzęży. Rekordy w benchmarkach bywają zasługą lepszej oprawy, a nie „mądrzejszego mózgu”.
- Wokół modelu działa pięć elementów uprzęży: kontekst, pamięć, narzędzia, weryfikacja i uprawnienia — plus sandbox jako bezpiecznik.
- Kontekst (np. pliki CLAUDE.md czy AGENTS.md) buduje się raz i oszczędza niekończącego się dopisywania tych samych instrukcji.
- Pamięć i kompakcja pozwalają modelowi pracować dłużej, niż pozwala jego okno kontekstowe; weryfikacja (testy, linters, kalkulator) odbiera modelowi bezpodstawne „wygląda dobrze”.
- Uprawnienia i piaskownica chronią zarówno przed pomyłkami modelu (np. kasowaniem plików), jak i przed działaniami niezgodnymi z intencją użytkownika.
- Pętla ReAct (rozumowanie + działanie) to silnik większości agentów; przyszłość to MCP w każdej aplikacji, natywne zespoły agentów, równoległe próby i uprzęże uczące się na własnych błędach.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Model to mózg w słoju — pracuje jego otoczka
Na czym polega: Model potrafi tylko generować tekst: nie ma pamięci, nie widzi plików, nie wykonuje działań, nie weryfikuje efektów. Cała realna praca — czytanie plików, uruchamianie kodu, sprawdzanie wyników — dzieje się w warstwie zwanej harness, czyli uprzęży.
Jak stosować: Oceniając narzędzie AI, patrz nie tylko na nazwę modelu, ale na całą oprawę: jakie ma narzędzia, jaką pamięć, jaką weryfikację. To otoczka decyduje, ile z potencjału modelu faktycznie wykorzystasz.
Na co uważać: Porównania „model X bije model Y” przeprowadzone w różnych narzędziach mówią często więcej o uprzęży niż o samym mózgu.
2.Ten sam model w innej uprzęży zachowuje się inaczej
Na czym polega: Przeniesienie modelu do innej otoczki zmienia jego wyniki — są już badania pokazujące, że sama zmiana uprzęży daje duże skoki wydajności, a niektóre modele „leżą” lepiej w niektórych środowiskach.
Jak stosować: Jeśli model „nie daje rady” w jednym narzędziu, zanim zapłacisz za inny model, przetestuj to samo zadanie w innej uprzęży — np. w środowisku kodującym zamiast zwykłego czatu.
Na co uważać: Wąskim gardłem bywa narzędzie, nie model — wymiana modelu na droższy nic wtedy nie da.
3.Nowe rekordy w benchmarkach często to zasługa uprzęży
Na czym polega: Postęp idzie dwutorowo: rośnie inteligencja modeli, ale poprawiają się też uprzęże. Model może zostać dokładnie ten sam, a nowy wynik wynika z lepszej oprawy, która pozwala tej samej inteligencji zrobić więcej.
Jak stosować: Czytając o „przełomach”, pytaj, co się faktycznie zmieniło: model czy jego otoczka. We własnych projektach szukaj tanich zysków w uprzęży — to znacznie tańsze niż trening czy even wynajem mocniejszego modelu.
Na co uważać: Nagłówki o „mądrzejszym AI” bywają marketingiem — realną zmianą bywa po prostu lepsze opięcie tego samego mózgu na narzędzia.
4.Kontekst rozwiąż raz — koniec z wiecznym dopisywaniem instrukcji
Na czym polega: Nowa sesja modelu zaczyna się od zera. Dobra uprząż podaje mu na starcie całą otoczkę zadania: projekt, strukturę plików, ostatnie zmiany, dostępne narzędzia. W praktyce robi się to plikami typu CLAUDE.md czy AGENTS.md, w których zapisuje się reguły: styl kodu, zakazy edycji, obowiązkowe testy.
Jak stosować: Opisz raz zasady pracy w takim pliku i pozwól, by każda kolejna sesja go czytała. Rozwiązując problem kontekstu, rozwiązujesz jednym ruchem wszystkie przyszłe problemy z promptowaniem.
Na co uważać: Instrukcje się starzeją — sprzeczne wpisy w rozrośniętym pliku kontekstowym mieszają modelowi bardziej niż ich brak.
5.Długie sesje wypełniają okno kontekstowe i psują jakość
Na czym polega: Okno kontekstu ma sztywny limit. Przy bardzo długich rozmowach (rzędu milionów tokenów, czyli 20–50 książek) inteligencja modelu spada, a w kontekście gromadzą się sprzeczne instrukcje — model robi się skołowany.
Jak stosować: Korzystaj z kompakcji — podsumowania celów, planu, zmian i błędów w zagęszczonej formie. Claude Code robi to automatycznie przy pełnym oknie; przy dużych zadaniach warto samemu zaczynać nową sesję od zwięzłego streszczenia dotychczasowej pracy.
Na co uważać: Kompakcja usuwa szczegóły — po ściśnięciu sprawdź, czy model nadal pamięta krytyczne ograniczenia projektu.
6.Narzędzia to „kora ruchowa” modelu — i możesz je sam rozbudowywać
Na czym polega: Model potrafi tylko wypisywać tekst; uprząż rozpoznaje konkretne fragmenty jako żądania działania i podłącza je do narzędzi. Dzieje się to dziesiątki razy na minutę, bez świadomości użytkownika. Standardem opisu narzędzi stał się protokół MCP.
Jak stosować: Jeśli brakuje ci funkcji, poproś własnego agenta o napisanie serwera MCP i podłącz go do pracy — tak każdy może rozszerzyć swój zestaw narzędzi i realnie wnieść coś do ekosystemu.
Na co uważać: Każde narzędzie to koszt tokenów i potencjalna powierzchnia ataku — dodawaj je celowo, nie hurtowo.
7.Bez weryfikacji model „się zgodzi” niemal ze wszystkim
Na czym polega: Model nie wie, czy jego kod działa — klasyczny przykład z 2022 roku: ChatGPT upierający się, że 17 × 3 = 48. Rozwiązaniem jest wpięcie zewnętrznych sprawdzianów: testów, linterów, kalkulatorów, formaterów — a ich wynik wraca do modelu jako informacja zwrotna.
Jak stosować: Po każdym wygenerowanym kodzie uruchamiaj testy i podawaj modelowi wynik (np. kod wyjścia 0 jako potwierdzenie sukcesu) — model sam poprawi to, co nie przeszło.
Na co uważać: „Wygląda dobrze” w ustach modelu to opinia, nie wynik testu — nie myl jednego z drugim, zwłaszcza przy matematyce i kodzie.
8.Hooki pozwalają wpleść własne kontrole w cykl pracy agenta
Na czym polega: Warstwa uprawnień sprawdza każde wywołanie narzędzia i całe ich sekwencje. Dzięki hookom — punktom zaczepienia w cyklu życia uprzęży — możesz dodać własne reguły, np. automatyczne testy po każdej edycji pliku albo pytanie o zgodę przed połączeniem z nowym serwisem.
Jak stosować: Jeśli agent optymalizuje np. czasy ładowania sklepu, ustaw hook „po edycji — pełny zestaw testów” albo „przed połączeniem z adresem, którego nie było na liście z ostatnich dwóch tygodni — zapytaj mnie”.
Na co uważać: Nadmiar pytań o zgodę zamienia automat w ankietę — grupuj zgody i dawaj agentowi pole do samodzielności w bezpiecznym zakresie.
9.Piaskownica ogranicza szkody z pomyłek i „niezgodności” modelu
Na czym polega: Sandbox to odizolowane środowisko, w którym model może działać swobodnie — ale nie wychodzi poza jego granice. Chroni dwojako: przed błędami („usuń wszystkie pliki”) oraz przed działaniami niezgodnymi z intencją użytkownika — od nieszkodliwych skrótów po próby wyrzucenia wag modelu do internetu.
Jak stosować: Uruchamiaj agentów produkcyjnych w odizolowanym środowisku (kontener, maszyna wirtualna) i trzymaj operacje krytyczne za murem zgód.
Na co uważać: Piaskownica nie zastępuje uprawnień — to druga linia obrony, nie jedyna.
10.Pętla ReAct: myśl — działaj — sprawdź, i od nowa
Na czym polega: Większość agentów działa w pętli: rozumowanie → działanie (narzędzie) → kontrola uprawnień → uruchomienie w piaskownicy → przycięcie wyników → odczyt i wnioski → kolejne rozumowanie, aż do osiągnięcia celu. To pętla ReAct (reason + action). Następne kroki rozwoju: MCP w każdej aplikacji, natywne zespoły agentów, uruchamianie wielu prób naraz i wybór tej, która się udała, oraz uprzęże uczące się na własnych błędach.
Jak stosować: Gdy agent „kręci się w kółko”, rozłóż pętlę na fazy i sprawdź, która się sypie — zwykle to kontekst albo weryfikacja. Tam, gdzie sprawdzanie wyniku jest tanie, stosuj równoległe próby i zachowuj tę udaną.
Na co uważać: Strategia „wypróbuj N razy” kosztuje tokeny — opłaca się tylko wtedy, gdy koszt weryfikacji jest niższy niż koszt błędu.
Redakcyjne tłumaczenie
Mózg w słoju, czyli kto naprawdę pracuje
Sztuczna inteligencja trafiła dziś niemal do każdej większej organizacji na świecie: rozwiązuje zadania matematyczne i przynosi firmom takim jak twoja czy moja setki milionów dolarów przychodu. Jest jednak jeden niuans: to wcale nie sam model AI wykonuje tę pracę. Model to tylko mózg w słoju — nie potrafi ani mówić, ani cokolwiek zrobić. Prawdziwą robotę wykonuje coś innego. I tym „czymś” jest tak zwany harness — po polsku dosłownie „uprząż”. W tym filmie przekażę wam wszystko, co musicie o nich wiedzieć.
Claude Code i Codex to nie modele, tylko uprzęże
Zacznijmy od czegoś, co już znacie: Claude Code i Codex. Nie wszyscy wiedzą, że to nie są modele AI — to uprzęże, otoczki nałożone na modele. Claude Code to uprząż Anthropic dla rodziny Claude (m.in. Mythos, Fable, Opus, Sonnet i Haiku), a Codex to uprząż OpenAI dla modeli z serii ChatGPT — GPT-6, GPT-5 i kolejnych.
Będę wszystko tłumaczył na przykładzie Codexa i Claude Code, ale pamiętajcie: zasady dotyczą praktycznie każdej uprzęży i każdego modelu, który pod nią pracuje. Kluczowa myśl brzmi: obie te otoczki pozwalają AI realnie pracować, a nie tylko gadać.
Ciekawostka: gdybyście wzięli Claude’a i wsadzili do uprzęży OpenAI, zachowywałby się zupełnie inaczej. Jeśli nasz mózg w słoju ma jakiś pułap wykonania na danym zadaniu, to w uprzęży A wypadnie on inaczej niż w uprzęży B. Właśnie dlatego zrozumienie harnessów jest tak ważne. Istnieje już sporo badań pokazujących, że ten sam model potrafi osiągnąć ogromne przyrosty wydajności po przeniesieniu do choćby nieco innej otoczki. Są też swoiste dopasowania między konkretnymi modelami a konkretnymi uprzężami — i to również warto rozumieć.
Okno czatu też jest uprzężą
Zwykłe okno rozmowy — uwierzcie albo nie — samo w sobie również jest uprzężą. Większość modeli wywodzi się właśnie z prostych okienek czatu i większość znanych wam dziś narzędzi AI zaczynało dokładnie tak samo. Od tego czasu zrobiło się znacznie bardziej złożenie — i właśnie dlatego nagrywam ten materiał.
I wreszcie: postęp AI biegnie po wielu wymiarach naraz. Rośnie inteligencja samych modeli, ale poprawiają się też uprzęże. Kiedy widzicie nowy benchmark, w którym Claude Code roznosi konkurencję w zdolności, do której wcześniej nie miał dostępu, nie oznacza to wcale, że „mózg” zrobił się mądrzejszy. Inteligencja mogła pozostać dokładnie ta sama — poprawiła się otoczka wokół niej, pozwalając tej inteligencji wciągnąć pancerz jak piechur w StarCrafcie i odwalić więcej roboty w krótszym czasie.
Co sam potrafi model: predyktor tekstu
Porozmawiajmy o modelu samym w sobie. Model faktycznie jest mózgiem w słoju. Modele, o których tu mówię — wielkie modele językowe — zostały pierwotnie wytrenowane jako predyktory tekstu. Podawaliście im krótki tekst, a one zwracały nieco dłuższy. I to wszystko.
Takie modele nie miały pamięci: każda nowa rozmowa zaczynała się od zera. Niczego nie widziały — ani plików na waszym komputerze, ani tego, co macie na ekranie. Nie potrafiły działać; mogły co najwyżej mówić wam, co macie zrobić: „zacznij tutaj, potem zrób to, potem tamto”. W wielu przypadkach to wystarczało — ale jeśli naprawdę chcemy być produktywni, po prostu dajemy modelowi możliwość zrobienia rzeczy samodzielnie. Jeszcze niedawno nie było to możliwe. Wreszcie: model nie umiał się sprawdzić. Nie wiedział, czy jego kod działa, ani czy to, co stworzył, dobrze wygląda. Nie istniała żadna pętla weryfikacji.
Dziś wszystkie te braki rozwiązaliśmy. Kiedyś jednak wszystko, co potrafił taki model, sprowadzało się do tego, że podawaliście mu tekst „niebo jest”, a on zwracał to samo zdanie z dorzuconym słowem: „niebo jest niebieskie”. To cała tajemnica wielkich modeli językowych „pod maską”. Karmimy je ogromną ilością danych — praktycznie całym tekstem internetu i nie tylko — i to wielokrotnie, aż dojdą do wniosku, że po „niebo jest” statystycznie miliardy razy następowało „niebieskie”, a „pterodaktil” — kilkanaście razy. Więc raczej nie pterodaktil.
Koń, siodło i lejce
Czym więc jest harness? Gdybyście używali samego modelu, byłby on trochę jak koń: mnóstwo mocy, ale zero sterowności. Czasem wypluje tekst genialny, kiedy indziej dziwny. Te huśtawki jakości, dołożone do niezdolności modelu do działania w realnym świecie, oznaczają brak jakiejkolwiek kontroli.
Uprząż to siodło i lejce — cała infrastruktura, którą zakłada się na konia, żeby szedł w kierunku użytecznym dla człowieka. Koń sam w sobie jest niezwykle potężny, ale jego siła z natury nie służy ludzkim celom. Harness to sposób, w jaki kierujemy tę potężną inteligencję tam, gdzie uznajemy to za pożyteczne.
W chwili nagrania wyróżniam pięć głównych elementów uprzęży wokół samego modelu. Jest oczywiście model — mózg w słoju. Otacza go kontekst, który opisuje, co robimy i po co. Dalej pamięć, czyli zapis dotychczasowych rozmów z modelem. Potem narzędzia, dzięki którym model może działać w świecie. Następnie weryfikacja — mechanizmy pozwalające modelowi ustalić, czy zrobił to, co trzeba. I wreszcie uprawnienia: warunek stopu, który powstrzymuje model przed robieniem rzeczy, których nie chcecie. To właśnie siodło i lejce naszego konia.
Warto zapamiętać: dziś dobra uprząż jest równie ważna jak dobry model. Możecie nałożyć wybitną otoczkę na całkiem słaby model — a wyniki i tak będą przyzwoite.
Kontekst: rozwiąż raz, korzystaj zawsze
Zacznijmy od kontekstu. Jego zrozumienie pomoże wam budować i projektować znacznie lepszych agentów AI. Kiedy startuje nowa sesja, model nie ma pojęcia, co się dzieje — rodzi się niemal jako czysta karta. Jeślibyście napisali „cześć”, odpowie „cześć”, ale nie napisze „cześć, Nicku, jak tam dziś biznes?” — bo nie ma pojęcia, kim jesteś.
W ujęciu biznesowym, które pewnie interesuje większość z was, kontekst to odpowiedzi na pytania: nad jakim projektem pracujemy? Jaka jest struktura plików? Co ostatnio się w niej zmieniło? Do jakich narzędzi mamy dostęp? Całą tę wiedzę podajemy modelowi na samym początku rozmowy i po prostu ukrywamy przed użytkownikiem, żeby nie zaśmiecała widoku. Model natomiast ma pełny dostęp do informacji potrzebnych do podjęcia trafnej decyzji w odpowiedzi na to, co powiemy dalej.
W Claude Code i Codexie robi się to zwykle przez mapę kodu oraz pliki takie jak CLAUDE.md czy AGENTS.md, do których wpisujecie zalecenia: „trzymaj się naszego stylu kodu”, „nie edytuj tego katalogu”, „zawsze uruchamiaj te testy” i tak dalej. (Informacja dodatkowa: CLAUDE.md i AGENTS.md to pliki konfiguracyjne czytane przez środowiska kodujące na starcie sesji — pełnią rolę stałej instrukcji dla agenta.) Inne modele i uprzęże mają własne konwencje.
Najlepsze w kontekście jest to, że daje on modelowi środowisko do działania, a tworzy się go raz. I właśnie dlatego oszczędza on was od ciągłego dopisywania tych samych instrukcji: kto rozwiąże problem kontekstu, ten rozwiązuje jednym ruchem wszystkie przyszłe problemy z promptowaniem. Nic dziwnego, że tak wiele uprzęży przykłada wielką wagę do tego, by kontekst był ułożony maksymalnie sprawnie i ekonomicznie.
Pamięć i kompakcja: jak pracować dłużej niż własne okno kontekstowe
Kolejny element to pamięć, a w jej obrębie coś, co nazywa się kompakcją. Im dłużej rozmawiacie z modelem, tym bardziej zapełnia się jego okno kontekstowe. To cecha samego modelu, nie uprzęży: okno kontekstu jest sztywno ustalone przez architekturę i sposób, w jaki model wyrósł. Niestety, gdy zbliżamy się do granicy, dynamika się zmienia. Inteligencja modelu nieco spada, a w kontekście zbiera się mnóstwo sprzecznych instrukcji — bo przy rozmiarach rzędu milionów tokenów, czyli 20–50 książek, niemal zawsze znajdzie się jedna dyrektywa „rób to” obok drugiej „rób tamto”, i model robi się mocno skołowany.
Pamięć pozwala wziąć wszystko — cele, plan, zmieniane pliki, bieżące kroki, błędy, notatki, nieudane próby — i zamienić w znacznie bardziej zwięzły, zagęszczony zapis tych danych. Dzięki temu model może kontynuować pracę w tym samym kierunku, tylko sprawniej i bez tracenia tego, co dotąd ustaliliśmy.
Sercem pamięci w uprzężach jest właśnie kompakcja: wszystko podsumowuje się w znacznie krótszej formie. Stare kroki zamieniają się w jedno krótkie streszczenie, wyrzucamy nieudane próby i opisujemy samą istotę — a w ten sposób uwalniamy okno kontekstowe, pozwalając modelowi rozmawiać znacznie, znacznie dłużej, niż pozwalałoby jego pierwotne okno. Claude Code robi to automatycznie, gdy okno jest niemal pełne.
Są jeszcze przydatne dodatki. Jeśli pracujecie nad tym samym plikiem wielokrotnie, uprząż zwykle prowadzi dziennik zmian: nie zapisuje całego pliku, tylko krótki log tego, co zmieniono — i na jego podstawie model potrafi odtworzyć pierwotną wersję, cofając się w czasie. Dla osób z inżynierskim bagażem brzmi to znajomo: to bardzo podobne do Gita i kontroli wersji.
Krótko mówiąc, pamięć daje modelowi trwałą świadomość nie tylko kontekstu z chwili startu sesji, ale coś w rodzaju kontekstu długotrwałego — odpornego na jego własne limity tokenów.
Narzędzia: kora ruchowa modelu
Narzędzia to ostatecznie sposób, w jaki model działa w świecie. Jak wiecie, modele potrafią tylko wypisywać tekst. Budujemy więc wokół nich systemy, które rozpoznają określone typy generowanego tekstu. Kiedy model wyprodukuje tekst konkretnego rodzaju, traktujemy to w pełni deterministycznie: „ten fragment znaczy, że model chce wykonać takie działanie” — i podłączamy go do aplikacji, która to działanie wykonuje. To jest warstwa narzędzi.
Wywołanie narzędzia (tool calling) wygląda tak: model tworzy wynik, uprząż rozpoznaje go jako żądanie i kieruje do długiej listy dostępnych narzędzi, gdzie zostaje dopasowany do konkretnego — powiedzmy do wyszukania pliku. Potem narzędzie zbiera dane, zwraca je do uprzęży, a uprząż podaje je z powrotem modelowi. Wszystko to dzieje się dziś zwykle dziesiątki razy na minutę, bez waszej świadomości, podczas gdy model porusza się po swoim środowisku.
Myślę o tym jak o mózgu podpiętym pod korę ruchową. Gdyby mózg nie był z nią połączony, moglibyście mieć tysiące pomysłów — chcę chwycić ten kubek, przybić piątkę przechodniowi — ale nie bylibyście w stanie nic z nimi zrobić. Narzędzia są dla modelu tym, czym kora ruchowa dla mózgu.
Na poziomie wywołań narzędzi doszło do sporo innowacji: modele przeszły od stanu, w którym wydawały mnóstwo tokenów przy skąpym zwrocie, do stanu wysokiej wydajności — dzięki przycinaniu wyników wywołań, przepisywaniu oprogramowania tak, by było „natywne dla AI” (czyli nie generowało wielkich wejść i wyjść), i uczeniu modeli inteligentnego wyboru narzędzi.
Narzędzia opisuje się schematami, a jednym z najpopularniejszych jest dziś MCP — Model Context Protocol: standard pozwalający modelom łączyć się z innymi aplikacjami za pomocą własnych narzędzi. I tu ciekawostka: jeśli chcecie realnie przyłożyć się do rozwoju uprzęży, możecie zacząć już teraz. Możecie podejść do swojego agenta AI i powiedzieć: „chcę stworzyć serwer MCP, który pozwoli modelowi robić X, Y i Z” — a on pomoże wam go napisać. Taką wtyczkę podajecie potem dowolnemu modelu i w ten sposób realnie wzbogacacie całą ekonomię narzędzi. Czy Claude Code albo Codex wchłoną wasz protokół bezpośrednio do swojej uprzęży — to osobna sprawa. Ale tak właśnie komponujecie swojemu modelowi własny arsenał.
Weryfikacja: koniec z „wygląda dobrze”
Weryfikacja może brzmieć groźnie, ale to po prostu rdzeń tego, co robimy ludzie, wykonując zadanie: sprawdzanie własnej pracy. Jeśli podacie wynik modelowi bez warstwy weryfikacji, często usłyszycie: „no, wygląda całkiem nieźle”. Dlaczego? Bo modele nie mają wbudowanego, ustandaryzowanego sposobu sprawdzania. Mogą popatrzeć na kawałek kodu i stwierdzić: „no, chyba okej, słowa pewnie są na swoich miejscach, kształt mniej więcej taki, jak chciałem”. Ale nie wiedzą, czy on działa.
Weryfikacja działa podobnie do warstwy narzędzi: do wygenerowanego — powiedzmy — kodu podpina się zestaw narzędzi sprawdzających i faktycznie uruchamia je na wyniku, żeby potwierdzić, że działa. Wynik takiego przebiegu wraca potem do modelu.
Mała historia: gdy wielkie modele językowe zyskały masową popularność za sprawą ChatGPT w 2022 roku, wydano je jako produkt konsumencki i ludzie zaczęli używać ich do konsumenckich celów — na przykład pomocy z matematyką. Uczniowie pytali: „hej, ile jest 17 razy 3?”, model odpowiadał „48”, człowiek mówił: „czekaj, chyba 51?”, a model upierał się: „nie, 48”. Choć to w gruncie rzeczy miniaturowe roboty, nie miały wbudowanego kalkulatora. Rozwiązanie: budujecie kalkulator i dajecie go modelowi. Model nie próbuje wtedy liczyć sam — bo często by się pomylił — tylko korzysta z kalkulatora, patrzy na wynik — „kalkulator potwierdził, że wynik jest poprawny” — i podaje go dalej.
To mały przykład ogromnej zmiany. Gdy ludzie zaczęli tak robić, modele AI po prostu stały się zdolne do matematyki. I pomyślcie: dokładnie tak działa człowiek. Nasz rozmyty mózg próbuje przemielić zadanie matematyczne, do którego ewolucja go nie stworzyła, i bez przerwy popełnia błędy. Więc część tej pracy odkładamy na coś z wbudowaną weryfikacją: kalkulator ma własne sprawdziany, linters w aplikacjach do przeglądu kodu — swoje, formatery markdowna — swoje. Dzięki temu ustalamy, że plik wynikowy jest faktycznie poprawny. W praktyce: model generuje kod, przepuszcza go przez narzędzie weryfikujące, otrzymuje kod wyjścia zero jako potwierdzenie sukcesu i wie: „to naprawdę działa, mogę oddać użytkownikowi”.
Uprawnienia i piaskownica: hamulce i bezpieczniki
Na szczycie piramidy: uprawnienia i sandbox. Tutaj uprząż dodatkowo sprawdza każde pojedyncze wywołanie narzędzia, a na wyższym poziomie — także całą sekwencję wykonanych wywołań. Dziś większość uprawnień działa proceduralnie, ale niektórzy eksperymentują z użyciem innego modelu AI jako strażnika podpiętego pod główny model. Mielibyśmy więc modele AI pilnujące działań innych modeli AI — co jest ciekawe, bo trochę przypomina budowę mózgu. Mózg to rozmyta sieć neuronowa z całą serią warunków stopu, nieustannie ocenianych względem siebie. Dlatego jest taki pofałdowany, przecinają go bruzdy, ma tyle różnych części: nie tylko korę przedczołową, ale też rdzeń przedłużony, jądra podstawy i tak dalej. Ta piramida to naprawdę niezwykły wynalazek — i uprawnienia są bardzo czytelnym sposobem, by to zobaczyć.
Wyobraźcie sobie, że wasz model chce wysłać dane na adres www.zdecydowanie-nie-jest-to-link-wyłudzeniowy.com (w oryginale: www.definitely-not-a-phishing-link.com). Dobra warstwa uprawnień zauważy: „hmm, to wygląda na potencjalnie ryzykowną stronę. Nowy adres, nigdy tu niczego nie wysyłaliśmy. Chcę tylko potwierdzić — to okej?”. Zamiast pozwolić modelowi działać samowolnie, wyskakuje okienko: „czy mogę połączyć się z tą stroną? Czy mogę usunąć stary katalog?”.
Realizuje się to głównie przez hooki — zaprogramowane punkty w cyklu życia uprzęży, w których można wpiąć własne wywołania. Przykład: po każdej edycji może działać warstwa automatycznie uruchamiająca testy na bazie kodu. Powiedzmy, że wasz agent zajmuje się optymalizacją jakiejś funkcji — pracujecie w firmie e-commerce i chcecie zbić czasy ładowania. Wszystko, co model robi, będzie się pewnie wiązać z tym zadaniem. Możecie więc dodać hook po-edycyjny: po każdej zmianie pliku odpalamy duży zestaw testów. Model dostaje wyniki i wie, czy faktycznie zrobił dobrą robotę — to część pętli weryfikacyjnej (nieco inna od uprawnień, ale spokrewniona). Kontrolę można też wpiąć tuż przed działaniem: przed wykonaniem wywołania uprząć może zajrzeć na listę wszystkich serwisów, do których wysyłaliście zapytania w ostatnich dwóch tygodniach. Nowy adres nie figuruje na liście? Wyskakuje pytanie: „pozwolić?”. Możliwości jest mnóstwo.
Drugim ważnym elementem bezpieczeństwa AI w organizacjach są piaskownice — sandboxy. To wirtualne środowiska, do których model ma dostęp i w których może robić, co chce, ale nie wolno mu działać poza nimi. Wartość jest dwojaka. Po pierwsze: jeśli coś pójdzie nie tak, szkody zostaną w środku. Model może odpalić jedno z tych „usuń wszystkie pliki, skasuj zapisaną pracę, zmień ustawienia systemu”. Oczywiście wolelibyśmy, żeby tego nie robił — ale modele są, jak wiemy, trochę rozmyte i czasem się mylą. Jeśli to się zdarzy, a uprząż nie wyłapie problemu, przynajmniej skala zniszczeń zostanie ograniczona do wnętrza piaskownicy.
Po drugie: niezgodność działania z intencją użytkownika. Modele, stając się coraz inteligentniejsze i coraz lepiej rozumiejąc te narzędzia, zaczynają podejmować działania mniej zgodne z tym, czego chce użytkownik. Z różnych powodów: czasem szukają po prostu tańszej i łatwiejszej odpowiedzi — zamiast wszystko wyliczać sam, model zajrzy do dużej bazy danych, w której te dane już są, i poda to użytkownikowi. A czasem powód bywa mniej niewinny. Niezależnie od wszystkiego piaskownica zapewnia, że model nie wykona pewnych zakazanych akcji — na przykład nie wyrzuci swoich wag do internetu ani nie wgra się na serwis, na który nie planowaliście go wysyłać.
Skąd się bierze „rozumowanie” modelu
Na końcu dnia to model jest tu inteligencją, która decyduje. Działanie wygląda tak: podajecie kontekst i aktualny stan, a model patrzy na jedno i drugie i — w oparciu o wasze instrukcje — decyduje, co zrobić dalej.
Niektóre modele wspinają to na pętlę rozumowania — i rozumowanie również jest wpisane w uprzęże. Polega ono na tym, że model wypisuje swój wstępny pomysł, po czym podaje go z powrotem na wejście jako kolejne podejście: „okej, to jest mój pierwszy sąd, ale przy bliższym spojrzeniu…” — i jedzie dalej. Najciekawsze, że firmy AI mają na to sporo kreatywnych patentów. Jeden z prostszych: użycie zwykłego słowa „ale”. Model przechodzi wstępny przebieg z osadzonym poleceniem „przemyśl to i zaproponuj najlepszy następny krok”, a potem wynik wraca do modelu z doklejonym słowem „ale”. I teraz model ma wszystko plus „ale” — więc natychmiast zaczyna myśleć: ale? ale co? I szuka wyjątków od tego, co przed chwilą sam powiedział. W ten sposób model wzmacnia własny proces decyzyjny. Gdybym poprosił was o dokończenie zdania zaczynającego się od „ale”, a w poprzednim postawiliście tezę — naturalnie musielibyście wymyślić kontrargument. Dokładnie to robią modele pod maską, kiedy „rozumują” i „myślą” — i jest to część uprzęży. Tak otoczki kontrolują wyniki modeli i podnoszą ich jakość.
Po takiej dużej pętli rozumowania model w końcu decyduje się na działanie. Podaje je do uprzęży, która porządkuje wynik — i tu dróg jest kilka. Może myśleć dalej, jeśli nie czuje się pewnie swojego odpowiedzi. Może wysłać żądanie narzędzia. Może faktycznie zrobić rzecz. Może też napisać do was z prośbą o doprecyzowanie lub opinię.
I tu najważniejszy wniosek całego tematu: uprzęże nie potrafią uczynić modeli inteligentniejszymi. Potrafią natomiast uczynić je znacznie bardziej użytecznymi — i właśnie w to skierowana była większość rozwoju harnessów ostatnich lat. Poszedłbym nawet dalej: największe skoki, jakie modele zrobiły w ostatnich może sześciu miesiącach, były w całości możliwe dzięki uprzężom. A piękno polega na tym, że uprząż to zwykłe oprogramowanie — każdy z was może wnieść do niej realny wkład. Przy wielkich modelach językowych, trenowanych na potężnych GPU, jest to trudniejsze, bo po prostu nie macie dostępu do tego sprzętu.
Pętla agentowa: ReAct
Zostawię wam na koniec pętlę agentową. Nie wymyślono jej w ostatnich miesiącach — mówi się o niej od lat; podejrzewam, że wywodzi się z LangChaina albo innego miejsca — ale to właśnie ten schemat, według którego większość modeli działa właściwie od pojawienia się pierwszych agentów. (Informacja dodatkowa: LangChain — popularna biblioteka open source do budowania aplikacji opartych na dużych modelach językowych.)
Zawsze dzieje się to samo: najpierw trochę myślimy i wybieramy następny krok. Potem działamy, co zwykle oznacza wywołanie narzędzia. Dalej warstwa uprawnień sprawdza, czy to wywołanie jest dozwolone. Potem faktycznie je uruchamiamy — najpierw zwykle w piaskownicy, żeby poznać pełny zakres skutków. Następnie przytniemy wyniki z piaskownicy, zostawiając użyteczną część. Potem czytamy, co się stało, wyciągamy wnioski, dlaczego tak — i znowu myślimy, by wybrać kolejny krok. I tak w kółko, aż do osiągnięcia celu — wtedy wychodzimy z pętli i kończymy.
Ta konkretna pętla nazywa się ReAct — od reason plus action, „rozumowanie plus działanie” — i to ona spina większość dzisiejszych agentowych uprzęży.
Co dalej: MCP wszędzie, zespoły agentów i uprzęże uczące się na błędach
Co przyniesie przyszłość — dla waszej nauki i dla stanu rozwoju uprzęży? Po pierwsze: MCP pojawi się w kolejnych aplikacjach. Praktycznie każda większa platforma łączy się teraz z tym protokołem, żeby modele takie jak Claude Code i Codex udostępniały te połączenia użytkownikom przez konektory i funkcje wtyczek.
Po drugie: zespoły agentów pracujących w zgodzie — co wzmocni warstwę kontekstu uprzęży. Dziś używamy subagentów i pozwalamy agentom delegować sobie pracę oraz dzielić się nią. Ale myślę, że to stanie się bardziej natywne: zamiast zwykłej warstwy kontekstu może powstać warstwa „rozmów między agentami”, przechowująca kontekst wszystkich agentów, które pracowały nad podobnymi problemami.
Po trzecie: równoległe testowanie wielu wersji naraz. Wiele uprzęży — zwłaszcza tych, które ostatnio notują bardzo wysokie wyniki — bierze zadanie agenta, duplikuje je i rozdaje kilku różnym modelom, każdemu z własną pętlą weryfikacji. Może wykonać je trzy razy, powiedzmy, a zadziała tylko jedna próba — i tę zachowuje jako wynik. To podejście statystyczne: przeszukujemy przestrzeń możliwych rozwiązań i zostawiamy tylko te poprawne. Biorąc pod uwagę obiecujące rezultaty, wydaje się to bardzo logiczny kierunek dla większości uprzęży agentowych.
I wreszcie wielka rzecz: uprząż ewolucyjna, do której firmy AI zaczynają się przymierzać szerzej. Zasada: za każdym razem, gdy model popełni błąd pracując w uprzęży, system to wychwytuje — ustala, jaka część działań była błędna, które były poprawne, dlaczego błędne okazały się błędne — i wzmacnia samą uprząż, żeby błąd się nie powtórzył. Przykład: model ma tendencję marnować tony tokenów na czytanie całej przestrzeni roboczej, zanim cokolwiek zrobi, co odbija się później na jakości jego pracy. Uprząż ewolucyjna to wyłapuje — jest przy tym model odpowiedzialny za ulepszanie samej uprzęży — i mówi: „wiesz co, nie trzeba skanować całej przestrzeni roboczej. Użytkownik zwykle potrzebuje kilku plików. Może najpierw zrobimy wyszukiwanie, zamiast wypisywać wszystkie pliki?”. Efekt: jedna dziesiąta zużycia tokenów — oszczędność dla użytkownika i znacznie większe prawdopodobieństwo, że zadanie zostanie skończone. Tak łapie się błędy wcześniej, mniejszym nakładem pracy i mniejszą liczbą ludzi.
Zakończenie
Mam nadzieję, że dowiedzieliście się dziś czegoś o uprzężach AI. Jeśli lubicie takie rzeczy i chcielibyście przykładać się do harnessów w firmach i innych organizacjach, kliknijcie pierwszy link w opisie i zobaczcie Maker School — mój 90-dniowy program, w którym rozliczacie się z postępów, a ja pokazuję, jak wystartować i zdobyć pierwszego klienta na usługę AI lub automatyzacji. Czyli dokładnie te usługi, które potraficie dziś świadczyć, bo właśnie zrozumieliście, jak działają uprzęże. A przy okazji zróbcie mi przysługę i zostawcie w komentarzu propozycję kolejnego filmu — w ostatnim czasie większość pomysłów biorę wprost z komentarzy, a moim celem jest dalej tworzyć treści, które chcecie oglądać. Dziękuję bardzo i do zobaczenia w następnym materiale.