Dari model ke agen: Membekali API Respons dengan lingkungan komputer

Saat ini kami sedang beralih dari penggunaan model, yang unggul dalam tugas-tugas tertentu, ke penggunaan agen yang mampu menangani alur kerja yang kompleks. Dengan memberikan prompt kepada model, Anda hanya dapat mengakses kecerdasan yang telah dilatih. Namun, memberikan model lingkungan komputer dapat mencapai rentang kasus penggunaan yang jauh lebih luas, seperti menjalankan layanan, meminta data dari API, atau menghasilkan artefak yang lebih berguna seperti spreadsheet atau laporan.

Beberapa masalah praktis muncul saat Anda mencoba membangun agen: di mana menaruh file perantara, bagaimana menghindari menempelkan tabel besar ke dalam prompt, bagaimana memberikan alur kerja akses jaringan tanpa menimbulkan masalah keamanan, dan bagaimana menangani batas waktu dan percobaan ulang tanpa membangun sistem alur kerja sendiri.

Alih-alih membebankan pengembang untuk membangun lingkungan eksekusi mereka sendiri, kami membangun komponen yang diperlukan untuk melengkapi API Respons⁠(terbuka di jendela baru) dengan lingkungan komputer agar dapat menjalankan tugas dunia nyata dengan andal.

API Respons dari OpenAI, bersama dengan alat shell dan workspace kontainer yang di-host, dirancang untuk mengatasi masalah praktis ini. Model mengusulkan langkah dan perintah; platform menjalankannya dalam lingkungan terpisah dengan filesystem untuk input dan output, penyimpanan terstruktur opsional (seperti SQLite), dan akses jaringan yang dibatasi. 

Dalam postingan ini, kami akan menguraikan bagaimana kami membangun lingkungan komputer untuk agen dan membagikan beberapa pelajaran awal tentang cara menggunakannya untuk alur kerja produksi yang lebih cepat, lebih dapat diulang, dan lebih aman.

Alur kerja agen yang baik dimulai dengan loop eksekusi yang rapat: model mengusulkan tindakan seperti membaca file atau mengambil data dengan API, platform menjalankannya, dan hasilnya menjadi masukan untuk langkah berikutnya. Kita akan mulai dengan alat shell—cara paling sederhana untuk melihat loop ini beraksi—lalu membahas workspace kontainer, jaringan, keterampilan yang dapat digunakan kembali, dan pemadatan konteks.

Untuk memahami alat shell, ada baiknya terlebih dahulu memahami bagaimana sebuah model bahasa menggunakan alat secara umum: untuk melakukan hal-hal seperti memanggil fungsi atau berinteraksi dengan komputer. Selama pelatihan, sebuah model diperlihatkan contoh cara alat digunakan dan efek yang dihasilkan, langkah demi langkah. Cara ini membantu model belajar memutuskan kapan harus menggunakan alat dan bagaimana menggunakannya. Saat kami mengatakan “menggunakan alat”, yang kami maksud adalah model sebenarnya hanya mengusulkan pemanggilan alat. Model tidak dapat mengeksekusi pemanggilan alat dengan sendirinya.

Alat shell membuat model menjadi jauh lebih andal: alat ini berinteraksi dengan komputer melalui baris perintah untuk menjalankan berbagai macam tugas, mulai dari mencari teks hingga mengirim permintaan API di komputer Anda. Dibangun di atas peralatan Unix yang sudah familiar, alat shell kami dapat melakukan apa pun yang Anda harapkan, dengan utilitas seperti grep, curl, dan awk tersedia secara bawaan.

Dibandingkan dengan penerjemah kode kami yang ada, yang hanya mengeksekusi Python, alat shell memungkinkan rentang kasus penggunaan yang jauh lebih luas, seperti menjalankan program Go atau Java atau memulai server NodeJS. Fleksibilitas ini memungkinkan model memenuhi tugas agen yang kompleks.

Dengan sendirinya, sebuah model hanya dapat mengusulkan perintah shell, tetapi bagaimana perintah ini dieksekusi? Kami memerlukan orkestrator untuk mendapatkan output model, memanggil alat, dan meneruskan respons alat kembali ke model dalam sebuah loop, hingga tugas selesai.

API Respons adalah cara pengembang berinteraksi dengan model OpenAI. Saat digunakan dengan alat kustom, API Respons mengembalikan kontrol kepada klien, dan klien memerlukan harness sendiri untuk menjalankan alat. Namun, API ini juga dapat mengorkestrasi antara model dan alat yang di-host secara langsung. 

Ketika API Respons menerima prompt, API tersebut menyusun konteks model: prompt pengguna, status percakapan sebelumnya, dan instruksi alat. Agar eksekusi shell berfungsi, prompt harus menyebutkan penggunaan alat shell dan model yang dipilih harus dilatih untuk mengusulkan perintah shell—model GPT‑5.2 dan yang lebih baru dilatih untuk ini. Dengan semua konteks ini, model kemudian memutuskan tindakan berikutnya. Jika memilih eksekusi shell, model mengembalikan satu atau beberapa perintah shell ke layanan API Respons. Layanan API meneruskan perintah tersebut ke runtime kontainer, melakukan streaming kembali output shell, dan memasukkannya ke model dalam konteks permintaan berikutnya. Model kemudian dapat memeriksa hasilnya, mengeluarkan perintah tindak lanjut, atau menghasilkan jawaban akhir. API Respons mengulangi loop ini hingga model mengembalikan penyelesaian tanpa perintah shell tambahan.

Saat API Respons mengeksekusi perintah shell, API ini mempertahankan koneksi streaming ke layanan kontainer. Saat output dihasilkan, API meneruskannya ke model hampir secara real time sehingga model dapat memutuskan apakah akan menunggu output lebih lanjut, menjalankan perintah lain, atau melanjutkan ke respons akhir.

Model dapat mengusulkan beberapa perintah shell dalam satu langkah, dan API Respons dapat mengeksekusinya secara bersamaan menggunakan sesi kontainer terpisah. Setiap sesi melakukan streaming output secara independen, dan API memultipleks stream tersebut kembali menjadi output alat terstruktur sebagai konteks. Dengan kata lain, loop agen dapat memparalelkan pekerjaan, seperti mencari file, mengambil data, dan memvalidasi hasil antara.

Ketika perintah melibatkan operasi file atau pemrosesan data, output shell dapat menjadi sangat besar dan menghabiskan anggaran konteks tanpa menambahkan sinyal yang berguna. Untuk mengendalikan hal ini, model menetapkan batas output per perintah. API Respons memberlakukan batas tersebut dan mengembalikan hasil terbatas yang mempertahankan awal dan akhir output, sambil menandai konten yang dihilangkan. Misalnya, Anda dapat membatasi output hingga 1.000 karakter, dengan awal dan akhir yang dipertahankan:

teks di awal ... 1000 karakter terpotong ... teks di akhir

Bersama-sama, eksekusi konkuren dan output terbatas membuat loop agen menjadi cepat sekaligus hemat konteks sehingga model dapat terus melakukan penalaran atas hasil yang relevan alih-alih kewalahan oleh log terminal mentah.

Salah satu potensi masalah dengan loop agen adalah bahwa tugas dapat berjalan untuk waktu yang lama. Tugas yang berjalan lama memenuhi jendela konteks, yang penting untuk menyediakan konteks lintas giliran dan lintas agen. Bayangkan seorang agen memanggil sebuah keterampilan, mendapatkan respons, menambahkan pemanggilan alat dan ringkasan penalaran—jendela konteks yang terbatas cepat terisi. Untuk menghindari hilangnya konteks penting saat agen terus berjalan, kita memerlukan cara untuk mempertahankan detail utama dan menghapus apa pun yang tidak relevan. Sebagai gantinya, alih-alih mengharuskan pengembang merancang dan memelihara sistem peringkasan atau sistem pembawa status kustom, kami menambahkan pemadatan bawaan di API Respons, yang dirancang agar selaras dengan cara model berperilaku dan cara model tersebut dilatih.

Model terbaru kami dilatih untuk menganalisis status percakapan sebelumnya dan menghasilkan item pemadatan yang mempertahankan status sebelumnya yang penting dalam representasi terenkripsi yang efisien token. Setelah pemadatan, jendela konteks berikutnya terdiri dari item pemadatan ini dan bagian bernilai tinggi dari jendela sebelumnya. Ini memungkinkan alur kerja berlanjut secara koheren melintasi batas jendela, bahkan dalam sesi multi-langkah yang diperluas dan digerakkan oleh alat. Codex mengandalkan mekanisme ini untuk mempertahankan tugas pengodean jangka panjang dan eksekusi alat secara iteratif tanpa menurunkan kualitas.

Pemadatan tersedia baik bawaan di server maupun melalui endpoint `/compact` yang berdiri sendiri. Pemadatan sisi server memungkinkan Anda mengonfigurasi ambang batas, dan sistem menangani waktu pemadatan secara otomatis, sehingga tidak perlu logika sisi klien yang kompleks. Ini memungkinkan jendela konteks input efektif yang sedikit lebih besar untuk menoleransi kelebihan kecil tepat sebelum pemadatan, sehingga permintaan yang mendekati batas masih dapat diproses dan dipadatkan alih-alih ditolak. Seiring pelatihan model terus berkembang, solusi pemadatan bawaan pun ikut berkembang untuk setiap rilis model OpenAI.

Codex membantu kami membangun sistem pemadatan sekaligus berperan sebagai pengguna awalnya. Saat satu instans Codex mengalami kesalahan pemadatan, kami akan menjalankan instans kedua untuk menyelidikinya. Hasilnya adalah Codex mendapatkan sistem pemadatan bawaan yang efektif hanya dengan mengerjakan masalah tersebut. Kemampuan Codex untuk memeriksa dan menyempurnakan dirinya sendiri ini telah menjadi bagian yang sangat menarik dari pengalaman bekerja di OpenAI. Sebagian besar alat hanya mengharuskan pengguna mempelajari cara menggunakannya; Codex belajar bersama kita.

Sekarang, mari kita bahas status dan sumber daya. Kontainer bukan hanya tempat untuk menjalankan perintah, tetapi juga konteks kerja untuk model. Di dalam kontainer, model dapat membaca file, melakukan kueri pada basis data, dan mengakses sistem eksternal di bawah kontrol kebijakan jaringan.

Bagian pertama dari konteks kontainer adalah sistem file untuk mengunggah, mengatur, dan mengelola sumber daya. Kami membangun API kontainer dan file⁠(terbuka di jendela baru) untuk memberi model peta data yang tersedia dan membantunya memilih operasi file yang terarah alih-alih melakukan pemindaian luas yang penuh noise.

Anti-pola yang umum adalah memasukkan semua input langsung ke dalam konteks prompt. Ketika input bertambah, mengisi prompt secara berlebihan menjadi mahal dan sulit dinavigasi oleh model. Pola yang lebih baik adalah menyiapkan sumber daya di sistem file kontainer dan membiarkan model memutuskan apa yang akan dibuka, diurai, atau ditransformasikan dengan perintah shell. Seperti halnya manusia, model bekerja lebih baik dengan informasi yang terorganisasi.

Bagian kedua dari konteks kontainer adalah basis data. Dalam banyak kasus, kami menyarankan pengembang menyimpan data terstruktur dalam basis data sebagai SQLite dan melakukan kueri terhadapnya. Daripada menyalin seluruh spreadsheet ke dalam prompt, misalnya, Anda dapat memberikan model deskripsi tabel—kolom apa saja yang ada dan apa artinya—dan membiarkannya menarik baris yang dibutuhkannya.

Sebagai contoh, jika Anda bertanya, “Produk mana yang mengalami penurunan penjualan pada kuartal ini?” model dapat melakukan kueri hanya pada baris yang relevan alih-alih memindai seluruh spreadsheet. Ini lebih cepat, lebih murah, lebih dapat ditingkatkan skalanya untuk set data yang lebih besar.

Bagian ketiga dari konteks kontainer adalah akses jaringan, yang merupakan bagian penting dari beban kerja agen. Alur kerja agen mungkin perlu mengambil data langsung, memanggil API eksternal, atau menginstal paket. Pada saat yang sama, memberikan akses internet tanpa batas kepada kontainer dapat berisiko: hal ini dapat mengekspos informasi ke situs web eksternal, tanpa sengaja menyentuh sistem internal yang sensitif atau sistem pihak ketiga, atau membuat kebocoran kredensial dan eksfiltrasi data lebih sulit untuk dilindungi.

