UCP Google meletakkan empat pengepala pada setiap pembayaran. Tiga daripadanya wujud untuk pertikaian yang menyusul

Pada 11 Januari 2026, Google menerbitkan Universal Commerce Protocol — satu piawaian sumber terbuka yang membolehkan ejen AI membeli, dibangunkan bersama Shopify dan disokong lebih daripada 20 rakan, termasuk Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa dan Zalando.

Liputan yang menyusul semuanya tentang membeli-belah. Ejen yang menyelak katalog untuk anda, ejen yang membayar untuk anda, pengakhiran troli beli-belah, dan seterusnya.

Kemudian anda membaca spesifikasinya, dan rupa-rupanya membeli-belah adalah perkara paling kurang menarik di dalamnya. Apa yang UCP piawaikan dengan kecermatan luar biasa bukanlah pembelian itu. Ia adalah bukti bahawa pembelian itu berlaku tepat seperti yang didakwa kedua-dua pihak.

Ringkasnya:

• Setiap permintaan UCP yang mengubah keadaan membawa empat pengepala, dan tiga daripadanya — request-signature, idempotency-key, request-id — tidak melakukan apa-apa untuk urus niaga itu sendiri. Ketiga-tiganya wujud supaya kemudian nanti seseorang boleh membuktikan apa yang diminta, bahawa ia diminta sekali sahaja, dan menemuinya semula.
• Ketidakbolehsangkalan ialah ciri yang mempunyai namanya sendiri. Dalam sambungan mandat AP2 yang bersifat pilihan (dev.ucp.shopping.ap2_mandate), perniagaan menandatangani syarat pembayaran secara kriptografi manakala platform menyediakan mandat kriptografi yang membuktikan pengguna telah mengizinkannya. Tujuan yang dinyatakan spesifikasi: "mengurangkan risiko gangguan dan pertikaian dengan ketara".
• Bilangan penyokong bukan bilangan integrasi. "Lebih 20 rakan global" ialah rumusan yang diterbitkan Google, dan ia menggambarkan sokongan. Sehingga tulisan ini disiapkan, kami tidak menemui sebarang sumber primer yang menyatakan bilangan peniaga yang benar-benar beroperasi di atas UCP.

Susunan pengepala diambil daripada panduan amali yang diterbitkan Google pada hari pelancaran. Sumber di bahagian akhir.

Apa itu UCP, dalam kata sesedikit mungkin yang masih benar

Sebelum hujah, inilah fakta yang boleh anda semak sendiri. Semuanya daripada spesifikasi yang diterbitkan di ucp.dev dan blog pembangun Google, kedua-duanya dicapai pada 5 September 2026.

Dua baris dalam jadual itu berbaloi dihentikan seketika, kerana kebanyakan tulisan melangkau kedua-duanya.

Pertama, baris pengangkutan. UCP bukan hal MCP, dan bukan juga hal REST. Data terisytihar yang sama ditawarkan melalui REST, MCP, A2A dan satu pengikatan terbenam, dan perniagaan yang memilih. Ini penolakan yang disengajakan untuk tidak bertaruh pada paip ejen yang mana akan menang.

Kedua, versi berasaskan tarikh. 2026-04-08 bukan versi semantik, tetapi satu hari. Alasan yang diberikan spesifikasi ialah susunan kronologi dan perbandingan yang tidak taksa — tetapi kesan praktikalnya lain: setiap sesi yang telah dirundingkan turut merekod tarikh peraturan yang menaunginya. Ini keputusan pengarkiban yang menyamar sebagai keputusan versi, dan ia menetapkan nada bagi keseluruhan dokumen.

Kesesakan yang hendak dihapuskannya

Bingkaian Google ialah masalah N×N. Setiap perniagaan yang mahu muncul dalam permukaan perbualan terpaksa membina sambungan khusus bagi setiap satu; setiap permukaan pula terpaksa mengambil masuk setiap perniagaan secara berasingan; akhirnya tiada siapa yang menghantar apa-apa.

Tulisan kejuruteraan Shopify, diterbitkan pada hari yang sama oleh distinguished engineer Ilya Grigorik, mendekati masalah yang sama dari bawah. Selepas lebih 20 tahun, berbilion urus niaga dan berjuta peniaga, pengajarannya ialah perdagangan enggan dinormalkan: "pilihan dan peraturan pembayaran berbeza mengikut sifat troli, pembeli dan pasaran; diskaun mempunyai peraturan penyusunan dan gabungan yang boleh menandingi kanun cukai; pilihan pemenuhan meletup menjadi pilih atur yang tidak terkawal". Kemudian datang ayat yang wajar disimpan: "Kerumitan ini bukan pepijat, ia sifat yang muncul daripada kepelbagaian peruncit."

