Langkau ke kandungan utama
OpenAI

23 Januari 2026

Kejuruteraan

Menyahgulung gelung ejen Codex

Oleh Michael Bolin, Ahli Kakitangan Teknikal

Memuat…

Codex CLI⁠(dibuka dalam tetingkap baru) ialah ejen perisian tempatan merentas platform kami, direka bentuk untuk menghasilkan perubahan perisian yang berkualiti tinggi dan boleh dipercayai sambil beroperasi dengan selamat dan cekap pada mesin anda. Kami telah mempelajari banyak perkara tentang cara membina ejen perisian bertaraf dunia sejak kami mula-mula melancarkan CLI pada bulan April⁠. Untuk menghuraikan wawasan tersebut, ini adalah siaran pertama dalam siri berterusan di mana kami akan meneroka pelbagai aspek tentang bagaimana Codex berfungsi, serta pengajaran yang diperoleh dengan susah payah. (Untuk pandangan yang lebih terperinci tentang bagaimana Codex CLI dibina, semak repositori sumber terbuka kami di https://github.com/openai/codex⁠(dibuka dalam tetingkap baru). Banyak butiran yang lebih halus tentang keputusan reka bentuk kami didokumentasikan dalam isu GitHub dan permintaan penarikan jika anda ingin mengetahui lebih lanjut.)

Untuk memulakan, kami akan menumpukan perhatian pada gelung ejen, yang merupakan logik teras dalam Codex CLI yang bertanggungjawab untuk menyelaraskan interaksi antara pengguna, model dan alat yang dipanggil oleh model untuk melaksanakan kerja perisian yang bermakna. Kami berharap siaran ini memberi anda gambaran yang baik tentang peranan ejen kami (atau “manfaat”) dalam memanfaatkan LLM.

Sebelum kita mulakan, satu nota ringkas tentang terminologi: di OpenAI, “Codex” merangkumi satu set tawaran ejen perisian, termasuk Codex CLI, Codex Cloud dan sambungan Codex VS Code. Siaran ini menumpukan pada manfaat Codex, yang menyediakan gelung ejen teras dan logik pelaksanaan yang mendasari semua pengalaman Codex dan dipaparkan melalui Codex CLI. Untuk memudahkan di sini, kami akan menggunakan istilah “Codex” dan “Codex CLI” secara berselang-seli.

Gelung ejen

Di tengah-tengah setiap ejen AI terdapat sesuatu yang dipanggil “gelung ejen.” Ilustrasi ringkas gelung ejen adalah seperti berikut:

Gambar rajah bertajuk “Gelung ejen” yang menggambarkan bagaimana sistem AI memproses permintaan pengguna, memanggil alat, memerhati hasil, mengemas kini pelannya dan mengembalikan output. Anak panah menghubungkan langkah-langkah seperti input pengguna, penaakulan model, tindakan alat dan respons akhir.

Untuk memulakan, ejen mengambil input daripada pengguna untuk dimasukkan dalam set arahan teks yang disediakannya untuk model yang dikenali sebagai prom.

Langkah seterusnya ialah menyoal model dengan menghantar arahan kami dan memintanya menjana respons, satu proses yang dikenali sebagai inferens. Semasa inferens, prom teks mula-mula diterjemahkan kepada satu jujukan token⁠(dibuka dalam tetingkap baru) input—integer yang mengindeks ke dalam perbendaharaan kata model. Token ini kemudian digunakan untuk menjadi sampel model, menghasilkan jujukan baharu token output.

Token output diterjemahkan kembali ke dalam teks, yang kemudian menjadi respons model. Oleh kerana token dihasilkan secara berperingkat, terjemahan ini boleh berlaku semasa model berjalan, sebab itulah banyak aplikasi berasaskan LLM memaparkan output penstriman. Dalam latihan, inferens biasanya dikapsulkan di sebalik API yang beroperasi pada teks, mengabstrak keluar butiran pentokenan.

Sebagai hasil daripada langkah inferens, model sama ada (1) menghasilkan respons akhir kepada input asal pengguna, atau (2) meminta satu panggilan alat yang ejen dijangka untuk dilaksanakan (contohnya, “jalankan ls dan laporkan output”). Dalam kes (2), ejen melaksanakan panggilan alat dan menambahkan outputnya kepada prom asal. Output ini digunakan untuk menghasilkan input baharu yang digunakan untuk menyoal semula model; ejen kemudian boleh mengambil kira maklumat baharu ini dan mencuba sekali lagi.

Proses ini berulang sehingga model berhenti mengeluarkan panggilan alat dan sebaliknya menghasilkan mesej untuk pengguna (dirujuk sebagai mesej pembantu dalam model OpenAI). Dalam kebanyakan kes, mesej ini menjawab permintaan asal pengguna secara langsung, tetapi ia juga mungkin menjadi soalan susulan untuk pengguna.

Disebabkan ejen boleh melaksanakan panggilan alat yang mengubah suai persekitaran setempat, “output”nya tidak terhad kepada mesej pembantu. Dalam kebanyakan kes, output utama ejen perisian ialah kod yang ditulis atau diedit pada mesin anda. Namun begitu, setiap pusingan sentiasa berakhir dengan mesej pembantu—seperti "Saya telah menambah architecture.md yang anda minta"—yang menandakan keadaan penamatan dalam gelung ejen. Dari perspektif ejen, kerjanya telah selesai dan kawalan kembali kepada pengguna.

Perjalanan dari input pengguna ke respons ejen yang ditunjukkan dalam gambar rajah dirujuk sebagai satu giliran perbualan (satu jalur dalam Codex). Walaupun giliran perbualan ini boleh merangkumi banyak lelaran antara inferens model dan panggilan alat. Setiap kali anda menghantar mesej baharu kepada perbualan yang sedia ada, sejarah perbualan disertakan sebagai sebahagian daripada prom untuk giliran baharu, yang merangkumi mesej dan panggilan alat daripada giliran sebelumnya:

Gambar rajah bertajuk “Gelung ejen berbilang giliran” yang menunjukkan bagaimana ejen AI mengambil input pengguna, menjana tindakan, merujuk kepada alat, mengemas kini keadaan dan mengembalikan hasil berulang kali. Termasuk langkah-langkah berlabel, anak panah dan output alat contoh yang menggambarkan kitaran penaakulan ejen.

Ini bermakna apabila perbualan berkembang, panjang prom yang digunakan untuk memberikan sampel model juga bertambah. Panjang ini penting kerana setiap model mempunyai tetingkap konteks, iaitu bilangan maksimum token yang boleh digunakan untuk satu panggilan inferens. Perhatikan tetingkap ini merangkumi kedua-dua token input dan output. Seperti yang anda mungkin bayangkan, seorang ejen boleh memutuskan untuk membuat ratusan panggilan alat dalam satu giliran, yang berpotensi menghabiskan tetingkap konteks. Atas sebab ini, pengurusan tetingkap konteks adalah salah satu daripada banyak tanggungjawab ejen. Sekarang, mari kita lihat bagaimana Codex menjalankan gelung ejen.

Inferens model

Codex CLI menghantar permintaan HTTP kepada Responses API⁠(dibuka dalam tetingkap baru) untuk menjalankan inferens model. Kami akan meneliti bagaimana maklumat mengalir melalui Codex, yang menggunakan Responses API untuk memacu gelung ejen.

Titik akhir API Respons yang digunakan oleh Codex CLI adalah boleh dikonfigurasikan⁠(dibuka dalam tetingkap baru), jadi ia boleh digunakan dengan mana-mana titik akhir yang melaksanakan Responses API⁠(dibuka dalam tetingkap baru):

Mari kita teroka bagaimana Codex mencipta prom untuk panggilan inferens pertama dalam perbualan.

Membina prom permulaan

Sebagai pengguna akhir, anda tidak menentukan prom yang digunakan untuk membuat sampel verbatim model secara verbatim apabila anda membuat pertanyaan kepada Responses API. Sebaliknya, anda menentukan pelbagai jenis input sebagai sebahagian daripada pertanyaan anda, dan pelayan Responses API memutuskan cara untuk menyusun maklumat ini ke dalam prom yang direka untuk digunakan oleh model. Anda boleh menganggap prom sebagai “senarai item”; bahagian ini akan menerangkan bagaimana pertanyaan anda diubah menjadi senarai tersebut.

Dalam prom awal, setiap item dalam senarai dikaitkan dengan satu peranan. Peranan menunjukkan sejauh mana kepentingan kandungan berkaitan dan merupakan salah satu daripada nilai berikut (dalam susunan keutamaan menurun): system, pemaju, pengguna, pembantu.

Responses API⁠(dibuka dalam tetingkap baru) mengambil muatan beban JSON dengan banyak parameter. Kami akan menumpukan kepada tiga perkara ini:

Dalam Codex, medan arahan dibaca daripada model_instructions_file⁠(dibuka dalam tetingkap baru) dalam ~/.codex/config.toml, jika dinyatakan; jika tidak, base_instructions yang berkaitan dengan model⁠(dibuka dalam tetingkap baru) akan digunakan. Arahan khusus model terdapat dalam repo Codex dan digabungkan ke dalam CLI (contohnya, gpt-5.2-codex_prompt.md⁠(dibuka dalam tetingkap baru)).

Medan alat adalah senarai definisi alat yang mengesahkan skema ditakrifkan oleh Responses API. Untuk Codex, ini termasuk alat yang disediakan oleh Codex CLI, alat yang disediakan oleh Responses API yang seharusnya tersedia untuk Codex, serta alat yang disediakan oleh pengguna, biasanya melalui pelayan 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
]

