Ξεκλείδωμα μηχανισμού Codex: πώς δημιουργήσαμε το App Server

Ο πράκτορας προγραμματισμού Codex της OpenAI είναι διαθέσιμος σε πολλές διαφορετικές επιφάνειες: την εφαρμογή web⁠(ανοίγει σε νέο παράθυρο), το CLI⁠(ανοίγει σε νέο παράθυρο), την επέκταση IDE⁠(ανοίγει σε νέο παράθυρο) και τη νέα εφαρμογή Codex για macOS. Κάτω από το καπό, όλα τροφοδοτούνται από τον ίδιο μηχανισμό Codex —ο βρόχος του πράκτορα και η λογική που αποτελεί τη βάση όλων των εμπειριών Codex. Ο κρίσιμος σύνδεσμος μεταξύ τους; Ο Codex App Server⁠(ανοίγει σε νέο παράθυρο), ένα φιλικό προς τον πελάτη, αμφίδρομο API JSON-RPC¹.

Σε αυτήν την ανάρτηση, θα παρουσιάσουμε τον Codex App Server. Θα μοιραστούμε όσα έχουμε μάθει μέχρι τώρα σχετικά με τους καλύτερους τρόπους για να ενσωματώσετε τις δυνατότητες του Codex στο προϊόν σας, ώστε να βοηθήσετε τους χρήστες σας να απογειώσουν τις ροές εργασίας τους. Θα καλύψουμε την αρχιτεκτονική και το πρωτόκολλο του App Server και το πώς ενσωματώνεται με διαφορετικές επιφάνειες του Codex, καθώς και συμβουλές για την αξιοποίηση του Codex, είτε θέλετε να μετατρέψετε το Codex σε αξιολογητή κώδικα, σε πράκτορα SRE ή σε βοηθό προγραμματισμού.

Πριν εμβαθύνουμε στην αρχιτεκτονική, είναι χρήσιμο να γνωρίζετε το παρασκήνιο του App Server. Αρχικά, ο App Server ήταν ένας πρακτικός τρόπος να επαναχρησιμοποιηθεί σε προϊόντα ο μηχανισμός του Codex, ο οποίος σταδιακά εξελίχθηκε στο πρότυπο πρωτόκολλό μας.

Το Codex CLI ξεκίνησε ως TUI (διεπαφή χρήστη τερματικού), που σημαίνει ότι το Codex είναι προσβάσιμο μέσω του τερματικού. Όταν δημιουργήσαμε την επέκταση VS Code (έναν πιο φιλικό προς το IDE τρόπο αλληλεπίδρασης με πράκτορες Codex), χρειαζόμασταν έναν τρόπο να χρησιμοποιούμε το ίδιο σύστημα ώστε να οδηγούμε τον ίδιο βρόχο πράκτορα από ένα IDE UI χωρίς να τον επαναϋλοποιήσουμε. Αυτό σήμαινε υποστήριξη πλούσιων μοτίβων αλληλεπίδρασης πέρα από το request/response, όπως η εξερεύνηση του χώρου εργασίας, η ροή προόδου καθώς ο πράκτορας συλλογίζεται και η έκδοση διαφορών. Αρχικά πειραματιστήκαμε με την έκθεση του Codex ως διακομιστή MCP⁠(ανοίγει σε νέο παράθυρο), αλλά η διατήρηση της σημασιολογίας του MCP με τρόπο που να έχει νόημα για το VS Code αποδείχθηκε δύσκολη. Αντίθετα, εισαγάγαμε ένα πρωτόκολλο JSON-RPC που αντικατόπτριζε το TUI loop, το οποίο έγινε η ανεπίσημη πρώτη έκδοση⁠(ανοίγει σε νέο παράθυρο) του App Server. Εκείνη την εποχή, δεν περιμέναμε άλλοι πελάτες να εξαρτώνται από τον App Server, οπότε δεν το σχεδιάσαμε ως σταθερό API.

