Kebolehkendalian Alat Pengekodan dengan MCP dan A2A

Laman Utama » Python » Kebolehkendalian Alat Pengekodan dengan MCP dan A2A

Ejen AI bukan lagi sekadar chatbot mewah yang menjawab soalan dalam satu tetingkap. Mereka bertukar menjadi sistem teragih yang boleh membaca dan menulis kod, memanggil API, menyelaras dengan perkhidmatan lain dan juga berunding dengan ejen lain untuk menyelesaikan kerja. Sebaik sahaja anda beralih daripada "satu pembantu pintar" kepada "rangkaian ejen", masalah besar akan muncul: bagaimana semua bahagian ini boleh berhubung antara satu sama lain tanpa menjadi huru-hara?

Itulah sebenarnya jurang yang cuba diisi oleh MCP (Protokol Konteks Model) dan A2A (Protokol Ejen-ke-Ejen). MCP memberi tumpuan kepada bagaimana ejen berhubung dengan alatan, data dan konteks, manakala A2A memberi tumpuan kepada bagaimana ejen berkomunikasi dan bekerjasama antara satu sama lain. Kesemuanya bertindih dalam semangat tetapi beroperasi pada lapisan yang berbeza. Dalam artikel ini, kita akan membincangkan secara mendalam apa yang dilakukan oleh setiap satunya, bagaimana ia saling melengkapi, bagaimana ia telah digunakan dalam sistem sebenar dan apa maksudnya untuk masa depan alatan pengekodan dan seni bina berbilang ejen.

Apakah sebenarnya MCP dalam praktiknya

Pada terasnya, MCP ialah cara standard untuk mendedahkan alatan, sumber dan gesaan kepada ejen AI supaya ejen tersebut boleh memanggilnya dengan selamat dan konsisten. Daripada menyambungkan setiap alat terus ke setiap ejen dengan kod gam tersuai, anda mendedahkan alat tersebut di sebalik pelayan MCP dan membiarkan klien MCP (ejen) menemui dan memanggilnya melalui protokol bersatu.

MCP mengikuti seni bina klien-pelayan yang jelas: Aplikasi hos (seperti editor, CLI atau masa jalan ejen) membenamkan klien MCP dan klien tersebut membuka sambungan satu sama lain kepada satu atau lebih pelayan MCP. Setiap pelayan hanyalah proses ringan yang mendedahkan sekumpulan keupayaan – biasanya alatan, sumber baca sahaja dan gesaan yang boleh diguna semula.

Inspirasi ini sangat hampir dengan Protokol Pelayan Bahasa (LSP). LSP mengabstrakkan masalah “ciri bahasa editor ↔” supaya kami tidak perlu menulis integrasi tersuai antara setiap editor dan setiap bahasa pengaturcaraan. Jika anda melaksanakan pelayan bahasa sekali, mana-mana editor yang serasi dengan LSP boleh bercakap dengannya. MCP mengambil idea yang sama dan mengaplikasikannya pada alatan dan konteks untuk LLM: melaksanakan alatan sekali sebagai pelayan MCP dan setiap ejen yang menyedari MCP boleh menggunakannya.

Dari sudut pandangan pengangkutan, MCP fleksibel tetapi cukup berpendirian untuk menjadi praktikal. Ia menggunakan JSON‑RPC 2.0 sebagai format mesej dan menyokong berbilang pengangkutan: stdio untuk proses setempat (hebat untuk aplikasi desktop dan pembangunan setempat) dan HTTP atau SSE untuk pelayan jauh (sesuai untuk Cloud Run atau penggunaan kontena). Protokol ini juga mentakrifkan cara klien menemui keupayaan dan cara alatan diterangkan menggunakan Skema JSON supaya LLM boleh memutuskan bila dan cara untuk memanggilnya.

