SKILL.state: γιατί οι AI agents χρειάζονται κατάσταση, όχι ατελείωτο ιστορικό

Σύντομη απάντηση: Σε ένα μακρύ workflow, ο AI agent δεν χρειάζεται να ξαναδιαβάζει όλο το παρελθόν του. Χρειάζεται μια ελεγχόμενη κατάσταση εκτέλεσης που κρατά ό,τι ισχύει τώρα, δέχεται μόνο έγκυρες αλλαγές και αφήνει τα πλήρη logs σε ξεχωριστό επίπεδο για audit και διερεύνηση.

Τι συμβαίνει όταν ένας AI agent πρέπει να ολοκληρώσει εκατό ή διακόσια διαδοχικά βήματα; Στα περισσότερα σημερινά συστήματα, κάθε νέα κίνηση συνοδεύεται από ένα ολοένα μεγαλύτερο ιστορικό: παλιές παρατηρήσεις, ενέργειες, αποτελέσματα εργαλείων και ενδιάμεσους συλλογισμούς. Ο agent καλείται ξανά και ξανά να ξεχωρίσει τι ισχύει τώρα από όσα ίσχυαν πριν. Το κόστος αυξάνεται, η καθυστέρηση μεγαλώνει και οι παλιές πληροφορίες μπορούν να παρασύρουν την επόμενη απόφαση.

Изследователската работа SKILL.state: Scalable Long-Horizon Agent Skills προτείνει μια διαφορετική αρχιτεκτονική. Αντί να αντιμετωπίζει τη συνομιλία ως μνήμη και ως μηχανισμό εκτέλεσης ταυτόχρονα, κρατά μια ρητή, δομημένη και μεταβλητή κατάσταση. Σε κάθε βήμα, το μοντέλο λαμβάνει μόνο την αμετάβλητη περιγραφή της διαδικασίας, την τρέχουσα κατάσταση και την τελευταία παρατήρηση. Ο ενδιάμεσος συλλογισμός χρησιμοποιείται για την απόφαση, αλλά δεν προστίθεται στο επόμενο prompt.

Για επιχειρήσεις που σχεδιάζουν αυτοματισμούς, customer-service agents, e-commerce λειτουργίες ή σύνθετα content pipelines, η ιδέα είναι σημαντική. Η αξιοπιστία ενός agent δεν εξαρτάται μόνο από το πόσο ισχυρό είναι το LLM. Εξαρτάται και από το τι επιλέγει το runtime να θυμάται, πώς το επικυρώνει και πώς αποτρέπει το παρελθόν από το να μολύνει την τρέχουσα απόφαση.

Το πρόβλημα δεν είναι απλώς το μικρό context window

Ένας συνηθισμένος agent λειτουργεί σαν μια συνομιλία που δεν τελειώνει. Μετά από κάθε tool call προστίθενται η παρατήρηση, ο συλλογισμός και η ενέργεια. Η προσέγγιση είναι εύκολη στην υλοποίηση και βοηθά το μοντέλο να «βλέπει» τι έχει προηγηθεί. Σε σύντομες εργασίες μπορεί να είναι επαρκής. Σε long-horizon workflows όμως το ιστορικό γίνεται όλο και μεγαλύτερο και περιέχει καταστάσεις που έχουν ήδη αλλάξει.

Η περίληψη ή η ανάκτηση επιλεγμένων αναμνήσεων περιορίζει μέρος του προβλήματος, αλλά διατηρεί την ίδια βασική λογική: η τρέχουσα πραγματικότητα ανακατασκευάζεται από κείμενο που περιγράφει το παρελθόν. Ακόμη και ένα framework που προσθέτει ένα structured state δίπλα στο transcript εξακολουθεί να δίνει στο μοντέλο παλιές ενέργειες και παρατηρήσεις. Η έρευνα υποστηρίζει ότι αυτό δημιουργεί «attention drag» και αυξάνει τον κίνδυνο να υπερισχύσει μια παλιά πληροφορία απέναντι σε μια νεότερη.

