Η Στοίβα των Πράκτορων Έχει Τέσσερα Στρώματα. Οι Πλειονότητες των Υλοποιήσεων Λείπουν Τρία

Η ταυτότητα, η φήμη, η εντολή και η πληρωμή πρέπει να ζουν on-chain. Σε πολλές παραγωγικές υλοποιήσεις, δεν το κάνουν ακόμη, και αυτό είναι ένα αρχιτεκτονικό πρόβλημα, όχι μια μεταγενέστερη σκέψη συμμόρφωσης.

Περνώ πολύ χρόνο εξετάζοντας πώς οι παραγωγικές υλοποιήσεις πρακτόρων είναι πραγματικά συνδεδεμένες, και το μοτίβο είναι συχνά το ίδιο: το μοντέλο είναι ικανό, και το πλαίσιο ορχήστρωσης είναι λογικό, όμως το επίπεδο πιστοποίησης παραμένει ακόμη ένα κοινό API κλειδί που δεν έχει αλλάξει για μήνες.

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

Και αυτό είναι πιο σημαντικό στη ρυθμιζόμενη χρηματοδότηση από οπουδήποτε αλλού. Ένας πράκτορας που μπορεί να πραγματοποιεί συναλλαγές σε τοκενισμένα χρεόγραφα, να εγκρίνει ενέργειες ταμείου ή να κατανέμει θέσεις πρέπει να μπορεί να δείξει τι του επιτράπηκε να κάνει, ποιος το εξουσιοδότησε, εντός ποιων ορίων, και πού βρίσκεται το on-chain αρχείο αυτής της εξουσιοδότησης. Οι περισσότερες υλοποιήσεις δεν μπορούν να απαντήσουν καθαρά σήμερα. Χωρίς αυτό το αρχείο, ο ίδιος ο πράκτορας αποτελεί κίνδυνο ελέγχου και συμμόρφωσης.

Γιατί τα κοινά κλειδιά API είναι το λανθασμένο primitive

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

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

Το κενό ταυτότητας

ERC-8004 καθορίζει την on-chain ταυτότητα για πράκτορες χωρίς εμπιστοσύνη: ένα μητρώο όπου ένας πράκτορας καταχωρείται με ένα ελεγκτικό πορτοφόλι, ένα σημείο υπηρεσίας και μια αναφορά μοντέλου. Αυτή τη στιγμή, ο πράκτορας είναι απλώς μια αδιαφανής διαδικασία που τρέχει μέσα στην υποδομή ενός προμηθευτή. Η εγγραφή στο μητρώο τον κάνει έναν πρώτης τάξης on-chain ηθοποιό με επαληθεύσιμη προέλευση — που ένα έξυπνο συμβόλαιο ή πίνακας συμμόρφωσης μπορεί να ελέγξει άμεσα, χωρίς να εμπιστεύεται ενδιάμεσο.

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

Και τα δύο επίπεδα είναι υλοποιήσιμα σήμερα χωρίς εξωτική μηχανική. Οι περισσότερες υλοποιήσεις δεν τα έχουν επειδή η διαδρομή υλοποίησης με τη λιγότερη αντίσταση είναι ακόμη να θεωρούν τους πράκτορες ως λογαριασμούς υπηρεσίας αντί για ηθοποιούς πρώτης τάξης. Μια λογική συντόμευση σε ένα πρωτότυπο γίνεται αρχιτεκτονικό χρέος που συντίθεται στην παραγωγή.

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

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

ERC-8226, το Πρότυπο Ρυθμιζόμενης Εντολής Πρακτόρων (RAMS), έχει σχεδιαστεί για να κλείσει αυτό το κενό. Το RAMS ορίζει ένα επίπεδο ανάθεσης συμμόρφωσης που βρίσκεται μεταξύ της ταυτότητας του πράκτορα και των πλαισίων συμμόρφωσης σε επίπεδο token. Ένας κύριος επαληθευμένος μέσω KYC χορηγεί στον πράκτορα μια εντολή με καθορισμένο εύρος, δικαιοδοσία, όρια αξίας και ημερομηνία λήξης. Στην πράξη, λειτουργεί όπως μια on-chain πληρεξούσια που μπορεί να ελεγχθεί πριν από την εξόφληση. Το ρυθμιζόμενο συμβόλαιο token στη συνέχεια επαληθεύει την εντολή ατομικά μέσα στην προ‑μεταφορά hook συμμόρφωσης πριν συμβεί οποιαδήποτε εξόφληση.

