Strands Agents, agenci sterowani modelem

Strands Agents, czyli mniej rusztowania wokół modelu

Strands to otwarty pakiet od AWS do budowania agentów, oparty na założeniu, że im mniej narzucasz modelowi z góry, tym lepiej. Podajesz model, instrukcję i zestaw narzędzi, a decyzję o tym, co i w jakiej kolejności wywołać, zostawiasz jemu.

Projekt jest wydany na licencji swobodnej i mimo pochodzenia nie wymaga infrastruktury AWS. Działa z modelami różnych dostawców, a integracja z usługami Amazona jest wygodnym domyślnym wyborem, a nie warunkiem użycia.

Podejście stoi w kontrze do bibliotek budujących jawny graf przepływu. Tam Ty opisujesz drogę, tutaj opisujesz możliwości, a drogę wybiera model. Obie szkoły mają swoje racje i poniżej opisuję, kiedy która wygrywa.

Najprostszy działający agent

pip install strands-agents strands-agents-tools

from strands import Agent, tool

@tool
def sprawdz_stan(sku: str) -> int:
    """Zwraca liczbe sztuk dostepnych w magazynie dla podanego kodu produktu."""
    return magazyn.policz(sku)

@tool
def zloz_zamowienie(sku: str, sztuk: int) -> str:
    """Sklada zamowienie i zwraca jego numer."""
    return zamowienia.utworz(sku, sztuk)

agent = Agent(
    tools=[sprawdz_stan, zloz_zamowienie],
    system_prompt="Obslugujesz zamowienia. Zawsze sprawdzasz stan przed zlozeniem.",
)

print(agent("Zamow dwie pary butow o kodzie BT-42."))

Narzędzie to zwykła funkcja z dekoratorem. Nazwa, typy argumentów i opis w potrójnym cudzysłowie stają się schematem, który widzi model, więc nie ma osobnego pliku z definicjami do utrzymania obok kodu.

To wygodne i niesie jedną konsekwencję, o której warto pamiętać od początku. Opis funkcji przestaje być komentarzem dla programisty i staje się częścią promptu. Zdanie mówiące wprost, kiedy narzędzie wywołać, podnosi trafność bardziej niż jakakolwiek zmiana instrukcji systemowej, a opis w rodzaju „pomocnicza funkcja do stanów" nie mówi modelowi nic.

Pętla, która dzieje się sama

Pakiet bierze na siebie cykl, który przy pracy z surowym API piszesz ręcznie: wysłanie zapytania, odczytanie żądania wywołania narzędzia, wykonanie funkcji, oddanie wyniku i powtórzenie aż do odpowiedzi końcowej.

Brzmi to jak drobiazg, dopóki nie policzysz, ile rzeczy trzeba w tej pętli obsłużyć poprawnie. Równoległe wywołania kilku narzędzi w jednej turze. Błąd funkcji, który powinien wrócić do modelu jako komunikat, a nie wywalić program. Limit tur chroniący przed kręceniem się w kółko. Historia rozmowy przycinana, gdy przekroczy okno kontekstu.

Ostatnia z tych rzeczy jest najczęściej pomijana przy własnej implementacji. Rozmowa rośnie z każdą turą, bo niesie ze sobą wszystkie poprzednie wypowiedzi i wyniki narzędzi, więc długi przebieg albo trafia na limit kontekstu, albo kosztuje wielokrotnie więcej niż zakładałeś. Pakiet obsługuje przycinanie i podsumowywanie historii, i warto sprawdzić, którą strategię ma ustawioną domyślnie, zanim wypuścisz to na produkcję.

Strumieniowanie działa na poziomie zdarzeń, więc możesz pokazywać użytkownikowi nie tylko powstającą odpowiedź, ale też informację, że agent właśnie sprawdza stan magazynu. Przy przebiegu trwającym pół minuty ta różnica decyduje o tym, czy ktoś poczeka.

Wzorce wieloagentowe

Wersja pierwsza dołożyła cztery układy do łączenia agentów i warto rozumieć różnice, bo pokrywają odmienne potrzeby.

Agent jako narzędzie to najprostszy wariant: jeden agent wywołuje drugiego dokładnie tak, jak wywołuje zwykłą funkcję. Sprawdza się przy podziale na specjalizacje, gdzie agent główny kieruje pytanie do właściwego eksperta.

Rój to grupa agentów pracująca nad wspólnym problemem z możliwością przekazywania sobie zadania. Elastyczny i najtrudniejszy do przewidzenia, bo kolejność wypowiedzi wynika z przebiegu.

Graf to układ deterministyczny: węzły połączone krawędziami, wykonywane zgodnie z zależnościami, gdzie wynik jednego węzła wchodzi na wejście następnego. To wybór dla procesów, które muszą przebiegać tak samo za każdym razem.

Przepływ opisuje zadania z jawnie zadeklarowanymi zależnościami, bliżej klasycznego harmonogramu niż rozmowy.

Praktyczna wskazówka jest taka sama jak przy innych bibliotekach tej klasy: zacznij od najprostszego układu, który da się obronić. Agent jako narzędzie pokrywa zaskakująco dużo przypadków, a rój wygląda najciekawiej i najczęściej rozczarowuje w produkcji, bo ten sam wsad daje różne przebiegi.

Narzędzia gotowe i własne

Osobny pakiet dostarcza kilkadziesiąt gotowych narzędzi i warto wiedzieć, co tam jest, zanim napiszesz własne odpowiedniki.

Zestaw obejmuje operacje na plikach, wykonywanie kodu, zapytania HTTP, pracę z pamięcią, obsługę obrazów oraz integracje z usługami chmurowymi. Do prototypu to oszczędność godziny, a przy okazji dobry wzorzec pokazujący, jak opisywać własne funkcje.

Do własnych narzędzi warto podejść z trzema zasadami, które oszczędzają najwięcej kłopotów.

Pierwsza dotyczy zwracanych wartości. Funkcja powinna oddawać dane, a nie gotowe zdanie dla użytkownika, bo redakcją odpowiedzi zajmuje się model. Narzędzie zwracające „Niestety nie znalazłem produktu" zamiast wartości pustej odbiera modelowi możliwość sensownego zareagowania i psuje odpowiedź w innym języku.

Druga dotyczy błędów. Wyjątek rzucony w narzędziu powinien wrócić do modelu jako komunikat, żeby mógł poprawić argumenty i spróbować ponownie. Kod przerywający cały przebieg przy pierwszej literówce w nazwie produktu marnuje możliwość, którą ten układ daje za darmo.

Trzecia dotyczy zakresu. Narzędzie robiące jedną rzecz jest wybierane trafniej niż narzędzie z siedmioma trybami sterowanymi parametrem. Model wybiera po opisie, a opis siedmiu trybów naraz jest z natury mętny.

Bezpieczeństwo narzędzi

Ta część zasługuje na osobne omówienie, bo przy sterowaniu oddanym modelowi ryzyko wygląda inaczej niż przy jawnym przepływie.

Argumenty przekazywane do funkcji pochodzą z tekstu wygenerowanego przez model, a ten czyta również dane wejściowe, w tym treści pobrane z zewnątrz. To znaczy, że dokument z osadzoną instrukcją potrafi wpłynąć na to, jakie narzędzie zostanie wywołane i z czym.

Trzy zabezpieczenia rozwiązują większość tego problemu. Pierwsze to podział narzędzi na czytające i zmieniające stan, przy czym te drugie wymagają potwierdzenia albo działają na wąskim, jawnie ograniczonym zakresie. Drugie to izolacja wszystkiego, co wykonuje kod albo polecenia systemowe, w środowisku bez dostępu do sieci i z limitem czasu. Trzecie to przekazywanie identyfikatorów zamiast danych wrażliwych, z podstawieniem właściwych wartości dopiero wewnątrz funkcji, poza zasięgiem kontekstu rozmowy.