Το ουσιαστικό ερώτημα επομένως δεν είναι μόνο πόσα tokens χωρά το μοντέλο. Είναι αν το πλήρες ιστορικό αποτελεί πράγματι τη σωστή αναπαράσταση της εργασίας. Το SKILL.state απαντά ότι για πολλές διαδικαστικές εργασίες ο agent χρειάζεται κυρίως μια αξιόπιστη εικόνα του παρόντος, όχι αναπαραγωγή ολόκληρης της διαδρομής.

Η αρχιτεκτονική του SKILL.state σε τρία στοιχεία

Σε κάθε βήμα εκτέλεσης το SKILL.state σχηματίζει το input από τρία στοιχεία: την αμετάβλητη προδιαγραφή της δεξιότητας, τη δομημένη κατάσταση του συγκεκριμένου βήματος και την πιο πρόσφατη παρατήρηση του περιβάλλοντος. Το μοντέλο παράγει ενδιάμεσο reasoning, ένα patch που αλλάζει επιλεγμένα πεδία της κατάστασης και την επόμενη ενέργεια.

Το runtime ελέγχει ντετερμινιστικά το patch πριν το εφαρμόσει. Η ενημέρωση λειτουργεί ως συγχώνευση λεξικού, ενώ μια τιμή null μπορεί να σημαίνει διαγραφή πεδίου. Μόλις η μετάβαση επικυρωθεί, ο συλλογισμός απορρίπτεται. Στο επόμενο βήμα επιβιώνει μόνο ό,τι έχει καταγραφεί στη νέα κατάσταση και είναι χρήσιμο για το μέλλον.

Αυτό δεν σημαίνει ότι το μοντέλο σταματά να σκέφτεται. Το within-step reasoning παραμένει διαθέσιμο κατά τη δημιουργία της απόφασης. Η διαφορά είναι ότι η σκέψη δεν μετατρέπεται αυτόματα σε μόνιμη μνήμη. Η μόνιμη μνήμη είναι το validated state patch, όχι το ακατέργαστο ίχνος της προηγούμενης απάντησης.

Οι δημιουργοί δίνουν ένα πρακτικό παράδειγμα από το InterCode CTF: ένα κοινό schema πέντε πεδίων χρησιμοποιείται και στα 100 διαφορετικά challenges. Τα πεδία καταγράφουν flags που έχουν βρεθεί, υποθέσεις που δοκιμάστηκαν, ενεργά αρχεία, working directory και σύνοψη εντολών. Το schema ορίζεται ανά domain και όχι από την αρχή για κάθε μεμονωμένο task.

Από τετραγωνική σε γραμμική κατανάλωση context

Η θεωρητική διαφορά είναι καθαρή. Σε ένα append-only runtime, το prompt του βήματος t μεγαλώνει μαζί με το ιστορικό. Αν κάθε νέο βήμα περιλαμβάνει όλα τα προηγούμενα, το συνολικό κόστος εισόδου σε T βήματα αυξάνεται τετραγωνικά, δηλαδή O(T²). Στο SKILL.state, εφόσον η προδιαγραφή, το schema και η τελευταία παρατήρηση παραμένουν φραγμένα, το prompt κάθε βήματος δεν εξαρτάται από το πλήθος των προηγούμενων turns. Το αθροιστικό κόστος αυξάνεται γραμμικά, O(T).

Το επιχείρημα δεν είναι ότι κάθε πραγματική κατάσταση θα έχει πάντα ακριβώς το ίδιο μέγεθος. Είναι ότι δεν χρειάζεται να μεγαλώνει μηχανικά επειδή πέρασε ακόμη ένα βήμα. Αντί να πληρώνει ο οργανισμός ξανά για κάθε παλιό tool output, πληρώνει για μια συμπυκνωμένη αναπαράσταση όσων παραμένουν λειτουργικά σημαντικά.