Yang penting, MCP tidak cuba mengatur penaakulan ejen anda. Ia tidak memutuskan apabila sesuatu alat harus digunakan, atau bagaimana alat harus dirangkaikan. MCP ialah lapisan pendawaian: ia menyediakan alat, sumber dan gesaan dengan cara yang berstruktur dan boleh ditemui, menyerahkan proses membuat keputusan kepada rangka kerja ejen, perancang atau kejuruteraan gesaan anda.

Blok binaan MCP teras: alat, sumber dan gesaan

Pelayan MCP berkisar tentang tiga primitif utama: alat, sumber dan gesaan. Tiga konsep ini sudah cukup untuk menampung kebanyakan keperluan ejen dunia sebenar tanpa mengubah protokol menjadi rangka kerja orkestrasi penuh.

Alat ialah tindakan diskret yang boleh dicetuskan oleh ejen. Fikirkan "get_weather","search_inventory","book_flight","run_sql_query"Atau"get_exchange_rateSetiap alat diisytiharkan dengan nama, penerangan yang boleh dibaca oleh manusia dan skema input. Skema itulah yang membolehkan LLM memahami parameter yang harus dilaluinya dan ia juga melindungi bahagian belakang anda dengan mengesahkan argumen sebelum pelaksanaan.

Sumber mewakili data baca sahaja yang boleh dilayan oleh pelayan atas permintaan. Fail, log, baris pangkalan data, coretan dokumentasi, fail konfigurasi – sebarang maklumat yang dimodelkan dengan lebih baik sebagai "ambil benda ini" daripada "jalankan fungsi ini". Sumber boleh jadi besar, jadi MCP mentakrifkan cara untuk memasukkan dan menstrimnya, yang penting apabila memasukkan konteks ke dalam model dengan tetingkap terhad.

Gesaan ialah templat yang boleh diguna semula yang boleh dipaparkan oleh pelayan kepada klien. Daripada mengekodkan rentetan gesaan yang panjang dan rapuh di dalam ejen anda, anda boleh memusatkannya sebagai gesaan MCP. Pelayan mendedahkannya dengan nama, perihalan dan slot parameter, dan klien mengisi slot tersebut semasa masa jalan. Ini sangat berkesan apabila berbilang ejen perlu berkongsi corak yang sama tentang cara bercakap dengan alat tertentu atau mematuhi peraturan keselamatan dan pematuhan seluruh syarikat.

Apabila klien bersambung ke pelayan, ia akan melaksanakan langkah penemuan keupayaan. Pelayan akan bertindak balas dengan katalog alatan, sumber dan gesaan, setiap satu dengan metadata terperinci. Katalog tersebut kemudiannya dimasukkan ke dalam LLM (biasanya dalam bentuk ringkasan) supaya model boleh membuat penaakulan: “Saya boleh menggunakan get_exchange_rate untuk menjawab soalan tentang penukaran mata wang ini, dan saya tidak sepatutnya cuba mereka-reka jawapannya.”

Oleh kerana semua ini adalah deklaratif, keupayaan baharu boleh ditambah atau dialih keluar tanpa menyentuh logik teras ejen. Tambahkan alat baharu pada pelayan, gunakan semula dan setiap klien MCP yang bersambung akan melihatnya pada rundingan keupayaan seterusnya. Ini adalah detik "pasang satu lagi peranti USB" untuk perkakasan AI.

Contoh MCP yang konkrit: alat penukaran mata wang

Demo ejen mata wang daripada Kit Pembangunan Ejen (ADK) Google ialah ilustrasi sempurna MCP dalam tindakan. Ia bermula dengan membina pelayan MCP kecil yang mendedahkan satu alat, get_exchange_rate, disokong oleh API Frankfurter awam. Pada cakera, ia hanyalah skrip Python kecil yang menggunakan fastmcp.

