Agno, agenci z własnym środowiskiem

Agno, czyli framework z własną warstwą uruchomieniową

Agno wyróżnia się w tłumie bibliotek agentowych dwiema rzeczami. Pierwsza to nacisk na wydajność, o którym mówi głośno i którą warto ocenić uczciwie. Druga jest ciekawsza: poza samą biblioteką dostajesz warstwę uruchomieniową wystawiającą agentów jako usługę sieciową, z zapisem sesji, historią i podglądem przebiegów.

Projekt zaczynał pod inną nazwą, jako narzędzie bliższe pracy z danymi, i zmienił kierunek na początku 2025 roku. Ta historia bywa źródłem zamieszania przy szukaniu materiałów, bo starsze poradniki opisują coś innego niż to, czym projekt jest dziś.

Konstrukcja opiera się na czterech pojęciach: agent, zespół, przepływ i środowisko uruchomieniowe. Pierwsze trzy znasz z innych bibliotek, czwarte jest tu wyróżnikiem.

Pierwszy agent

pip install agno

from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.tools import tool

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

agent = Agent(
    model=OpenAIChat(id="gpt-4o"),
    tools=[sprawdz_stan],
    instructions="Odpowiadasz na pytania o dostepnosc. Zawsze sprawdzasz stan.",
    markdown=True,
)

agent.print_response("Czy sa jeszcze buty w rozmiarze 42?")

Interfejs jest zwięzły i przypomina inne biblioteki tej klasy. Obsługiwanych jest kilkadziesiąt rodzin modeli, w tym uruchamiane lokalnie przez Ollamę, a zmiana dostawcy to podmiana jednego obiektu.

Wbudowane są też trzy rzeczy, które w innych bibliotekach dokłada się osobno: pamięć rozmowy, warstwa wiedzy oparta na wyszukiwaniu po dokumentach oraz obsługa danych innych niż tekst. To skraca drogę od pomysłu do działającego prototypu.

Głośne liczby i co naprawdę znaczą

Projekt promuje się wynikami rzędu tysięcy razy szybszego tworzenia agenta i wielokrotnie mniejszego zużycia pamięci niż u konkurencji. Te liczby są prawdziwe i zarazem mylące, jeśli nie wiesz, co dokładnie mierzą.

Mierzą koszt utworzenia obiektu agenta w pamięci, czyli czas od wywołania konstruktora do gotowości. Nie mierzą czasu odpowiedzi na pytanie użytkownika, bo ten jest zdominowany przez wywołanie modelu, trwające setki milisekund albo sekundy.

Proporcja jest tu rozstrzygająca. Jeśli utworzenie agenta zajmuje mikrosekundy, a wywołanie modelu dwie sekundy, to przyspieszenie pierwszego tysiąckrotnie zmienia całkowity czas o wielkość niemierzalną. Wybór biblioteki na podstawie tej liczby przypomina wybór samochodu po czasie otwierania drzwi.

Są jednak przypadki, w których to naprawdę ma znaczenie, i warto je nazwać. Pierwszy to systemy tworzące agentów dynamicznie, po jednym na żądanie, przy dużym ruchu. Drugi to symulacje z tysiącami agentów naraz, gdzie zużycie pamięci decyduje o tym, ile ich zmieścisz na maszynie. Trzeci to środowiska, w których proces startuje przy każdym żądaniu, więc koszt inicjalizacji płacisz za każdym razem.

Poza tymi trzema przypadkami wybieraj według czegoś innego: obserwowalności, dojrzałości narzędzi i tego, jak szybko ustalisz przyczynę po nieudanym przebiegu. Rachunek za model i tak będzie kilka rzędów wielkości większy niż koszt samej biblioteki.

To nie jest zarzut wobec projektu, bo liczby są rzetelne, a niskie zużycie pamięci ma realną wartość przy dużej liczbie równoległych sesji. Chodzi wyłącznie o to, żeby nie budować na nich decyzji, dla której nie zostały pomyślane. Cała branża publikuje dziś takie zestawienia i każdy dostawca wybiera liczbę, w której wypada najlepiej.

Zespoły i przepływy

Do łączenia agentów służą dwa mechanizmy o różnym przeznaczeniu.

from agno.team import Team

zespol = Team(
    members=[analityk, redaktor],
    model=OpenAIChat(id="gpt-4o"),
    instructions="Analityk przygotowuje liczby, redaktor pisze raport.",
)

zespol.print_response("Przygotuj raport sprzedazy za czerwiec.")

Zespół działa w jednym z czterech trybów: koordynator sam dobiera członków i skleja ich wyniki, kieruje całą sprawę do jednego specjalisty, rozsyła to samo zadanie do wszystkich albo prowadzi wspólną listę zadań aż do jej wyczerpania. Dzielenie się odpowiedziami między członkami jest osobnym ustawieniem, domyślnie wyłączonym. To jest wygodne przy zadaniach wymagających różnych specjalizacji i kosztowne, bo koordynacja to dodatkowe wywołania modelu poza samą pracą.

Przepływ służy do czegoś innego: opisuje kroki jawnie, w kodzie, z warunkami i pętlami. To wybór dla procesów, które muszą przebiegać tak samo za każdym razem.

Podział pracy między te dwa mechanizmy jest praktyczną wskazówką na cały projekt. Proces o znanych etapach opisuj przepływem, bo zyskujesz powtarzalność i tańszą diagnozę. Pojedynczy krok wymagający oceny sytuacji zostaw agentowi albo zespołowi.

Warstwa uruchomieniowa

To jest część, której konkurencja zwykle nie ma, i najmocniejszy argument za tym projektem.

Środowisko uruchomieniowe opakowuje agentów, zespoły i przepływy w serwer wystawiający je przez zwykłe API sieciowe. Dostajesz gotowe punkty końcowe, zarządzanie sesjami, zapis historii rozmów, ślady wykonania i podgląd tego, co się dzieje w środku.

Praktyczna różnica jest taka, że nie piszesz warstwy serwerowej sam. Przy typowym wdrożeniu agenta to jest kilkaset linii kodu obsługującego sesje, strumieniowanie, zapis historii i uwierzytelnianie, plus decyzje, które trzeba podjąć poprawnie za pierwszym razem.

Ważne rozróżnienie: stan trafia do Twojej bazy danych, a nie do usługi producenta. To znaczy, że dane rozmów zostają u Ciebie i podlegają Twoim regułom przechowywania, co przy wymogach dotyczących danych osobowych bywa warunkiem wejścia.

Warto natomiast pamiętać, że warstwa uruchomieniowa to kolejna zależność w architekturze, z własnym cyklem wydań. Jeśli masz już dojrzałą warstwę serwerową, wpięcie agentów w nią bywa prostsze niż dołożenie osobnego środowiska obok.

Wart uwagi jest też podgląd przebiegów, bo to najbardziej praktyczna część tego rozwiązania. Widzisz jeden przebieg jako drzewo: wywołania modelu, wywołania narzędzi, argumenty, wyniki, czasy i zużycie tokenów. Bez tego jedyną metodą diagnozy jest powtarzanie przebiegu i patrzenie w konsolę, a przy agentach, gdzie ten sam wsad daje różne przebiegi, ta metoda po prostu zawodzi.

Pamięć i wiedza

Dwie rzeczy dostępne od razu, które w innych bibliotekach wymagają osobnych pakietów.

Pamięć przechowuje historię rozmowy oraz wnioski z niej, przypisane do użytkownika i sesji. Agent pamięta, co ustaliliście wczoraj, bez przekazywania całej historii w każdym zapytaniu.

To jest zapis prowadzony przez bibliotekę: agent z niego korzysta, ale nim nie zarządza. Odwrotne podejście wybiera Letta, gdzie agent edytuje bloki własnej pamięci narzędziami i sam decyduje, co zatrzymać w kontekście, a co odesłać poza niego. Wychodzi to lepiej w długich relacjach z jednym użytkownikiem, kosztem dodatkowych wywołań modelu przy każdym zapisie, natomiast warto wiedzieć, że pythonowy serwer tamtego projektu autorzy w lipcu 2026 roku opisali jako przestarzały i przenieśli rozwój do wariantu w Node.js.

