Harness to produkt: praktyczny przewodnik po harnessach w sztucznej inteligencji agentowej

Załóżmy, że dajemy ten sam model językowy dwóm różnym zespołom. Zespół A tworzy agenta, który naprawia błędy w ogromnym repozytorium, uruchamia zestaw testów i składa schludną prośbę o połączenie kodu. Zespół B buduje asystenta do czatowania, który po kilku wiadomościach traci wątek rozmowy i z radością wymyśla politykę firmy. Wagi modelu są identyczne, a jednak wyniki są zupełnie różne.

Rama to całość, wokół której budowana jest cała struktura: obejmuje pętlę umożliwiającą działanie modelu, narzędzia, do których może się odwołać, sposób zarządzania jego oknem kontekstowym, zasady ograniczające, które zapobiegają podejmowaniu nierozsądnych decyzji, oraz informacje zwrotne wskazujące, czy odnosi sukces. To, co następuje, zaczyna od zera, wyjaśnia, czym jest agent, i omawia poszczególne elementy ramy, wzorce produkcji takie jak podagenty i kompresja, kilka dobrze znanych systemów oraz dostępne obecnie frameworki. Nie wymaga się żadnego wcześniejszego doświadczenia z agentami.

Podstawy

Co oznacza sztuczna inteligencja agentowa

Bez nadmiernego hajpu, agent to coś prostego:

Agent to model językowy działający w pętli, wykorzystujący narzędzia, aż zostanie osiągnięty cel.

Wymagają to trzech składników: modelu, który potrafi rozumować i wybrać następny krok, narzędzi, których model może używać, takich jak wyszukiwanie w sieci, dostęp do plików, wykonywanie kodu, wyszukiwanie w bazie danych lub wysyłanie e-maili, oraz pętli, która przekazuje wyniki każdego narzędzia z powrotem, aby model mógł zdecydować, co robić dalej.

Chatbot odpowiada raz i przestaje. Agent kontynuuje: podejmuje działanie, sprawdza jego rezultat, a następnie podejmuje kolejne. To właśnie ten cykl sprawia, że predyktor tekstu jest w stanie wykonywać rzeczywiste zadania, a reszta tego tekstu rozwija tę koncepcję.

Czym jest „harness”

Można myśleć o „harness” jako o środowisku wykonawczym tej pętli. Model decyduje, co powinno się wydarzyć dalej, podczas gdy „harness” realizuje to i zapewnia, że cały proces jest bezpieczny, dostępny finansowo, widoczny i kontrolowalny. Nazwa nawiązuje do środowiska testowego w oprogramowaniu lub do siodła u konia: surowa moc wymaga struktury, aby mogła być skierowana na użyteczną pracę.

W praktyce ten „ Harness” wykonuje żądania narzędzia skierowane do modelu, kontroluje to, co model widzi na każdym kroku, egzekwuje uprawnienia, radzi sobie z błędami, ponawianymi próbami i nieskończonymi pętlami, śledzi postęp i wie, kiedy zadanie jest zakończone, a kiedy należy przestać i poprosić człowieka o pomoc.

Jednym z przydatnych sposobów na to wyobrażenie jest ten: model nie ma pamięci między poszczególnymi rundami. Za każdym razem, gdy jest wywoływany, zaczyna od zera, czyta podany mu tekst i wytwarza jeden wynik. Wszystko inne – skrypt, elementy scenograficzne, scena oraz mechanizmy bezpieczeństwa – to właśnie „ Harness”. Jeśli to zmienimy, ten sam „aktor” będzie zachowywał się zupełnie inaczej.

Dlaczego „ Harness” jest ważny

Wyróżniają się trzy praktyczne powody.

Wyniki modeli topowych zbliżają się, podczas gdy narzędzia wspomagające nie. Modele z czołówki coraz bardziej różnią się pod względem surowych możliwości. W testach mierzących rozwiązywanie rzeczywistych problemów w oprogramowaniu ten sam model może osiągać znacznie różne wyniki, zależnie wyłącznie od narzędzi, wskazówek i pętli zwrotnej, które mu służą. W pewnym momencie to właśnie te narzędzia stają się decydującym czynnikiem.

