Runtime-ul de memorie pentru agenți EverOS adoptă formatul Markdown
EverMind a lansat EverOS, un runtime de memorie pentru agenți open-source, pe 29 iunie 2026, poziționându-l ca o metodă bazată pe Markdown pentru a oferi agenților AI memorie între sesiuni. Acest lucru este esențial deoarece majoritatea stivelor pentru agenți eșuează în moduri plictisitoare și costisitoare odată ce contextul dispare: reîncercările cresc, transferurile devin haotice și fiecare sarcină pornește din nou de la zero. Conform raportului MarkTechPost din 29 iunie despre EverOS, EverOS este livrat sub licența Apache 2.0 și combină fișiere Markdown, SQLite și LanceDB pentru memorie persistentă.
EverMind lansează EverOS pentru a oferi agenților AI memorie persistentă
Din punct de vedere al implementării, EverOS nu încearcă să fie un framework complet pentru agenți. Este o bibliotecă Python și un runtime local pe care îl poți integra într-o buclă existentă, expune prin FastAPI și conecta la backend-uri de modele care utilizează deja protocolul OpenAI. Această sferă de aplicare mai restrânsă este motivul pentru care această lansare merită atenție.
Problema pe care o abordează este familiară. Într-un prototip pentru un client la care am lucrat luna trecută, modelul a gestionat bine un flux de lucru de asistență în primele 20 de minute, apoi a uitat preferințele specifice ale clientului în a doua sesiune și a început să ceară informații pe care le văzuse deja. Modelul era bun; stratul de memorie era subțire. EverOS vizează exact acest gol: memorie persistentă pentru agenți AI fără a forța totul într-un singur vector store.
MarkTechPost explică clar ideea: EverOS tratează memoria ca pe niște fișiere editabile, nu ca pe înregistrări ascunse într-o bază de date. Aceasta este o distincție practică, nu doar o preferință de design. Dacă memoria este un fișier, un inginer o poate inspecta, compara, versiona și repara fără a inventa o altă interfață de administrare.
Markdown devine sursa de adevăr pentru memoria agenților
Partea neobișnuită este sursa de adevăr. EverOS scrie înregistrările de memorie ca fișiere .md simple, în timp ce o bibliotecă însoțitoare, EverAlgo, gestionează logica de extracție. Aceasta înseamnă că profilurile, episoadele, faptele, previziunile, cazurile și competențele sunt toate reprezentate într-un format pe care un om îl poate deschide direct. Dacă echipa ta folosește deja Git, instrumente shell sau sisteme de notițe precum Obsidian, modelul operațional este imediat lizibil.
Îmi place acest lucru mai mult decât mă așteptam. În producție, erorile de memorie nu sunt adesea erori de regăsire, ci erori de structură a stării. O preferință a fost îmbinată de două ori. O cheie de identitate a utilizatorului a deviat. Un pas de extracție a fost supra-ajustat pe o frază. Ascunderea acestor probleme în interiorul embedding-urilor le face mai greu de diagnosticat. Stocarea stării canonice în Markdown oferă echipelor o cale de depanare mai simplă.
Există totuși indexare în fundal. EverOS utilizează monitorizarea fișierelor și o cascadă de sincronizare, astfel încât modificările aduse fișierelor Markdown să nu lase căutarea învechită. Aceasta este partea pe care aș testa-o riguros într-un proiect pilot, mai ales dacă mai mulți agenți sau lucrători pot scrie simultan. Conceptul de „local-first” sună bine până când apar scrieri concurente, eșecuri parțiale și întârzieri în coadă.
O alegere de design conexă este izolarea domeniului. Căutările pot fi restricționate prin user_id, agent_id, app_id, project_id și session_id. Pentru automatizarea enterprise, acestea sunt condiții de bază. Dacă aș integra acest lucru într-un flux de lucru live, aș revizui acele limite înainte de orice benchmark.
Echipele care evaluează modul în care acest lucru se integrează într-o stivă de livrare mai largă vor fi probabil mai puțin interesate de noutatea Markdown și mai mult de cât de rapid poate fi integrat în fluxuri de lucru reale. Aici, un serviciu precum AI Business Process Automation este cea mai potrivită soluție: EverOS pare cel mai util atunci când memoria este o componentă în cadrul unui proces automatizat mai mare, nu un proiect de cercetare de sine stătător.
Cum combină EverOS SQLite, LanceDB, BM25 și vectori
Sub capotă, stiva de stocare este intenționat mică. Markdown este sursa de adevăr. SQLite gestionează starea și cozile. LanceDB gestionează vectorii, BM25 și filtrarea scalară. Comparativ cu stivele de memorie mai grele care includ Redis, Elasticsearch, Kafka și o bază de date vectorială separată, aceasta reprezintă o amprentă mai ușoară pentru o echipă mică.
Principala promisiune de regăsire este căutarea hibridă într-o singură interogare: BM25 pentru precizia cuvintelor cheie, vectori denși pentru similitudine semantică și filtre scalare pentru limitele de metadate. Dacă ai văzut vreodată regăsirea bazată doar pe vectori ratând un cod de produs exact sau un nume de client deoarece embedding-ul a clasat un concept mai larg mai sus, știi de ce BM25 este încă important. Regăsirea hibridă BM25-vector nu este spectaculoasă, dar rezolvă moduri de eșec foarte reale.
Conform articolului sursă, EverMind numește această cale combinată generare augmentată prin regăsire multimodală, sau mRAG. Mecanica contează mai mult decât eticheta. Întrebarea este dacă interogările tale sunt în mare parte semantice, lexicale sau mixte. În jurnalele de asistență, textele de conformitate și depanarea tehnică, acestea sunt de obicei mixte.
Acesta este și punctul în care EverOS pare mai puternic decât memoria bazată doar pe prompt-uri. Introducerea mai multor date istorice în fereastra de context funcționează până când costul, latența sau degradarea atenției încep să devină o problemă. Un strat de regăsire cu potrivire exactă a termenilor și căutare limitată îmbătrânește de obicei mai bine decât simpla mărire a prompt-ului.
Cazurile devin Competențe în EverOS
Funcționalitatea mai interesantă este memoria procedurală. EverOS stochează sarcinile finalizate ca „Cazuri” (Cases), apoi distilează tiparele repetate de succes în „Competențe” (Skills) reutilizabile. Aș descrie acest lucru mai puțin ca pe o magie de auto-îmbunătățire și mai mult ca pe o compresie a fluxului de lucru. Dacă un agent rezolvă în mod repetat aceeași clasă de sarcini, păstrarea căii de succes este mai utilă decât stocarea la nesfârșit a transcrierilor brute.
Totuși, aici aș fi cel mai sceptic. Conductele de distilare pot devia. Pot generaliza excesiv dintr-un eșantion mic, pot păstra pași fragili sau pot perpetua o decizie proastă care a părut de succes într-un singur context. EverOS versiunea 1.1.0 adaugă componente de ciclu de viață precum API-uri de cunoștințe și reflecție pentru a rafina profilurile, episoadele și competențele între sesiuni, ceea ce este direcția corectă. Dar aș dori în continuare audituri despre cum un Caz devine o Competență și cât de ușor este să revii la o stare anterioară.
Articolul sursă explică simplu modelul de memorie: memoria episodică urmărește ce s-a întâmplat, memoria de profil urmărește cine este utilizatorul, iar memoria procedurală urmărește cum se realizează o sarcină. Aceasta este o separare utilă. Majoritatea echipelor încep cu istoricul chat-ului, apoi realizează prea târziu că memoria sarcinilor și memoria utilizatorului nu ar trebui amestecate într-un jurnal nediferențiat.
Unde se încadrează EverOS față de RAG-ul naiv și ferestrele de context complete
EverOS pare cel mai potrivit pentru echipele care au deja o buclă de agenți și au nevoie de un subsistem de memorie mai mic pe care să îl poată inspecta. Față de RAG-ul naiv, câștigul nu este doar vectori plus BM25. Este combinația de stare lizibilă pentru oameni, delimitarea metadatelor și un strat de memorie procedurală. Față de abordările cu context complet, câștigul este persistența și selectivitatea.
Dar compromisurile sunt reale. Adevărul bazat pe fișiere este mai ușor de inspectat, dar poate deveni mai greu de guvernat dacă denumirea, schemele și disciplina de scriere sunt neglijente. SQLite menține stiva compactă, dar trebuie totuși să te gândești la limitele de concurență și procedurile de recuperare. LanceDB reduce complexitatea stivei, dar tot trebuie să te ocupi de indexare și de calitatea regăsirii în timp.
Pe partea pozitivă, runtime-ul pare ușor de testat. MarkTechPost notează Python 3.12+, un demo local, un server FastAPI și endpoint-uri compatibile cu OpenAI care pot fi redirecționate către OpenAI, OpenRouter, vLLM, Ollama sau DeepInfra cu o simplă modificare a URL-ului de bază. Acest lucru reduce efortul de integrare pentru echipele care doresc să testeze memoria fără a schimba mai întâi stratul de model.
Ce ar trebui să verifice echipele înainte de a adopta EverOS
Cifrele de benchmark sunt promițătoare, dar nu sunt încă suficiente pentru a lua o decizie. Articolul sursă citează scoruri raportate de EverMind de 93,05% pe LoCoMo, 83,00% pe LongMemEval, 93,04% pe HaluMem și o latență de regăsire p95 sub 500ms. Aș trata acestea ca pe un punct de plecare, nu ca pe o dovadă. Rulează aceleași teste pe propriul tău flux de lucru, mai ales dacă datele tale includ fire tehnice lungi, limite stricte de tenanță sau sesiuni cu scriere intensă.
Ceea ce aș urmări în continuare este dacă primii adoptatori vor publica rapoarte de eșec, precum și cazuri de succes. Dacă EverOS menține stratul de memorie inspectabil sub o sarcină reală multi-agent, designul bazat pe Markdown ar putea deveni un standard. Dacă nu, ideea ar putea influența în continuare modul în care echipele construiesc următoarea generație de runtime-uri de memorie pentru agenți, chiar dacă vor înlocui părți din stivă.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation