Protokol A2A (Agent2Agent) 2026: Spesifikasi dan Keselamatan

Penjelasan rasmi A2A tentang pembahagian peranannya dengan MCP ialah: “MCP bersifat menegak, mendalamkan satu ejen; A2A bersifat mendatar, menghubungkan ejen merentasi sempadan.” Dalam A2A, pihak yang dipanggil ialah ejen yang “legap”: ia menaakul sendiri dan menyimpan keadaannya sendiri, pemanggil tidak dapat melihat model atau alat yang digunakan di dalamnya, dan kedua-dua pihak hanya berinteraksi berbilang pusingan melalui kitar hayat tugas (Task). Dokumen rasmi Taiwan juga sudah menyentuh A2A: Buku Panduan Rujukan Aplikasi AI Sektor Awam V1.0 oleh Kementerian Hal Ehwal Digital Taiwan (tarikh penyediaan yang tercatat dalam dokumen 115-01-28, kalendar Minguo) mempunyai subseksyen “A2A: protokol komunikasi antara ejen AI” di halaman 14, yang menerangkan bahawa fokusnya ialah komunikasi “Client–jauh”.

Tadbir urus A2A melalui tiga peringkat. Pada 2025-06-23 Linux Foundation mengumumkan pengambilalihan, dengan ahli pengasas AWS, Cisco, Google, Microsoft, Salesforce, SAP dan ServiceNow; pada 2025-08-29 ACP yang diterajui IBM digabungkan ke dalam A2A dan pembangunannya dihentikan. Kuasa membuat keputusan sebenar terletak pada Jawatankuasa Pemandu Teknikal (TSC) 9 kerusi, satu kerusi bagi setiap syarikat: Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM dan Bloomberg. Usul diundi menggunakan gitvote pada GitHub issue yang berlabel TSC Review; sebagai contoh, #1942 yang menggabungkan 41 isu kepada lapan tema v1.1 diluluskan pada 2026-06-25 dengan 5 undi menyokong dan 0 undi menentang (ambang 51%).

Pada Ogos 2026, A2A menyertai Agentic AI Foundation (AAIF) sebagai projek Growth Stage, menjadikannya bernaung di bawah yayasan yang sama dengan MCP. Tarikh penyertaan tidak konsisten antara sumber: blog AAIF dan Axios mencatat 2026-08-17, blog rasmi A2A dan halaman spesifikasi mencatat 2026-08-27, manakala laporan Forbes bertarikh 08-19. Satu kemungkinan ialah 08-17 merupakan pengumuman yayasan dan 08-27 merupakan hantaran pihak projek, tetapi tiada sumber yang mengesahkan tafsiran ini; artikel ini menyenaraikan kedua-dua tarikh bersebelahan tanpa memilih satu bagi pihak pembaca. Diginomica mengira A2A sebagai projek ke-5 di bawah AAIF, selepas MCP, goose, AGENTS.md dan agentgateway; terdapat juga sumber sekunder yang menegaskan bahawa ini hanyalah penyusunan semula di peringkat organisasi dan kedua-dua spesifikasi tidak digabungkan.

Dokumen tadbir urus A2A menyatakan “komposisi tempoh stabil diputuskan 18 bulan selepas penubuhan”. Dikira dari Jun 2025, tempoh itu tamat kira-kira pada Disember 2026, sedangkan pengumuman AAIF tidak menjelaskan sama ada TSC akan disusun semula. Ini inferens: komposisi TSC mungkin berubah dalam masa terdekat dan wajar dipantau.

Semua kaedah A2A v1.0 dinamakan semula: message/send menjadi SendMessage, message/stream menjadi SendStreamingMessage, tasks/resubscribe menjadi SubscribeToTask, dan ListTasks ditambah. Laluan REST bertukar kepada gaya AIP, contohnya POST /tasks/{id}:cancel, dan awalan /v1 dibuang. Format ralat HTTP ditukar daripada application/problem+json RFC 9457 kepada google.rpc.Status; reason ditulis dalam huruf besar dengan garis bawah (contohnya TASK_NOT_FOUND), dan domain ditetapkan sebagai “a2a-protocol.org”. Nota penyelidikan berpendapat semakan ini pada hakikatnya mengubah A2A mengikut gaya panduan reka bentuk Google API; ini inferens.

Perubahan paling memecahkan keserasian dalam model data ialah Part yang diratakan. TextPart, FilePart, DataPart dan medan pembeza kind semuanya dibuang; kini satu Part hanya memuatkan salah satu daripada text, raw (bytes), url atau data, dan jenisnya ditentukan berdasarkan medan yang wujud, bukan dengan membaca kind; mimeType dinamakan semula sebagai mediaType, dan file.fileWithUri menjadi url. Laporan komuniti menunjukkan banyak penghurai sehingga kini masih membaca part.kind, dan inilah punca paling lazim kegagalan kebolehoperasian antara 0.3 dan 1.0. Agent Card pula kini berteraskan supportedInterfaces[]; setiap antara muka membawa url, protocolBinding, protocolVersion dan tenant pilihan masing-masing; klien memilih mengikut susunan tatasusunan dan SHOULD melaksanakan fallback.

Rundingan versi mempunyai satu tetapan lalai yang jarang disedari: jika pengepala A2A-Version kosong, ia dianggap sebagai 0.3. Klien hanya menghantar Major.Minor, dan pelayan yang tidak menyokongnya akan memulangkan −32009 VersionNotSupportedError; satu ejen boleh menyenaraikan antara muka dengan protocolVersion berlainan dalam supportedInterfaces supaya 0.3 dan 1.0 boleh wujud bersama. Migrasi rasmi melalui tiga peringkat: mula-mula mampu menghurai kedua-dua format, kemudian mengeluarkan 1.0 sambil membaca 0.3, dan akhirnya hanya mengekalkan 1.0. Atlassian Forge dan MuleSoft telah menerbitkan panduan migrasi 0.3→1.0, menunjukkan perubahan yang memecahkan keserasian ini benar-benar menelan kos.

Semantik tugas mempunyai beberapa butiran yang hanya ditemui selepas membaca spesifikasi sepenuhnya. taskId sentiasa dijana oleh pelayan; jika contextId dibawa oleh klien, ejen hanya boleh menerima atau menolaknya, tidak boleh menjana yang lain; apabila taskId dan contextId tidak sepadan, ejen MUST menolak. Menghantar mesej kepada tugas yang berada dalam empat keadaan akhir COMPLETED, FAILED, CANCELED atau REJECTED akan menghasilkan UnsupportedOperationError; untuk meneruskan kerja, buka tugas baharu dalam context yang sama dan pautkan kembali kepada tugas asal melalui referenceTaskIds. Mesin keadaan mempunyai dua keadaan “gangguan”: TASK_STATE_INPUT_REQUIRED dan TASK_STATE_AUTH_REQUIRED; SendMessage yang menyekat (blocking) juga akan kembali apabila menemui keadaan gangguan.

