Deep Agents v0.7 Pangkas Token per Giliran 65%

Deep Agents v0.7 memangkas token input dasar per giliran sebesar 65%. Artinya, overhead prompt tetap pada setiap panggilan berkurang, pengeluaran API lebih rendah, dan ruang konteks untuk bagian tugas yang penting menjadi lebih besar.

Jika pembaruan ini diringkas, inilah intinya:

• Prompt sistem dasar bawaan telah dihapus
• Deskripsi alat bawaan lebih singkat
• Todo tidak lagi disertakan secara bawaan
• Middleware dipilih secara sengaja, bukan dibundel
• Penghematan berasal dari harness, bukan model

Sederhananya, jika agen melakukan 10 panggilan, wrapper tetap yang sama sebelumnya dikirim 10 kali. Di v0.7, wrapper tersebut jauh lebih kecil secara bawaan. Jadi, saya mendapatkan permintaan yang lebih ringkas pada setiap giliran, terutama untuk tugas sederhana seperti membaca atau menulis file.

Beberapa hal menonjol:

• Biaya meningkat mengikuti llm_calls × input_tokens_per_call
• Pengaturan lama mengirim teks perencanaan, sistem file, dan subagen meskipun tugas tidak membutuhkannya
• Pengaturan baru memberikan kendali kepada saya, sehingga saya memilih prompt, alat, dan middleware untuk pekerjaan tersebut
• Pengurangan terbesar berasal dari penghapusan prompt dasar dan pemangkasan teks alat
• Alur kerja panjang dan multiagen memperoleh manfaat terbesar karena overhead tetap berulang di setiap langkah

Berikut gambaran sederhana sebelum dan sesudah:

Kesimpulan saya: v0.7 lebih berfokus pada disiplin prompt daripada perubahan model. Jika harness tetap ringkas, saya mempertahankan seluruh keuntungan 65%. Jika middleware dan alat ditambahkan kembali secara berlebihan, sebagian keuntungan itu akan hilang.

Itulah inti pembaruan ini dan landasan untuk bagian artikel berikutnya.

Perubahan pada harness yang dapat dikonfigurasi

Pengurangan token 65% berasal dari perubahan pada konten yang disuntikkan harness di setiap giliran, bukan dari penggunaan model yang lebih cerdas. Sederhananya, v0.7 menghapus banyak teks bawaan yang sebelumnya ikut dalam setiap permintaan.

Prompt sistem dasar dihapus dan deskripsi alat dipangkas

Sebelum v0.7, harness memasukkan prompt sistem bawaan, deskripsi alat yang panjang, middleware perencanaan, dan logika subagen ke dalam setiap permintaan, bahkan ketika tugas tidak memerlukannya. v0.7 mengubah pengaturan ini dengan membuat harness dapat dikonfigurasi, sehingga pengembang menentukan apa yang disuntikkan pada setiap giliran.

Sumber overhead terbesar adalah prompt sistem dasar bawaan dan deskripsi alat bawaan yang panjang. Prompt dasar memuat instruksi untuk alat perencanaan, alat sistem file, dan subagen, serta dikirim pada setiap giliran. Di v0.7, prompt tersebut dihapus. Pengembang kini dapat menyediakan teks prompt yang sesuai dengan tugas.

Deskripsi alat bawaan untuk utilitas seperti ls, read_file, dan write_file juga dipersingkat. Alat tetap berfungsi dengan cara yang sama. Hanya ada lebih sedikit teks tetap yang membungkus setiap permintaan. Kedua perubahan tersebut tidak memengaruhi model yang mendasarinya. Perubahan ini hanya memangkas beban token yang sebelumnya dibawa setiap giliran.

Todo bersifat opsional dan middleware kini dipilih secara eksplisit

Sebelum v0.7, todoListMiddleware disertakan secara bawaan, sehingga teks perencanaan dikirim pada setiap giliran. Di v0.7, todo bersifat opsional. Artinya, Anda hanya menambahkannya jika tugas menjadi lebih baik dengan perencanaan multi-langkah.

Perubahan yang sama berlaku untuk keseluruhan tumpukan middleware. FilesystemMiddleware dan SubAgentMiddleware tidak lagi dibundel secara bawaan. Pengembang kini dapat menyusun hanya middleware yang dibutuhkan. Tugas membaca file dapat melewati logika subagen. Alur verifikasi dapat menambahkan middleware daftar periksa hanya saat membantu.

Cara orkestrasi menjadi lebih eksplisit

Perubahan praktisnya sederhana: pengaturan beralih dari bawaan implisit ke konfigurasi eksplisit. Alih-alih harness menentukan alat yang terlihat, middleware yang berjalan, dan isi prompt sistem, pengembang membuat keputusan tersebut sendiri. Mereka kini mengendalikan penyusunan prompt, visibilitas alat, dan middleware untuk setiap tugas.

Perubahan ini tampak pada tumpukan agen bawaan di bawah. ^[2]

Penggunaan token sebelum dan sesudah

Perubahan harness tersebut langsung terlihat dalam payload yang dikirim pada setiap giliran. Penghematan berasal dari pemangkasan selubung permintaan tetap, bukan dari perubahan prompt pengguna atau model.

Giliran agen bawaan sebelum v0.7

Sebelum v0.7, setiap giliran menyertakan kerangka perencanaan, sistem file, dan subagen meskipun tidak ada yang digunakan. Teks todo dan prompt middleware juga disertakan secara bawaan. Akibatnya, payload tetap yang besar berulang di setiap giliran.

Giliran agen bawaan setelah v0.7

Setelah v0.7, tugas membaca file sederhana hanya mengirim alat dan middleware yang dibutuhkan. Overhead tambahan tidak lagi berulang di setiap giliran. Prompt sistem dasar dihapus, deskripsi alat lebih singkat, dan tugas membaca file tidak lagi membawa teks perencanaan atau subagen yang tidak digunakan.

Seperti dicatat Aaron Jewitt, biaya agen meningkat mengikuti llm_calls × input_tokens_per_call.^[1]

Sumber penghematan token

Berikut asal pengurangan 65% tersebut.

Penghematan terbesar berasal dari penghapusan prompt dasar dan pemangkasan deskripsi alat. Itulah alasan middleware selektif dan visibilitas alat yang lebih sempit membuat perbedaan jelas dalam alur kerja harian.

Bagian berikut menunjukkan cara pengembang mempertahankan penghematan ini dengan memilih hanya bagian harness yang dibutuhkan tugas.

Pola konfigurasi harness untuk pengembang

Setelah penghematan token terkunci, langkah berikutnya adalah memilih profil harness yang ringkas untuk setiap tugas. Penghematan tersebut berasal dari prompt yang lebih kecil dan bawaan harness yang lebih ketat. Dalam Deep Agents v0.7, harness—bukan model—menyumbang sebagian besar overhead token per giliran. Artinya, optimasi di Deep Agents v0.7 lebih bergantung pada cara menyusun harness daripada pilihan model.

Pilih hanya middleware yang dibutuhkan tugas

Gunakan middleware hanya ketika tugas memerlukan pembatasan, perencanaan, atau pengelolaan status. Pada tugas singkat, lapisan tambahan tersebut hanya menambah overhead.

Aturannya sederhana: Mulailah dengan tumpukan middleware terkecil yang dibutuhkan tugas. Hal yang sama berlaku untuk alat. Tampilkan hanya alat yang benar-benar dibutuhkan tugas saat ini.

Batasi visibilitas alat dan persingkat deskripsi

Menampilkan setiap alat pada setiap giliran merupakan salah satu cara tercepat untuk membengkakkan input per giliran. Menjaga visibilitas alat tetap sempit membantu mempertahankan prompt yang kecil.

Deskripsi alat yang lebih singkat membantu memangkas ukuran prompt lebih jauh. Deskripsi yang ringkas dan tepat mengurangi ukuran prompt serta memudahkan model memilih alat yang tepat tanpa banyak konteks tambahan.

Gunakan todo opsional dan bawaan berbasis profil

Pengelolaan todo membantu tugas jangka panjang ketika agen perlu melacak kemajuan di banyak langkah. Untuk pekerjaan singkat satu langkah, todo menambah overhead tanpa memberikan manfaat.

Jadikan todo opsional untuk tugas jangka panjang, lalu tetapkan bawaan ringkas atau kaya menurut kelas agen. Bawaan kelas agen yang ringkas mempertahankan keuntungan 65% pada agen sederhana, sedangkan profil yang lebih kaya digunakan untuk alur kerja dengan banyak perencanaan.

Pilihan tersebut menentukan apakah pengurangan 65% benar-benar menghasilkan biaya lebih rendah dan iterasi lebih cepat dalam penggunaan sehari-hari.

Arti pembaruan v0.7 bagi biaya, kecepatan, dan skala

Biaya inferensi lebih rendah dan loop iterasi lebih cepat

Selubung permintaan yang lebih kecil terakumulasi pada setiap giliran dalam alur kerja panjang. Biaya token menumpuk sepanjang proses multi-turn, sehingga harness yang lebih ringkas tidak hanya menghemat uang pada giliran pertama. Harness ini menjaga titik awal tetap lebih kecil pada setiap giliran berikutnya, dan selisihnya membesar seiring percakapan berkembang.

Berikut tempat pengurangan tersebut terlihat dalam praktik:

Payload yang lebih kecil juga mempercepat loop iterasi. Jika Anda menguji perubahan prompt atau mencoba pengaturan alat baru, permintaan yang lebih ringan kembali lebih cepat. Hal ini menghilangkan banyak hambatan dalam pekerjaan pengembangan harian.

Skalabilitas lebih baik untuk alur kerja panjang dan multiagen

Penghematan token yang sama menjadi lebih penting ketika beberapa agen berbagi anggaran alur kerja yang sama. Overhead tetap adalah penguras anggaran tersembunyi dalam sistem multiagen. Jika setiap agen membawa harness yang terlalu besar, overhead tersebut berlipat ganda di setiap giliran terkoordinasi.

Paket harness yang lebih ringkas menjaga jejak setiap agen lebih kecil. Hal ini meningkatkan throughput dan mengurangi kemungkinan mencapai batas konteks atau batas laju di tengah alur kerja.

Ketika jendela konteks terisi, performa dapat menurun. Harness yang lebih ringkas memberi setiap agen lebih banyak ruang konteks yang dapat digunakan untuk data tugas sebenarnya. Sederhananya, alur kerja panjang dapat tetap akurat lebih lama tanpa logika pemadatan atau peringkasan masuk terlalu dini.

Overhead per panggilan yang lebih rendah paling penting dalam alur kerja dengan banyak giliran, banyak agen, atau keduanya. Pemangkasan token 65% mengurangi biaya per panggilan. Namun, keuntungan skala yang lebih besar berasal dari model orkestrasi eksplisit di v0.7. Dengan kriteria penghentian yang jelas, bukan loop tanpa akhir, agen melakukan lebih sedikit total panggilan untuk menyelesaikan tugas.

Poin utama dari rilis Deep Agents v0.7

Deep Agents v0.7 meningkatkan biaya dan kualitas dengan membuat harness dapat dikonfigurasi. Pemilihan middleware, visibilitas alat, dan bawaan berbasis profil kini menentukan apakah alur kerja mempertahankan seluruh penghematan atau mengembalikan sebagian besar melalui overhead tambahan.

Konfigurasi adalah pengungkit optimasi utama. Pengaruhnya paling besar dalam alur kerja dengan banyak giliran, banyak agen, atau keduanya.

Pertanyaan umum

Bagaimana cara mempertahankan seluruh penghematan token 65% dalam alur kerja nyata?

Perlakukan konfigurasi harness sebagai sistem yang terus berkembang, bukan tugas yang cukup diatur sekali lalu dilupakan. Mulailah dengan mengukur penggunaan token dan jumlah panggilan LLM. Kemudian gunakan harness untuk mengunci aturan perilaku yang ketat.

Gunakan PreCompletionChecklistMiddleware untuk menghentikan loop penalaran berulang. Gunakan LocalContextMiddleware agar hanya konteks dan alat yang dibutuhkan model yang diteruskan. Tambahkan caching prompt agar instruksi sistem tetap stabil di seluruh proses.

Saat penggunaan token melonjak, pantau penyimpangan dan perketat aturan harness.

Tugas mana yang tetap perlu menggunakan todo atau middleware tambahan?

Gunakan todoListMiddleware saat agen mengerjakan masalah kompleks yang terdiri dari banyak bagian. Middleware ini membantu agen melacak bagian yang telah selesai dan bagian yang masih memerlukan perhatian seiring pekerjaan berjalan.

Saat Anda memerintahkan penggunaan alat write_todos, agen dapat memperbarui kemajuan ketika detail baru masuk. Hal ini membuat alur kerja panjang dan sulit lebih mudah diikuti serta membantu agen tetap terarah.

Apakah harness yang lebih kecil memengaruhi kualitas atau keandalan agen?

Tidak secara bawaan. Harness yang lebih kecil dan disetel dapat mempertahankan keandalan yang sama—atau bahkan meningkatkannya—dengan memangkas token per giliran melalui penanganan konteks yang lebih baik, pengalihan ke alat, dan pengemasan prompt terstruktur.

Kualitas tetap terjaga ketika penghematan tersebut dipadukan dengan guardrail deterministik, seperti loop verifikasi dan daftar periksa sebelum selesai. Hal ini membantu agen tetap berfokus pada data tugas yang penting dan memeriksa kembali pekerjaannya sebelum merespons.