Rekayasa konteks untuk agen AI jangka panjang

Jika digabungkan, analisis Arize, makalah arXiv tentang context window overflow, penjelasan produksi dari Redis, dan perbandingan rekayasa harness dari Atlan menunjukkan pergeseran praktis dalam desain agen. Agen yang berjalan lama kini lebih dinilai dari lapisan kontrol di sekeliling context window model, bukan dari ukuran context window model itu sendiri. Arize membuat pergeseran itu konkret. Mereka menyebut tool agen dan sistem memori/harness yang sudah dirilis, termasuk Pi, OpenClaw, Claude Code, dan Letta, sebagai contoh rekayasa konteks di level harness, serta menggambarkan simulator interaktif yang menunjukkan window 200K token terisi.

Detail publik yang tersedia dalam sumber yang dikutip tidak merata. Arize memberikan angka implementasi konkret untuk Pi, OpenClaw, Claude Code, dan Letta. Sebuah makalah riset tentang menyelesaikan context window overflow pada agen AI memberikan mekanisme yang lebih umum untuk menangani output tool yang dapat melampaui window praktis apa pun. Penjelasan Redis tentang context window overflow merangkum gejala produksi: error API yang keras, degradasi kualitas yang diam-diam, akumulasi output tool, dan latensi yang lebih panjang saat prompt membesar. Perbandingan Atlan tentang rekayasa prompt, konteks, dan harness memberikan metafora stack yang berguna: rekayasa prompt membentuk pesan, rekayasa konteks membentuk apa yang dilihat model, dan rekayasa harness membentuk seluruh lingkungan agen.

Kabar pentingnya bukan bahwa context window terlalu kecil. Para builder sudah tahu itu. Poin yang lebih berguna adalah bahwa sistem agen yang dikutip mulai berkonvergensi pada empat mekanisme harness yang menjaga pekerjaan tetap hidup setelah transkrip berhenti menjadi sumber kebenaran yang aman.

Agen yang dangkal membaca file, memanggil tool, menambahkan hasilnya, lalu berharap model bisa mengatasinya. Agen yang mengutamakan harness memblokir atau membentuk ulang input besar sebelum mencapai model.

Cara yang lebih bersih untuk membaca rangkaian batas pertama adalah:

• Pi: pembacaan file berhenti pada 2.000 baris atau 50KB, mana pun yang tercapai lebih dulu. Konten yang dikembalikan menyertakan petunjuk lanjutan yang memberi tahu model rentang baris mana yang ditampilkan dan cara melanjutkan dengan offset dan limit. OpenClaw mewarisi perilaku itu, lalu menambahkan batas terpisah: file bootstrap dibatasi hingga 12.000 karakter per file dan total 60.000 karakter. Hasil tool mendapat budget lain sebesar 16.000 karakter atau 30% dari context window, mana pun yang lebih kecil.

Claude Code menggunakan desain dua gerbang. Menurut Arize, ia memeriksa batas byte 256KB sebelum membuka file, lalu menghitung token hasilnya terhadap budget 25.000 token setelah pembacaan. Bahkan untuk file yang berada di bawah batas, default-nya mengembalikan 2.000 baris dari awal, dan memotong baris yang lebih panjang dari 2.000 karakter. Jika model membaca ulang rentang file yang sama dan file belum berubah, Claude Code dapat mengembalikan stub alih-alih mengulang konten penuh.

Itu bukan sekadar optimasi. Itu mengubah mode kegagalan. Alih-alih membiarkan satu pembacaan besar menggeser tugas, harness mengubah “baca semuanya” menjadi “baca irisan yang terkendali.” Jika model membutuhkan lebih banyak, ia bisa memintanya. Untuk builder yang merancang harness agen dari nol, ini adalah garis pertahanan pertama: jangan pernah membiarkan data eksternal mentah menjadi transkrip secara default.

Pola berikutnya adalah memperlakukan konteks seperti viewport, bukan storage.

Pi dan Claude Code mengekspos paginasi melalui offset dan limit. OpenClaw menambahkan pemotongan head/tail di beberapa tempat, mempertahankan bagian awal dan akhir ketika bagian tengah cenderung kurang penting. Arize mengatakan OpenClaw menggunakan pembagian 75% head / 25% tail untuk file bootstrap yang terlalu besar, dan dapat mempertahankan head sekaligus tail untuk hasil tool ketika tail terlihat penting, seperti error, kurung kurawal penutup JSON, atau kata kunci yang menyerupai ringkasan.

Letta melangkah lebih jauh dengan membuat file hidup di luar prompt. File yang diunggah diurai, dipecah menjadi chunk, dan di-embed ke dalam vector store, sehingga agen mendapat tampilan langsung, pencarian persis, dan pencarian semantik. Ketika sebuah file terbuka dalam konteks, Letta menampilkan tampilan terkelola yang ukurannya mengikuti konteks model: 5.000 karakter untuk konteks 8K, 15.000 untuk 32K, 25.000 untuk 128K, dan 40.000 untuk 200K+. Jumlah file yang bisa dibuka secara bersamaan juga ikut meningkat, dari 3 untuk model kecil hingga 15 untuk model yang sangat besar, dengan kebijakan LRU yang mengeluarkan file yang paling lama tidak diakses.

Ini adalah ide desain yang sama di balik RAG produksi: jangan jejalkan seluruh korpus ke dalam prompt; ambil bagian yang penting. Bedanya, harness agen harus melakukannya terus-menerus, lintas file, output tool, memori, dan rencana perantara. Batasan yang sama berlaku untuk sistem RAG: retrieval bukan hanya soal relevansi, tetapi juga soal mempertahankan budget konteks yang cukup untuk langkah penalaran sebenarnya.

Redis menyampaikan poin terkait: context window yang lebih besar tidak menghilangkan kebutuhan akan manajemen konteks. System prompt, dokumen yang diambil, riwayat percakapan, dan output tool semuanya berebut ruang yang sama. Bahkan sebelum batas keras tercapai, model dapat menurun kualitasnya ketika informasi relevan terkubur dalam input yang panjang.

Overflow adalah kegagalan yang jelas. Goal loss lebih senyap. Agen masih punya ruang untuk merespons, tetapi ia melupakan tujuan awal, melewatkan batasan, atau mulai mengoptimalkan sub-tugas lokal.

Di situlah kompaksi menjadi penting. Jika dilakukan dengan buruk, peringkasan mengganti riwayat yang berantakan tetapi setia dengan cerita yang rapi tetapi kehilangan detail. Jika dilakukan dengan baik, ia mempertahankan state tugas, pekerjaan terbaru, item tertunda, dan integritas pemanggilan tool.

Arize melaporkan bahwa Pi memicu kompaksi ketika estimasi token konteks melebihi context window dikurangi token cadangan, dengan cadangan default 16.384 token. Ia mempertahankan kira-kira 20.000 token terbaru dan meringkas konten yang lebih lama ke dalam pesan pengguna sintetis yang diletakkan sebelum tail yang dipertahankan. Ia juga menghindari pemotongan di antara pasangan tool-call/tool-result.

OpenClaw menambahkan kebijakan riwayat yang lebih agresif. Ketika riwayat melebihi 50% dari context window, ia membagi pesan menjadi chunk token dengan massa yang setara, membuang chunk tertua, meringkas konten yang dibuang melalui peringkasan multi-pass bertahap, dan memperbaiki pasangan tool-call/result. Ia juga melakukan pre-compaction flush: satu giliran agentic yang senyap memberi agen kesempatan untuk menyimpan state ke file memori sebelum riwayat menghilang. Secara terpisah, ia memangkas hasil tool di memori dengan perilaku soft-trim dan hard-clear pada cache TTL 5 menit.