Στο ελεγχόμενο warehouse benchmark με Gemini-3-Flash, για ορίζοντα 100 βημάτων το LangGraph-style baseline κατανάλωσε 1.062.387 tokens, ενώ το SKILL.state 65.408, με αντίστοιχη ακρίβεια 0,91 και 0,94. Η μείωση που αναφέρει η εργασία είναι 16,2 φορές. Στα 200 βήματα το SKILL.state διατήρησε ακρίβεια 0,94 με 122.384 tokens, ενώ το memory baseline έφτασε περίπου 6,18 εκατομμύρια tokens με ακρίβεια 0,84.

Δύο testbeds: αποθήκη και repository λογισμικού

Για να απομονώσουν τους μηχανισμούς εκτέλεσης από την ανοιχτή αναζήτηση, οι ερευνητές δημιούργησαν το SkillExecBench. Το πρώτο περιβάλλον είναι μια αποθήκη με 500 ανεξάρτητα ράφια. Ο agent δέχεται αφίξεις προϊόντων, παραγγελίες και συμβάντα συντήρησης και πρέπει να εκτελεί Store, Ship, Move ή Wait χωρίς να μπερδεύει θέσεις και αντικείμενα.

Το δεύτερο περιβάλλον αναπαριστά repository λογισμικού με branches, commits, pull requests, αρχεία και αποτελέσματα CI. Ενέργειες όπως merge ή νέα commit μεταβάλλουν πολλές συσχετισμένες οντότητες. Ένα λανθασμένο state δεν οδηγεί απλώς σε λάθος κείμενο, αλλά μπορεί να προκαλέσει merge σε λάθος branch ή να αγνοήσει αποτυχημένο pipeline.

Η επιλογή αυτών των περιβαλλόντων είναι εύστοχη για επιχειρηματική χρήση. Η αποθήκη μοντελοποιεί πολλές ανεξάρτητες μεταβλητές που αλλάζουν διαδοχικά, ενώ το repository μοντελοποιεί πυκνές σχέσεις και εξαρτήσεις. Μαζί εξετάζουν αν το state μπορεί να διατηρήσει τόσο μεγάλο πλήθος απλών facts όσο και μια πιο σύνθετη γράφικη δομή.

Ο θόρυβος δεν πρέπει να γίνεται μόνιμη μνήμη

Τα πραγματικά συστήματα παράγουν logs, telemetry και ειδοποιήσεις που δεν σχετίζονται με τον κύριο στόχο. Στο πείραμα θορύβου, οι ερευνητές κράτησαν τον ορίζοντα στα 50 βήματα και πρόσθεσαν 5, 20 ή 50 άσχετα συμβάντα ανά turn. Στην αποθήκη εμφανίζονταν δεδομένα για μπαταρίες ρομπότ, θερμοκρασία, CPU, υγρασία, φωτισμό και camera OCR. Στο repository εμφανίζονταν syslog μηνύματα από άσχετους servers.

Το απλό prompt runtime υποχώρησε από score 0,68 στον χαμηλό θόρυβο σε 0,53 στον υψηλό. Το SKILL.state διατήρησε score τουλάχιστον 0,97 και στα τρία επίπεδα. Σύμφωνα με την ερμηνεία των συγγραφέων, ο θόρυβος μπορεί να επηρεάσει την τρέχουσα απόφαση, αλλά αν δεν μεταβάλει την κατάσταση δεν μεταφέρεται στα επόμενα prompts.

Αυτή είναι χρήσιμη αρχή για marketing και e-commerce συστήματα. Ένα pipeline μπορεί να βλέπει analytics alerts, παλιά exports, προσωρινά API errors ή πολλαπλές εκδόσεις ενός catalog. Αν όλα αποθηκεύονται ως ισότιμο ιστορικό, ο agent πρέπει συνεχώς να τα επανεξετάζει. Αν το runtime κρατά μόνο ενεργές εργασίες, επιβεβαιωμένα IDs, τρέχον status και unresolved errors, το επόμενο βήμα ξεκινά από καθαρότερη βάση.

Η ανάκαμψη από αλλαγές δείχνει τη διαφορά μεταξύ ιστορίας και παρόντος

