Langsung ke konten utama
OpenAI

23 Januari 2026

Teknik Rekayasa

Mengurai loop agen Codex

Oleh Michael Bolin, Anggota Staf Teknis

Memuat…

Codex CLI⁠(terbuka di jendela baru) adalah agen perangkat lunak lokal lintas platform yang dirancang untuk menghasilkan perubahan perangkat lunak berkualitas tinggi dan andal, sekaligus beroperasi secara aman dan efisien di mesin Anda. Kami telah mempelajari banyak hal tentang cara membangun agen perangkat lunak kelas dunia sejak pertama kali kami meluncurkan CLI pada bulan April⁠. Untuk menguraikan insight tersebut, ini adalah pos pertama dalam seri berkelanjutan di mana kami akan mengeksplorasi berbagai aspek tentang cara kerja Codex, serta pelajaran yang diperoleh dengan susah payah. (Untuk tampilan yang lebih terperinci tentang cara Codex CLI dibangun, kunjungi repositori sumber terbuka kami di https://github.com/openai/codex⁠(terbuka di jendela baru). Banyak detail yang lebih halus dari keputusan desain kami diabadikan dalam issue GitHub dan pull request jika Anda ingin mempelajari lebih lanjut.)

Sebagai langkah awal, kami akan berfokus pada agent loop, yaitu logika inti dalam Codex CLI yang bertugas mengorkestrasi interaksi antara pengguna, model, serta alat yang dipanggil model untuk melakukan pekerjaan perangkat lunak yang bermakna. Kami berharap postingan ini memberi Anda gambaran yang baik tentang peran yang dimainkan agen kami (atau “harness”) dalam memanfaatkan LLM.

Sebelum kita mulai, catatan singkat tentang terminologi: di OpenAI, “Codex” mencakup rangkaian penawaran agen perangkat lunak, termasuk Codex CLI, Codex Cloud, dan ekstensi Codex VS Code. Postingan ini berfokus pada Codex harness, yang menyediakan loop agen inti dan logika eksekusi yang mendasari semua pengalaman Codex dan ditampilkan melalui Codex CLI. Untuk memudahkan di sini, kami akan menggunakan istilah “Codex” dan “Codex CLI” secara bergantian.

Loop agen

Di inti dari setiap agen AI terdapat sesuatu yang disebut “loop agen.” Ilustrasi sederhana dari loop agen tampak seperti ini:

Diagram berjudul “Agent loop” yang menggambarkan bagaimana sistem AI memproses permintaan pengguna, memanggil alat, mengamati hasil, memperbarui rencananya, dan mengembalikan hasil. Panah menghubungkan langkah-langkah seperti masukan pengguna, penalaran model, tindakan alat, dan tanggapan akhir.

Untuk memulai, agen mengambil input dari pengguna untuk dimasukkan ke dalam kumpulan instruksi tekstual yang disiapkannya untuk model yang dikenal sebagai prompt.

Langkah berikutnya adalah melakukan kueri pada model dengan mengirimkan instruksi kami dan memintanya untuk menghasilkan respons, sebuah proses yang dikenal sebagai inferensi. Selama inferensi, prompt tekstual pertama-tama diterjemahkan menjadi urutan token⁠(terbuka di jendela baru)masukan—bilangan bulat yang mengindeks ke dalam kosakata model. Token-token ini kemudian digunakan untuk melakukan sampling pada model, menghasilkan urutan token keluaran yang baru.

Token output diterjemahkan kembali menjadi teks, yang kemudian menjadi respons model. Karena token diproduksi secara bertahap, terjemahan ini dapat terjadi saat model berjalan, itulah sebabnya banyak aplikasi berbasis LLM menampilkan output streaming. Dalam praktiknya, inferensi biasanya dienkapsulasi di balik API yang beroperasi pada teks, mengabstraksi detail tokenisasi.

Sebagai hasil dari langkah inferensi, model (1) menghasilkan respons akhir terhadap input asli pengguna, atau (2) meminta pemanggilan alat yang diharapkan untuk dilakukan oleh agen (misalnya, “jalankan ls dan laporkan outputnya”). Dalam kasus (2), agen mengeksekusi panggilan alat dan menambahkan hasilnya ke prompt asli. Output ini digunakan untuk menghasilkan input baru yang digunakan untuk mengajukan kueri ulang ke model; agen kemudian dapat mempertimbangkan informasi baru ini dan mencoba lagi.

Proses ini berulang hingga model berhenti mengeluarkan panggilan alat dan sebagai gantinya menghasilkan pesan untuk pengguna (disebut sebagai pesan asisten dalam model OpenAI). Dalam banyak kasus, pesan ini secara langsung menjawab permintaan awal pengguna, tetapi juga dapat berupa pertanyaan lanjutan untuk pengguna.

Karena agen dapat melakukan panggilan alat yang memodifikasi lingkungan lokal, “output”-nya tidak terbatas pada pesan asisten. Dalam banyak kasus, keluaran utama dari agen perangkat lunak adalah kode yang ditulis atau dieditnya di mesin Anda. Namun demikian, setiap giliran selalu diakhiri dengan pesan dari asisten—seperti “Saya menambahkan architecture.md yang Anda minta”—yang menandakan keadaan terminasi dalam loop agen. Dari sudut pandang agen, pekerjaannya telah selesai dan kendali kembali kepada pengguna.

Perjalanan dari input pengguna ke respons agen yang ditampilkan dalam diagram disebut sebagai satu giliran percakapan (sebuah utas di Codex). Meskipun giliran percakapan ini dapat mencakup banyak iterasi antara inferensi model dan pemanggilan alat. Setiap kali Anda mengirim pesan baru ke percakapan yang sudah ada, riwayat percakapan akan disertakan sebagai bagian dari prompt untuk giliran baru, yang mencakup pesan dan pemanggilan alat dari giliran sebelumnya:

Diagram berjudul “Multi-turn agent loop” yang menunjukkan bagaimana agen AI secara iteratif menerima masukan pengguna, menghasilkan tindakan, berkonsultasi dengan alat, memperbarui status, dan mengembalikan hasil. Mencakup langkah-langkah yang diberi label, panah, dan keluaran alat contoh yang menggambarkan siklus penalaran agen.

Ini berarti bahwa seiring percakapan berkembang, panjang prompt yang digunakan untuk mengambil sampel model juga bertambah. Panjang ini penting karena setiap model memiliki jendela konteks, yang merupakan jumlah token maksimum yang dapat digunakan untuk satu panggilan inferensi. Perhatikan bahwa jendela ini mencakup baik token masukan dan token output. Seperti yang mungkin Anda bayangkan, seorang agen dapat memutuskan untuk melakukan ratusan pemanggilan alat dalam satu giliran, yang berpotensi menghabiskan jendela konteks. Oleh karena itu, manajemen jendela konteks adalah salah satu dari banyak tanggung jawab agen. Sekarang, mari kita selami untuk melihat bagaimana Codex menjalankan loop agen.

Inferensi model

Codex CLI mengirimkan permintaan HTTP ke API Respons⁠(terbuka di jendela baru) untuk menjalankan inferensi model. Kami akan menelaah bagaimana informasi mengalir melalui Codex, yang menggunakan API Respons untuk menjalankan loop agen.

Endpoint API Respons yang digunakan oleh Codex CLI dapat dikonfigurasi⁠(terbuka di jendela baru), sehingga dapat digunakan dengan endpoint mana pun yang mengimplementasikan API Respons⁠(terbuka di jendela baru):

Mari kita jelajahi bagaimana Codex membuat prompt untuk panggilan inferensi pertama dalam sebuah percakapan.

Membangun prompt awal

Sebagai pengguna akhir, Anda tidak menentukan prompt yang digunakan untuk mengambil sampel model secara verbatim ketika Anda mengajukan kueri ke API Respons. Sebagai gantinya, Anda menentukan berbagai jenis input sebagai bagian dari kueri Anda, dan server API Respons memutuskan cara menyusun informasi ini menjadi prompt yang dirancang untuk dikonsumsi oleh model. Anda dapat menganggap prompt sebagai “daftar item”; bagian ini akan menjelaskan bagaimana kueri Anda diubah menjadi daftar tersebut.

Dalam prompt awal, setiap item dalam daftar dikaitkan dengan sebuah peran. Atribut role menunjukkan seberapa besar bobot yang harus dimiliki konten terkait dan merupakan salah satu dari nilai berikut (dalam urutan prioritas menurun): system, developer, user, assistant.

API Respons⁠(terbuka di jendela baru) menerima payload JSON dengan banyak parameter. Kami akan berfokus pada tiga hal ini:

Di Codex, kolom instructions dibaca dari model_instructions_file⁠(terbuka di jendela baru) di ~/.codex/config.toml, jika ditentukan; jika tidak, base_instructions yang terkait dengan model⁠(terbuka di jendela baru) digunakan. Instruksi khusus model terdapat di repo Codex dan dibundel ke dalam CLI (misalnya, gpt-5.2-codex_prompt.md⁠(terbuka di jendela baru)).

Kolom tools adalah daftar definisi alat yang sesuai dengan skema yang ditentukan oleh API Respons. Untuk Codex, ini mencakup alat yang disediakan oleh Codex CLI, alat yang disediakan oleh API Respons yang harus tersedia untuk Codex, serta alat yang disediakan oleh pengguna, biasanya melalui server 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
]