Długie zadania powiększają wpływ małych błędów. Jeśli model jest w 99 procentach niezawodny na każdym kroku, zadanie składające się z 50 kroków udaje się tylko w około 60 procentach przypadków, ponieważ 0,99 w potęgę 50 wynosi mniej więcej 0,605. Weryfikacja, ponawianie prób, punkty kontrolne i korekta kursu to mechanizmy wspomagające, które przeciwdziałają temu efektowi kumulatywnemu. To one odróżniają wersję demonstracyjną od produktu gotowego do użycia.

Wolność wymaga ograniczeń. Każdy agent, który może wykonywać polecenia wiersza poleceń, przekazywać pieniądze lub korespondować z klientami, musi mieć określone limity uprawnień, środowiska testowe oraz rejestracje audytowe. Elementy te znajdują się w narzędziu sterującym, a model nie dostarcza żadnego z nich.

Anatomia narzędzia sterującego

Agenty do kodowania, badawcze agenty oraz agenty wsparcia zazwyczaj mają siedem wspólnych komponentów. Poniżej przedstawiono je pojedynczo.

1. Instrukcje systemowe, zasady działania

Tutaj agent otrzymuje informacje o swojej roli, ograniczeniach, zasadach postępowania oraz celu każdego narzędzia. W dojrzałych produktach tekst ten liczy tysiące słów i jest utrzymywany z taką samą starannością jak kod źródłowy, uwzględniając ton, bezpieczeństwo, moment zadawania pytań oraz sposoby radzenia sobie z niejasnymi instrukcjami.

Ciężko jest nowicjuszowi napisać choć jedną linijkę mówiącą, że agent jest przydatnym asystentem do programowania. Z kolei instrukcja produkcyjna określa procedury: otwarcie pliku przed edycją, preferowanie małych zmian, uruchamianie testów po każdej edycji, zatrzymanie się i zgłoszenie problemu po dwóch nieudanych próbach testów, a także nigdy nie wysyłanie zmian bezpośrednio do głównej gałęzi – dalej następuje wiele innych podobnych zasad.

2. Warstwa narzędzi, „ręce”

Narzędzie to funkcja, którą model może wywołać, zdefiniowana poprzez nazwę, opis oraz schemat typów dla jej argumentów. Model żąda wywołania w formie ustrukturyzowanego wyniku, po czym narzędzie je wykonuje i zwraca wynik.

Projektowanie narzędzi to niedoceniana umiejętność. Polega ono na projektowaniu API dla użytkownika bardzo dosłownego:

• Opisy pełnią rolę instrukcji. Model wybiera narzędzia na podstawie ich opisów, więc niejasny opis prowadzi do niewłaściwego narzędzia.
• Kilka dobrze skonstruowanych narzędzi jest lepszych niż wiele nakładających się na siebie. Rozproszenie narzędzi dezorientuje modele w taki sam sposób, w jaki menu z czterdziestoma pozycjami dezorientuje gości restauracji.
• Zwracaj błędy, na które model może zareagować. Komunikat informujący, że plik jest tylko do odczytu i że należy najpierw poprosić o dostęp, jest lepszy niż surowy zapis błędu.
• Utrzymuj niebezpieczne narzędzia w wąskich granicach. Narzędzie, które wysyła tylko uprzednio zatwierdzone projekty, jest znacznie bezpieczniejsze niż takie, które uruchamia dowolny kod.

Ważnym rozwojem w tym obszarze jest Model Context Protocol, który Anthropic udostępnił jako oprogramowanie otwarte pod koniec 2024 roku, a który przyjęła większość firm z branży. Standardyzuje on sposób, w jaki dostawcy narzędzi udostępniają je dowolnemu agentowi, stanowiąc coś w rodzaju uniwersalnego łącznika: wystarczy raz napisać integrację, a potem podłączyć ją do dowolnego systemu.

3. Zarządzanie kontekstem, pamięć robocza

Okno kontekstowe to cały świat percepcyjny modelu. Jego rozmiar zazwyczaj waha się od setek tysięcy do miliona tokenów, co wydaje się ogromne, dopóki agent nie przeczyta czterdziestu plików i nie wykona sześćdziesięciu poleceń.