Akhir sekali, medan input dalam muatan beban JSON adalah senarai item. Codex memasukkan item berikut⁠(dibuka dalam tetingkap baru) ke dalam input sebelum menambah mesej pengguna:

1. Mesej dengan role=developer yang menerangkan medan ujian yang hanya terpakai kepada alat kekerang disediakan oleh Codex yang ditakrifkan dalam bahagian alat. Iaitu, alat lain, seperti yang disediakan daripada pelayan MCP, bukannya medan ujian oleh Codex dan bertanggungjawab untuk menguatkuasakan pengadang mereka sendiri.

Mesej ini dibina daripada templat di mana bahagian kandungan utama datang daripada petikan Markdown yang digabungkan ke dalam Codex CLI, seperti workspace_write.md⁠(dibuka dalam tetingkap baru) dan on_request.md⁠(dibuka dalam tetingkap baru):

Teks Biasa

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. (Pilihan) Mesej dengan role=developer yang kandungannya adalah nilai developer_instructions yang dibaca daripada fail config.toml pengguna.

3. (Pilihan) Mesej dengan role=user yang kandungannya ialah “arahan pengguna,” yang tidak bersumberkan daripada satu fail tetapi teragregat merentasi pelbagai sumber⁠(dibuka dalam tetingkap baru). Secara umum, arahan yang lebih terperinci akan muncul kemudian:

4. Mesej dengan role=user yang menerangkan persekitaran setempat di mana ejen sedang beroperasi pada masa ini. Ini menentukan direktori kerja semasa dan kekerang pengguna⁠(dibuka dalam tetingkap baru):

Teks Biasa

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

Setelah Codex selesai melakukan semua pengiraan di atas untuk memulakan input, ia menambahkan mesej pengguna untuk memulakan perbualan.

Contoh yang sebelumnya menumpukan pada kandungan setiap mesej, tetapi sila ambil perhatian bahawa setiap elemen input adalah objek JSON dengan jenis, peranan⁠(dibuka dalam tetingkap baru) dan kandungan seperti berikut:

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
}

Setelah Codex membina muatan beban JSON penuh untuk dihantar ke Responses API, ia kemudian membuat permintaan HTTP POST dengan pengepala Kebenaran bergantung pada cara titik akhir Responses API dikonfigurasikan dalam ~/.codex/config.toml (pengepala HTTP tambahan dan parameter pertanyaan ditambah jika dinyatakan).

Apabila pelayan Responses API OpenAI menerima permintaan, ia menggunakan JSON untuk mendapatkan prom bagi model seperti berikut (untuk memastikan, pelaksanaan tersuai Responses API mungkin membuat pilihan yang berbeza):