Untuk mengatasi kekhawatiran ini tanpa membatasi kegunaan agen, kami membangun kontainer yang di-host untuk menggunakan proksi egress sidecar. Semua permintaan jaringan keluar mengalir melalui lapisan kebijakan terpusat yang menerapkan allowlist dan kontrol akses sambil menjaga lalu lintas tetap dapat diamati. Untuk kredensial, kami menggunakan injeksi rahasia bercakupan domain pada egress. Model dan kontainer hanya melihat placeholder, sementara nilai rahasia mentah tetap berada di luar konteks yang terlihat oleh model dan hanya diterapkan untuk tujuan yang disetujui. Cara ini mengurangi risiko kebocoran sambil tetap memungkinkan panggilan eksternal yang terautentikasi.

Perintah shell sangat andal, tetapi banyak tugas mengulang pola multi-langkah yang sama. Agen harus menemukan kembali alur kerja setiap kali dijalankan—merencanakan ulang, menerbitkan ulang perintah, dan mempelajari ulang konvensi—yang menyebabkan hasil yang tidak konsisten dan eksekusi yang terbuang. Keterampilan agen⁠(terbuka di jendela baru) mengemas pola-pola tersebut ke dalam blok pembangun yang dapat digunakan kembali dan dapat dikomposisikan. Secara konkret, sebuah keterampilan adalah bundel folder yang mencakup ‘SKILL.md⁠(terbuka di jendela baru)’ (berisi metadata dan instruksi) ditambah sumber daya pendukung apa pun, seperti spesifikasi API dan aset antarmuka pengguna.

Struktur ini memetakan secara alami ke arsitektur runtime yang kami jelaskan sebelumnya. Kontainer menyediakan file persisten dan konteks eksekusi, dan alat shell menyediakan antarmuka eksekusi. Dengan sudah tersedianya keduanya, model dapat menemukan file keterampilan menggunakan perintah shell (`ls`, `cat`, dll.) saat diperlukan, menafsirkan instruksi, dan menjalankan skrip keterampilan semuanya dalam loop agen yang sama.

Kami menyediakan API⁠(terbuka di jendela baru) untuk mengelola keterampilan di platform OpenAI. Pengembang mengunggah dan menyimpan folder keterampilan sebagai bundel berversi, yang nantinya dapat diambil berdasarkan ID keterampilan. Sebelum mengirim prompt ke model, API Respons memuat keterampilan dan menyertakannya dalam konteks model. Urutan ini bersifat deterministik:

1. Ambil metadata keterampilan, termasuk nama dan deskripsi.
2. Ambil bundel keterampilan, salin ke dalam kontainer, dan ekstrak.
3. Perbarui konteks model dengan metadata keterampilan dan jalur kontainer.

Saat memutuskan apakah suatu keterampilan relevan, model secara progresif mengeksplorasi instruksinya, dan mengeksekusi skripnya melalui perintah shell di dalam kontainer.

Untuk menyatukan semua bagiannya: API Respons menyediakan orkestrasi, alat shellmenyediakan tindakan yang dapat dieksekusi, kontainer yang di-host menyediakan konteks runtime persisten, keterampilan melapisi logika alur kerja yang dapat digunakan kembali, dan pemadatan memungkinkan agen berjalan dalam waktu lama dengan konteks yang dibutuhkannya.

Dengan elemen dasar ini, satu prompt dapat berkembang menjadi alur kerja dari awal hingga akhir: menemukan keterampilan yang tepat, mengambil data, mengubahnya menjadi status terstruktur lokal, melakukan kueri secara efisien, dan menghasilkan artefak yang tahan lama. 

Diagram di bawah ini menunjukkan cara kerja sistem ini untuk membuat spreadsheet dari data langsung.

Untuk contoh mendalam tentang menggabungkan alat shell dan lingkungan komputer untuk alur kerja menyeluruh dari awal hingga akhir, lihat postingan blog pengembang⁠(terbuka di jendela baru) dan cookbook⁠(terbuka di jendela baru) kami yang menjelaskan cara mengemas sebuah keterampilan dan menjalankannya melalui API Respons.

Kami sangat antusias untuk menyaksikan apa yang akan dibangun para pengembang dengan rangkaian elemen dasar ini. Model bahasa dibuat untuk melakukan lebih dari sekadar menghasilkan teks, gambar, dan audio–kami akan terus mengembangkan platform kami agar menjadi lebih mampu dalam menangani tugas-tugas dunia nyata yang kompleks dalam skala besar.