UCP ของ Google ใส่เฮดเดอร์สี่ตัวในทุกคำขอชำระเงิน สามตัวมีไว้เพื่อการโต้แย้งที่จะตามมา

วันที่ 11 มกราคม 2026 Google เผยแพร่ Universal Commerce Protocol มาตรฐานโอเพนซอร์สที่เปิดทางให้เอเจนต์ AI ซื้อของได้ พัฒนาร่วมกับ Shopify และมีพันธมิตรกว่า 20 รายให้การสนับสนุน ในนั้นมี Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa และ Zalando

ข่าวที่ตามมาล้วนพูดเรื่องการช้อป เอเจนต์ที่เดินดูของแทนคุณ เอเจนต์ที่จ่ายเงินแทนคุณ จุดจบของตะกร้าสินค้า และอื่น ๆ ทำนองนั้น

แล้วพออ่านสเปกจริง ๆ ก็พบว่าการช้อปคือสิ่งที่น่าสนใจน้อยที่สุดในนั้น สิ่งที่ UCP กำหนดมาตรฐานอย่างพิถีพิถันผิดปกติไม่ใช่การซื้อ แต่คือหลักฐานว่าการซื้อนั้นเกิดขึ้นตรงตามที่ทั้งสองฝ่ายบอก

สรุปสั้น

• คำขอ UCP ทุกครั้งที่เปลี่ยนสถานะจะพ่วงเฮดเดอร์มาสี่ตัว และสามตัวในนั้น คือ request-signature, idempotency-key, request-id ไม่ได้ช่วยอะไรกับตัวธุรกรรมเลย มันมีอยู่เพื่อให้ภายหลังมีใครสักคนพิสูจน์ได้ว่าขออะไรไป ขอไปเพียงครั้งเดียว และหาบันทึกนั้นกลับมาได้
• การปฏิเสธไม่ได้เป็นฟีเจอร์ที่มีชื่อเรียกของมันเอง ในส่วนขยาย AP2 mandate แบบเลือกใช้ (dev.ucp.shopping.ap2_mandate) ฝั่งร้านค้าจะเซ็นเงื่อนไขการชำระเงินด้วยวิธีเข้ารหัส ขณะที่ฝั่งแพลตฟอร์มส่งแมนเดตเชิงเข้ารหัสที่พิสูจน์ว่าผู้ใช้อนุมัติเงื่อนไขนั้นแล้ว วัตถุประสงค์ที่สเปกระบุไว้คือ "ลดความเสี่ยงของการปลอมแปลงและข้อพิพาทลงอย่างมีนัยสำคัญ"
• จำนวนผู้สนับสนุนไม่ใช่จำนวนผู้เชื่อมต่อจริง "พันธมิตรระดับโลกกว่า 20 ราย" เป็นถ้อยคำที่ Google เผยแพร่ และมันหมายถึงการสนับสนุน ณ เวลาที่เขียน เรายังไม่พบแหล่งข้อมูลปฐมภูมิใดที่ระบุจำนวนร้านค้าที่ใช้งาน UCP จริงในระบบ

ชุดเฮดเดอร์นำมาจากคู่มือปฏิบัติที่ Google เผยแพร่ในวันเปิดตัว แหล่งอ้างอิงอยู่ท้ายบทความ

UCP คืออะไร ในจำนวนคำที่น้อยที่สุดเท่าที่ยังจริงอยู่

ก่อนเข้าสู่ข้อถกเถียง นี่คือข้อเท็จจริงที่ตรวจสอบได้เอง ทั้งหมดมาจากสเปกที่เผยแพร่บน ucp.dev และบล็อกนักพัฒนาของ Google ซึ่งดึงข้อมูลทั้งคู่เมื่อวันที่ 5 กันยายน 2026

มีสองแถวในตารางนี้ที่ควรหยุดดู เพราะบทความส่วนใหญ่ข้ามไปทั้งคู่

แถวแรกคือช่องทางรับส่ง UCP ไม่ใช่เรื่องของ MCP และไม่ใช่เรื่องของ REST ข้อมูลชุดเดียวกันที่ประกาศไว้ถูกเสิร์ฟผ่าน REST, MCP, A2A และ binding แบบฝัง โดยฝั่งร้านค้าเป็นคนเลือก นี่คือการปฏิเสธอย่างจงใจที่จะไม่เดิมพันว่าท่อประปาฝั่งเอเจนต์แบบไหนจะชนะ

แถวที่สองคือการกำหนดเวอร์ชันตามวันที่ 2026-04-08 ไม่ใช่เวอร์ชันเชิงความหมาย แต่เป็นวันที่ สเปกให้เหตุผลว่าเพื่อให้เรียงลำดับตามเวลาได้ชัดและเปรียบเทียบได้ไม่กำกวม แต่ผลในทางปฏิบัติอยู่ตรงอื่น นั่นคือทุกเซสชันที่เจรจากันแล้วจะบันทึกวันที่ของกติกาที่ใช้กำกับเซสชันนั้นไปด้วย นี่คือการตัดสินใจเรื่องการเก็บจดหมายเหตุที่สวมเสื้อคลุมเป็นการตัดสินใจเรื่องเวอร์ชัน และมันวางโทนให้กับเอกสารทั้งฉบับ

คอขวดที่มันถูกสร้างมาเพื่อกำจัด

Google อธิบายปัญหานี้ว่าเป็นโจทย์ N×N ธุรกิจทุกรายที่อยากปรากฏอยู่ในพื้นผิวสนทนาต้องสร้างการเชื่อมต่อเฉพาะทางให้กับแต่ละพื้นผิว ส่วนพื้นผิวก็ต้องรับธุรกิจแต่ละรายเข้าระบบแยกกัน สุดท้ายจึงไม่มีใครส่งของออกมาได้เลย

บทความฝั่งวิศวกรรมของ Shopify ที่เผยแพร่วันเดียวกันโดย Ilya Grigorik ตำแหน่ง distinguished engineer เข้าหาปัญหาเดียวกันจากข้างล่าง หลังผ่านมากว่า 20 ปี ธุรกรรมหลายพันล้านรายการ และร้านค้าหลายล้านราย บทเรียนคือการค้าปฏิเสธที่จะถูกทำให้เป็นมาตรฐานเดียว "ตัวเลือกและกติกาการชำระเงินต่างกันตามคุณสมบัติของตะกร้า ผู้ซื้อ และตลาด ส่วนลดมีกติกาการซ้อนและการรวมที่สู้กับประมวลกฎหมายภาษีได้ ตัวเลือกการจัดส่งระเบิดออกเป็นการเรียงสับเปลี่ยนที่คุมไม่อยู่" แล้วจึงตามด้วยประโยคที่ควรเก็บไว้ "ความซับซ้อนนี้ไม่ใช่บั๊ก แต่เป็นคุณสมบัติที่ผุดขึ้นจากความหลากหลายของผู้ค้าปลีก"

บรรทัดเดียวนั้นอธิบายสถาปัตยกรรมทั้งหมด ถ้ายอมรับว่าร้านค้าแตกต่างกันอย่างลดทอนไม่ได้ คุณก็กำหนดมาตรฐานให้พฤติกรรมไม่ได้ สิ่งที่กำหนดมาตรฐานได้มีเพียงวิธีที่ร้านค้า ประกาศ พฤติกรรมของตัวเอง และวิธีที่เอเจนต์รู้ว่าตัวเองเพิ่งตกลงอะไรไป

โครงสร้างที่ธุรกิจเผยแพร่ไว้ที่ /.well-known/ucp แหล่งอ้างอิง: สเปก UCP 2026-04-08 หัวข้อ Overview

การค้นพบเกิดขึ้นก่อนบทสนทนาจะเริ่ม

นี่คือลำดับการทำงานตามที่สเปกและคู่มือของ Google อธิบายไว้ ควรไล่ตามทีละขั้นตามตัวอักษร เพราะลำดับนี่แหละคือข้อถกเถียง