Satu baris itu menerangkan keseluruhan seni binanya. Jika anda menerima bahawa peniaga memang berbeza secara tak terkurangkan, anda tidak boleh memiawaikan kelakuan. Yang boleh dipiawaikan hanyalah cara seorang peniaga mengisytiharkan kelakuannya, dan cara seorang ejen mengetahui apa yang baru sahaja dipersetujuinya.

Struktur yang diterbitkan sebuah perniagaan di /.well-known/ucp. Sumber: spesifikasi UCP 2026-04-08, Overview.

Penemuan berlaku sebelum perbualan bermula

Inilah alirannya, seperti yang diterangkan oleh spesifikasi dan panduan Google. Wajar diikuti secara harfiah, kerana susunannya itulah hujahnya.

1. Perniagaan menerbitkan satu profil di /.well-known/ucp. Di situ ia mengisytiharkan versi protokol, satu atau lebih perkhidmatan (dev.ucp.shopping), capability di dalamnya, pengangkutan dan titik akhir, pengendali pembayaran yang ada, dan — ini penting kemudian — signing_keys awamnya.
2. Ejen mengumumkan profilnya sendiri pada setiap permintaan, melalui pengepala UCP-Agent bersintaks kamus RFC 8941: UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". Pada pengangkutan MCP, maklumat yang sama menumpang dalam objek meta.
3. Perniagaan mengira persilangannya. Daripada capability miliknya, ia menyimpan yang turut diisytiharkan platform; bagi setiap yang terselamat, ia memilih versi tertinggi yang hadir dalam kedua-dua tatasusunan; jika tiada versi sepunya, capability itu gugur sepenuhnya.
4. Sambungan yatim dicantas. Sambungan yang mengisytiharkan extends: "dev.ucp.shopping.checkout" lenyap jika checkout tidak terselamat. Pencantasan diulang sehingga tiada lagi yang gugur, jadi rantaian kebergantungan berlapis pun terurus.
5. Perniagaan yang memilih. UCP menggunakan seni bina di mana pelayan yang memilih: peniaga, bukan ejen, yang menentukan apa yang aktif bagi sesi itu, lalu memulangkan daftar capability aktif dalam responsnya.

Penamaan bukan konvensyen tetapi perkara yang ditadbir. Setiap capability ditulis {domain-terbalik}.{perkhidmatan}.{capability} — dev.ucp.shopping.checkout untuk yang piawai, com.example.payments.installments untuk milik seorang peniaga. Seorang peruncit boleh mencipta capability yang tiada pada orang lain tanpa meminta izin sesiapa dan tanpa berlanggar dengan sesiapa, kerana domain terbalik itulah autoritinya.

Kegagalan turut mempunyai taksonominya sendiri, dan pembahagian itu memberi pengajaran. Spesifikasi memisahkan kegagalan penemuan (ralat pengangkutan: invalid_profile_url memulangkan 400, profile_unreachable memulangkan 424, profile_malformed memulangkan 422) daripada kegagalan rundingan, yang merupakan hasil perniagaan lalu pulang sebagai 200 biasa dengan capabilities_incompatible di dalam badannya. "Saya tidak dapat menghubungi anda" dan "kita tiada persamaan langsung" ialah dua peristiwa berbeza, dan UCP enggan melebur kedua-duanya menjadi satu 400.

Empat pengepala menumpang pada setiap permintaan yang mengubah keadaan

Sekarang lihat satu panggilan sebenar. Ini contoh Google sendiri pada hari pelancaran: mencipta sesi pembayaran di sebuah kedai bunga contoh.

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

Empat pengepala. Tanya apa gunanya setiap satu, dan satu corak akan terserlah.

Tiga daripada empat bukan untuk urus niaga. Ketiga-tiganya untuk perselisihan tentang urus niaga itu.

Ini bukan kebetulan daripada kebersihan API. Kunci idempotensi dan ID permintaan memang amalan baik yang lazim dalam dunia pembayaran — tetapi spesifikasi ini melangkah jauh lebih jauh, dan semakin jauh ia melangkah, semakin jelas niatnya.

Ketidakbolehsangkalan ialah matlamat reka bentuk, bukan tampalan pematuhan

UCP menyenaraikan empat mekanisme pengesahan yang boleh diterima sebuah perniagaan: kunci API, OAuth 2.0, mTLS, dan tandatangan mesej HTTP mengikut RFC 9421. Tiga yang pertama biasa sahaja. Yang keempat sedang melakukan sesuatu yang khusus.

Dengan tandatangan mesej, kedua-dua pihak menerbitkan kunci awam mereka dalam tatasusunan signing_keys pada dokumen profil yang sama persis dengan yang mengisytiharkan capability mereka. Pengesah menarik keyid daripada pengepala Signature-Input, memadankannya dengan kid dalam set kunci yang diterbitkan penandatangan, lalu menyemak tandatangan itu. Tiada rahsia dikongsi, tiada pendaftaran, tiada akaun. Spesifikasi menamakan hasil ini sebagai onboarding tanpa kebenaran: "mana-mana platform yang mempunyai profil yang boleh ditemui boleh berinteraksi dengan mana-mana perniagaan tanpa pendaftaran terlebih dahulu".

Lubang yang nyata ditutup oleh pengikatan identiti. Apa pun mekanismenya, pengesah mesti memastikan bahawa prinsipal yang disahkan memang berkuasa bertindak bagi profil yang dinamakan dalam UCP-Agent, dan menolak permintaan apabila kedua-duanya bercanggah. Anda tidak boleh disahkan sebagai diri sendiri lalu mendakwa anda ejen orang lain.

Dan webhook daripada perniagaan kepada platform mesti ditandatangani. Bukan patut — mesti. Kemas kini kitaran hayat pesanan seperti penghantaran, penerimaan dan pemulangan ialah satu-satunya tempat dalam protokol ini yang syaratnya mutlak, kerana itulah mesej yang tiba selepas wang bergerak dan tiada siapa memerhatinya secara masa nyata.

Sumber: spesifikasi UCP 2026-04-08, bahagian Identity & Authentication dan Transaction Integrity.

Kemudian ada puncak tangganya. Bagi ejen autonomi dan urus niaga bernilai tinggi, UCP mentakrifkan satu sambungan pilihan, dev.ucp.shopping.ap2_mandate. Apabila kedua-dua pihak merundingkannya:

• perniagaan menyediakan tandatangan kriptografi ke atas syarat pembayaran, dan
• platform menyediakan mandat kriptografi yang membuktikan pengguna telah mengizinkannya.

Ejen menandatangani objek mandat menggunakan kunci persendirian pengguna pada permukaan bukan ejen — bermakna manusia memberi keizinan pada skrin yang dikawalnya, bukan di dalam gelung ejen yang sebentar lagi akan membelanjakan wangnya. Pernyataan tujuan daripada spesifikasi itu sendiri berbaloi dipetik bulat-bulat, kerana ia bukan ayat keselamatan sekadar melepas: mekanisme ini "memberikan jaminan kriptografi yang kukuh dari hujung ke hujung mengenai butiran urus niaga dan persetujuan pihak yang terlibat, serta mengurangkan risiko gangguan dan pertikaian dengan ketara".

Inilah intinya. Protokol yang direka semata-mata untuk membolehkan ejen membeli-belah tidak memerlukan satu pun daripada semua ini. Syarat bertandatangan di pihak peniaga dan mandat bertandatangan di pihak pengguna bukan ciri untuk membeli. Kedua-duanya ciri untuk bertengkar tentang pembelian itu, enam minggu kemudian, di hadapan seseorang yang terpaksa memutuskan siapa yang betul.

Di mana naratifnya memintas bukti

Ada tiga perkara yang berulang kali disebut tentang UCP tetapi tidak disokong sumber primer sebagaimana ia dinyatakan.

"Lebih 20 rakan" ialah kiraan penyokong. Rumusan Google ialah UCP "dibangunkan bersama dan disokong oleh lebih daripada 20 rakan". Sokongan ialah kenyataan sokongan awam. Ia bukan integrasi yang telah dihantar, apatah lagi peniaga yang sedang beroperasi. Kami mencari sumber primer yang menyatakan bilangan peniaga yang berurus niaga melalui UCP dan tidak menemuinya.

"Piawaian terbuka" dan "piawaian Google" kedua-duanya benar, dan ketegangannya nyata. Spesifikasinya sumber terbuka, repositori GitHub-nya menerima pull request, dan konvensyen penamaannya sengaja membenarkan sesiapa sahaja menuntut ruang namanya sendiri. Pada masa yang sama, Google yang membina pelaksanaan rujukan pertama, dan untuk menyertai pelaksanaan itu, sebuah perniagaan memerlukan akaun Google Merchant Center yang aktif dengan produk yang layak untuk pembayaran. Protokol yang neutral, pentas pertama yang berpintu.

