Mem0, pamięć długoterminowa dla agentów AI

Mem0, czyli agent, który pamięta poprzednią rozmowę

Model językowy niczego nie pamięta. Każde wywołanie zaczyna się od pustki, a wrażenie ciągłości bierze się wyłącznie z tego, że doklejasz historię rozmowy do promptu. Przy piątej wymianie zdań to działa, przy pięćsetnej kosztuje więcej niż sama odpowiedź.

Mem0 rozwiązuje to inaczej niż przez doklejanie wszystkiego. Wydobywa z rozmowy fakty warte zapamiętania, zapisuje je osobno i przy kolejnym pytaniu podaje tylko te, które mają związek ze sprawą. Projekt jest otwarty, ma za sobą rundę finansowania rzędu dwudziestu czterech milionów dolarów i jest dziś najczęściej używaną biblioteką w tej kategorii.

Na czym polega problem

Rozwiązanie naiwne wygląda tak: trzymasz całą historię i wysyłasz ją przy każdym pytaniu. Rozwiązanie to psuje się na trzech poziomach naraz.

Koszt rośnie liniowo z długością rozmowy, więc setna wiadomość kosztuje sto razy więcej niż pierwsza. Jakość spada, bo model gubi istotne szczegóły w ścianie tekstu, zwłaszcza te umieszczone w środku wejścia. Wreszcie okno kontekstu ma granicę i prędzej czy później trzeba coś wyrzucić, a wyrzucanie najstarszych wiadomości oznacza zapominanie właśnie tego, co użytkownik powiedział o sobie na początku.

Drugie podejście, czyli streszczanie historii, tylko przesuwa problem. Streszczenie streszczenia po dziesięciu iteracjach nie zawiera już nic konkretnego, a fakt „użytkownik ma alergię na orzechy" znika w trzeciej rundzie skracania.

Warstwa pamięci odwraca tę logikę. Zamiast pytać, co da się zmieścić, pyta, co jest istotne dla bieżącego pytania, i podaje tylko to.

Jak to działa w środku

Przepływ ma dwie strony. Przy zapisie biblioteka analizuje wymianę zdań i wydobywa z niej fakty, na przykład że użytkownik pracuje w Krakowie albo woli odpowiedzi po polsku. Te fakty trafiają do bazy wektorowej razem z osadzeniem, a system sprawdza jednocześnie, czy nowy fakt nie jest sprzeczny z zapisanym wcześniej.

Ten drugi krok jest tym, co odróżnia warstwę pamięci od zwykłego wyszukiwania. Jeśli w marcu użytkownik powiedział, że mieszka w Warszawie, a w lipcu że przeprowadził się do Gdańska, prosta baza zwróci oba fakty i model się pogubi. Warstwa pamięci musi rozpoznać aktualizację, tylko robi to inaczej, niż podpowiada intuicja. Bieżący algorytm usługi hostowanej niczego nie kasuje: zapisuje oba fakty z kontekstem czasowym, a przy odczycie wyżej ustawia ten aktualny.

Przy odczycie idzie zapytanie do bazy, wracają fakty najbliższe pytaniu, a Ty doklejasz je do promptu. Zamiast pięćdziesięciu tysięcy tokenów historii wysyłasz pięćset tokenów faktów, co przekłada się wprost na rachunek i na czas odpowiedzi.

W kwietniu 2026 roku projekt wdrożył nowy algorytm oparty na jednoprzebiegowym wydobywaniu hierarchicznym i wyszukiwaniu wielosygnałowym. Wielosygnałowe znaczy tu, że ranking łączy podobieństwo wektorowe, dopasowanie słów kluczowych i powiązania encji, zamiast opierać się na samych osadzeniach. Poprawa dotyczy przede wszystkim pytań o czas oraz takich, które wymagają połączenia dwóch faktów w jeden wniosek.

Pierwsze uruchomienie

pip install mem0ai

from mem0 import Memory

pamiec = Memory()

pamiec.add(
    "Pracuje w Krakowie jako backend developer, glownie w Pythonie",
    user_id="anna",
)

wyniki = pamiec.search("W czym pracuje ta osoba?", user_id="anna", limit=3)
for wpis in wyniki["results"]:
    print(wpis["memory"])

Identyfikator użytkownika jest tu kluczowy i nieprzypadkowo pojawia się w obu wywołaniach. Pamięć jest przypisana do osoby, więc pominięcie tego pola albo podanie stałej wartości sprawia, że wszyscy użytkownicy dzielą jeden zbiór faktów. To najczęstszy błąd na starcie i zarazem najpoważniejszy, bo oznacza wyciek danych między kontami.

Wpięcie w rozmowę wygląda tak: przed wywołaniem modelu pobierasz istotne fakty, po wywołaniu zapisujesz nową wymianę zdań.

def odpowiedz(pytanie: str, user_id: str) -> str:
    fakty = pamiec.search(pytanie, user_id=user_id, limit=5)
    kontekst = "\n".join(f["memory"] for f in fakty["results"])

    wynik = klient.messages.create(
        model="claude-sonnet-5",
        max_tokens=2000,
        system=f"Co wiesz o uzytkowniku:\n{kontekst}",
        messages=[{"role": "user", "content": pytanie}],
    )

    tresc = wynik.content[0].text
    pamiec.add(
        [{"role": "user", "content": pytanie},
         {"role": "assistant", "content": tresc}],
        user_id=user_id,
    )
    return tresc

Zapis wypada wykonać w tle, a nie przed zwróceniem odpowiedzi. Wydobywanie faktów to kolejne wywołanie modelu, więc czekanie na nie dokłada sekundę do czasu, w którym użytkownik widzi wynik.

Pamięć grafowa

Sama baza wektorowa dobrze odpowiada na pytanie „co wiem na ten temat", a gorzej na „jak te osoby są ze sobą powiązane". Warstwa grafowa dokłada relacje między encjami, więc obok faktu o osobie zapisuje, że pracuje w danej firmie, a ta firma jest klientem innej.

To ma znaczenie przy pytaniach wymagających dwóch kroków. Pytanie o to, kto w zespole zna dany język programowania, wymaga połączenia faktów o osobach z faktami o zespole, czego samo podobieństwo wektorowe nie zapewni.

Cena tej możliwości jest podwójna. Wydobywanie relacji to dodatkowe wywołania modelu przy zapisie, a w wersji hostowanej graf włącza się dopiero od planu Pro za 249 dolarów miesięcznie. Zacznij bez grafu i włącz go dopiero wtedy, gdy zobaczysz w logach pytania, na które sama warstwa wektorowa nie odpowiada.

OpenMemory i tryb lokalny

Osobną gałęzią projektu jest warstwa pamięci działająca lokalnie, przeznaczona do narzędzi deweloperskich. Idea polega na tym, żeby kontekst wędrował między asystentami zamiast żyć osobno w każdym z nich.

Integracja odbywa się przez protokół MCP, więc ten sam zbiór faktów widzi zarówno Claude, jak i edytor obsługujący ten standard. W praktyce znaczy to tyle, że decyzja architektoniczna zapisana w jednym narzędziu jest znana w drugim, bez ręcznego przeklejania.

Tryb lokalny ma też oczywistą zaletę przy danych, które nie mogą opuścić maszyny. Osadzenia można liczyć modelem uruchomionym przez Ollamę, a bazę trzymać w pliku, więc nic nie wychodzi na zewnątrz.

Ceny

Progi są sztywne, a zapisy i odczyty liczone osobno, więc plan dobiera się do tego z nich, który wyczerpie się pierwszy. Kto nie mieści się w tym układzie, ustala z dostawcą rozliczenie za faktyczne zużycie, bo cennik nie przewiduje automatycznego doładowania.

Wersja otwarta jest darmowa bez ograniczeń i uruchamiasz ją u siebie, płacąc wyłącznie za bazę wektorową i za wywołania modelu przy wydobywaniu faktów. Ten drugi koszt bywa pomijany w kalkulacjach, a przy dużym ruchu przewyższa cenę abonamentu, bo każdy zapis to osobne wywołanie.

Prosty sposób na oszacowanie: policz, ile wymian zdań dziennie obsługuje aplikacja, pomnóż przez koszt jednego wydobycia i porównaj z tym, ile kosztowałoby wysyłanie pełnej historii. Przy rozmowach krótkich pamięć się nie opłaca, przy długich zwraca się szybko.

Zakresy pamięci i wielu użytkowników

Poza identyfikatorem osoby biblioteka przyjmuje też identyfikator agenta i sesji. Trzy poziomy pozwalają rozdzielić rzeczy, które w jednym worku szybko robią bałagan.

Pamięć użytkownika trzyma fakty trwałe: preferencje, rolę, kontekst zawodowy. Pamięć agenta trzyma to, czego nauczył się sam agent, na przykład że dana procedura kończy się błędem i trzeba iść inną drogą. Pamięć sesji dotyczy bieżącego zadania i po jego zakończeniu zwykle nie ma po co żyć dalej.

pamiec.add(tresc, user_id="anna", agent_id="asystent-wsparcia", run_id="zgloszenie-1841")

Rozdzielenie tych warstw ma wymiar praktyczny przy kasowaniu. Zakończone zgłoszenie można usunąć w całości po identyfikatorze przebiegu, nie ruszając tego, co system wie o użytkowniku. Bez tego podziału czyszczenie danych sprowadza się do wybierania wpisów ręcznie.

Przy aplikacji z wieloma agentami warto z góry ustalić, czy dzielą one pamięć użytkownika. Zwykle tak, bo to sens całej warstwy, ale agent obsługujący sprawy wrażliwe bywa wyjątkiem i wtedy lepiej trzymać jego zapisy osobno.

Co warto mierzyć

Warstwa pamięci wchodzi między pytanie a odpowiedź, więc jej jakość widać dopiero w liczbach. Trzy wskaźniki wystarczą, żeby wiedzieć, czy działa.

Pierwszy to trafność odczytu, czyli jak często wśród zwróconych faktów jest ten potrzebny. Sprawdzisz to na kilkudziesięciu prawdziwych pytaniach, przeglądając, co warstwa podała. Jeśli w połowie przypadków fakty są przypadkowe, problem leży zwykle w zbyt ogólnym zapytaniu, a nie w bazie.

Drugi to liczba tokenów kontekstu przed i po wdrożeniu. To jedyna miara, która pokazuje, czy oszczędność jest realna, i jedyna, którą można wprost przeliczyć na pieniądze.

Trzeci to liczba wpisów na użytkownika w czasie. Baza rosnąca po sto faktów miesięcznie na osobę sygnalizuje, że zapisujesz zbyt wiele, a nadmiar wpisów obniża trafność odczytu, bo podobnych faktów jest coraz więcej.

Wszystkie trzy warto zmierzyć przed wdrożeniem warstwy, na tym samym zestawie pytań. Bez punktu odniesienia zostaje wrażenie, że jest lepiej, a to zwykle wystarcza do podjęcia decyzji, ale nie do jej obrony, gdy ktoś zapyta o koszt.

Mem0 kontra alternatywy

Warto zauważyć, że ostatni wiersz to inna kategoria. Baza wektorowa jest składnikiem, a warstwa pamięci gotowym rozwiązaniem zbudowanym na takiej bazie. Jeśli masz nietypowe wymagania co do tego, co i kiedy zapamiętywać, własna implementacja na bazie wektorowej daje więcej swobody kosztem pracy.

Kiedy pamięć nie jest potrzebna

Nie każda aplikacja jej wymaga i to warto ustalić przed wdrożeniem. Narzędzie odpowiadające na pojedyncze pytania bez ciągłości, na przykład klasyfikator albo generator opisów produktów, nic nie zyska.