Jaminan penstriman dan push lebih lemah daripada sangkaan kebanyakan orang. Bendera final pada TaskStatusUpdateEvent dibuang dalam 1.0 dan digantikan dengan “sambungan ditutup” sebagai tanda tamatnya strim, maka sambungan yang terputus di tengah tugas dan tugas yang selesai kelihatan sama di pihak klien; GetTask atau SubscribeToTask perlu dipanggil semula untuk membezakannya. Spesifikasi juga tidak mempunyai mekanisme penyambungan semula berdasarkan ID peristiwa, dan perkara ini telah disenaraikan sebagai tema v1.1 #1986. Pemberitahuan push menghantar StreamResponse melalui HTTP POST ke webhook klien dengan Content-Type application/a2a+json; spesifikasi hanya mewajibkan ejen mencuba menghantar sekurang-kurangnya sekali, dengan had masa SHOULD kira-kira 10–30 saat, dan penerima SHOULD memprosesnya secara idempoten serta MUST menyemak taskId. Dalam erti kata lain, push bersifat “sekurang-kurangnya sekali, susunan tidak dijamin, payload tidak bertandatangan”; ini inferens berdasarkan spesifikasi. Idempotensi juga hanya separuh siap: SendMessage “boleh” menyahduakan menggunakan messageId, tetapi tidak diwajibkan.

Terdapat dua percanggahan sumber tentang tarikh dan bilangan. Tarikh keluaran v1.0: CHANGELOG mencatat 2026-03-12, sebuah kertas tinjauan (arXiv:2507.10644 v4) mencatat Januari 2026, manakala kenyataan media ulang tahun pertama Linux Foundation hanya menyebut v1.0 sebagai versi stabil pertama tanpa tarikh; artikel ini menggunakan CHANGELOG sebagai sumber primer. Bilangan SDK: Linux Foundation pada 2026-04 menyebut 5 bahasa yang “production-ready”, manakala pengumuman rasmi A2A menyenaraikan 6 bahasa, iaitu Python, Go, Java, JS, .NET dan Rust, tetapi SDK Rust yang telah diuji secara terperinci ialah versi komuniti.

Sepanjang setahun lalu sering kedengaran “MCP sudah menambah Tasks, jadi A2A tidak diperlukan lagi”, tetapi hala tuju sebenar MCP versi 2026-07-28 adalah sebaliknya. MCP versi 2025-11-25 memang menambah Tasks eksperimen (SEP-1686) untuk menjejak permintaan berpanjangan, tinjauan berkala (polling) dan pengambilan hasil secara tertunda, dan keadaannya (working, input_required, completed, failed, cancelled) hampir sepadan satu lawan satu dengan A2A. Namun versi 2026-07-28 membuang session dan jabat tangan initialize sehingga MCP menjadi tanpa keadaan (SEP-2567, SEP-2575), mengeluarkan Tasks daripada teras dan menjadikannya sambungan rasmi io.modelcontextprotocol/tasks (SEP-2663), menggantikan permintaan yang dimulakan oleh pelayan dengan MRTR (InputRequiredResult bersama inputResponses yang dilampirkan semasa penghantaran semula) (SEP-2322), serta menandakan Sampling, Roots dan Logging sebagai deprecated (SEP-2577).

Maksud perubahan ini ialah penyelenggara MCP sengaja meninggalkan laluan pengejenan “pelayan meminjam penaakulan LLM pemanggil”; ini inferens. Jika pelayan MCP mahu menaakul sendiri, ia perlu membawa modelnya sendiri, dan pada ketika itu ia sebenarnya sudah menjadi ejen legap yang hanya berupa alat dari luar. Task dalam MCP mengendalikan “pengambilan tertunda bagi satu panggilan alat yang berpanjangan”, manakala Task dalam A2A mengendalikan “kolaborasi berbilang pusingan yang membolehkan kedua-dua pihak bertanya”, di samping penemuan melalui Agent Card, pengisytiharan kemahiran dan penstriman artifak. Arah sebaliknya juga ada senario kegagalan: pertanyaan deterministik seperti semakan harga atau kadar cukai, jika dipaksa menggunakan kitar hayat Task, Message dan Artifact, akan meningkatkan kependaman dan kos pelaksanaan, dan LLM pemanggil juga tidak mendapat schema alat yang terperinci; ini juga inferens. Nota penyelidikan tidak menemui rekod insiden sebenar tentang “gagal kerana menggunakan MCP untuk ejen-ke-ejen” atau “gagal kerana membalut alat dengan A2A”.

Dari segi penggunaan, selain bilangan topic GitHub, satu perbandingan PyPI yang tidak sistematik menunjukkan SDK A2A dimuat turun kira-kira 10.9 juta kali dan SDK MCP kira-kira 257 juta kali. Sumber sekunder menyatakan titik akhir UCP Shopify menggunakan MCP sebagai lapisan pengangkutan, bermakna ejen perdagangan arus perdana disambungkan melalui MCP. Bagi platform awan: AWS AgentCore Runtime boleh menempatkan pelayan A2A (JSON-RPC, POST /, port 9000, OAuth 2.0 atau SigV4); sokongan A2A dalam Microsoft Foundry memasuki public preview pada Jun 2026; Google Agent Registry membaca kad well-known, tetapi penemuan automatik terhad dalam projek yang sama sahaja. Antara pembekal model utama yang disemak dalam nota penyelidikan, Anthropic pada masa ini tiada sokongan A2A asli, dan issue #104852 berkaitan Claude Code hanya dibuka pada akhir Oktober 2026.

Cara memilih secara praktikal agak mudah: jika anda mahu pembantu AI memanggil fungsi deterministik anda (sebut harga, semakan kadar cukai, semakan status bungkusan), gunakan MCP; A2A hanya diperlukan apabila dua ejen yang masing-masing menaakul sendiri dan dimiliki organisasi berlainan perlu berkolaborasi dalam berbilang pusingan. MCP awam HowBridge tergolong dalam kategori pertama; cara menyambungkannya boleh dirujuk dalam tutorial MCP penyatuan barangan di laman ini.

