Ό,τι οι περισσότεροι αποκαλούν agent είναι στην πραγματικότητα μια σταθερή ακολουθία βημάτων με μία ή δύο κλήσεις μοντέλου στη μέση. Η ροή ελέγχου είναι γνωστή εκ των προτέρων, αλλά οι ομάδες την παραδίδουν στο μοντέλο έτσι κι αλλιώς, και μετά ξοδεύουν εβδομάδες κάνοντας ένα μη ντετερμινιστικό loop να συμπεριφέρεται σωστά. Όταν το σχήμα της εργασίας είναι γνωστό, ο orchestrator πρέπει να είναι ντετερμινιστικός, και το AWS Step Functions ταιριάζει καλύτερα σε αυτή τη δουλειά από ένα χειροποίητο agent loop. Λύνει ήδη retries, timeouts, χειρισμό σφαλμάτων, παραλληλισμό και ανθρώπινη έγκριση, ακριβώς τα πράγματα που ένα agent framework σου ζητά να επανυλοποιήσεις.

Το reframing που αξίζει να εσωτερικεύσεις: άσε το μοντέλο να παίρνει αποφάσεις, όχι τη σωληνοποιία. Χρησιμοποίησε το μοντέλο για τα βήματα που πραγματικά χρειάζονται κρίση, εξαγωγή, ταξινόμηση, σύνταξη, και άσε μια state machine να αποφασίσει τι τρέχει, με ποια σειρά, και τι συμβαίνει όταν ένα βήμα αποτυγχάνει. Δεν χρειάζεσαι ένα LLM για να ξέρει ότι το βήμα τρία ακολουθεί το βήμα δύο.

Το ντετερμινιστικό orchestration είναι χαρακτηριστικό, όχι περιορισμός

Ένα χειροποίητο agent loop βάζει το μοντέλο επικεφαλής της ροής ελέγχου: αποφασίζει ποιο εργαλείο να καλέσει, διαβάζει το αποτέλεσμα, αποφασίζει το επόμενο εργαλείο, και ούτω καθεξής μέχρι να πιστεύει ότι τελείωσε. Αυτός είναι ο σωστός σχεδιασμός όταν το μονοπάτι είναι γνήσια άγνωστο τη στιγμή της συγγραφής. Είναι ο λάθος σχεδιασμός όταν το μονοπάτι είναι μια ροή εργασίας που θα μπορούσες να σχεδιάσεις σε έναν πίνακα, γιατί τώρα κάθε εκτέλεση μπορεί να ακολουθήσει διαφορετική διαδρομή, τα retries είναι αυτοσχέδια, και μια αποτυχία στη μέση αφήνει κατάσταση που πρέπει να ανασυνθέσεις.

Το Step Functions αναστρέφει αυτό. Δηλώνεις τις καταστάσεις και τις μεταβάσεις. Κάθε κατάσταση που χρειάζεται κρίση καλεί το Bedrock (άμεσα ή μέσω Lambda), κάθε κατάσταση που δεν χρειάζεται είναι απλή λογική. Η εκτέλεση είναι αναπαραγώγιμη, κάθε μετάβαση καταγράφεται, και το ιστορικό εκτέλεσης είναι ένα ενσωματωμένο audit trail. Για μια ροή εργασίας με γνωστό σχήμα, ο ντετερμινισμός είναι ακριβώς αυτό που θέλεις.

Retries και χειρισμός σφαλμάτων που δεν γράφεις

Η μη γοητευτική πλειοψηφία της δουλειάς αξιοπιστίας ενός agent είναι η πολιτική retry. Μια κλήση μοντέλου throttle-άρει, ένα εργαλείο κάνει timeout, ένα downstream API επιστρέφει ένα προσωρινό 500. Σε ένα χειροποίητο loop γράφεις backoff, jitter και χειρισμό ανά σφάλμα με το χέρι, και συνήθως το κάνεις λάθος με λεπτό τρόπο.

