O czym jest ten film
- Metody, które czynią agentów kodujących coraz pewniejszymi, przenoszą się niemal jeden do jednego na agenty produkcyjne — kluczowa jest tzw. inżynieria harnessu, czyli ciągłe doskonalenie całej otoczki modelu: reguł, umiejętności i przepływów pracy.
- Współczesne agenty produkcyjne buduje się tak jak agenty kodujące: konfigurację trzyma się w markdownie (instrukcje, umiejętności, pamięci), a nie w kodzie. W pokazanym przykładzie definicja agenta to zaledwie 30 linii Pythona.
- Elementy tej otoczki mają bezpośrednie odpowiedniki: reguły = system prompt, sub-agensi = delegowanie zadań, narzędzia MCP = integracje, umiejętności = workflow, hooki = barierki bezpieczeństwa.
- Pierwsza pętla uczenia: agent sygnalizuje niepewność i kieruje sprawę do skrzynki zespołu; człowiek podaje poprawną odpowiedź, a agent zapisuje ją jako lekcję — do wspólnej pamięci oraz do pamięci danego użytkownika.
- Druga pętla: silnik analizujący ślady produkcyjne (w demo LangSmith Engine) wskazuje konkretne porażki i proponuje zmiany w instrukcjach, które człowiek zatwierdza jednym kliknięciem.
- Demonstracja na help desku dla społeczności: po jednej poprawionej lekcji agent sam rozwiązuje podobny, ale nieidentyczny problem zgłoszony przez innego użytkownika.
- Zasada nadrzędna: agent sam wykrywa błędy i przygotowuje poprawki, ale każdą z nich akceptuje człowiek — analogia do pull requestów znanych z pracy nad agentami kodującymi.
- Zmiany otoczki są wersjonowane jak commity: można awansować wersje i cofać je, gdy poprawka coś pogorszy.
- Efekt obu pętli na 14 pytaniach z realnych rozmów: wzrost z 4 poprawnych odpowiedzi do 13.
- Demonstracje wykonano na platformie LangChain Managed Deep Agents (materiał sponsorowany), ale autor podkreśla, że same strategie są uniwersalne.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Inżynieria harnessu to proces ciągły, nie jednorazowy projekt
Na czym polega: Siła agentów kodujących bierze się stąd, że ich reguły i umiejętności są stale poprawiane na podstawie realnych błędów. To samo trzeba robić z agentami produkcyjnymi: zbierać błędy z produkcji i wracać do nich, uzupełniając dokumenty konfiguracyjne.
Jak stosować: Wprowadź stały rytm przeglądu błędów agenta (np. co tydzień) i traktuj każdy poważniejszy błąd jako materiał do zmiany w markdownie, a nie tylko incydent do załagodzenia.
Na co uważać: Wdrożenie agenta to dopiero start — jeśli po nim nikt nie odpowiada za doskonalenie reguł, agent zostanie na poziomie z dnia wdrożenia.
2.Konfiguruj agenta produkcyjnego w markdownie, nie w kodzie
Na czym polega: Instrukcje (odpowiednik system promptu), umiejętności i pamięci to dokumenty markdown, a nie zakodowana na sztywno logika. W pokazanym przykładzie cała definicja agenta to 30 linii kodu plus markdown.
Jak stosować: Wynieś z kodu wszystko, co opisuje zachowanie agenta, do plików typu instructions.md i folderu umiejętności — zmiana zachowania agenta staje się edycją dokumentu, a nie wdrożeniem nowej wersji aplikacji.
Na co uważać: Część „hydrauliki” (integracje, uwierzytelnianie, działanie narzędzi) słusznie zostaje w kodzie — nie przenoś do markdowna rzeczy, które z natury są logiką programistyczną.
3.Przenoś mapowanie komponentów z agentów kodujących
Na czym polega: Elementy otoczki mają odpowiedniki jeden do jednego: reguły pełnią rolę system promptu, sub-agensi odpowiadają delegowaniu w przepływach wieloagentowych, narzędzia MCP warstwie integracji, umiejętności zastępują tradycyjne narzędzia, a hooki działają jak barierki monitorujące lub blokujące wywołania.
Jak stosować: Projektując agenta produkcyjnego, zacznij od tej samej listy elementów, którą znasz z agenta kodującego — każdy ma swojego odpowiednika.
Na co uważać: Barierki na wywołaniach narzędzi i na granicach rozmów to warstwa bezpieczeństwa; pominięcie ich przy przenoszeniu architektury zostawia agenta bez nadzoru.
4.Niech agent sygnalizuje niepewność i eskaluj ją do człowieka
Na czym polega: Duże modele językowe halucynują, ale zaskakująco dobrze wykrywają własną niepewność. Agent powinien próbować pomóc, a jednocześnie jawnie przyznawać „nie wiem” i wysyłać sprawę do skrzynki zespołu, gdzie człowiek potwierdza właściwą odpowiedź.
Jak stosować: Zbuduj skrzynkę eskalacyjną i mechanizm „potwierdź poprawkę” — odpowiedź człowieka staje się lekcją zapisywaną do pamięci współdzielonej oraz do pamięci danego użytkownika.
Na co uważać: Agent nie może się całkiem blokować w oczekiwaniu na człowieka: niepewność jest sygnalizowana, ale próba pomocy trwa. Z drugiej strony nadmiar eskalacji zaleje zespół.
5.Rozdzielaj pamięć współdzieloną i pamięci indywidualne użytkowników
Na czym polega: Lekcje z eskalacji trafiają w dwa miejsca: do wspólnej bazy rdzennych reguł (rodzaj wewnętrznego agents.md) oraz do prywatnej pamięci konkretnego użytkownika. Rozdzielenie gwarantują barierki.
Jak stosować: Już na etapie projektu pamięci przewiduj dwa poziomy i pilnuj, by użytkownicy nie mieli wglądu w pamięci innych — to kwestia prywatności i zaufania.
Na co uważać: Prywatne szczegóły jednej osoby nie mogą wpływać na odpowiedzi dla innych; mieszanie poziomów pamięci to prosta droga do wycieku kontekstu między użytkownikami.
6.Ucz lekcjami, ale pobieraj je selektywnie
Na czym polega: Wspomnienia nie są wrzucane w całości do kontekstu obok instrukcji — agent przeszukuje je w razie potrzeby (tzw. hub kontekstu) i potrafi uogólniać: inny użytkownik, podobny problem, pewna odpowiedź.
Jak stosować: Zadbaj o efektywne wyszukiwanie po lekcjach i celowo testuj, czy agent przenosi wnioski na podobne, ale nieidentyczne przypadki.
Na co uważać: Mechaniczne dokładanie lekcji do głównych instrukcji spuchnie kontekst. Lekcje trzymaj jako bazę do przeszukiwania, a do instrukcji przenoś tylko regularnie powtarzające się wzorce.
7.Ślady produkcyjne to żyła złota — większość je ignoruje
Na czym polega: Druga pętla opiera się na telemetrii z prawdziwych rozmów (w demo: ślady LangSmith). Silnik analizuje porażki i dla każdej podaje opis, dowód w postaci pełnego przebiegu rozmowy oraz konkretną propozycję poprawki instrukcji.
Jak stosować: Włącz pełne śledzenie przebiegów od pierwszego dnia produkcji i przeglądaj porażki razem z przyczynami — one wskazują, co w regułach wymaga naprawy.
Na co uważać: Bez śladów nie ma czego analizować; przy szczątkowej telemetrii obie pętle uczenia obracają się w próżni.
8.Poprawki przygotowuje agent, zatwierdza człowiek
Na czym polega: Silnik na podstawie śladów sam formułuje i wpisuje zmiany, ale każda wymaga zatwierdzenia — dokładnie tak, jak przy agentach kodujących akceptujemy pull requesty do reguł i umiejętności.
Jak stosować: Wprowadź jawny punkt akceptacji dla każdej zmiany reguł, umiejętności i pamięci; to ty decydujesz, co wchodzi na produkcję.
Na co uważać: Pełna autonomia w samodoskonaleniu oznacza utratę kontroli nad kierunkiem rozwoju agenta — przestajesz wiedzieć, dokąd zmierza.
9.Wersjonuj zmiany otoczki i umożliw cofnięcie
Na czym polega: Każda zmiana to osobny „commit” z możliwością awansowania wersji i cofnięcia. Jeśli zaproponowana poprawka pogorszy agenta, wraca się do poprzedniej wersji i świat się nie zawali.
Jak stosować: Prowadź historię zmian reguł i umiejętności tak samo jak historię kodu; przed awansowaniem nowej wersji porównaj jej zachowanie na testach.
Na co uważać: Zmiany bez historii są nieodwracalne — jedna niefortunna „poprawka” może zepsuć zachowanie, które dotąd działało.
10.Mierz postęp na stałym zbiorze testowym
Na czym polega: Autor przetestował agenta na 14 pytaniach odzwierciedlających realne zapytania: przed procesem uczenia 4 poprawne odpowiedzi, po przejściu obu pętli — 13.
Jak stosować: Przygotuj zestaw pytań z prawdziwych rozmów i uruchamiaj go po każdej większej zmianie konfiguracji — to jedyny sposób, by wiedzieć, czy poprawki faktycznie pomagają.
Na co uważać: Stu procent nie ma — dąż do wysokiego, ale realnego progu i odświeżaj zbiór o nowe, trudne przypadki, inaczej przestanie być wyzwaniem.
Redakcyjne tłumaczenie
Od agentów kodujących do agentów produkcyjnych
W tym roku na kanale zajmowałem się głównie agentami AI do programowania. Ale to, czego wiele osób — być może także ty — nie dostrzega, to fakt, że sporo strategii, dzięki którym nasi agenci kodujący z czasem pracują pewniej, świetnie sprawdza się również w innych rodzajach agentów wdrażanych na produkcję, do automatyzacji i zastosowań biznesowych. Jednym z najważniejszych takich pomysłów jest inżynieria harnessu: systematyczne poprawianie wszystkiego, co otacza model — reguł i przepływów pracy.
Oczywiście każdy chce, żeby jego agent z czasem radził sobie lepiej. Ale konkretnie chodzi mi o co innego: o rejestrowanie wszystkich błędów, jakich agent dopuszcza się na produkcji, a następnie o powrót do nich i wspólną rozmowę z agentem — jak powinniśmy poprawić twoje reguły i umiejętności, żeby te pomyłki się nie powtarzały. Uczę tego od dawna w kontekście agentów kodujących, a przy agentach produkcyjnych zasada jest identyczna.
To przełożenie działa lepiej, niż mogłoby się wydawać, bo dzisiejsze agenty produkcyjne buduje się w zasadzie tak samo jak kodujące: całą otoczkę zarządzamy przede wszystkim markdownem, co daje ogromną elastyczność. Stare podejście polegało na zapisywaniu całej „hydrauliki” bezpośrednio w kodzie — na przykład na pisaniu funkcji w Pythonie czy TypeScripcie dla naszych narzędzi. Dziś umiejętności to dokumenty markdown, globalne reguły to plik w rodzaju instructions.md, do tego pamięci. Jeśli pracujesz z agentami kodującymi, powinno być ci to znajome — konstrukcja otoczki jest niemal ta sama.
Odpowiedniki jeden do jednego
Przełożenie działa tak dobrze, że wszystkie elementy inżynierii agentowej mają swoje wprost odpowiadające imniki u agentów produkcyjnych. Reguły — dla klasycznego agenta to dokładnie to samo, co system prompt. Sub-agensi — odpowiednik przepływów wieloagentowych, wszędzie tam, gdzie dochodzi do delegowania zadań. Narzędzia MCP stanowią warstwę połączeń. Umiejętności pełnią rolę przepływów pracy i zastępują wiele tradycyjnych narzędzi. No i hooki — czyli barierki: jeśli chcemy monitorować lub blokować poszczególne wywołania narzędzi albo początek i koniec rozmów, służą do tego właśnie one.
Pokażę dziś nie tylko, jak zbudować taką otoczkę, ale też jak ją z czasem doskonalić dwiema podstawowymi pętliami. Pierwsza to pamięć agenta. Druga to wspomniane poprawianie wstecz — analiza śladów prowadzona wtedy, gdy agent pracuje na produkcji z prawdziwymi użytkownikami. To żyła złota informacji, której nie wolno bagatelizować — a większość ludzi właśnie to robi.
Platforma: Managed Deep Agents od LangChain
Potrzebny jest jeszcze system, który zwiąże wszystkie te markdownowe dokumenty w całość przy wdrożeniu agenta na produkcję. Możesz go zbudować samodzielnie, jeśli chcesz osobiście zarządzać wdrożeniem i potokami doskonalenia otoczki — nie ma w tym nic złego. Najczęściej jednak praktyczniej sięgnąć po platformę, która robi to za ciebie. Dlatego we wszystkich demonstracjach posłużę się Managed Deep Agents od LangChain, które konfiguruje całość w LangSmith. Widziałem, jak to rozwiązanie sprawdza się na produkcji raz za razem. A przy okazji: strategie są uniwersalne — działają niezależnie od tego, jak budujesz agentów.
Krótkie podziękowanie dla LangChain za współpracę przy tym materiale — najwyższy czas, bo ich platform używam bez przerwy. Mała podróż w przeszłość: jeden z pierwszych filmów na moim kanale, ponad dwa lata temu, dotyczył agentów ręcznie kodowanych z LangChain jako frameworkiem, więc ten temat mam u siebie sentymentalnie. Korzystam z nich nadal, bo LangChain zawsze pozostawał w czołówce — zwłaszcza teraz, gdy Managed Deep Agents pozwala wdrażać agentów na modłę agentów kodujących. Dochodzą do tego śledzenie i metryki, które napędzają całą tę inżynierię: pokazują, gdzie agent się myli, a nawet podsuwają propozycje poprawek do automatycznego zastosowania.
Trzydzieści linii kodu i stos markdownów
Wróćmy pamięcią do tego, jak budowało się agentów rok–dwa lata temu: mnóstwo kodu. Trzeba było go napisać bardzo dużo, żeby postawić barierki, narzędzia, podpiąć system prompt i tak dalej. A teraz spójrzcie na plik agent.py — ma 30 linii. Tyle wystarcza, by zdefiniować agenta łącznie z barierkami, sub-agensami, wszystkimi narzędziami, umiejętnościami i instrukcjami, bo to wszystko jest po prostu opisane w dokumentach markdown. Drobiazg definicji wciąż zapisujemy w kodzie — odrobina „hydrauliki” została — ale w dużej mierze działa to jak u agentów kodujących: elementy są wykrywane automatycznie. Plik instructions.md wystarczy umieścić w katalogu głównym folderu agenta — zupełnie jak CLAUDE.md czy agents.md u agenta kodującego — i zostanie podchwycony sam. Umiejętności trzymamy w folderze skills, analogicznie do folderów znanych z Claude Code czy Codexa. Kiedy pakujemy całość, by uruchomić ją lokalnie albo wdrożyć na produkcję, LangChain w tle spina wszystko w jedną całość. Budowanie i zarządzanie agentem jest więc bardzo proste, a przy tym elastyczne: jeśli nie jesteśmy zadowoleni z jego działania, po prostu zmieniamy dokumenty markdown — dokładnie tak, jak w ewolucji systemu, jak nazywam to u agentów kodujących.
Pierwsza pętla: pamięć, niepewność i skrzynka zespołu
Za kulisami dzieje się jeszcze więcej: ewaluacje i mechanizmy uczenia, które czynią otoczkę coraz lepszą. Niezależnie od tego, jakiego agenta wdrażasz, potrzebujesz systemu tego typu. LangChain robi to naprawdę dobrze i z tego rozwiązania można czerpać mnóstwo inspiracji — pokażę je na żywo.
Potrzebujemy przede wszystkim sposobu, by agent wyciągał wnioski w trakcie pracy na produkcji. Oznacza to także eskalowanie niektórych spraw do człowieka. Kiedy ktoś rozmawia z naszym agentem, a agent sobie nie radzi, powinien to rozpoznać i przekazać niepewność dalej. Potrzebna jest więc skrzynka, w której zarządzamy sprawami budzącymi wątpliwości. Podajemy właściwą odpowiedź i dbamy o to, by agent zapisał ją jako lekcję. LangChain nazywa to hubem kontekstu: przechowujemy tam wspomnienia, agent może je w każdej chwili pobrać i skojarzyć — „aha, tę sytuację już obsługiwałem, tak poprawił mnie człowiek, więc tym razem odpowiem właściwie”.
To bardzo ważne, bo gdy dopiero wypuszczamy agenta do prawdziwych użytkowników, w zasadzie nie znamy luk w jego wiedzy i procesach. Modele językowe — tak, halucynują, ale zaskakująco dobrze ujawniają własną niepewność. Możemy więc te rzeczy prostować i kumulować wnioski. Dochodzi do tego sprawna strategia pobierania: nie wrzucamy wszystkich lekcji do kontekstu obok głównych instrukcji. Z lekcji można też korzystać przy poprawianiu samych instrukcji — wrócimy do tego przy drugiej pętli — ale tu chodzi o budowanie bazy wiedzy o obsłudze kluczowych sytuacji z klientami i użytkownikami. Ludzie zwykle korzystają z agenta dość podobnie, więc taka baza, gromadzona w hubie kontekstu, pomaga bardzo mocno. A im lepiej agent działa, tym mniej spraw trafia do eskalacji — nie staje się to rosnącym ciężarem dla zespołu.
W pakiecie produkcyjnym mojego agenta w Managed Deep Agents, w folderze pamięci, mamy kilka rzeczy. Przede wszystkim wszystkie przypadki — sprawy, w których agent nie był pewien i eskalował je do mojej skrzynki zespołu (pokażę ją za chwilę). Wnoszę poprawkę, a agent zapamiętuje ją osobno dla danego użytkownika i jednocześnie buduje rodzaj wewnętrznego agents.md — rdzenne reguły wyuczone z lekcji, których udzieliłem mu przez eskalacje.
Demonstracja: help desk dla członków społeczności
Czas na praktykę. Zbudowałem własny pulpit z wersją demonstracyjną prawdziwego agenta, nad którym pracuję — help desku dla członków społeczności Dynamous. To dowód, że jeszcze przed nagraniem testowałem, jak agent potrafi w zaskakującym stopniu sam się doskonalić. Pokażę jeden przykład, a dane celowo uprościłem.
Mam więc help deska, w którym udaję różnych członków społeczności zadających pytania o Archon — narzędzie, które rozwijam — o treści kursu i tak dalej. (Informacja dodatkowa: Archon to open-source’owy projekt autora kanału, służący do budowania agentów AI.) Teraz jestem Nina i piszę do agenta wsparcia: „Cześć, jestem Nina. Zacommitowałam lokalnie poprawkę komendy w moim plan.md i uruchomiłam workflow Archona, ale run użył starej treści tej komendy”. Brzmi podejrzanie konkretnie? To autentyczne pytanie, jakie dostałem o Archona kilka tygodni temu — wszystko, czego tu używam, opiera się na prawdziwych zapytaniach.
Agent odpowie za chwilę, ale — jak zobaczycie — nie będzie pewien swojej odpowiedzi. Chwilę mu zajęło, zanim zaczął „myśleć”, bo musiałem skompilować agenta lokalnie, ale potem całość trwała około dziesięciu sekund: przeszukanie wspomnień tej osoby, załadowanie umiejętności diagnostycznej i aktualizacja jej wspomnień. Mamy więc indywidualne pamięci użytkowników — jeszcze do nich wrócę. Najważniejsze jednak jest to, co powiedział help desk: „Nie mam wystarczająco danych, by orzec na pewno”. Nadal próbował pomóc — nie chcemy, by agent całkiem się zablokował i czekał na człowieka — ale swoją niepewność wyniósł do góry.
Teraz spójrzcie na moją skrzynkę zespołu. Przed tą rozmową były w niej cztery sprawy, teraz jest pięć — właśnie doszło coś eskalowanego do mnie. Widzę pytanie użytkownika, odpowiedź help deska i muszę potwierdzić poprawkę. Mogę albo skorygować agenta, albo przyznać, że zrobił dobrze — w obu wypadkach zaktualizuje pamięci i wyciągnie lekcję, by następnym razem być pewnym. Tu rozwiązanie już znam: Archon tworzy worktree’e (odizolowane katalogi robocze gita) na podstawie gałęzi origin/main, więc trzeba wykonać git push i uruchomić workflow ponownie. Wysyłam to agentowi, klikam „potwierdź poprawkę” — i agent uczy się z tego lekcji. Po dziesięciu sekundach mam potwierdzenie: nowe współdzielone wspomnienie, lekcja odnotowana. Zaktualizował rdzenny plik agents.md w folderze pamięci oraz prywatną pamięć Niny.
A to kluczowe: jeśli ktoś inny trafi na podobny problem, odpowiedź będzie dużo pewniejsza. Sprawdźmy. W czatach wciadam się w inną osobę: „Jestem Omar. Mój run Archona zakończył się na zielono, czyli sukcesem, i otworzył PR, ale w diffie brakuje trzech commitów, które zrobiłem dziś rano. To bug czy co?”. Problem nie jest identyczny jak u Niny, ale wystarczająco podobny, by agent mógł skorzystać z tamtej lekcji. Celowo nie pokazuję sceny, w której to dosłownie ten sam kłopot — chcę udowodnić, że agent potrafi uogólniać na podstawie wspomnień. I proszę: tym razem nie przyznał się do niepewności. Odpowiedział: „prawdopodobnie to nie bug” i wyjaśnił dokładnie, jak działa Archon. To dokładnie ta lekcja, którą przed chwilą mu przekazaliśmy — i dzięki niej odpowiedź była bardzo solidna.
W zakładce pamięci, podpiętej wprost do LangChain, mogę zajrzeć do folderu przypadków i faktycznie: nowe wspomnienie — Archon buduje worktree z origin/main, rozwiązaniem był git push i ponowny run workflow. To dokładnie to samo, co widzieliśmy w przypadkach w Managed Deep Agents. W kontekście obejzymy też pamięci per użytkownik — to wspomnienia wyłącznie Niny. I to ważne: rozdzielenie gwarantują barierki oraz sam agent. Pamięci użytkowników nigdy się nie mieszają i nikt nie podejrzy cudzych wspomnień.
Druga pętla: poprawki na podstawie śladów produkcyjnych
Została nam druga pętla. Dużo mówiliśmy o pamięci — to ważna część hubu kontekstu, ale nie główny element otoczki. Lekcje dotyczące pojedynczych przypadków to dobry zasób do przeszukiwania w razie potrzeby, jednak mamy wyższy poziom: rdzenne workflow i instrukcje, i to je chcemy z czasem aktualizować, ucząc się zarówno z lekcji, jak i z pozostałych śladów danych produkcyjnych.
To druga strona Managed Deep Agents: silnik, który pod spodem czerpie z LangSmith dane przebiegów, a potem je zbiera i zaczyna proponować ulepszenia na podstawie porażek widocznych w prawdziwych danych. Mam tu rzeczywisty przykład niepowodzenia z moich runów produkcyjnych. Na górze szczegółowy opis; jeśli temat mnie interesuje, sięgam po dowód w postaci śladu z LangSmith — mogę wejść w konkretną rozmowę i zobaczyć, co robił model, gdy powstał problem. A moja ulubiona część jest na dole: proponowana poprawka. To wszystko pracuje w tle dzięki LangSmith Engine, który wskazuje wprost, co zmienić w instructions.md. Dokładnie ta sama ewolucja systemu, którą znamy z agentów kodujących: przegląd całej otoczki — reguł, barierków, instrukcji — i decyzja, co dostroić, żeby ten typ problemu się nie powtórzył. Propozycja jest zwięzła, bo nie chcę nadymać reguł, upychając w nich masę nowego kontekstu. Klikam „zastosuj” i zmiana natychmiast trafia do agenta produkcyjnego.
Człowiek w pętli: zatwierdzanie, wersje, cofanie zmian
Zatwierdzam więc poprawki i pozwalam agentowi naprawiać się w czasie rzeczywistym — ale tylko te, które nadzoruję. Nie chcę, by agent całkowicie samodzielnie się doskonalił, bo wtedy tracę nad nim kontrolę i nie wiem, dokąd zmierza. To wielki motyw całego materiału: agent zawsze ma sam wykrywać i wprowadzać poprawki, ale my musimy pozostać w pętli i je zatwierdzać. W zakładce kontekstu — wszystkie pamięci tworzone dla pojedynczych osób, główne wyciągane lekcje — zawsze uczestniczymy w każdej z nich. W umiejętnościach i instrukcjach również nic nie zmienia się bez naszej akceptacji. Podobnie jak przy agentach kodujących, gdzie do aktualizacji reguł czy umiejętności zakładamy pull requesty, robimy tu to samo — tylko bezpośrednio w LangSmith, z Managed Deep Agents jako platformą.
I kontynuując analogię z pull requestami: mamy tu dosłownie commity. Mogę przejrzeć każdy z nich i zobaczyć, jak wyglądały poszczególne części mojej otoczki; mogę awansować wersje i cofać zmiany, gdy zajdzie potrzeba. Jeśli poprawki zaproponowane przez silnik pogorszą agenta, nie jest to tragedia — mamy pełną kontrolę nad systemem. Wdrożenie wszędzie jest przy tym banalnie proste: wdrożyłem go choćby do swojego Slacka i rozmawiam z agentem bezpośrednio tam.
Wynik: od 4 do 13 na 14 pytań
Pracowałem już z dużo większymi zbiorami danych, ale do tej demonstracji przygotowałem 14 pytań. Pierwsza wersja agenta — z początkowymi regułami i umiejętnościami — odpowiadała poprawnie tylko na 4 z 14. Po przejściu procesu uczenia: zastosowaniu lekcji oraz wykorzystaniu śladów LangSmith z proponowanymi przez silnik ulepszeniami — wynik wzrósł do 13 na 14. Modele językowe nie zawsze będą bezbłędne, stu procent nie osiągniemy, ale można się bardzo zbliżyć — i właśnie te dwie pętle prowadzą nas w tę stronę.
Podsumowanie
Tak właśnie pozwala się agentowi samemu zajmować inżynierią własnej otoczki — z tobą w pętli, zatwierdzającym każdą zmianę. Mam nadzieję, że materiał pokazał siłę Managed Deep Agents od LangChain, ale też ogólne idee inżynierii agentów wdrażanych na produkcję: przeniesienie rozwiązań z agentów kodujących, które sprawdzają się tak dobrze. Największa lekcja? Inżynieria harnessu to nie jednorazowe zadanie. Właśnie w tym pomaga Managed Deep Agents: daje agentowi otoczkę szytą na miarę, z dowolnym modelem, a na wierzchu dokłada LangSmith Engine, dzięki któremu harness może stale się poprawiać — przy twojej pełnej kontroli. Link do wypróbowania LangSmith znajdziesz w opisie filmu; z kodem „colem” dostajesz 50 dolarów kredytu. Dzięki LangChain za współpracę — a jeśli materiał ci się przyda i czekasz na więcej o inżynierii agentowej, polub film i zasubskrybuj kanał. Do zobaczenia w następnym odcinku.