Runtime pamięci agentów EverOS stawia na Markdown
29 czerwca 2026 r. firma EverMind udostępniła EverOS, open-source'owy runtime pamięci agentów, pozycjonując go jako rozwiązanie typu „Markdown-first”, które zapewnia agentom AI pamięć między sesjami. Jest to istotne, ponieważ większość stosów technologicznych dla agentów zawodzi w nudny i kosztowny sposób, gdy znika kontekst: liczba ponownych prób rośnie, przekazywanie zadań staje się chaotyczne, a każde zadanie zaczyna się od zera. Według raportu MarkTechPost z 29 czerwca na temat EverOS, EverOS jest wydawany na licencji Apache 2.0 i łączy pliki Markdown, SQLite oraz LanceDB w celu zapewnienia trwałej pamięci.
EverMind wydaje EverOS, aby zapewnić agentom AI trwałą pamięć
Z punktu widzenia implementacji, EverOS nie próbuje być kompletnym frameworkiem dla agentów. To biblioteka Python i runtime typu „local-first”, który można wdrożyć w istniejącej pętli, udostępnić przez FastAPI i skierować do backendów modeli, które już obsługują protokół OpenAI. Ten węższy zakres sprawia, że warto przyjrzeć się tej premierze.
Problem, który rozwiązuje, jest dobrze znany. W jednym z prototypów dla klienta, nad którym pracowałem w zeszłym miesiącu, model dobrze radził sobie z obsługą zgłoszeń przez pierwsze 20 minut, a następnie zapominał o preferencjach klienta podczas drugiej sesji i zaczynał pytać o informacje, które już widział. Model był w porządku; warstwa pamięci była zbyt cienka. EverOS celuje dokładnie w tę lukę: trwała pamięć dla agentów AI bez konieczności upychania wszystkiego w jednej bazie wektorowej.
MarkTechPost jasno parafrazuje tę koncepcję: EverOS traktuje pamięć jako edytowalne pliki, a nie ukryte rekordy bazy danych. To praktyczne rozróżnienie, a nie tylko preferencja projektowa. Jeśli pamięć jest plikiem, inżynier może ją sprawdzić, porównać (diff), wersjonować i naprawić bez tworzenia kolejnego panelu administracyjnego.
Markdown staje się źródłem prawdy dla pamięci agentów
Nietypowym elementem jest źródło prawdy. EverOS zapisuje rekordy pamięci jako zwykłe pliki .md, podczas gdy biblioteka towarzysząca, EverAlgo, obsługuje logikę ekstrakcji. Oznacza to, że profile, epizody, fakty, prognozy, przypadki i umiejętności są reprezentowane w formacie, który człowiek może bezpośrednio otworzyć. Jeśli Twój zespół korzysta już z Git, narzędzi powłoki lub systemów notatek takich jak Obsidian, model operacyjny jest natychmiast czytelny.
Podoba mi się to bardziej, niż się spodziewałem. W środowisku produkcyjnym błędy pamięci często nie wynikają z błędów wyszukiwania, lecz z błędów struktury stanu. Preferencja została scalona dwukrotnie. Klucz tożsamości użytkownika uległ przesunięciu. Krok ekstrakcji nadmiernie dopasował się do jednej frazy. Ukrywanie tych problemów wewnątrz embeddingów sprawia, że trudniej je zdiagnozować. Przechowywanie kanonicznego stanu w Markdown daje zespołom prostszą ścieżkę debugowania.
Pod spodem nadal istnieje indeksowanie. EverOS wykorzystuje monitorowanie plików i kaskadę synchronizacji, dzięki czemu edycje w Markdown nie powodują przestarzałości wyszukiwania. To część, którą przetestowałbym bardzo dokładnie w fazie pilotażowej, zwłaszcza jeśli wielu agentów lub pracowników może pisać jednocześnie. Podejście „local-first” brzmi dobrze, dopóki nie pojawią się jednoczesne zapisy, częściowe awarie i opóźnienia w kolejkach.
Powiązanym wyborem projektowym jest izolacja zakresu. Wyszukiwania mogą być ograniczone przez user_id, agent_id, app_id, project_id oraz session_id. W automatyzacji korporacyjnej to podstawa. Gdybym wdrażał to w działający proces, sprawdziłbym te granice przed jakimikolwiek wykresami porównawczymi.
Zespoły oceniające, jak to pasuje do szerszego stosu dostarczania, prawdopodobnie mniej przejmą się nowością Markdown, a bardziej tym, jak szybko można to zintegrować z rzeczywistymi procesami. W tym miejscu usługa taka jak AI Business Process Automation najlepiej pasuje: EverOS wydaje się najbardziej użyteczny, gdy pamięć jest jednym z komponentów większego zautomatyzowanego procesu, a nie samodzielnym projektem badawczym.
Jak EverOS łączy SQLite, LanceDB, BM25 i wektory
Pod maską stos pamięci jest celowo niewielki. Markdown jest źródłem prawdy. SQLite obsługuje stan i kolejki. LanceDB obsługuje wektory, BM25 i filtrowanie skalarne. W porównaniu z cięższymi stosami pamięci, które wymagają Redis, Elasticsearch, Kafka i oddzielnej bazy danych wektorowych, jest to lżejszy ślad dla małego zespołu.
Kluczową zaletą wyszukiwania jest wyszukiwanie hybrydowe w jednym zapytaniu: BM25 dla precyzji słów kluczowych, gęste wektory dla podobieństwa semantycznego i filtry skalarne dla granic metadanych. Jeśli kiedykolwiek widziałeś, jak wyszukiwanie tylko wektorowe pomija dokładny kod produktu lub nazwę klienta, ponieważ embedding wyżej ocenił szerszą koncepcję, wiesz, dlaczego BM25 nadal ma znaczenie. Hybrydowe wyszukiwanie BM25 + wektorowe nie jest krzykliwe, ale naprawia bardzo realne tryby awarii.
Według artykułu źródłowego, EverMind nazywa tę połączoną ścieżkę multimodalną generacją wspomaganą wyszukiwaniem (mRAG). Mechanika jest ważniejsza niż etykieta. Pytanie brzmi, czy Twoje zapytania są głównie semantyczne, leksykalne czy mieszane. W logach wsparcia, tekstach zgodności i rozwiązywaniu problemów technicznych zazwyczaj są mieszane.
To również miejsce, w którym EverOS wygląda lepiej niż pamięć oparta tylko na promptach. Wrzucanie większej ilości historii do okna kontekstowego działa do momentu, w którym koszty, opóźnienia lub zanik uwagi zaczynają być odczuwalne. Warstwa wyszukiwania z dopasowywaniem dokładnych terminów i wyszukiwaniem o ograniczonym zakresie zazwyczaj starzeje się lepiej niż po prostu powiększanie promptu.
Przypadki stają się Umiejętnościami w EverOS
Ciekawszą funkcją jest pamięć proceduralna. EverOS przechowuje zakończone zadania jako Przypadki (Cases), a następnie destyluje powtarzalne udane wzorce w reużywalne Umiejętności (Skills). Opisałbym to mniej jako magię samodoskonalenia, a bardziej jako kompresję procesów. Jeśli agent wielokrotnie rozwiązuje ten sam typ zadania, zachowanie udanej ścieżki jest bardziej użyteczne niż przechowywanie surowych transkrypcji w nieskończoność.
To jednak miejsce, w którym byłbym najbardziej sceptyczny. Potoki destylacji mogą ulec dryfowi. Mogą nadmiernie generalizować na podstawie małej próbki, zachowywać kruche kroki lub przenosić złą decyzję, która w jednym kontekście wyglądała na udaną. EverOS w wersji 1.1.0 dodaje komponenty cyklu życia, takie jak Knowledge APIs i Reflection, aby udoskonalać profile, epizody i umiejętności między sesjami, co jest właściwym kierunkiem. Nadal jednak chciałbym audytów tego, jak Przypadek staje się Umiejętnością i jak łatwo jest wycofać zmiany.
Artykuł źródłowy opisuje model pamięci w prosty sposób: pamięć epizodyczna śledzi, co się wydarzyło, pamięć profilowa śledzi, kim jest użytkownik, a pamięć proceduralna śledzi, jak wykonać zadanie. To użyteczne rozdzielenie. Większość zespołów zaczyna od historii czatu, a potem zbyt późno orientuje się, że pamięć zadań i pamięć użytkownika nie powinny być mieszane w jeden niezróżnicowany log.
Gdzie EverOS pasuje w porównaniu z naiwnym RAG i pełnymi oknami kontekstowymi
EverOS wygląda najlepiej dla zespołów, które już mają pętlę agenta i potrzebują mniejszego podsystemu pamięci, który mogą kontrolować. W porównaniu z naiwnym RAG, zyskiem nie są tylko wektory plus BM25. To połączenie czytelnego dla człowieka stanu, zakresu metadanych i warstwy pamięci proceduralnej. W porównaniu z podejściami pełnego kontekstu, zyskiem jest trwałość i selektywność.
Ale kompromisy są realne. Prawda oparta na plikach jest łatwiejsza do sprawdzenia, ale może stać się trudniejsza do zarządzania, jeśli nazewnictwo, schematy i dyscyplina zapisu są niechlujne. SQLite utrzymuje stos w zwartej formie, ale nadal trzeba myśleć o limitach współbieżności i procedurach odzyskiwania. LanceDB redukuje rozrost stosu, ale nadal decydujesz się na obsługę indeksowania i jakości wyszukiwania w czasie.
Pozytywną stroną jest to, że runtime wydaje się łatwy do przetestowania. MarkTechPost zauważa, że Python 3.12+, lokalne demo, serwer FastAPI i punkty końcowe kompatybilne z OpenAI, które można przekierować do OpenAI, OpenRouter, vLLM, Ollama lub DeepInfra za pomocą zmiany base-URL, obniżają koszt integracji dla zespołów, które chcą przetestować pamięć bez zmiany platformy warstwy modelu.
Co zespoły powinny zweryfikować przed przyjęciem EverOS
Liczby w benchmarkach są obiecujące, ale same w sobie nie są jeszcze podstawą do decyzji. Artykuł źródłowy cytuje wyniki zgłoszone przez EverMind: 93,05% w LoCoMo, 83,00% w LongMemEval, 93,04% w HaluMem i opóźnienie wyszukiwania p95 poniżej 500 ms. Traktowałbym to jako punkt wyjścia, a nie dowód. Przeprowadź te same testy na własnym obciążeniu, zwłaszcza jeśli Twoje dane obejmują długie wątki techniczne, ścisłe granice najmu lub sesje o wysokiej częstotliwości zapisu.
To, co będę obserwował dalej, to czy wczesni użytkownicy opublikują raporty o błędach, a także przypadki sukcesu. Jeśli EverOS utrzyma warstwę pamięci w stanie umożliwiającym inspekcję przy rzeczywistym obciążeniu wieloma agentami, projekt „Markdown-first” może się przyjąć. Jeśli nie, pomysł ten może nadal wpłynąć na to, jak zespoły budują następną generację runtime'ów pamięci agentów, nawet jeśli wymienią części stosu.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation