ทีมที่ทำเอเจนต์สำหรับซื้อของหรือช่วยขายของมักเริ่มจากศูนย์เหมือนกันทุกครั้ง: ต้องมีวงจร agent, ชั้นเชื่อม catalog, จุดอนุมัติ, และชุดทดสอบพฤติกรรม Anthropic เลยตัดสินใจปล่อยของพวกนี้ออกมาเป็นโค้ดในชื่อ anthropics/commerce-agents พร้อม agent สองฝั่งคือ shopping agent และ merchant agent
สิ่งที่ทำให้แพ็กนี้น่าสนใจคือมันไม่ได้ถูกทำมาเพื่อเดโมอย่างเดียว แต่เป็นพิมพ์เขียวที่รันได้จริงภายใต้สัญญา Apache 2.0 และมี vertical ตัวอย่างถึง 4 แบบคือ retail, travel, telecom และ entertainment นั่นทำให้มันเป็นมากกว่าบทความอธิบายแนวคิด เพราะมันคือฐานเริ่มต้นที่ทีมสามารถเอาไปแตกต่อได้
สองเอเจนต์ สองบทบาท
ฝั่ง shopping agent ทำงานอยู่ในแอปของร้านค้าเอง หน้าที่คือค้นสินค้า, เปรียบเทียบตัวเลือก, จัดการคำขอหลายรายการ, สร้าง cart และตอบคำถามเรื่องออเดอร์หรือการคืนสินค้าในบทสนทนาเดียว ส่วน merchant agent ถูกออกแบบมาช่วยพนักงานร้านด้าน sales performance, inventory alert, pricing, promotion และ campaign draft
Anthropic กำหนด skills ของ shopping agent เป็น search-discovery, purchase-research, planning-goals, customer-care および memory-personalization ขณะที่ merchant agent มี performance-insights, catalog-listings, inventory-operations, pricing-promotions および marketing-campaigns โครงสร้างจึงชัดว่าบริษัทไม่ได้คิดเอเจนต์แบบตัวเดียวครอบจักรวาล แต่คิดจากหน้าที่ธุรกิจที่ต่างกัน
ทำไมถึงไม่ใช้ subagents เป็นหลัก
ข้อถกเถียงที่บทความต้นฉบับเน้นคือ Anthropic ไม่เชื่อว่าต้องมี intent router หรือ subagent แยกโดเมนทุกชั้น เพราะในงาน commerce การส่งต่อหลายครั้งทำให้เสีย state ทั้ง cart, preference และประวัติสนทนา แถม latency ยังเพิ่มขึ้นทีละรอบ
แนวทางของพวกเขาคือใส่ “skills” เข้าไปใน agent เดียวที่ถือ history อยู่แล้ว วิธีนี้ช่วยให้ modular ได้โดยไม่ต้องเสียค่านำส่งข้อมูลซ้ำในแต่ละ handoff และจาก deployment หลายราย Anthropic ระบุว่า single agent with skills ชนะทั้งแบบ prompt ใหญ่ก้อนเดียวและแบบ subagent ในด้าน quality โดยมักจะถูกกว่าและเร็วกว่า
UI ไม่ควรถูกบังคับให้เป็นข้อความล้วน
อีกจุดที่น่าสนใจคือผลลัพธ์ของ commerce agent จำนวนมากเป็น component ไม่ใช่ prose Anthropic จึงทำให้แต่ละชิ้นเป็น tool เช่น present_products, present_itinerary, present_plan_comparison โดยมี typed arguments ให้เซิร์ฟเวอร์ตรวจได้ก่อน render
ผลคือประวัติการสนทนาไม่ต้องผ่าน parser พิเศษ และ agent ยังสามารถอ้างอิงกลับไปยัง “รายการแรก” หรือ “โรงแรมแรก” จาก call ล่าสุดได้ด้วย หากต้องการ streaming ระดับ token ก็มี eager_input_streaming: true ช่วยลดการรอ buffer ฝั่งเซิร์ฟเวอร์
เวลาและต้นทุนเป็นเรื่องจริง
Anthropic บอกว่าหนึ่ง response ที่เป็น component อาจกิน 500 ถึง 700 output tokens ถ้าไม่ streaming ก็จะกลายเป็น spinner ราว 5 วินาที ซึ่งไม่ดีพอสำหรับงานขายของจริง จึงมีทั้งการ streaming component ทีละส่วนและ eager tool dispatch ที่ช่วยลดช่องว่างหลายวินาทีลงเหลือเพียงไม่กี่ร้อยมิลลิวินาที
ด้านต้นทุน prompt caching คือคันโยกสำคัญ Requests ถูกเรียงจาก global → session → volatile เพราะ caching เป็นแบบ prefix-based ถ้ามี timestamp อยู่บนสุดของ system prompt แคชจะพังทุกครั้ง Anthropic บอกว่า cached reads ใช้ต้นทุนเพียงหนึ่งในสิบของ token ใหม่ และ deployments ที่ดีทำ hit rate ได้ถึง 90 ถึง 99% ส่วน memory extraction แบบแยกกระบวนการยังให้ fact recall สูงกว่า tool เก็บความจำใน turn เดียวถึง 13%
ความหมายต่อผู้ประกอบการ/ผู้ใช้งานไทย
สำหรับอีคอมเมิร์ซไทย พิมพ์เขียวนี้มีประโยชน์ตรงที่มันช่วยลดงานเริ่มต้นซ้ำซาก เช่น การวาง agent loop, การเชื่อม catalog, และการออกแบบคำสั่งอนุมัติ แต่สิ่งที่ต้องทำต่อเองคือการปรับให้เข้ากับภาษาไทย, โครงสร้าง SKU, นโยบายคืนสินค้า, และพฤติกรรมการซื้อของคนไทยที่มักคุยยืดหยุ่นกว่าภาษาบริการแบบตะวันตก
ในมุมของสมาคมโดรนไทย สิ่งที่เห็นชัดคือ agent commerce ไม่ได้ชนะด้วยการตอบเก่งอย่างเดียว แต่มันต้องเชื่อมระบบหลังบ้านและคุม latency ให้ได้ ถ้าธุรกิจไทยไม่มี catalog ที่สะอาดหรือข้อมูลสินค้าที่เป็นโครงสร้างชัด พิมพ์เขียวนี้ก็ยังต้องใช้แรงคนมากอยู่ดี
ข้อควรระวังคือ blueprint นี้ไม่ได้แปลว่าคุณจะได้ผู้ช่วยขายของอัตโนมัติทันที ทีมต้องลงทุนเรื่อง integration, policy, observability และการทดสอบความถูกต้องของ UI component ด้วย ไม่งั้นความเร็วที่เพิ่มขึ้นอาจกลายเป็นความผิดพลาดที่เร็วขึ้นแทน