Podobnie rozmowa mieszcząca się w kilkunastu wymianach zdań. Przy współczesnych oknach kontekstu wysłanie całej historii jest prostsze, tańsze w utrzymaniu i nie wprowadza ryzyka, że warstwa pamięci zapamięta coś błędnie.

Trzeci przypadek to dane wymagające ścisłej poprawności, jak saldo konta albo status zamówienia. Tych rzeczy nie zapamiętuje się w warstwie pamięci, tylko pobiera z systemu źródłowego przy każdym pytaniu, bo zapamiętany stan sprzed tygodnia jest gorszy niż brak odpowiedzi.

Typowe błędy

Pierwszy to brak rozdzielenia użytkowników. Wspólny identyfikator oznacza, że fakty jednej osoby trafiają do promptu innej, co jest wyciekiem danych, a nie usterką wygody.

Drugi to zapisywanie wszystkiego. Każda wymiana zdań przekazana do zapisu to wywołanie modelu i kolejne wpisy w bazie. Zapisuj to, co niesie fakt o użytkowniku, a nie potwierdzenia i uprzejmości.

Trzeci to zbyt duży limit przy odczycie. Dwadzieścia faktów w prompcie to znowu ściana tekstu, przed którą pamięć miała chronić. Pięć trafnych wpisów działa lepiej niż dwadzieścia przypadkowych.

Czwarty to brak możliwości podejrzenia i usunięcia zapamiętanych danych. Użytkownik ma prawo wiedzieć, co system o nim wie, więc interfejs do przeglądania i kasowania wpisów należy zaplanować od początku, a nie dopiero po pierwszym zgłoszeniu.

Piąty to zapisywanie synchroniczne przed odpowiedzią. Dokłada opóźnienie widoczne dla użytkownika, a nie wnosi nic, czego nie da się zrobić po odesłaniu wyniku.

FAQ

Czym Mem0 różni się od zwykłej bazy wektorowej?

Baza wektorowa przechowuje i wyszukuje fragmenty, a warstwa pamięci dokłada wydobywanie faktów z rozmowy, rozpoznawanie sprzeczności i aktualizowanie starych wpisów. Można to napisać samodzielnie na Pineconie albo Qdrancie, tylko że to kilkaset linii logiki, którą trzeba potem utrzymywać.

Czy Mem0 jest darmowy?

Wersja otwarta tak, uruchamiasz ją u siebie i płacisz wyłącznie za bazę oraz za wywołania modelu przy wydobywaniu faktów. Wersja hostowana ma plan darmowy z limitem dziesięciu tysięcy zapisów i tysiąca odczytów miesięcznie, a plany płatne zaczynają się od 19 dolarów. Pamięć grafowa włącza się od planu Pro za 249 dolarów, powyżej którego jest jeszcze Enterprise z wyceną indywidualną.

Ile to realnie oszczędza?

Zależy od długości rozmów. Przy historii rzędu pięćdziesięciu tysięcy tokenów zastąpionej pięcioma setkami tokenów faktów oszczędność na wejściu jest kilkudziesięciokrotna, ale trzeba od niej odjąć koszt wydobywania przy zapisie. Przy krótkich rozmowach bilans wychodzi na zero albo na minus.

Z czym się integruje?

Dokumentacja obejmuje ponad dwadzieścia frameworków i platform w Pythonie oraz TypeScripcie, między innymi LangChain, LangGraph i CrewAI. Osobno działa serwer w protokole MCP, który podłącza pamięć do asystentów i edytorów.

Czy dane da się trzymać u siebie?

Tak, wersja otwarta działa w całości lokalnie. Bazę wektorową uruchamiasz we własnej infrastrukturze, a osadzenia liczysz modelem lokalnym, więc treść rozmów nie opuszcza Twojego środowiska. To standardowy wybór przy wymogach zgodności.

Dokumentacja stoi na stronie projektu, a kod źródłowy w repozytorium na GitHubie.