Akhirnya, bidang input dari payload JSON adalah daftar item. Codex menyisipkan item berikut⁠(terbuka di jendela baru) ke dalam input sebelum menambahkan pesan pengguna:

1. Pesan dengan role=developer yang menjelaskan sandbox yang hanya berlaku untuk alat shell yang disediakan Codex yang didefinisikan di bagian alat. Artinya, alat lain, seperti yang disediakan dari server MCP, tidak disandbox oleh Codex dan bertanggung jawab untuk menerapkan pembatas mereka sendiri.

Pesan dibangun dari templat di mana bagian-bagian utama konten berasal dari cuplikan Markdown yang dibundel ke dalam Codex CLI, seperti workspace_write.md⁠(terbuka di jendela baru) dan on_request.md⁠(terbuka di jendela baru):

Teks polos

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. (Opsional) Sebuah pesan dengan role=developer yang isinya adalah nilai developer_instructions yang dibaca dari file config.toml milik pengguna.

3. (Opsional) Sebuah pesan dengan role=user yang isinya adalah “instruksi pengguna,” yang tidak bersumber dari satu file tetapi dikumpulkan dari berbagai sumber⁠(terbuka di jendela baru). Secara umum, instruksi yang lebih spesifik akan muncul kemudian:

4. Sebuah pesan dengan role=user yang menjelaskan lingkungan lokal di mana agen saat ini beroperasi. Langkah ini menentukan direktori kerja saat ini dan shell pengguna⁠(terbuka di jendela baru):

