UCP của Google gắn bốn header vào mỗi lần thanh toán. Ba trong số đó tồn tại cho cuộc tranh cãi về sau

Ngày 11 tháng 1 năm 2026, Google công bố Universal Commerce Protocol — một chuẩn mã nguồn mở cho phép tác nhân AI mua hàng, được phát triển cùng Shopify và có hơn 20 đối tác ủng hộ, trong đó có Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa và Zalando.

Những bài viết sau đó đều nói về mua sắm. Tác nhân dạo cửa hàng thay bạn, tác nhân thanh toán thay bạn, hồi kết của giỏ hàng, đại loại thế.

Rồi bạn đọc đặc tả, và hóa ra mua sắm là thứ ít thú vị nhất trong đó. Cái mà UCP chuẩn hóa với sự cẩn trọng khác thường không phải là giao dịch mua. Đó là bằng chứng rằng giao dịch ấy đã diễn ra đúng như cả hai bên nói.

Tóm tắt:

• Mọi yêu cầu UCP làm thay đổi trạng thái đều mang bốn header, và ba trong số đó — request-signature, idempotency-key, request-id — chẳng đóng góp gì cho bản thân giao dịch. Chúng tồn tại để về sau ai đó chứng minh được đã yêu cầu điều gì, rằng chỉ yêu cầu đúng một lần, và tìm lại được bản ghi ấy.
• Tính không thể chối bỏ là một tính năng có tên gọi hẳn hoi. Trong phần mở rộng mandate AP2 tùy chọn (dev.ucp.shopping.ap2_mandate), doanh nghiệp ký mật mã lên các điều khoản thanh toán, còn nền tảng cung cấp mandate mật mã chứng minh người dùng đã cho phép. Mục đích đặc tả nêu rõ: "giảm đáng kể rủi ro giả mạo và tranh chấp".
• Số đối tác ủng hộ không phải số đơn vị đã tích hợp. "Hơn 20 đối tác toàn cầu" là cách Google diễn đạt, và nó mô tả sự ủng hộ. Đến thời điểm viết bài, chúng tôi không tìm được nguồn sơ cấp nào nêu số nhà bán hàng đang chạy UCP trong thực tế.

Bộ header lấy từ chính hướng dẫn thực hành Google đăng trong ngày ra mắt. Nguồn ở cuối bài.

UCP là gì, gói trong số chữ ít nhất mà vẫn đúng

Trước khi vào lập luận, đây là những dữ kiện bạn tự tra được. Chúng lấy từ đặc tả đăng trên ucp.dev và blog dành cho lập trình viên của Google, cả hai truy xuất ngày 5 tháng 9 năm 2026.

Có hai dòng trong bảng đáng dừng lại, vì phần lớn bài viết đều bỏ qua cả hai.

Thứ nhất là dòng giao vận. UCP không phải chuyện của MCP, cũng không phải chuyện của REST. Cùng một dữ liệu khai báo được cung cấp qua REST, MCP, A2A và một binding nhúng, và doanh nghiệp chọn dùng cái nào. Đó là sự từ chối có chủ ý việc đặt cược xem hệ đường ống tác nhân nào sẽ thắng.

Thứ hai là cách đánh phiên bản theo ngày. 2026-04-08 không phải phiên bản ngữ nghĩa mà là một ngày. Đặc tả nêu lý do là để có thứ tự thời gian rõ ràng và so sánh không mơ hồ — nhưng hệ quả thực tế lại nằm chỗ khác: mọi phiên đã đàm phán đều ghi kèm ngày của bộ quy tắc mà nó vận hành theo. Đó là một quyết định lưu trữ khoác áo quyết định phiên bản, và nó định giọng cho toàn bộ phần còn lại của tài liệu.

Nút thắt cổ chai mà nó sinh ra để phá