Wybór tego, co model może zobaczyć na każdym kroku, jest prawdopodobnie najważniejszym elementem w tym systemie, a praktycy nazywają to inżynierią kontekstu, która w dużej mierze zastąpiła inżynierię promptów jako kluczowa umiejętność. Techniki te obejmują od prostych po zaawansowane: skracanie (przechowywanie tylko najnowszych wiadomości lub fragmentu pliku), wyszukiwanie (tworzenie indeksu bazy wiedzy i pobieranie wyłącznie tego, co jest aktualnie potrzebne) oraz kompresję. W przypadku kompresji, gdy okno jest już prawie pełne, model tworzy streszczenie sesji, które zastępuje surowy zapis i umożliwia kontynuację pracy. W ten sposób agenci mogą skupiać się na zadaniu przez wiele godzin.

4. Pamięć, długoterminowe przechowywanie

Kontekst trwa przez jedną sesję, natomiast pamięć pozostaje. Zazwyczaj wykorzystuje się kilka poziomów pamięci:

• pamięć projektu, np. pliki instrukcji w repozytorium, które uczą agenta programistycznego Twoich konwencji oraz poleceń budowania i są czytane na początku sesji,
• pamięć użytkownika, czyli preferencje nabyte w trakcie różnych rozmów,
• pamięć epizodyczna, która przechowuje informacje o poprzednich działaniach, często w bazie wektorowej, aby móc je odzyskać, gdy pojawią się podobne sytuacje.

5. Zasady bezpieczeństwa, uprawnienia i izolacja, hamulce

Poziom bezpieczeństwa ciągle sprawdza, czy dana akcja rzeczywiście powinna zostać wykonana. W praktyce oznacza to:

• Poziomy uprawnień. Czytanie odbywa się swobodnie, zapisy przechodzą kontrolę polityki, a nieodwracalne działania, takie jak wdrażanie, wysyłanie, usuwanie lub płatności, wymagają wyraźnej zgody człowieka.

Sandboxing. Kod jest wykonywany w izolowanych kontenerach z ścisłymi ograniczeniami dotyczącymi plików i sieci, dzięki czemu agent zdezorientowany lub przejęty przez wstrzyknięty tekst nie może zaszkodzić maszynie hostującej.

Filtering. Wyniki narzędzia są sprawdzane pod kątem prób wstrzykiwania kodu oraz wycieków poufnych danych.

Hard budgets. Limity liczby iteracji i wydatków zapobiegają niekontrolowanemu ich wykonywaniu. Większość systemów produkcyjnych ma historię wyjaśniającą powstanie tych ograniczeń, ponieważ nikt nie wprowadza ich proaktywnie.

6. Weryfikacja i informacje zwrotne – oczy

Nic nie poprawia agenta w bardziej niezawodny sposób niż możliwość sprawdzenia jego własnego wyniku. Agenty do programowania kompilują kod, sprawdzają jego poprawność i uruchamiają testy po każdej modyfikacji. Agenty badawcze porównują informacje z różnych źródeł. Agenty przeglądarkowe zapisują obraz ekranu, aby sprawdzić, co faktycznie zostało załadowane. Niektóre rozwiązania dodają osobę sprawdzającą – drugi model, który ocenia odpowiedź pierwszego modelu według określonych kryteriów, zanim zostanie ona przyjęta.

To bezpośrednio atakuje problem błędów kumulatywnych. Agent, który może zauważyć swój błąd, może spróbować ponownie, podczas gdy ten, który tego nie może, z pewnością przekaże błędne dane.

7. Obserwowalność, rejestr lotu

W środowisku produkcyjnym rejestrowane są każde żądanie modelu, każde wezwanie narzędzia oraz każdy wydany token. Dzięki tym śladom można odtworzyć nieudaną próbę, zlokalizować błędny krok i poprawić błędny prompt, narzędzie lub zasadę działania. Wokół tego rozwiązania powstała cała kategoria produktów, w tym LangSmith, Langfuse, Braintrust oraz konwencje OpenTelemetry dla sztucznej inteligencji generatywnej, ponieważ debugowanie agenta bez żadnych informacji jest równie trudne jak debugowanie usług rozproszonych bez logów.