Καθώς η υιοθέτηση του Codex αυξανόταν τους επόμενους μήνες, οι εσωτερικές ομάδες και οι εξωτερικοί συνεργάτες ήθελαν τη δυνατότητα να ενσωματώσουν το ίδιο εργαλείο στα δικά τους προϊόντα, ώστε να επιταχύνουν τις ροές εργασίας ανάπτυξης λογισμικού των χρηστών τους. Για παράδειγμα, οι JetBrains και Xcode ήθελαν μια εμπειρία πράκτορα επιπέδου IDE, ενώ η εφαρμογή Codex για επιτραπέζιους υπολογιστές έπρεπε να ενορχηστρώνει πολλούς πράκτορες Codex παράλληλα. Αυτές οι απαιτήσεις μας ώθησαν να σχεδιάσουμε μια επιφάνεια πλατφόρμας στην οποία τόσο τα προϊόντα μας όσο και οι ενσωματώσεις συνεργατών θα μπορούσαν να βασίζονται με ασφάλεια με την πάροδο του χρόνου. Έπρεπε να είναι εύκολο να ενσωματωθεί και να είναι συμβατό με προηγούμενες εκδόσεις, πράγμα που σήμαινε να μπορούμε να εξελίσσουμε το πρωτόκολλο χωρίς να διακόπτουμε τη λειτουργία των υφιστάμενων πελατών.

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

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

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

2. Διαμόρφωση και έλεγχος ταυτότητας. Το Codex φορτώνει τη διαμόρφωση, διαχειρίζεται τις προεπιλογές και εκτελεί ροές ελέγχου ταυτότητας όπως «Σύνδεση με το ChatGPT», συμπεριλαμβανομένης της κατάστασης των διαπιστευτηρίων.

3. Εκτέλεση εργαλείου και επεκτάσεις. Το Codex εκτελεί εργαλεία shell/file σε περιβάλλον δοκιμών και συνδέει ενσωματώσεις, όπως διακομιστές MCP και δεξιότητες, ώστε να μπορούν να συμμετέχουν στον βρόχο πρακτόρων υπό ένα συνεπές μοντέλο πολιτικής.

Όλη η λογική πράκτορα που αναφέραμε εδώ, συμπεριλαμβανομένου του βασικού βρόχου πράκτορα, βρίσκεται σε ένα τμήμα της βάσης κώδικα Codex CLI που ονομάζεται «Πυρήνας Codex⁠(ανοίγει σε νέο παράθυρο)». Ο Πυρήνας Codex είναι τόσο μια βιβλιοθήκη όπου βρίσκεται όλος ο κώδικας πράκτορα όσο και ένας χρόνος εκτέλεσης που μπορεί να εκκινηθεί για να εκτελέσει τον βρόχο πράκτορα και να διαχειριστεί τη διατήρηση ενός νήματος Codex (συνομιλία).

Για να είναι χρήσιμος, ο μηχανισμός Codex πρέπει να είναι προσβάσιμος στους πελάτες. Εκεί είναι που μπαίνει στο παιχνίδι το App Server.

Το App Server είναι τόσο το πρωτόκολλο JSON-RPC μεταξύ του πελάτη και του διακομιστή όσο και μια μακρόχρονη διεργασία που φιλοξενεί τα νήματα του πυρήνα του Codex. Όπως μπορούμε να δούμε από το παραπάνω διάγραμμα, μια διεργασία App Server έχει τέσσερα κύρια στοιχεία: τον αναγνώστη stdio, τον επεξεργαστή μηνυμάτων Codex, τον διαχειριστή νημάτων και τα νήματα του πυρήνα. Ο διαχειριστής νημάτων εκκινεί μία περίοδο λειτουργίας πυρήνα για κάθε νήμα και στη συνέχεια ο επεξεργαστής μηνυμάτων Codex επικοινωνεί απευθείας με κάθε περίοδο λειτουργίας πυρήνα για να υποβάλει αιτήματα πελατών και να λαμβάνει ενημερώσεις.

Ένα αίτημα πελάτη μπορεί να οδηγήσει σε πολλές ενημερώσεις συμβάντων, και αυτά τα λεπτομερή συμβάντα είναι αυτά που μας επιτρέπουν να δημιουργήσουμε ένα πλούσιο περιβάλλον χρήστη (UI) πάνω από τον App Server. Επιπλέον, ο αναγνώστης stdio και ο επεξεργαστής μηνυμάτων Codex λειτουργούν ως το επίπεδο μετάφρασης μεταξύ του πελάτη και των νημάτων του πυρήνα του Codex. Μεταφράζουν αιτήματα JSON-RPC πελάτη σε λειτουργίες του πυρήνα Codex, παρακολουθούν την εσωτερική ροή συμβάντων του πυρήνα Codex και στη συνέχεια μετατρέπουν αυτά τα χαμηλού επιπέδου συμβάντα σε ένα μικρό σύνολο σταθερών ειδοποιήσεων JSON-RPC που είναι έτοιμες για το περιβάλλον χρήστη.