1. ธุรกิจเผยแพร่โปรไฟล์ ไว้ที่ /.well-known/ucp โดยประกาศเวอร์ชันโปรโตคอล บริการหนึ่งรายการหรือมากกว่า (dev.ucp.shopping) ความสามารถที่อยู่ภายใน ช่องทางรับส่งและ endpoint ตัวจัดการการชำระเงินที่ใช้ได้ และสิ่งที่จะสำคัญในภายหลังคือ signing_keys สาธารณะของตัวเอง
2. เอเจนต์ประกาศโปรไฟล์ของตัวเองในทุกคำขอ ผ่านเฮดเดอร์ UCP-Agent ในไวยากรณ์พจนานุกรมตาม RFC 8941 เช่น UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json" ส่วนบนช่องทาง MCP ข้อมูลเดียวกันจะเดินทางในอ็อบเจกต์ meta
3. ธุรกิจคำนวณส่วนร่วม จากความสามารถของตัวเอง จะเก็บเฉพาะรายการที่แพลตฟอร์มประกาศไว้ด้วย จากนั้นสำหรับแต่ละรายการที่รอด จะเลือกเวอร์ชันสูงสุดที่ปรากฏใน ทั้งสอง อาเรย์ ถ้าไม่มีเวอร์ชันร่วมกันเลย ความสามารถนั้นจะหลุดออกทั้งรายการ
4. ส่วนขยายที่กำพร้าจะถูกตัดทิ้ง ส่วนขยายที่ประกาศ extends: "dev.ucp.shopping.checkout" จะหายไปถ้า checkout ไม่รอด การตัดจะวนซ้ำจนไม่มีอะไรหลุดเพิ่ม ซึ่งครอบคลุมโซ่การพึ่งพาแบบต่อทอด
5. ฝ่ายที่เลือกคือธุรกิจ UCP ใช้สถาปัตยกรรมแบบเซิร์ฟเวอร์เป็นผู้เลือก ผู้ตัดสินว่าอะไรทำงานอยู่ในเซสชันคือร้านค้า ไม่ใช่เอเจนต์ และจะส่งทะเบียนความสามารถที่ทำงานอยู่กลับมาในคำตอบ

การตั้งชื่อไม่ใช่ธรรมเนียมแต่เป็นเรื่องที่ถูกกำกับ ทุกความสามารถเขียนในรูป {โดเมนกลับด้าน}.{บริการ}.{ความสามารถ} เช่น dev.ucp.shopping.checkout สำหรับตัวมาตรฐาน และ com.example.payments.installments สำหรับตัวเฉพาะของร้านค้า ผู้ค้าปลีกสามารถคิดความสามารถที่ไม่มีใครมีขึ้นมาเองได้โดยไม่ต้องขออนุญาตใครและไม่ชนกับใคร เพราะโดเมนกลับด้านคือแหล่งอำนาจในตัวมันเอง

ความล้มเหลวก็มีการจัดหมวดของมันเอง และการแบ่งนี้ให้แง่คิด สเปกแยก ความล้มเหลวในการค้นพบ (ข้อผิดพลาดระดับการรับส่ง โดย invalid_profile_url ตอบ 400, profile_unreachable ตอบ 424, profile_malformed ตอบ 422) ออกจาก ความล้มเหลวในการเจรจา ซึ่งเป็นผลลัพธ์เชิงธุรกิจ จึงตอบกลับเป็น 200 ตามปกติพร้อม capabilities_incompatible อยู่ในเนื้อหา "ผมติดต่อคุณไม่ได้" กับ "เราไม่มีอะไรตรงกันเลย" เป็นคนละเหตุการณ์ และ UCP ปฏิเสธที่จะยุบทั้งสองอย่างเข้าเป็น 400 เดียว

เฮดเดอร์สี่ตัวเดินทางไปกับทุกคำขอที่เปลี่ยนสถานะ

ทีนี้มาดูการเรียกจริง นี่คือตัวอย่างของ Google เองในวันเปิดตัว เป็นการสร้างเซสชันชำระเงินกับร้านดอกไม้ตัวอย่าง

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

เฮดเดอร์สี่ตัว ลองถามว่าแต่ละตัวมีไว้ทำอะไร แล้วรูปแบบหนึ่งจะโผล่ออกมา

สามในสี่ตัวไม่ได้มีไว้เพื่อธุรกรรม แต่มีไว้เพื่อความขัดแย้งเรื่องธุรกรรมนั้น