Cách Google đóng khung vấn đề là bài toán N×N. Mọi doanh nghiệp muốn xuất hiện trong một bề mặt hội thoại đều phải xây kết nối riêng cho từng bề mặt; mỗi bề mặt lại phải tiếp nhận từng doanh nghiệp riêng lẻ; rốt cuộc chẳng ai ra mắt được gì.

Bài viết kỹ thuật của Shopify, đăng cùng ngày bởi kỹ sư xuất sắc Ilya Grigorik, tiếp cận cùng vấn đề từ bên dưới. Sau hơn 20 năm, hàng tỷ giao dịch và hàng triệu nhà bán hàng, bài học là thương mại từ chối được chuẩn hóa: "tùy chọn và quy tắc thanh toán khác nhau theo thuộc tính của giỏ hàng, người mua và thị trường; quy tắc cộng dồn và kết hợp khuyến mãi có thể sánh với luật thuế; các phương án giao hàng bùng nổ thành vô số hoán vị". Rồi đến câu đáng giữ lại: "Sự phức tạp này không phải lỗi, nó là thuộc tính trồi lên từ sự đa dạng của các nhà bán lẻ."

Chỉ một dòng ấy giải thích toàn bộ kiến trúc. Nếu chấp nhận rằng các nhà bán hàng khác nhau đến mức không thể quy về một mối, bạn không thể chuẩn hóa hành vi. Bạn chỉ có thể chuẩn hóa cách một nhà bán hàng khai báo hành vi của mình, và cách một tác nhân biết được nó vừa đồng ý điều gì.

Cấu trúc mà một doanh nghiệp công bố tại /.well-known/ucp. Nguồn: đặc tả UCP 2026-04-08, mục Overview.

Việc khám phá diễn ra trước khi cuộc trò chuyện bắt đầu

Đây là luồng xử lý, đúng như đặc tả và hướng dẫn của Google mô tả. Nên theo dõi từng bước một, vì chính thứ tự mới là lập luận.

1. Doanh nghiệp công bố một hồ sơ tại /.well-known/ucp. Trong đó khai báo phiên bản giao thức, một hoặc nhiều dịch vụ (dev.ucp.shopping), các capability bên trong, giao vận và endpoint, các payment handler khả dụng, và — điều này quan trọng ở phần sau — các signing_keys công khai của nó.
2. Tác nhân tự khai hồ sơ của mình ở mỗi yêu cầu, qua header UCP-Agent dùng cú pháp từ điển RFC 8941: UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". Trên giao vận MCP, thông tin ấy đi trong một đối tượng meta.
3. Doanh nghiệp tính phần giao. Trong các capability của mình, nó giữ lại những cái nền tảng cũng khai báo; với mỗi cái còn sống sót, nó chọn phiên bản cao nhất có mặt trong cả hai mảng; nếu không có phiên bản chung, capability đó bị loại hoàn toàn.
4. Phần mở rộng mồ côi bị cắt bỏ. Một phần mở rộng khai extends: "dev.ucp.shopping.checkout" sẽ biến mất nếu checkout không sống sót. Việc cắt bỏ lặp lại đến khi không còn gì rơi rụng, nhờ đó xử lý được các chuỗi phụ thuộc bắc cầu.
5. Doanh nghiệp là bên chọn. UCP dùng kiến trúc máy chủ chọn: chính nhà bán hàng, chứ không phải tác nhân, quyết định cái gì đang hoạt động trong phiên, và trả lại danh mục capability đang hoạt động trong phản hồi.

Việc đặt tên không phải quy ước mà là đối tượng quản trị. Mọi capability đều viết theo dạng {tên-miền-đảo}.{dịch-vụ}.{capability} — dev.ucp.shopping.checkout cho cái chuẩn, com.example.payments.installments cho cái riêng của một nhà bán hàng. Một nhà bán lẻ có thể tự nghĩ ra capability không ai khác có, không phải xin phép ai và không đụng độ với ai, vì chính tên miền đảo là thẩm quyền.

