Η πρακτορική υποδομή και το νέο backend
· 10 min read · Filippo Spinella · AI, Agents, Infrastructure, Developer Tools
Συχνά έχουμε μιλήσει για πρακτορεία. LangGraph, CrewAI, AutoGen, διάφορα SDK, βρόχος, κλήση εργαλείων, μνήμη, προγραμματιστής, κριτικός, επόπτης. Όλες οι χρήσιμες λέξεις, για το καλό. Αλλά όσο περισσότερο κοιτάζω τους πράκτορες που χρησιμοποιούνται στην πραγματικότητα, τόσο περισσότερο μου φαίνεται ότι το ενδιαφέρον μέρος έχει μετακινηθεί κάτω από το επίπεδο πλαισίου.
Το ερώτημα δεν είναι πλέον μόνο: ποια βιβλιοθήκη θα χρησιμοποιήσω για να σκεφτώ ένα βηματικό μοντέλο;
Το πραγματικό ερώτημα είναι: πού μένει αυτός ο πράκτορας όταν σταματήσει να είναι demo;
Επειδή ένας σοβαρός πράκτορας δεν είναι μια συνάρτηση που καλεί ένα μοντέλο και επιστρέφει κείμενο. Είναι ένα μικρό κατανεμημένο σύστημα. Πρέπει να διαβάζει το πλαίσιο, να χρησιμοποιεί εργαλεία, να εκτελεί κώδικα, να αγγίζει αρχεία, να θυμάται αποφάσεις, να ζητά άδεια, να αποτυγχάνει καλά, να επανεκκινεί, να αφήνει αρχεία καταγραφής, να μην καίει τον προϋπολογισμό και να μην μετατρέπεται σε μπουλντόζα μέσα στο αποθετήριο παραγωγής.
Το πλαίσιο είναι το τιμόνι. Η υποδομή είναι ο δρόμος, τα φρένα, το γκαράζ, η ασφάλεια και ο άνθρωπος που ξέρει πού είναι τα κλειδιά.
Γιατί γίνεται πολύς λόγος για αυτό τώρα
Το 2023 και το 2024 η συζήτηση ήταν πολύ μοντελοκεντρική. Ποιο LLM; Πόσο πλαίσιο; Πόσο κοστίζει; Πόσο καλός είναι στον προγραμματισμό;
Το 2025 και το 2026 η συζήτηση έχει αλλάξει. Τα μοντέλα είναι αρκετά καλά για να κάνουν πραγματική δουλειά, αλλά γι' αυτό τα βαρετά κομμάτια γίνονται ορατά: χρόνος εκτέλεσης, ασφάλεια, σύνδεσμοι, ταυτότητα, παρατηρησιμότητα, εκτέλεση κώδικα, ανάπτυξη, επαναφορά.
Είναι η φυσική μετάβαση από τη μαγεία στη μηχανική.
Όταν ένας πράκτορας χρειάζεται απλώς να δημιουργήσει μια απάντηση, μια συνομιλία αρκεί. Όταν χρειάζεται να ανοίξετε ένα αίτημα έλξης, να υποβάλετε ερώτημα σε μια βάση δεδομένων, να καλέσετε ένα CRM, να ξεκινήσετε μια εργασία, να πλοηγηθείτε σε έναν ιστότοπο, να διαβάσετε το Slack, να μεταγλωττίσετε κώδικα και να ενημερώσετε ένα έγγραφο, χρειάζεστε ένα λειτουργικό σύστημα γύρω από αυτό.
Όχι με κυριολεκτική έννοια. Με οργανωτική έννοια.
Το πρώτο κομμάτι: ένας χρόνος εκτέλεσης όπου ο πράκτορας μπορεί να διαρκέσει
Ένας πράκτορας συχνά εργάζεται σε βήματα. Look at the state, choose an action, use a tool, observe the result, update the plan, repeat.
If this loop lives inside a single HTTP request, you immediately have a problem. Ορισμένες ενέργειες είναι αργές. Μερικοί περιμένουν την ανθρώπινη συμβολή. Μερικοί αποτυγχάνουν και πρέπει να δοκιμαστούν ξανά. Κάποιοι πρέπει να επιβιώσουν από την ανάπτυξη ή το timeout.
This is where durable workflows, queues, job backgrounds and state machines come into play. Δεν είναι λαμπεροί, αλλά είναι η διαφορά ανάμεσα σε έναν πράκτορα που φαίνεται έξυπνος στο demo και σε έναν που μπορείς να αφήσεις να εργάζεται ενώ πας να πάρεις καφέ.
For me the agentic runtime must answer very concrete questions:
- πού μπορώ να σώσω το κράτος ανάμεσα στο ένα βήμα και το άλλο;
- what happens if the process dies halfway through?
- Μπορώ να σταματήσω και να ζητήσω έγκριση;
- Μπορώ να επαναλάβω ένα τρέξιμο για να καταλάβω γιατί έκανε αυτή την επιλογή;
- Μπορώ να περιορίσω τη διάρκεια, τη μνήμη, τα εργαλεία και το κόστος;
Η Vercel πιέζει σκληρά σε αυτό το μέτωπο με AI SDK, λειτουργίες, ροές εργασίας και εργαλεία για τη δημιουργία πρακτόρων σε εφαρμογές web. Αλλά το θέμα δεν είναι μόνο ο Vercel. The point is that the agent needs an operational home, not a single endpoint.
Το δεύτερο κομμάτι: sandbox, γιατί ο πράκτορας πρέπει να μπορεί να λερωθεί χωρίς να σπάσει
As soon as an agent writes code or executes commands, a sandbox is needed.
Μοιάζει με τεχνική λέξη, αλλά η ιδέα είναι εγχώρια: του δίνεις έναν πάγκο εργασίας. Μπορεί να ανοίξει αρχεία, να εγκαταστήσει εξαρτήσεις, να εκτελέσει δοκιμές, να κάνει πειράματα, να δημιουργήσει έξοδο. Αν το κάνει λάθος, έχετε περιορίσει τη ζημιά. Εάν λειτουργεί, προωθήστε το αποτέλεσμα.
Ένα πρακτορείο sandbox πρέπει να έχει ορισμένες ιδιότητες:
- απομονωμένο σύστημα αρχείων.
- CPU, μνήμη και χρονικά όρια.
- ελεγχόμενο δίκτυο.
- τα μυστικά τοποθετούνται μόνο όταν χρειάζεται.
- πλήρη αρχεία καταγραφής
- δυνατότητα εξαγωγής αντικειμένων·
- καθαρή επαναφορά μεταξύ των δρομολογίων, όταν είναι απαραίτητο.
Το Vercel Sandbox πηγαίνει ακριβώς προς αυτήν την κατεύθυνση: απομονωμένα περιβάλλοντα για εκτέλεση κώδικα, εγκατάσταση εξαρτήσεων, εργασία με αρχεία και παραγωγή τεχνουργημάτων χωρίς να εκτελούνται τα πάντα στον χρόνο εκτέλεσης της κύριας εφαρμογής.
Αυτό το πράγμα είναι πιο σημαντικό από όσο φαίνεται. Πολλά πρωτότυπα πράκτορα μεταπηδούν απευθείας από το μοντέλο στο πραγματικό σύστημα. Το μοντέλο μπορεί να καλέσει το εργαλείο. Τα εργαλεία μπορούν να κάνουν πράγματα. Όλα φαίνονται κομψά μέχρι την πρώτη λάθος εντολή, την πρώτη εξάρτηση που εγκαταστάθηκε σε λάθος μέρος, το πρώτο διακριτικό που καταλήγει σε ένα αρχείο καταγραφής.
Το sandbox είναι ο τρόπος για να πούμε για ενήλικες: προχωρήστε, αλλά εδώ.
Το τρίτο κομμάτι: MCP και πρόβλημα σύνδεσης
Το Πρωτόκολλο Περιεχομένου Μοντέλου έχει γίνει ένα από τα πιο ενδιαφέροντα μέρη του οικοσυστήματος, επειδή προσπαθεί να τυποποιήσει κάτι που διαφορετικά γρήγορα γίνεται μη διαχειρίσιμο: πώς ένα μοντέλο ανακαλύπτει και χρησιμοποιεί εξωτερικά εργαλεία.
Χωρίς πρότυπο, κάθε ένταξη είναι ένα μικρό νησί. Μια σύνδεση για το GitHub με έναν τρόπο, μια για το Slack με άλλη, μια για βάσεις δεδομένων με διαφορετική σημασιολογία, μια για αυτοματοποίηση προγράμματος περιήγησης που δεν μοιάζει με τίποτα.
Το MCP προτείνει μια κοινή γλώσσα μεταξύ πελάτη και διακομιστή: εργαλεία, πόροι, προτροπές, εξουσιοδοτήσεις, μεταφορά, ανακάλυψη. Δεν λύνει μαγικά τη διακυβέρνηση και την ασφάλεια, αλλά δίνει μια γραμματική.
Και η γραμματική έχει σημασία. Όταν ένας πράκτορας μπορεί να συνδεθεί με πολλά εργαλεία, το ερώτημα δεν είναι απλώς «μπορεί να το κάνει;». Το πρόβλημα είναι «καταλαβαίνει τι μπορεί να κάνει, με ποια όρια, για λογαριασμό ποιου και τι ίχνος αφήνει;».
Για μένα το MCP δεν είναι διαφημιστική εκστρατεία επειδή "κάνει κλήση εργαλείων". Το κάναμε ήδη. Είναι διαφημιστική εκστρατεία επειδή μετατοπίζει το κέντρο βάρους από την ενιαία ενσωμάτωση στον λειτουργικό κατάλογο εργαλείων.
Σε μια καλή αρχιτεκτονική πράκτορα, το MCP γίνεται ένα είδος πίνακα ενημέρωσης κώδικα:
- GitHub for code and issues;
- Slack for conversational context;
- Linear or Jira for planned work;
- read-only database for analytics;
- πρόγραμμα περιήγησης ή ξύστρα ελεγχόμενο για εξωτερικούς ιστότοπους.
- αποθήκευση εγγράφων
- isolated execution environments;
- εσωτερικά συστήματα εκτεθειμένα με αυστηρές άδειες.
Το δύσκολο μέρος είναι ότι ένας κατάλογος εργαλείων χωρίς πολιτική είναι απλώς ένας πιο κομψός τρόπος για να δημιουργήσετε χάος.
The fourth piece: identity and permissions
Αυτή είναι η περιοχή όπου πολλά demos κάνουν τα στραβά μάτια.
An agent acts on someone's behalf. Πρέπει λοιπόν να είναι ξεκάθαρο ποιο είναι το αντικείμενο της δράσης.
Is it using user permissions? Λογαριασμού υπηρεσίας; Χώρου εργασίας; Do you have temporary or permanent access? Can you read everything or just some resources? Μπορείτε να γράψετε; Μπορείτε να ακυρώσετε; Μπορεί να στείλει μήνυμα σε αληθινούς ανθρώπους;
Εάν δεν απαντήσετε καλά σε αυτές τις ερωτήσεις, αργά ή γρήγορα θα φτιάξετε έναν βοηθό με κλειδιά σπιτιού και χωρίς να θυμάται ποιος του τα έδωσε.
Ο εμπειρικός κανόνας που μου αρέσει είναι ο εξής: ο πράκτορας πρέπει να μπορεί να κάνει λιγότερα από τον άνθρωπο, όχι περισσότερα από τον άνθρωπο. Και όταν πρέπει να κάνει κάτι πιο ριψοκίνδυνο, πρέπει να σταματήσει και να ρωτήσει.
Αυτό σημαίνει OAuth, εύρος διακριτικού, μυστική διαχείριση, αρχείο καταγραφής ελέγχου, πολιτική εργαλείου, λίστα επιτρεπόμενων, βήμα έγκρισης. Όχι πολύ ρομαντικά πράγματα. Απαραίτητα πράγματα.
Το πέμπτο κομμάτι: μνήμη και πλαίσιο, αλλά χωρίς να συσσωρεύονται σκουπίδια
Οι πράκτορες χρειάζονται μνήμη, αλλά η μνήμη είναι επικίνδυνη όταν γίνεται σοφίτα.
There are at least three types of memory:
- μνήμη εκτέλεσης: τι συνέβη σε αυτήν την εκτέλεση.
- μνήμη έργου: συμβάσεις, αποφάσεις, περιορισμοί.
- προσωπική ή ομαδική μνήμη: προτιμήσεις, τόνος, τελετουργίες, διαδικασίες.
Η συντόμευση είναι η τοποθέτηση των πάντων στην προτροπή. Λειτουργεί μέχρι να μην λειτουργεί πια. Πρέπει να λαμβάνεται μέριμνα για τη χρήσιμη μνήμη: ευρετηριασμένη, ενημερωμένη, ληγμένη, επαληθευμένη, δυνατότητα αναφοράς.
Ένας πράκτορας που θυμάται άσχημα είναι χειρότερος από έναν πράκτορα που δεν θυμάται. Γιατί μιλάει με σιγουριά.
Επομένως η υποδομή πρέπει να περιλαμβάνει ανάκτηση, αρχεία οδηγιών, βάση γνώσεων, ενσωμάτωση όταν χρειάζεται, αλλά και καθαρισμό. Χρειαζόμαστε μια κουλτούρα μνήμης: τι μπαίνει, ποιος το εγκρίνει, πότε φθείρεται, πώς το διορθώνω.
Το έκτο κομμάτι: παρατηρησιμότητα, αξιολόγηση και επανάληψη
Εάν ένας πράκτορας κάνει λάθος, το αρχείο καταγραφής "που ονομάζεται μοντέλο" δεν είναι αρκετό.
Θέλετε να δείτε τη διαδρομή. Τι πλαίσιο έλαβε; Ποια εργαλεία ήταν διαθέσιμα; Ποιο εργαλείο επιλέξατε; Με ποια επιχειρήματα; Τι απάντηση λάβατε; Πόσο κόστισε; Που κόλλησε; Ο άνθρωπος ενέκρινε κάτι; Είναι το μοντέλο σφάλματος, το εργαλείο, η προτροπή, τα δεδομένα ή το σφάλμα άδειας;
Εδώ οι πράκτορες μοιάζουν περισσότερο με κατανεμημένα συστήματα παρά με chatbot.
Χρειάζεστε ευανάγνωστα ίχνη, όχι μόνο αρχεία καταγραφής κειμένου. Πρέπει να είστε σε θέση να επαναλάβετε ένα τρέξιμο. Είναι απαραίτητο να συγκρίνουμε δύο εκδόσεις του ίδιου πράκτορα σε γνωστές εργασίες. Πρέπει να μετρήσουμε τις παλινδρομήσεις: όχι μόνο «απαντάει καλύτερα», αλλά «κλείνει το σωστό δελτίο χωρίς να αγγίζει αυτόκλητα αρχεία».
Οι πρακτικές αξιολογήσεις είναι πιο δύσκολες από τις αξιολογήσεις κειμένου επειδή περιλαμβάνουν ενέργειες. Δεν αρκεί η σύγκριση μιας αναμενόμενης συμβολοσειράς. Πρέπει να εξετάσετε τις αλληλουχίες, τις παρενέργειες, την ποιότητα του αντικειμένου, τον χρόνο, το κόστος, τον αριθμό των ανθρώπινων παρεμβάσεων.
Το αστείο είναι ότι πάντα επιστρέφουμε εκεί: μηχανική λογισμικού. Δοκιμές, περιβάλλοντα, ίχνη, ανατροπές. Μόνο που ο κωδικός τώρα αποφασίζει επίσης τι θα κάνουμε στη συνέχεια.
Το έβδομο κομμάτι: ανθρώπινες διεπαφές
Ο πράκτορας δεν χρειάζεται να ζει απλώς σε μια συνομιλία.
Μερικοί πράκτορες χρειάζονται συμβούλιο. Άλλοι μια σελίδα με κατάσταση και αρχείο καταγραφής. Άλλα ενός κουμπιού "έγκριση". Περισσότερα ενσωματωμένα σχόλια. Άλλοι πάλι ενός CLI.
Το UI αλλάζει συμπεριφορά. Εάν ο μόνος τρόπος για να ελέγξετε έναν πράκτορα είναι να γράψετε ένα μεγάλο μήνυμα, ο χρήστης θα δώσει στον πράκτορα αόριστες οδηγίες. Αν, ωστόσο, δει το σχέδιο, τη διαφορά, τις πηγές, τους κινδύνους και την επόμενη δράση, μπορεί να επέμβει με ακρίβεια.
Μια αξιοπρεπής υποδομή πρακτόρων περιλαμβάνει επιφάνειες ελέγχου:
- τρέχουσα κατάσταση.
- επεξεργάσιμο σχέδιο.
- παραγόμενα τεχνουργήματα.
- Διαφ.
- αιτήματα έγκρισης·
- χρονολογία
- κουμπί διακοπής
- κουμπί επανάληψης
- ορατά δικαιώματα.
Φαίνεται ασήμαντο, αλλά δεν είναι. Η διαφορά μεταξύ του "ανατριχιαστικού AI" και του "αξιόπιστου βοηθού" είναι συχνά απλώς ότι ο δεύτερος σας δείχνει πού έχει τα χέρια του.
Η ψυχική στοίβα
Αν το σχεδιάζα σήμερα, η ελάχιστη στοίβα πρακτόρων θα ήταν αυτή:
- Μοντέλο: συλλογισμός, παραγωγή, κλήση εργαλείου, πολυτροπικό εάν είναι απαραίτητο.
- Ενορχήστρωση: loop, step, planner, policy, human-in-the-loop.
- Ανθεκτικός χρόνος εκτέλεσης: ροή εργασίας, ουρά, επανάληψη, παύση, συνέχιση.
- Sandbox: εκτέλεση κώδικα, απομονωμένο σύστημα αρχείων, περιορισμοί, τεχνουργήματα.
- Επίπεδο εργαλείου: MCP, εσωτερικό API, πρόγραμμα περιήγησης, βάση δεδομένων, αποθετήριο.
- Επίπεδο ταυτότητας: OAuth, πεδίο εφαρμογής, μυστικό, έλεγχος, πολιτική.
- Επίπεδο μνήμης: πλαίσιο έργου, ανάκτηση, οδηγίες, λήξη.
- Παρατηρησιμότητα: μετρήσεις ίχνους, επανάληψης, αξιολόγησης, κόστους και ποιότητας.
- Επιφάνεια προϊόντος: συνομιλία όταν είναι αρκετό, πίνακας ελέγχου όταν χρειάζεται, αναθεώρηση όταν έχει σημασία.
Το πρακτορείο καλύπτει κυρίως τα σημεία 2 και ένα κομμάτι του σημείου 1. Το υπόλοιπο είναι η πραγματική δουλειά.
Τι θα έκανα στην πράξη
Αν μια ομάδα μου έλεγε «θέλουμε πράκτορες στην παραγωγή», δεν θα ξεκινούσα με δέκα πράκτορες.
Θα ξεκινούσα με μια μικρή, επαναλαμβανόμενη και παρατηρήσιμη ροή εργασίας. Για παράδειγμα: άνοιγμα PR συντήρησης, ενημέρωση τεκμηρίωσης από κλειστά θέματα, προετοιμασία εβδομαδιαίας αναθεώρησης, διαλογή διπλών σφαλμάτων, δημιουργία δοκιμών για επηρεαζόμενα αρχεία.
Τότε θα έβαζα πολύ ξεκάθαρα όρια:
- Δεν υπάρχει γραφή χωρίς κλαδιά ή sandbox.
- δεν υπάρχουν μυστικά στην προτροπή
- εργαλεία στη λίστα επιτρεπόμενων
- ανθρώπινη έγκριση για εξωτερικές δράσεις.
- υποχρεωτικό ημερολόγιο και ίχνος.
- προϋπολογισμός ανά διαδρομή
- Η έξοδος είναι πάντα επιθεωρήσιμη.
Μόνο τότε θα επεκτανόμουν.
Οι πράκτορες δεν αποτυγχάνουν μόνο και μόνο επειδή τα μοντέλα το κάνουν λάθος. Αποτυγχάνουν γιατί τους βάζουμε σε ασαφή περιβάλλοντα, με μπερδεμένες άδειες και θεατρικές προσδοκίες.
Η ανάγνωση μου
Η πρακτορική υποδομή είναι βαρετή με τον καλύτερο τρόπο.
Δεν είναι το κομμάτι που σε κάνει να χειροκροτήσεις στο demo. Είναι το μέρος που σας επιτρέπει να χρησιμοποιήσετε πραγματικά την επίδειξη το πρωί της Δευτέρας, με πραγματικούς ανθρώπους, πραγματικά δεδομένα και πραγματικές συνέπειες.
Το μέλλον των πρακτόρων δεν θα κριθεί μόνο από το ποιος έχει το καλύτερο πρότυπο. Θα το αποφασίσει όποιος κατασκευάσει το καλύτερο μέρος για να τον κάνει να δουλέψει: απομονωμένος όταν πειραματίζεται, συνδεδεμένος όταν χρειάζεται, πάντα παρατηρήσιμος, εξουσιοδοτημένος με κριτήρια και αρκετά ταπεινός για να σταματήσει όταν δεν ξέρει.
Εκεί οι πράκτορες παύουν να είναι παιχνιδάκι και γίνονται υποδομές.