Ringkasan Utama
Context engineering adalah disiplin mengatur token mana persisnya yang dilihat agen LLM di setiap langkah: system prompt, tools, data hasil retrieval, memory, dan history. Ia menggantikan prompt engineering untuk agen produksi pada 2025 karena mayoritas kegagalan agen adalah kegagalan konteks, bukan kegagalan model, dan membebani window justru menurunkan akurasi.
Selama dua tahun keahlian ini disebut prompt engineering, dan umumnya berarti memoles satu instruksi cerdas sampai sebuah chatbot berperilaku benar. Kerangka itu runtuh saat saya mulai mengirim agen yang berjalan ratusan giliran, memanggil tools, dan membaca dokumen. Ternyata susunan kata pada prompt hanyalah sebagian kecil dari penentu keberhasilan. Segala hal lain di dalam window, potongan hasil retrieval, output tools, riwayat percakapan, dan memory, jauh lebih menentukan.
Di tulisan ini saya bahas apa sebenarnya context engineering, mengapa istilahnya mengkristal pada 2025, cara-cara spesifik sebuah context window gagal, empat strategi yang saya pakai untuk menjaganya tetap sehat, dan angka-angka terpublikasi yang menunjukkan dampaknya. Setiap angka di sini bersumber dari primary source yang ditautkan di akhir.
Apa itu context engineering, dan mengapa istilahnya muncul pada 2025
Istilah ini populer pada Juni 2025. Pada 19 Juni, CEO Shopify Tobi Lutke menulis bahwa ia lebih suka context engineering daripada prompt engineering karena menggambarkan keahlian intinya dengan lebih baik: seni menyediakan seluruh konteks agar tugas masuk akal untuk diselesaikan oleh model. Enam hari kemudian, pada 25 Juni, Andrej Karpathy mendukungnya, menyebut context engineering sebagai seni dan sains yang cermat dalam mengisi context window dengan informasi yang tepat untuk langkah berikutnya. Pada September 2025 Anthropic menerbitkan panduan teknik yang mendefinisikannya sebagai strategi untuk menyusun dan menjaga kumpulan token yang optimal selama inferensi model.
Pergeseran pola pikir utamanya adalah prompt engineering kini menjadi bagian dari context engineering. Menulis instruksi yang baik tetap penting, tetapi dalam agen nyata ia hanya satu input di antara banyak input. Anthropic membingkai context engineering sebagai kelanjutan alami prompt engineering: alih-alih menyusun satu prompt, Anda mengelola seluruh keadaan informasi yang dilihat model di setiap giliran.
| Dimensi | Prompt engineering | Context engineering |
|---|---|---|
| Cakupan | Satu prompt yang ditulis tangan | Seluruh kumpulan token di setiap giliran |
| Unit kerja | Susunan kata satu instruksi | System prompt, tools, data retrieval, memory, history |
| Kapan berjalan | Sekali, sebelum pemanggilan | Terus-menerus, dibangun ulang di tiap langkah |
| Risiko kegagalan utama | Instruksi yang samar atau kikuk | Membebani window sampai recall menurun |
Bagaimana context window gagal
Konteks yang lebih panjang tidak otomatis lebih baik. Anthropic menyebutnya context rot: seiring jumlah token bertambah, kemampuan model mengingat informasi dari konteks itu secara akurat menurun, karena perhatian tersebar ke lebih banyak relasi antar-pasangan. Drew Breunig mencatat empat cara konkret konteks gagal, masing-masing dengan bukti dari studi publik.
- Poisoning: sebuah halusinasi atau kesalahan masuk ke konteks lalu terus dirujuk berulang kali. Sebuah agen Gemini yang memainkan Pokemon terus mengejar tujuan mustahil karena keadaan game yang keliru tetap tertahan di konteksnya.
- Distraction: konteks tumbuh begitu panjang sehingga model terlalu fokus padanya dan mengabaikan apa yang dipelajari saat pelatihan. Studi Databricks menemukan akurasi Llama 3.1 405b mulai menurun sekitar 32k token, jauh sebelum window penuh.
- Confusion: tools atau konten berlebih menarik kualitas ke bawah. Dalam satu benchmark, Llama 3.1 8b terkuantisasi gagal dengan 46 tools termuat tetapi berhasil ketika himpunannya dipangkas menjadi 19.
- Clash: informasi baru berbenturan dengan yang sudah ada. Studi Microsoft dan Salesforce menemukan model berkinerja 39 persen lebih buruk ketika informasi datang tersebar di beberapa giliran, dengan o3 milik OpenAI turun dari 98,1 ke 64,1.
Konteks lebih banyak bukan peningkatan gratis. Model dengan window sejuta token pun bisa kehilangan alur pada sebagian kecil dari batas itu, jadi perlakukan setiap token yang Anda tambahkan sebagai biaya, bukan fitur. Jika sebuah potongan tidak membantu langkah berikutnya, membuangnya biasanya justru memperbaiki jawaban.
Write, select, compress, isolate: empat strateginya
LangChain mengelompokkan teknik yang bekerja ke dalam empat kategori, dengan analogi yang berguna: context window itu seperti RAM, sumber daya terbatas yang dikurasi sistem operasi. Hampir semua yang saya lakukan di produksi memetakan ke salah satu dari empat kata kerja ini.
- Write: simpan informasi di luar window agar bertahan, memakai scratchpad untuk tugas saat ini atau memory persisten lintas sesi, lalu baca kembali hanya saat dibutuhkan.
- Select: tarik hanya token relevan sesuai kebutuhan. RAG atas dokumen dan bahkan atas deskripsi tools, ditambah identifier ringan yang dimuat tepat waktu alih-alih memuat semuanya di awal.
- Compress: pertahankan hanya token esensial. Ringkas giliran lama, pangkas pesan usang, dan proses ulang output tools yang besar. Claude Code melakukan auto-compact di sekitar 95 persen pemakaian window.
- Isolate: pisahkan konteks ke sub-agen atau sandbox. Sub-agen milik Anthropic masing-masing bekerja di window sendiri dan mengembalikan ringkasan padat sekitar 1.000 hingga 2.000 token ke agen utama.
Anggaran konteks, dalam kode
Berikut bentuk satu giliran agen ketika Anda memperlakukan konteks sebagai anggaran. Ia menulis inti kecil yang stabil, memilih hanya tools dan dokumen yang cocok dengan tujuan, lalu mengompres history begitu mendekati batas. Intinya, perakitan konteks adalah kode yang Anda miliki, dijalankan di setiap langkah, bukan prompt sekali jalan.
# One agent turn: assemble context under a fixed token budget
MAX_TOKENS = 180_000
COMPACT_AT = 0.95 # Claude Code auto-compacts near 95% utilization
def build_context(state):
# WRITE once, keep it small: system prompt + a few canonical examples
ctx = [state.system_prompt, *state.canonical_examples]
# SELECT: RAG over tool specs and docs — pull the few that fit the goal,
# not all 40 tools (more tools measurably lowers tool-call accuracy)
ctx += select_relevant(state.tools, state.goal, top_k=5)
# SELECT just-in-time: keep lightweight IDs, load full docs only on demand
ctx += retrieve(state.query, top_k=5)
ctx += state.recent_messages
# COMPRESS: if we near the budget, summarize the oldest turns and
# keep decisions, open bugs, and file paths — then drop the raw history
if count_tokens(ctx) > MAX_TOKENS * COMPACT_AT:
summary = summarize(state.older_messages,
keep=["decisions", "open_bugs", "file_paths"])
ctx = replace(ctx, state.older_messages, summary)
return ctx # ISOLATE heavy sub-tasks in sub-agents that return ~1-2k tokens
Saran praktis Anthropic: mulai dengan prompt terkecil pada model terbaik yang Anda punya, lalu tambahkan instruksi hanya di tempat Anda mengamati kegagalan nyata. Utamakan beberapa contoh kanonik yang beragam daripada daftar panjang kasus tepi. Konteks ramping yang Anda tumbuhkan dengan sengaja mengalahkan konteks bengkak yang Anda pangkas belakangan.
Hasil yang terukur
Alasan hal ini berhenti menjadi opsional adalah karena angkanya besar dan berulang. Penurunan 39 persen pada multi-giliran, skor o3 runtuh dari 98,1 ke 64,1, akurasi tools pulih ketika himpunan menyusut dari 46 ke 19, dan akurasi merosot di 32k token bukanlah kasus tepi. Itulah perilaku bawaan model yang mumpuni ketika diberi konteks yang buruk kurasinya.
Maka aturan saya ketika sebuah agen berperilaku aneh adalah memeriksa konteks sebelum menyalahkan model. Sembilan dari sepuluh kali solusinya adalah lebih sedikit tools, kueri retrieval yang lebih ketat, ringkasan dua puluh giliran terakhir, atau sub-agen untuk mengisolasi sub-tugas yang berisik. Context engineering adalah pekerjaan pipa yang tak glamor, dan ia adalah pekerjaan berdaya ungkit tertinggi dalam membangun agen yang tahan di produksi.