Agent Card A2A mengisytiharkan salah satu daripada lima skema pengesahan melalui securitySchemes: API Key, HTTP Auth, OAuth2, OIDC, mTLS. v1.0 membuang implicit flow dan password flow OAuth, menambah Device Code, dan mengesyorkan semua klien menggunakan PKCE. Spesifikasi mewajibkan pelayan “MUST authenticate every incoming request”, tetapi kebenaran bersifat implementation-specific, dan bukti kelayakan mesti diperoleh melalui saluran luar jalur (out-of-band); apabila tugas memasuki keadaan AUTH_REQUIRED, spesifikasi secara khusus menyatakan “Agents MUST NOT treat the state transition alone as authorization”. Seksyen 13 “Pertimbangan Keselamatan” langsung tidak menyebut prompt injection, perwakilan atau token exchange, OpenTelemetry, dan juga tiada keperluan khusus tentang pengasingan penyewa. Ulasan Semgrep semasa era v0.3 menunjukkan bahawa A2A “supports but does not enforce Agent Card signing”, jangka hayat dan skop token tidak dikawal oleh protokol, dan satu tugas boleh mempunyai beberapa strim selari, maka token sesi yang dicuri boleh digunakan untuk mencuri dengar strim mangsa secara senyap.

Walaupun Agent Card sudah ditandatangani, pada masa ini tiada jaminan ia boleh disahkan merentasi SDK. Spesifikasi menetapkan kad dikanonkan dahulu mengikut RFC 8785 (JCS) (tidak termasuk medan signatures) sebelum dijadikan JWS, dan protected header MUST mengandungi alg dan kid. Issue #2122 (dibuka pada 2026-08-10, setakat 2026-10-31 belum ditutup) merekodkan perbezaan yang diuji: a2a-python 1.1.2 dan @a2a-js/sdk 1.0.1 menghasilkan bait kanonik yang berbeza; Python melepaskan aksara bukan ASCII kepada \uXXXX, menyusun mengikut code point dan bukan unit UTF-16, dan mengeluarkan nombor sebagai 1e-06, manakala ECMAScript mengeluarkan 0.000001; spesifikasi menghendaki medan REQUIRED tetap muncul walaupun bernilai lalai, tetapi proto3 tiada konsep presence, maka description: "" dan skills: [] akan digugurkan; typ juga taksa. PR #2319 membetulkan contoh dalam spesifikasi, tetapi output a2a-go masih berbeza. Satu lagi batasan: tandatangan yang lulus pengesahan hanya membuktikan kad tidak diubah suai, bukan identiti pengeluarnya, dan komuniti juga menegaskan bahawa spesifikasi tiada sebarang mekanisme untuk mengikat kad kepada persekitaran pelaksanaan yang benar-benar membuat panggilan.

Sesetengah serangan boleh berjaya walaupun mematuhi spesifikasi sepenuhnya. A2ABreak (arXiv:2609.10871, v3 2026-10-24) menggunakan LLM untuk mengekstrak 37 keadaan, 76 peralihan dan 929 pernyataan formal daripada spesifikasi bahasa tabii, lalu menemui 11 kelemahan baharu yang semuanya “tidak memerlukan sebarang kecacatan pelaksanaan; musuh yang mematuhi spesifikasi sudah boleh mengeksploitasinya”, contohnya context identifier tanpa perlindungan yang membawa kepada suntikan context merentasi klien, identiti yang hilang selepas beberapa lompatan dalam rantaian perwakilan, dan ejen yang mendakwa keupayaan yang belum dibuktikan. Kajian perlanggaran nama (arXiv:2609.27624) menunjukkan spesifikasi meletakkan name sebagai “human-readable metadata, not as a stable identity” tanpa mentakrifkan peraturan perlanggaran; daripada 7 pelaksanaan sumber terbuka yang dijejak oleh penulis, 6 integrasi jenis klien akan menghantar permintaan ke titik akhir yang dikawal penyerang, dan penulis mengkategorikannya sebagai kelas kelemahan pelaksanaan yang berulang, bukan kelemahan protokol yang umum. Unit 42 di bawah Palo Alto Networks membina bukti konsep session smuggling dengan Google ADK, menunjukkan ejen berniat jahat menggunakan “soalan penjelasan” untuk mencungkil arahan sistem dan memperdaya klien memanggil buy_stock sehingga membeli 10 saham tanpa kebenaran; Unit 42 menyatakan dengan jelas bahawa ini bukan kelemahan protokol, mana-mana protokol berbilang pusingan yang berkeadaan boleh terjejas, dan tiada eksploitasi dikesan di alam nyata. Komuniti turut melaporkan bahawa pelayan berniat jahat boleh menyembunyikan arahan dalam medan description atau skills Agent Card, yang kemudiannya dilaksanakan oleh LLM hos sebagai arahan.

Bukti empirik akademik tentang serangan merentasi ejen juga menyokong prinsip “kepercayaan antara ejen tidak boleh diandaikan”. Triedman et al. (COLM 2025) mendapati kandungan laman web berniat jahat boleh merampas aliran kawalan sistem berbilang ejen; dengan GPT-4o, pelaksanaan kod sewenang-wenangnya berjaya dalam 58%–90% percubaan. Tinjauan bersemak rakan sebaya oleh Ferrag et al. dalam ICT Express (2026) menyusun serangan bermula daripada prompt injection hingga ke lapisan protokol, merangkumi MCP dan A2A.

Nombor CVE dalam jadual di bawah disalin tepat seperti dalam nota penyelidikan. Nota penyelidikan itu sendiri mencatatkan bahawa nombor-nombor ini luar biasa, dan sesetengah entri hanya terdapat dalam satu pangkalan data (contohnya CVE-2026-90790 tiada GHSA sepadan dalam repo a2a-python, hanya terdapat dalam OpenCVE). Carian repo advisories bagi a2a-js, a2a-go dan a2a-dotnet tidak memulangkan hasil, tetapi ini mungkin kerana kebenaran akses tidak mencukupi dan tidak semestinya bermakna tiada kelemahan. Jadual ini boleh dirumuskan kepada tiga pengajaran, dan yang berikut ialah inferens: pertama, Agent Card ialah input yang boleh dikawal penyerang, malah nama pengepala pun boleh ditentukan oleh pihak sebelah sana; kedua, spesifikasi hanya menulis “SHOULD mengesahkan URL webhook”, maka SDK dalam dua bahasa sama-sama terkena SSRF; ketiga, spesifikasi menyatakan “kebenaran ditentukan oleh pelaksanaan”, dan SDK Java yang paling popular secara lalai tidak melaksanakan kebenaran, malah pembaikannya pernah dipintas oleh perbezaan platform Android.