Warto też pamiętać, że uprawnienia agenta są uprawnieniami procesu, w którym działa. Agent uruchomiony z rolą mającą szeroki dostęp do zasobów chmurowych może zrobić dokładnie tyle, ile ta rola pozwala, niezależnie od tego, co napisałeś w instrukcji systemowej.

Modele i przenośność

Biblioteka nie wiąże Cię z jednym dostawcą, co przy pakiecie wydanym przez dostawcę chmury zasługuje na odnotowanie.

Poza usługami Amazona obsługiwane są modele Claude, OpenAI, rozwiązania Google oraz modele uruchamiane lokalnie przez Ollamę. Zmiana dostawcy sprowadza się do podmiany obiektu modelu przekazywanego do agenta.

Wspierany jest też protokół komunikacji między agentami różnych producentów, co ma znaczenie, gdy Twój agent ma rozmawiać z cudzym. Zgodność takich standardów bywa częściowa, więc przed wpisaniem tego do projektu architektury warto sprawdzić konkretny przypadek.

Ta przenośność ma praktyczny wymiar przy porównywaniu modeli. Ten sam agent uruchomiony na trzech różnych modelach na Twoim zestawie przypadków mówi więcej niż jakiekolwiek publiczne zestawienie, bo mierzy Twoje zadanie, a nie uśrednione.

Warto natomiast wiedzieć, że przenośność kodu nie oznacza przenośności zachowania. Modele różnią się tym, jak chętnie wywołują narzędzia, jak radzą sobie z kilkoma wywołaniami w jednej turze i jak reagują na błąd zwrócony przez funkcję. Instrukcja systemowa dostrojona pod jeden model potrafi po zmianie dostawcy dawać wyraźnie gorsze wyniki, mimo że nie ruszyłeś ani jednej linii kodu. To kolejny powód, dla którego zestaw przypadków z oczekiwanym wynikiem jest tu potrzebny, a nie opcjonalny.

Wdrożenie i obserwowalność

Agent jest zwykłym obiektem Pythona, więc wdrożenie nie wymaga specjalnego środowiska uruchomieniowego. Działa w funkcji bezserwerowej, w kontenerze, na klastrze i w usłudze zarządzanej przeznaczonej dla agentów, przy czym w tym ostatnim przypadku kod pozostaje ten sam.

Ta ostatnia własność jest wygodniejsza, niż brzmi. Agent uruchamiany lokalnie i agent w usłudze zarządzanej to ten sam kod wywoływany w ten sam sposób, więc rozwój lokalny nie różni się od produkcji, a to usuwa całą klasę różnic wychodzących dopiero po wdrożeniu.

Tę usługę warto odróżnić od starszego produktu konsolowego tego samego dostawcy, bo nazwy bywają mylone. Bedrock Agents pozwalał złożyć agenta klikaniem, bez pisania kodu, ale nosi dziś nazwę Agents Classic, od 30 lipca 2026 roku nie przyjmuje nowych kont i ma zamrożony katalog modeli. Przy zakładaniu projektu na tej chmurze wybierasz więc między tym pakietem a następcą tamtej usługi, a droga przez Agents Classic jest zamknięta niezależnie od tego, jak dobrze pasuje.

Telemetria idzie w powszechnie przyjętym formacie, więc przebieg wpina się w narzędzia, których zespół już używa. Jeden przebieg widać jako drzewo: wywołania modelu, wywołania narzędzi, czasy i zużycie tokenów.

Trzy miary warto obserwować od pierwszego dnia. Liczba tur na zadanie mówi, czy agent krąży zamiast kończyć. Koszt na zadanie mówi, czy rozwiązanie się skaluje. Udział zadań zakończonych powodzeniem, liczony na stałym zestawie przypadków, mówi, czy zmiana w instrukcji cokolwiek poprawiła. Ta trzecia jest jedyną, która pozwala porównać dwie wersje agenta, i jest sprawdzana najrzadziej.

Strands kontra alternatywy