Thất bại cũng có phân loại riêng, và cách chia này rất đáng chú ý. Đặc tả tách lỗi khám phá (lỗi giao vận: invalid_profile_url trả 400, profile_unreachable trả 424, profile_malformed trả 422) khỏi lỗi đàm phán, vốn là kết quả nghiệp vụ nên quay về bằng một mã 200 bình thường kèm capabilities_incompatible trong thân phản hồi. "Tôi không với tới bạn" và "chúng ta chẳng có điểm chung" là hai sự kiện khác nhau, và UCP từ chối gộp chúng thành cùng một mã 400.

Bốn header đi cùng mọi yêu cầu làm thay đổi trạng thái

Giờ hãy nhìn một lệnh gọi thật. Đây là ví dụ Google đưa ra trong ngày ra mắt: tạo một phiên thanh toán với cửa hàng hoa mẫu.

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

Bốn header. Hỏi từng cái để làm gì, một quy luật sẽ hiện ra.

Ba trên bốn không phục vụ giao dịch. Chúng phục vụ cuộc bất đồng về giao dịch.

Đây không phải sản phẩm phụ của thói quen viết API sạch sẽ. Khóa idempotency và ID yêu cầu đúng là thực hành tốt thông thường trong thanh toán — nhưng đặc tả đi xa hơn nhiều, và càng đi xa thì ý đồ càng rõ.

Không thể chối bỏ là mục tiêu thiết kế, không phải phần vá cho tuân thủ

UCP liệt kê bốn cơ chế xác thực mà một doanh nghiệp có thể chấp nhận: khóa API, OAuth 2.0, mTLS, và chữ ký thông điệp HTTP theo RFC 9421. Ba cái đầu là bình thường. Cái thứ tư đang làm một việc rất cụ thể.

Với chữ ký thông điệp, cả hai bên công bố khóa công khai trong mảng signing_keys của đúng cái tài liệu hồ sơ đã khai báo capability của họ. Bên xác minh rút keyid từ header Signature-Input, đối chiếu với kid trong bộ khóa mà bên ký đã công bố, rồi kiểm tra chữ ký. Không cần bí mật chia sẻ, không cần đăng ký, không cần tài khoản. Đặc tả gọi kết quả này là onboarding không cần cấp phép: "bất kỳ nền tảng nào có hồ sơ khám phá được đều có thể tương tác với bất kỳ doanh nghiệp nào mà không cần đăng ký trước".

Lỗ hổng hiển nhiên được bịt bằng ràng buộc danh tính. Dù dùng cơ chế nào, bên xác minh phải xác nhận rằng chủ thể đã xác thực thực sự có quyền hành động thay cho hồ sơ nêu trong UCP-Agent, và phải từ chối yêu cầu khi hai thứ đó mâu thuẫn. Bạn không thể xác thực với danh tính của chính mình rồi tuyên bố mình là tác nhân của người khác.

Và webhook đi từ doanh nghiệp tới nền tảng bắt buộc phải được ký. Không phải "nên" — mà là bắt buộc. Cập nhật vòng đời đơn hàng như giao vận, giao thành công và trả hàng là chỗ duy nhất trong giao thức mà yêu cầu này mang tính tuyệt đối, bởi đó là những thông điệp đến sau khi tiền đã chuyển và không ai theo dõi theo thời gian thực.

Nguồn: đặc tả UCP 2026-04-08, mục Identity & Authentication và Transaction Integrity.

Và rồi là đỉnh thang. Cho các tác nhân tự chủ và giao dịch giá trị cao, UCP định nghĩa một phần mở rộng tùy chọn, dev.ucp.shopping.ap2_mandate. Khi cả hai bên đàm phán bật nó lên:

• doanh nghiệp cung cấp chữ ký mật mã trên các điều khoản thanh toán, và
• nền tảng cung cấp mandate mật mã chứng minh người dùng đã cho phép.