Isu identiti ejen kini terbahagi kepada tiga lapisan di luar A2A. Lapisan pertama ialah identiti beban kerja, yang menjawab “program apakah ini”: penulis draft-klrc-aiagent-auth datang daripada Amazon, Zscaler, Ping Identity, OpenAI dan lain-lain; draf ini telah diterima pakai oleh kumpulan kerja IETF WIMSE dan digantikan oleh draft-ietf-wimse-aims, dengan pendekatan menggunakan keluarga WIMSE dan OAuth 2.0 sedia ada, “tanpa mencipta protokol baharu”. Lapisan kedua ialah kebenaran dan perwakilan, yang menjawab “mewakili siapa dan boleh melakukan apa”: contoh Ping Identity menggunakan act claim dalam token exchange RFC 8693 untuk merekodkan keseluruhan laluan perwakilan dan may_act untuk mengehadkan lompatan seterusnya; namun RFC 8693 asalnya direka untuk pertukaran antara pelayan “selepas persetujuan berlaku”, dan tidak secara asli merangkumi persetujuan pengguna terhadap ejen tertentu.

Lapisan ketiga ialah identiti yang boleh disahkan oleh pihak luar, yang menjawab “bagaimana pihak asing boleh mempercayainya”. Cloudflare Web Bot Auth menandatangani permintaan HTTP dengan Ed25519 dan RFC 9421, tetapi Cloudflare pada masa ini tidak mengesahkan nonce, maka perlindungan daripada serangan ulang main bergantung terutamanya pada tempoh sah yang singkat, kira-kira 1 minit; draf ANS v2 mengesahkan domain melalui ACME dan dibahagikan kepada tiga tahap: Bronze, Silver (ditambah DANE) dan Gold (ditambah log ketelusan SCITT). A2A hanya menyentuh tandatangan kad pada lapisan ini, dan tandatangan itu pun pilihan. Produk komersial telah pun dilancarkan lebih awal: Okta Agent SSO dilancarkan secara rasmi pada 2026-08-24 dan menggunakan ID-JAG; Microsoft Entra Agent ID tidak menyokong ID-JAG secara asli, dan tarikh pelancaran rasminya berbeza antara sumber (2026-04 atau 2026-05). Oleh itu, apabila melaksanakan A2A rentas syarikat, kedua-dua pihak berkemungkinan besar perlu melakukan penukaran token di sempadan masing-masing; ini inferens.

Di peringkat kerajaan, usaha mengisi kekosongan ini juga sedang berjalan. CAISI di bawah NIST Amerika Syarikat pada 2026-02-17 mengumumkan AI Agent Standards Initiative dengan tiga tonggak: piawaian yang diterajui industri, protokol sumber terbuka yang diterajui komuniti, serta penyelidikan keselamatan dan identiti ejen; namun halaman inisiatif itu hanya menggunakan istilah umum seperti “interoperable agent protocols” tanpa menamakan A2A atau MCP. Projek NIST NCCoE “Software and AI Agent Identity and Authorization” pada 2026-09-29 menerbitkan ringkasan maklum balas terhadap kertas konsepnya, dengan lebih 600 organisasi atau individu memberi maklum balas. Blog NIST pada 2026-10-27 bertajuk “Design Tenets for Agent Identity Management Systems” mengemukakan 10 prinsip reka bentuk, termasuk ejen mesti mempunyai identiti tersendiri, dikaitkan dengan pemula dan kebenarannya semakin sempit pada setiap lapisan perwakilan, keistimewaan minimum, kebenaran jangka pendek yang boleh dibatalkan, campur tangan manusia yang dicetuskan berdasarkan risiko, mandat bertandatangan untuk menentukan skop tindakan, dan rekod yang tidak boleh diubah; statusnya ialah blog, bukan piawaian rasmi.

Hala tuju penyelidikan akademik selari dengan perkara ini. South et al. mencadangkan pelanjutan bukti kelayakan khusus ejen di atas OAuth 2.0 / OIDC untuk membina rantaian perwakilan yang boleh diaudit, dan versi kertas pendirian bagi kajian yang sama dimuatkan dalam ICML 2025 Position Paper Track; Chan et al. dalam FAccT 2024 berhujah bahawa keterlihatan ejen boleh dipertingkatkan melalui tiga jenis langkah: pengecam ejen, pemantauan masa nyata dan log aktiviti.

AP2 bukan lagi versi yang diingati orang pada 2025. v0.2.0 menukar mekanismenya kepada Checkout Mandate dan Payment Mandate, masing-masing dengan dua peringkat open dan closed, dilaksanakan dengan SD-JWT, dan open mandate menyimpan kunci awam ejen dalam cnf claim. Tambahan penting ialah aliran Human-Not-Present: pengguna terlebih dahulu menandatangani open mandate dengan kuncinya sendiri pada antara muka yang dipercayai dan menetapkan syarat had, kemudian ejen menandatangani closed mandate dengan kunci ejen, dan kedua-duanya diikat dengan sd_hash; peniaga atau pembekal bukti kelayakan boleh memulangkan unresolved_constraint untuk mengembalikan aliran kepada keadaan “manusia hadir”. Spesifikasi juga mengesyorkan peniaga menggunakan tandatangan bukan deterministik (ECDSA), bukan Ed25519, semasa menandatangani Checkout JWT bagi mengelakkan serangan jadual pelangi (rainbow table). Yang paling kritikal, spesifikasi AP2 meletakkan pengendalian, penyimpanan dan pengambilan semula bukti pertikaian sebagai out of scope, dan hanya menjanjikan jejak audit kriptografi yang tidak boleh dinafikan. Nota penyelidikan juga mendapati kaedah pelanjutan yang disyorkan oleh spesifikasi AP2 ialah extension points UCP, manakala A2A pula tidak dibincangkan dalam teks utama spesifikasi; kedudukan AP2 sedang beralih daripada “sambungan A2A” kepada “lapisan keselamatan dalam protokol perdagangan”; ini inferens.