Το πρωτόκολλο JSON-RPC μεταξύ του πελάτη και του App Server είναι πλήρως αμφίδρομο. Ένα τυπικό νήμα περιλαμβάνει ένα αίτημα πελάτη και πολλές ειδοποιήσεις από τον διακομιστή. Επιπλέον, ο διακομιστής μπορεί να ξεκινήσει αιτήματα όταν ο πράκτορας χρειάζεται εισαγωγή, όπως μια έγκριση, και στη συνέχεια να θέσει σε παύση την αλληλεπίδραση μέχρι να απαντήσει ο πελάτης.

Στη συνέχεια, θα παρουσιάσουμε διεξοδικά τα πρωταρχικά στοιχεία της συνομιλίας, τα δομικά στοιχεία του πρωτοκόλλου App Server. Ο σχεδιασμός ενός API για έναν βρόχο πράκτορα είναι περίπλοκος, επειδή η αλληλεπίδραση χρήστη/πράκτορα δεν είναι μια απλή διαδικασία αιτήματος/απόκρισης. Ένα αίτημα χρήστη μπορεί να εξελιχθεί σε μια δομημένη ακολουθία ενεργειών που ο πελάτης πρέπει να αναπαριστά πιστά: την εισαγωγή του χρήστη, την σταδιακή πρόοδο του πράκτορα, τα τεχνουργήματα που παράγονται στην πορεία (π.χ., διαφορές). Για να διευκολύνουμε την ενσωμάτωση αυτής της ροής αλληλεπίδρασης και να την κάνουμε ανθεκτική σε όλα τα περιβάλλοντα χρήστη, καταλήξαμε σε τρία πρωταρχικά στοιχεία πυρήνα με σαφή όρια και κύκλους ζωής:

1. Στοιχείο: Ένα στοιχείο είναι η ατομική μονάδα εισόδου/αποτελέσματος στο Codex. Τα στοιχεία είναι τυποποιημένα (π.χ., μήνυμα χρήστη, μήνυμα πράκτορα, εκτέλεση εργαλείου, αίτημα έγκρισης, διαφορά) και το καθένα έχει έναν σαφή κύκλο ζωής:

