23 Ιανουαρίου 2026

Ξετυλίγοντας τον βρόχο πρακτόρων Codex

Από τον Μάικλ Μπόλιν, μέλος του τεχνικού προσωπικού

Φόρτωση…

Το Codex CLI⁠(ανοίγει σε νέο παράθυρο) είναι ο τοπικός παράγοντας λογισμικού για όλες τις πλατφόρμες, σχεδιασμένος να παράγει υψηλής ποιότητας και αξιόπιστες αλλαγές λογισμικού, ενώ παράλληλα λειτουργεί με ασφάλεια και αποτελεσματικότητα στον υπολογιστή σας. Έχουμε μάθει πάρα πολλά για το πώς να δημιουργήσουμε έναν πράκτορα λογισμικού παγκόσμιας κλάσης από τότε που κυκλοφορήσαμε για πρώτη φορά το CLI τον Απρίλιο⁠. Για να αναλύσουμε αυτές τις πληροφορίες, αυτή είναι η πρώτη ανάρτηση σε μια συνεχιζόμενη σειρά όπου θα εξερευνήσουμε διάφορες πτυχές του τρόπου με τον οποίον λειτουργεί το Codex, καθώς και διδάγματα που αποκτήθηκαν με κόπο. (Για μια ακόμη πιο λεπτομερή εικόνα του τρόπου κατασκευής του Codex CLI, ανατρέξτε στο αποθετήριο ανοιχτού κώδικα στο https://github.com/openai/codex⁠(ανοίγει σε νέο παράθυρο).) Πολλές από τις πιο λεπτές λεπτομέρειες των σχεδιαστικών αποφάσεών μας έχουν καταγραφεί σε ζητήματα και αιτήματα συγχώνευσης κώδικα στο GitHub, εάν θέλετε να μάθετε περισσότερα.

Για να ξεκινήσουμε, θα επικεντρωθούμε στον βρόχο πρακτόρων, ο οποίος είναι η βασική λογική στο Codex CLI που είναι υπεύθυνη για την ενορχήστρωση της αλληλεπίδρασης μεταξύ του χρήστη, του μοντέλου και των εργαλείων που επικαλείται το μοντέλο για εκτέλεση ουσιαστικής εργασίας λογισμικού. Ελπίζουμε ότι η ανάρτηση αυτή σας δίνει μια καλή εικόνα για τον ρόλο που διαδραματίζει ο πράκτοράς μας (ή ο «πληρεξούσιος») στην αξιοποίηση ενός LLM.

Προτού εμβαθύνουμε, μια γρήγορη σημείωση σχετικά με την ορολογία: στην OpenAI, το «Codex» περιλαμβάνει μια σουίτα προσφορών λογισμικού, συμπεριλαμβανομένων των Codex CLI, Codex Cloud και της επέκτασης Codex VS Code. Αυτή η ανάρτηση εστιάζει στο πληρεξούσιο Codex, το οποίο παρέχει τον βασικό βρόχο του πράκτορα και τη λογική εκτέλεσης που αποτελεί τη βάση όλων των εμπειριών Codex και εμφανίζεται μέσω του Codex CLI. Για λόγους ευκολίας εδώ, θα χρησιμοποιούμε τους όρους «Codex» και «Codex CLI» εναλλακτικά.

Ο βρόχος του πράκτορα

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

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

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

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

Τα διακριτικά εξόδου μεταφράζονται ξανά σε κείμενο, το οποίο γίνεται η απόκριση του μοντέλου. Επειδή τα διακριτικά παράγονται σταδιακά, η μετάφραση αυτή μπορεί να συμβεί καθώς εκτελείται το μοντέλο, γι' αυτό και πολλές εφαρμογές που βασίζονται σε LLM εμφανίζουν ροή δεδομένων. Στην πράξη, η συμπερασματολογία συνήθως ενθυλακώνεται πίσω από ένα API που λειτουργεί με κείμενο, αφαιρώντας τις λεπτομέρειες της δημιουργίας διακριτικών.

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

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

Επειδή ο πράκτορας μπορεί να εκτελέσει κλήσεις εργαλείων που τροποποιούν το τοπικό περιβάλλον, η «έξοδός» του δεν περιορίζεται στο μήνυμα του βοηθού. Σε πολλές περιπτώσεις, η κύρια εξαγωγή ενός λογισμικού είναι ο κώδικας που γράφει ή επεξεργάζεται στο μηχάνημά σας. Παρ 'όλα αυτά, κάθε σειρά τελειώνει πάντα με ένα μήνυμα βοηθού—όπως «Πρόσθεσα το architecture.md που ζητήσατε»—το οποίο σηματοδοτεί μια κατάσταση τερματισμού στον βρόχο πράκτορα. Από την οπτική του πράκτορα, η εργασία του έχει ολοκληρωθεί και ο έλεγχος επιστρέφει στον χρήστη.

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

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

Αυτό σημαίνει ότι καθώς η συνομιλία αυξάνεται, αυξάνεται και το μήκος της προτροπής που χρησιμοποιείται για τη δειγματοληψία του μοντέλου. Αυτό το μήκος έχει σημασία επειδή κάθε μοντέλο έχει ένα παράθυρο περιβάλλοντος, το οποίο είναι ο μέγιστος αριθμός διακριτικών που μπορεί να χρησιμοποιήσει για μία κλήση συμπερασματολογίας. Σημειώστε ότι αυτό το παράθυρο περιλαμβάνει διακριτικά εισαγωγής και εξαγωγής. Όπως μπορείτε να φανταστείτε, ένας πράκτορας θα μπορούσε να αποφασίσει να πραγματοποιήσει εκατοντάδες κλήσεις εργαλείων σε μία μόνο αλληλεπίδραση, εξαντλώντας ενδεχομένως το παράθυρο περιεχομένου. Γι' αυτόν τον λόγο, η διαχείριση παραθύρων περιβάλλοντος είναι μία από τις πολλές αρμοδιότητες του πράκτορα. Τώρα, ας εξετάσουμε πώς εκτελεί το Codex τον βρόχο του πράκτορα.

Συμπερασματολογία μοντέλου

Το Codex CLI στέλνει αιτήματα HTTP στο Responses API⁠(ανοίγει σε νέο παράθυρο) για να εκτελέσει συμπερασματολογία μοντέλου. Θα εξετάσουμε πώς ρέει η πληροφορία μέσω του Codex, το οποίο χρησιμοποιεί το Responses API για να καθοδηγήσει τον βρόχο του πράκτορα.

Το τελικό σημείο του Responses API που χρησιμοποιεί το Codex CLI είναι διαμορφώσιμο⁠(ανοίγει σε νέο παράθυρο), ώστε να μπορεί να χρησιμοποιηθεί με οποιοδήποτε τελικό σημείο που υλοποιεί το Responses API⁠(ανοίγει σε νέο παράθυρο):

Όταν χρησιμοποιείτε το ChatGPT για σύνδεση⁠(ανοίγει σε νέο παράθυρο) με το Codex CLI, χρησιμοποιεί https://chatgpt.com/backend-api/codex/responses ως το τελικό σημείο
Όταν χρησιμοποιείτε έλεγχο ταυτότητας με κλειδί API⁠(ανοίγει σε νέο παράθυρο) με τα φιλοξενούμενα μοντέλα της OpenAI, χρησιμοποιεί https://api.openai.com/v1/responses ως το τελικό σημείο
Όταν εκτελείτε το Codex CLI με --oss για να χρησιμοποιήσετε το gpt-oss⁠ με το ollama 0.13.4+⁠(ανοίγει σε νέο παράθυρο) ή το LM Studio 0.3.39+⁠(ανοίγει σε νέο παράθυρο), από προεπιλογή γίνεται χρήση του http://localhost:11434/v1/responses που εκτελείται τοπικά στον υπολογιστή σας
Το Codex CLI μπορεί να χρησιμοποιηθεί με το Responses API που φιλοξενείται από έναν πάροχο cloud, όπως το Azure

Ας εξετάσουμε πώς δημιουργεί το Codex την προτροπή για την πρώτη κλήση συμπερασματολογίας σε μια συνομιλία.

Δημιουργία της αρχικής προτροπής

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

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

Το Responses API⁠(ανοίγει σε νέο παράθυρο) δέχεται ένα ωφέλιμο φορτίο JSON με πολλές παραμέτρους. Θα επικεντρωθούμε σε αυτά τα τρία:

οδηγίες⁠(ανοίγει σε νέο παράθυρο): μήνυμα συστήματος (ή προγραμματιστή) που εισάγεται στο πλαίσιο του μοντέλου
εργαλεία⁠(ανοίγει σε νέο παράθυρο): μια λίστα εργαλείων που το μοντέλο μπορεί να καλέσει κατά τη δημιουργία μιας απάντησης
εισαγωγή⁠(ανοίγει σε νέο παράθυρο): μια λίστα από εισαγωγές κειμένου, εικόνας ή αρχείων στο μοντέλο

Στο Codex, το πεδίο οδηγίες διαβάζεται από το model_instructions_file⁠(ανοίγει σε νέο παράθυρο) στο ~/.codex/config.toml, αν έχει καθοριστεί. Διαφορετικά, χρησιμοποιούνται τα base_instructions που σχετίζονται με ένα μοντέλο⁠(ανοίγει σε νέο παράθυρο). Οι οδηγίες που αφορούν συγκεκριμένα μοντέλα βρίσκονται στο αποθετήριο του Codex και είναι ομαδοποιημένες στο CLI (π.χ., gpt-5.2-codex_prompt.md⁠(ανοίγει σε νέο παράθυρο)).

Το πεδίο εργαλεία αποτελεί λίστα ορισμών εργαλείων που συμμορφώνονται με ένα σχήμα που ορίζεται από το Responses API. Για το Codex, αυτό περιλαμβάνει εργαλεία τα οποία παρέχονται από το Codex CLI, εργαλεία που παρέχονται από το Responses API και πρέπει να είναι διαθέσιμα στο Codex, καθώς και εργαλεία που παρέχονται από τον χρήστη, συνήθως μέσω διακομιστών MCP:

JavaScript

1[
2  // Codex's default shell tool for spawning new processes locally.
3  {
4    "type": "function",
5    "name": "shell",
6    "description": "Runs a shell command and returns its output...",
7    "strict": false,
8    "parameters": {
9      "type": "object",
10      "properties": {
11        "command": {"type": "array", "description": "The command to execute", ...},
12        "workdir": {"description": "The working directory...", ...},
13        "timeout_ms": {"description": "The timeout for the command...", ...},
14        ...
15      },
16      "required": ["command"],
17    }
18  }
19
20  // Codex's built-in plan tool.
21  {
22    "type": "function",
23    "name": "update_plan",
24    "description": "Updates the task plan...",
25    "strict": false,
26    "parameters": {
27      "type": "object",
28      "properties": {"plan":..., "explanation":...},
29      "required": ["plan"]
30    }
31  },
32
33  // Web search tool provided by the Responses API.
34  {
35    "type": "web_search",
36    "external_web_access": false
37  },
38
39  // MCP server for getting weather as configured in the
40  // user's ~/.codex/config.toml.
41  {
42    "type": "function",
43    "name": "mcp__weather__get-forecast",
44    "description": "Get weather alerts for a US state",
45    "strict": false,
46    "parameters": {
47      "type": "object",
48      "properties": {"latitude": {...}, "longitude": {...}},
49      "required": ["latitude", "longitude"]
50    }
51  }
52]

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

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

Το μήνυμα δημιουργείται από ένα πρότυπο όπου τα βασικά τμήματα περιεχομένου προέρχονται από αποσπάσματα Markdown τα οποία περιλαμβάνονται στο Codex CLI, όπως τα workspace_write.md⁠(ανοίγει σε νέο παράθυρο) και on_request.md⁠(ανοίγει σε νέο παράθυρο):

Απλό κείμενο

1<permissions instructions>
2  - description of the sandbox explaining file permissions and network access
3  - instructions for when to ask the user for permissions to run a shell command
4  - list of folders writable by Codex, if any
5</permissions instructions>

2. (Προαιρετικό) Ένα μήνυμα με ρόλος=προγραμματιστής του οποίου το περιεχόμενο είναι η τιμή developer_instructions που διαβάζεται από το αρχείο config.toml του χρήστη.

3. (Προαιρετικό) Ένα μήνυμα με ρόλος=χρήστης του οποίου το περιεχόμενο είναι οι «οδηγίες χρήστη», οι οποίες δεν προέρχονται από ένα μόνο αρχείο ωστόσο είναι συγκεντρωμένες από πολλαπλές πηγές⁠(ανοίγει σε νέο παράθυρο). Γενικά, πιο συγκεκριμένες οδηγίες εμφανίζονται αργότερα:

Περιεχόμενα των AGENTS.override.md και AGENTS.md στο $CODEX_HOME
Με την επιφύλαξη ενός ορίου (32 KiB, βάσει προεπιλογής), αναζητήστε σε κάθε φάκελο από τη ρίζα Git/project του cwd (αν υπάρχει) μέχρι το ίδιο το cwd : προσθέστε τα περιεχόμενα οποιουδήποτε από το AGENTS.override.md, AGENTS.md ή οποιοδήποτε όνομα αρχείου καθορίζεται από το project_doc_fallback_filenames στο config.toml
Εάν έχουν διαμορφωθεί κάποιες δεξιότητες⁠(ανοίγει σε νέο παράθυρο):
- ένα σύντομο προοίμιο σχετικά με τις δεξιότητες
- τα μεταδεδομένα δεξιοτήτων⁠(ανοίγει σε νέο παράθυρο) για κάθε δεξιότητα
- μια ενότητα σχετικά με το πώς να χρησιμοποιείτε δεξιότητες⁠(ανοίγει σε νέο παράθυρο)

4. Ένα μήνυμα με ρόλος=χρήστης που περιγράφει το τοπικό περιβάλλον στο οποίο ο πράκτορας λειτουργεί αυτήν τη στιγμή. Αυτό καθορίζει τον τρέχοντα κατάλογο εργασίας και το περιβάλλον κώδικα του χρήστη⁠(ανοίγει σε νέο παράθυρο):

Απλό κείμενο

1<environment_context>
2  <cwd>/Users/mbolin/code/codex5</cwd>
3  <shell>zsh</shell>
4</environment_context>

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

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

JSON

1{
2  "type": "message",
3  "role": "user",
4  "content": [
5    {
6      "type": "input_text",
7      "text": "Add an architecture diagram to the README.md"
8    }
9  ]
10}

Μόλις το Codex δημιουργήσει το πλήρες ωφέλιμο φορτίο JSON για αποστολή στο Responses API, στη συνέχεια υποβάλλει το αίτημα HTTP POST με μια κεφαλίδα Εξουσιοδότησης ανάλογα με τον τρόπο που έχει ρυθμιστεί το τελικό σημείο του Responses API στο ~/.codex/config.toml (προστίθενται επιπλέον κεφαλίδες HTTP και παράμετροι ερωτήματος, εάν καθοριστούν).

Όταν ένας διακομιστής του OpenAI Responses API λαμβάνει το αίτημα, χρησιμοποιεί το JSON για να εξάγει την προτροπή για το μοντέλο ως ακολούθως (για να είστε σίγουροι, μια προσαρμοσμένη υλοποίηση του Responses API θα μπορούσε να κάνει διαφορετική επιλογή):

Διάγραμμα στιγμιότυπου που δείχνει ένα μόνο βήμα σε έναν βρόχο πράκτορα τεχνητής νοημοσύνης. Ένα αίτημα χρήστη εισέρχεται στο μοντέλο, το οποίο παράγει μια σκέψη, μια ενέργεια με το όνομα ενός εργαλείου και μια είσοδο εργαλείου. Το διάγραμμα επισημαίνει αυτό το ενδιάμεσο βήμα της συλλογιστικής πριν από την κλήση του εργαλείου.

Όπως μπορείτε να δείτε, η σειρά των τριών πρώτων στοιχείων στην προτροπή καθορίζεται από τον διακομιστή, όχι από τον πελάτη. Ωστόσο, από αυτά τα τρία στοιχεία, μόνο το περιεχόμενο του μηνύματος του συστήματος ελέγχεται επίσης από τον διακομιστή, καθώς τα εργαλεία και οι οδηγίες καθορίζονται από τον πελάτη. Αυτά ακολουθούνται από την εισαγωγή από το JSON ωφέλιμο φορτίο για να ολοκληρωθεί η προτροπή.

Τώρα που έχουμε την προτροπή μας, είμαστε έτοιμοι να δειγματίσουμε το μοντέλο.

Η πρώτη σειρά

Αυτό το αίτημα HTTP προς το Responses API ξεκινά την πρώτη «σειρά» μιας συνομιλίας στο Codex. Ο διακομιστής απαντά με μια ροή Server-Sent Events (SSE⁠(ανοίγει σε νέο παράθυρο)). Τα δεδομένα κάθε συμβάντος είναι ένα ωφέλιμο φορτίο JSON με έναν «τύπο» που ξεκινά με «απόκριση», το οποίο θα μπορούσε να είναι κάτι σαν αυτό (μια πλήρης λίστα συμβάντων μπορεί να βρεθεί στα έγγραφα API⁠(ανοίγει σε νέο παράθυρο) που διαθέτουμε):

Απλό κείμενο

1data: {"type":"response.reasoning_summary_text.delta","delta":"ah ", ...}
2data: {"type":"response.reasoning_summary_text.delta","delta":"ha!", ...}
3data: {"type":"response.reasoning_summary_text.done", "item_id":...}
4data: {"type":"response.output_item.added", "item":{...}}
5data: {"type":"response.output_text.delta", "delta":"forty-", ...}
6data: {"type":"response.output_text.delta", "delta":"two!", ...}
7data: {"type":"response.completed","response":{...}}

Το Codex καταναλώνει τη ροή των συμβάντων⁠(ανοίγει σε νέο παράθυρο) και τα αναδημοσιεύει ως εσωτερικά αντικείμενα συμβάντων που μπορούν να χρησιμοποιηθούν από έναν πελάτη. Συμβάντα όπως το response.output_text.delta χρησιμοποιούνται για υποστήριξη της ροής στο περιβάλλον χρήστη, ενώ άλλα συμβάντα όπως το response.output_item.added μετατρέπονται σε αντικείμενα που προστίθενται στην εισαγωγή για επόμενες κλήσεις του Responses API.

Ας υποθέσουμε ότι το πρώτο αίτημα προς το Responses API περιλαμβάνει δύο συμβάντα response.output_item.done: ένα με τύπος=συλλογιστική και ένα με τύπος=λειτουργική_κλήση. Αυτά τα συμβάντα πρέπει να αναπαρίστανται στο πεδίο εισαγωγή του JSON όταν υποβάλλουμε ξανά ερώτημα στο μοντέλο με την απόκριση στην κλήση του εργαλείου:

JavaScript

1[
2  /* ... original 5 items from the input array ... */
3  {
4    "type": "reasoning",
5    "summary": [
6      "type": "summary_text",
7      "text": "**Adding an architecture diagram for README.md**\n\nI need to..."
8    ],
9    "encrypted_content": "gAAAAABpaDWNMxMeLw..."
10  },
11  {
12    "type": "function_call",
13    "name": "shell",
14    "arguments": "{\"command\":\"cat README.md\",\"workdir\":\"/Users/mbolin/code/codex5\"}",
15    "call_id": "call_8675309..."
16  },
17  {
18    "type": "function_call_output",
19    "call_id": "call_8675309...",
20    "output": "<p align=\"center\"><code>npm i -g @openai/codex</code>..."
21  }
22]

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

Διάγραμμα με ετικέτα «Snapshot 2» που δείχνει έναν πράκτορα τεχνητής νοημοσύνης μετά από μια κλήση εργαλείου. Το μοντέλο λαμβάνει μια παρατήρηση εργαλείου και παράγει μια νέα σκέψη και δράση. Τα βέλη συνδέουν εισαγωγές, παρατηρήσεις και εξόδους για να απεικονίσουν πώς ο πράκτορας επαναλαμβάνει τον βρόχο της συλλογιστικής του.

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

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

Απλό κείμενο

1data: {"type":"response.output_text.done","text": "I added a diagram to explain...", ...}
2data: {"type":"response.completed","response":{...}}

Στο Codex CLI, παρουσιάζουμε το μήνυμα του βοηθού στον χρήστη και εστιάζουμε το πεδίο σύνταξης για να υποδείξουμε στον χρήστη ότι είναι η «σειρά» του να συνεχίσει τη συζήτηση. Εάν ο χρήστης απαντήσει, τόσο το μήνυμα του βοηθού από την προηγούμενη αλληλεπίδραση όσο και το νέο μήνυμα του χρήστη πρέπει να προστεθούν στην εισαγωγή στο αίτημα του Responses API για να αρχίσει η νέα αλληλεπίδραση:

JavaScript

1[
2  /* ... all items from the last Responses API request ... */
3  {
4    "type": "message",
5    "role": "assistant",
6    "content": [
7      {
8        "type": "output_text",
9        "text": "I added a diagram to explain the client/server architecture."
10      }
11    ]
12  },
13  {
14    "type": "message",
15    "role": "user",
16    "content": [
17      {
18        "type": "input_text",
19        "text": "That's not bad, but the diagram is missing the bike shed."
20      }
21    ]
22  }
23]

Για άλλη μια φορά, επειδή συνεχίζουμε μια συζήτηση, το μήκος της εισαγωγής που στέλνουμε στο Responses API αυξάνεται συνεχώς:

Διάγραμμα με την ετικέτα «Snapshot 3» που δείχνει το τελικό στάδιο ενός βρόχου πράκτορα τεχνητής νοημοσύνης. Αφού λάβει τα αποτελέσματα των εργαλείων, το μοντέλο δημιουργεί μια καταληκτική σκέψη και μια τελική απάντηση που επιστρέφεται στον χρήστη. Τα βέλη απεικονίζουν τη μετάβαση από την έξοδο του εργαλείου στην ολοκληρωμένη απάντηση.

Ας εξετάσουμε τι σημαίνει αυτή η συνεχώς αυξανόμενη προτροπή για την απόδοση.

Σκέψεις για την απόδοση

Ίσως να αναρωτιέστε, «Για μία στιγμή. Δεν είναι ο βρόχος του πράκτορα τετραγωνικός ως προς την ποσότητα JSON που αποστέλλεται στο Responses API κατά τη διάρκεια της συνομιλίας;» Και θα είχατε δίκιο. Αν και το Responses API υποστηρίζει μια προαιρετική παράμετρο previous_response_id⁠(ανοίγει σε νέο παράθυρο) για αντιμετώπιση αυτού του προβλήματος, το Codex δεν τη χρησιμοποιεί σήμερα, κυρίως για να διατηρεί τα αιτήματα πλήρως χωρίς κατάσταση και να υποστηρίζει διαμορφώσεις Μη διατήρησης δεδομένων (ZDR).

Η αποφυγή του previous_response_id απλοποιεί τα πράγματα για τον πάροχο του Responses API, καθώς διασφαλίζει ότι κάθε αίτημα δεν έχει κατάσταση. Αυτό καθιστά επίσης απλή την υποστήριξη πελατών που έχουν επιλέξει Μη διατήρηση δεδομένων (ZDR)⁠(ανοίγει σε νέο παράθυρο), καθώς η αποθήκευση των δεδομένων που απαιτούνται για υποστήριξη του previous_response_id θα ήταν αντίθετη με το ZDR. Σημειώστε ότι οι πελάτες ZDR δεν θυσιάζουν τη δυνατότητα να επωφελούνται από ιδιοκτησιακά μηνύματα συλλογιστικής από προηγούμενους γύρους, καθώς το σχετικό encrypted_content μπορεί να αποκρυπτογραφηθεί στον διακομιστή. (Η OpenAI διατηρεί το κλειδί αποκρυπτογράφησης ενός πελάτη ZDR, αλλά όχι τα δεδομένα του.) Δείτε τα αιτήματα συγχώνευσης κώδικα #642⁠(ανοίγει σε νέο παράθυρο) και #1641⁠(ανοίγει σε νέο παράθυρο) για τις σχετικές αλλαγές στο Codex για την υποστήριξη του ZDR.

Γενικά, το κόστος της δειγματοληψίας του μοντέλου υπερβαίνει το κόστος της κίνησης δικτύου, καθιστώντας τη δειγματοληψία τον κύριο στόχο των προσπαθειών μας για αποδοτικότητα. Γι’ αυτό η προσωρινή αποθήκευση προτροπών είναι τόσο σημαντική, καθώς μας επιτρέπει να επαναχρησιμοποιούμε υπολογιστική ισχύ από μια προηγούμενη κλήση συμπερασματολογίας. Όταν έχουμε επισκέψεις στην προσωρινή μνήμη, η δειγματοληψία του μοντέλου είναι γραμμική αντί για τετραγωνική. Η τεκμηρίωση για την προσωρινή αποθήκευση προτροπών ⁠(ανοίγει σε νέο παράθυρο)το επεξηγεί αυτό με περισσότερες λεπτομέρειες:

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

Έχοντας αυτό κατά νου, ας εξετάσουμε ποιοι τύποι λειτουργιών θα μπορούσαν να προκαλέσουν «αστοχία προσωρινής μνήμης» στο Codex:

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

Η ομάδα της Codex πρέπει να είναι επιμελής κατά την εισαγωγή νέων λειτουργιών στο Codex CLI που θα μπορούσαν να θέσουν σε κίνδυνο την άμεση προσωρινή αποθήκευση. Για παράδειγμα, η αρχική μας υποστήριξη για εργαλεία MCP παρουσίασε ένα σφάλμα όταν δεν καταφέραμε να απαριθμήσουμε τα εργαλεία με συνεπή σειρά⁠(ανοίγει σε νέο παράθυρο), προκαλώντας αστοχίες στην προσωρινή μνήμη. Σημειώστε ότι τα εργαλεία MCP μπορεί να είναι ιδιαίτερα δύσκολα, επειδή οι διακομιστές MCP μπορούν να αλλάζουν τη λίστα των εργαλείων που παρέχουν δυναμικά μέσω μιας ειδοποίησης notifications/tools/list_changed⁠(ανοίγει σε νέο παράθυρο). Η τήρηση αυτής της ειδοποίησης στη μέση μιας μακράς συνομιλίας μπορεί να προκαλέσει μια δαπανηρή αστοχία στην προσωρινή μνήμη.

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

Εάν αλλάξει η διαμόρφωση του περιβάλλοντος δοκιμών ή η λειτουργία έγκρισης, εισάγουμε⁠(ανοίγει σε νέο παράθυρο) ένα νέο μήνυμα role=developer με την ίδια μορφή όπως το αρχικό στοιχείο <permissions instructions>.
Εάν αλλάξει ο τρέχων κατάλογος εργασίας, εισάγουμε⁠(ανοίγει σε νέο παράθυρο) ένα νέο μήνυμα ρόλος=χρήστης με την ίδια μορφή όπως το αρχικό <environment_context>.

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

Η γενική στρατηγική μας για να αποφύγουμε να εξαντλήσουμε το παράθυρο συμφραζομένων είναι να συμπυκνώσουμε τη συνομιλία μόλις ο αριθμός των διακριτικών υπερβεί κάποιο όριο. Συγκεκριμένα, αντικαθιστούμε την εισαγωγή με μια νέα, μικρότερη λίστα στοιχείων που αντιπροσωπεύει τη συνομιλία, επιτρέποντας στον πράκτορα να συνεχίσει με κατανόηση του τι έχει συμβεί μέχρι στιγμής. Μια πρώιμη υλοποίηση της συμπίεσης⁠(ανοίγει σε νέο παράθυρο) απαιτούσε από εσάς να καλέσετε μη αυτόματα την εντολή /compact, η οποία θα έθετε ερώτημα στο Responses API χρησιμοποιώντας την υπάρχουσα συζήτηση μαζί με προσαρμοσμένες οδηγίες για σύνοψη⁠(ανοίγει σε νέο παράθυρο). Το Codex χρησιμοποίησε το προκύπτον μήνυμα βοηθού που περιείχε τη σύνοψη ως τη νέα εισαγωγή⁠(ανοίγει σε νέο παράθυρο) για επόμενες σειρές συνομιλίας.

Από τότε, το Responses API έχει εξελιχθεί ώστε να υποστηρίζει ένα ειδικό /responses/compact τελικό σημείο⁠(ανοίγει σε νέο παράθυρο) που εκτελεί τη συμπύκνωση πιο αποδοτικά. Επιστρέφει μια λίστα στοιχείων⁠(ανοίγει σε νέο παράθυρο) που μπορούν να χρησιμοποιηθούν στη θέση της προηγούμενης εισαγωγής για να συνεχιστεί η συνομιλία, ενώ παράλληλα ελευθερώνεται το παράθυρο περιβάλλοντος. Αυτή η λίστα περιλαμβάνει ένα ειδικό στοιχείο τύπος=συμπύκνωση με ένα αδιαφανές στοιχείο encrypted_content που διατηρεί τη λανθάνουσα κατανόηση του μοντέλου για την αρχική συνομιλία. Τώρα, το Codex χρησιμοποιεί αυτόματα αυτό το τελικό σημείο για να συμπυκνώνει τη συνομιλία όταν υπερβεί το auto_compact_limit⁠(ανοίγει σε νέο παράθυρο).

Στη συνέχεια

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

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

Συντάκτης

Michael Bolin

Ευχαριστίες

Ιδιαίτερες ευχαριστίες σε ολόκληρη την ομάδα που ανέπτυξε το Codex CLI.

Συνεχίστε να διαβάζετε

Εμφάνιση όλων

Κατασκευή αυτοβελτιούμενων φορολογικών πρακτόρων με Codex

27 Μαΐ 2026

Δημιουργία ενός ασφαλούς, αποτελεσματικού sandbox για την ενεργοποίηση του Codex στα Windows

13 Μαΐ 2026

Πώς προέκυψαν τα γκόμπλιν

5 Μαΐ 2026