Cara sambungan pembayaran dipasang pada A2A ialah melalui mekanisme extension A2A itu sendiri: diisytiharkan sebagai AgentExtension (uri, description, required, params) dalam AgentCapabilities, dan klien meminta pengaktifan melalui pengepala A2A-Extensions; sambungan tidak boleh mengubah struktur data teras atau menambah nilai enum, hanya boleh beroperasi melalui metadata, perubahan yang memecahkan keserasian mesti menggunakan URI baharu, dan apabila menemui versi yang tidak disokong “MUST NOT fall back”. a2a-x402 (spec v0.1) ialah sambungan sedemikian: peniaga menghantar payment-required, klien menandatangani lalu membalas payment-submitted, dan selepas peniaga menyelesaikan penyelesaian di rantaian (on-chain), ia membalas payment-completed.

Bilangan transaksi x402 kebanyakannya datang daripada volum tiruan. Chainalysis merekodkan transaksi x402 di rangkaian Base secara kumulatif melebihi 100 juta sehingga suku pertama 2026, tetapi lonjakan pada suku keempat 2025 “kebanyakannya didorong oleh meme coin farming”, dan pengekalan mingguan jatuh daripada 87% kepada 5%. Coinbase pada akhir April 2026 mendakwa kira-kira 165 juta transaksi dengan nilai kumulatif kira-kira USD 50 juta; ini dakwaan vendor. Artemis pula berpendapat lebih 95% merupakan isyarat protokol atau ujian; sebuah laman penjejak lain menganggarkan nilai perdagangan sebenar kira-kira USD 28 ribu sehari.

Amalan sebenar rangkaian kad dan platform ialah “terima pelbagai protokol, dengan pengesahan kukuh semasa manusia hadir sebagai injap keselamatan”. Pada Mac 2026, OpenAI mengembalikan Instant Checkout dalam ChatGPT kepada model Apps peniaga; menurut jurucakapnya, “Instant Checkout is moving to Apps”. Visa pada 2026-07-02 mengumumkan bahawa di Eropah sudah ada ejen yang benar-benar menyelesaikan pembelian, dengan lebih 30 bank pengeluar kad sebagai rakan kongsi, dan semua transaksi menggunakan Payment Passkeys untuk memenuhi pengesahan pelanggan yang kukuh (SCA). Rangka kerja tanggungjawab masih kosong: Chargebacks911 memberi amaran bahawa infrastruktur pertikaian dan tanggungjawab “largely unaddressed”; Taylor Wessing menganalisis bahawa di bawah rangka kerja Kesatuan Eropah, pembelian oleh ejen yang melampaui syarat yang ditetapkan pelanggan pada dasarnya akan dianggap sebagai transaksi tanpa kebenaran; Ant International, Visa dan Mastercard hanya mula meneroka rangka kerja kebolehoperasian Know-Your-Agent pada 2026-09-10. PSD3 / PSR Kesatuan Eropah setakat ini hanya sampai ke kedudukan bacaan pertama yang diluluskan oleh Majlis pada 2026-10-29, belum diterbitkan dalam Official Journal, dan carian kata kunci dalam memorandum penjelasan PSR oleh Majlis tidak menemui peruntukan tentang AI atau ejen autonomi; CFPB Amerika Syarikat juga tiada garis panduan pembayaran oleh ejen.

Penyelidikan akademik menunjukkan satu lagi titik buta. Debi et al. (IEEE IMNS 2026) menjalankan ujian pasukan merah ke atas ejen beli-belah AP2: prompt injection tidak langsung dan langsung boleh memanipulasi susunan produk dan mengeluarkan data sensitif pengguna, menunjukkan bahawa mandate bertandatangan tidak dapat melindungi proses penaakulan sebelum tandatangan dibuat; Jiang et al. (arXiv:2609.00060) pula menggunakan Tamarin untuk analisis formal ke atas x402, MPP, ACP dan AP2, dan menunjukkan kebergantungan keselamatan yang timbul apabila niat, kuasa perwakilan dan penyelesaian tersebar kepada pelbagai pihak. Pengejenan dalam industri logistik pada masa ini berjalan melalui MCP: pelayan MCP Flexport membolehkan pembantu AI pelanggan menempah ruang kargo dengan kadar yang dipersetujui dan memperoleh booking ID. Nota penyelidikan tidak menemui sebarang contoh penyelesaian bayaran penghantaran melalui AP2 atau x402.

Kenyataan media ulang tahun pertama Linux Foundation pada 2026-04-09 menyatakan A2A mempunyai lebih 150 organisasi penyokong serta pelaksanaan pengeluaran dalam rantaian bekalan, kewangan, insurans dan operasi IT; ini dakwaan vendor: kenyataan media itu tidak menamakan mana-mana pengguna dan tidak memberikan sebarang penunjuk proses atau hasil. Artikel .NET Microsoft Agent Framework dan codelab concierge perolehan Google, yang paling kerap dijadikan contoh, kedua-duanya ialah contoh kod dan bukan laporan pelaksanaan. Tyson Foods sering dipromosikan sebagai kes rantaian bekalan A2A, tetapi apis.io memberikan A2A Agent Card syarikat itu skor 0/8, dan apa yang disediakannya kepada rakan dagang masih EDI dan API.

Sangkalan paling langsung datang daripada ujian sebenar. Seorang penulis pada April 2026 mengambil 50 ejen yang mendakwa menyokong A2A daripada pendaftaran awam; hanya kira-kira 0–2 yang menyediakan kad sah di laluan well-known, dan 0 yang membalas task dengan betul. Penulis yang sama pada 2026-09-09 menghantar 24 permintaan kepada 12 organisasi dan pada 2026-10-27 menghantar 36 permintaan kepada 18 organisasi, dan kedua-duanya memperoleh 0 kad. Sampel dipilih sendiri oleh penulis dan bukan banci, tetapi hala tujunya konsisten. Yang benar-benar beroperasi ialah kebolehoperasian dalam satu platform awan yang sama: AWS AgentCore, Microsoft Foundry, Google Agent Registry.