Pelayan mentakrifkan alat dengan argumen yang ditaip untuk currency_from, currency_to dan currency_date, serta pengelogan dan pengendalian ralat yang mantap. Apabila ejen memanggilnya, pelayan akan menghubungi Frankfurter melalui HTTP, mengesahkan respons dan mengembalikan muatan JSON dengan kadar pertukaran atau objek ralat. Tiada apa-apa tentang perkara ini yang khusus untuk AI; MCP hanya menyeragamkan cara fungsi ini diterangkan dan digunakan.

Secara setempat, anda menjalankan pelayan dengan arahan mudah dan ia mendengar http://localhost:8080. Klien ujian berasingan, yang juga menggunakan MCP, menyambung, menemui get_exchange_rate dan mencetuskan panggilan untuk USD → EUR. Log menunjukkan pemanggilan alat, permintaan HTTP keluar, respons yang berjaya dan JSON yang dikembalikan. Dari sudut pandangan ejen anda, ia hanya bertanya "alat apa yang saya ada?" dan kemudian "sila panggil yang ini".

Menggunakan pelayan yang sama ke Cloud Run hampir tidak mengubah ceritanya. Anda menyimpan pelayan MCP dalam bekas, menggunakan --no-allow-unauthenticated jadi ia memerlukan pengesahan yang disokong IAM, dan kemudian membuka terowong selamat daripada mesin tempatan anda menggunakan arahan proksi Cloud Run. Secara setempat, klien MCP anda masih menganggap ia sedang bercakap dengan http://127.0.0.1:8080; proksi mengendalikan auth dan hop rangkaian secara telus.

Corak ini berkuasa dalam pasukan: anda boleh menjalankan pelayan MCP berpusat untuk alatan kongsi seperti kadar mata wang, API dalaman atau pangkalan data proprietari. Setiap ejen pembangun dalam organisasi boleh menyambung ke pelayan tersebut melalui pengangkutan yang selamat dan bukannya menghantar pembalutnya sendiri yang sedikit berbeza dan separuh diselenggara di sekitar API yang sama.

Ejen bangunan di atas MCP: daripada alat tunggal kepada aliran kerja penuh

MCP menjadi sangat menarik apabila anda membenamkannya ke dalam rangka kerja ejen seperti ADK Google. Dalam contoh ejen mata wang, ADK digunakan untuk mencipta ejen LLM khusus yang tugasnya hanyalah menjawab soalan tentang kadar pertukaran menggunakan alat MCP. Arahan sistem ejen secara literalnya memberitahunya: "tujuan tunggal anda adalah untuk menggunakan get_exchange_rate alat”.

ADK akan menyambungkan arahan ini, model yang dipilih (contohnya gemini-2.5-flash) dan a MCPToolset contoh yang menunjukkan URL pelayan MCP. Mulai dari itu, apabila pengguna bertanya "Berapakah harga 250 CAD dalam USD?", ejen akan membuat pertimbangan sama ada ia memerlukan panggilan alat, mengisi parameter alat, menghantar permintaan melalui MCP dan kemudian menulis respons mesra pengguna menggunakan JSON yang dikembalikan.

Corak yang sama berskala kepada ejen yang jauh lebih kompleks. Daripada API mata wang tunggal, anda boleh menyambungkan berbilang pelayan melalui wayar: satu untuk pangkalan data dalaman, satu lagi untuk SaaS pihak ketiga, satu lagi untuk carian dokumen, serta pelayan yang mendedahkan gesaan boleh guna semula atau saluran paip RAG. MCP tidak kisah sama ada pelayan tersebut berjalan secara setempat, pada Cloud Run, dalam Kubernetes atau di sebalik VPN, selagi pengangkutan disokong dan pengesahan dikonfigurasikan dengan betul.

ADK juga menambah perspektif yang mengutamakan ejen yang sengaja dielakkan oleh MCP. Ia melayan ejen sebagai komponen perisian yang boleh dikompos: anda boleh mentakrifkan ejen berasaskan LLM, ejen yang banyak menggunakan alatan, ejen penilaian dan orkestrator, semuanya mampu menggunakan MCP secara langsung. Hasilnya ialah "bina ejen" mula kelihatan lebih seperti "bina perkhidmatan mikro" dan kurang seperti "ubah suai gesaan tanpa henti dalam buku nota".