UCP tidak menyingkirkan peniaga. Perkara ini cukup kerap diputarbelitkan sehingga wajar dinyatakan terus terang: di bawah UCP, perniagaan mengekalkan logik perniagaannya sendiri dan kekal sebagai Merchant of Record. Embedded Checkout Protocol milik Shopify memberikan komitmen yang sama dari arah bertentangan — apabila aliran memerlukan manusia, ejen memuatkan satu continue_url dan halaman pembayaran sebenar peniaga dipaparkan di dalam permukaan ejen melalui saluran JSON-RPC 2.0, dengan peniaga yang memuktamadkan urus niaga itu. Ejen ialah satu permukaan, bukan pengganti.

Empat perkara yang tidak dapat kami sahkan, ditandakan sebagaimana adanya

Spesifikasi yang diterbitkan di ucp.dev ketika dicapai membawa versi 2026-04-08, dan senarai capability piawainya — Cart, Checkout, Identity Linking, Order — berbeza daripada panduan 11 Januari, yang contoh-contohnya berjalan pada versi 2026-01-11 dan menunjukkan checkout, discount serta fulfillment. Ada sesuatu yang ditambah antara dua tarikh itu. Kami tidak menemui log perubahan primer yang menyatakan bila, mahupun nota keluaran bertarikh bagi versi-versi pertengahan, jadi kami melaporkan perbezaannya dan bukan sesuatu peristiwa keluaran.

Kami tidak menemui sebarang kiraan terbitan tentang bilangan peniaga yang beroperasi di atas UCP, sama ada daripada Google, Shopify, atau mana-mana rakan penyokong. Ketiadaan angka bukan bukti bahawa angkanya kecil, tetapi itulah sebabnya kami tidak mencetak sebarang angka.

Google menyatakan ia telah membina pelaksanaan rujukan pertama yang menggerakkan pembelian di dalam AI Mode pada Carian dan aplikasi Gemini. Kami belum mengesahkan secara bebas ketersediaan, liputan geografi, mahupun skala pelancaran itu.

Sama ada UCP akan menjadi piawaian perdagangan berejen, pada saat tulisan ini disiapkan tidak mungkin diketahui, dan mana-mana tulisan yang berkata sebaliknya sedang meneka. Bacaan yang jujur lebih sempit: satu spesifikasi wujud, ia terbuka kepada umum, ia luar biasa berhati-hati tentang pembuktian, dan beberapa syarikat yang sangat besar turut menandatangani pengumumannya.

Separuh yang belum ditandatangani

Mari berundur daripada perdagangan, kerana bahagian yang menarik itu boleh diumumkan lebih luas.

UCP menggambarkan sebuah dunia di mana mesin bertindak bagi pihak anda dan setiap langkah tindakan itu meninggalkan sesuatu: siapa yang meminta, bertandatangan; syarat apa, bertandatangan; berapa kali, berkunci; dalam susunan apa, berkait. Enam minggu kemudian, apabila caj itu dipertikaikan, ada artifaknya. Tiada siapa perlu mengingat.

Sekarang fikirkan dari mana sebenarnya kuasa bagi tindakan-tindakan itu datang. Seorang ejen membeli 400 unit kerana satu keputusan perolehan telah dibuat. Sebuah kontrak diperbaharui kerana seseorang bersetuju dengan satu terma. Skop berubah kerana dua orang membincangkannya pada hari Khamis dan salah seorang berkata ya.

Perbualan-perbualan itulah separuh yang belum ditandatangani bagi aliran kerja yang sama. Separuh mesinnya sedang dibina dengan resit kriptografi dan sebuah spesifikasi yang memperlakukan pertikaian sebagai senario kelas pertama. Separuh manusianya, di kebanyakan organisasi, ialah ingatan seseorang, ingatan berbeza seseorang yang lain, dan satu ringkasan yang ditulis daripada kedua-duanya.

Ketaksimetrian ini akan bertambah buruk sebelum bertambah baik, kerana separuh mesin bertambah baik mengikut rentak sebuah spesifikasi manakala separuh manusia langsung tidak bertambah baik. Dan bentuk kegagalannya khusus: bukan kerana orang berbohong. Sebaliknya, artifak terbitan — ringkasan, minit mesyuarat, senarai tindakan — mula dianggap sebagai rekod itu sendiri sebaik sahaja sumber yang menerbitkannya lenyap. Ringkasan memang kehilangan maklumat secara binaan. Itulah yang menjadikannya berguna. Dan itu jugalah yang menjadikannya sumber primer yang buruk: selepas yang asal dibuang, tiada cara membezakan ringkasan yang tercicir maklumat daripada ringkasan yang tepat.