Ένα ακόμη πείραμα τροποποίησε σιωπηρά την πραγματική κατάσταση του περιβάλλοντος έξω από τον κύκλο ενεργειών του agent. Για παράδειγμα, ένας εξωτερικός παράγοντας μπορούσε να μετακινήσει ένα προϊόν σε άλλο ράφι. Τα history-based runtimes συνέχισαν για 5 έως 8 βήματα να στηρίζονται σε παλιές πληροφορίες πριν ανακάμψουν.

Στα τρία σενάρια που μπορούσαν να διορθωθούν, το SKILL.state χρειάστηκε μηδενικά βήματα ανάκαμψης: η διορθωτική παρατήρηση ενημέρωσε αμέσως την τρέχουσα κατάσταση. Σε ένα τέταρτο σενάριο, μια ακυρωμένη παραγγελία, κανένα runtime δεν πέτυχε. Η λεπτομέρεια έχει σημασία, γιατί η εργασία δεν παρουσιάζει την αρχιτεκτονική ως πανάκεια.

Για ένα CRM ή order-management workflow, η αναλογία είναι άμεση. Αν η κατάσταση μιας παραγγελίας αλλάξει από άλλο σύστημα, ο agent δεν πρέπει να «ψηφίζει» μεταξύ δέκα παλιών μηνυμάτων και ενός νέου event. Χρειάζεται σαφή κανόνα ώστε το verified current state να αντικαθιστά το ξεπερασμένο fact, μαζί με audit trail σε ξεχωριστό επίπεδο όπου απαιτείται.

Τα δημόσια benchmarks δείχνουν όφελος πέρα από το συνθετικό περιβάλλον

Η αξιολόγηση επεκτάθηκε στο InterCode CTF και στο Sierra τ-Bench. Το πρώτο περιλαμβάνει 100 Linux Capture-The-Flag tasks με reverse engineering, forensics, cryptography και binary exploitation. Το δεύτερο εξετάζει customer-service agents σε retail και airline σενάρια, με βάσεις δεδομένων, APIs, συναλλαγές και περιορισμούς πολιτικής.

Στο InterCode CTF το SKILL.state πέτυχε pass@1 54,2%, έναντι 46,4% για το ισχυρότερο από τα τρία βασικά baselines. Κατανάλωσε 387 χιλιάδες tokens, έναντι 977 χιλιάδων για το ReAct-style runtime και 1,13 εκατομμυρίων για το stateful baseline. Η ρητή καταγραφή δοκιμασμένων υποθέσεων και flags βοήθησε να μην επαναλαμβάνονται αποτυχημένες εντολές.

Στο τ-Bench Retail το SKILL.state είχε pass rate 58,3%, ενώ στο Airline 32,4%. Στο δεύτερο διατήρησε μέσο prompt περίπου 2.800 tokens ανά βήμα, εκεί όπου σύνθετες απαντήσεις βάσης δεδομένων έκαναν τα baseline prompts να κορυφώνονται πάνω από 11.000 tokens ανά βήμα. Τα αποτελέσματα παραμένουν από τη συγκεκριμένη πειραματική ρύθμιση με Gemini-3-Flash και δεν πρέπει να θεωρηθούν καθολική εγγύηση για κάθε production agent.

Η συμπίεση από μόνη της δεν ισοδυναμεί με σωστό state

Θα μπορούσε κανείς να υποθέσει ότι το πλεονέκτημα προκύπτει απλώς επειδή το prompt είναι μικρότερο. Για να το ελέγξουν, οι ερευνητές σύγκριναν το SKILL.state με sliding window, περιορισμένη περίληψη και LLMLingua, όλα περίπου στο ίδιο budget των 1.800 χαρακτήρων για 100 βήματα warehouse.