Bukti empirik tentang seni bina berbilang ejen itu sendiri juga tidak memihak kepada A2A rentas organisasi. MAST (NeurIPS 2025 Datasets & Benchmarks Track) menganalisis 1,642 jejak pelaksanaan dan merumuskan 14 mod kegagalan dalam tiga kategori besar: reka bentuk sistem, ketidakjajaran antara ejen dan pengesahan tugas; kadar kegagalan 7 sistem berbilang ejen sumber terbuka tercanggih dalam kertas itu ialah antara 41%–86.7% (penulis mengingatkan bahawa penanda aras yang berbeza tidak boleh dibandingkan secara langsung). “Towards a Science of Scaling Agent Systems” oleh penulis dari Google Research, MIT dan lain-lain menguji 180 konfigurasi dalam v1 / v2 dan versi blog Google: ralat dalam berbilang ejen bebas diperbesar 17.2 kali, dalam model penyelarasan berpusat 4.4 kali, dan pada tugas penaakulan berjujukan semua varian berbilang ejen merosot 39%–70%; v3 pada 2026-04-08 diperluas kepada 260 konfigurasi dan 6 penanda aras, dan masih mengekalkan kesimpulan 17.2 kali dan 4.4 kali. Blog kejuruteraan Anthropic (bukan kertas bersemak rakan sebaya) menerangkan bahawa sistem penyelidikan berbilang ejennya 90.2% lebih baik daripada Claude Opus 4 ejen tunggal, tetapi penggunaan token kira-kira 15 kali ganda perbualan biasa, dan menamakan domain yang “memerlukan semua ejen berkongsi konteks yang sama, atau mempunyai banyak kebergantungan antara ejen” sebagai tidak sesuai. A2A rentas organisasi kebetulan menghimpunkan kesemua keadaan yang tidak memihak ini: kedua-dua pihak tidak berkongsi konteks, tiada pengesah bersama, dan aliran perdagangan (semakan harga→pesanan→bayaran→penghantaran) adalah berjujukan; ini inferens.