Tác nhân ký các đối tượng mandate bằng khóa riêng của người dùng trên một bề mặt phi tác nhân — nghĩa là con người phê duyệt trên màn hình mà họ kiểm soát, chứ không phải bên trong vòng lặp tác nhân sắp tiêu tiền của họ. Câu tuyên bố mục đích của chính đặc tả đáng được trích nguyên văn, vì đây không phải câu bảo mật cho có: cơ chế này "cung cấp bảo đảm mật mã mạnh, đầu cuối tới đầu cuối, về chi tiết giao dịch và sự đồng thuận của các bên tham gia, giảm đáng kể rủi ro giả mạo và tranh chấp".

Điểm mấu chốt là đây. Một giao thức chỉ để tác nhân đi mua sắm thì chẳng cần thứ nào trong số này. Điều khoản có chữ ký bên phía nhà bán hàng và mandate có chữ ký bên phía người dùng không phải là tính năng của việc mua. Chúng là tính năng của việc tranh cãi về vụ mua ấy, sáu tuần sau, trước một người phải phân định ai đúng.

Chỗ mà câu chuyện chạy nhanh hơn bằng chứng

Có ba điều được nhắc đi nhắc lại về UCP mà nguồn sơ cấp không chống đỡ đúng như cách nó được nói.

"Hơn 20 đối tác" là con số ủng hộ. Google viết rằng UCP được "đồng phát triển và ủng hộ bởi hơn 20 đối tác". Ủng hộ là một tuyên bố hậu thuẫn công khai. Đó không phải một tích hợp đã hoàn thành, và càng không phải một nhà bán hàng đang vận hành. Chúng tôi đã tìm nguồn sơ cấp nêu số nhà bán hàng giao dịch qua UCP và không thấy.

"Chuẩn mở" và "chuẩn của Google" đều đúng, và căng thẳng giữa hai điều đó là có thật. Đặc tả là mã nguồn mở, kho GitHub nhận pull request, và quy ước đặt tên cố tình cho phép bất kỳ ai giành lấy không gian tên riêng. Đồng thời, Google là bên xây triển khai tham chiếu đầu tiên, và để tham gia vào triển khai đó, doanh nghiệp cần một tài khoản Google Merchant Center đang hoạt động với sản phẩm đủ điều kiện thanh toán. Giao thức trung lập, nhưng sân khấu đầu tiên thì có cổng.

UCP không loại bỏ nhà bán hàng. Điều này bị nói sai đủ nhiều để cần nêu rõ: dưới UCP, doanh nghiệp giữ nguyên logic nghiệp vụ của mình và vẫn là Merchant of Record. Embedded Checkout Protocol của Shopify cam kết đúng điều đó theo chiều ngược lại — khi luồng cần con người, tác nhân nạp một continue_url và trang thanh toán thật của nhà bán hàng hiển thị ngay bên trong bề mặt của tác nhân qua kênh JSON-RPC 2.0, còn bên chốt giao dịch vẫn là nhà bán hàng. Tác nhân là một bề mặt, không phải vật thay thế.

Bốn điều chúng tôi không xác minh được, xin ghi rõ như vậy

Đặc tả công bố trên ucp.dev tại thời điểm truy xuất mang phiên bản 2026-04-08, và danh sách capability chuẩn của nó — Cart, Checkout, Identity Linking, Order — khác với hướng dẫn ngày 11 tháng 1, nơi các ví dụ chạy phiên bản 2026-01-11 và cho thấy checkout, discount và fulfillment. Có thứ gì đó đã được thêm vào giữa hai mốc ngày ấy. Chúng tôi không tìm được nhật ký thay đổi sơ cấp chỉ ra thời điểm, cũng không có ghi chú phát hành có ngày tháng cho các phiên bản trung gian, nên chúng tôi báo cáo sự khác biệt chứ không báo cáo một sự kiện phát hành.

Chúng tôi không tìm thấy con số nào được công bố về số nhà bán hàng đang chạy UCP, dù từ Google, Shopify hay bất kỳ đối tác ủng hộ nào. Không có con số không đồng nghĩa con số ấy nhỏ, nhưng đó là lý do chúng tôi không in ra con số nào cả.