Apakah A2A – dan mengapa MCP sahaja tidak mencukupi

Jika MCP adalah tentang ejen pendawaian kepada alat, A2A adalah tentang ejen pendawaian kepada ejen lain. Sebaik sahaja anda mempunyai berbilang ejen yang setiap satunya tahu cara melakukan sesuatu dengan baik, anda memerlukan cara untuk mereka mencari satu sama lain, bertukar tugas dan kekal selaras semasa kerja sedang dijalankan. Itulah ruang masalah yang direka untuk A2A.

A2A, yang dimulakan oleh Google Cloud dan kini di bawah Yayasan Linux, merupakan standard terbuka untuk kebolehkendalian ejen-ke-ejen. Ia menggunakan teknologi yang biasa (HTTP(S), JSON‑RPC 2.0 dan SSE untuk penstriman) tetapi membungkusnya dalam model domain yang memahami ejen, kemahiran, tugas, artifak dan keupayaan. Daripada "panggilan alat", anda mendapat bahasa kerjasama peringkat tinggi.

Dua idea teras dalam A2A ialah Kad Ejen dan Tugasan. Kad Ejen ialah dokumen JSON – biasanya boleh ditemui di /.well-known/agent.json – yang menerangkan apa yang boleh dilakukan oleh ejen, cara untuk mencapainya, pengesahan yang dijangkakan dan mod input/output yang disokongnya. Tugasan ialah unit kerja yang boleh dihantar oleh satu ejen kepada ejen yang lain, dengan kitaran hayat yang jelas dan hasil yang berstruktur.

Dalam interaksi A2A, seorang ejen memainkan peranan sebagai "ejen klien" dan seorang lagi bertindak sebagai "ejen jarak jauh". Klien menemui kad ejen jarak jauh, memutuskan sama ada ini rakan kongsi yang tepat untuk tugas tersebut, dan kemudian membuat permintaan tugas. Ejen jarak jauh menerima tugas tersebut, menggunakan LLM dan alatan dalamannya sendiri (selalunya melalui MCP) untuk melaksanakannya, dan kemudian menstrim kembali kemas kini kemajuan dan artifak akhir.

Reka bentuk ini menjadikan A2A secara aslinya bersifat titik-ke-titik, tak segerak dan mesra rangkaian. Di sebalik itu, pelaksanaan Python dibina berdasarkan rangka kerja ASGI seperti Starlette (melalui A2AStarletteApplication) dan uvicorn, dengan artifak dan kemas kini tugas yang mengalir melalui JSON‑RPC dan SSE. Ini bermakna tugas boleh dijalankan selama beberapa saat atau jam tanpa menyekat satu permintaan HTTP pun, yang penting untuk aliran kerja berbilang ejen dunia sebenar.

Contoh A2A: mendedahkan ejen "Helo" dan seterusnya

A2A kanonik “HelloWorldAgent” menunjukkan mekanik dalam bentuk yang ringkas. Anda mentakrifkan satu AgentExecutor subkelas yang melaksanakan execute kaedah. Di dalam, anda memasukkan satu mesej teks – “Helo dari A2A!” – ke dalam barisan acara sebagai hasil tugasan. Pembatalan menjadi tidak dibenarkan untuk kes mudah ini, tetapi cangkuknya wujud untuk beban kerja sebenar.

Seterusnya anda mencipta AgentSkill menerangkan apa yang boleh dilakukan oleh ejen ini. Dalam contoh tersebut, kemahiran hello membawa nama, perihalan, satu set tag dan pertanyaan pengguna yang mewakili. Kemahiran itu kemudiannya digabungkan ke dalam AgentCard bersama-sama dengan nama, versi, URL, keupayaan dan mod input/output yang disokong oleh ejen.

