Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Ruang lingkup alat
Ada dua pendekatan untuk mengembangkan alat: granular dan berbutir kasar.
Granular
Dalam pendekatan granular, Anda akan membuat alat per API, tindakan, atau kueri. Misalnya, Anda dapat membuatcreate_issue,,, get_issue add_labelassign_issue, dan close_issue alat untuk repositori Git Anda. Ini akan memungkinkan LLM untuk membuat panggilan granular ke setiap API dan mengatur masing-masing sesuai kebutuhan. Pertimbangkan prompt berikut: “Buat masalah untuk layanan produk yang disebut 'Kueri hanya mengembalikan hasil parsial', beri label sebagai bug dan prioritas tinggi, dan tetapkan ke Alice.” Gambar berikut menunjukkan bagaimana tool-per-API pendekatan akan merespons prompt ini.
Dalam pendekatan ini prompt sistem dan setiap definisi alat terdaftar disediakan untuk LLM pada setiap panggilan. Ini menggunakan konteks tambahan dan menimbulkan penalti latensi karena setiap panggilan alat mewakili panggilan individu ke LLM. Hal ini juga meningkatkan kompleksitas penanganan kesalahan dalam alur kerja.
Berbutir kasar
Pendekatan berbutir kasar, atau didorong oleh alur kerja, akan menjadi alat yang berorientasi pada alur kerja. Alat ini berfokus pada maksud end-to-end pengguna atas struktur API. Alih-alih a tool-per-API, Anda memiliki satu alat yang secara deterministik memanggil banyak. APIs Menggunakan contoh repositori Git sebelumnya, Anda dapat membuat create_and_setup_issue alat yang dipanggil sekali oleh agen. Implementasi alat menciptakan masalah, menambahkan label, dan menetapkannya ke pengguna, berdasarkan parameter yang disediakan untuk alat. Gambar berikut menunjukkan bagaimana pendekatan berbutir kasar akan memproses prompt yang sama.
Pendekatan ini menunjukkan bagaimana semua kompleksitas tetap tersembunyi dari lapisan LLM. Ketika logika orkestrasi tertanam dalam implementasi alat, semua langkah berurutan, logging, logika coba lagi, pemutus sirkuit, dan pembatasan laju dilakukan secara deterministik di alat. Pendekatan berbasis alur kerja membuatnya lebih mudah bagi LLM untuk menggunakan alat yang benar dengan parameter yang tepat. Penting untuk dicatat bahwa beberapa API mungkin sudah menyediakan maksud alur kerja, seperti Amazon RunInstances EC2 API. Dalam kasus ini, a tool-per-API dapat memberikan desain berorientasi alur kerja yang Anda inginkan.
Namun, alat bisa menjadi terlalu kasar juga. Jika alat alur kerja tunggal Anda mencoba melakukan terlalu banyak hal dan memiliki banyak parameter yang mungkin, LLM dapat berjuang untuk bernalar tentang cara menggunakan alat dengan benar. Itu juga dapat menciptakan tantangan dengan pemilihan parameter dan penanganan kesalahan. Dengan demikian, pengembangan alat harus mencapai keseimbangan yang selaras dengan maksud pengguna dan menghindari terlalu sedikit atau terlalu banyak fungsionalitas dalam satu alat. Kami menyarankan Anda merancang alat di sekitar alur kerja pengguna yang lengkap, operasi bundling yang biasanya terjadi bersamaan (seperti tiga atau lebih panggilan API). Kami juga menyarankan Anda menguraikan alat yang melebihi delapan parameter atau lebih atau menangani beberapa maksud pengguna yang berbeda. Uji dengan petunjuk nyata untuk memverifikasi bahwa agen dapat menggunakan setiap alat dengan benar.
Jika Anda memiliki alur kerja yang kompleks dan dinamis yang tidak dapat dengan mudah dienkapsulasi sebagai alat deterministik, Anda dapat mempertimbangkan untuk menggunakan pola tersebut. agent-as-tool Alih-alih agen utama Anda mencoba mengatur tugas-tugas kompleks dalam alur kerja, agen khusus dapat bertindak sebagai alat. Jenis alat ini dapat menerapkan pengambilan keputusan dan percabangan tingkat lanjut, dan mereka dapat menangani kesalahan dan mencoba kembali logika yang tidak dapat dengan mudah dikelola dalam kode deterministik. Ini mirip dengan, tetapi berbeda dari, protokol Agent2Agent (A2A
Kami menyarankan Anda memulai dengan analisis alur kerja Anda dengan memetakan alur kerja pengguna yang paling umum untuk mengidentifikasi kemampuan inti yang dibutuhkan setiap agen. Ini menetapkan toolset minimum Anda yang layak. Berdasarkan pengalaman kami mengembangkan server MCP dalam skala besar, kami merekomendasikan praktik-praktik berikut. Ketika praktik ini bertentangan, prioritaskan maksud pengguna dan alur kerja.
Praktik terbaik untuk pelingkupan alat MCP
-
Pikirkan cerita pengguna dan bundel operasi umum — Alat harus memetakan langsung untuk menyelesaikan interaksi pengguna daripada memerlukan orkestrasi beberapa operasi. Jika alur kerja biasanya memerlukan tiga atau lebih panggilan terpisah, gabungkan mereka menjadi satu alat. Ini mengurangi beban kognitif pada LLM, meminimalkan jumlah panggilan alat, mengurangi konsumsi konteks dan latensi yang diperlukan untuk menyelesaikan tugas, dan meningkatkan akurasi dan latensi.
-
Batasi parameter hingga delapan atau kurang — Jika alat melebihi delapan parameter, uraikan menjadi beberapa alat. LLMs berjuang dengan pemilihan parameter saat kompleksitas meningkat.
catatan
Jika operasi bundling membutuhkan lebih dari delapan parameter, prioritaskan bundling di atas jumlah parameter karena menyederhanakan alur kerja lebih berharga daripada batas parameter yang ketat.
-
Operasi baca dan tulis terpisah - Sediakan alat yang berbeda untuk membaca data dan memodifikasinya. Pemisahan ini membuatnya eksplisit ketika agen melakukan operasi yang berpotensi merusak, memungkinkan kebijakan otorisasi yang berbeda, dan mengurangi risiko modifikasi yang tidak diinginkan selama pengumpulan informasi.
-
Berikan default yang masuk akal - Alat desain sehingga LLM hanya perlu menentukan parameter yang spesifik untuk permintaan individu. Default mengurangi kompleksitas parameter dan meningkatkan akurasi pemilihan alat dengan meminimalkan informasi yang harus dipertimbangkan LLM.
-
Lebih suka eksekusi deterministik — Jadikan eksekusi alat dan output deterministik bila memungkinkan. Alat deterministik lebih andal dan lebih mudah diuji. Untuk alur kerja kompleks yang memerlukan orkestrasi cerdas, logika percabangan, atau penanganan kesalahan lanjutan yang tidak dapat dengan mudah dikelola dalam kode deterministik, pertimbangkan untuk menggunakan agen khusus sebagai alat. Namun, gunakan pola ini secara selektif karena menambah kompleksitas.