Τα αποτελέσματα ήταν έντονα διαφορετικά. Το sliding window είχε score 0,18, η capped summary 0,52 και το LLMLingua 0,22. Το SKILL.state έφτασε 0,94 με μέσο prompt 1.905 χαρακτήρων. Η εξήγηση της εργασίας είναι ότι μια γενική μέθοδος περικοπής μπορεί να αφαιρέσει ένα παλιό identifier που φαίνεται ασήμαντο αλλά παραμένει απαραίτητο για μια μελλοντική ενέργεια.

Για μια ομάδα προϊόντος, το συμπέρασμα δεν είναι «μη χρησιμοποιείτε summaries». Είναι ότι η επιχειρησιακή κατάσταση πρέπει να σχεδιάζεται με σημασιολογικούς κανόνες. Ένα order ID, μια συγκατάθεση πελάτη, μια εγκεκριμένη τιμή ή το τελευταίο επιτυχές checkpoint δεν είναι απλώς tokens. Είναι πεδία με διαφορετική διάρκεια ζωής, εγκυρότητα και συνέπειες.

Τα μικρότερα μοντέλα αποκαλύπτουν το κόστος του structured output

Η αρχιτεκτονική απαιτεί από το μοντέλο να παράγει έγκυρα state patches. Στην ανάλυση αποτυχιών του Gemma-4-31B στα 100 βήματα, όπου το score ήταν 0,42, το 68% των σφαλμάτων αποδόθηκε σε πρόωρη αντικατάσταση ή διαγραφή κατάστασης. Το 20% αφορούσε κατανόηση schema ή μετατροπή τύπων και το 12% συντακτικά προβλήματα JSON.

Οι συγγραφείς ερμηνεύουν αυτή την κατανομή ως πρόβλημα τήρησης structured output και όχι κατ’ ανάγκη ως έλλειψη reasoning. Προτείνουν grammar-constrained decoding για μικρότερα μοντέλα. Παράλληλα, το deterministic runtime απορρίπτει ένα malformed patch και ενεργοποιεί rollback-retry, ώστε το λάθος format να μην καταστρέφει τη μόνιμη κατάσταση.

Στην παραγωγή αυτό σημαίνει ότι το schema δεν είναι απλώς documentation. Χρειάζεται validation, versioning, κανόνες merge και ασφαλής αποτυχία. Ένα μοντέλο που ξεχνά ένα παλιό κλειδί επειδή έστειλε ολόκληρο object αντί για patch μπορεί να προκαλέσει απώλεια λειτουργικής πληροφορίας, ακόμη κι αν η λεκτική του εξήγηση φαίνεται σωστή.

Πού η προσέγγιση συναντά τα όριά της

Το SKILL.state βασίζεται στην υπόθεση ότι η τρέχουσα κατάσταση μπορεί να λειτουργήσει ως επαρκής στατιστική για το μέλλον: κάθε πληροφορία που θα χρειαστεί αργότερα πρέπει να αναγνωριστεί και να αποθηκευτεί όταν εμφανίζεται. Η ίδια η εργασία περιγράφει τρεις περιπτώσεις όπου αυτή η υπόθεση αποτυγχάνει.

Πρώτον, μπορεί να μην υπάρχει γνωστό schema και η σωστή δομή να πρέπει να ανακαλυφθεί κατά την εκτέλεση. Δεύτερον, μια παλιά παρατήρηση μπορεί να γίνει σημαντική μόνο αργότερα, αφού προηγουμένως κρίθηκε άσχετη και δεν καταγράφηκε. Τρίτον, υπάρχουν εργασίες όπου η ιστορική διαδρομή είναι το ζητούμενο: audit, debugging προέλευσης ή εξήγηση προηγούμενων ενεργειών.

Η τρέχουσα υλοποίηση εξετάζει επίσης single-agent execution. Σε multi-agent περιβάλλον, μια κοινή κατάσταση θα μπορούσε να μειώσει τις συνομιλίες μεταξύ agents, αλλά δημιουργεί ταυτόχρονες εγγραφές και συγκρούσεις. Χρειάζονται ντετερμινιστικοί κανόνες επίλυσης που δεν δοκιμάζονται στην παρούσα εργασία.