นี่ไม่ใช่ผลพลอยได้จากการเขียน API ให้สะอาด คีย์ idempotency และ ID คำขอเป็นแนวปฏิบัติที่ดีทั่วไปในวงการชำระเงินก็จริง แต่สเปกเดินไปไกลกว่านั้นมาก และยิ่งเดินไกล เจตนาก็ยิ่งชัด

การปฏิเสธไม่ได้คือเป้าหมายการออกแบบ ไม่ใช่ของแถมด้านการกำกับ

UCP ระบุกลไกยืนยันตัวตนสี่แบบที่ธุรกิจรับได้ ได้แก่ คีย์ API, OAuth 2.0, mTLS และลายเซ็นข้อความ HTTP ตาม RFC 9421 สามแบบแรกเป็นเรื่องธรรมดา แบบที่สี่กำลังทำอะไรบางอย่างที่เฉพาะเจาะจง

ในแบบลายเซ็นข้อความ ทั้งสองฝ่ายเผยแพร่คีย์สาธารณะไว้ในอาเรย์ signing_keys ของเอกสารโปรไฟล์ฉบับเดียวกันกับที่ประกาศความสามารถของตน ผู้ตรวจสอบจะดึง keyid ออกจากเฮดเดอร์ Signature-Input แล้วจับคู่กับ kid ในชุดคีย์ที่ผู้เซ็นเผยแพร่ไว้ จากนั้นจึงตรวจลายเซ็น ไม่ต้องมีความลับร่วม ไม่ต้องลงทะเบียน ไม่ต้องมีบัญชี สเปกเรียกผลลัพธ์นี้ว่า การเข้าร่วมโดยไม่ต้องขออนุญาต โดยระบุว่า "แพลตฟอร์มใดก็ตามที่มีโปรไฟล์ซึ่งค้นพบได้ สามารถโต้ตอบกับธุรกิจใดก็ได้โดยไม่ต้องลงทะเบียนล่วงหน้า"

ช่องโหว่ที่เห็นชัดถูกปิดด้วยการผูกตัวตน ไม่ว่าจะใช้กลไกใด ผู้ตรวจสอบ ต้อง ยืนยันว่าตัวตนที่ผ่านการยืนยันแล้วมีสิทธิ์กระทำการแทนโปรไฟล์ที่ระบุใน UCP-Agent จริง และต้องปฏิเสธคำขอเมื่อสองอย่างขัดกัน คุณจะยืนยันตัวตนในนามตัวเองแล้วอ้างว่าเป็นเอเจนต์ของคนอื่นไม่ได้

และเว็บฮุกที่วิ่งจากธุรกิจไปหาแพลตฟอร์ม ต้อง ถูกเซ็น ไม่ใช่ควร แต่คือต้อง การอัปเดตวงจรชีวิตคำสั่งซื้ออย่างการจัดส่ง การส่งมอบ และการคืนสินค้า คือจุดเดียวในโปรโตคอลที่ข้อกำหนดนี้เด็ดขาด เพราะมันคือข้อความที่มาถึงหลังจากเงินเคลื่อนไปแล้ว และไม่มีใครเฝ้าดูแบบเรียลไทม์

แหล่งอ้างอิง: สเปก UCP 2026-04-08 หัวข้อ Identity & Authentication และ Transaction Integrity

แล้วก็มาถึงยอดบันได สำหรับเอเจนต์อัตโนมัติและธุรกรรมมูลค่าสูง UCP นิยามส่วนขยายแบบเลือกใช้ชื่อ dev.ucp.shopping.ap2_mandate เมื่อทั้งสองฝ่ายเจรจาเปิดใช้แล้ว

• ธุรกิจจะให้ลายเซ็นเชิงเข้ารหัสบนเงื่อนไขการชำระเงิน และ
• แพลตฟอร์มจะให้แมนเดตเชิงเข้ารหัสที่พิสูจน์ว่าผู้ใช้อนุมัติเงื่อนไขเหล่านั้น