Akhirnya, anda menghubungkan semuanya ke dalam A2AStarletteApplication dengan DefaultRequestHandler dan jalankannya di bawah uvicorn. Bagi dunia luar, kini anda mempunyai ejen A2A yang serba lengkap yang mendengar http://localhost:9000Mana-mana pelanggan yang menyokong A2A boleh mengambil /.well-known/agent.json, fahami apa yang ditawarkan oleh ejen ini dan hantarkan tugasan kepadanya.

Dalam penggunaan yang lebih realistik, corak yang sama akan diskalakan kepada senario orkestrasi seperti tempahan perjalanan, onboarding atau automasi sokongan. "Ejen Pelancongan" mungkin menemui dan bercakap dengan "Ejen Penerbangan", "Ejen Hotel" dan "Ejen Sewa Kereta", setiap satunya beroperasi di sebalik titik akhir A2Anya sendiri dan menyembunyikan perkakasan dalamannya dan kontrak API khusus vendor. Ejen Pelancongan hanya melihat tugasan, kemahiran dan artifak.

Di sinilah pemisahan kebimbangan A2A menonjol. Setiap ejen hiliran boleh memilih model, rangka kerja dan alatannya sendiri – ejen hotel yang dibina dengan ADK dan MCP, ejen syarikat penerbangan yang dibina dengan susunan lain, ejen penyewaan kereta yang berada dalam infrastruktur rakan kongsi – dan semuanya masih bekerjasama dengan bersih melalui permukaan A2A.

Menggabungkan MCP dan A2A dalam satu seni bina

Di atas kertas, perpecahan itu kedengaran kemas – MCP untuk alat, A2A untuk ejen – tetapi dalam praktiknya sempadannya kabur dengan cepat. Sistem sebenar selalunya mahu menyembunyikan A2A di sebalik MCP, melapisi MCP di dalam A2A atau menggabungkan kedua-duanya dalam proses yang sama. Sampel rasmi A2A juga membungkus komunikasi A2A sebagai alat MCP yang terdedah daripada satu pelayan, supaya LLM melihat "satu set alat MCP" dan bukannya dua susunan protokol selari.

Satu corak biasa adalah untuk menganggap MCP sebagai pendawaian dalaman setiap ejen dan A2A sebagai rangkaian luaran antara ejen. Di dalam ejen, LLM anda memanggil alat MCP untuk mencapai pangkalan data, API atau stor dokumen. Di luar, orchestrator anda bercakap dengan ejen tersebut melalui A2A, menyerahkan tugasan dan membaca kembali artifak. Dari perspektif orchestrator, ejen tersebut ialah perkhidmatan kotak hitam dengan antara muka yang bersih dan ditaip.

Corak terbalik – yang memaparkan A2A sebagai alat MCP – adalah menarik dari sudut pandangan penyepaduan. Banyak penyedia LLM sudah mempunyai perkakasan yang digilap di sekitar MCP: devtools, demo UI, SDK dan panduan keselamatan. Dengan mendedahkan "hubungi ejen jauh X" sebagai alat MCP tunggal, anda membiarkan LLM mencetuskan interaksi A2A dengan persediaan yang minimum. Anda hanya mendaftarkan satu pelayan MCP, tetapi di sebalik itu, pelayan tersebut boleh menjadi perantara tugas merentasi keseluruhan rangkaian A2A.

Inilah yang ditunjukkan oleh beberapa contoh repo: pelayan MCP menawarkan satu set alat padat yang sendiri bercakap tentang A2A dan bukannya menyambungkan setiap ejen A2A jauh terus ke dalam model. Itu memecahkan model mental naif (“MCP dan A2A mestilah berasingan sepenuhnya”) tetapi memudahkan penyepaduan praktikal secara besar-besaran dan memastikan permukaan antara muka LLM anda kecil dan tersusun rapi.