Δύο διεπαφές μεταφέρουν το σχεδιασμό. Η `ComplianceProvider` υλοποιείται από οποιονδήποτε χειριστή KYC ή βεβαίωσης και εγγυάται την επιλεξιμότητα του κύριου για ένα δεδομένο εύρος. Η `IAgentMandate` είναι το μητρώο που καταγράφει χορηγήσεις, επεκτάσεις, ανακλήσεις, εκτελέσεις και παγώματα επιπέδου ρυθμιστή. Η επιβολή γίνεται μέσω της `recordExecution`, η οποία ελέγχει τα όρια της ενεργής εντολής κατά τη μεταφορά και ακυρώνει αν η συναλλαγή τα παραβιάσει.

Αυτή η αρχιτεκτονική βρίσκεται μεταξύ της ταυτότητας ERC-8004 και των πλαισίων συμμόρφωσης token όπως το ERC-7943, αντί να αντικαθιστά κανένα από τα δύο. Η ταυτότητα λέει ότι ο πράκτορας υπάρχει και είναι επαληθεύσιμος· η συμμόρφωση token, ότι ο κύριος είναι επιλέξιμος να κατέχει αυτό το συγκεκριμένο περιουσιακό στοιχείο. Το RAMS προσθέτει το μέρος που κανένα από τα δύο δεν καλύπτει: εξουσία από αυτόν τον κύριο, για αυτό το εύρος, εντός αυτών των ορίων, μέχρι αυτήν την ημερομηνία. Το νομικά εκτελέσιμο επίπεδο ανάθεσης που αυτή τη στιγμή υπάρχει μόνο σε PDF και σε λογιστικά φύλλα back‑office μετακινείται on-chain, όπου μπορεί πραγματικά να επιβληθεί κατά τη μεταφορά.

Ο διαχωρισμός προετοιμασίας‑εκτέλεσης δεν είναι τριβή

Μια απόφαση σχεδίασης αξίζει άμεση υπεράσπιση: ο διαχωρισμός της προετοιμασίας συναλλαγής από την υπογραφή και τη μετάδοση. Συχνά παραλείπεται σε πολλά συστήματα που προσπαθούν να κάνουν τους πράκτορες να φαίνονται πιο απρόσκοπτοι.

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

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

Πώς φαίνεται η στοίβα όταν είναι πλήρης

Όταν όλα τα τέσσερα στρώματα είναι στη θέση τους, συνθέτουν καθαρά. Το ERC-8004 αγκυροβολεί την ταυτότητα του πράκτορα και την on-chain φήμη, και το ERC-8226 προσθέτει το στρώμα εντολής που περιορίζει τι μπορεί να κάνει κάθε πράκτορας και για λογαριασμό ποιος. x402 διαχειρίζεται την εξόφληση, υπογράφοντας κάθε αίτηση ώστε κάθε ενέργεια να είναι αποδοτική και ελεγχόμενη. Κάτω από αυτό, τα πλαίσια ρυθμιζόμενων περιουσιακών στοιχείων όπως το ERC-7943 επιβάλλουν τη συμμόρφωση κατά τη μεταφορά έναντι τόσο της επιλεξιμότητας του κύριου όσο και της ενεργής εντολής του πράκτορα.

Αυτά τα στοιχεία βρίσκονται σε διαφορετικά επίπεδα ωριμότητας, αλλά κανένα δεν είναι καθαρά θεωρητικό. Το ERC-8004 είναι ένα Draft Standards Track ERC με υλοποιήσιμα primitives ταυτότητας και φήμης. Το ERC-7943 είναι ένα τελικό πρότυπο Ethereum. Το ERC-8226 βρίσκεται στο standards track, και οι βασικές διεπαφές είναι αρκετά σταθερές για πρώιμη υλοποίηση. Το x402 είναι ζωντανό και έχει ήδη σχεδιαστεί γύρω από προγραμματιστικές πληρωμές HTTP για ανθρώπους και πράκτορες.

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