Claude Code melakukan kompaksi mendekati ujung window. Arize mengatakan pemicunya adalah context window efektif dikurangi buffer 13.000 token, yang menempatkan kompaksi di sekitar 167K token untuk model dengan konteks 200K. Prompt peringkasannya meminta bagian terstruktur yang mencakup permintaan utama, konsep teknis, file dan kode, error dan perbaikan, pemecahan masalah, pesan pengguna, tugas tertunda, pekerjaan saat ini, dan langkah berikutnya. Setelah kompaksi, ia dapat memasang kembali hingga 5 file yang baru-baru ini dibaca dalam sebuah budget token.

Polanya jelas: kompaksi bukan “meringkas chat.” Kompaksi adalah checkpointing. Agen yang berjalan lama membutuhkan padanan save file: tujuan, batasan, keputusan, handle terbuka, bukti terbaru, dan aksi berikutnya.

Sebagian output seharusnya tidak pernah ditempatkan di context window sama sekali.

Makalah arXiv membuat ini konkret dengan workflow ilmu material. Satu tool menghasilkan struktur grid elektronik untuk sebuah molekul: matriks 3D berdimensi 128 × 128 × 128, dengan total 2.097.152 elemen float32. Output itu jauh melampaui context window LLM yang banyak digunakan. Namun tool berikutnya membutuhkan grid tersebut sebagai input.

Solusi yang diusulkan adalah menyimpan nilai besar di luar konteks model dan mengembalikan identifier singkat, atau pointer. Wrapper tool memeriksa input untuk melihat apakah input tersebut berupa nilai mentah atau path memori. Output yang terlalu besar disimpan di memori runtime di bawah sebuah path, dan tool berikutnya dapat menerima pointer lalu me-resolve-nya secara internal. Model memanipulasi referensi, sementara harness mempertahankan data lengkap. Dalam satu eksperimen komparatif ketika kedua metode berhasil, pendekatan berbasis pointer menggunakan sekitar tujuh kali lebih sedikit token dibandingkan workflow tradisional, menurut makalah tersebut.

Ini adalah pemisahan paling bersih antara penalaran dan transport data. Model tidak perlu “melihat” matriks 2 juta elemen untuk meneruskannya ke tool lain. Model perlu tahu bahwa matriks itu ada, apa yang diwakilinya, dan operasi mana yang harus menggunakannya berikutnya.

Logika yang sama berlaku di luar array ilmiah. Respons JSON besar, PDF, log, embedding, file media, dan ekspor database sering kali lebih cocok berada di storage, bukan di prompt. Untuk sistem yang dibangun di sekitar tool MCP atau connector API kustom, penerusan pointer seharusnya menjadi pilihan desain kelas satu, bukan tambalan setelah overflow pertama.

Context window 200K token terasa besar sampai agen mulai bertindak. System prompt, definisi tool, beberapa dokumen yang diambil, pembacaan file, log, jejak error, dan ringkasan dapat menghabiskannya lebih cepat dari dugaan. Kerangka praktisnya bukan seberapa besar window terlihat di atas kertas, tetapi seberapa cepat agen membelanjakannya saat runtime. Panduan memori agen dari Redis mengarah pada memori eksternal yang tahan lama untuk state yang harus bertahan lintas pemanggilan, sementara pembingkaian rekayasa konteks dari Atlan memisahkan prompt yang lebih baik dari perakitan konteks yang lebih baik. Jika digabungkan, keduanya memperlakukan context window bukan seperti gudang, melainkan seperti working set yang terbatas.

Pelajaran yang lebih dalam adalah bahwa context window adalah sumber daya runtime yang langka. Memperlakukannya sebagai “memori” memang membantu, tetapi hanya jika harness berperilaku seperti sistem operasi: mengalokasikan, mengeluarkan, melakukan paging, mengompaksi, mendeduplikasi, dan menyimpan secara persisten. Pembedaan layer dari Atlan berguna di sini. Rekayasa prompt tidak bisa memperbaiki pembaca file yang menumpahkan 80.000 token tidak relevan ke pemanggilan berikutnya. Rekayasa konteks dapat meningkatkan working set. Rekayasa harness menentukan apakah working set itu terlindungi sejak awal.

Ini juga mengubah cara tim seharusnya mengevaluasi agen. Prompt demo tidak cukup. Evaluasi jangka panjang harus mencakup transkrip yang terus tumbuh, pembacaan file berulang, output tool besar, pemanggilan tool yang gagal, pelanjutan setelah kompaksi, dan tugas ketika langkah berikutnya yang benar bergantung pada batasan awal. Panduan kami tentang rekayasa konteks untuk agen membahas versi masalah tersebut dari sisi model; layer harness adalah tempat masalah itu menjadi operasional.

Pertama, pasang budget pada setiap sumber konteks. File, output tool, chunk yang diambil, sisipan memori, dan riwayat percakapan masing-masing harus memiliki batas eksplisit. Satu batas token maksimum global terlalu tumpul.

Kedua, buat pemotongan dapat ditindaklanjuti. Jika harness memotong konten, model harus tahu rentang apa yang dilihatnya dan cara meminta lebih banyak. Pemotongan senyap lebih buruk daripada penolakan karena menciptakan pekerjaan yang percaya diri di atas data yang hilang.

Ketiga, lakukan kompaksi di sekitar state, bukan prosa. Ringkasan harus mempertahankan tujuan pengguna, batasan, keputusan, tugas tertunda, file yang disentuh, hasil tool yang penting, dan langkah berikutnya yang langsung. Pasangan tool-call harus tetap utuh.

Keempat, pindahkan nilai besar keluar dari prompt. Simpan, beri nama, dan teruskan pointer melalui tool. Ini sangat penting untuk agen yang memanggil API, memproses dokumen, atau mengoordinasikan sistem multi-agen.

Terakhir, uji goal loss secara terpisah dari overflow. Agen dapat tetap berada di bawah window keras dan tetap melenceng. Pertanyaan yang tepat bukan hanya “apakah API menerima prompt?” Melainkan “apakah aksi berikutnya masih melayani tugas awal?”

Ringkasan di bawah ini mengubah pola-pola tersebut menjadi checklist cepat sebelum FAQ.

• Agen jangka panjang gagal melalui context overflow dan goal loss, jadi harness harus mengelola lebih dari sekadar panjang prompt.
• Sistem agen produksi menggunakan budget keras pada file, output tool, dan riwayat sebelum data mentah mencapai model.
• Paginasi, pencarian, dan tampilan terkelola memperlakukan konteks sebagai viewport terbatas, bukan storage permanen.
• Kompaksi bekerja paling baik sebagai checkpointing: mempertahankan tujuan, batasan, keputusan, pekerjaan tertunda, dan integritas pemanggilan tool.
• Output tool besar sering kali lebih cocok berada di storage eksternal dengan pointer singkat yang diteruskan antar-tool, bukan nilai penuh di dalam prompt.

Bagian ini menjawab pertanyaan praktis di balik rekayasa konteks untuk agen jangka panjang: apa yang overflow, bagaimana tujuan hilang, dan pola harness mana yang menjaga pekerjaan tetap pada jalurnya.

Context overflow terjadi ketika akumulasi prompt, riwayat, data yang diambil, file, dan output tool milik agen melebihi context window model yang dapat digunakan atau menurunkan kualitas sebelum batas keras tercapai.

Goal loss terjadi ketika tugas awal masih ada di suatu tempat dalam transkrip tetapi tidak lagi memandu aksi agen berikutnya, sering kali setelah riwayat panjang atau peringkasan yang buruk.

Harness menetapkan budget per sumber, mempaginasi pembacaan file, mengambil hanya tampilan yang relevan, mengompaksi riwayat di sekitar state, mendeduplikasi pembacaan berulang, dan menyimpan output besar di luar prompt.

Pointer memungkinkan model merujuk ke nilai besar yang disimpan di memori runtime, seperti matriks, log, atau PDF, sementara tool downstream me-resolve data penuh tanpa menempatkannya di context window.

Tidak. Window yang lebih besar membantu, tetapi system prompt, definisi tool, dokumen yang diambil, log, dan riwayat tetap berebut ruang, dan informasi relevan dapat terkubur sebelum batas keras tercapai.