Tiada apa-apa yang menghalang anda daripada menggunakan MCP dan A2A secara berasingan di tempat yang masuk akal. Banyak projek hanya memerlukan MCP untuk menghubungkan satu ejen kepada beberapa alat. Projek lain, terutamanya apabila menggabungkan vendor atau pasukan dalaman, akan banyak bergantung pada A2A untuk penyelarasan merentas organisasi sambil menggunakan pendawaian dalaman mereka sendiri dan bukannya MCP. Perkara penting ialah protokol tidak bersaing – ia membentuk.

Kebolehkendalian, rangka kerja dan "struktur besar" yang hilang

Protokol sahaja tidak menjamin kebolehkendalian jika semua orang membenamkannya ke dalam seni bina peringkat lebih tinggi yang sangat berbeza. Anda boleh bertutur dalam MCP dan A2A yang sempurna dan masih berakhir dengan sekumpulan corak ejen yang saling tidak serasi yang masing-masing mencipta semula perancangan, ingatan, pengendalian ralat dan tadbir urus.

Langkah seterusnya yang mungkin dalam ekosistem ini ialah lapisan rangka kerja yang dibina di atas MCP dan A2A yang menyeragamkan bukan sahaja wayar, tetapi juga struktur yang lebih besar. Fikirkan bagaimana rangka kerja web muncul di atas HTTP atau bagaimana ORM dibina di atas SQL. Kita mula melihat perkara ini dengan ADK, orkestrator seperti LangGraph, platform terurus seperti Vertex AI Agent Engine dan gerbang AI yang memahami kedua-dua protokol.

Sebaik sahaja industri ini bertemu dengan beberapa corak pragmatik – “beginilah cara anda menstrukturkan aliran kerja berbilang ejen berbanding A2A dan MCP”, “beginilah cara anda mendedahkan kemahiran pasukan di sebalik MCP” – keraguan tentang sama ada sesuatu “patut berada di sebalik MCP atau A2A” akan mula pudar. Kebanyakan pembina hanya akan memilih rangka kerja, memasang satu atau dua pelayan, dan mendapat tetapan lalai yang waras.

Masalah yang lebih rumit dan perlahan ialah kejuruteraan pantas dan kebolehkendalian segera. Walaupun dengan protokol yang sempurna, apabila anda menyambungkan sistem melalui MCP dan A2A, anda secara efektifnya membenarkan gesaan sewenang-wenangnya – arahan sistem, penerangan alat, rel keselamatan – bocor dan berinteraksi merentasi sempadan. Jika gesaan tersebut tidak sejajar, berlebihan atau bercanggah sama sekali, prestasi anda akan terjejas lama sebelum timbulnya kebimbangan keselamatan.

Dalam praktiknya, gesaan dan arahan yang direka bentuk dengan buruk merentasi susunan MCP + A2A boleh menghasilkan kependaman, halusinasi dan ketidakstabilan yang besar. Setiap ejen mungkin "digesa dengan baik" secara setempat, tetapi apabila anda melapiskannya, aliran boleh menjadi rapuh: alatan disalahutamakan, tetingkap konteks dibazirkan dan jangkaan peringkat pengguna dilanggar. A2A boleh menyelaras tugas, MCP boleh mendedahkan alatan, tetapi kedua-duanya tidak memaksa anda untuk memastikan gesaan sentiasa koheren.

Inilah sebabnya mengapa pasukan yang benar-benar telah menghantar produk LLM secara besar-besaran cenderung untuk menganggap kejuruteraan segera sebagai kebimbangan kejuruteraan kelas pertama, bukan perubahan saat akhir. Pihak berkepentingan perniagaan sering melihat gesaan sebagai cara ajaib untuk memperbaiki segala-galanya; jurutera kadangkala menolak gesaan sebagai perincian sekunder berbanding kod. Realiti berada di tengah-tengah: gesaan tidak akan menjadikan sistem yang buruk baik, tetapi gesaan yang cuai benar-benar boleh merosakkan seni bina yang sepatutnya kukuh.