Gambar rajah snapshot yang menunjukkan satu langkah dalam gelung ejen AI. Permintaan pengguna memasuki model, yang menghasilkan pemikiran, tindakan dengan nama alat dan input alat. Gambar rajah ini menyerlahkan langkah penaakulan pertengahan ini sebelum alat dipanggil.

Seperti yang anda boleh lihat, susunan tiga item pertama dalam prom ditentukan oleh pelayan dan bukan pelanggan. Walau bagaimanapun, daripada tiga item tersebut, hanya kandungan mesej sistem juga dikawal oleh pelayan, kerana alat dan arahan ditentukan oleh klien. Ini diikuti oleh input daripada muatan beban JSON untuk melengkapkan prom.

Sekarang kami sudah mempunyai prom, kami bersedia untuk mengambil sampel model.

Giliran pertama

Permintaan HTTP ini kepada Responses API memulakan “giliran” pertama perbualan dalam Codex. Pelayan membalas dengan strim Acara Dihantar-Pelayan (SSE⁠(dibuka dalam tetingkap baru)). Data bagi setiap acara ialah muatan beban JSON dengan "jenis" yang bermula dengan "respons", yang mungkin seperti ini (senarai penuh acara boleh didapati dalam dokumen API⁠(dibuka dalam tetingkap baru) kami):

Teks Biasa

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

Codex menggunakan strim acara⁠(dibuka dalam tetingkap baru) dan menerbitkannya semula sebagai objek acara dalaman yang boleh digunakan oleh klien. Acara seperti response.output_text.delta digunakan untuk menyokong penstriman dalam UI, manakala acara lain seperti response.output_item.added ditukar menjadi objek yang ditambah kepada input untuk panggilan Responses API yang seterusnya.

Andai kata permintaan pertama kepada Responses API merangkumi dua acara response.output_item.done: satu dengan type=reasoning dan satu dengan type=function_call. Acara ini mesti diwakili dalam medan input JSON apabila kami menyoal model sekali lagi dengan respons kepada panggilan alat: 

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
]

Prom yang terhasil digunakan untuk membuat sampel model sebagai sebahagian daripada pertanyaan seterusnya akan kelihatan seperti ini:

Gambar rajah berlabel “Snapshot 2” menunjukkan ejen AI selepas panggilan alat. Model menerima pemerhatian alat dan menghasilkan pemikiran serta tindakan baharu. Anak panah menyambungkan input, pemerhatian dan output untuk menggambarkan bagaimana ejen mengulangi gelung penaakulan.

Terutamanya, perhatikan bagaimana prom lama merupakan awalan yang tepat bagi prom baharu. Ini disengajakan, kerana ini menjadikan permintaan seterusnya yang jauh lebih cekap kerana ia membolehkan kami memanfaatkan cache prom (yang akan kami bincangkan dalam bahagian seterusnya mengenai prestasi).

Melihat kembali pada gambar rajah pertama kami mengenai gelung ejen, kami mendapati bahawa mungkin terdapat banyak lelaran antara inferens dan panggilan alat. Prom mungkin terus berkembang sehingga akhirnya kami menerima mesej pembantu, menandakan penghujung giliran:

Teks Biasa

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

Dalam Codex CLI, kami memaparkan mesej pembantu kepada pengguna dan menumpukan komposer untuk menunjukkan kepada pengguna bahawa ini adalah “giliran” mereka untuk meneruskan perbualan. Jika pengguna memberikan respons, kedua-dua mesej pembantu daripada giliran yang sebelumnya dan mesej baharu pengguna mesti ditambahkan pada input dalam permintaan Responses API untuk memulakan giliran baharu:

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
]