Skuteczne prowadzenie procesu

Nazwanie poszczególnych elementów to najłatwiejsza część. Różnica pomiędzy rozwiązaniem, które sprawdza się podczas demonstracji, a tym, które funkcjonuje prawidłowo w normalnych warunkach pracy, wynika z poniższych praktyk.

Planuj, działaj, weryfikuj

Proste agenty od razu przystępują do pracy. Zaawansowane narzędzia wprowadzają określoną strukturę: opracowuje się plan poprzez podzielenie celu na listę zadań, podejmuje małe kroki, sprawdza każdy wynik przed kontynuacją, a następnie modyfikuje plan i próbuje ponownie. Pisany plan pełni dwie funkcje – utrzymuje model skupiony na długotrwałych zadaniach, ponieważ jest ponownie czytany przy każdej rundzie, a także umożliwia osobie obserwującej widzenie postępów w czasie rzeczywistym, co okazuje się cenniejsze, niż się spodziewano.

Strukturyzowane wyniki

Zawsze, gdy program ma przetwarzać wyniki modelu, należy to ograniczyć za pomocą schematu. Obecne API obsługują wymuszone wywołania narzędzi oraz generowanie weryfikowane według schematu. Proza jest przeznaczona dla ludzi; kod powinien mieć strukturę.

Koszt i opóźnienie

Agenci szybko zużywają tokeny, co sprawia, że aspekty ekonomiczne stają się istotnym problemem. Przechowywanie dużego statycznego prefiksu (promptu systemowego wraz z definicjami narzędzi) między rundami kosztuje znacznie mniej niż jego ponowna wysyłka, co jest dużym atutem w długich sesjach. Mechanizm routingu kieruje rutynowe kroki do małego, szybkiego modelu, a model zaawansowany zachowuje na kroki wymagające rozumowania. Niezależne podzadania, takie jak czytanie dziesięciu plików lub sprawdzanie pięciu źródeł, mogą być wykonywane równolegle.

Systemy wieloagentowe i więcej

Podagenty i orkiestracja

Gdy zadania przekraczają możliwości jednego okna kontekstowego, systemy stają się wieloagentowe. Orkiestrator dzieli cel i tworzy podagenty, z których każdy ma własny kontekst, zazwyczaj węższy zestaw narzędzi oraz precyzyjnie określone zadanie. Każdy podagent wykona swoją pracę i zwróci tylko swój wniosek, a nie całą historię swoich działań.

Prawdziwa korzyść jest mniej oczywista niż szybkość: każdy podagent działa we własnym, izolowanym kontekście, a nie tylko równolegle. Dziesięć podagentów może każdy wypełnić całe okno jednym podsystemem, podczas gdy orkiestrator przechowuje jedynie dziesięć krótkich streszczeń.

Powszechne topologie obejmują orkiestratora i pracowników (zdecydowanie najczęstsze), łańcuchy przetwarzania takie jak projekt, krytyka i poprawki, oraz panele debatowe, w których kilka agentów rozwiązuje problem niezależnie, a sędzia syntetyzuje odpowiedzi. Debata jest kosztowna, ale nadaje się do pytań o duże znaczenie.

Zespoły, które przygotowały ten raport, wyciągnęły kilka cennych wniosków:

• Określ oczekiwany poziom wysiłku dla każdego zadania, w przeciwnym razie nawet błahe pytanie może wywołać dziesiątki poszukiwań.
• Pisz instrukcje szczegółowe i samodzielne, ponieważ podagent nie może zobaczyć kontekstu swojego nadzorcy.

Należy jak najszybciej izolować przestrzenie robocze, ponieważ w końcu doszło do sytuacji, gdy dwa agenty edytowały ten sam plik.

Tworzenie punktów kontrolnych i trwałość

Agenty działające przez długi czas zawodzą w trakcie awarii, ograniczeń szybkości i restartów. Systemy produkcyjne wykorzystują stan punktów kontrolnych, obejmujący historię rozmów, listę zadań oraz wyniki narzędzi, dzięki czemu proces może być kontynuowany od kroku 37, a nie od początku. To właśnie domena trwałych silników workflow, a kilka frameworki dla agentów jest budowanych bezpośrednio na tej bazie.