Google cho biết đã xây triển khai tham chiếu đầu tiên phục vụ việc mua hàng bên trong AI Mode của Tìm kiếm và ứng dụng Gemini. Chúng tôi chưa xác minh độc lập phạm vi khả dụng, khu vực địa lý hay quy mô của đợt triển khai đó.

UCP có trở thành cái chuẩn của thương mại tác nhân hay không thì ở thời điểm viết bài là không thể biết, và bài nào nói ngược lại là đang đoán. Cách đọc trung thực thì hẹp hơn: một đặc tả đang tồn tại, nó công khai, nó cẩn trọng khác thường ở khoản chứng minh, và vài công ty rất lớn đã đứng tên trong thông báo.

Nửa chưa được ký

Hãy lùi ra khỏi thương mại, vì phần thú vị có thể khái quát được.

UCP mô tả một thế giới nơi máy móc hành động thay bạn, và mỗi bước của hành động đó đều để lại thứ gì đó: ai yêu cầu, đã ký; điều khoản nào, đã ký; bao nhiêu lần, có khóa; theo thứ tự nào, có đối chiếu. Sáu tuần sau, khi khoản trừ tiền bị khiếu nại, có một hiện vật ở đó. Không ai cần phải nhớ.

Giờ hãy nghĩ xem thẩm quyền cho những hành động ấy thực ra đến từ đâu. Tác nhân mua 400 đơn vị vì một quyết định mua sắm đã được đưa ra. Hợp đồng gia hạn vì có người đồng ý một điều khoản. Phạm vi công việc thay đổi vì hai người bàn với nhau vào thứ Năm và một trong hai nói được.

Những cuộc trò chuyện đó chính là nửa chưa được ký của cùng một quy trình. Nửa máy móc đang được dựng trên các biên nhận mật mã và trên một đặc tả coi tranh chấp là kịch bản hạng nhất. Nửa con người, ở phần lớn tổ chức, là trí nhớ của một người, trí nhớ khác đi của một người nữa, và một bản tóm tắt viết ra từ cả hai.

Sự bất đối xứng này sẽ tệ hơn trước khi khá lên, vì nửa máy móc cải thiện theo nhịp của một đặc tả còn nửa con người thì không cải thiện chút nào. Và kiểu hỏng hóc rất cụ thể: vấn đề không phải người ta nói dối. Vấn đề là một hiện vật phái sinh — bản tóm tắt, biên bản, danh sách việc cần làm — bị coi là chính bản ghi ngay khi cái mà nó phái sinh từ đó biến mất. Bản tóm tắt về bản chất là mất mát thông tin. Chính điều đó khiến nó hữu ích. Và cũng chính điều đó khiến nó là nguồn sơ cấp tồi: sau khi bản gốc bị bỏ đi, không có cách nào phân biệt một bản tóm tắt thiếu sót với một bản tóm tắt chính xác.

Những người thiết kế UCP đã hiểu điều này ở tầng giao thức và viết nó ra: giữ bản gốc đã ký, phái sinh ra thứ gì tùy ý, và bảo đảm rằng bản phái sinh luôn có thể đối chiếu với thứ chưa hề xê dịch. Đó là kỷ luật chứ không phải công nghệ, và nó áp dụng cho một giờ con người nói chuyện y hệt như áp dụng cho POST /checkout-sessions.

Chốt lại: thương mại tác nhân là một chuẩn về chứng từ khoác áo mua sắm

Universal Commerce Protocol thường được mô tả là cách để tác nhân AI mua đồ. Đọc từ đầu đến cuối, nó được mô tả chính xác hơn là một nỗ lực trả lời câu hỏi mà mọi thứ mang tính tác nhân sắp phải đối mặt liên tục: khi máy móc hành động thay tôi, chính xác thì có thể chứng minh được điều gì về những gì tôi đã đồng ý?