Sekali lagi, disebabkan kami sedang meneruskan perbualan, panjang input yang kami hantar ke Responses API terus meningkat:

Gambar rajah berlabel “Snapshot 3” menunjukkan tahap akhir gelung ejen AI. Selepas menerima hasil alat, model menjana kesimpulan akhir dan jawapan akhir yang dikembalikan kepada pengguna. Anak panah menggambarkan peralihan daripada output alat ke respons yang lengkap.

Mari kita teliti apa maksud prom yang semakin berkembang ini untuk prestasi.

Pertimbangan prestasi

Anda mungkin bertanya kepada diri sendiri, “Tunggu sekejap, bukankah gelung ejen itu kuadratik dari segi jumlah JSON yang dihantar ke Responses API sepanjang perbualan?” Dan mungkin anda benar. Walaupun Responses API menyokong parameter pilihan previous_response_id⁠(dibuka dalam tetingkap baru) untuk mengurangkan isu ini, Codex tidak menggunakannya pada masa ini, terutamanya untuk memastikan permintaan kekal sepenuhnya tanpa keadaan dan menyokong konfigurasi Pengekalan Data Sifar (ZDR).

Mengelakkan previous_response_id memudahkan perkara untuk penyedia Responses API kerana ia memastikan setiap permintaan adalah tanpa keadaan. Ini juga memudahkan untuk menyokong pelanggan yang telah memilih Pengekalan Data Sifar (ZDR)⁠(dibuka dalam tetingkap baru), kerana menyimpan data yang diperlukan untuk menyokong previous_response_id akan bertentangan dengan ZDR. Harap maklum bahawa pelanggan ZDR tidak mengurangkan keupayaan untuk mendapat manfaat daripada mesej penaakulan proprietari daripada giliran sebelumnya, kerana encrypted_content yang berkaitan boleh dinyahsulit pada pelayan. (OpenAI menyimpan kunci penyahsulitan pelanggan ZDR, tetapi bukan data mereka.) Lihat PR #642⁠(dibuka dalam tetingkap baru) dan #1641⁠(dibuka dalam tetingkap baru) untuk perubahan berkaitan pada Codex untuk menyokong ZDR.

Secara amnya, kos pensampelan model mendominasi kos trafik rangkaian, menjadikan pensampelan sebagai sasaran utama dalam usaha kecekapan kami. Inilah sebabnya cache prom begitu penting, kerana ia membolehkan kami menggunakan semula pengiraan daripada panggilan inferens yang sebelumnya. Apabila kami mendapat cache hit, pensampelan model adalah linear dan bukannya kuadratik. Dokumentasi cache prom ⁠(dibuka dalam tetingkap baru)kami menerangkan tentang perkara ini dengan lebih terperinci:

Cache kena hanya boleh berlaku untuk padanan awalan yang tepat dalam prom. Untuk merealisasikan manfaat cache, letakkan kandungan statik seperti arahan dan contoh pada permulaan prom anda dan letakkan kandungan berubah-ubah, seperti maklumat khusus pengguna, pada penghujungnya. Ini juga terpakai kepada imej dan alat, yang mesti sama antara permintaan.

Dengan memikirkan tentang perkara ini, mari kita pertimbangkan jenis operasi yang boleh menyebabkan “cache terlepas” dalam Codex:

  • Menukar alat yang tersedia untuk model di tengah-tengah perbualan.
  • Menukar model yang menjadi sasaran permintaan Responses API (dilaksanakan, ini menukar item ketiga dalam prom asal, kerana ia mengandungi arahan khusus model).
  • Menukar konfigurasi medan ujian, mod kelulusan atau direktori kerja semasa.

