/goal Command: Cara Menjalankan Kode Codex dan Claude Sebagai Agen Otonom 24/7

Setiap laboratorium AI besar merilis primitif yang sama dalam enam minggu terakhir. Anthropic menambahkan /goal ke Claude Code. OpenAI merilisnya di dalam Codex CLI dan aplikasi desktop Codex. Nous Research mengintegrasikannya ke Hermes. Penamaan ini konsisten dengan sengaja; ini adalah industri yang menyepakati antarmuka bersama untuk satu hal: agen yang berjalan dalam lingkaran tertutup hingga kondisi akhir yang terukur tercapai, tanpa meminta izin Anda di setiap langkah.

Jika Anda selama ini melakukan tarian manual “setujui, kirim prompt, suruh agen melanjutkan, ulangi”, /goal adalah perintah slash yang mengakhirinya. Anda memberikan target kepada agen, ia bekerja mencapai target tersebut, dan ia kembali ketika target tercapai.

Panduan ini ditujukan untuk pengembang dan pembuat API. Kami akan membahas apa yang sebenarnya dilakukan /goal secara internal, cara mengaturnya di Codex dan Claude Code, struktur prompt yang menghasilkan hasil nyata alih-alih perulangan tak terbatas, dan cara mengintegrasikan semuanya ke dalam alur kerja API Anda menggunakan Apidog.

Unduh Apidog secara gratis jika Anda ingin mengikuti contoh API nanti dalam panduan ini.

Apa sebenarnya yang dilakukan /goal

Singkatnya: /goal memungkinkan agen AI melakukan perulangan pada suatu tugas hingga kondisi berhenti terpenuhi, tanpa harus bolak-balik meminta persetujuan Anda.

Mekanisme dasarnya sederhana. Sebuah model validator kecil dan cepat berjalan setelah setiap langkah yang diambil agen utama dan menjawab satu pertanyaan: “Apakah tujuan sudah tercapai?” Jika tidak, model utama terus berjalan. Jika ya, perulangan berakhir dan agen melaporkan hasilnya. Ini adalah pola yang sama dengan “Ralph loop” yang populer di awal tahun 2026, hanya saja sekarang ia disertakan sebagai perintah kelas satu di dalam alat resmi.

Perbedaan dengan penggunaan agen normal:

• Tanpa /goal: Anda adalah perulangan. Anda membaca output, memutuskan apakah itu benar, memberikan perintah untuk langkah selanjutnya, menyetujui panggilan alat, dan seterusnya. Setiap iterasi membutuhkan perhatian Anda.
• Dengan /goal: agen memiliki perulangan. Ia merencanakan, menjalankan, memvalidasi diri sendiri, dan hanya muncul ketika selesai, mencapai batasan, atau kehabisan anggaran.

Contoh konkret: memberitahu Claude Code /goal buat halaman landing memicu penelitian, kerangka kerja, penataan gaya, debugging, dan pratinjau akhir, semuanya dalam satu proses berkelanjutan. Anda pergi, kembali, dan kemudian merilisnya atau mengulanginya.

Mengapa ini tiba-tiba ada di mana-mana

Alasan mengapa /goal dirilis di berbagai vendor saat ini adalah karena tugas agen dengan horizon panjang sering gagal dalam dua cara yang dapat diprediksi:

1. Penyimpangan. Tanpa validator yang memeriksa target asli, model akan menyimpang dan menghasilkan output yang percaya diri tetapi salah.
2. Pengawasan berlebihan. Bahkan ketika model dapat melakukan pekerjaan, pengguna harus mengawasi setiap iterasi, yang mengalahkan tujuan dari sebuah agen.

Model validator kedua memperbaiki keduanya. Ini murah (model kecil, prompt sempit), dan memberikan kondisi berhenti yang pasti pada perulangan. Itulah seluruh triknya. Setelah laboratorium menyadari pola ini berhasil, mereka semua merilisnya dengan nama yang sama dalam beberapa minggu satu sama lain.

Mengatur /goal di Codex

Codex CLI memberi Anda kendali paling besar. Berikut adalah pengaturan minimum:

1. Aktifkan tujuan di aplikasi desktop: buka desktop Codex, buka Settings → Configuration, dan atur goals = true. CLI akan mewarisi pengaturan ini.
2. Jalankan CLI dalam mode full-auto agar Anda tidak lagi melihat prompt persetujuan:

codex --approval-mode full-auto

3. Tetapkan tujuan:

/goal [tujuan Anda di sini]

Itu saja. Codex akan mencetak konfirmasi bahwa tujuan telah terdaftar, lalu mulai berjalan.

Jika Anda non-teknis, mulailah di dalam aplikasi desktop Codex alih-alih CLI. Fungsionalitasnya sama, tetapi Anda mendapatkan antarmuka pengguna untuk menjeda, menghapus, dan memantau penggunaan token.

Mengatur /goal di Claude Code

Claude Code CLI bekerja hampir identik. Luncurkan CLI, ketik /goal, dan ikuti dengan deskripsi tugas. Dokumen resmi tersedia di situs dokumentasi Claude Code.

Jika Anda mengalami kesalahan pengaturan atau konfigurasi saat meluncurkan Claude Code, perbaikan konfigurasi enterprise custom3p yang tidak valid mencakup mode kegagalan yang paling umum. Untuk melihat lebih dalam tentang cara mengoperasikan Claude Code dengan alur kerja multi-agen bersama /goal, lihat ulasan kami tentang Ruflo, lapisan multi-agen di atas Claude Code.

Satu tip yang mudah terlewat: /goal menunjukkan jumlah token langsung dan bilah kemajuan untuk tugas yang sedang berjalan di dalam Claude Code. Perhatikan jumlah token, bukan hanya outputnya. Tujuan yang menghabiskan token tanpa kemajuan adalah tanda bahwa validator gagal mencapai konvergensi, dan Anda harus menekan /pause atau /goal clear.

Struktur prompt yang benar-benar berfungsi

Sintaks untuk /goal sangat mudah. Bagian yang sulit adalah menulis prompt yang menghasilkan hasil yang dapat digunakan alih-alih agen yang berjalan selama dua jam dan memberi Anda sesuatu yang sedikit salah.

Setiap prompt /goal yang efektif memiliki tiga komponen:

1. Pekerjaan: apa yang ingin Anda selesaikan, dalam satu baris.
2. Kondisi akhir yang terukur: seperti apa "selesai" itu, dalam bentuk yang dapat diperiksa oleh validator.
3. Batasan: aturan yang harus berlaku di seluruh proses.

Kerangkanya:

/goal [lakukan pekerjaan] sampai [kondisi akhir yang terukur] tanpa [batasan yang harus dipertahankan]

Contoh nyata untuk tugas coding:

/goal perbaiki setiap pengujian yang gagal hingga npm test keluar 0 tanpa mengubah file apa pun di luar direktori /auth

Kondisi akhir dapat diverifikasi (kode keluar npm test), dan batasan adalah batas keras yang dapat ditegakkan oleh validator di setiap iterasi. Agen tidak dapat memalsukan penyelesaian karena validator menjalankan perintah pengujian.

Untuk tugas-tugas yang ambigu (“buat UI ini terasa modern”), /goal berkinerja buruk karena kondisi akhir tidak dapat diukur. Ubah tujuan agar dapat diukur (“hingga skor aksesibilitas Lighthouse 90+”), atau tetap gunakan prompt normal.

Struktur lanjutan untuk tugas yang lebih panjang

Untuk tujuan yang lebih besar, perluas kerangka menjadi empat blok:

/goal
Tujuan: [tujuan satu baris]
Kriteria keberhasilan:
  - [kriteria terukur 1]
  - [kriteria terukur 2]
Batasan:
  - [batas 1]
  - [batas 2]
Konteks:
  - [file, repo, kunci API yang harus diketahui agen]

Format ini memberikan hal-hal konkret kepada validator untuk diperiksa pada setiap iterasi perulangan. Tanpa kriteria keberhasilan, validator akan kembali ke pencocokan semantik yang tidak jelas, dari situlah penyimpangan berasal.

Contoh yang patut ditiru

/goal tidak hanya untuk menulis kode. Beberapa pola yang berfungsi dengan baik:

Riset

/goal kumpulkan setiap benchmark publik untuk Claude Opus 4.7 yang diterbitkan sejak April 2026, simpan sumber, dan hasilkan tabel markdown yang diurutkan berdasarkan tanggal hingga tabel mencakup setidaknya 10 benchmark berbeda

Pemeliharaan Repo

/goal temukan kode mati, dependensi tidak terpakai, dan file usang di repo ini, lalu usulkan deskripsi PR yang mencantumkan penghapusan yang aman hingga setiap item memiliki justifikasi

Dokumentasi

/goal tulis ulang README.md agar kontributor baru dapat menginstal, menjalankan, menguji, dan memahami proyek hingga setiap dari empat langkah tersebut memiliki perintah yang berfungsi dan output yang diharapkan

Pekerjaan Fitur