เอเจนต์เซ็นอ็อบเจกต์แมนเดตด้วยกุญแจส่วนตัวของผู้ใช้บนพื้นผิวที่ไม่ใช่ของเอเจนต์ กล่าวคือมนุษย์อนุมัติบนหน้าจอที่ตนควบคุม ไม่ใช่ภายในลูปของเอเจนต์ที่กำลังจะใช้เงินของเขา ประโยคที่สเปกใช้ระบุวัตถุประสงค์ควรอ้างตรงตัว เพราะไม่ใช่ประโยคความปลอดภัยแบบขอไปที กลไกนี้ "ให้การรับประกันเชิงเข้ารหัสที่หนักแน่นแบบต้นทางถึงปลายทางเกี่ยวกับรายละเอียดธุรกรรมและความยินยอมของผู้เกี่ยวข้อง ลดความเสี่ยงของการปลอมแปลงและข้อพิพาทลงอย่างมีนัยสำคัญ"

ประเด็นอยู่ตรงนี้ โปรโตคอลที่ออกแบบมาเพื่อให้เอเจนต์ช้อปอย่างเดียวไม่จำเป็นต้องมีสิ่งเหล่านี้เลยสักอย่าง เงื่อนไขที่มีลายเซ็นฝั่งร้านค้าและแมนเดตที่มีลายเซ็นฝั่งผู้ใช้ไม่ใช่ฟีเจอร์ของการซื้อ แต่เป็นฟีเจอร์ของการ เถียงกัน เรื่องการซื้อนั้น หกสัปดาห์ให้หลัง ต่อหน้าคนที่ต้องตัดสินว่าใครถูก

ตรงไหนที่คำบรรยายวิ่งแซงหลักฐาน

มีสามเรื่องเกี่ยวกับ UCP ที่ถูกพูดซ้ำ ๆ แต่แหล่งข้อมูลปฐมภูมิไม่ได้รองรับตามที่พูด

"พันธมิตรกว่า 20 ราย" คือจำนวนผู้ให้การสนับสนุน ถ้อยคำของ Google คือ UCP ถูก "พัฒนาร่วมกันและได้รับการสนับสนุนจากพันธมิตรกว่า 20 ราย" การสนับสนุนคือการแถลงสนับสนุนต่อสาธารณะ ไม่ใช่การเชื่อมต่อที่ส่งมอบแล้ว และยิ่งไม่ใช่ร้านค้าที่เปิดใช้งานจริง เราหาแหล่งข้อมูลปฐมภูมิที่ระบุจำนวนร้านค้าที่ทำธุรกรรมผ่าน UCP แล้วไม่พบ

"มาตรฐานเปิด" กับ "มาตรฐานของ Google" จริงทั้งคู่ และความตึงระหว่างสองอย่างนี้มีอยู่จริง สเปกเป็นโอเพนซอร์ส คลัง GitHub รับ pull request และธรรมเนียมการตั้งชื่อจงใจเปิดให้ใครก็ได้อ้างสิทธิ์ในเนมสเปซของตัวเอง ในเวลาเดียวกัน Google เป็นผู้สร้างการนำไปใช้อ้างอิงรายแรก และการจะเข้าร่วมกับ การนำไปใช้นั้น ธุรกิจต้องมีบัญชี Google Merchant Center ที่ใช้งานอยู่พร้อมสินค้าที่ผ่านเกณฑ์การชำระเงิน โปรโตคอลเป็นกลาง แต่เวทีแรกมีประตูกั้น

UCP ไม่ได้ตัดร้านค้าออกไป เรื่องนี้ถูกเล่าผิดบ่อยพอที่จะต้องพูดตรง ๆ ภายใต้ UCP ธุรกิจยังคงถือตรรกะทางธุรกิจของตัวเองและยังเป็น Merchant of Record อยู่ Embedded Checkout Protocol ของ Shopify ให้คำมั่นเดียวกันจากอีกด้าน คือเมื่อขั้นตอนใดต้องการมนุษย์ เอเจนต์จะโหลด continue_url แล้วหน้าชำระเงินจริงของร้านค้าจะแสดงอยู่ภายในพื้นผิวของเอเจนต์ผ่านช่องทาง JSON-RPC 2.0 โดยผู้ปิดธุรกรรมยังคงเป็นร้านค้า เอเจนต์คือพื้นผิว ไม่ใช่ตัวแทนที่มาแทนที่

