Agent membutuhkan kumpulan alat dasar seperti apa

Melihat semua orang membahas masalah kumpulan alat Agent—apakah cukup hanya menyediakan shell saja? Setelah membuat holon, ternyata tidak semudah itu.
Baca: Mengapa meninggalkan Read/Glob, dan sepenuhnya menggunakan shell
Kumpulan alat holon telah diubah beberapa versi, akhirnya membuang alat khusus seperti Read (membaca file) dan Glob (pencarian pola) yang disediakan Claude Code, semua pembacaan dan pencarian dilakukan melalui shell. Ini sejalan dengan jalur Codex—ExecCommand-nya satu paket, membaca file cukup pakai cat, mencari kode pakai rg, tidak lagi mendefinisikan alat terpisah untuk setiap operasi "baca".
Alasan melakukan ini sangat sederhana: shell adalah "bahasa pemrograman" yang paling akrab bagi LLM. Daripada membiarkan model belajar parameter dan semantik alat Read yang kamu definisikan, lebih baik langsung biarkan model menulis perintah shell yang sudah dilatih puluhan miliar kali. Setiap alat khusus menambah beban kognitif model; sedangkan antarmuka shell, model sudah cukup mahir.
Tapi sepenuhnya menggunakan shell memiliki satu biaya: pemotongan output. Kerangka kerja untuk menghindari nilai kembali shell yang terlalu panjang dan memenuhi konteks akan membatasi output setiap perintah. Agent yang pakai cat untuk membaca file besar mungkin hanya mendapatkan bagian depan, sisanya di file artifact, dan harus cat lagi berkali-kali untuk membacanya. Read tool Claude Code memiliki ambang kompresi yang jauh lebih tinggi daripada shell umum, membaca file besar sekaligus, mengurangi bolak-balik. Intinya adalah kompromi: mengurangi definisi alat untuk mengurangi beban kognitif, tetapi alat khusus lebih efisien di skenario batasan.
Tulis: Dari sed ke ApplyPatch, dan tantangan alat grammar bebas
Tapi operasi tulis tidak bisa sepenuhnya diselesaikan dengan shell.
Jika membiarkan Agent hanya pakai sed untuk pengeditan, akan sulit menangani pencocokan multi-baris yang kompleks—baris baru, escape, indentasi, setiap lapisan yang bermasalah bisa menyebabkan kegagalan pengeditan. Jadi banyak sistem menyediakan alat pengeditan seperti Replace String, agar Agent bisa mengirim satu blok old_string untuk pencocokan dan penggantian yang tepat ke new_string. Meskipun canggung, ini jauh lebih stabil daripada sed.
Codex bahkan lebih jauh lagi, menciptakan alat ApplyPatch sendiri, memungkinkan Agent langsung menghasilkan patch, menyelesaikan pengeditan massal sekaligus. holon mengadopsi ide ini.
Namun saat diimplementasikan, ada jebakan: Codex menggunakan format patch yang disederhanakan yang didefinisikan sendiri oleh OpenAI, dan menggabungkan mekanisme alat khusus bernama free grammar tool untuk mengatasi masalah format.
Mengapa harus membuat mekanisme baru? Karena definisi alat standar LLM adalah tool(args) dalam format JSON. Jika patch dikirim sebagai string JSON, akan melibatkan banyak escape—baris baru harus diubah, tanda kutip harus diberi garis miring terbalik, indentasi harus hati-hati. Agent yang menulis patch sendiri sudah rawan error, ditambah lagi dengan escape JSON, peluang error jadi dua kali lipat. Ide free grammar tool adalah langsung menggunakan teks asli patch sebagai input alat, tanpa melalui encoding JSON, apa pun yang ditulis model adalah apa adanya. Ini secara signifikan mengurangi kemungkinan kesalahan saat model menghasilkan patch.
Saat ini, mekanisme ini hanya didukung oleh antarmuka Codex dari OpenAI. holon harus kompatibel dengan berbagai penyedia model, jadi tidak bisa hanya mengandalkan satu jalur ini.
Jadi, pendekatan holon adalah: menginjeksikan definisi ApplyPatch berbeda sesuai model. Untuk model yang mendukung free grammar, langsung pakai format patch asli; untuk model lain, terima format diff git standar. Saya percaya bahwa LLM yang sudah dilatih dengan puluhan miliar diff di GitHub harus cukup mahir dengan format diff git. Secara praktik, hasilnya cukup baik—meskipun sering error, tapi sebagian besar bisa diperbaiki, dan seiring bertambahnya data pelatihan, kemampuan ini akan semakin baik. Tapi saya tetap menyarankan semua vendor model mendukung free grammar tool, karena ini benar-benar kebutuhan utama dalam skenario penulisan kode oleh Agent.
Penjadwalan: perintah jangka panjang dan abstraksi tugas
Masalah ketiga adalah perintah shell yang dijalankan Agent tidak selalu cepat selesai—misalnya menjalankan dev server, menjalankan pengujian, membangun proyek, semuanya bisa berlangsung lama, bahkan tidak pernah keluar. Kerangka awal menangani ini secara kasar: entah sinkron dan memblokir, atau semua perintah dijalankan di latar belakang, sehingga Agent bisa menjalankan perintah yang sama berulang kali.
Sekarang, industri secara bertahap menyepakati satu prinsip dasar: tidak memberi pilihan "depan/belakang" kepada Agent—karena Agent sendiri tidak bisa menilai dengan pasti. Pendekatan yang lebih baik adalah menetapkan batas waktu, jika perintah melebihi waktu, otomatis dipindahkan ke latar belakang, dan ini sepenuhnya transparan bagi Agent. Agent tidak perlu memprediksi apakah perintah harus dipindahkan ke latar belakang, runtime yang mengatur sendiri.
Tapi, memindahkan ke latar belakang hanyalah langkah pertama. Setelah dipindahkan, muncul masalah nyata—dan saat ini belum ada jawaban standar.
Pertama, bagaimana membaca outputnya. Tugas latar belakang mungkin masih berjalan atau sudah selesai, outputnya bisa besar. Tapi API dari berbagai penyedia tidak seragam—ada yang menggunakan polling, ada yang menggunakan push event.
Kedua, bagaimana menghentikan tugas. Semua penyedia punya mekanisme cancel, tapi apakah membunuh secara langsung atau keluar secara elegan, dan apakah output yang sudah dihasilkan harus disimpan?
Ketiga, siapa yang membangunkan kembali Agent. Setelah tugas dipindahkan ke latar belakang dan tidur, siapa yang membangunkannya saat tugas selesai? Ini membutuhkan integrasi mendalam antara runtime dan penjadwalan Agent, bukan sekadar alat terpisah.
Ketiga hal—membaca output, menghentikan tugas, membangunkan Agent—bersama-sama membentuk siklus hidup lengkap dari tugas latar belakang. Semua penyedia sudah mampu menjalankan tugas di latar belakang, tapi manajemen siklus hidupnya belum distandarisasi, dan ini bisa menjadi titik kunci evolusi berikutnya dari rangkaian alat Agent.
Belum saatnya pakai satu pola yang langsung jadi tanpa pikir panjang
Jadi, kembali ke pertanyaan awal: shell memang bisa menyelesaikan 80%, tapi sisa 20%—ketepatan pengeditan, format patch yang cocok dengan kemampuan model, penjadwalan tugas panjang—justru menentukan apakah Agent bisa bertransformasi dari demo ke sistem yang benar-benar bisa digunakan.
Kumpulan alat jauh lebih dari sekadar "bungkus shell" dan juga belum saatnya semua orang bisa sembarangan pakai pola yang sama. Itulah mengapa Codex dan Claude Code memberikan jawaban berbeda pada masalah dasar ini, dan holon juga membuat pilihan berbeda sesuai skenario. Masih banyak area yang bisa dieksplorasi dan diperbaiki.