/goal tambahkan tombol tema gelap/terang, pertahankan pilihan di localStorage, perbarui gaya untuk kedua tema, dan verifikasi di browser hingga tombol berfungsi tanpa memuat ulang halaman dan bertahan setelah refresh

Pola umumnya: setiap contoh menetapkan kondisi akhir yang dapat diverifikasi. Itulah garis pemisah antara tujuan yang selesai dan tujuan yang berputar-putar tanpa akhir.

Memasangkan /goal dengan alur kerja pengembangan API

Sebagian besar ulasan tentang /goal sejauh ini adalah tentang tugas pengkodean umum. Kasus penggunaan yang lebih menarik bagi insinyur backend dan platform adalah pekerjaan API, di mana kondisi akhir hampir selalu dapat diuji.

Endpoint API sangat cocok untuk /goal karena "selesai" tidak ambigu: permintaan mengembalikan 200, skema respons cocok, dan kontrak didokumentasikan. Anda dapat menulis tujuan yang mengatakan "buat endpoint ini lolos pengujiannya" dan validator memiliki sinyal konkret untuk dibaca.

Alur kerja yang berlaku dalam praktik:

1. Rancang kontrak terlebih dahulu di Apidog. Tentukan endpoint, skema permintaan, skema respons, dan contoh payload di dalam Apidog. Ini menjadi sumber kebenaran.
2. Ekspor spesifikasi. Apidog mengekspor OpenAPI 3.x, yang Anda berikan kepada Codex atau Claude Code sebagai konteks.
3. Jalankan /goal. Beri tahu agen: “implementasikan endpoint hingga setiap kasus pengujian Apidog lolos.”
4. Validator memeriksa test runner. Setiap iterasi perulangan, validator menjalankan pengujian Apidog CLI terhadap layanan yang sedang berjalan. Agen hanya selesai ketika setiap kasus berwarna hijau.

Ini secara material lebih baik daripada membiarkan agen menciptakan pengujiannya sendiri, karena kontrak sudah terkunci. Agen tidak dapat merilis rangkaian pengujian yang lolos tetapi melewatkan kasus-kasus khusus yang tercakup dalam spesifikasi.

Jika Anda belum pernah menggunakan Apidog sebelumnya, platform API ini menggabungkan desain, mocking, pengujian, dan dokumentasi dalam satu alat, yang penting di sini karena /goal bekerja paling baik ketika validator hanya perlu menjalankan satu perintah untuk memeriksa status. Panduan alur kerja API berbasis desain kami membahas pengaturan kontrak-pertama secara rinci, dan ikhtisar alat pengujian API untuk insinyur QA menunjukkan cara menyusun kasus pengujian yang akan diulang oleh agen.

Jika Anda bekerja dengan server MCP (protokol yang kini digunakan sebagian besar alat pengkodean AI untuk memanggil alat eksternal), pola yang sama berlaku. Lihat pengujian server MCP dengan Apidog untuk pengaturan yang memungkinkan agen /goal berjalan dengan aman terhadap server MCP lokal Anda.

Tips pro dari menjalankan /goal dalam produksi

Beberapa hal yang hanya Anda pelajari setelah menggunakan /goal dalam pekerjaan nyata:

• Satu tujuan pada satu waktu. Baik Codex maupun Claude Code membatasi Anda pada satu tujuan aktif. Mencoba menumpuknya akan menghasilkan keadaan yang aneh. Gunakan /goal clear di antara eksekusi.
• Pasangkan dengan /plan. Alur kerja yang berguna adalah /plan terlebih dahulu, tinjau rencana, lalu /goal dengan rencana sebagai konteks. Ini mengurangi jumlah iterasi hingga setengahnya karena agen tidak merancang ulang pendekatan di tengah perulangan.
• Gunakan file markdown sebagai catatan. Beri tahu agen untuk memelihara file progress.md. Anda mendapatkan jejak audit yang mudah dibaca dan agen mendapatkan konteks persisten di seluruh iterasi.
• Biarkan model menulis tujuannya sendiri. Masukkan ide kasar Anda ke dalam prompt normal dan minta model untuk mengubahnya menjadi pemanggilan /goal dengan kriteria keberhasilan. Model menulis prompt tujuan yang lebih baik daripada Anda, karena ia tahu apa yang sebenarnya dapat diperiksa oleh validator.
• Perhatikan validator, bukan model utama. Jika perulangan tidak menutup, masalahnya hampir selalu karena kriteria keberhasilan tidak terukur. Perketat kriteria, jangan mencoba lagi tujuan yang sama.
• /goal adalah untuk pekerjaan berjangka panjang. Untuk refaktor satu baris, prompt normal lebih cepat. Perulangan otonom memiliki overhead.