Pasukan Codex mesti berwaspada apabila memperkenalkan ciri baharu dalam Codex CLI yang boleh menjejaskan cache prom. Sebagai contoh, sokongan awal kami untuk alat MCP telah memperkenalkan pepijat di mana kami gagal menyenaraikan alat dalam susunan yang konsisten⁠(dibuka dalam tetingkap baru), menyebabkan cache terlepas. Sila ambil perhatian bahawa alat MCP boleh menjadi sangat rumit kerana pelayan MCP boleh menukar senarai alat yang mereka sediakan dengan cepat melalui pemberitahuan notifications/tools/list_changed⁠(dibuka dalam tetingkap baru). Mematuhi pemberitahuan ini di tengah-tengah perbualan yang panjang boleh menyebabkan cache terlepas yang mahal.

Apabila boleh, kami mengendalikan perubahan konfigurasi yang berlaku di tengah-tengah perbualan dengan menambahkan mesej baharu pada input untuk mencerminkan perubahan tersebut dan bukannya mengubah suai mesej yang lebih awal:

Kami berusaha sedaya upaya untuk memastikan cache kena bagi meningkatkan prestasi. Terdapat satu lagi sumber utama yang perlu kita uruskan: tetingkap konteks.

Strategi umum kami untuk mengelakkan kehabisan tetingkap konteks adalah dengan memampatkan perbualan sebaik sahaja bilangan token melebihi ambang tertentu. Terutamanya, kami menggantikan input dengan senarai item baharu lebih kecil yang mewakili perbualan, membolehkan ejen meneruskan dengan pemahaman tentang apa yang telah berlaku setakat ini. Satu pelaksanaan pemampatan⁠(dibuka dalam tetingkap baru) awal memerlukan pengguna menggunakan arahan /compact secara manual, yang akan membuat pertanyaan kepada Responses API menggunakan perbualan sedia ada serta arahan tersuai untuk peringkasan⁠(dibuka dalam tetingkap baru). Codex menggunakan mesej pembantu terhasil yang mengandungi ringkasan sebagai input⁠(dibuka dalam tetingkap baru) baharu untuk giliran perbualan yang seterusnya.

Sejak itu, Responses API telah berkembang untuk menyokong titik akhir /respons/padat⁠(dibuka dalam tetingkap baru) khas yang melaksanakan pemadatan dengan lebih cekap. Ia mengembalikan senarai item⁠(dibuka dalam tetingkap baru) yang boleh digunakan sebagai ganti input sebelumnya untuk meneruskan perbualan sambil mengosongkan tetingkap konteks. Senarai ini termasuk item khas type=compaction dengan item legap encrypted_content yang mengekalkan pemahaman pendam model tentang perbualan asal. Kini, Codex menggunakan titik akhir ini untuk memampatkan perbualan secara automatik apabila auto_compact_limit⁠(dibuka dalam tetingkap baru) melebihi had.

Akan datang seterusnya

Kami telah memperkenalkan gelung ejen Codex dan menjelaskan bagaimana Codex membina dan mengurus konteksnya apabila membuat pertanyaan kepada model. Sepanjang proses itu, kami menekankan pertimbangan praktikal dan amalan terbaik yang terpakai kepada sesiapa sahaja yang membina gelung ejen di atas Responses API.

Walaupun gelung ejen menyediakan asas untuk Codex, ia hanya permulaan. Dalam siaran yang akan datang, kami akan menyelami seni bina CLI, meneroka bagaimana penggunaan alat dilaksanakan dan melihat model medan ujian Codex dengan lebih dekat.

Penulis

Michael Bolin

Penghargaan

Ucapan terima kasih istimewa kepada seluruh pasukan yang membangunkan Codex CLI.

Teruskan membaca

Lihat semua
Rockset > Art Card
Epidemiologi core dump: membaiki pepijat 18 tahun

Kejuruteraan

Tax Agent > Art Card
Membina ejen cukai yang menambah baik diri dengan Codex

Kejuruteraan

codex windows > art card
Membina persekitaran sandbox yang selamat dan berkesan untuk mendayakan Codex pada Windows

Kejuruteraan