Podział przebiega wzdłuż jednego pytania: kto decyduje o kolejności kroków. Jeśli proces ma znane etapy i musi przebiegać tak samo za każdym razem, jawny graf wygrywa, bo daje powtarzalność i miejsce, w którym można wskazać błąd. Jeśli zadanie jest otwarte i sztywny plan przeszkadza, sterowanie modelem daje krótszy kod i lepsze wyniki.

Drugie kryterium to infrastruktura. Zespół pracujący w usługach Amazona dostaje tu integrację, której nie ma w konkurencyjnych bibliotekach, i to bywa argumentem rozstrzygającym niezależnie od reszty.

Trzecie, jak zawsze, to pytanie o konieczność. Agent z trzema narzędziami i jednym krokiem to niewiele kodu wywołującego model wprost, bez żadnej biblioteki pośredniczącej. Warstwa orkiestrująca zarabia na siebie dopiero wtedy, gdy potrzebujesz zarządzania historią, ponawiania, obserwowalności albo pracy kilku agentów naraz.

Typowe błędy

Pierwszy to opisy narzędzi pisane dla programisty. Model widzi wyłącznie nazwę, typy i opis, więc zdanie mówiące, kiedy wywołać funkcję, jest ważniejsze niż to, co ona robi.

Drugi to brak limitu tur i limitu kosztu. Agent w pętli wykona kilkadziesiąt wywołań, zanim ktokolwiek zauważy, a próg jest jedynym mechanizmem działającym bez Twojej uwagi.

Trzeci to zignorowanie strategii zarządzania historią rozmowy. Długi przebieg albo trafia na limit kontekstu, albo kosztuje wielokrotnie więcej, niż zakładałeś.

Czwarty to oddanie modelowi procesu o znanych krokach. Sterowanie modelem jest zaletą przy zadaniach otwartych i wadą tam, gdzie kolejność i tak jest stała.

Piąty to narzędzia bez izolacji. Funkcja wykonująca polecenia systemowe albo modyfikująca dane powinna mieć zatwierdzanie albo ograniczenia, bo argumenty pochodzą z tekstu wygenerowanego przez model.

Szósty to migracja albo strojenie bez zestawu przypadków testowych. Agenci nie zwracają wartości porównywalnych znakiem równości, więc bez oczekiwanych wyników ocena zmiany jest zgadywanką.

FAQ

Czy Strands wymaga konta AWS?

Nie. Pakiet jest otwarty i działa z modelami różnych dostawców, w tym uruchamianymi lokalnie. Integracja z usługami Amazona jest wygodnym domyślnym wyborem i nie jest warunkiem użycia.

Czym różni się od LangGraph?

Tym, kto decyduje o kolejności kroków. LangGraph każe Ci opisać graf przepływu, tutaj opisujesz narzędzia, a drogę wybiera model. Graf daje powtarzalność i łatwiejszą diagnozę, sterowanie modelem daje krótszy kod i lepsze wyniki przy zadaniach otwartych.

Jak definiuje się narzędzia?

Jako zwykłe funkcje z dekoratorem. Nazwa, typy argumentów i opis w potrójnym cudzysłowie tworzą schemat widziany przez model, więc nie ma osobnego pliku definicji do utrzymania obok kodu.

Czy nadaje się do systemów wieloagentowych?

Tak, dostępne są cztery układy: agent jako narzędzie, rój, graf i przepływ. Warto zacząć od pierwszego, bo pokrywa większość przypadków, a układy swobodniejsze trudniej przewidzieć w produkcji.

Jak sprawdzić, czy pasuje do mojego projektu?

Zbuduj w nim jeden realny proces ze swojego systemu i zmierz trzy rzeczy: koszt przebiegu, czas odpowiedzi i to, jak szybko ustalasz przyczynę po nieudanym uruchomieniu. Trzecia miara przesądza najczęściej i jest sprawdzana najrzadziej.

Dokumentacja stoi na stronie projektu, a kod w repozytorium na GitHubie.