สี่เรื่องที่เรายืนยันไม่ได้ และขอระบุไว้ตรง ๆ

สเปกที่เผยแพร่บน ucp.dev ณ เวลาที่ดึงข้อมูลเป็นเวอร์ชัน 2026-04-08 และรายการความสามารถมาตรฐานของมัน คือ Cart, Checkout, Identity Linking, Order ต่างจากคู่มือวันที่ 11 มกราคม ซึ่งตัวอย่างรันบนเวอร์ชัน 2026-01-11 และแสดง checkout, discount กับ fulfillment มีบางอย่างถูกเพิ่มเข้ามาระหว่างสองวันนั้น เราหาบันทึกการเปลี่ยนแปลงปฐมภูมิที่ระบุช่วงเวลาไม่พบ และไม่พบบันทึกการปล่อยเวอร์ชันที่มีวันที่กำกับสำหรับเวอร์ชันระหว่างกลาง เราจึงรายงานความต่างนี้แทนที่จะรายงานว่ามีเหตุการณ์ปล่อยเวอร์ชัน

เราไม่พบตัวเลขที่เผยแพร่เกี่ยวกับจำนวนร้านค้าที่ใช้ UCP จริง ไม่ว่าจาก Google, Shopify หรือพันธมิตรผู้สนับสนุนรายใด การไม่มีตัวเลขไม่ได้พิสูจน์ว่าตัวเลขน้อย แต่มันคือเหตุผลที่เราไม่พิมพ์ตัวเลขใดลงไปเลย

Google ระบุว่าตนสร้างการนำไปใช้อ้างอิงรายแรกที่ขับเคลื่อนการซื้อภายใน AI Mode ของ Search และแอป Gemini เรายังไม่ได้ตรวจสอบอย่างเป็นอิสระถึงขอบเขตการให้บริการ พื้นที่ หรือขนาดของการเปิดใช้งานนั้น

UCP จะกลายเป็นมาตรฐาน หลัก ของการค้าแบบเอเจนต์หรือไม่ ณ เวลาที่เขียนยังไม่มีทางรู้ และบทความใดที่บอกเป็นอย่างอื่นคือกำลังเดา การอ่านอย่างซื่อตรงจึงแคบกว่านั้น คือมีสเปกอยู่จริง มันเปิดเผย มันพิถีพิถันเรื่องการพิสูจน์อย่างผิดปกติ และมีบริษัทขนาดใหญ่มากหลายรายร่วมลงชื่อในประกาศ

ครึ่งที่ยังไม่ได้เซ็น

ลองถอยออกจากเรื่องการค้า เพราะส่วนที่น่าสนใจสามารถขยายไปใช้กับเรื่องอื่นได้

UCP อธิบายโลกที่เครื่องจักรลงมือแทนคุณ และทุกก้าวของการลงมือนั้นทิ้งบางอย่างไว้ ใครเป็นคนขอ มีลายเซ็น เงื่อนไขอะไร มีลายเซ็น กี่ครั้ง มีคีย์กำกับ ตามลำดับไหน มีการเชื่อมโยงไว้ หกสัปดาห์ให้หลัง เมื่อยอดเรียกเก็บถูกโต้แย้ง จะมีวัตถุพยานอยู่ตรงนั้น ไม่มีใครต้องอาศัยความจำ

ทีนี้ลองคิดว่าอำนาจในการลงมือเหล่านั้นมาจากไหนกันแน่ เอเจนต์ซื้อของ 400 หน่วยเพราะมีการตัดสินใจจัดซื้อเกิดขึ้น สัญญาต่ออายุเพราะมีคนตกลงเงื่อนไขข้อหนึ่ง ขอบเขตงานเปลี่ยนเพราะสองคนคุยกันเมื่อวันพฤหัสฯ แล้วคนหนึ่งบอกว่าตกลง