Warstwa wiedzy to wyszukiwanie po dokumentach wpięte w agenta jako źródło kontekstu. Wczytujesz dokumenty, wskazujesz magazyn wektorów i agent sięga do nich, gdy potrzebuje.

Przy obu mechanizmach warto od początku zaplanować dwie rzeczy. Pierwsza to koszt: pamięć wymaga wywołań modelu przy zapisie, a wiedza przy wyliczaniu wektorów, więc oba dokładają się do rachunku poza samą rozmową. Druga to usuwanie danych. Zapis przypisany do osoby podlega prawu do bycia zapomnianym, więc możliwość skasowania wszystkiego, co dotyczy jednego użytkownika, powinna istnieć od pierwszego dnia, a nie powstawać po pierwszym żądaniu.

Co naprawdę warto mierzyć

Skoro wyniki tworzenia agenta niewiele mówią, warto wskazać liczby, które rzeczywiście rozstrzygają o wyborze biblioteki i o tym, czy rozwiązanie nadaje się na produkcję.

Pierwsza to koszt jednego zadania, liczony na realnych przypadkach ze swojego systemu, a nie na przykładzie z dokumentacji. Weź dziesięć prawdziwych zapytań, zsumuj zużyte tokeny i pomnóż przez planowaną skalę. Ta jedna liczba mówi więcej niż jakiekolwiek porównanie bibliotek.

Druga to liczba tur na zadanie. Agent, który kończy w trzech turach, i agent, który potrzebuje dwunastu, różnią się kosztem czterokrotnie, a różnica bierze się zwykle z opisów narzędzi i instrukcji, nie z biblioteki.

Trzecia to czas do pierwszego widocznego znaku. Użytkownik ocenia szybkość po tym, kiedy coś się zaczyna dziać, a nie po całkowitym czasie przebiegu. Strumieniowanie zdarzeń pośrednich potrafi zmienić odbiór trzydziestosekundowego zadania bardziej niż jakakolwiek optymalizacja.

Czwarta, najważniejsza i najrzadziej mierzona, to udział zadań zakończonych powodzeniem na stałym zestawie przypadków z oczekiwanym wynikiem. Tylko ona pozwala stwierdzić, czy zmiana w instrukcji cokolwiek poprawiła. Bez niej ocena sprowadza się do wrażenia po kilku ręcznych próbach, a wrażenie regularnie myli.

Piąta to czas ustalenia przyczyny po nieudanym przebiegu. Trudna do zmierzenia, za to najbardziej odczuwalna w codziennej pracy, i to ona zwykle decyduje, czy zespół zostaje przy wybranej bibliotece po trzech miesiącach.

Wdrożenie i koszty utrzymania

Kilka rzeczy, które przy tej klasie narzędzi trzeba rozstrzygnąć przed wypuszczeniem czegokolwiek do użytkowników.

Limit kosztu na przebieg powinien istnieć od pierwszego uruchomienia. Agent w pętli potrafi wykonać kilkadziesiąt wywołań modelu, zanim ktokolwiek zauważy problem, a górny próg jest jedynym mechanizmem działającym bez Twojej uwagi.

Zapisywanie przebiegów jest tu tańsze niż gdzie indziej, bo warstwa uruchomieniowa robi to sama, natomiast warto zdecydować, jak długo te dane mają być przechowywane. Zapis każdej rozmowy bez okresu ważności rośnie w bazie w tempie, którego nikt nie planował, a przy danych osobowych dochodzi jeszcze wymóg ich usuwania.

Warto też przemyśleć, co się dzieje przy wdrożeniu nowej wersji, gdy sesje są w toku. Zmiana instrukcji systemowej w środku rozmowy daje agenta zachowującego się inaczej niż dwie tury wcześniej, co dla użytkownika wygląda na awarię. Przypisanie sesji do wersji konfiguracji rozwiązuje to raz.