Keselamatan, identiti dan tadbir urus merentasi MCP dan A2A

Sebaik sahaja anda mula membiarkan ejen bertindak bagi pihak manusia merentasi sempadan MCP dan A2A, identiti dan kebenaran dengan cepat menjadi masalah utama. Satu permintaan mungkin merentasi beberapa lapisan pendelegasian: pengguna bercakap dengan ejen orchestrator, yang memanggil alat melalui MCP, yang secara dalaman memanggil pelayan MCP lain atau ejen A2A yang memerlukan kelayakan berasingan.

Senario konkrit muncul di mana-mana: Aplikasi SaaS mendedahkan pelayan MCP yang memerlukan token OAuth; ejen HR dalaman di sebalik A2A menggunakan identiti LDAP korporat; alat analitik pihak ketiga menggunakan SSO sendiri. Pengguna menjangkakan "log masuk sekali dan menyelesaikan sesuatu", tetapi di sebalik tabir berbilang sistem identiti mesti digabungkan.

Dokumen A2A Google secara eksplisit menyebut persekutuan berbilang identiti sebagai cabaran teras. Pengguna U mungkin berinteraksi dengan Ejen A yang memerlukan identiti sistem A (katakan, LDAP perusahaan), manakala Ejen A secara dalaman perlu mewakilkan kepada Ejen B yang memerlukan identiti sistem B (katakan, penyedia SaaS luaran). Protokol perlu menyokong pembawaan dan penentuan skop identiti ini tanpa memaksa pengguna untuk mengesahkan semula secara manual untuk setiap hop.

Penyedia identiti dan platform OAuth/OIDC pantas menyesuaikan diri dengan realiti baharu ini. Infrastruktur seperti Logto, Auth0 atau penyedia identiti dalaman sudah boleh mengeluarkan token yang dibawa oleh ejen melalui panggilan MCP dan A2A. Persoalan terbuka bukanlah sama ada ini mungkin – ia jelas mungkin – tetapi bagaimana kita menyeragamkan corak supaya alat yang dibina hari ini tidak menjadi liabiliti keselamatan atau tadbir urus esok.

Selain auth, kebolehcerapan dan penguatkuasaan dasar kemungkinan akan beralih kepada "gerbang ejen" yang dikongsi. Gerbang tersebut boleh menamatkan trafik MCP dan A2A, memusatkan pembalakan, menguatkuasakan had kadar, melampirkan identiti pengguna dan ejen dan juga menapis alatan atau ejen yang boleh diakses dalam konteks yang mana. Ini mula kelihatan seperti gerbang API – hanya ditala untuk trafik AI dan bukannya HTTP vanila.

Berundur ke belakang, MCP dan A2A secara senyap-senyap membentuk semula cara kita berfikir tentang penyepaduan perisian dan alat pengekodan. Bagi pembangun, pembantu pengekodan yang dipasang pada MCP dan ACP (Protokol Klien Ejen untuk IDE) boleh menemui alatan, memanggil pelayan bahasa, berintegrasi dengan kawalan versi dan bercakap dengan ejen pengekod lain – semuanya melalui protokol standard. Bagi perusahaan, sistem berbilang ejen boleh beroperasi secara saling berkaitan merentasi pasukan dan vendor tanpa perlu menyambung semula semua data untuk setiap kes penggunaan baharu.

Peralihan jangka panjang adalah daripada "aplikasi terbina dalam" kepada "ekosistem ejen". Sama seperti USB dan HTTP yang membolehkan peranti dan perkhidmatan disambungkan secara sembarangan, MCP dan A2A bertujuan untuk menjadikan alatan dan ejen boleh dipasang. Pemenangnya ialah pasukan yang menganggap protokol ini bukan sebagai logo yang berkilat, tetapi sebagai infrastruktur asas untuk cara sistem mereka berfungsi, bekerjasama dan berkembang dari semasa ke semasa.