Kekosongan dari segi kejuruteraan lebih banyak daripada dari segi spesifikasi. Apabila A2A mewakilkan kepada ejen seterusnya, trace akan terputus: Python SDK hanya membina span setempat, dan tiada cara piawai untuk menghantar W3C Trace Context antara ejen (Issue #2103). SDK Rust komuniti melaporkan 7 kegagalan TCK, yang selepas disemak didapati merupakan kecacatan dalam suite ujian itu sendiri; laporan yang sama menyatakan SDK JS, Go dan Java lulus 21/21 pada kedua-dua pengikatan. Trafik ejen di pihak pengguna juga masih kecil: HUMAN Security merekodkan trafik ejen pada 2025 meningkat 7,851% setahun, tetapi hanya 2.3% berlaku di halaman checkout; sumber sekunder yang memetik data Cloudflare Radar Ogos 2026 menyatakan bot AI kira-kira 7% daripada permintaan HTML, dan daripadanya “tindakan masa nyata bagi pihak pengguna” hanya 5.8%; hasil darab kedua-duanya kira-kira 0.4%, dan pendaraban ini ialah inferens yang belum disahkan dengan data asal. Akamai pula memberi amaran bahawa laman e-dagang hanya memantau lebih 90% bot AI, sedangkan aktiviti ejen penipuan semakin meningkat. Nota penyelidikan tidak menemui bukti bahawa ejen peribadi seperti ChatGPT, Gemini atau Claude memanggil ejen syarikat biasa melalui A2A, tetapi ini hanyalah ketiadaan bukti, bukan pengesahan rasmi.

Temu bual oleh kerajaan dan organisasi antarabangsa pula menunjukkan bahawa keperluannya benar. OECD Artificial Intelligence Papers No. 65 di halaman 16 merekodkan bahawa pengamal yang ditemu bual lebih gemar protokol terbuka, dan menyatakan protokol komunikasi ejen-ke-ejen seperti A2A ialah pemacu penting penyelarasan berbilang ejen, di samping bimbang terikat kepada ekosistem satu pembekal.

Taiwan: Akta Asas Kecerdasan Buatan mengandungi 20 seksyen; Seksyen 3 mentakrifkan kecerdasan buatan sebagai “sistem yang berkeupayaan beroperasi secara autonomi”, yang boleh merangkumi ejen AI, tetapi perkataan “ejen” tidak muncul dalam teks undang-undang; Seksyen 4 menyenaraikan tujuh prinsip utama, termasuk autonomi dan pengawasan manusia, ketelusan dan kebolehjelasan, serta akauntabiliti; Seksyen 16 menugaskan Kementerian Hal Ehwal Digital memacu rangka kerja pengelasan risiko yang selaras dengan amalan antarabangsa; Seksyen 17 mewajibkan kerajaan menetapkan atribusi tanggungjawab dan syarat liabiliti bagi AI berisiko tinggi, serta mewujudkan mekanisme remedi, pampasan atau insurans; Seksyen 18 mewajibkan setiap agensi menyelesaikan penyesuaian peraturan berkaitan dalam tempoh dua tahun selepas berkuat kuasa. Berdasarkan Seksyen 16, Kementerian Hal Ehwal Digital pada 115-07-07 mengumumkan Rangka Kerja Pengelasan Risiko AI v1.0 (rujukan surat Strategi Digital No. 1150015933, berkuat kuasa serta-merta), dan bagi jenis risiko B6 “tindakan ejen AI autonomi di luar kebenaran” ia menyatakan: “Sistem berbilang ejen lebih berkemungkinan, akibat ejen saling mencetuskan satu sama lain, menghasilkan tindak balas berantai yang tidak dijangka oleh pembangun mahupun pengguna, menyukarkan manusia untuk campur tangan dan membetulkannya tepat pada masanya.” Garis panduan AI generatif untuk institusi perubatan yang dikeluarkan oleh Kementerian Kesihatan dan Kebajikan pada 115-05-29 pula secara jelas menyatakan bahawa sistem ejen AI “belum termasuk dalam skop pemakaian garis panduan ini”.

Undang-undang sedia ada Taiwan juga terpakai bagi senario ejen. Seksyen 4 Akta Perlindungan Data Peribadi menetapkan bahawa pihak yang diamanahkan untuk mengumpul, memproses atau menggunakan data peribadi, dalam skop akta ini, dianggap sama seperti agensi yang mengamanahkan; oleh itu menyerahkan data peribadi kepada ejen untuk diproses tidak membebaskan tanggungjawab hanya kerana “AI yang melakukannya”; Seksyen 21 mengawal selia sekatan pemindahan antarabangsa. Perlu diberi perhatian bahawa beberapa seksyen yang dipinda pada 114-11-11 (termasuk versi baharu Seksyen 21 dan Seksyen 20-1 yang ditambah) telah diwartakan tetapi belum berkuat kuasa, dan tarikh kuat kuasanya akan ditetapkan oleh Executive Yuan. Akta Tandatangan Elektronik tidak menyebut AI atau ejen; sama ada tandatangan yang dibuat oleh ejen bagi pihak seseorang boleh dianggap sebagai tandatangan orang itu sendiri tidak dinyatakan secara jelas dalam undang-undang, dan artikel ini tidak dapat mengesahkannya.

China: State Administration for Market Regulation dan Standardization Administration of China, melalui Pengumuman Piawaian Kebangsaan Tahun 2026 No. 22, meluluskan dan menerbitkan pada 2026-05-22 siri GB/Z 185.1～185.7-2026 “Kecerdasan Buatan – Saling Sambung Ejen Pintar” yang terdiri daripada 7 dokumen teknikal panduan (seni bina keseluruhan, kod identiti, pengurusan identiti, penerangan ejen, penemuan ejen, interaksi ejen, panggilan alat oleh ejen); platform perkhidmatan awam maklumat piawaian kebangsaan menandakan statusnya sebagai “berkuat kuasa”, teks penuhnya didedahkan kepada umum pada 2026-06-18, dan State Administration for Market Regulation turut mengadakan sidang media bertema pada 2026-06-26. Nama protokol yang digunakan dalam dokumen rasmi ialah AIP (Agent Interconnection Protocol), dan halaman rasmi yang ditemui tidak menyebut A2A atau MCP; sama ada kedua-duanya serasi belum disahkan. “Pendapat Pelaksanaan tentang Aplikasi Terkawal dan Pembangunan Inovatif Ejen Pintar” yang dikeluarkan bersama oleh Cyberspace Administration of China, National Development and Reform Commission dan Ministry of Industry and Information Technology pada 2026-05-08 pula menggabungkan promosi AIP, platform pendaftaran ejen pintar dan identiti digital ejen pintar sebagai satu pakej, serta menetapkan bahawa “operasi yang dilaksanakan oleh ejen pintar tidak boleh melampaui skop kebenaran pengguna”. Laluan ini berbeza daripada pendirian komuniti A2A bahawa “tiada pendaftaran rasmi disediakan”.

Kesatuan Eropah: AI Act (Regulation (EU) 2024/1689) berkuat kuasa pada 2024-08-01; kewajipan bagi model AI tujuan umum terpakai mulai 2025-08-02, manakala pemakaian umum dan kewajipan ketelusan mulai 2026-08-02; kewajipan berisiko tinggi telah ditangguhkan oleh Regulation (EU) 2026/1744 (diterbitkan dalam Official Journal pada 2026-07-24), dengan Lampiran III ditangguhkan hingga 2027-12-02 dan Lampiran I hingga 2028-08-02. PSD3 dan PSR pula hanya mencapai kedudukan bacaan pertama yang diluluskan oleh Majlis pada 2026-10-29, masih menunggu bacaan kedua Parlimen Eropah, dan belum diterbitkan dalam Official Journal.

Amerika Syarikat, Singapura, United Kingdom: CISA, NSA dan agensi Five Eyes lain pada 2026-04-30 / 05-01 menerbitkan “Careful Adoption of Agentic AI Services”, yang mengesyorkan pengehadan hak akses dan bermula dengan kes penggunaan berisiko rendah dan tidak sensitif; CFPB Amerika Syarikat tiada garis panduan khusus untuk pembayaran oleh ejen, dan cadangan peraturan tafsiran berkaitan pada 2025 telah ditarik balik pada 2025-05-15. “Model AI Governance Framework for Agentic AI” v1.5 oleh IMDA Singapura (diterbitkan 2026-05-20, dikemas kini 06-05) dalam seksyen 1.1.1 menamakan secara langsung A2A untuk komunikasi antara ejen dan MCP untuk komunikasi antara ejen dengan alat, serta menunjukkan bahawa perwakilan rekursif dan identiti rentas organisasi merupakan jurang semasa. Garis panduan CMA United Kingdom yang diterbitkan pada 2026-03-09 (dikemas kini 10-30) menyatakan “if an AI agent you use does something illegal, you are responsible”, bermakna perniagaan bertanggungjawab atas perbuatan menyalahi undang-undang oleh ejen yang digunakannya; perundingan awam ICO United Kingdom tentang AI agentik ditutup pada 2026-11-20.

Issue #1942 menggabungkan 41 isu kepada lapan tema v1.1, manakala memori ejen merentasi tugas (#893) tidak termasuk dalam skop penjejakan. Yang lebih menggambarkan hala tuju berbanding senarai tema ialah isu dengan komen terbanyak: #1672 pengesahan identiti ejen dalam Agent Card (kira-kira 658 komen), #1829 tandatangan mesej menggunakan Ed25519 dan RFC 9421, #2028 perwakilan actor-chain, #2121 penghantaran kos dan bajet, serta #1815 menggunakan HTTP 402 untuk menyatakan “bayaran diperlukan”. Semua ini ialah isu kepercayaan dan perdagangan; ditambah dengan proses tadbir urus extension yang baharu diwujudkan, nota penyelidikan menilai bahawa isu-isu ini lebih berkemungkinan muncul sebagai sambungan dan bukan sebagai pindaan spesifikasi teras; ini inferens.

Soalan “bagaimana ejen peribadi menemui ejen syarikat” pada masa ini belum mempunyai jawapan terbuka yang telah dilaksanakan. Dokumentasi rasmi A2A menyatakan dengan jelas bahawa pendaftaran terkurasi berada di luar skop A2A; cadangan Agent Registry dalam Discussion #741 telah lama tertangguh, dan penyemak mempersoalkan premis “pembekal menguruskan sendiri entri pendaftaran mereka”. Bagi menemui ejen daripada domain, IETF mempunyai empat draf individu yang saling bersaing: DNS-AID (menggunakan rekod SVCB yang menunjuk ke /.well-known/agent-card.json), AID (menyemak rekod TXT _agent), ADP dan DAN, dan kesemuanya belum diterima pakai oleh kumpulan kerja; draf landscape pada Julai 2026 juga menyatakan bahawa ruang nama perlu diselaraskan. Di pihak MCP, MCP Registry sejak September 2025 hingga kini masih dalam versi pratonton.

Audit dan tanggungjawab rentas organisasi juga belum mempunyai rangka kerja. Spesifikasi A2A hanya mengandungi keperluan peringkat SHOULD untuk perekodan kegagalan pengesahan dan pengehadan kadar, manakala keterangan antara sumber tentang status stabil konvensyen semantik OpenTelemetry GenAI saling bercanggah. Dengan alat sedia ada, unit audit minimum yang boleh disimpan lebih kurang: taskId dan contextId di pihak sendiri, cap jari tandatangan Agent Card pihak sebelah sana, dan rantaian perwakilan act dalam token yang ditunjukkan oleh pihak sebelah sana, yang disimpan oleh setiap pihak untuk penyesuaian kemudian; ini inferens. Nota penyelidikan juga tidak menemui sebarang kajian empirik denial-of-wallet yang bertujuan “menghabiskan bajet LLM pihak sebelah sana”.

Keadaan A2A sekarang amat menyerupai HTTP pada zaman awalnya: format sudah diseragamkan, tetapi lapisan kepercayaan masih perlu dilengkapkan oleh setiap pihak; bezanya, kali ini pihak yang dipanggil menaakul sendiri, malah boleh dipujuk oleh pihak sebelah sana. Oleh itu kesesakan bukan pada kejuruteraan, tetapi pada “siapa yang bertanggungjawab atas tindakan ejen”, dan perkara ini pada masa ini tersebar di tangan IETF (identiti), FIDO Alliance (niat pembayaran), rangkaian kad (pertikaian) dan pengawal selia pelbagai negara, di luar bidang kuasa TSC A2A. Daripada ini disimpulkan bahawa dalam beberapa tahun akan datang, bentuk kebolehoperasian ejen rentas syarikat yang paling mungkin ialah “kulit A2A yang membalut panggilan alat deterministik”: pihak yang dipanggil kelihatan seperti ejen, tetapi di dalamnya sebenarnya API, dan penaakulan sebenar hanya berlaku dalam sempadan kepercayaan sendiri.

Hala tuju garis panduan kerajaan selari dengan perkara ini. CISA, NSA dan agensi Five Eyes lain mengesyorkan bermula dengan kes penggunaan berisiko rendah dan tidak sensitif serta mengehadkan hak akses; rangka kerja IMDA Singapura meletakkan “memastikan manusia memikul tanggungjawab yang bermakna” dan kawalan teknikal sebagai aspek teras; Kementerian Hal Ehwal Digital Taiwan menyenaraikan tindak balas berantai akibat ejen saling mencetuskan sebagai risiko B6; CMA United Kingdom pula menyatakan dengan jelas bahawa perniagaan bertanggungjawab atas perbuatan menyalahi undang-undang oleh ejen yang digunakannya.

Jadual di bawah mengelaskan pilihan penerimaan pakai bagi syarikat umum mengikut kekuatan bukti. Dalam jadual, “Lakukan” bermaksud risiko rendah dan pulangan jelas berdasarkan bukti sedia ada; “Boleh dilakukan” bermaksud kos rendah tetapi tiada kes yang diukur; “Tangguhkan” dan “Jangan lakukan” disertakan dengan sebab, dan dinilai semula apabila keadaan pencetus muncul.

Pertanyaan teras e-dagang rentas sempadan dan logistik — berapakah kos penghantaran, berapakah cukai, apakah nombor klasifikasi tarif dan syarat import bagi barangan ini — pada asasnya ialah pengiraan deterministik, iaitu jenis perkhidmatan yang paling diperlukan oleh ejen luar dan paling kecil kemungkinan tersilap. Pengalaman daripada blog kejuruteraan Anthropic menunjukkan bahawa menulis semula penerangan alat mengurangkan masa penyiapan tugas ejen seterusnya sebanyak 40%; pengalaman OpenAI mengembalikan Instant Checkout kepada Apps peniaga pula menunjukkan bahawa transaksi akhirnya tetap kembali kepada aliran peniaga sendiri. Maka susunan persediaan perniagaan sepatutnya: mula-mula pastikan laman web dan data berstruktur boleh dibaca, kemudian jadikan alat deterministik sebagai MCP, sertakan URL sambungan dalam respons alat untuk membawa transaksi kembali ke aliran sendiri, dan akhir sekali barulah mempertimbangkan penanda tempat A2A.

Kad penanda tempat A2A bermaksud menerbitkan sekeping kad di /.well-known/agent-card.json yang kemahirannya dipetakan kepada alat deterministik sedia ada seperti sebut harga, cukai dan aliran proses, dengan bahagian belakang yang terus memanggil program tanpa menjalankan LLM. Pendekatan ini berkos rendah dan bernilai sebagai “opsyen”, tetapi pada masa ini tiada kes yang diukur tentang PKS memperoleh trafik atau hasil daripadanya; ini inferens. Jika benar-benar mahu membuka titik akhir A2A, sekurang-kurangnya: hanya buka kemahiran baca sahaja, jangan percaya mana-mana medan dalam kad pihak sebelah sana, tolak IP persendirian bagi URL push, dan rekodkan taskId, contextId, identiti pemanggil serta traceparent.

Pendekatan HowBridge pada masa ini (semuanya boleh disemak di halaman pembangun HowBridge): HowBridge menyediakan MCP awam tanpa kunci API dan tanpa OAuth (https://0523.tw/mcp/public) yang mengandungi 8 alat baca sahaja dan idempoten, merangkumi pengenalan jenama dan perkhidmatan HowBridge, anggaran kos penghantaran penyatuan barangan China→Taiwan (Sea Express / kargo udara), anggaran cukai import Taiwan, carian calon klasifikasi tarif CCC berdasarkan nama barangan, kadar tarif dan syarat import mengikut kod CCC, caj saiz berlebihan bagi penghantaran domestik Taiwan, serta aliran penyatuan barangan dan peraturan pengisytiharan ringkas; hadnya 120 kali seminit bagi setiap IP, dan telah didaftarkan dalam MCP Registry rasmi (nama tw.0523/lucky-public); respons anggaran kos penghantaran disertakan dengan URL sambungan (continue_url) supaya pengguna kembali ke laman rasmi untuk meneruskan. MCP ahli (https://0523.tw/mcp) pula menggunakan kebenaran OAuth 2.1 dan menyediakan 6 alat baca sahaja yang hanya boleh membaca bil, bungkusan, pra-makluman penghantaran, notis cukai dan dokumen pengisytiharan import milik ahli yang memberi kebenaran, dengan had lalai 60 kali seminit dan 5,000 kali sehari. Halaman pembangun HowBridge kini menyenaraikan API data ahli, MCP ahli dan MCP awam, tanpa titik akhir A2A; artikel ini tidak bermaksud HowBridge sudah menyokong A2A.

Jika anda mahu pembantu AI membantu menganggar kos penghantaran dari China ke Taiwan, anda boleh terus menggunakan anggaran kos penghantaran penyatuan barangan, kalkulator duti import dan carian klasifikasi tarif versi web; alat-alat ini dan MCP awam menggunakan logik pengiraan yang sama. Anggaran hanyalah sebagai rujukan: kos penghantaran adalah berdasarkan bil selepas pengukuran di gudang, dan cukai berdasarkan penetapan pihak kastam.