Pereka UCP memahami hal ini pada lapisan protokol dan menuliskannya: simpan yang asal yang bertandatangan, terbitkan apa sahaja yang anda mahu daripadanya, dan pastikan terbitan itu sentiasa boleh disemak terhadap sesuatu yang tidak beranjak. Ini satu disiplin, bukan teknologi, dan ia terpakai kepada sejam manusia berbual sama baiknya seperti kepada satu POST /checkout-sessions.

Kesimpulannya: perdagangan berejen ialah piawaian resit yang berpakaian membeli-belah

Universal Commerce Protocol lazimnya digambarkan sebagai cara untuk ejen AI membeli barang. Dibaca dari hujung ke hujung, ia lebih tepat digambarkan sebagai percubaan menjawab satu soalan yang bakal ditemui berulang kali oleh segala yang berejen: apabila sebuah mesin bertindak untuk saya, apa sebenarnya yang boleh dibuktikan tentang apa yang saya persetujui?

Jawapan UCP ialah jawapan yang baik: isytiharkan capability anda secara terbuka, tandatangani syaratnya, tandatangani keizinannya, berikan kunci pada cubaan semula, kaitkan panggilannya, dan tandatangani juga webhook yang kemudian melaporkan apa yang berlaku. Sama ada protokol ini akan menang benar-benar masih terbuka. Soalan yang menjadi tunjangnya pula tidak akan hilang, siapa pun yang menang.

Tinggal satu soalan yang wajar direnung. Tidak lama lagi ejen anda akan mempunyai rekod yang lebih baik tentang apa yang mereka persetujui berbanding rekod yang anda ada tentang apa yang anda persetujui. Ke mana hala tujunya?

---

Di mana Telli.sh berada: kami membina separuh yang belum ditandatangani itu. Telli.sh merakam perbualan, memisahkan penutur, menterjemah secara langsung merentas 15 bahasa, dan menyimpan rakaman asal serta transkrip penuh di sebelah setiap ringkasan yang dijananya — supaya artifak terbitan tidak pernah menjadi satu-satunya artifak. Telli.sh tidak melaksanakan UCP dan tidak mendakwa sedemikian; kami menangani hujung yang satu lagi bagi masalah yang sama, iaitu bahawa keputusan yang mengizinkan ejen bertindak lazimnya dibuat secara lisan dan tidak disimpan di mana-mana.

Rakam mesyuarat membuat keputusan anda yang seterusnya

Sumber

• Spesifikasi Universal Commerce Protocol, Overview, versi 2026-04-08 — model perkhidmatan, capability dan sambungan, konvensyen penamaan, versi berasaskan tarikh, algoritma persilangan capability, kod ralat rundingan dan tandatangan, capability piawai (Cart, Checkout, Identity Linking, Order), pengangkutan, pengepala UCP-Agent dan sintaks RFC 8941, mekanisme pengesahan dan onboarding tanpa kebenaran, penemuan kunci melalui signing_keys, pengikatan identiti, kewajipan menandatangani webhook, serta bahagian Transaction Integrity and Non-Repudiation; dicapai 5 September 2026
• Google Developers Blog, "Under the Hood: Universal Commerce Protocol (UCP)", 11 Januari 2026 — senarai rakan dan angka lebih 20 penyokong, keserasian AP2, A2A dan MCP, bingkaian N×N, manifes /.well-known/ucp, panduan lima langkah dan susunan pengepala POST /checkout-sessions, Merchant of Record dan pilihan terbenam, pelaksanaan rujukan Google dalam AI Mode dan Gemini, serta syarat Merchant Center; dicapai 5 September 2026
• Shopify Engineering, Ilya Grigorik, "Building the Universal Commerce Protocol", 11 Januari 2026 — bingkaian 20+ tahun, berbilion urus niaga dan berjuta peniaga, hujah "bukan pepijat tetapi sifat yang muncul", empat prinsip reka bentuk, serta serahan Embedded Checkout Protocol melalui JSON-RPC 2.0 dengan continue_url; dicapai 5 September 2026
• Agent Payments Protocol (AP2) — protokol pembayaran yang UCP isytiharkan keserasiannya
• Universal Commerce Protocol di GitHub — repositori sumber terbuka yang dinamakan dalam kedua-dua pengumuman
• Bacaan kami tentang GPT-6 Astra dan apa yang masih ditentukan oleh lapisan rakaman — hujah yang sama dari sudut model: mutu penaakulan dibataskan oleh apa jua yang menghasilkan rekod yang ditaakulnya