Το Step Functions το κάνει δηλωτικό. Κάθε κατάσταση κουβαλά τη δική της συμπεριφορά retry και catch:

"InvokeModel": {
  "Type": "Task",
  "Resource": "arn:aws:states:::bedrock:invokeModel",
  "Retry": [{
    "ErrorEquals": ["Bedrock.ThrottlingException"],
    "IntervalSeconds": 2,
    "BackoffRate": 2.0,
    "MaxAttempts": 5
  }],
  "Catch": [{
    "ErrorEquals": ["States.ALL"],
    "Next": "HandleFailure"
  }]
}

Το throttling παίρνει εκθετικό backoff, οτιδήποτε άλλο δρομολογείται σε μια κατάσταση αποτυχίας που ελέγχεις. Κανένας κώδικας retry, καμία χαμένη εξαίρεση, και η συμπεριφορά είναι ορατή στον ορισμό αντί να είναι θαμμένη σε ένα loop.

Το human-in-the-loop είναι κατάσταση πρώτης τάξης

Το σημείο όπου οι χειροποίητοι agents πονάνε περισσότερο είναι η παύση για έναν άνθρωπο. Ένας agent που μπορεί να ξοδέψει χρήματα, να στείλει email ή να αλλάξει παραγωγή πρέπει να σταματήσει και να περιμένει έγκριση, και το να το κάνεις αυτό σε μια διαδικασία μεγάλης διάρκειας σημαίνει να κρατάς κατάσταση κάπου ενώ ένα άτομο χρειάζεται ώρες ή μέρες για να απαντήσει.

Το Step Functions το έχει ενσωματωμένο μέσω του callback pattern. Ένα task που ξεκινά με .waitForTaskToken παύει την εκτέλεση, εκπέμπει ένα token, και δεν κάνει τίποτα μέχρι κάτι να καλέσει το SendTaskSuccess ή το SendTaskFailure με αυτό το token. Η ροή εργασίας μπορεί να μείνει σε παύση όσο χρειαστεί η έγκριση χωρίς να τρέχει διαδικασία, και μετά να συνεχίσει ακριβώς εκεί που σταμάτησε. Παίρνεις μια ανθεκτική, ελέγξιμη ανθρώπινη πύλη χωρίς να χτίσεις μια ουρά, ένα state store και έναν μηχανισμό resume μόνος σου.

Όταν θέλεις ακόμα ένα πραγματικό agent loop

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

Η παγίδα είναι να χρησιμοποιείς αυτό το πρότυπο για ένα pipeline πέντε βημάτων με έναν κλάδο. Αν μπορείς να σχεδιάσεις το διάγραμμα ροής, κωδικοποίησε το διάγραμμα ροής. Κράτα το μη ντετερμινιστικό loop για τη δουλειά που είναι πραγματικά μη ντετερμινιστική.

Το συμπέρασμα

Ένα μεγάλο μερίδιο της δουλειάς παραγωγής agents είναι ντετερμινιστικό orchestration φορώντας κοστούμι agent. Για αυτή τη δουλειά, το Step Functions σου δίνει retries, δρομολόγηση σφαλμάτων, παραλληλισμό και μια ανθεκτική κατάσταση ανθρώπινης έγκρισης που διαφορετικά θα χτιζες και θα συντηρούσες με το χέρι, συν ένα ιστορικό εκτέλεσης που λειτουργεί και ως audit log. Άσε το μοντέλο να κάνει τις κλήσεις που χρειάζονται κρίση, και άσε μια state machine να κατέχει τη ροή ελέγχου. Ο πιο αξιόπιστος agent είναι συχνά αυτός όπου το μοντέλο αποφασίζει το λιγότερο.

Διάβασε αυτό στη συνέχεια

Για την ανάγνωση υποδομής και πλατφόρμας του ίδιου προτύπου, συμπεριλαμβανομένων πυλών έγκρισης σε λειτουργίες υψηλού κινδύνου, οι σημειώσεις πεδίου cloud βρίσκονται στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.