อ่านสถาปัตยกรรมแบบแบ่งชั้นของ SKU.md v0.8: ข้อมูลที่โฮสต์เองกับธุรกรรมที่ต้องผ่านแพลตฟอร์ม

แผนภาพ SKU.md v0.8 ไม่ได้เรียงเทคโนโลยีจากง่ายไปยาก แต่เป็นแผนที่แสดงจุดที่ผู้ควบคุมเปลี่ยนมือ เอเจนต์ AI เริ่มจากโดเมนของผู้ขาย ผ่านเส้นทางค้นพบที่เผยแพร่ไว้และบริบทสินค้าที่ผู้ขายจัดทำ ก่อนเข้าสู่ความสามารถที่ต้องพึ่งพาโปรโตคอลภายนอก แพลตฟอร์ม ระบบยืนยันตัวตน หรือระบบหลังบ้านสำหรับธุรกรรม

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

สีบอกขอบเขตอำนาจ

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

ในชั้นสีเขียวอมฟ้า ผู้ขายมีอำนาจเผยแพร่ ผู้ขายตั้งค่า robots.txt ให้บริการ Sitemap เผยแพร่ llms.txt และ sku.md ที่ราก เพิ่มดัชนีพาร์ทิชันกับเอกสารสินค้า และสร้างเครื่องมือที่ทำงานบนหน้าเว็บได้จากโดเมนของตนเอง ยังคงต้องมีโฮสติ้งที่ถูกต้อง การแยกวิเคราะห์ที่ปลอดภัย และข้อมูลที่แม่นยำ แต่การวางไฟล์ไม่ต้องขออนุมัติล่วงหน้าจากแพลตฟอร์มการค้า

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

ดังนั้น แผนภาพจึงแยกสองเรื่องที่มักสับสนกัน คือการเผยแพร่คำประกาศ กับการมีอำนาจดำเนินการตามคำประกาศนั้น

ผู้ขายควบคุมการกำกับดูแลและการค้นพบ

ชั้นแรกประกอบด้วย robots.txt, llms.txt และ sitemap.xml ทั้งสามช่วยให้ผู้บริโภคค้นหาและตีความทรัพยากรของเว็บไซต์ แต่มีบทบาทต่างกัน

robots.txt ระบุกฎการเก็บข้อมูลและตำแหน่ง Sitemap ได้ แต่ไม่ใช่โปรโตคอลทั่วไปสำหรับยืนยันตัวตนหรืออนุมัติการเข้าถึง Sitemap ใช้ค้นพบ URL จำนวนมาก แต่ไม่ได้พิสูจน์ว่าเนื้อหาในทุก URL เป็นปัจจุบัน ถูกต้อง หรือน่าเชื่อถือ llms.txt ให้คำแนะนำสั้น ๆ แก่ระบบ AI ได้ แต่การเผยแพร่ไม่ได้รับประกันว่าโมเดลหรือเอเจนต์จะอ่าน ยอมรับ อ้างอิง หรือเพิ่มอันดับ

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

ชุดเอกสาร SKU-MD รักษาขนาดของรากให้คงที่

ชั้นสีเขียวอมฟ้าที่สองคือชุดเอกสาร SKU-MD

• แมนนิเฟสต์ Catalog ที่ราก /sku.md
• ดัชนีพาร์ทิชันแบบเลือกใช้สำหรับ Catalog ขนาดใหญ่หรือแยกส่วน
• เอกสาร *.sku.md รายสินค้า

O(1) ในแผนภาพหมายถึงขนาดของแมนนิเฟสต์ที่รากควรอยู่ในขอบเขตคงที่เมื่อ Catalog เติบโต ไม่ได้หมายถึงค้นหาทั้ง Catalog ได้ในเวลาคงที่ รากไม่ฝังสินค้าทั้งหมด แต่เชื่อมไปยังจุดเข้า Catalog พาร์ทิชัน และเอกสารสินค้า จึงรักษาความสั้นและเสถียรได้

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

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

ชั้นข้อมูลสินค้าแยกความรู้คงที่จากสถานะที่เปลี่ยนแปลง

ชั้นสีเขียวอมฟ้าที่สามวาง Product JSON-LD คู่กับ SKU.md Knowledge และแสดง offer_snapshot แยกจาก live_verification เพื่อไม่ให้ข้อเท็จจริงที่เสถียรกับสถานะการค้าที่เปลี่ยนง่ายปะปนในระเบียนเดียว

Product JSON-LD ให้ความหมายของสินค้าระดับหน้าเว็บที่ใช้กันแพร่หลาย SKU.md Knowledge จัดระเบียบข้อเท็จจริง คำกล่าวอ้าง ข้อมูลเปิดเผย คำแนะนำ ข้อจำกัด และหลักฐานที่เกี่ยวข้องได้ Knowledge คือที่เก็บข้อความที่ควรเผยแพร่และตรวจสอบ ไม่ใช่ที่ตรึงราคา สินค้าคงคลัง ค่าขนส่ง หรือโปรโมชันระยะสั้นไว้ในเนื้อหาถาวร

offer_snapshot บันทึกสถานะที่สังเกต ณ เวลาหนึ่งสำหรับตลาดและ Variant ที่ระบุ observed_at, refresh_after และ offer_valid_until ที่มีอยู่จริงช่วยประเมินความเป็นปัจจุบัน ภาพบันทึกนี้พิสูจน์ได้เพียงสิ่งที่สังเกตในอดีต ไม่ได้ล็อกสินค้าและไม่รับประกันว่าราคาและความพร้อมจำหน่ายจะเหมือนเดิมตอนตัดสินใจ