Evals – zestaw testów systemu

Zachowanie agenta jest probabilistyczne, więc prompt, który działa w poniedziałek, może zawieść we wtorek. Silne zespoły utrzymują zestaw narzędzi oceniających zawierający od kilkudziesięciu do tysięcy realistycznych zadań, których wyniki można automatycznie sprawdzić. Czy testy przeszły, czy znaleziono właściwą odpowiedź, czy koszty pozostały w ramach budżetu? Edycje promptów, nowe narzędzia oraz zmiany modeli przechodzą przez ten zestaw przed wdrożeniem. Pełni on rolę, jaką w innych miejscach pełni CI/CD, a pominięcie go oznacza pracę bez odpowiednich narzędzi.

Używanie komputera – egzamin końcowy

Na najnowszych rozwiązaniach agenci otrzymują ekran, klawiaturę i myszkę i mogą uruchamiać dowolne aplikacje, niezależnie od tego, czy mają API, czy nie. To zwiększa trudność każdego z wcześniejszych problemów: zrzuty ekranu zużywają ogromną ilość tokenów, więc kontrola kontekstu musi być ścisła; błędny kliknięcie może spowodować poważne konsekwencje, więc uprawnienia są ściśle regulowane; a weryfikacja polega na rzeczywistym oglądaniu ekranu po każdym kroku.

Jak znane systemy stosują te koncepcje

Claude Code – narzędzie do programowania. Jest to zwięzła lekcja projektowania. Zestaw narzędzi jest mały, ale skuteczny – umożliwia czytanie, zapisywanie i edycję plików, wykonywanie poleceń w terminalu oraz wyszukiwanie kodu, bez setek drobnych narzędzi. Weryfikacja jest kluczowa: uruchamia kompilatory, narzędzia do sprawdzania kodu i testy, a w razie niepowodzenia powtarza proces. Plik z instrukcjami projektu pełni rolę pamięci. Nic z tego nie stanowi funkcji modelu, i właśnie dlatego ten sam model zachowuje się inaczej w jego środowisku.

Produkty oparte na dogłębnych badaniach, narzędzie do prowadzenia badań. Narzędzia badawcze z dużych laboratoriów przekształcają zapytanie w autonomiczne dochodzenie trwające wiele minut, które kończy się raportem z odnośnikami. Ich cechą charakterystyczną jest plan badawczy opracowany z góry, czasami przedstawiany do zatwierdzenia, co umożliwia zaangażowanie człowieka w najtańszym możliwym momencie, przed rozpoczęciem kosztownych prac. Procesy wyszukiwania polegają na analizie, wykrywaniu luk i ponownym wyszukiwaniu, a metadane odnośników towarzyszą faktom w całym procesie.

Manus i szkoła inżynierii kontekstu. Zespół Manus opublikował niezwykle szczere notatki na temat wewnętrznych mechanizmów narzędzia tuż przed jego uruchomieniem w 2025 roku, a kilka z tych informacji rozprzestrzeniło się szeroko. Traktuj cache KV jako ograniczenie projektowe: utrzymuj stabilność początku zapytania (brak daty i godziny na początku promptu systemowego), ponieważ liczba tokenów wejściowych może być znacznie większa od liczby tokenów wyjściowych. Unikaj dodawania lub usuwania narzędzi w trakcie sesji, ponieważ to unieważnia cache i myli model, gdy wcześniejsze wywołania wspominają zniknęte narzędzia; utrzymuj listę w niezmienionej formie i maskuj te opcje, które można obecnie wybrać.

Kursor i narzędzia IDE. Edytor oparty na sztucznej inteligencji reprezentuje inną filozofię głębokiej integracji z środowiskiem. Wykorzystuje semantyczny indeks bazy kodu edytora do szybkiego wyszukiwania, przechowuje zmiany w postaci różnic do sprawdzenia, dzięki czemu osoba zatwierdzająca połączenie jest elementem modelu uprawnień ukrytym pod postacią interfejsu, uruchamia w tle agenty na oddzielnych gałęziach oraz przekazuje wyniki narzędzi do sprawdzania kodu i typów z powrotem w cykl. Te same siedem komponentów pojawia się w innej formie.