Teks polos

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

Setelah Codex menyelesaikan semua komputasi di atas untuk menginisialisasi input, Codex menambahkan pesan pengguna untuk memulai percakapan.

Contoh-contoh sebelumnya berfokus pada konten setiap pesan, tetapi harap dicatat bahwa setiap elemen dari input adalah objek JSON dengan type, role⁠(terbuka di jendela baru), dan content sebagai 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 menyusun payload JSON lengkap untuk dikirim ke API Respons, Codex kemudian membuat permintaan HTTP POST dengan header Authorization bergantung pada bagaimana endpoint API Respons dikonfigurasi di ~/.codex/config.toml (header HTTP tambahan dan parameter kueri ditambahkan jika ditentukan).

Ketika server API Respons OpenAI menerima permintaan, server tersebut menggunakan JSON untuk menghasilkan prompt bagi model sebagai berikut (untuk memastikan, implementasi kustom API Respons dapat membuat pilihan yang berbeda):

Diagram snapshot yang menunjukkan satu langkah dalam loop agen AI. Permintaan pengguna masuk ke model, yang menghasilkan pemikiran, tindakan dengan nama alat, dan masukan alat. Diagram ini menyoroti langkah penalaran menengah sebelum alat dipanggil.

Seperti yang dapat Anda lihat, urutan tiga item pertama dalam prompt ditentukan oleh server, bukan klien. Namun demikian, dari ketiga item tersebut, hanya konten dari system message yang juga dikendalikan oleh server, karena tools dan instructions ditentukan oleh klien. Ini diikuti oleh input dari payload JSON untuk menyelesaikan prompt.

Sekarang setelah kami memiliki prompt kami, kami siap untuk melakukan sampling pada model.

Giliran pertama

Permintaan HTTP ini ke API Respons memulai putaran pertama dari sebuah percakapan di Codex. Server memberikan balasan dengan aliran Server-Sent Events (SSE⁠(terbuka di jendela baru)). Data dari setiap event adalah payload JSON dengan "type" yang dimulai dengan "response", yang bisa berupa sesuatu seperti ini (daftar lengkap event dapat ditemukan di API docs⁠(terbuka di jendela baru) kami):

Teks polos

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 mengonsumsi aliran peristiwa⁠(terbuka di jendela baru) dan menerbitkannya kembali sebagai objek peristiwa internal yang dapat digunakan oleh klien. Peristiwa seperti response.output_text.delta digunakan untuk mendukung streaming di UI, sedangkan peristiwa lain seperti response.output_item.added diubah menjadi objek yang ditambahkan ke input untuk panggilan API Respons berikutnya.