Άρα, η σωστή επιχειρησιακή αρχιτεκτονική πιθανότατα δεν είναι «κρατάμε μόνο state και διαγράφουμε τα πάντα». Είναι ο διαχωρισμός μεταξύ operational state, immutable audit log και προσβάσιμων evidence stores. Το state καθοδηγεί την επόμενη ενέργεια, ενώ το ιστορικό παραμένει διαθέσιμο για συμμόρφωση, διερεύνηση και εξηγήσεις χωρίς να φορτώνεται αυτόματα σε κάθε prompt.

Πώς μεταφράζεται σε ένα production workflow

Η πρακτική εφαρμογή ξεκινά με ένα schema που περιγράφει τι πρέπει να επιβιώνει από βήμα σε βήμα. Σε ένα content pipeline μπορεί να περιλαμβάνει source GUID, canonical link, queue position, verification status, generated title, CMS draft ID, Drive file IDs, email status και unresolved warnings. Σε ένα e-commerce flow μπορεί να κρατά order ID, current fulfillment state, πληρωμή, επιστροφή, policy constraints και pending approval.

Κάθε tool result δεν πρέπει να μπαίνει αυτούσιο στη μνήμη. Το runtime μπορεί να εξάγει ένα μικρό patch, να ελέγχει τύπους και επιτρεπόμενες μεταβάσεις και να αποθηκεύει χωριστά το raw evidence. Έτσι, το operational prompt παραμένει μικρό, αλλά μια ομάδα μπορεί ακόμη να ανατρέξει στο αρχικό API response όταν χρειάζεται έλεγχο.

Ιδιαίτερη σημασία έχει η ιδιοκτησία του schema. Η έρευνα το ορίζει ανά domain, όχι ανά task. Στην πράξη αυτό απαιτεί συνεργασία μεταξύ product, engineering και operations: ποιο πεδίο είναι authoritative, πότε λήγει, ποια αλλαγή επιτρέπεται, ποια χρειάζεται επιβεβαίωση και τι συμβαίνει όταν δύο πηγές διαφωνούν.

Η αξιολόγηση πρέπει επίσης να μετρά το συνολικό workflow. Εκτός από task success, η εργασία καταγράφει μέσο prompt size και συνολικό token cost. Μια επιχείρηση μπορεί να προσθέσει latency, retries, manual interventions, invalid state patches και ποσοστό εργασιών που ολοκληρώνονται χωρίς επανεκκίνηση.

Η ουσία: ο agent χρειάζεται καθαρή αλήθεια για το παρόν

Το SKILL.state δεν αποδεικνύει ότι η συνομιλιακή μνήμη είναι άχρηστη. Δείχνει ότι δεν πρέπει να αποτελεί από μόνη της το λειτουργικό σύστημα μιας μακράς διαδικασίας. Όταν παλιά γεγονότα, προσωρινά logs και reasoning traces παραμένουν μόνιμα στο prompt, ο agent πληρώνει ξανά το κόστος τους και κινδυνεύει να τα μπερδέψει με την τρέχουσα πραγματικότητα.

Η πιο ισχυρή συνεισφορά της εργασίας είναι ο διαχωρισμός ρόλων. Η προδιαγραφή λέει τι πρέπει να γίνει. Η δομημένη κατάσταση λέει τι ισχύει τώρα. Η τελευταία παρατήρηση λέει τι μόλις άλλαξε. Ο reasoning μηχανισμός αποφασίζει την επόμενη μετάβαση, αλλά δεν γίνεται αυτόματα μέρος της μόνιμης αλήθειας.

Για ομάδες που επενδύουν σε agentic AI, αυτό μετακινεί τη συζήτηση από το «ποιο μοντέλο έχει μεγαλύτερο context window;» στο «ποια πληροφορία αξίζει να επιβιώνει και με ποιον έλεγχο;». Η απάντηση σε αυτό το ερώτημα μπορεί να καθορίσει τόσο το κόστος όσο και την αξιοπιστία του αυτοματισμού.