Claude mengungkap fitur penggunaan alat tingkat lanjut
(anthropic.com)- Tiga fitur baru ditambahkan ke Claude Developer Platform, menghadirkan arsitektur penggunaan alat tingkat lanjut yang memungkinkan model menelusuri, memanggil, dan mempelajari ribuan alat eksternal secara efisien
- Tool Search Tool memuat definisi alat hanya saat dibutuhkan sehingga menghemat penggunaan token hingga 85% dan meningkatkan akurasi ke kisaran 74~88% di lingkungan MCP berskala besar
- Programmatic Tool Calling memungkinkan pemanggilan alat secara paralel di lingkungan eksekusi kode untuk mencapai penghematan token (37%), pengurangan latensi, dan peningkatan akurasi
- Tool Use Examples membuat model mempelajari pola penggunaan alat dan hubungan antar-parameter yang tidak dapat direpresentasikan dengan JSON Schema melalui contoh pemanggilan nyata
- Ketiga fitur ini menyediakan fondasi orkestrasi yang efisien untuk agen AI skala besar dan menjadi komponen inti dalam otomatisasi workflow yang kompleks
Perluasan penggunaan alat oleh agen AI
- Agen AI di masa depan perlu memanfaatkan ratusan hingga ribuan alat secara terpadu
- Contohnya mencakup alat bantu IDE, koordinator operasional, serta integrasi dengan Slack, GitHub, Jira, Google Drive, dan lainnya
- Pendekatan lama mengharuskan semua definisi alat dimuat terlebih dahulu sehingga cepat menghabiskan context window
- Pendekatan baru menelusuri dan memuat alat saat diperlukan, lalu meningkatkan efisiensi melalui pemanggilan berbasis kode dan pembelajaran dari contoh
Tool Search Tool
- Di lingkungan MCP yang ada, saat banyak server terhubung, definisi alat dapat memakan lebih dari 100 ribu token
- Contoh: GitHub (26K), Slack (21K), Jira (17K), dan saat diakumulasi bisa melampaui 134K token
- Tool Search Tool menelusuri dan memuat alat secara on-demand
- Saat pemuatan awal hanya menggunakan sekitar 500 token, lalu memuat tambahan hanya untuk alat yang diperlukan
- Total penggunaan token turun menjadi sekitar 8.7K, menghasilkan penghematan konteks sebesar 95%
- Hasil pengujian internal menunjukkan peningkatan akurasi evaluasi MCP: Opus 4: 49%→74%, Opus 4.5: 79.5%→88.1%
- Alat dapat dimuat secara tertunda melalui pengaturan
defer_loading: true- Hanya alat yang sering dipakai yang selalu dimuat, sisanya dipanggil saat pencarian dilakukan
- Disediakan alat pencarian berbasis regex dan BM25 secara bawaan, serta mendukung pencarian kustom berbasis embedding
- Kondisi yang direkomendasikan untuk penerapan: lebih dari 10 alat, definisi di atas 10K token, atau lingkungan dengan kesalahan pemilihan alat yang sering terjadi
Programmatic Tool Calling
- Pemanggilan berbasis bahasa alami sebelumnya tidak efisien karena akumulasi hasil antara dan multi-pass reasoning
- Contoh: saat menganalisis log 10MB, seluruh data masuk ke konteks dan memboroskan token
- Programmatic Tool Calling (PTC) memungkinkan pemanggilan alat paralel di lingkungan eksekusi kode
- Claude dapat menjalankan loop, kondisi, dan transformasi data dengan kode Python
- Hasil antara tidak dimasukkan ke konteks model, dan hanya hasil akhir yang dikembalikan
- Contoh: pada tugas mencari pihak yang melebihi anggaran per kuartal, hanya hasil 1KB yang masuk ke konteks alih-alih 2.000 item
- Dampak
- Penggunaan token 43,588→27,297 (turun 37%)
- Latensi berkurang (19 langkah inferensi dihilangkan pada 20 kali pemanggilan)
- Akurasi meningkat: pencarian internal 25.6→28.5%, benchmark GIA 46.5→51.2%
- Kondisi yang direkomendasikan untuk penerapan
- Ringkasan data skala besar, pemanggilan berantai dengan ketergantungan lebih dari 3 tahap, atau tugas yang memerlukan eksekusi paralel
- Tidak efisien untuk pemanggilan tunggal atau respons yang kecil
Tool Use Examples
- JSON Schema hanya mendefinisikan struktur, tetapi tidak dapat merepresentasikan pola penggunaan, aturan format, dan hubungan antar-parameter
- Contoh: format tanggal, aturan ID, atau kapan objek bertingkat digunakan bisa menjadi tidak jelas
- Tool Use Examples menambahkan contoh input nyata (
input_examples) ke definisi alat- Melalui contoh, Claude mempelajari format tanggal (YYYY-MM-DD), aturan ID (USR-XXXXX), dan kombinasi parameter opsional
- Dalam pengujian internal, akurasi pemrosesan parameter kompleks meningkat dari 72% menjadi 90%
- Kondisi yang direkomendasikan untuk penerapan
- Alat dengan banyak struktur bertingkat dan parameter opsional
- API yang memiliki aturan spesifik domain yang tidak dapat dinyatakan lewat Schema
- Kasus yang memerlukan pembedaan antar alat yang serupa
Pemanfaatan terintegrasi ketiga fitur dan best practice
- Ketiga fitur bekerja saling melengkapi
- Tool Search Tool → menelusuri alat yang dibutuhkan
- Programmatic Tool Calling → menjalankan secara efisien
- Tool Use Examples → memastikan pemanggilan yang akurat
- Prioritas penerapan
- Konteks terlampaui → Tool Search Tool
- Hasil antara terlalu banyak → Programmatic Tool Calling
- Kesalahan parameter → Tool Use Examples
- Tips konfigurasi
- Tulis nama dan deskripsi alat dengan jelas untuk meningkatkan akurasi pencarian
- Selalu muat 3~5 alat yang paling sering digunakan, dan tunda pemuatan sisanya
- Tentukan format output untuk alat eksekusi kode
- Tulis data contoh secara realistis dan ringkas (1~5 contoh)
Memulai
- Ketiga fitur tersedia dalam versi beta
- Dapat digunakan setelah menambahkan header
betas=["advanced-tool-use-2025-11-20"] - Alat yang disertakan:
tool_search_tool_regex_20251119,code_execution_20250825, dan lainnya
- Dapat digunakan setelah menambahkan header
- Dokumentasi resmi dan cookbook GitHub menyediakan contoh API serta panduan implementasi
- Fitur-fitur ini diposisikan sebagai teknologi dasar yang berkembang melampaui function calling sederhana menuju orkestrasi cerdas
- Ditekankan sebagai komponen inti yang mewujudkan penelusuran dinamis, eksekusi efisien, dan pemanggilan akurat dalam workflow kompleks dan lingkungan data berskala besar
5 komentar
Tapi sampai sekarang rasanya ini masih karena kekuatan model. Ini bekerja sebagus ini karena model yang dilayani Claude memang seperti itu, jadi untuk model lain apakah bakal begitu juga... saya jadi ragu.
Di antara perusahaan seperti Anthropic, Google, dan OpenAI, saya merasa Anthropic paling mendekati Agentic AI.
Opini Hacker News
Sedang mencari cara untuk mengurangi penggunaan context saat melakukan streaming beberapa tool call
Sebagian pemrosesan dialihkan ke tool itu sendiri agar markdown 200k token dikembalikan dalam struktur ringkasan, tetapi pendekatan seperti ini pun kadang tetap cepat memenuhi context model utama
Menurut saya Programmatic Tool Calling adalah langkah berikutnya yang alami
LLM bergerak ke arah memperlakukan kode seperti bahasa, jadi definisi bahasanya menjadi penting
Namun saya menganggap pencarian tool sebagai overhead yang tidak perlu. Lebih efisien jika tool yang dibutuhkan dimasukkan lebih dulu ke dalam context
Pada akhirnya dibutuhkan tool definition language yang ringkas seperti definisi fungsi; saya ingin bisa memasukkan objek ke context dan membuatnya mengenali tipe serta metode yang dapat dipanggil
.d.tsPemeliharaan dan pengujian juga lebih mudah, dan jika perlu bisa diimpor dengan gaya seperti
export * as Foo from '@foo/foo'Karena LLM juga pandai menulis kode, jika diberi izin menulis, ia bisa membuat atau mengimpor tool sendiri
Ke depannya, platform kolaborasi AI↔manusia yang interaktif seperti Jupyter/Pluto/Mathematica tampaknya akan lebih cocok
Jika ditambah input suara dan kolaborasi lintas sesi, sistemnya akan hampir setara Skynet
Agen yang saya buat berjalan cukup baik hanya dengan sebagian kemampuan Python SDK dan fungsi kustom
Struktur pseudo-RPC seperti ini terasa seperti ritual yang tidak perlu
Smolagents memanfaatkannya untuk menangani output tool sebagai objek (dict)
Saya penasaran apakah pendekatan ini mirip dengan arah yang saya maksud
Detailnya ada di postingan blog Hugging Face
Saya penasaran apakah server MCP akan menyertakan contoh penggunaan di definisi tool
Jika iya, mereka juga bisa memasukkan contoh kode sehingga tahap pembuatan kode bisa dilewati, tetapi mungkin hal ini diblokir karena masalah keamanan
Menjalankan kode yang disediakan pihak ketiga itu berbahaya, jadi desain seperti ini bisa dimengerti
Sayang sekali mereka memakai Python sebagai wrapper
Jika memakai Bash, kompatibilitas antarbahasa akan lebih tinggi dan akan cocok juga untuk workflow yang tidak menggunakan Python
Kemampuan menjalankan tool eksternalnya juga tidak kalah dari Bash
Arah “masa depan di mana model dengan mulus menangani ratusan hingga ribuan tool” tampaknya keliru
Menurut saya arah yang benar justru lebih sedikit tool + kemampuan pemanfaatan yang lebih baik
Secara ekstrem, satu ShellTool saja mungkin sudah cukup
Cara idealnya adalah model belajar membuat dan menguji tool sendiri sampai bisa dipercaya
Ekosistem konektor mudah dipahami dan enak dipasarkan, tetapi secara mendasar terasa seperti paradigma yang keliru
Saya rasa akan bagus jika ada model orkestrator lokal yang kecil
Dalam banyak kasus, mengorkestrasi seluruh workflow secara programatik itu tidak efisien
Untuk mengurangi polusi context dan meningkatkan kecepatan, struktur programmatic > tiny local LLM > frontier LLM tampaknya ideal
Model kecil bisa sering menginisialisasi ulang context, lalu hanya meneruskan hasil yang diperlukan ke model besar
Saat memakai asisten AI, ada pola yang terus berulang
Ketika saya sendiri memperbaiki cara yang tidak efisien, beberapa bulan kemudian muncul tool baru dan pekerjaan saya jadi sia-sia
Saya menganggap itu sebagai harga mengejar teknologi terbaru
Suatu hari nanti, sepertinya seluruh web akan tersusun dari miliaran tool
Google akan mengindeksnya, dan Gemini akan memilihnya secara dinamis untuk bertindak di dunia
Sejujurnya saya mengharapkan hal seperti ini di Gemini 3
Fitur #2 yang dibahas di sini adalah implementasi dari konsep yang belakangan ramai dibicarakan: “tidak memanggil tool secara langsung, tetapi menulis kode untuk memanggilnya”
Ini berjalan di Python sandbox, bisa diakses lewat API juga, dan mengekspos pemanggilan tool seperti pemanggilan API biasa
Batch tool calling sudah sangat meningkatkan kecepatan asisten AI di produk kami, dan fitur kali ini terlihat seperti evolusinya
Agentic builder kami hanya memakai satu tool — yaitu GraphQL
Agen menulis query lalu menjalankannya, dan mendapatkan informasi yang diperlukan lewat introspection
Karena hanya menerima data minimal, penghematan token pun dimungkinkan
Tidak perlu memuat lebih dari 50 tool, dan masalah N+1 pada REST API juga teratasi
Berkat typed schema GraphQL, agen menulis kode yang lebih baik
Dulu saya tidak menyukai GraphQL, tetapi melihat kondisi MCP saat ini, saya rasa ini salah satu teknologi yang paling cocok untuk agen AI
Rinciannya saya tulis di artikel ini
Agen saya hanya menjalankan satu query SPARQL, dan state-nya hanyalah graph DB
Sebagian besar ontologi bersifat publik, jadi hampir tidak perlu schema introspection
Berkat output terstruktur, kita bisa membatasi agar hanya RDF yang valid yang dihasilkan
Sepertinya pendekatan serupa juga mungkin di GraphQL
Saya harus melakukan berbagai tugas seperti pencarian web, pemanggilan API lokal, integrasi Slack, dan lain-lain, jadi GraphQL saja tidak cukup
Ada isu izin, caching, dan mutation, tetapi itu tidak terlalu memengaruhi pemuatan context selektif
LLM cukup pandai menulis query GraphQL yang sesuai schema
Bahkan jika melakukan kesalahan, selama diberi pesan error yang baik, ia cepat memperbaikinya
Reasoning terkait ada di postingan blog ini
Saya pikir Sonnet 4.5 juga sudah cukup bagus.
Opus 4.5 sepertinya lebih bagus. Wow.
Begitukah? Bagian mana yang terutama seperti itu?