บทสนทนาเหล่านั้นคือครึ่งที่ยังไม่ได้เซ็นของกระบวนการเดียวกัน ครึ่งฝั่งเครื่องจักรกำลังถูกสร้างขึ้นบนใบเสร็จเชิงเข้ารหัสและบนสเปกที่ถือว่าข้อพิพาทเป็นสถานการณ์ระดับต้น ๆ ส่วนครึ่งฝั่งมนุษย์ ในองค์กรส่วนใหญ่ คือความจำของคนหนึ่ง ความจำที่ต่างออกไปของอีกคนหนึ่ง และบทสรุปที่เขียนขึ้นจากทั้งสองอย่าง

ความไม่สมมาตรนี้จะแย่ลงก่อนที่จะดีขึ้น เพราะครึ่งฝั่งเครื่องจักรพัฒนาตามจังหวะของสเปก ส่วนครึ่งฝั่งมนุษย์ไม่ได้พัฒนาเลย และรูปแบบความล้มเหลวก็ชัดเจน ปัญหาไม่ใช่ว่าคนโกหก แต่คือวัตถุที่ได้มาจากการแปรรูป ไม่ว่าจะเป็นบทสรุป รายงานการประชุม หรือรายการงานที่ต้องทำ กลายเป็นตัวบันทึกเสียเองนับจากวินาทีที่สิ่งซึ่งมันถูกแปรรูปมาหายไป บทสรุปสูญเสียข้อมูลโดยโครงสร้าง นั่นแหละคือสิ่งที่ทำให้มันมีประโยชน์ และก็คือสิ่งเดียวกันที่ทำให้มันเป็นแหล่งข้อมูลปฐมภูมิที่แย่ เพราะเมื่อต้นฉบับถูกทิ้งไปแล้ว ไม่มีทางแยกออกได้เลยว่าบทสรุปที่สูญข้อมูลกับบทสรุปที่แม่นยำต่างกันตรงไหน

ผู้ออกแบบ UCP เข้าใจเรื่องนี้ในระดับโปรโตคอลและเขียนมันลงไป คือเก็บต้นฉบับที่มีลายเซ็นไว้ จะแปรรูปอะไรออกมาก็ตามใจ แต่ต้องทำให้สิ่งที่แปรรูปนั้นตรวจทานย้อนกลับไปยังสิ่งที่ไม่เคยขยับได้เสมอ นี่คือวินัย ไม่ใช่เทคโนโลยี และมันใช้ได้กับหนึ่งชั่วโมงที่คนคุยกันดีเท่า ๆ กับที่ใช้ได้กับ POST /checkout-sessions

บทสรุป: การค้าแบบเอเจนต์คือมาตรฐานใบเสร็จที่สวมชุดช้อปปิ้ง

Universal Commerce Protocol มักถูกอธิบายว่าเป็นวิธีให้เอเจนต์ AI ซื้อของ แต่ถ้าอ่านตั้งแต่ต้นจนจบ มันถูกอธิบายได้ดีกว่าในฐานะความพยายามตอบคำถามที่ทุกสิ่งซึ่งเป็นเอเจนต์กำลังจะต้องเจอซ้ำแล้วซ้ำเล่า เมื่อเครื่องจักรลงมือแทนฉัน มีอะไรบ้างที่พิสูจน์ได้แน่ชัดว่าฉันตกลงอะไรไป

คำตอบของ UCP เป็นคำตอบที่ดี คือประกาศความสามารถของคุณต่อสาธารณะ เซ็นเงื่อนไข เซ็นความยินยอม ใส่คีย์ให้การส่งซ้ำ เชื่อมโยงการเรียก และเซ็นเว็บฮุกที่จะรายงานภายหลังว่าเกิดอะไรขึ้น โปรโตคอลนี้จะชนะหรือไม่ยังเปิดกว้างจริง ๆ แต่คำถามที่มันถูกสร้างขึ้นรอบ ๆ นั้นจะไม่หายไป ไม่ว่าใครจะชนะก็ตาม

จึงเหลือคำถามหนึ่งที่ควรนั่งคิดกับมัน อีกไม่นานเอเจนต์ของคุณจะมีบันทึกว่าตัวมันตกลงอะไรไว้ ดีกว่าบันทึกที่คุณมีว่าคุณตกลงอะไรไว้ แล้วเรื่องนี้จะไปจบตรงไหน

---

