Pembangun yang menggunakan model bahasa besar (LLM) tempatan mendapati bahawa satu pelayan Multi-Channel-Protocol (MCP) boleh menghabiskan keseluruhan tetingkap konteks sebelum pengguna sempat menaip sebarang arahan. Mereka terpaksa memilih antara penerangan alatan yang terhad atau aliran perbualan yang terganggu.

Mengapa pembengkakan token penting untuk LLM tempatan

MCP membolehkan LLM memanggil alatan luaran—API, skrip, atau utiliti sistem fail—dengan memberikan penerangan bagi setiap alatan kepada model tersebut. Model hos awan dengan tetingkap 128k token boleh menyerap banyak definisi alatan dan masih mempunyai ruang untuk dialog pengguna. Model dengan 7 bilion parameter yang dijalankan secara tempatan dengan tetingkap 8k token akan kehabisan ruang selepas memuatkan hanya beberapa alatan sahaja. Pertukaran (trade-off) ini sangat ketara: penerangan yang pendek dan murah menyebabkan panggilan salah hala; penerangan yang panjang dan terperinci pula menggunakan bajet yang diperlukan untuk sembang.

Rantaian peristiwa yang membawa kepada situasi ini

MCP dibina untuk menggantikan kod integrasi tersuai dengan satu antara muka tunggal yang dipacu model untuk pelbagai sumber data. Kebanyakan pelayan MCP bertindak sebagai pembungkus (wrapper) nipis di sekeliling endpoint REST yang dimaksudkan untuk pengendali manusia, bukan mesin. Apabila pembungkus tersebut dimasukkan ke dalam sesi LLM tempatan, model mesti membaca setiap nama alatan, parameter, dan nota penggunaan sebelum ia boleh memutuskan alatan mana yang perlu dipanggil. Tetingkap konteks yang kecil menukarkan "bebanan penerangan" (description overhead) ini menjadi satu hambatan struktur.

Siapa yang menang, siapa yang kalah

  • Pembangun yang membina pembantu peranti kehilangan fleksibiliti. Mereka sama ada perlu memangkas katalog alatan, yang berisiko menyebabkan kegagalan kerap, atau menerima prompt yang membengkak yang memotong input pengguna.
  • Pengguna akhir melihat tingkah laku yang tidak stabil apabila pembantu memilih alatan yang salah atau enggan bertindak kerana konteks telah penuh.
  • Penyedia alatan mendapat titik kemasukan yang seragam.

Kosnya bukan sekadar pengalaman yang lebih buruk; ia juga menimbulkan kebimbangan keselamatan. Apabila ejen MCP boleh membaca sebarang fail tempatan, model kebenaran menjadi "semua-atau-tiada". Tanpa sandbox, alatan yang salah dikonfigurasi boleh mendedahkan keseluruhan sistem fail.

Apa yang dilakukan oleh pembangun mengenainya

Tiga jalan penyelesaian mendominasi komuniti:

  • Memangkas penerangan – Membuang metadata alatan ke tahap minimum. Ini membebaskan token tetapi meningkatkan kemungkinan model memilih endpoint yang salah, membawa kepada ralat yang mesti dikesan dan dicuba semula oleh pembangun.
  • Pemuatan dinamik – Memuatkan hanya subset alatan yang relevan dengan perbualan semasa. Seorang dispatcher yang ringan akan memutuskan, berdasarkan niat pengguna, set alatan mana yang perlu dimasukkan. Ini mengurangkan penggunaan token yang tidak diperlukan tetapi menambah kependaman (latency) dan kerumitan kod.
  • Menghadkan pelayan aktif – Menghadkan jumlah pelayan MCP bagi setiap sesi, memaksa pembangun untuk mengutamakan integrasi yang paling penting. Ini memastikan saiz prompt boleh diurus tetapi mengorbankan keluasan keupayaan.

Tiada satu pun daripada penyelesaian ini yang merupakan penyelesaian mutlak. Memangkas penerangan menjejaskan kebolehpercayaan; pemuatan dinamik menambah lapisan keputusan yang melambatkan respons; mengehadkan pelayan memaksa pilihan sukar tentang sumber data mana yang perlu disokong.

Risiko keselamatan yang menyertai masalah token

Ejen tempatan sering dijalankan dengan akses sistem fail tanpa sekatan. Protokol MCP tidak menawarkan keperincian antara "baca folder ini" dan "baca semua". Sesetengah pasukan telah membina lapisan gerbang (gateway) untuk membaiki isu akses penuh, yang menambah lebih banyak kerumitan. Gerbang tersebut mengurangkan masalah "kawalan penuh" tetapi juga meningkatkan pangkalan kod.

Mereka bentuk alatan untuk model kecil

Model awan yang besar boleh pulih daripada penerangan yang buruk, jadi pembangun kadangkala terlepas pandang keperluan untuk definisi alatan yang tepat. Untuk model tempatan, ikuti prinsip-prinsip ini:

  • Fungsi yang khusus – Setiap alatan harus melakukan satu perkara sahaja. Alatan "carian" yang juga menulis fail akan mengelirukan model yang tidak dapat menjejaki tanggungjawab yang bertindih.
  • Penamaan yang tidak mengelirukan – Elakkan nama generik seperti "proses" atau "endalikan". Nama harus menyampaikan operasi yang tepat, mengurangkan beban mental model.
  • Penerangan yang jelas dan ringkas – Sertakan hanya parameter yang benar-benar diperlukan oleh model untuk membuat keputusan. Gunakan format yang konsisten supaya model dapat mengenali corak dengan cepat.

Pandangan balas: protokol ini masih mempunyai nilai

Walaupun terdapat geseran, MCP tetap menarik kerana ia mengabstraksikan kod boilerplate. Satu antara muka tunggal yang dipacu model boleh menyambung ke berpuluh-puluh perkhidmatan tanpa perlu menulis penyesuai (adapter) tersuai untuk setiap satu. Pasukan yang mampu menggunakan model skala awan melihat pembengkakan token sebagai isu yang tidak penting, dan kemudahan yang ditawarkan melebihi bebanan tersebut. Cabarannya adalah menterjemahkan kemudahan itu ke dalam dunia LLM peranti yang terhad.

Intipati

Jika anda sedang membina pembantu peranti, anggap deskripsi alatan MCP sebagai sumber yang terhad. Ringkaskan, muat secara dinamik, dan reka alatan dengan skop yang sempit untuk mengekalkan tetingkap konteks bagi perbualan sebenar. Pada masa yang sama, lindungi diri daripada model keselamatan "akses penuh" secara tersirat dengan memasukkan lapisan kebenaran, walaupun ia melibatkan penggunaan beberapa token tambahan. Keseimbangan yang anda capai akan menentukan sama ada LLM tempatan anda terasa seperti teman yang membantu atau bot sembang yang rosak.