Kapan /goal akan mengecewakan Anda

Batasan jujur yang perlu diingat:

• Biaya. Perulangan yang berjalan selama satu jam menghabiskan lebih banyak token daripada tugas yang sama yang dilakukan secara manual. Tetapkan anggaran.
• Tugas tanpa sinyal. Poles UX, nada prosa, selera desain; tidak ada di antaranya yang memiliki validator yang jelas. Agen akan menyerah atau menciptakan kondisi berhenti palsu.
• Efek samping eksternal. Tujuan yang melibatkan pengiriman email, pembayaran, atau panggilan API produksi memerlukan batasan yang ketat. Agen tidak akan menyimpulkan kehati-hatian dengan sendirinya. Jika Anda masih membangun kontrol akses di sekitar agen AI yang memanggil API Anda, artikel tentang penggunaan dan API penagihan GitHub Copilot untuk tim membahas bagaimana vendor utama menangani hal ini.
• Konteks kedaluwarsa. Tujuan yang berjalan lama dapat menyimpang dari spesifikasi asli jika basis kode berubah di tengah perulangan. Jeda dan atur ulang daripada membiarkannya berlanjut dengan konteks lama.

Apa artinya ini untuk cara Anda membangun dengan AI

/goal adalah pergeseran dari “AI sebagai pelengkap otomatis” menjadi “AI sebagai pekerja yang Anda berikan arahan dan Anda periksa.” Perubahan antarmuka kecil (satu perintah slash), tetapi implikasinya besar: pekerjaan yang Anda lakukan sebagai pengembang bergerak ke arah menulis kriteria keberhasilan dan batasan yang lebih baik, dan menjauh dari mengetik baris kode yang sebenarnya.

Tim yang paling diuntungkan dari ini adalah mereka yang sudah memiliki kontrak yang dapat diuji, CI yang kuat, dan spesifikasi yang jelas. Jika API Anda memiliki dokumen OpenAPI yang terdefinisi dan rangkaian pengujian, Anda dapat memberikan agen /goal sebuah endpoint dan tenggat waktu. Jika API Anda hanya ada di benak seseorang, agen tidak memiliki apa pun untuk divalidasi dan perulangan akan berantakan.

Di sinilah platform API menjadi infrastruktur penopang untuk alur kerja AI. Apidog dibangun di sekitar pengembangan API berbasis desain-pertama, dan itu menjadi jauh lebih berguna ketika agen yang melakukan implementasi dapat membaca spesifikasi Anda dan memeriksa pekerjaannya sendiri terhadap kasus pengujian Anda. Unduh Apidog jika Anda ingin menyiapkan alur kerja kontrak-pertama yang dijelaskan di atas.

FAQ

Apakah /goal berfungsi di aplikasi web Codex? Ya. Ini berfungsi di Codex CLI, desktop Codex, aplikasi Codex, dan Claude Code CLI. Hermes juga mendukung perintah yang sama. Kesetaraan fitur di seluruh vendor adalah intinya.

Bagaimana /goal berbeda dari prompt biasa? Prompt biasa berjalan satu putaran dan berhenti. /goal berjalan dalam lingkaran tertutup dengan model validator yang memeriksa kondisi berhenti setelah setiap langkah. Agen yang memutuskan kapan harus berhenti, bukan Anda.

Bisakah agen melanggar batasan yang saya tetapkan? Validator menegakkan batasan pada setiap iterasi, jadi agen seharusnya tidak melanggarnya. Dalam praktiknya, semakin longgar frasa batasan, semakin banyak ruang bagi agen untuk menafsirkannya. Bersikaplah eksplisit: "tanpa memodifikasi file apa pun di luar /auth" dapat ditegakkan; "tanpa merusak apa pun" tidak.

Apakah /goal akan lebih mahal daripada sesi Claude atau Codex biasa? Ya. Harapkan untuk menghabiskan lebih banyak token. Validator berjalan pada model yang lebih murah dan lebih kecil, tetapi model utama masih melakukan pekerjaan, dan melakukannya lebih banyak secara otonom. Tetapkan anggaran atau gunakan /pause untuk mengontrol pengeluaran.

Bagaimana jika saya ingin menguji output agen terhadap API nyata? Gunakan alat seperti Apidog untuk mengunci kontrak API dan menjalankan kasus pengujian nyata terhadap implementasi. Validator agen dapat memanggil Apidog CLI, yang memberi Anda kondisi akhir yang terukur. Lihat panduan API Claude gratis jika Anda sedang memulai layanan bertenaga Claude dengan anggaran terbatas.