O czym jest ten film
- Pydantic AI wydało wersję 2.0, którą autor uważa za istotny krok w ewolucji sposobu budowania agentów AI.
- Centralnym pojęciem nowej wersji jest „capability” (zdolność) — jeden składalny prymityw budulcowy agenta.
- Pojedyncza capability łączy instrukcje, narzędzia, hooki cyklu życia, guardraile i ustawienia modelu w jednej jednostce.
- Capabilities można wielokrotnie używać między agentami — jak klocki Lego — i traktować jako warstwę „ponad” serwerami MCP.
- Autor porównuje wersję 1.0 (wszystko wrzucone bez organizacji) z 2.0 (agent = zestaw składalnych capabilities).
- Mechanizm „progressive disclosure” pozwala dać agentowi dziesiątki lub setki zdolności bez przeciążania modelu.
- Demo na przykładzie agenta wsparcia klienta: prosty pytanie ładuje tylko bazę wiedzy, sprawa wymagająca eskalacji ładuje capability eskalacji.
- Nowa architektura dzieli się na „lean core” (kluczowe capabilities) i „harness” (dodatkowe, np. code mode z sandboxem Monty).
- Autor radzi nie pisać kodu Pydantic AI ręcznie — wystarczy skierować asystenta kodującego na dokumentację capabilities.
- Konkluzja: do wdrożeń produkcyjnych z realnymi użytkownikami wciąż potrzebny jest framework, a Pydantic AI jest dla autora wyborem numer jeden.
Redakcyjne tłumaczenie
Dlaczego Pydantic AI to mój ulubiony framework
Pydantic AI od dawna jest moim ulubionym frameworkiem do budowy agentów AI. Materiały na jego temat tworzę od stycznia zeszłego roku. To zespół, który konsekwentnie wyprzedza branżę: budowanie agentów jest u nich naprawdę proste, a jednocześnie zachowujesz pełną możliwość dostosowania i kontrolę, których potrzebujesz, żeby wdrażać agentów klasy produkcyjnej. To właśnie odróżnia ich, moim zdaniem, od innych frameworków, takich jak LangChain czy Crew AI.
I zrobili to znowu. Właśnie wydali wersję 2.0 — dużą ewolucję w sposobie budowania agentów. Ta wersja frameworka koncentruje się wokół jednego prymitywu, który nazywa się „capability” (zdolność). To główny element, który teraz konstruujemy, tworząc agentów. I zwyczajnie to uwielbiam. To piękne uproszczenie, które jednocześnie kapsułkuje wszystko, czego agent potrzebuje, i uwzględnia to, do czego branża ostatnio zmierza — czyli hooki, guardraile, umiejętności (skills) i serwery MCP.
(Informacja dodatkowa: „hook” to zaczep — deterministyczny kod uruchamiany w określonym momencie działania agenta; „guardrail” to zabezpieczenie/ograniczenie prowadzące agenta; MCP, czyli Model Context Protocol, to standard pakowania narzędzi udostępnianych agentom.)
To nie jest film sponsorowany przez Pydantic AI i zwykle nie robię materiałów poświęconych samej aktualizacji frameworka. Ale ta jest na tyle dobra, że wygląda to na początek realnej zmiany — potężnej ewolucji sposobu budowania agentów.
Czym jest capability
Capability zbiera w jednej składalnej jednostce instrukcje agenta, narzędzia, hooki cyklu życia i ustawienia modelu. Dzięki temu całe rozszerzenie może sięgać każdej warstwy agenta poprzez jedno pojęcie. Brzmi to trochę jak marketingowa sałatka słowna, więc powiem to prościej: niezależnie od tego, jaką odpowiedzialność chcesz nadać agentowi, będzie ona złożona z zestawu narzędzi (żeby mógł sięgać do świata zewnętrznego) oraz z instrukcji i guardraili, które go prowadzą. Cokolwiek to jest, możemy spakować to razem jako jedną capability — pojedyncze wejście przy definiowaniu agenta.
W efekcie agenta można teraz rozumieć bardzo prosto: jako zestaw takich składalnych jednostek. Łączymy je razem, by nadać agentowi wszystkie odpowiedzialności, których od niego oczekujemy. Najlepsze jest to, że dzięki tej składalności — a to naprawdę jak układanie klocków Lego — bardzo łatwo używamy tych samych capabilities w różnych agentach, dla siebie albo dla firmy.
Warto też myśleć o capabilities jako o warstwie ponad serwerami MCP. MCP działa podobnie: to spakowany zestaw narzędzi, który wręczasz agentowi i którym łatwo dzielisz się między agentami — to jedna z głównych zalet MCP. Serwer MCP jest jednak podzbiorem tego, co wkładasz do capability. Capability to znacznie więcej niż samo „ramię” agenta, czyli narzędzia — to również instrukcje, ustawienia, hooki, guardraile oraz sposób, w jaki człowiek ma wchodzić w interakcję z agentem i coś do niego wstrzykiwać. To wszystko jest tu spakowane razem.
Chcę też podkreślić: nic z tego nie jest nowe. Wszystko, co składa się na capability, to elementy, z którymi już pracujesz — zwłaszcza w swoim asystencie kodowania: skills, hooki i tym podobne. Nowy i piękny jest sam sposób ich uproszczenia i wprowadzenia do frameworka agentowego.
Dlaczego Pydantic AI wraca na prowadzenie
Po tym wydaniu i wraz z ideą capability mam wrażenie, że Pydantic AI przeszło od lekkiego pozostawania w tyle do ponownego wyprzedzania branży. Mówię „w tyle” głównie z powodu wzrostu znaczenia SDK agentów kodujących. Dziś jest niesamowicie łatwo zbudować agenta — zwłaszcza bardziej osobistego — na czymś takim jak Claude Agent SDK czy Codex SDK. Są one wolniejsze i bardziej „żarłoczne” tokenowo niż tradycyjny framework w rodzaju Pydantic AI, więc są tu kompromisy, o czym też ostatnio mówiłem na kanale. Ale zwłaszcza w bardziej osobistych zastosowaniach zwykle budujesz agenta właśnie na czymś takim albo wprost w narzędziach typu Hermes czy Open Claw.
Pozostawał więc mniejszy zbiór przypadków, w których Pydantic AI wciąż był użyteczny — tym bardziej, że frameworki agentów kodujących świetnie integrują się z prymitywami, o których mówimy: hookami, sub-agentami, serwerami MCP. Dodanie tych rzeczy to dosłownie kilka linii — na przykład dołączenie serwera MCP albo hooka. I właśnie do tego Pydantic AI teraz dogonił: dodawanie takich capabilities jest bardzo proste, a moim zdaniem nawet prostsze. W tej chwili to dla mnie zwycięzca.
(Informacja dodatkowa: Hermes i Open Claw to lekkie narzędzia/środowiska do budowania osobistych agentów; w tym fragmencie autor przechodzi też do bloku sponsorskiego o narzędziu Nimble.)
Jak zacząć: skieruj asystenta na dokumentację
Żeby szybko unaocznić ideę capabilities, autor przygotował repozytorium na GitHubie, w którym zbudował agenta Pydantic AI zarówno w wersji 2.0, jak i 1.0. Repo można wykorzystać jako szablon albo punkt startowy dla własnego asystenta kodowania.
Jest jednak podejście, które gorąco polecam: po prostu podaj asystentowi kodowania dokumentację capabilities. W artykule zapowiadającym wersję 2.0 twórcy piszą wprost: „Wystarczy skierować asystenta kodowania na dokumentację capabilities”. To ciekawe, bo ta strona dokumentacji jest ogromna — co samo w sobie pokazuje, ile możliwości dostosowania i kontroli daje Pydantic AI. Właśnie dlatego to nie jest materiał przeznaczony do czytania przez człowieka. Ma go konsumować asystent kodowania, żeby pomóc ci zbudować agenta.
Naprawdę uważam, że kodu agenta Pydantic AI nie powinno się już pisać ręcznie. Sam nie robię tego od ponad roku — nie marnuj na to czasu. W filmie zaglądamy do kodu tylko po to, by wyjaśnić idee, a nie po to, byś rozumiał każdy szczegół czy pisał go samodzielnie.
Porównanie: wersja 1.0 kontra 2.0
To, co widać w wersji 1.0, to wciąż świetny framework — nie mam wielu zastrzeżeń i nadal chętnie budowałbym w ten sposób. Definiowanie narzędzi, dodawanie ich do agenta, ustawienie promptu systemowego i parametrów modelu jest względnie proste. Problem w tym, że przy definiowaniu agenta 1.0 wszystko jest wrzucone razem — instrukcje i narzędzia bez organizacji i bez składalności. Nie da się łatwo wyjąć podzbioru zdolności i dołożyć go do innego agenta; trzeba je definiować i tworzyć od nowa.
Wersja 2.0 to naprawia. Konstruktor jest bardzo prosty: podajemy model dla całego agenta, a cała reszta to po prostu zestaw capabilities. Każda z nich zawiera instrukcje, guardraile, hooki i narzędzia — nawet więcej, niż trzeba było definiować wcześniej — i można ją wielokrotnie używać między agentami.
Przykład: pierwszy agent to agent wsparcia, który musi sięgać do bazy wiedzy (wykonywać RAG w naszej bazie danych) i eskalować sprawy do człowieka. Wyobraź sobie teraz widżet FAQ na froncie platformy — nie potrzebuje eskalacji, ale wciąż potrzebuje dostępu do bazy wiedzy, żeby odpowiadać na podstawowe pytania. Nic nie budujemy od nowa. A gdy z czasem rozwijamy capability bazy wiedzy — poprawiamy instrukcje, guardraile i narzędzia — obaj agenci korzystają z tego jednocześnie.
(Informacja dodatkowa: RAG, czyli Retrieval-Augmented Generation, to technika, w której model najpierw wyszukuje odpowiednie dokumenty, a potem generuje odpowiedź w oparciu o nie.)
Jak wygląda sama definicja capability? Mamy instrukcje, zestaw narzędzi (dla bazy wiedzy to np. jedna funkcja przeszukiwania bazy), ustawienia modelu oraz prosty przykład hooka. Działa to jak w Claude Code czy Codex, gdzie masz hook „pre-tool use” — chcesz jakiejś deterministycznej akcji dla bezpieczeństwa albo dla właściwego pokierowania agentem. Analogicznie zdefiniowana jest capability eskalacji dla agenta wsparcia. Do capability można też dodawać kolejne elementy, na przykład serwery MCP.
Progressive disclosure: dziesiątki zdolności bez przeciążania modelu
Jedna z moich ulubionych cech capabilities to progressive disclosure. Tak jak w przypadku skills w Claude Code, Codex czy GitHub Copilot, możesz podać krótki opis capability. Dzięki temu agent ma katalog tego, na czym może się oprzeć, ale pełne instrukcje danej capability ładuje dopiero wtedy, gdy uzna, że naprawdę jej potrzebuje.
To ważne, bo pozwala dostarczyć agentowi wiele różnych capabilities — wbudowanych w Pydantic AI albo własnych — dziesiątki, a może i setki, nie przeciążając modelu. Model musi zagłębić się tylko w te, których wymaga bieżące zapytanie użytkownika.
Demo: agent wsparcia w akcji
W CLI mam uruchomionego agenta. Pytam: „Czy mogę połączyć Orbit ze Slackiem?”. To pytanie w ogóle nie wymaga capability eskalacji — potrzebne jest tylko przeszukanie bazy wiedzy. I rzeczywiście agent odpowiada, że Orbit nie ma jeszcze natywnej integracji ze Slackiem, choć jest ona w planach, i powołuje się na znaleziony w bazie dokument. Widać, że z dostarczonych capabilities wykorzystał wbudowaną capability „thinking” oraz własną capability bazy wiedzy — załadował instrukcje obu i użył narzędzia przeszukiwania bazy. Capability eskalacji nie ruszył, i słusznie: ładowanie tych tokenów nie miałoby wartości, a spowolniłoby agenta i podniosło koszt wywołania.
(Informacja dodatkowa: „Orbit” to fikcyjny produkt użyty w demonstracji.)
Teraz przypadek, w którym eskalacja jest potrzebna: „W tym miesiącu obciążono mnie dwukrotnie za subskrypcję. Czy możecie zwrócić zdublowaną opłatę?”. Tutaj capability eskalacji zostaje załadowana, tworzone jest zgłoszenie i agent podaje jego identyfikator. To oczywiście dane pozorowane na potrzeby demo, ale idea jest jasna: agent sam wybiera potrzebne capabilities. Dzięki temu jest nie tylko bardziej składalny (łatwiej dzielić go z innymi agentami), ale też w bieżącej rozmowie skupia się wyłącznie na odpowiedzialnościach faktycznie potrzebnych w tym kontekście.
Lean core i harness
Ostatni istotny temat z artykułu to „harness” i odchudzony rdzeń Pydantic AI. Framework ma teraz dwie warstwy capabilities.
Pierwsza to capabilities uznane za krytyczne dla większości agentów: zwykle chcesz „thinking”, chcesz wyszukiwania w sieci, chcesz „tool search”, które daje progressive disclosure i pozwala skalować agentów. To importujesz wprost z Pydantic AI — są wspierane bezpośrednio, są częścią odchudzonego rdzenia (lean core), a dodanie ich sprowadza się do wpięcia jako capability i ewentualnego dostrojenia paru parametrów, jak przy „thinking”.
Druga warstwa to harness — capabilities, które Pydantic AI chce wspierać bezpośrednio, ale nie uznaje ich za krytyczne dla większości zastosowań. Dobrym przykładem jest „code mode”: danie agentowi możliwości pisania i wykonywania kodu w sandboksie. To ważne dla sporej części agentów, ale może nie dla większości. Ciekawostka: firma stojąca za Pydantic AI pracuje nad własnym lekkim sandboksem o nazwie Monty, również open source — temat na osobny film, ale poza zakresem tego materiału. Harness to więc opakowanie ponad odchudzonym rdzeniem — stąd nazwa. Podoba mi się to podejście: rdzeń zostaje lekki, a jednocześnie masz mnóstwo gotowych elementów, po które możesz sięgnąć.
Podsumowanie
To wszystko, co przynosi wydanie Pydantic AI 2.0 i nowa idea capability jako jednego prymitywu do budowania agentów. To uproszczenie, które nie odbiera agentom mocy. Zachęcam, żeby po prostu z tym poeksperymentować. Sam wciąż używam Pydantic AI cały czas — bo kiedy chcesz wdrożyć agenta na produkcję i mają z niego korzystać inni ludzie, nie możesz oprzeć się wyłącznie na SDK agentów kodujących ani na narzędziach typu Hermes czy Open Claw. Potrzebujesz frameworka, a Pydantic AI naprawdę jest moim wyborem numer jeden. Planuję więcej materiałów na jego temat.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Capability jako jeden prymityw budulcowy agenta
Na czym polega: Pydantic AI 2.0 sprowadza budowę agenta do składania „capabilities” — jednostek pakujących instrukcje, narzędzia, hooki, guardraile i ustawienia modelu w jeden składalny klocek.
Jak stosować: Projektuj agenta jako listę capabilities odpowiadających jego odpowiedzialnościom (np. „baza wiedzy”, „eskalacja”), zamiast wrzucać wszystkie narzędzia i instrukcje w jeden monolit.
Na co uważać: Sama abstrakcja nie zastąpi dobrego podziału odpowiedzialności — źle wyznaczone granice capability przeniosą bałagan z 1.0 do 2.0. Zaplanuj, co jest osobną, wielokrotnie używalną jednostką.
2.Ponowne użycie capabilities między agentami
Na czym polega: Tę samą capability (np. dostępu do bazy wiedzy) możesz wpiąć do wielu agentów, a jej ulepszenia natychmiast trafiają do wszystkich.
Jak stosować: Wydzielaj wspólne funkcje (RAG, autoryzacja, logowanie) jako osobne capabilities i współdziel je między agentem wsparcia a np. widżetem FAQ, zamiast duplikować kod.
Na co uważać: Współdzielenie oznacza wspólny los — zmiana w jednej capability wpływa na wszystkich jej konsumentów. Testuj zmiany pod kątem każdego agenta, który jej używa.
3.Capability jako warstwa ponad MCP
Na czym polega: Serwer MCP to podzbiór capability (tylko narzędzia); capability dokłada instrukcje, guardraile, hooki i ustawienia.
Jak stosować: Jeśli masz już serwery MCP, opakuj je w capability wraz z instrukcjami i zabezpieczeniami, zamiast podpinać same narzędzia bez kontekstu.
Na co uważać: Nie myl warstw — samo dodanie MCP nie daje ci guardraili ani hooków. Kontekst i zabezpieczenia trzeba świadomie dopisać w capability.
4.Progressive disclosure oszczędza tokeny i pozwala skalować
Na czym polega: Agent widzi krótkie opisy wszystkich capabilities, ale pełne instrukcje ładuje dopiero, gdy dana zdolność jest faktycznie potrzebna.
Jak stosować: Dostarczaj agentowi wiele capabilities z trafnymi, zwięzłymi opisami — model wybierze właściwe na podstawie zapytania, bez przeciążania kontekstu.
Na co uważać: Jakość opisu decyduje o trafności wyboru. Zbyt ogólny opis sprawi, że agent załaduje niepotrzebną capability (koszt, spowolnienie) albo pominie potrzebną.
5.Nie pisz kodu Pydantic AI ręcznie — skieruj asystenta na dokumentację
Na czym polega: Twórcy wprost zalecają wskazanie asystentowi kodowania dokumentacji capabilities; jest ona obszerna i przeznaczona do konsumpcji przez model, nie przez człowieka.
Jak stosować: Podaj asystentowi kodowania link do dokumentacji capabilities (lub repo-szablon) i pozwól mu wygenerować szkielet agenta, zamiast pisać boilerplate ręcznie.
Na co uważać: Wygenerowany kod i tak trzeba zweryfikować pod kątem guardraili i bezpieczeństwa — autor mówi o wygodzie, nie o zwolnieniu z odpowiedzialności za przegląd.
6.Hooki dla deterministycznej kontroli i bezpieczeństwa
Na czym polega: W capability możesz umieścić hooki (np. „pre-tool use”), które wykonują deterministyczną akcję przed użyciem narzędzia — dla bezpieczeństwa lub prowadzenia agenta.
Jak stosować: Używaj hooków do walidacji, filtrowania danych wejściowych lub blokowania niebezpiecznych wywołań, zamiast liczyć wyłącznie na instrukcje w promptcie.
Na co uważać: Hook to logika, którą trzeba utrzymywać — nadmiar hooków utrudni debugowanie przepływu. Stosuj je tam, gdzie deterministyczna gwarancja naprawdę jest potrzebna.
7.Podział na lean core i harness
Na czym polega: Framework rozdziela capabilities krytyczne dla większości agentów (lean core: thinking, web search, tool search) od dodatkowych (harness, np. code mode).
Jak stosować: Zaczynaj od lekkiego rdzenia i dokładaj capabilities z harnessu tylko, gdy przypadek użycia tego wymaga — utrzymasz agenta szczupłym i szybkim.
Na co uważać: Capabilities z harnessu (jak wykonywanie kodu w sandboksie) niosą większe ryzyko i koszt. Włączaj je świadomie, a nie „na wszelki wypadek”.
8.Code mode i sandbox Monty
Na czym polega: „Code mode” daje agentowi możliwość pisania i uruchamiania kodu w sandboksie; Pydantic rozwija do tego własny lekki, otwarty sandbox Monty.
Jak stosować: Sięgaj po code mode w zadaniach wymagających obliczeń czy transformacji danych, które trudno opisać samymi narzędziami; rozważ Monty jako lekką opcję izolacji.
Na co uważać: Wykonywanie kodu generowanego przez model to poważna powierzchnia ataku i zasobożerność — bez solidnej izolacji nie uruchamiaj go w produkcji.
9.Framework, a nie SDK agenta kodującego, do wdrożeń produkcyjnych
Na czym polega: Autor twierdzi, że do agentów obsługujących realnych, zewnętrznych użytkowników potrzebny jest framework taki jak Pydantic AI, a nie SDK typu Claude/Codex czy Hermes/Open Claw.
Jak stosować: Do osobistych, jednorazowych agentów wybieraj szybkie SDK; do produkcji z wieloma użytkownikami wybieraj framework dający kontrolę, wydajność i mniejsze zużycie tokenów.
Na co uważać: To opinia autora, nie prawo — SDK agentów kodujących są wolniejsze i bardziej tokenożerne, ale prostsze; oceń kompromis wydajność/koszt/kontrola dla własnego przypadku.
10.Uproszczenie bez utraty kontroli i mocy
Na czym polega: Model capability upraszcza sposób myślenia o agencie, nie odbierając możliwości dostosowania — obszerna dokumentacja pokazuje, jak dużo kontroli wciąż masz.
Jak stosować: Traktuj capability jako domyślny sposób organizowania agenta, ale korzystaj z pełnej konfigurowalności tam, gdzie potrzebujesz precyzyjnego zachowania produkcyjnego.
Na co uważać: „Prostsze na wierzchu” nie znaczy „proste pod spodem” — pełne opanowanie frameworka wymaga czasu, a długa dokumentacja jest sygnałem złożoności, nie tylko elastyczności.