Câu trả lời của UCP là một câu trả lời tốt: khai báo capability của bạn công khai, ký lên điều khoản, ký lên sự đồng thuận, gắn khóa cho lần gửi lại, đối chiếu lệnh gọi, và ký cả cái webhook báo cáo về sau chuyện gì đã xảy ra. Giao thức này có thắng hay không thì thật sự còn bỏ ngỏ. Nhưng câu hỏi mà nó được dựng lên quanh đó thì sẽ không biến mất, bất kể ai thắng.

Còn lại một câu hỏi đáng ngồi lại với nó. Các tác nhân của bạn sắp có bản ghi tốt hơn về những gì chúng đã đồng ý, so với bản ghi mà bạn có về những gì chính bạn đã đồng ý. Chuyện đó dẫn tới đâu?

---

Telli.sh đứng ở đâu: chúng tôi xây đúng cái nửa chưa được ký ấy. Telli.sh ghi lại cuộc trò chuyện, tách người nói, dịch trực tiếp giữa 15 ngôn ngữ, và giữ bản ghi âm gốc cùng bản chép lời đầy đủ ngay bên cạnh mọi bản tóm tắt mà nó tạo ra — để hiện vật phái sinh không bao giờ trở thành hiện vật duy nhất. Telli.sh không triển khai UCP và cũng không tuyên bố như vậy; chúng tôi xử lý đầu bên kia của cùng một vấn đề, đó là những quyết định cho phép tác nhân hành động thường được đưa ra bằng lời nói và chẳng được lưu ở đâu cả.

Ghi lại cuộc họp ra quyết định tiếp theo của bạn

Nguồn

• Đặc tả Universal Commerce Protocol, mục Overview, phiên bản 2026-04-08 — mô hình dịch vụ, capability và phần mở rộng, quy ước đặt tên, đánh phiên bản theo ngày, thuật toán giao capability, mã lỗi đàm phán và chữ ký, capability chuẩn (Cart, Checkout, Identity Linking, Order), các giao vận, header UCP-Agent và cú pháp RFC 8941, cơ chế xác thực và onboarding không cần cấp phép, khám phá khóa qua signing_keys, ràng buộc danh tính, yêu cầu ký webhook, và mục Transaction Integrity and Non-Repudiation; truy xuất ngày 5 tháng 9 năm 2026
• Google Developers Blog, "Under the Hood: Universal Commerce Protocol (UCP)", 11 tháng 1 năm 2026 — danh sách đối tác và con số hơn 20 bên ủng hộ, tương thích AP2, A2A và MCP, cách đóng khung N×N, manifest /.well-known/ucp, hướng dẫn năm bước và bộ header của POST /checkout-sessions, Merchant of Record và tùy chọn nhúng, triển khai tham chiếu của Google trong AI Mode và Gemini, cùng yêu cầu Merchant Center; truy xuất ngày 5 tháng 9 năm 2026
• Shopify Engineering, Ilya Grigorik, "Building the Universal Commerce Protocol", 11 tháng 1 năm 2026 — bối cảnh hơn 20 năm, hàng tỷ giao dịch và hàng triệu nhà bán hàng, lập luận "không phải lỗi mà là thuộc tính trồi lên", bốn nguyên tắc thiết kế, và việc bàn giao qua Embedded Checkout Protocol trên JSON-RPC 2.0 bằng continue_url; truy xuất ngày 5 tháng 9 năm 2026
• Agent Payments Protocol (AP2) — giao thức thanh toán mà UCP tuyên bố tương thích
• Universal Commerce Protocol trên GitHub — kho mã nguồn mở được nêu tên trong cả hai thông báo
• Bài đọc của chúng tôi về GPT-6 Astra và những gì lớp thu âm vẫn đang quyết định — cùng lập luận nhìn từ phía mô hình: chất lượng suy luận bị chặn trần bởi thứ đã tạo ra bản ghi mà nó suy luận trên đó