Model Context Protocol ( MCP ) berjanji untuk memudahkan cara agen AI berhubung dengan alat luaran, tetapi pembangun membangkitkan kebimbangan serius mengenai keselamatan pengesahan dan kemerosotan prestasi. Walaupun MCP telah mendapat tarikan sebagai cara piawai untuk mendedahkan alat kepada model bahasa yang besar, cabaran pelaksanaan dunia sebenar menyebabkan sesetengah pihak mempersoalkan nilai praktikalnya.
Komponen Seni Bina MCP:
- Aplikasi Hos: Aplikasi sembang atau IDE (seperti Cursor) dengan klien MCP
- Klien MCP: Mengendalikan komunikasi dengan pelayan MCP
- Pelayan MCP: Mendedahkan alatan, gesaan, sumber, atau sampel
- Protokol Komunikasi: Berasaskan JSON-RPC dengan pengesahan dan penemuan
Mimpi Ngeri Pengesahan Mengancam Penggunaan Perusahaan
Salah satu isu paling mendesak yang dihadapi MCP ialah sistem pengesahannya yang rosak. Pembangun melaporkan bahawa menyediakan sambungan selamat adalah tidak perlu kompleks dan rapuh, terutamanya apabila aliran OAuth terlibat. Pendekatan semasa sering memerlukan penyimpanan token pengesahan teks biasa di lokasi yang terkenal pada mesin tempatan, mewujudkan apa yang dipanggil oleh seorang pembangun yang sedar keselamatan sebagai impian topi hitam.
Bagi pengguna perusahaan, masalah pengesahan amat menyusahkan. Pasukan pemasaran yang ingin menggunakan pelayan MCP Google Analytics menghadapi tugas yang menakutkan untuk menavigasi persediaan Google Cloud dan berkongsi kelayakan akaun perkhidmatan - proses yang begitu kompleks sehingga ia menghalang pengguna bukan teknikal daripada penggunaan.
Kekacauan pengesahan telah membawa kepada perpecahan dalam komuniti. Sesetengah pembangun menolak untuk pelayan MCP jauh yang berjalan dalam bekas terpencil dengan pengurusan identiti yang betul, manakala yang lain berpegang pada pelaksanaan tempatan walaupun terdapat risiko keselamatan. Perpecahan ini menjejaskan matlamat MCP untuk mencipta standard universal.
Masalah Utama MCP yang Dikenal Pasti:
- Pengesahan: Token plaintext disimpan di lokasi yang diketahui umum
- Prestasi: Definisi alat menggunakan ruang tetingkap konteks yang berharga
- Kerumitan: Persediaan OAuth memerlukan kepakaran teknikal untuk kegunaan perusahaan
- Beban Berlebihan Alat: Lebih banyak alat yang tersedia boleh merendahkan pembuatan keputusan AI
- Penemuan: Semua alat didedahkan terlebih dahulu tanpa mengira kaitan
Beban Berlebihan Alat Merendahkan Prestasi AI
Penemuan mengejutkan di kalangan pembangun AI ialah lebih banyak alat tidak selalu bermakna prestasi yang lebih baik. Apabila agen mempunyai akses kepada berpuluh-puluh atau beratus-ratus alat melalui MCP , pembuatan keputusan mereka sebenarnya menjadi lebih teruk. Masalah ini berpunca daripada batasan tetingkap konteks - setiap definisi alat mengambil ruang berharga yang boleh digunakan untuk perbualan sebenar atau maklumat khusus tugas.
Hanya dengan menyediakan lebih banyak alat boleh memberikan agen lebih banyak keupayaan, tetapi ia boleh dengan mudah merosakkan prestasi.
Kemerosotan prestasi ini telah memaksa pembangun untuk memilih secara manual alat mana yang boleh diakses oleh agen mereka, mengalahkan sebahagian besar kemudahan yang dijanjikan MCP . Ada yang beralih kepada penyelesaian gateway yang menapis dan menyusun alat sebelum mempersembahkannya kepada AI , menambah satu lagi lapisan kerumitan kepada apa yang sepatutnya menjadi protokol yang memudahkan.
Proses penemuan alat dalam MCP juga menyumbang kepada masalah tersebut. Apabila sistem AI berhubung dengan pelayan MCP , ia menerima maklumat tentang semua alat yang tersedia terlebih dahulu, tanpa mengira sama ada ia berkaitan dengan tugas semasa. Ini mewujudkan masalah nisbah isyarat kepada bunyi yang merendahkan keupayaan AI untuk memberi tumpuan kepada kerja sebenar.
Komuniti Mempersoalkan Cadangan Nilai Teras MCP
Selain isu teknikal, pembangun mempersoalkan sama ada MCP menyelesaikan masalah sebenar. Ramai yang menunjukkan bahawa API REST sedia ada dengan dokumentasi OpenAPI sudah menyediakan penemuan alat dan antara muka piawai. Lapisan MCP tambahan kelihatan berlebihan apabila model AI sudah boleh bekerja dengan skema JSON dan titik akhir HTTP .
Model pelayan MCP tempatan, di mana pembangun memuat turun dan menjalankan pelayan alat pada mesin mereka, berasa amat dipersoalkan kepada ramai. Untuk fungsi mudah seperti mendapatkan tarikh semasa atau membuat panggilan API , mengimport pakej alat kelihatan lebih mudah daripada menjalankan proses pelayan yang berasingan.
Sesetengah pembangun melihat masa depan MCP dalam organisasi besar di mana pasukan berbeza perlu mendedahkan kepakaran domain mereka kepada sistem AI seluruh syarikat. Dalam senario ini, MCP boleh menyediakan pemisahan kebimbangan yang membolehkan pasukan backend memiliki definisi alat mereka manakala pasukan frontend membina antara muka AI . Walau bagaimanapun, kes penggunaan perusahaan ini sebahagian besarnya kekal teori.
Pendekatan Alternatif yang Disebut:
- REST APIs Langsung: Menggunakan titik akhir HTTP sedia ada dengan dokumentasi OpenAPI
- Import Pakej: Memasukkan definisi alat sebagai perpustakaan kod
- Penyelesaian Gateway: Menapis dan menyusun alat sebelum akses AI
- Pelaksanaan Tersuai: Membina panggilan alat tanpa penyeragaman MCP
 |
|---|
| Meneroka kerumitan dan redundansi Model Context Protocol dalam penemuan alat dalam sistem AI |
Jalan Ke Hadapan Masih Tidak Jelas
Walaupun terdapat kritikan, MCP bukan tanpa pembela. Penyokong berhujah bahawa seperti USB , MCP mungkin berkembang melampaui kes penggunaan tertumpu AI asalnya untuk menjadi protokol integrasi tujuan umum. Asas JSON-RPC dan mekanisme penemuan terbina dalam boleh menjadikannya berguna untuk komunikasi sistem ke sistem walaupun tanpa penglibatan AI .
Kelebihan terbesar protokol mungkin adalah masanya. Memandangkan panggilan alat AI menjadi lebih biasa, mempunyai sebarang standard adalah lebih baik daripada landskap terpecah-belah semasa pelaksanaan tersuai. Walau bagaimanapun, isu pengesahan dan prestasi memerlukan penyelesaian sebelum MCP boleh mencapai penggunaan perusahaan yang meluas.
Buat masa ini, pembangun nampaknya mengambil pendekatan menunggu dan melihat. Mereka yang membina aplikasi AI mudah sering melangkau MCP sepenuhnya, manakala organisasi yang lebih besar bereksperimen dengan penyelesaian gateway untuk menangani batasan semasanya. Kejayaan protokol berkemungkinan bergantung pada sama ada masalah asas ini diselesaikan dalam versi akan datang.