Ostatnia rzecz to izolacja narzędzi zmieniających stan. Funkcja wysyłająca wiadomość albo modyfikująca dane powinna wymagać potwierdzenia albo działać na jawnie ograniczonym zakresie, bo jej argumenty pochodzą z tekstu wygenerowanego przez model, na który wpływają również dane wejściowe.

Agno kontra alternatywy

Pierwsze kryterium to, co masz już zbudowane. Jeśli warstwa serwerowa, sesje i zapis historii działają w Twoim systemie, dokładanie osobnego środowiska uruchomieniowego jest nadmiarem, a wtedy liczy się sam interfejs biblioteki.

Drugie to dojrzałość narzędzi diagnostycznych. Przy agentach największym kosztem jest ustalenie, dlaczego przebieg poszedł nie tak, a tu przewagę mają projekty z dłuższą historią i większą społecznością.

Typowe błędy

Pierwszy to wybór biblioteki na podstawie wyników tworzenia agenta. Mierzą one koszt utworzenia obiektu, a nie czas odpowiedzi, który jest zdominowany przez wywołanie modelu.

Drugi to szukanie materiałów pod dawną nazwą projektu. Starsze poradniki opisują narzędzie o zupełnie innym przeznaczeniu i wprowadzają w błąd co do interfejsu.

Trzeci to zespół agentów tam, gdzie wystarczy przepływ. Koordynacja to dodatkowe wywołania modelu, więc przy znanych krokach dokładasz koszt bez zysku.

Czwarty to włączenie pamięci i warstwy wiedzy bez policzenia kosztu. Oba mechanizmy dokładają wywołania poza samą rozmową i widać to dopiero na rachunku.

Piąty to brak możliwości usunięcia danych jednego użytkownika. Pamięć przypisana do osoby podlega przepisom o danych osobowych, a dopisanie tego później jest trudniejsze niż zaplanowanie na starcie.

Szósty to dokładanie warstwy uruchomieniowej do systemu, który ma już własną. Dwa środowiska obok siebie to dwa cykle wydań i dwa miejsca, w których coś może się zepsuć.

FAQ

Czy Agno to dawne Phidata?

Tak, projekt zmienił nazwę na początku 2025 roku i przy okazji zmienił kierunek: z narzędzia bliższego pracy z danymi na framework agentowy z własną warstwą uruchomieniową. Materiały pod dawną nazwą opisują co innego i warto je pomijać.

Czy te wyniki wydajnościowe mają znaczenie?

W trzech przypadkach tak: przy tworzeniu agentów dynamicznie na żądanie, przy symulacjach z tysiącami agentów naraz oraz w środowiskach uruchamiających proces przy każdym żądaniu. Poza nimi czas odpowiedzi jest zdominowany przez wywołanie modelu i różnica jest niemierzalna.

Czym jest warstwa uruchomieniowa?

Serwerem wystawiającym agentów przez API sieciowe, z zarządzaniem sesjami, zapisem historii i podglądem przebiegów. Stan trafia do Twojej bazy danych, więc dane rozmów zostają u Ciebie i podlegają Twoim regułom przechowywania.

Czy działa z modelami spoza jednego dostawcy?

Tak, obsługiwanych jest kilkadziesiąt rodzin modeli, w tym uruchamiane lokalnie. Zmiana dostawcy sprowadza się do podmiany obiektu modelu przekazywanego do agenta, bez zmian w reszcie kodu.

Kiedy wybrać coś innego?

Gdy masz już dojrzałą warstwę serwerową z sesjami i zapisem historii, bo wtedy główna przewaga tego projektu jest dla Ciebie nadmiarem. Gdy zależy Ci na jak najlepszej diagnostyce przebiegów, warto sprawdzić LangGraph, który ma dłuższą historię i bogatsze narzędzia obserwacyjne.

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