Misalkan permintaan pertama ke API Respons menyertakan dua peristiwa response.output_item.done: satu dengan type=reasoning dan satu dengan type=function_call. Peristiwa ini harus direpresentasikan dalam bidang input dari JSON ketika kami mengkueri model lagi dengan respons terhadap pemanggilan 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
]

Prompt yang dihasilkan untuk melakukan sampling pada model sebagai bagian dari kueri berikutnya akan tampak seperti ini:

Diagram berlabel “Snapshot 2” yang menunjukkan agen AI setelah pemanggilan alat. Model menerima observasi alat dan menghasilkan pemikiran serta tindakan baru. Panah menghubungkan masukan, pengamatan, dan keluaran untuk mengilustrasikan bagaimana agen mengulangi siklus penalarannya.

Secara khusus, perhatikan bagaimana prompt lama adalah awalan yang persis dari prompt baru. Ini memang disengaja, karena hal ini membuat permintaan berikutnya jauh lebih efisien karena memungkinkan kami memanfaatkan prompt caching (yang akan kita bahas di bagian selanjutnya tentang kinerja).

Melihat kembali diagram pertama kami tentang loop agen, kita dapat melihat bahwa mungkin ada banyak iterasi antara inferensi dan pemanggilan alat. Prompt dapat terus bertambah hingga akhirnya kami menerima pesan asisten, yang menunjukkan akhir dari giliran:

Teks polos

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

Di Codex CLI, kami menampilkan pesan asisten kepada pengguna dan memfokuskan komposer untuk menunjukkan kepada pengguna bahwa ini adalah “giliran” Anda untuk melanjutkan percakapan. Jika pengguna merespons, baik pesan asisten dari giliran sebelumnya maupun pesan baru pengguna harus ditambahkan ke input dalam permintaan API Respons untuk memulai giliran baru:

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, karena kami melanjutkan percakapan, panjang input yang kami kirim ke API Respons terus bertambah:

Diagram berlabel “Snapshot 3” yang menunjukkan tahap akhir dari loop agen AI. Setelah menerima hasil dari alat, model menghasilkan pemikiran penutup dan jawaban akhir yang dikembalikan kepada pengguna. Panah menggambarkan peralihan dari keluaran alat ke respons yang sudah selesai.

Mari kita telaah apa arti dari prompt yang terus berkembang ini bagi kinerja.

Pertimbangan kinerja

Anda mungkin bertanya-tanya, “Tunggu, bukankah loop agen kuadratik dalam hal jumlah JSON yang dikirim ke API Respons selama percakapan?” Dan Anda bisa jadi benar. Meskipun API Respons mendukung parameter opsional previous_response_id⁠(terbuka di jendela baru) untuk mengurangi masalah ini, Codex tidak menggunakannya saat ini, terutama untuk menjaga agar permintaan tetap sepenuhnya tanpa status dan untuk mendukung konfigurasi retensi data nol (ZDR).

Menghindari previous_response_id menyederhanakan proses bagi penyedia API Respons karena memastikan bahwa setiap permintaan bersifat stateless. Ini juga memudahkan untuk mendukung pelanggan yang telah memilih Retensi Data Nol (ZDR)⁠(terbuka di jendela baru), karena menyimpan data yang diperlukan untuk mendukung previous_response_id akan bertentangan dengan ZDR. Perhatikan bahwa pelanggan ZDR tidak mengorbankan kemampuan untuk mendapatkan manfaat dari pesan penalaran eksklusif dari giliran sebelumnya, karena encrypted_content terkait dapat didekripsi di server. (OpenAI menyimpan kunci dekripsi pelanggan ZDR, tetapi bukan data mereka.) Lihat PR #642⁠(terbuka di jendela baru) dan #1641⁠(terbuka di jendela baru) untuk perubahan terkait pada Codex untuk mendukung ZDR.

Secara umum, biaya pengambilan sampel model lebih besar daripada biaya lalu lintas jaringan, menjadikan pengambilan sampel sebagai target utama upaya efisiensi kami. Inilah alasan mengapa caching prompt sangat penting, karena hal ini memungkinkan kita untuk menggunakan kembali komputasi dari panggilan inferensi sebelumnya. Ketika kami mendapatkan cache hit, pengambilan sampel model bersifat linear, bukan kuadratik. Dokumentasi prompt caching ⁠(terbuka di jendela baru)kami menjelaskan hal ini secara lebih detail:

Cache hit hanya mungkin terjadi untuk kecocokan prefiks yang persis dalam sebuah prompt. Untuk menyadari manfaat caching, tempatkan konten statis seperti instruksi dan contoh di awal prompt Anda, dan letakkan konten variabel, seperti informasi khusus pengguna, di bagian akhir. Hal ini juga berlaku untuk gambar dan alat, yang harus identik di antara permintaan.

Dengan mengingat hal ini, mari kita pertimbangkan jenis operasi apa yang dapat menyebabkan “cache miss” di Codex:

  • Mengubah tools yang tersedia untuk model di tengah percakapan.
  • Mengubah model yang menjadi target permintaan Responses API (dalam praktiknya, ini mengubah item ketiga dalam prompt asli, karena berisi instruksi spesifik untuk model).
  • Mengubah konfigurasi sandbox, mode persetujuan, atau direktori kerja saat ini.

Tim Codex harus berhati-hati dan teliti saat memperkenalkan fitur baru di Codex CLI yang berpotensi mengganggu mekanisme prompt caching. Sebagai contoh, dukungan awal kami untuk alat MCP memperkenalkan bug di mana kami gagal mengurutkan alat tersebut secara konsisten⁠(terbuka di jendela baru), yang menyebabkan cache miss. Perhatikan bahwa alat MCP bisa sangat rumit karena server MCP dapat mengubah daftar alat yang mereka sediakan secara dinamis melalui notifikasi notifications/tools/list_changed⁠(terbuka di jendela baru). Menghormati notifikasi ini di tengah percakapan panjang dapat menyebabkan cache miss yang mahal.

Jika memungkinkan, kami menangani perubahan konfigurasi yang terjadi di tengah percakapan dengan menambahkan pesan baru ke input untuk mencerminkan perubahan tersebut, daripada memodifikasi pesan sebelumnya:

Kami berupaya keras untuk memastikan cache hit demi kinerja. Ada sumber daya utama lain yang harus kita kelola: jendela konteks.

Strategi umum kami untuk menghindari kehabisan jendela konteks adalah dengan memadatkan percakapan setelah jumlah token melebihi ambang batas tertentu. Secara khusus, kami mengganti input dengan daftar item baru yang lebih kecil yang mewakili percakapan, memungkinkan agen untuk melanjutkan dengan pemahaman tentang apa yang telah terjadi sejauh ini. Implementasi awal pemadatan⁠(terbuka di jendela baru) mengharuskan Anda untuk memanggil perintah /compact secara manual, yang akan melakukan kueri ke Responses API menggunakan percakapan yang ada ditambah instruksi khusus untuk peringkasan⁠(terbuka di jendela baru). Codex menggunakan pesan asisten yang dihasilkan yang berisi ringkasan sebagai input⁠(terbuka di jendela baru) baru untuk giliran percakapan berikutnya.

Sejak saat itu, API Respons telah berkembang untuk mendukung /responses/compact endpoint⁠(terbuka di jendela baru) khusus yang melakukan pemadatan lebih efisien. Langkah ini mengembalikan daftar item⁠(terbuka di jendela baru) yang dapat digunakan sebagai pengganti input sebelumnya untuk melanjutkan percakapan sambil membebaskan jendela konteks. Daftar ini mencakup item khusus type=compaction dengan item encrypted_content yang tidak transparan yang mempertahankan pemahaman laten model tentang percakapan asli. Sekarang, Codex secara otomatis menggunakan endpoint ini untuk memadatkan percakapan ketika auto_compact_limit⁠(terbuka di jendela baru) terlampaui.

Berikutnya

Kami telah memperkenalkan loop agen Codex dan menjelaskan bagaimana Codex menyusun dan mengelola konteksnya saat melakukan kueri ke model. Sepanjang perjalanan, kami menyoroti pertimbangan praktis dan praktik terbaik yang berlaku bagi siapa pun yang membangun loop agen di atas API Respons.

Meskipun loop agen menyediakan fondasi bagi Codex, ini baru permulaan. Dalam postingan mendatang, kami akan menggali lebih dalam arsitektur CLI, mengeksplorasi bagaimana penggunaan alat diterapkan, dan melihat lebih dekat model sandboxing Codex.

Penulis

Michael Bolin

Ucapan Terima Kasih

Terima kasih khusus kepada seluruh tim yang telah membangun Codex CLI.

Terus membaca

Lihat semua
Tax Agent > Art Card
Membangun agen pajak yang meningkatkan diri dengan Codex

Teknik Rekayasa

codex windows > art card
Membangun sandbox yang aman dan efektif untuk mengaktifkan Codex di Windows

Teknik Rekayasa

MRC 1_1
Supercomputer networking to accelerate large scale AI training

Teknik Rekayasa