Pracownicy obsługi klienta w przedsiębiorstwach, gdzie kluczowa jest zgodność z regulacjami. Pracownicy mający kontakt z klientem zmieniają priorytety: unikanie błędnych działań jest ważniejszy niż sama zdolność techniczna. Dlatego startują od określonych zasad: zakres działania ograniczony do zatwierdzonej wiedzy, działania sprawdzane pod kątem schematów systemów biznesowych (limit zwrotów pieniędzy, uprzednia weryfikacja tożsamości), obowiązkowe przekazywanie zadań innym osobom przy niskim poziomie pewności oraz pełne rejestracje audytowe. W sektorach regulowanych taki zestaw narzędzi stanowi w praktyce sam produkt.

Ramy i narzędzia dostępne obecnie

Rzadko już tworzy się takie zestawy narzędzi wyłącznie na podstawie prostych wywołań API. Oto popularne opcje, grupowane w przybliżeniu według filozofii:

• Claude Agent SDK. Narzędzie stanowiące podstawę Claude Code, dostępne jako biblioteka zawierająca mechanizmy pętli, różne narzędzia, podagentów, uprawnienia oraz funkcje kompresji. Najlepsze do szybkiego tworzenia zaawansowanych agentów w środowisku Claude.
• OpenAI Agents SDK. Lekkie narzędzia do obsługi agentów, przekazywania zadań, zasad bezpieczeństwa, sesji oraz śledzenia działań. Najlepsze do aplikacji wieloagentowych w ekosystemie OpenAI.
• LangGraph. Agenty jako wyraźne maszyny stanowe, z możliwością zapisywania stanów, przerw realizowanych przez człowieka oraz trwałej eksploatacji. Najlepsze do złożonych, kontrolowalnych procesów pracujących przez długi czas.
• CrewAI. Zespoły oparte na rolach, takie jak badacze i pisarze. Najlepsze do szybkich prototypów wieloagentowych oraz procesów przetwarzania treści.
• AutoGen, AG2 i Semantic Kernel. Narzędzia do pracy wieloagentowej skupione na konwersacjach, integrujące się z rozwiązaniami korporacyjnymi. Najlepsze dla środowisk .NET i Azure oraz do eksperymentów badawczych.
• smolagents. Biblioteka minimalistyczna, w której agenci piszą kod jako swoje działania. Najlepsza do szybkich implementacji wykorzystujących otwarte modele.
• Pydantic AI. Bezpieczne pod względem typów agenty oparte na schematach z weryfikowanymi wynikami. Najlepsze dla zespołów używających Pythona, którzy wymagają ścisłego typowania.
• Vercel AI SDK. Elementy bazowe oparte na TypeScript z możliwością kontrolowania pętli agenta. Najlepsze dla inżynierów webowych i produktowych w ekosystemie JavaScript.

Wokół nich znajduje się „tkanka łączna”: MCP dla standardowych narzędzi, platformy do śledzenia i oceny, trwałe silniki wykonywania oraz dostawcy sandboxów zapewniających bezpieczne wykonywanie kodu.

Porada przy wyborze: podczas nauki napisz sam prostą pętlę raz, korzystając z API modelu, pętli while i dwóch narzędzi, w około stu liniach kodu. Potem żaden framework nie będzie wydawał się czymś magicznym, a to właśnie jest celem. Podczas wdrażania wybierz framework najbliższy twojemu dostawcy modeli i językowi, a zaoszczędzony czas poświęć na to, czego żaden framework ci nie da – mianowicie na twoje narzędzia, procedury oceny oraz zasady bezpieczeństwa.

# The whole idea, in miniature
while not done:
    response = model.generate(context, tools)      # model decides
    if response.tool_calls:
        results = execute(response.tool_calls)     # harness acts (safely!)
        context = manage(context + results)        # harness curates memory
    else:
        done = verify(response)                    # harness checks the work

Tryby awarii

