Το EverOS, το runtime μνήμης για πράκτορες, υιοθετεί το Markdown ως πρώτη επιλογή
Η EverMind κυκλοφόρησε το EverOS, ένα open-source runtime μνήμης για πράκτορες (agent memory runtime), στις 29 Ιουνίου 2026, τοποθετώντας το ως μια λύση που βασίζεται στο Markdown για να παρέχει στους πράκτορες AI μνήμη μεταξύ των συνεδριών. Αυτό είναι σημαντικό, καθώς τα περισσότερα stacks πρακτόρων αποτυγχάνουν με βαρετούς και δαπανηρούς τρόπους μόλις χαθεί το πλαίσιο: οι επαναλήψεις αυξάνονται, οι μεταβιβάσεις γίνονται χαοτικές και κάθε εργασία ξεκινά πάλι από το μηδέν. Σύμφωνα με την αναφορά του MarkTechPost της 29ης Ιουνίου για το EverOS, το EverOS διατίθεται υπό την άδεια Apache 2.0 και συνδυάζει αρχεία Markdown, SQLite και LanceDB για μόνιμη μνήμη.
Η EverMind κυκλοφορεί το EverOS για να δώσει στους πράκτορες AI μόνιμη μνήμη
Από πλευράς υλοποίησης, το EverOS δεν προσπαθεί να αποτελέσει ένα ολοκληρωμένο πλαίσιο πρακτόρων. Είναι μια βιβλιοθήκη Python και ένα local-first runtime που μπορείτε να ενσωματώσετε σε έναν υπάρχοντα βρόχο, να εκθέσετε μέσω FastAPI και να κατευθύνετε σε μοντέλα backends που υποστηρίζουν ήδη το πρωτόκολλο OpenAI. Αυτό το περιορισμένο εύρος είναι ο λόγος που αξίζει να παρακολουθήσετε αυτή την κυκλοφορία.
Το πρόβλημα που επιλύει είναι οικείο. Σε ένα πρωτότυπο πελάτη στο οποίο εργάστηκα τον περασμένο μήνα, το μοντέλο διαχειρίστηκε καλά μια ροή εργασίας υποστήριξης για τα πρώτα 20 λεπτά, μετά ξέχασε τις προτιμήσεις του πελάτη στη δεύτερη συνεδρία και άρχισε να ζητά πληροφορίες που είχε ήδη δει. Το μοντέλο ήταν μια χαρά· το επίπεδο μνήμης ήταν ανεπαρκές. Το EverOS στοχεύει ακριβώς σε αυτό το κενό: μόνιμη μνήμη για πράκτορες AI χωρίς να αναγκάζει τα πάντα να εισαχθούν σε ένα ενιαίο διανυσματικό κατάστημα (vector store).
Το MarkTechPost συνοψίζει την ιδέα με σαφήνεια: το EverOS αντιμετωπίζει τη μνήμη ως επεξεργάσιμα αρχεία και όχι ως κρυφές εγγραφές βάσης δεδομένων. Αυτή είναι μια πρακτική διάκριση, όχι απλώς μια σχεδιαστική προτίμηση. Εάν η μνήμη είναι αρχείο, ένας μηχανικός μπορεί να την επιθεωρήσει, να τη συγκρίνει (diff), να τη διαχειριστεί με εκδόσεις και να την επιδιορθώσει χωρίς να εφεύρει ένα επιπλέον admin UI.
Το Markdown γίνεται η πηγή αλήθειας για τη μνήμη των πρακτόρων
Το ασυνήθιστο κομμάτι είναι η πηγή αλήθειας. Το EverOS γράφει εγγραφές μνήμης ως απλά αρχεία .md, ενώ μια συνοδευτική βιβλιοθήκη, το EverAlgo, διαχειρίζεται τη λογική εξαγωγής. Αυτό σημαίνει ότι προφίλ, επεισόδια, γεγονότα, προβλέψεις, περιπτώσεις και δεξιότητες αναπαρίστανται όλα σε μια μορφή που ένας άνθρωπος μπορεί να ανοίξει απευθείας. Εάν η ομάδα σας χρησιμοποιεί ήδη Git, εργαλεία κελύφους ή συστήματα σημειώσεων όπως το Obsidian, το λειτουργικό μοντέλο είναι άμεσα κατανοητό.
Μου αρέσει αυτό περισσότερο από όσο περίμενα. Στην παραγωγή, τα σφάλματα μνήμης συχνά δεν είναι σφάλματα ανάκτησης· είναι σφάλματα στη δομή της κατάστασης. Μια προτίμηση συγχωνεύτηκε δύο φορές. Ένα κλειδί ταυτότητας χρήστη μετατοπίστηκε. Ένα βήμα εξαγωγής υπερπροσαρμόστηκε σε μια φράση. Η απόκρυψη αυτών των προβλημάτων μέσα σε embeddings τα καθιστά πιο αργά στη διάγνωση. Η αποθήκευση της κανονικής κατάστασης σε Markdown δίνει στις ομάδες μια απλούστερη διαδρομή εντοπισμού σφαλμάτων.
Υπάρχει ακόμα ευρετηρίαση από κάτω. Το EverOS χρησιμοποιεί παρακολούθηση αρχείων και μια αλληλουχία συγχρονισμού, ώστε οι επεξεργασίες στο Markdown να μην αφήνουν την αναζήτηση παρωχημένη. Αυτό είναι το κομμάτι που θα δοκίμαζα εξαντλητικά σε ένα πιλοτικό πρόγραμμα, ειδικά αν πολλοί πράκτορες ή εργαζόμενοι μπορούν να γράφουν ταυτόχρονα. Το local-first ακούγεται καθαρό μέχρι να εμφανιστούν ταυτόχρονες εγγραφές, μερικές αποτυχίες και καθυστέρηση ουράς.
Μια σχετική επιλογή σχεδιασμού είναι η απομόνωση του εύρους. Οι αναζητήσεις μπορούν να περιοριστούν από user_id, agent_id, app_id, project_id και session_id. Για τον αυτοματισμό επιχειρήσεων, αυτό είναι το ελάχιστο απαραίτητο. Αν το ενσωμάτωνα σε μια ζωντανή ροή εργασίας, θα εξέταζα αυτά τα όρια πριν από οποιοδήποτε διάγραμμα συγκριτικής αξιολόγησης.
Οι ομάδες που αξιολογούν πώς ταιριάζει αυτό σε ένα ευρύτερο stack παράδοσης πιθανότατα θα ενδιαφέρονται λιγότερο για την καινοτομία του Markdown και περισσότερο για το πόσο γρήγορα μπορεί να ενσωματωθεί σε πραγματικές ροές εργασίας. Εκεί είναι που μια υπηρεσία όπως το AI Business Process Automation ταιριάζει καλύτερα: το EverOS φαίνεται πιο χρήσιμο όταν η μνήμη είναι ένα συστατικό μέσα σε μια μεγαλύτερη αυτοματοποιημένη διαδικασία, όχι ένα επιστημονικό project από μόνο του.
Πώς το EverOS συνδυάζει SQLite, LanceDB, BM25 και διανύσματα
Στο παρασκήνιο, το stack αποθήκευσης είναι σκόπιμα μικρό. Το Markdown είναι η πηγή αλήθειας. Το SQLite διαχειρίζεται την κατάσταση και τις ουρές. Το LanceDB διαχειρίζεται διανύσματα, BM25 και βαθμωτό φιλτράρισμα. Σε σύγκριση με βαρύτερα stacks μνήμης που χρησιμοποιούν Redis, Elasticsearch, Kafka και μια ξεχωριστή διανυσματική βάση δεδομένων, αυτό είναι ένα ελαφρύτερο αποτύπωμα για μια μικρή ομάδα.
Η βασική αξίωση ανάκτησης είναι η υβριδική αναζήτηση σε ένα ερώτημα: BM25 για ακρίβεια λέξεων-κλειδιών, πυκνά διανύσματα για σημασιολογική ομοιότητα και βαθμωτά φίλτρα για όρια μεταδεδομένων. Αν έχετε δει ποτέ την ανάκτηση μόνο με διανύσματα να χάνει έναν ακριβή κωδικό προϊόντος ή ένα όνομα πελάτη επειδή το embedding κατέταξε υψηλότερα μια ευρύτερη έννοια, ξέρετε γιατί το BM25 εξακολουθεί να έχει σημασία. Η υβριδική ανάκτηση BM25 με διανύσματα δεν είναι εντυπωσιακή, αλλά διορθώνει πολύ πραγματικούς τρόπους αποτυχίας.
Σύμφωνα με το άρθρο πηγής, η EverMind αναφέρεται σε αυτή τη συνδυασμένη διαδρομή ως πολυτροπική γενιά με ενίσχυση ανάκτησης (multimodal retrieval-augmented generation), ή mRAG. Οι μηχανισμοί έχουν μεγαλύτερη σημασία από την ετικέτα. Το ερώτημα είναι αν τα ερωτήματά σας είναι κυρίως σημασιολογικά, κυρίως λεξικά ή μικτά. Στα αρχεία υποστήριξης, στο κείμενο συμμόρφωσης και στην τεχνική αντιμετώπιση προβλημάτων, είναι συνήθως μικτά.
Εδώ είναι επίσης που το EverOS φαίνεται ισχυρότερο από τη μνήμη που βασίζεται μόνο σε prompt. Η προσθήκη περισσότερου ιστορικού στο παράθυρο πλαισίου λειτουργεί μέχρι να αρχίσουν να επηρεάζουν το κόστος, η καθυστέρηση ή η φθορά της προσοχής. Ένα επίπεδο ανάκτησης με αντιστοίχιση ακριβών όρων και στοχευμένη αναζήτηση συνήθως γερνάει καλύτερα από το να κάνετε απλώς το prompt μεγαλύτερο.
Οι περιπτώσεις μετατρέπονται σε Δεξιότητες στο EverOS
Το πιο ενδιαφέρον χαρακτηριστικό είναι η διαδικαστική μνήμη. Το EverOS αποθηκεύει ολοκληρωμένες εργασίες ως Περιπτώσεις (Cases) και στη συνέχεια αποστάζει επαναλαμβανόμενα επιτυχημένα μοτίβα σε επαναχρησιμοποιήσιμες Δεξιότητες (Skills). Θα το περιέγραφα λιγότερο ως μαγεία αυτοβελτίωσης και περισσότερο ως συμπίεση ροής εργασίας. Εάν ένας πράκτορας επιλύει επανειλημμένα την ίδια κατηγορία εργασίας, η διατήρηση της επιτυχημένης διαδρομής είναι πιο χρήσιμη από την αποθήκευση ακατέργαστων μεταγραφών για πάντα.
Τούτου λεχθέντος, εδώ θα ήμουν πιο σκεπτικός. Οι αγωγοί απόσταξης μπορούν να αποκλίνουν. Μπορούν να υπεργενικεύσουν από ένα μικρό δείγμα, να διατηρήσουν εύθραυστα βήματα ή να μεταφέρουν μια κακή απόφαση που έτυχε να φαίνεται επιτυχημένη σε ένα πλαίσιο. Η έκδοση 1.1.0 του EverOS προσθέτει στοιχεία κύκλου ζωής, όπως Knowledge APIs και Reflection, για τη βελτίωση προφίλ, επεισοδίων και δεξιοτήτων μεταξύ των συνεδριών, κάτι που είναι προς τη σωστή κατεύθυνση. Ωστόσο, θα ήθελα ακόμα ελέγχους για το πώς μια Περίπτωση γίνεται Δεξιότητα και πόσο εύκολο είναι να γίνει επαναφορά.
Το άρθρο πηγής θέτει το μοντέλο μνήμης απλά: η επεισοδιακή μνήμη παρακολουθεί τι συνέβη, η μνήμη προφίλ παρακολουθεί ποιος είναι ο χρήστης και η διαδικαστική μνήμη παρακολουθεί πώς γίνεται μια εργασία. Αυτός είναι ένας χρήσιμος διαχωρισμός. Οι περισσότερες ομάδες ξεκινούν με το ιστορικό συνομιλιών και μετά συνειδητοποιούν πολύ αργά ότι η μνήμη εργασιών και η μνήμη χρήστη δεν πρέπει να αναμειγνύονται σε ένα αδιαφοροποίητο αρχείο καταγραφής.
Πού ταιριάζει το EverOS σε σχέση με το απλό RAG και τα πλήρη παράθυρα πλαισίου
Το EverOS φαίνεται καλύτερο για ομάδες που έχουν ήδη έναν βρόχο πρακτόρων και χρειάζονται ένα μικρότερο υποσύστημα μνήμης που μπορούν να επιθεωρήσουν. Σε σχέση με το απλό RAG, το κέρδος δεν είναι μόνο τα διανύσματα συν το BM25. Είναι ο συνδυασμός αναγνώσιμης από τον άνθρωπο κατάστασης, καθορισμού ορίων μεταδεδομένων και ενός επιπέδου διαδικαστικής μνήμης. Σε σχέση με τις προσεγγίσεις πλήρους πλαισίου, το κέρδος είναι η επιμονή και η επιλεκτικότητα.
Όμως οι συμβιβασμοί είναι πραγματικοί. Η αλήθεια που βασίζεται σε αρχεία είναι πιο εύκολο να επιθεωρηθεί, αλλά μπορεί να γίνει πιο δύσκολο να κυβερνηθεί εάν η ονοματολογία, τα σχήματα και η πειθαρχία εγγραφής είναι χαλαρά. Το SQLite διατηρεί το stack συμπαγές, αλλά πρέπει ακόμα να σκεφτείτε τα όρια συγχρονισμού και τις διαδικασίες αποκατάστασης. Το LanceDB μειώνει τη διασπορά του stack, αλλά εξακολουθείτε να δεσμεύεστε να λειτουργείτε την ευρετηρίαση και την ποιότητα ανάκτησης με την πάροδο του χρόνου.
Στη θετική πλευρά, το runtime φαίνεται εύκολο για πιλοτική εφαρμογή. Το MarkTechPost σημειώνει Python 3.12+, ένα τοπικό demo, έναν διακομιστή FastAPI και endpoints συμβατά με OpenAI που μπορούν να ανακατευθυνθούν στο OpenAI, OpenRouter, vLLM, Ollama ή DeepInfra με μια αλλαγή base-URL. Αυτό μειώνει τον φόρο ενσωμάτωσης για ομάδες που θέλουν να δοκιμάσουν τη μνήμη χωρίς να αλλάξουν πρώτα το επίπεδο του μοντέλου.
Τι πρέπει να επαληθεύσουν οι ομάδες πριν υιοθετήσουν το EverOS
Οι αριθμοί των benchmarks είναι ελπιδοφόροι, αλλά όχι ακόμη ικανοί να αποτελέσουν τη βάση για αποφάσεις από μόνοι τους. Το άρθρο πηγής αναφέρει βαθμολογίες που αναφέρθηκαν από την EverMind: 93,05% στο LoCoMo, 83,00% στο LongMemEval, 93,04% στο HaluMem και καθυστέρηση ανάκτησης p95 κάτω από 500ms. Θα τα αντιμετώπιζα ως σημείο εκκίνησης, όχι ως απόδειξη. Εκτελέστε τις ίδιες δοκιμές στο δικό σας φόρτο εργασίας, ειδικά αν τα δεδομένα σας περιλαμβάνουν μεγάλα τεχνικά νήματα, αυστηρά όρια μίσθωσης ή συνεδρίες με πολλές εγγραφές.
Αυτό που θα παρακολουθούσα στη συνέχεια είναι αν οι πρώτοι χρήστες δημοσιεύσουν αναφορές αποτυχίας καθώς και περιπτώσεις επιτυχίας. Εάν το EverOS διατηρεί το επίπεδο μνήμης επιθεωρήσιμο υπό πραγματικό φόρτο πολλαπλών πρακτόρων, ο σχεδιασμός Markdown-first θα μπορούσε να επικρατήσει. Αν όχι, η ιδέα μπορεί να επηρεάσει ακόμα το πώς οι ομάδες χτίζουν την επόμενη γενιά runtimes μνήμης πρακτόρων, ακόμα κι αν αντικαταστήσουν μέρη του stack.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation