Dalam landskap AI semasa, satu konsep menarik perhatian: MCP, atau Protokol Konteks Model. Hebatnya, perhatian di sekeliling sistem protokol ini telah mengatasi keluaran model terkini dari OpenAI, menjadi tumpuan perbincangan industri.
Lonjakan populariti teknologi Agent, didorong oleh kebangkitan Manus, telah membangkitkan semangat pembangun global. MCP, yang diposisikan sebagai ‘protokol bersatu’ untuk invokasi alat Agent, telah mendapat tarikan dengan pantas, mendapatkan sokongan daripada pemain AI utama seperti OpenAI dan Google dalam masa hanya dua bulan. Kenaikan pantas ini telah mengubah MCP daripada spesifikasi teknikal yang agak kabur menjadi standard asas dalam ekosistem AI, menandakan ‘peristiwa yang luar biasa’ dalam bidang infrastruktur AI.
Walau bagaimanapun, apabila keterujaan awal reda, soalan kritikal timbul: Adakah MCP benar-benar boleh digunakan secara universal? Adakah jangkaan untuk keupayaannya menjadi melambung?
Penerokaan ini menyelidiki asal-usul MCP, membedah kekuatan dan batasan terasnya, menjelaskan salah tanggapan yang lazim, dan meneliti potensi trajektori masa depannya. Matlamatnya bukanlah untuk menolak nilai intrinsik MCP tetapi untuk memupuk pemahaman yang lebih berasas tentang peranan dan batasannya. Hanya melalui kejelasan sedemikian potensi dapat direalisasikan sepenuhnya.
Membongkar MCP: Protokol Invokasi Alat Bersatu
Mentakrifkan MCP
MCP ialah protokol teknikal terbuka yang direka untuk menyeragamkan cara Model Bahasa Besar (LLM) berinteraksi dengan alat dan perkhidmatan luaran. Anggap ia sebagai penterjemah universal dalam dunia AI, membolehkan model AI ‘bercakap’ dengan pelbagai alat luaran. Ia menyediakan bahasa dan struktur yang sama untuk LLM meminta dan menggunakan fungsi yang ditawarkan oleh aplikasi dan perkhidmatan yang berbeza.
Keperluan untuk MCP
Sebelum kemunculan MCP, invokasi alat AI dibelenggu oleh dua cabaran utama:
- Pecahan Antara Muka: Setiap LLM menggunakan format arahan yang berbeza, manakala setiap API alat mempunyai struktur datanya yang unik. Pembangun terpaksa menulis kod sambungan tersuai untuk setiap kombinasi, yang membawa kepada proses pembangunan yang kompleks dan tidak cekap.
- Ketidakcekapan Pembangunan: Pendekatan ‘terjemahan satu-ke-satu’ ini terbukti mahal dan sukar untuk diskalakan. Ia sama seperti mengupah penterjemah khusus untuk setiap pelanggan asing, menghalang produktiviti dan ketangkasan.
MCP menangani isu ini dengan menyediakan rangka kerja yang diseragamkan untuk LLM berinteraksi dengan alat luaran, memudahkan proses pembangunan dan membolehkan kebolehskalaan yang lebih besar.
Memahami Fungsi MCP
Seni bina teknikal MCP boleh dikonseptualisasikan sebagai sistem yang terdiri daripada tiga komponen teras: Hos MCP, Klien MCP dan Pelayan MCP. Elemen-elemen ini berfungsi secara sinergi untuk memudahkan komunikasi yang lancar antara model AI dan dunia luar.
Untuk memahami peranan MCP, pertimbangkan persekitaran perusahaan moden. Dalam analogi ini:
- Pengguna mewakili eksekutif kanan, bertanggungjawab untuk memahami keperluan pengguna dan membuat keputusan akhir.
- Model Bahasa Besar (LLM) (seperti Claude atau GPT) memahami arahan eksekutif, merancang langkah tugas, menentukan bila hendak menggunakan perkhidmatan luaran dan menyatukan maklumat untuk memberikan jawapan.
- Sistem Agent berfungsi sebagai pembantu peribadi atau setiausaha eksekutif, menjalankan tugas seperti yang diarahkan.
- MCP bertindak sebagai platform komunikasi yang diseragamkan atau sistem akses perkhidmatan perusahaan yang digunakan oleh setiausaha. Ia tidak membuat keputusan tetapi sebaliknya mengikut arahan, berkomunikasi dengan pelbagai penyedia perkhidmatan dalam format dan protokol yang disatukan.
Sebelum MCP, interaksi AI dengan alat luaran adalah sama dengan era piawaian komunikasi yang huru-hara. Setiap kali setiausaha (Agent) perlu menghubungi jabatan yang berbeza atau pembekal luaran, mereka terpaksa menggunakan peranti atau perisian komunikasi yang berbeza. Ini memerlukan kebiasaan dengan sistem yang pelbagai, yang mengakibatkan ketidakcekapan. Pembangun terpaksa menulis kod sambungan yang berasingan untuk setiap alat, yang membawa kepada pembaziran masa dan kebolehskalaan yang terhad.
MCP menyelaraskan proses ini dengan menyediakan platform komunikasi yang disatukan, membolehkan setiausaha menghubungi mana-mana jabatan atau penyedia perkhidmatan menggunakan sistem dan protokol komunikasi yang sama. Pembangun hanya perlu melaksanakan antara muka MCP sekali, membolehkan sistem AI berinteraksi dengan semua alat yang menyokong protokol.
MCP: Kotak Alat Dibina Berdasarkan Panggilan Fungsi
Adalah penting untuk memahami bahawa MCP bukanlah pengganti untuk Panggilan Fungsi tradisional; sebaliknya, ia merupakan komponen pelengkap yang meningkatkan keupayaannya.
Panggilan Fungsi ialah mekanisme teras yang membolehkan LLM berinteraksi dengan alat atau API luaran. Ia merupakan keupayaan asas LLM, membolehkannya mengenal pasti apabila alat diperlukan dan jenis alat yang diperlukan.
MCP bertindak sebagai sistem klasifikasi alat, menyediakan rangka kerja berstruktur untuk menyusun dan mengakses pelbagai alat. Oleh itu, MCP tidak menggantikan Panggilan Fungsi tetapi sebaliknya berfungsi bersama-sama dengan Agent untuk menyelesaikan tugas yang kompleks.
Proses invokasi alat yang lengkap melibatkan gabungan ‘Panggilan Fungsi + Agent + Sistem MCP’.
Pada dasarnya, LLM menyatakan keperluan untuk memanggil alat tertentu melalui Panggilan Fungsi. Agent mengikut arahan untuk melaksanakan invokasi alat, manakala MCP menyediakan spesifikasi invokasi alat yang diseragamkan.
Pertimbangkan analogi berikut: seorang bos (pengguna) mahukan kopi. Di pejabat (Hos MCP), pengurus pejabat (LLM) mengarahkan setiausaha (Agent) untuk membeli Americano (Panggilan Fungsi). Setiausaha menyemak senarai pembekal dan mendapati bahawa pembekal kopi Americano telah disepadukan dengan sama ada Meituan atau sistem perolehan bersatu syarikat (melaksanakan Pelayan MCP). Setiausaha kemudian mencari pembekal dalam sistem perolehan (Klien MCP) dan membuat pesanan.
Sebelum ini, tanpa MCP, apabila LLM mengeluarkan Panggilan Fungsi, Agent akan menterjemah dan terus menyambung ke API untuk memanggil alat tersebut. Setiap API memerlukan mod invokasi yang berasingan dan senarai alat serta mod invokasi yang ditakrifkan untuk Agent mentafsir. Dengan MCP, banyak API boleh dipesan terus melalui Klien MCP pembekal, menjimatkan masa dan usaha Agent. Walau bagaimanapun, Panggilan Fungsi LLM kekal tidak berubah, masih dalam format {tool: ‘beli kopi’, ‘type’: ‘Americano’}.
Dengan membezakan antara Panggilan Fungsi dan MCP, menjadi jelas bahawa MCP tidak menentukan alat mana yang hendak digunakan, mahupun ia mengendalikan perancangan tugas atau niat pengguna. Aspek ini terletak di bawah bidang lapisan Agent. MCP hanya menyediakan antara muka alat yang disatukan, menjadi protokol standard yang diiktiraf dalam industri.
Cabaran Pembangunan MCP dan Landskap Pasaran
Teka-teki Pembangunan
Sejak Februari, komuniti pembangunan AI telah menyaksikan ‘demam emas MCP’. Dengan ketiadaan kedai aplikasi rasmi, beribu-ribu alat telah disepadukan secara sukarela dengan protokol MCP dalam tempoh tiga bulan.
Pertumbuhan pesat ini telah mendorong MCP ke tumpuan industri tetapi juga mendedahkan jurang antara aspirasi dan realiti. Pembangun pada mulanya melihat MCP sebagai ‘kunci universal’ tetapi mendapati ia lebih kepada ‘sepana khusus’, cemerlang dalam senario tertentu tetapi terbukti kurang berkesan dalam senario lain.
Peserta MCP boleh dikategorikan sebagai aplikasi klien tempatan, aplikasi klien awan dan pembangun pelayan MCP. Aplikasi tempatan serupa dengan pembantu AI tempatan, manakala aplikasi klien awan menyerupai versi ChatGPT berasaskan web. Pembangun pelayan MCP ialah penyedia alat sebenar, yang perlu membungkus semula API mereka untuk mematuhi peraturan MCP.
Kemunculan MCP pada mulanya dialu-alukan oleh aplikasi klien tempatan, tetapi aplikasi klien awan dan pembangun pelayan MCP menghadapi cabaran.
MCP berasal dari aplikasi Claude Desktop Anthropic, yang pada mulanya direka bentuk sebagai protokol antara muka untuk memanggil fail dan fungsi tempatan, berakar umbi dalam keperluan bahagian klien.
Bagi pengguna klien tempatan, MCP mewakili revolusi, menawarkan kotak alat yang boleh dikembangkan tanpa had yang membolehkan pengguna terus mengembangkan keupayaan pembantu AI mereka.
Aplikasi klien tempatan seperti Cursor dan Claude Desktop telah memanfaatkan MCP untuk membolehkan pengguna menambah alat secara dinamik berdasarkan keperluan individu, mencapai pengembangan keupayaan pembantu AI tanpa had.
MCP menangani isu utama dalam pembangunan klien tempatan: cara membolehkan aplikasi AI berinteraksi dengan lancar dengan persekitaran tempatan dan alat luaran tanpa membangunkan antara muka berasingan untuk setiap alat. Protokol bersatu ini dengan ketara mengurangkan kos penyepaduan, menyediakan syarikat permulaan kecil dan pembangun individu jalan pintas untuk membina aplikasi AI kaya ciri dengan sumber yang terhad.
Walau bagaimanapun, daya tarikan MCP berkurangan apabila mempertimbangkan pembangunan bahagian pelayan (Pelayan MCP) dan klien awan. Versi awal MCP menggunakan mekanisme pautan dwi untuk pelayan awan (jauh), menggunakan sambungan panjang SSE untuk tolakan mesej sehala daripada pelayan ke klien dan sambungan pendek HTTP untuk menghantar mesej.
Pendekatan ini berfungsi dengan baik untuk maklum balas dan intervensi pengguna yang tepat pada masanya tetapi mewujudkan satu siri cabaran kejuruteraan dalam persekitaran bahagian pelayan.
Pertama, melaksanakan antara muka MCP mewakili beban kerja tambahan untuk penyedia perkhidmatan perusahaan besar, tanpa semestinya memberikan faedah yang sepadan. Perkhidmatan ini selalunya mempunyai sistem API yang matang, dan menyediakan lapisan penyesuaian MCP tambahan mungkin hanya meningkatkan kos penyelenggaraan tanpa mewujudkan nilai yang besar. Banyak aplikasi peringkat perusahaan lebih suka mekanisme invokasi alat yang tertutup dan boleh dikawal berbanding ekosistem terbuka MCP.
Selain itu, untuk mengendalikan invokasi konkurensi tinggi, perkhidmatan MCP selalunya perlu diskalakan kepada seni bina berbilang pelayan. Model sambungan dwi MCP memperkenalkan kerumitan pengalamatan merentas mesin. Apabila sambungan panjang diwujudkan pada satu pelayan, dan permintaan dihala ke pelayan lain, mekanisme baris gilir siaran tambahan diperlukan untuk menyelaraskan sambungan teragih ini, yang ketara meningkatkan kesukaran pelaksanaan dan kos penyelenggaraan.
Kedua, MCP mempunyai batasan dalam bidang aplikasi awan. Agent AI awan (Agent bahagian pelayan) biasanya berjalan dalam perkhidmatan tanpa keadaan, memproses tugas selepas penerimaan dan melepaskan sumber selepas selesai. Menggunakan Klien MCP di bahagian pelayan memerlukan penciptaan sementara pautan SSE, menghantar permintaan invokasi alat, menerima hasil daripada SSE dan kemudian menutup pautan SSE, yang merupakan pendekatan tidak cekap yang meningkatkan kerumitan dan mengurangkan prestasi. Permintaan RPC tunggal sepatutnya mencukupi dalam senario ini.
Dalam praktiknya, aplikasi awan yang menggunakan MCP selalunya bergantung pada set alat pratetap dan tidak menggunakan keupayaan tandatangan MCP bagi penemuan alat dinamik dan pemuatan fleksibel.
Mod interaksi data persekitaran awan menghadkan keupayaan untuk menggunakan alat secara bebas seperti yang dimaksudkan oleh MCP. Ia memerlukan proses yang sangat standard untuk memanggil alat berkod keras tertentu, mengorbankan fleksibiliti.
Pasukan MCP telah menunjukkan responsif terhadap maklum balas pengguna. Selepas menerima maklum balas daripada pembangun bahagian pelayan, MCP mengemas kini protokolnya pada 26 Mac, menggantikan pengangkutan SSE asal dengan pengangkutan HTTP boleh strim. Protokol baharu menyokong kedua-dua senario perkhidmatan tanpa keadaan yang hanya memerlukan permintaan invokasi alat tunggal dan keperluan tolakan masa nyata yang sebelum ini dipenuhi melalui pautan dwi HTTP + SSE.
Penambahbaikan ini mencadangkan bahawa isu MCP semasa berpunca daripada batasan reka bentuk awal tetapi tidak dapat diatasi.
Kekacauan Pasaran
Satu lagi cabaran yang dihadapi oleh MCP ialah kebolehgunaan yang rendah bagi banyak pelaksanaan di pasaran.
Pasaran MCP semasa sedang mengalami kitaran gembar-gembur teknologi yang tipikal. Sama seperti kekacauan Kedai Apl awal, kurang daripada 20% daripada beribu-ribu alat MCP yang tersedia pada masa ini mempunyai nilai praktikal. Banyak pelaksanaan mempunyai isu yang serius, daripada ralat konfigurasi mudah hingga tidak boleh digunakan sepenuhnya. Sesetengahnya tergesa-gesa ke pasaran tanpa ujian yang mencukupi, manakala yang lain merupakan produk eksperimen yang tidak pernah dimaksudkan untuk kegunaan praktikal.
Isu yang lebih asas ialah banyak pelaksanaan MCP mungkin tidak diperlukan oleh pasaran. Banyak alat yang ditawarkan melalui MCP hanyalah API yang dibungkus semula yang sudah tersedia dan digunakan sebelum kemunculan MCP, menambah sedikit nilai unik.
Sebagai contoh, berpuluh-puluh perkhidmatan carian ditawarkan melalui MCP, tetapi kualitinya berbeza dengan ketara. Sesetengah perkhidmatan mungkin tidak tepat atau perlahan, menjadikannya kurang diingini berbanding penyelesaian sedia ada.
Selain itu, MCP kekurangan sistem penilaian yang teguh, yang menyukarkan Agent untuk memilih alat yang paling sesuai berdasarkan metrik yang boleh dipercayai. Proses pemilihan yang tidak cekap ini membazirkan sumber pengkomputeran, memanjangkan masa penyelesaian tugas dan merendahkan pengalaman pengguna.
Kekurangan sistem penilaian menyukarkan agent untuk memilih alat yang paling sesuai. Jika berbilang perkhidmatan MCP menawarkan alat dengan nama dan penerangan yang serupa, ejen mungkin bergelut untuk memilih pilihan terbaik, yang membawa kepada pembaziran token dan pengurangan kecekapan.
Aplikasi AI yang paling berjaya selalunya mengambil pendekatan yang bertentangan, menyediakan alat yang lebih tepat dan bukannya kuantiti alat yang lebih besar. Manus, sebagai contoh, memilih untuk membina aplikasi dalaman dan bukannya menerima pakai protokol MCP, walaupun ia wujud. Manus mengutamakan ketepatan dan kestabilan panggilan berbanding penyepaduan dengan ekosistem MCP.
Editor kod seperti Cursor mempunyai fungsi pembangunan terbina dalam, menjadikan kebanyakan alat MCP luaran berlebihan.
Keadaan huru-hara pasaran MCP pada masa ini tidak semestinya menjadi tanda kegagalan tetapi sebaliknya peringkat pertumbuhan yang diperlukan untuk mana-mana ekosistem teknologi baru muncul. Preseden sejarah mencadangkan bahawa pengembangan berlebihan awal ini secara beransur-ansur akan menumpu melalui mekanisme pemilihan pasaran, meninggalkan unsur yang paling berharga.
Proses ini akan membolehkan industri belajar daripada cabaran semasa dan mewujudkan rangka kerja MCP yang lebih kukuh dan boleh dipercayai. Sama seperti bagaimana gelembung dot-com membawa kepada inovasi yang mengubah permainan dalam e-dagang dan media sosial, trend MCP mungkin membawa kepada ekosistem alat yang lebih diperkemas dan berharga.
Sikap terbuka pasukan MCP terhadap maklum balas pengguna adalah menggalakkan, dan industri memerlukan alat yang lebih baik untuk menilai dan memastikan kualiti perkhidmatan MCP, yang akan membantu menjadikan ekosistem lebih boleh digunakan.
MCP Baik, Bukan Penawar
Isu yang disebutkan di atas datang daripada batasan dan kekurangan MCP, menyerlahkan perkara yang boleh dicapai secara realistik. Walau bagaimanapun, kritikan lain datang daripada jangkaan yang tidak realistik.
Satu kritikan baru-baru ini melabel MCP sebagai protokol yang cacat kerana ia tidak menentukan corak interaksi antara LLM dan MCP.
Sesetengah menjangkakan MCP untuk meningkatkan secara automatik pembuatan keputusan sistem AI atau meningkatkan kecekapan perancangan tugas. Jangkaan ini mengelirukan alat dengan artisan.
Isu ini berpunca daripada ketidakpadanan kognitif – menjangkakan protokol komunikasi untuk melaksanakan tugas sistem pintar. Ini seperti menyalahkan USB kerana tidak menyunting foto atau menyalahkan piawaian 5G kerana tidak menulis kod. MCP terutamanya ‘soket alat’ yang diseragamkan, memastikan keserasian palam dan bukannya menentukan perkakas mana yang hendak digunakan atau cara.
Keberkesanan invokasi alat Agent bergantung pada faktor seperti kecekapan pemilihan alat, kemahiran merancang tugas dan pemahaman konteks, yang mana tiada satu pun yang termasuk dalam bidang kuasa MCP. MCP hanya menjamin antara muka alat yang diseragamkan, bukan cara alat tersebut akan dipilih dan digabungkan.
Kita sering mencari peluru perak dalam teknologi, penyelesaian yang boleh digunakan secara universal. Seperti aksiom ‘tiada peluru perak’ kejuruteraan perisian, penggunaan alat AI tidak mempunyai penyelesaian ajaib. Sistem AI yang kukuh memerlukan komponen yang direka bentuk: LLM untuk memahami dan menjana, rangka kerja Agent untuk merancang dan melaksanakan serta MCP yang memfokuskan pada antara muka alat yang disatukan.
MCP menunjukkan reka bentuk protokol yang baik – memfokuskan pada satu masalah dan menyelesaikannya dengan baik, bukannya semua. Kekangan membantu ia maju dalam penyepaduan alat bahagian klien.
Entiti seperti Qwen Alibaba, ‘Xinxiang’ Baidu dan Kouzi Space ByteDance menerima protokol MCP, cuba mewujudkan ekosistem MCP dalaman yang lebih cekap.
Walau bagaimanapun, terdapat perbezaan utama dalam penggunaan: Baidu dan ByteDance lebih agresif. Baidu cuba pendekatan hujung C, menyepadukan beberapa model AI dan alat luaran melalui ‘Xinxiang’ (Kokone) yang memanfaatkan protokol MCP, terutamanya untuk peranti mudah alih, untuk disepadukan ke dalam kehidupan harian pengguna dan menggalakkan penggunaan.
Kouzi Space ByteDance mempunyai 60+ pemalam sambungan MCP. Diakses melalui halaman web, ia juga melancarkan IDE asli AI, Trae, yang menyokong MCP, terutamanya menyasarkan senario produktiviti.
Alibaba menyepadukan protokol MCP ke dalam produk seperti Alipay, membolehkan invokasi alat AI satu klik dan sumber terbuka model Qwen3, yang menyokong protokol MCP, meningkatkan keupayaan Agentnya.
Pembangun Tencent Cloud mengeluarkan suit pembangunan AI yang menyokong perkhidmatan pengehosan pemalam MCP. Enjin pengetahuan model besar Tencent Cloud membolehkan pengguna memanggil pemalam MCP. Ejen pintar pembangunan perisian Craft yang dilancarkan oleh CodeBuddy Tencent Cloud serasi dengan ekosistem terbuka MCP. Selain itu, Tencent Maps dan Tencent Cloud Storage telah mengeluarkan PELAYAN MCP mereka sendiri.
Penggunaan alat AI mungkin berkembang daripada operasi alat tunggal langsung kepada kerjasama Agent profesional, sama seperti gaya pengaturcaraan berkembang daripada bahasa himpunan kepada orientasi objek.
Dalam paradigma ini, MCP mungkin hanya menjadi sebahagian daripada infrastruktur asas, dan bukannya antara muka yang menghadap pengguna atau pembangun. Pelan yang lebih lengkap mungkin memerlukan seni bina seperti Agent to Agents (A2A) untuk meningkatkan perancangan tugas dan kecekapan pemilihan alat dengan meningkatkan tahap abstraksi.
Dengan mengembalikan MCP kepada peranannya sebagai ‘protokol’, kita boleh mengiktiraf kuasa sebenar untuk memacu penyeragaman industri – ini mungkin menjadi detik ‘penyahmistifikasi’ yang paling dihargai dalam evolusi teknologi.