Oto typowe sposoby, w jakie agenci zawodzą, każdy z nich w połączeniu z rozwiązaniem zastosowanym po stronie narzędzi:

• Zepsucie kontekstu. Okno stopniowo wypełnia się przestarzałymi wynikami narzędzi, a jakość spada, aż po kilku godzinach cel zostaje zapomniany. Rozwiązanie: kompresja danych, prowadzenie notatek oraz okresowe ponawianie celu.
• Pętle zagłady. Ta sama błędna komenda jest powtarzana w nieskończoność, przy koszcie kilku centów za każdą próbę. Leczenie: wykrywanie pętli, ustalanie limitów iteracji oraz przymusowe zmiany strategii.
• Rozprzestrzenianie się narzędzi. Przy czterdziestu podobnych narzędziach model wybiera niewłaściwe w najgorszym momencie. Rozwiązanie: mniejszy zestaw bardziej precyzyjnych narzędzi z jasnymi opisami.
• Iniekcja poleceń. Tekst na stronie internetowej lub w e-mailu każe agencie zignorować swoje instrukcje i wylać dane z bazy danych, a ponieważ agent nie może z natury oddzielić danych od poleceń, może to zrobić. Rozwiązanie: filtrowanie danych wejściowych, narzędzia o minimalnych uprawnieniach, środowiska testowe oraz ludzka aprobatka dla decyzji o znaczeniu, przy czym należy stosować kilka warstw ochrony, ponieważ żadna pojedyncza metoda nie jest niezawodna.
• Fałszywy wynik. Agent zgłasza sukces, mimo że praca nie jest ukończona. Rozwiązanie: sprawdzanie wyników za pomocą niezależnego źródła oraz uniemożliwienie agentowi oceniania własnej pracy.
• Nadmierne wydatki. Wieloagentowa struktura może potajemnie znacznie zwiększyć rachunek. Rozwiązanie: budżety, routowanie, cache oraz szczere rozważenie, czy jeden zdolny agent wystarczyłby.
• Ukryty zmierzch możliwości modelu. Aktualizacja modelu zmienia jego zachowanie, a prompty dostosowane do wcześniejszej wersji przestają działać. Rozwiązanie: uruchamiaj zestaw testów po każdej zmianie.

Co należy pamiętać

Model dostarcza inteligencji, a narzędzia przekształcają ją w praktyczne działanie. Narzędzie to zbiór elementów składający się z siedmiu komponentów: wytycznych, narzędzi, zarządzania kontekstem, pamięci, zabezpieczeń, weryfikacji oraz możliwości obserwacji. Wokół nich funkcjonują wzorce realizacji długotrwałych zadań, takie jak planowanie, działanie i weryfikacja, kompresja danych, punkty kontrolne, podagenty oraz testy. Większość awarii agentów wynika z problemów z narzędziami, a większość ulepszeń dotyczy właśnie tych narzędzi. Dlatego, gdy agent nie spełnia oczekiwań, najpierw sprawdź narzędzia, a dopiero potem model.

Literatura pokrewna

• Subagenty w praktyce: role, budżety, zakazy i ciche niepowodzenia — Jak tworzyć trwałe subagenty w Claude Code: role, pliki przekazywania danych, stan wykonywania zadań, budżety, zakazy, sprawdzanie cichych niepowodzeń oraz narzędzie pomocnicze Copilot, na podstawie agentów używanych w dziesiątkach repozytoriów.
• Analityka agencyjna to coś więcej niż tekst do SQL: lekcje z Anthropic — Co mówi artykuł Anthropic o analityce samousługowej na temat warstw semantycznych, umiejętności, ocen i podstaw danych, oraz dlaczego sam tekst do SQL daje fałszywe wrażenie precyzji.

D3.js w React: powiązanie danych, SVG i zasada własności useEffect — Dowiedz się, czym naprawdę jest D3, jak działa powiązanie przy dodawaniu/aktualizowaniu/usuwaniu elementów, dlaczego SVG jest do tego odpowiednie, oraz jak podzielić kontrolę nad DOM, aby D3 i React mogły współpracować przy tworzeniu wykresów słupkowych.