Ένας AI agent που απαντά σε μία ερώτηση μπορεί να ολοκληρώσει σε λίγα δευτερόλεπτα. Ένας agent που συλλέγει δεδομένα, δημιουργεί report, περιμένει έγκριση και ενημερώνει CRM μπορεί να χρειαστεί λεπτά, ώρες ή ημέρες. Αν όλη η εργασία εκτελείται μέσα σε ένα HTTP request ή μόνο στη μνήμη ενός process, μια επανεκκίνηση αρκεί για να χαθεί η πρόοδος.
Οι long-running agents χρειάζονται workflow architecture. Το model παίρνει αποφάσεις, αλλά η εφαρμογή διατηρεί state, προγραμματίζει βήματα και εγγυάται ότι μια επανάληψη δεν θα διπλασιάσει εξωτερικές ενέργειες.
Χωρίστε την εργασία σε ανθεκτικά βήματα
Αντί για μία αδιαφανή λειτουργία «κάνε τα πάντα», η ροή χωρίζεται σε nodes ή tasks με σαφή input και output:
- φόρτωση αιτήματος
- συλλογή πηγών
- αξιολόγηση επάρκειας
- δημιουργία draft
- ανθρώπινη έγκριση
- αποστολή ή ενημέρωση συστήματος
Κάθε βήμα πρέπει να κάνει μία συγκεκριμένη δουλειά. Αυτό επιτρέπει checkpoint ανάμεσα στα βήματα, ξεχωριστό retry policy και καθαρό trace. Η τεκμηρίωση του LangGraph περιγράφει durable execution με checkpoints στα όρια των nodes, ώστε μια ροή να συνεχίζει από αποθηκευμένο state αντί να επαναλαμβάνει όλη την εργασία.
Τι αποθηκεύει ένα checkpoint
Το checkpoint δεν είναι μόνο το τελευταίο μήνυμα του model. Χρειάζεται το ελάχιστο state που επιτρέπει ασφαλή συνέχεια:
- run και thread ID
- τρέχον βήμα και προηγούμενες ολοκληρώσεις
- δομημένα inputs και outputs
- references σε αρχεία ή μεγάλα artifacts
- model, prompt και tool versions
- pending approval ή αναμενόμενο external event
- retry count και τελευταίο σφάλμα
- timestamps και ownership
Δεν είναι καλό να αποθηκεύεται άκριτα όλο το context για πάντα. Το state σχεδιάζεται με data minimization, retention και permissions. Μεγάλα documents μπορούν να βρίσκονται σε object storage και το checkpoint να κρατά ασφαλές reference αντί για πλήρες αντίγραφο.
Queues αντί για ανοιχτά requests
Το API που ξεκινά την εργασία μπορεί να επιστρέφει γρήγορα ένα run_id. Η εκτέλεση περνά σε queue και workers αναλαμβάνουν τα βήματα. Ο χρήστης βλέπει status page, λαμβάνει notification ή κάνει polling σε endpoint που δεν επανεκκινεί την εργασία.
Ενδεικτικές καταστάσεις run είναι:
queued -> running -> waiting_for_approval -> running -> completed
| |
-> canceled -> failed
Η queue επιτρέπει concurrency limits, priorities και backpressure. Αν ο provider έχει προσωρινό πρόβλημα, οι εργασίες δεν χρειάζεται να χαθούν ούτε να επιτεθούν όλες ταυτόχρονα στο API όταν επανέλθει.
Retries μόνο για το σωστό είδος σφάλματος
Δεν λύνονται όλα με retry. Timeout, προσωρινό network error ή rate limit μπορεί να αντιμετωπιστεί με exponential backoff και jitter. Validation failure, έλλειψη permission ή επιχειρηματική απόρριψη χρειάζονται διαφορετική διαδρομή.
Κάθε error ταξινομείται ως transient, user-fixable, approval-required ή terminal. Ένα ασαφές «κάτι πήγε στραβά» οδηγεί είτε σε ατελείωτες επαναλήψεις είτε σε άσκοπη αποτυχία. Υπάρχει μέγιστος αριθμός προσπαθειών και dead-letter ή manual review queue για runs που δεν μπορούν να προχωρήσουν.
Idempotency στις εξωτερικές ενέργειες
Το δυσκολότερο σημείο είναι το resume μετά από αβεβαιότητα. Ο worker μπορεί να έστειλε email ή να δημιούργησε εγγραφή CRM και να έκλεισε πριν αποθηκεύσει ότι το βήμα ολοκληρώθηκε. Αν επαναληφθεί, μπορεί να δημιουργήσει διπλή ενέργεια.
Κάθε side effect χρειάζεται idempotency key, όπως run_id + step_id, και αποθήκευση του external reference. Όπου ο τρίτος provider υποστηρίζει idempotency, χρησιμοποιείται. Διαφορετικά η εφαρμογή κρατά δικό της execution record και κάνει reconciliation.
Τα read-only βήματα μπορούν συχνά να επαναληφθούν. Τα write steps χρειάζονται πολύ αυστηρότερη σχεδίαση. Η υπόθεση «το model θα θυμηθεί ότι το έκανε» δεν αποτελεί μηχανισμό αξιοπιστίας.
Pause για ανθρώπινη έγκριση
Ένα workflow μπορεί να σταματήσει για ημέρες περιμένοντας άνθρωπο. Το run μεταβαίνει σε waiting_for_approval, αποθηκεύει τι προτείνει ο agent και ποια ακριβώς ενέργεια θα ακολουθήσει. Ο reviewer βλέπει context, μπορεί να εγκρίνει, να απορρίψει ή να τροποποιήσει το payload.
Η συνέχεια πρέπει να δεσμεύεται στην ίδια έκδοση state. Αν τα δεδομένα άλλαξαν σημαντικά όσο περίμενε, η έγκριση μπορεί να θεωρηθεί παρωχημένη και να ζητηθεί νέα αξιολόγηση. Επίσης, μόνο εξουσιοδοτημένοι ρόλοι επιτρέπεται να κάνουν resume.
Η durable execution τεκμηρίωση δείχνει αυτό το μοτίβο: η ροή κάνει interrupt, αποθηκεύει state και συνεχίζει αργότερα με το ίδιο thread identifier. Η αρχή είναι framework-independent.
Versioning για workflows που περιμένουν
Αν γίνει deployment νέου κώδικα ενώ υπάρχουν paused runs, ποια έκδοση θα εκτελέσουν όταν συνεχίσουν; Το checkpoint πρέπει να καταγράφει workflow version. Η ομάδα μπορεί να υποστηρίζει την παλιά έκδοση μέχρι να ολοκληρωθούν τα runs ή να εφαρμόζει ρητή migration state.
Δεν είναι ασφαλές ένα παλιό checkpoint να φορτωθεί τυφλά σε νέο schema. Χρειάζονται backward-compatible state changes ή migration functions με tests. Prompt και tool changes μπορούν επίσης να αλλάξουν τη συμπεριφορά, γι' αυτό καταγράφονται ως versions.
Progress χωρίς παραπλανητικά ποσοστά
Ο χρήστης χρειάζεται εικόνα προόδου, αλλά ένα agentic workflow δεν γνωρίζει πάντα πόσα βήματα απομένουν. Ένα ψεύτικο progress bar 87% που μένει ακίνητο δεν βοηθά. Καλύτερα να εμφανίζονται πραγματικά milestones: «Συλλογή πηγών ολοκληρώθηκε», «Περιμένει έγκριση», «Αποστολή report».
Κάθε update προέρχεται από state transition. Αν το run αποτύχει, εμφανίζεται κατανοητό μήνυμα και ασφαλής δυνατότητα retry ή cancel. Τα τεχνικά traces παραμένουν για την ομάδα, όχι ως ωμό error στον τελικό χρήστη.
Παρακολούθηση και λειτουργία
Χρήσιμα metrics είναι queue latency, συνολικός χρόνος run, χρόνος ανά step, retry rate, failure reason, χρόνος αναμονής για approval και κόστος model ανά workflow. Alerts χρειάζονται για stuck runs, αυξανόμενη dead-letter queue και υψηλό ποσοστό tool failures.
Το cancel πρέπει να είναι πραγματική λειτουργία. Σταματά νέα βήματα, ακυρώνει εργασίες όπου γίνεται και καταγράφει ποιες εξωτερικές ενέργειες είχαν ήδη ολοκληρωθεί. Σε ορισμένες ροές χρειάζονται compensating actions, όχι απλή διαγραφή του state.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry μετατρέπουμε τις πολύωρες agentic εργασίες σε ρητά workflows με durable state, queues και checkpoints. Ορίζουμε retry policies ανά βήμα, idempotency για tool calls και ασφαλή pause/resume για approvals. Το model δεν είναι υπεύθυνο για την εγγύηση εκτέλεσης· αυτή ανήκει στο backend και στα δεδομένα της εφαρμογής.
Δημιουργούμε admin views για runs, βήματα, errors και manual recovery, καθώς και user-facing progress με πραγματικά milestones. Ελέγχουμε restart, duplicate delivery, stale approval και deployment με paused runs. Αυτή η προσέγγιση επιτρέπει στην Ai Foundry να υλοποιεί agents που δεν είναι απλώς εντυπωσιακά demos, αλλά λειτουργικές εφαρμογές που μπορούν να περιμένουν, να συνεχίσουν και να εξηγήσουν τι συνέβη.
Συμπέρασμα
Ο long-running agent είναι distributed workflow με model στο loop. Checkpoints, queues, idempotency, versioning και approvals είναι αυτά που τον κάνουν αξιόπιστο. Χωρίς αυτά, κάθε διακοπή μετατρέπεται σε επανεκκίνηση, διπλή ενέργεια ή χαμένη εργασία.