live_verification เป็นวิธีตรวจสอบปัจจุบันแบบระมัดระวัง โดยเปิดหน้าสินค้าสาธารณะอีกครั้งและตรวจการแสดงผลของ Variant เดิม ไม่ใช่ Catalog Lookup API แบบมีโครงสร้างและไม่สามารถซื้อสินค้าโดยตรง หากผู้บริโภคระบุ live_lookup แบบมีโครงสร้างที่ใช้ได้ ก็ควรเลือกวิธีนั้นก่อน มิฉะนั้นจึงตรวจซ้ำบนหน้าสาธารณะที่ผู้ขายควบคุม

capabilities[] และ protocol_profiles[] เป็นคนละเส้นทาง

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

capabilities[]: ความสามารถขณะทำงานที่ผู้ขายเผยแพร่

เมื่อไม่มี Profile ที่มีอำนาจจากโปรโตคอลภายนอก หรือความสามารถเกิดขึ้นขณะหน้าเว็บทำงาน capabilities[] อธิบายฟังก์ชันทั่วไปอย่างเครื่องมือหน้า WebMCP ได้ ผู้ขายสร้างเครื่องมือในหน้าร้านและประกาศขอบเขต สถานะ วิธีค้นพบ และวิธีเข้าถึง

เครื่องมือขณะหน้าเว็บทำงานผูกกับบริบทของหน้า อาจต้องให้ผู้ใช้อยู่ด้วย จำกัดเฉพาะสินค้าหรือ Cart และการเขียนลงแมนนิเฟสต์ไม่ได้สร้าง URL สำหรับเรียกจากระยะไกลโดยอัตโนมัติ “ควบคุมเอง” ไม่ได้แปลว่าเรียกได้ไม่จำกัด เพราะเบราว์เซอร์ นโยบายเว็บไซต์ เซสชันปัจจุบัน Schema ของเครื่องมือ และโค้ดของแอปพลิเคชันยังคงจำกัดพฤติกรรมจริง

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

protocol_profiles[]: การอ้างอิงระบบความไว้วางใจภายนอก

เมื่อโปรโตคอลภายนอกกำหนด Profile สำหรับการค้นพบที่มีอำนาจ protocol_profiles[] จะเชื่อมไปยัง Profile นั้น ไม่ได้คัดลอกเวอร์ชันโปรโตคอล บริการ การรับส่งข้อมูล จุดปลายทาง และ Schema ทั้งหมดลงในแมนนิเฟสต์ Catalog

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

นี่คือคุณสมบัติสำคัญ เอกสารค้นพบแบบเปิดสามารถอธิบายสภาพแวดล้อมที่ต้องผ่านการอนุมัติได้อย่างตรงไปตรงมา โดยไม่แสร้งว่าไม่มีข้อกำหนดในการเข้าร่วม

สองเส้นทางมาบรรจบที่ขอบเขตธุรกรรม

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

SKU.md ระบุตำแหน่งระบบเหล่านั้นและแหล่งข้อมูลที่มีอำนาจของแต่ละฟิลด์ได้ แต่แทนระบบหลังบ้านของ Checkout ไม่ได้ ยอดรวมสุดท้าย สถานะการชำระเงิน และสถานะคำสั่งซื้อต้องมาจากระบบที่ดำเนินและบันทึกการเปลี่ยนแปลงได้ หากไม่มีแหล่งข้อมูลที่ใช้ได้ ผลลัพธ์ที่ปลอดภัยคือ “ไม่ทราบ” ไม่ใช่อนุมานธุรกรรมจากเอกสารคงที่

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

ข้อผิดพลาดด้านการจัดประเภทห้าประการที่สถาปัตยกรรมหลีกเลี่ยง

1. การค้นพบไม่ใช่การนำไปใช้ เข้าถึงไฟล์ได้ไม่ได้หมายความว่าเอเจนต์จะใช้ เชื่อถือ หรือแนะนำ
2. คำประกาศไม่ใช่การอนุมัติ การระบุความสามารถหรือ Profile ของโปรโตคอลไม่ได้พิสูจน์ว่าระบบภายนอกเปิดใช้งานแล้ว
3. ภาพบันทึกไม่ใช่สถานะปัจจุบัน ต้องประเมินราคาและความพร้อมจำหน่ายพร้อมเวลาที่สังเกตและตรวจซ้ำเมื่อตัดสินใจ
4. เครื่องมือหน้าเว็บไม่ใช่อำนาจชำระเงิน ความสามารถขณะทำงานถูกจำกัดด้วยการที่ผู้ใช้อยู่ร่วม นโยบายแอปพลิเคชัน และ Checkout
5. ข้อกำหนดแบบเปิดไม่ใช่ธุรกรรมแบบเปิด อาจยังต้องมีการยืนยันตัวตน ข้อมูลรับรอง ความยินยอม การควบคุมความเสี่ยง และสัญญาทางการค้า

เอกสารขนาดเล็กก็แสดงขอบเขตอย่างซื่อสัตย์ได้

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

นี่คือแก่นของการแบ่งชั้น SKU.md ไม่ได้พยายามลบขอบเขตระหว่างบริบทสินค้าและการค้าที่ดำเนินการได้ แต่ทำให้ขอบเขตชัดเจน เพื่อให้ผู้ขายเข้าใจส่วนที่ตนควบคุม แพลตฟอร์มรักษากระบวนการอนุมัติ และผู้บริโภครับรู้จุดที่เปลี่ยนจากการอ่านหลักฐานไปสู่การขอให้ดำเนินการ

อ่านเพิ่มเติม

เปรียบเทียบหน้าที่ของแต่ละชั้นใน ตาราง llms.txt, agents.md และ SKU.md