• item/started όταν το στοιχείο ξεκινά
• προαιρετικά συμβάντα item/*/delta ως ροές περιεχομένου (για τύπους στοιχείων ροής)
• item/completed όταν το στοιχείο ολοκληρώνεται με το τελικό του φορτίο

Αυτός ο κύκλος ζωής επιτρέπει στους πελάτες να ξεκινήσουν την απόδοση αμέσως στο started, να μεταδίδουν σταδιακές ενημερώσεις στο delta και να ολοκληρώνουν στο completed.

2. Αλληλεπίδραση: Μια αλληλεπίδραση είναι μία μονάδα εργασίας του πράκτορα που ξεκινά από την εισαγωγή του χρήστη. Αρχίζει όταν ο πελάτης εισάγει περιεχόμενο (για παράδειγμα, «εκτέλεσε δοκιμές και συνόψισε τα σφάλματα») και τελειώνει όταν ο πράκτορας ολοκληρώνει την παραγωγή αποτελεσμάτων για αυτήν την εισαγωγή. Μια αλληλεπίδραση περιλαμβάνει μια ακολουθία στοιχείων που αντιπροσωπεύουν τα ενδιάμεσα βήματα και τα αποτελέσματα που παράγονται κατά τη διάρκεια της διαδικασίας.

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

Τώρα, θα εξετάσουμε μια απλοποιημένη συνομιλία μεταξύ ενός πελάτη και ενός πράκτορα, όπου η συνομιλία αναπαρίσταται από πρωταρχικά στοιχεία:

Στην αρχή της συνομιλίας, ο πελάτης και ο διακομιστής πρέπει να πραγματοποιήσουν τη χειραψία initialize. Ο πελάτης πρέπει να στείλει ένα μόνο αίτημα initialize πριν από οποιαδήποτε άλλη μέθοδο και ο διακομιστής το επιβεβαιώνει με μια απάντηση. Αυτό δίνει στον διακομιστή την ευκαιρία να προβάλλει τις δυνατότητές του και επιτρέπει και στις δύο πλευρές να συμφωνήσουν στην έκδοση του πρωτοκόλλου, στις σημαίες χαρακτηριστικών και στις προεπιλογές πριν ξεκινήσει η πραγματική εργασία. Ακολουθεί ένα παράδειγμα φορτίου από την επέκταση VS Code της OpenAI:

Αυτό επιστρέφει ο διακομιστής:

Όταν ένας πελάτης κάνει ένα νέο αίτημα, θα δημιουργήσει πρώτα ένα νήμα και μετά μια αλληλεπίδραση. Ο διακομιστής θα στείλει πίσω ειδοποιήσεις για την πρόοδο (thread/started και turn/started). Θα στείλει επίσης πίσω τις εισαγωγές που καταγράφει ως στοιχεία, όπως το μήνυμα του χρήστη εδώ.

Οι κλήσεις εργαλείων αποστέλλονται επίσης πίσω στον πελάτη ως στοιχεία. Επιπλέον, ο διακομιστής μπορεί να ζητήσει έγκριση από τον πελάτη πριν μπορέσει να εκτελέσει μια ενέργεια, στέλνοντας ένα αίτημα διακομιστή. Η έγκριση θα θέσει σε παύση την αλληλεπίδραση μέχρι να απαντήσει ο πελάτης με «allow» (να επιτραπεί) ή «deny» (να μην επιτραπεί). Έτσι εμφανίζεται η ροή έγκρισης στην επέκταση του VS Code:

Στο τέλος, ο διακομιστής στέλνει ένα μήνυμα πράκτορα και στη συνέχεια ολοκληρώνει την αλληλεπίδραση με turn/completed. Τα συμβάντα delta του μηνύματος του πράκτορα μεταδίδουν ξανά τμήματα του μηνύματος μέχρι να ολοκληρωθεί το μήνυμα με item/completed.

Τα μηνύματα στο διάγραμμα είναι απλοποιημένα για να είναι ευανάγνωστα. Αν θέλετε να δείτε το JSON για να έχετε ολοκληρωμένη εικόνα, μπορείτε να εκτελέσετε τον test client από το αποθετήριο του Codex CLI:

Τώρα, ας εξετάσουμε πώς ενσωματώνουν το Codex διαφορετικές επιφάνειες πελάτη μέσω του App Server. Θα καλύψουμε τρία μοτίβα: τοπικές εφαρμογές και IDE, το Codex web runtime και το TUI.

Και στα τρία εξ αυτών, η μεταφορά είναι JSON-RPC μέσω stdio (JSONL). Το JSON-RPC καθιστά εύκολη τη δημιουργία συνδέσεων πελάτη στη γλώσσα της επιλογής σας. Οι επιφάνειες του Codex και οι ενσωματώσεις συνεργατών έχουν υλοποιήσει πελάτες App Server σε γλώσσες όπως Go, Python, TypeScript, Swift και Kotlin. Για το TypeScript, μπορείτε να δημιουργήσετε ορισμούς απευθείας από το πρωτόκολλο Rust εκτελώντας:

Για άλλες γλώσσες, μπορείτε να δημιουργήσετε ένα πακέτο JSON Schema και να το τροφοδοτήσετε στον προτιμώμενο δημιουργό κώδικα εκτελώντας:

Οι τοπικοί πελάτες συνήθως ομαδοποιούν ή ανακτούν ένα δυαδικό αρχείο App Server ειδικό για την πλατφόρμα, το εκκινούν ως θυγατρική διεργασία μεγάλης διάρκειας και διατηρούν ανοιχτό ένα αμφίδρομο κανάλι stdio για JSON-RPC. Στην επέκταση VS Code και την εφαρμογή Desktop, για παράδειγμα, το τεχνούργημα που διατέθηκε περιλαμβάνει το δυαδικό αρχείο Codex που είναι ειδικό για την πλατφόρμα και είναι συνδεδεμένο σε μια δοκιμασμένη έκδοση, ώστε ο πελάτης να εκτελεί πάντα ακριβώς τα δεδομένα που επικυρώσαμε.

Δεν μπορούν όλες οι ενσωματώσεις να διαθέτουν συχνά ενημερώσεις πελάτη. Ορισμένοι συνεργάτες, όπως το Xcode, αποσυνδέουν τους κύκλους κυκλοφορίας διατηρώντας τον client σταθερό και επιτρέποντας να δείχνει σε ένα νεότερο δυαδικό αρχείο App Server όταν χρειάζεται. Με αυτόν τον τρόπο μπορούν να υιοθετούν βελτιώσεις από την πλευρά του διακομιστή (π.χ., καλύτερη αυτόματη συμπίεση στον πυρήνα του Codex ή νέα υποστηριζόμενα κλειδιά διαμόρφωσης) και να κυκλοφορούν διορθώσεις σφαλμάτων χωρίς να περιμένουν μια έκδοση πελάτη. Η επιφάνεια JSON-RPC του App Server έχει σχεδιαστεί για να είναι συμβατή με προηγούμενες εκδόσεις, ώστε οι παλαιότεροι πελάτες να μπορούν να επικοινωνούν με νεότερους διακομιστές με ασφάλεια.

Το Codex Web χρησιμοποιεί τον μηχανισμό Codex, αλλά τον εκτελεί σε περιβάλλον κοντέινερ. Ένας εργαζόμενος προετοιμάζει ένα κοντέινερ με τον χώρο εργασίας που έχει ελεγχθεί, εκκινεί το δυαδικό αρχείο του App Server μέσα σε αυτό και διατηρεί ένα μακράς διάρκειας κανάλι JSON-RPC μέσω stdio². Η εφαρμογή web (που εκτελείται στην καρτέλα του προγράμματος περιήγησης του χρήστη) επικοινωνεί με το backend του Codex μέσω HTTP και SSE, που μεταδίδει σε ροή συμβάντα εργασιών που παράγονται από τον εργαζόμενο. Αυτό διατηρεί το περιβάλλον χρήστη (UI) στην πλευρά του προγράμματος περιήγησης ελαφρύ, ενώ μας προσφέρει έναν συνεπή χρόνο εκτέλεσης τόσο σε επιτραπέζιους υπολογιστές όσο και στο web.

Επειδή οι περίοδοι λειτουργίας ιστού είναι εφήμερες (οι καρτέλες κλείνουν, τα δίκτυα αποσυνδέονται), η εφαρμογή web δεν μπορεί να είναι η πηγή αλήθειας για εργασίες μεγάλης διάρκειας. Η διατήρηση της κατάστασης και της προόδου στον διακομιστή σημαίνει ότι η εργασία συνεχίζεται ακόμη και αν η καρτέλα εξαφανιστεί. Το πρωτόκολλο ροής και οι αποθηκευμένες περίοδοι λειτουργίας νημάτων διευκολύνουν μια νέα περίοδο λειτουργίας να επανασυνδεθεί, να συνεχίσει από εκεί που σταμάτησε και να συγχρονιστεί χωρίς να χρειάζεται να αναδημιουργήσει την κατάσταση στον πελάτη.

Ιστορικά, το TUI ήταν ένας «native» πελάτης που εκτελούνταν στην ίδια διεργασία με τον βρόχο του πράκτορα και επικοινωνούσε απευθείας με τους βασικούς τύπους της Rust αντί για το πρωτόκολλο του app-server. Αυτό έκανε την πρώιμη επανάληψη γρήγορη, αλλά έκανε επίσης το TUI μια επιφάνεια ειδικής περίπτωσης.

Τώρα που υπάρχει το App Server, σκοπεύουμε να αναδιαμορφώσουμε το TUI⁠(ανοίγει σε νέο παράθυρο) ώστε να το χρησιμοποιεί, έτσι ώστε να συμπεριφέρεται όπως κάθε άλλος πελάτης: να εκκινεί μια θυγατρική διεργασία App Server, να επικοινωνεί με JSON-RPC μέσω stdio και να αποδίδει τα ίδια συμβάντα ροής και εγκρίσεις. Έτσι ξεκλειδώνονται ροές εργασίας όπου το TUI μπορεί να συνδεθεί σε έναν διακομιστή Codex που εκτελείται σε απομακρυσμένο μηχάνημα, διατηρώντας τον πράκτορα κοντά στους υπολογιστικούς πόρους και συνεχίζοντας την εργασία ακόμη κι αν ο φορητός υπολογιστής τεθεί σε αναστολή ή αποσυνδεθεί, ενώ εξακολουθεί να παρέχει ζωντανές ενημερώσεις και ελέγχους τοπικά.

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

Εκτελέστε codex mcp-server⁠(ανοίγει σε νέο παράθυρο) και συνδεθείτε από οποιονδήποτε πελάτη MCP που υποστηρίζει διακομιστές stdio (π.χ. OpenAI Agents SDK⁠(ανοίγει σε νέο παράθυρο)). Αυτό είναι μια καλή επιλογή αν έχετε ήδη μια ροή εργασιών βασισμένη σε MCP και θέλετε να χρησιμοποιήσετε το Codex ως εργαλείο με δυνατότητα κλήσης. Το μειονέκτημα είναι ότι λαμβάνετε μόνο ό,τι εκθέτει το MCP, επομένως οι αλληλεπιδράσεις ειδικά για το Codex οι οποίες βασίζονται σε πλουσιότερη σημασιολογία περιόδου λειτουργίας (π.χ., ενημερώσεις διαφορών) ενδέχεται να μην αντιστοιχίζονται καθαρά μέσω των τελικών σημείων MCP.

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

Επιλέξτε το App Server όταν θέλετε ο πλήρης μηχανισμός του Codex να εκτεθεί ως μια σταθερή ροή συμβάντων που να είναι φιλική για το περιβάλλον χρήστη. Αποκτάτε τόσο την πλήρη λειτουργικότητα του βρόχου του πράκτορα όσο και άλλες υποστηρικτικές λειτουργίες, όπως το Sign in with ChatGPT, την ανακάλυψη μοντέλου και τη διαχείριση ρυθμίσεων. Το κύριο κόστος είναι η εργασία ενσωμάτωσης, καθώς εσείς πρέπει να δημιουργήσετε τη σύνδεση JSON-RPC στην πλευρά του πελάτη στη γλώσσα σας. Στην πράξη, ωστόσο, το Codex μπορεί να αναλάβει μεγάλο μέρος της βαριάς δουλειάς, εάν του παρέχετε το σχήμα και την τεκμηρίωση JSON. Πολλές ομάδες με τις οποίες συνεργαστήκαμε κατάφεραν να υλοποιήσουν γρήγορα μια λειτουργική ενσωμάτωση χρησιμοποιώντας το Codex.

Μια ελαφριά λειτουργία CLI με δυνατότητα για δέσμες ενεργειών καθώς και εφάπαξ εργασίες και εκτελέσεις CI. Είναι κατάλληλο για αυτοματοποίηση και διαδικασίες όπου επιθυμείτε μία εντολή να εκτελείται μέχρι την ολοκλήρωση χωρίς αλληλεπίδραση, να μεταδίδει δομημένα αποτελέσματα για αρχεία καταγραφής και να τερματίζει με σαφές σήμα επιτυχίας ή αποτυχίας.

Μια βιβλιοθήκη TypeScript για τον προγραμματικό έλεγχο τοπικών πρακτόρων Codex από τη δική σας εφαρμογή. Είναι καλύτερο όταν θέλετε μια εγγενή διεπαφή βιβλιοθήκης για εργαλεία και ροές εργασίας από την πλευρά του διακομιστή, χωρίς να δημιουργήσετε έναν ξεχωριστό πελάτη JSON-RPC. Επειδή κυκλοφόρησε νωρίτερα από το App Server, προς το παρόν υποστηρίζει λιγότερες γλώσσες και μικρότερη επιφάνεια. Εάν υπάρξει ενδιαφέρον από προγραμματιστές, ενδέχεται να προσθέσουμε επιπλέον SDK που να αξιοποιούν το πρωτόκολλο App Server, ώστε οι ομάδες να μπορούν να καλύψουν μεγαλύτερο μέρος της επιφάνειας του μηχανισμού χωρίς να γράφουν συνδέσεις JSON-RPC.

Σε αυτή την ανάρτηση, μοιραστήκαμε πώς προσεγγίζουμε τον σχεδιασμό ενός νέου προτύπου για την αλληλεπίδραση με πράκτορες και πώς να μετατρέψουμε τον μηχανισμό Codex σε ένα σταθερό, φιλικό προς τον πελάτη πρωτόκολλο. Καλύψαμε πώς το App Server εκθέτει τον πυρήνα του Codex, επιτρέπει στους πελάτες να καθοδηγούν τον πλήρη βρόχο του πράκτορα και υποστηρίζει ένα ευρύ φάσμα επιφανειών, συμπεριλαμβανομένων του TUI, των τοπικών ενσωματώσεων IDE και του web runtime.

Αν αυτό σας έδωσε ιδέες για την ενσωμάτωση του Codex στις δικές σας ροές εργασίας, αξίζει να δοκιμάσετε το App Server. Όλος ο πηγαίος κώδικας βρίσκεται στο αποθετήριο⁠(ανοίγει σε νέο παράθυρο) ανοιχτού κώδικα Codex CLI. Μη διστάσετε να μοιραστείτε μαζί μας σχόλια και αιτήματα για λειτουργίες. Ανυπομονούμε να επικοινωνήσετε μαζί μας και να συνεχίσουμε να κάνουμε τους πράκτορες πιο προσβάσιμους σε όλους.