Telli.sh อยู่ตรงไหน เราสร้างครึ่งที่ยังไม่ได้เซ็นนั่นแหละ Telli.sh บันทึกบทสนทนา แยกผู้พูด แปลสดข้ามภาษาได้ 15 ภาษา และเก็บไฟล์เสียงต้นฉบับกับข้อความถอดเสียงฉบับเต็มไว้ข้างบทสรุปทุกฉบับที่มันสร้าง เพื่อไม่ให้วัตถุที่ได้จากการแปรรูปกลายเป็นวัตถุเพียงชิ้นเดียวที่เหลืออยู่ Telli.sh ไม่ได้รองรับ UCP และไม่ได้อ้างเช่นนั้น เราจัดการกับอีกปลายหนึ่งของปัญหาเดียวกัน นั่นคือการตัดสินใจที่อนุมัติให้เอเจนต์ลงมือทำ มักเกิดขึ้นด้วยคำพูดและไม่ถูกเก็บไว้ที่ใดเลย

บันทึกการประชุมตัดสินใจครั้งต่อไปของคุณ

แหล่งอ้างอิง

• สเปก Universal Commerce Protocol หัวข้อ Overview เวอร์ชัน 2026-04-08 — โมเดลบริการ ความสามารถ และส่วนขยาย ธรรมเนียมการตั้งชื่อ การกำหนดเวอร์ชันตามวันที่ อัลกอริทึมหาส่วนร่วมของความสามารถ รหัสข้อผิดพลาดของการเจรจาและลายเซ็น ความสามารถมาตรฐาน (Cart, Checkout, Identity Linking, Order) ช่องทางรับส่ง เฮดเดอร์ UCP-Agent และไวยากรณ์ RFC 8941 กลไกยืนยันตัวตนกับการเข้าร่วมโดยไม่ต้องขออนุญาต การค้นพบคีย์ผ่าน signing_keys การผูกตัวตน ข้อบังคับให้เซ็นเว็บฮุก และหัวข้อ Transaction Integrity and Non-Repudiation ดึงข้อมูลเมื่อ 5 กันยายน 2026
• Google Developers Blog, "Under the Hood: Universal Commerce Protocol (UCP)", 11 มกราคม 2026 — รายชื่อพันธมิตรและตัวเลขผู้สนับสนุนกว่า 20 ราย ความเข้ากันได้กับ AP2, A2A และ MCP การอธิบายแบบ N×N ไฟล์ manifest /.well-known/ucp คู่มือห้าขั้นตอนและชุดเฮดเดอร์ของ POST /checkout-sessions สถานะ Merchant of Record กับตัวเลือกแบบฝัง การนำไปใช้อ้างอิงของ Google ใน AI Mode และ Gemini และเงื่อนไข Merchant Center ดึงข้อมูลเมื่อ 5 กันยายน 2026
• Shopify Engineering, Ilya Grigorik, "Building the Universal Commerce Protocol", 11 มกราคม 2026 — บริบทกว่า 20 ปี ธุรกรรมหลายพันล้านรายการ และร้านค้าหลายล้านราย ข้อโต้แย้ง "ไม่ใช่บั๊กแต่เป็นคุณสมบัติที่ผุดขึ้น" หลักการออกแบบสี่ข้อ และการส่งต่อผ่าน Embedded Checkout Protocol บน JSON-RPC 2.0 ด้วย continue_url ดึงข้อมูลเมื่อ 5 กันยายน 2026
• Agent Payments Protocol (AP2) — โปรโตคอลการชำระเงินที่ UCP ประกาศความเข้ากันได้ด้วย
• Universal Commerce Protocol บน GitHub — คลังโอเพนซอร์สที่ถูกระบุชื่อในประกาศทั้งสองฉบับ
• บทวิเคราะห์ GPT-6 Astra ของเรา และสิ่งที่ชั้นการบันทึกยังเป็นผู้ตัดสิน — ข้อโต้แย้งเดียวกันจากฝั่งโมเดล คุณภาพการให้เหตุผลถูกกำหนดเพดานไว้แล้วโดยสิ่งที่สร้างบันทึกซึ่งมันใช้เป็นฐานในการให้เหตุผล