简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

การซื้อขายที่เกิดจากเครื่องจักร: สถานะปัจจุบันและโครงสร้างพื้นฐานที่ขาดหายไป

อ่านบทความนี้ใน 129 นาที

จากรางการชำระเงินด้วยเครื่องจักรสู่เครือข่ายการจัดซื้อจัดจ้างอัตโนมัติ การโยกย้ายโครงสร้างพื้นฐานที่หมุนรอบคำถามว่า "ใครจะติดอาวุธให้ฝ่ายผู้ซื้อ"

ชื่อเรื่องต้นฉบับ: 《การซื้อขายแบบ Machine-Native: สถานะปัจจุบันและโครงสร้างพื้นฐานที่ขาดหาย》

แหล่งที่มาต้นฉบับ: Waterdrop Capital

บทคัดย่อ

โมเดลขนาดใหญ่กำลังเปลี่ยนจากเครื่องมือตอบคำถามไปสู่ตัวแทนอัจฉริยะที่สามารถวางแผน เรียกใช้เครื่องมือ และส่งมอบผลลัพธ์ได้ ในขณะเดียวกัน การชำระบัญชีด้วย stablecoin โปรโตคอลการชำระเงินแบบ HTTP-native (http 402) และกระเป๋าเงินอัจฉริยะก็เริ่มประกอบกันเป็นโครงสร้างพื้นฐานการชำระเงินที่มุ่งเน้นสำหรับเครื่องจักร โปรแกรมสามารถรับใบเสนอราคา ลงนามอนุญาต และชำระเงินจำนวนเล็กน้อยได้ในขณะรันไทม์ ซึ่งเมื่อไม่กี่ปีก่อนยังเป็นเพียงแนวคิด แต่ตอนนี้กลายเป็นเส้นทางเทคโนโลยีที่ใช้งานได้จริงแล้ว

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

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

บทนำ: ตัวแทนอัจฉริยะกำลังได้รับ "งบประมาณที่ใช้จ่ายได้" แบบมีข้อจำกัด

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

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

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

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

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

1. ทำไม Agent Payment จึงกลายเป็นสนามแข่งอิสระ

1.1 จากการเรียกใช้เครื่องมือสู่การดำเนินการทางเศรษฐกิจ

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

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

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

1.2 จำนวนน้อย ความถี่สูง และผู้ขายหลายรายเปลี่ยนเศรษฐศาสตร์การชำระเงิน

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

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

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

1.3 Stablecoin กำลังเปลี่ยนจากสื่อกลางการซื้อขายไปสู่โครงสร้างพื้นฐานการชำระบัญชี

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

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

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

2. รางการชำระเงินได้ปรากฏขึ้นแล้ว: x402, MPP และธุรกรรม HTTP แบบเนทีฟ

2.1 ทำให้ 402 เปลี่ยนจากรหัสสถานะเป็นอินเทอร์เฟซเชิงพาณิชย์

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

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

x402 เป็นหนึ่งในโปรโตคอลเปิดที่ได้รับความสนใจมากที่สุดในเส้นทางนี้ โดยจัดระเบียบการท้าทายการชำระเงินและข้อมูลรับรองรอบ HTTP 402 ทำให้ผู้ให้บริการสามารถเรียกเก็บเงินตามคำขอได้ ส่วน MPP เริ่มต้นจากระบบนิเวศอีกชุดหนึ่ง สำรวจวิธีการชำระเงินแบบ charge, session และอื่นๆ ที่มุ่งเน้นเครื่องจักร การออกแบบเฉพาะของทั้งสองแตกต่างกัน แต่ร่วมกันยืนยันทิศทางหนึ่ง นั่นคือ การชำระเงินระหว่างเครื่องจักรสามารถเป็นส่วนหนึ่งของโปรโตคอลแอปพลิเคชันได้ ไม่จำเป็นต้องสร้างกระบวนการชำระบัญชีแบบmanualขึ้นนอกแอปพลิเคชัน

2.2 ความเป็นระยะยาวของการกระจายตัวของรางชำระเงิน

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

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

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

ภาพที่ 1: เมทริกซ์การกำหนดค่ารางชำระเงินภายใต้การแตกกระจาย

ดังนั้น การแตกกระจายอาจไม่หายไปเองเมื่อตลาดเติบโตเต็มที่ ตลาดบัตรธนาคารไม่ได้เหลือเพียงองค์กรบัตรเดียวจากการพัฒนาระยะยาว และคลาวด์คอมพิวติ้งก็ไม่ได้บรรจบเหลือผู้ให้บริการรายเดียว ตลาดที่เติบโตเต็มที่มักไม่ใช่การกำจัดความแตกต่าง แต่เป็นการสร้างชั้นการรวม การกำหนดเส้นทาง และการชำระบัญชีบนความแตกต่างนั้น Agent Payment มีแนวโน้มที่จะเดินตามเส้นทางวิวัฒนาการเดียวกันนี้ ความแตกแยกนี้สามารถวัดได้แล้ว ข้อมูล 30 วันล่าสุดจากเบราว์เซอร์สาธารณะสองตัว (x402scan และ mppscan) (ณ วันที่ 3 กันยายน 2026) แสดงว่าโปรโตคอล MPP บนเชน Tempo มีกระเป๋าเงินผู้ซื้อที่ใช้งานอยู่ 65,591 ราย x402 บนเชน Base มี 19,472 ราย แต่กระเป๋าเงินที่ปรากฏบนทั้งสองรางมีเพียง 365 ราย คิดเป็นไม่ถึง 0.6% ของผู้ซื้อโปรโตคอล MPP และ 2% ของผู้ซื้อ x402 Base ในจำนวนนี้มีเพียง 112 รายที่ทำธุรกรรมมากกว่าสิบครั้งบนแต่ละราง และส่วนใหญ่เป็นตัวรวมสองรางที่ใช้คีย์เดียวกันจ่ายแทน ไม่ใช่ผู้ซื้อที่นำรางชำระเงินที่สองมาใช้ด้วยตนเอง ผู้ซื้อไม่ได้เคลื่อนย้ายข้ามราง แต่ละรางกำลังสะสมกลุ่มผู้ซื้ออิสระของตนเอง

2.3 การเชื่อมต่อฝั่งผู้ขายเป็นเพียงครึ่งหนึ่งของการซื้อขาย

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

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

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

3. คอขวดที่แท้จริงของอุตสาหกรรม: การซื้อขายไม่มีวงจรปิด

ภาพที่ 2: กระบวนการจัดซื้อจัดจ้างด้วยเครื่องจักรที่สมบูรณ์

3.1 ด่านแรก: การค้นพบบริการที่ซื้อได้

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

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

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

3.2 ด่านที่สอง: การเข้าใจและเปรียบเทียบข้อเสนอ

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

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

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

3.3 ด่านที่สาม: การกระจายเงินทุนและสภาพคล่องข้ามแทร็ก

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

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

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

3.4 ด่านที่สี่: การอนุญาตตามนโยบาย

ความกังวลที่พบบ่อยที่สุดจากการชำระเงินอัตโนมัติ คือเอเจนต์จะใช้จ่ายเกินควบคุมหรือไม่ ทางแก้ไม่ใช่การเลือกระหว่าง "ห้ามโดยสิ้นเชิง" กับ "อนุญาตเต็มที่" อย่างง่ายๆ แต่คือการสร้างนโยบายหลายชั้น

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

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

3.5 ด่านที่ห้า: การชำระบัญชีสำเร็จไม่เท่ากับการส่งมอบบริการ

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

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

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

3.6 ด่านที่หก: การกระทบยอดแบบรวมศูนย์และการกำหนดความรับผิดชอบ

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

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

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

4. จากโปรโตคอลการชำระเงินสู่ชั้นการจัดซื้อของเครื่อง

4.1 นามธรรมหลักในอนาคตไม่ใช่ "Pay" แต่เป็น "Buy"

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

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

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

4.2 การรวมฝั่งผู้ซื้ออาจสำคัญกว่าการรวมฝั่งผู้ขาย

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

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

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

4.3 สร้างชื่อเสียงจากข้อมูลธุรกรรมจริง

ผู้ซื้อที่เป็นเครื่องจักรตัดสินใจเร็วมาก ไม่สามารถพึ่งพาการตรวจสอบสถานะอันยาวนานได้ จำเป็นต้องได้รับสัญญาณของคู่สัญญาในขณะที่ใบเสนอราคาปรากฏขึ้น การให้คะแนนแบบดั้งเดิมและรีวิวผู้ใช้สามารถใช้เป็นข้อมูลอ้างอิงได้ แต่ถูกปั่น ปั่นด้วยบัญชีไซบิล และผู้มีส่วนได้ส่วนเสียจัดการได้ง่าย หากรีวิวไม่ต้องการการชำระเงินจริง ต้นทุนการโจมตีก็ยิ่งต่ำ การศึกษาเชิงประจักษ์ล่าสุดเกี่ยวกับ ERC-8004 ซึ่งเป็นชั้นความเชื่อมั่นบนเชนแบบไม่ต้องขออนุญาตชั้นแรกที่มุ่งเน้นเอเจนต์ ยืนยันสิ่งนี้ [6] ข้อกำหนดต้นฉบับของโปรโตคอลนี้ระบุว่า "Payments are orthogonal to this protocol" (การชำระเงินตั้งฉากกับโปรโตคอลนี้) — รีวิวโดยค่าเริ่มต้นไม่จำเป็นต้องผูกกับธุรกรรมที่ชำระเงินจริงใดๆ หลักฐานการชำระเงินเป็นเพียงฟิลด์เสริมเท่านั้น ผลลัพธ์คือ บนเชน Ethereum, BSC และ Base (ณ วันที่ 13 พฤษภาคม 2026) มีผู้รีวิว 73.5%, 59.2% และ 90.6% ตามลำดับที่แสดงพฤติกรรมไซบิลแบบร่วมมือ

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

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

4.4 กลยุทธ์งบประมาณจะกลายเป็นความสามารถสำคัญของเอเจนต์

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

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

ในความหมายนี้ Agent Payment ไม่ใช่ปลั๊กอินทางการเงินที่อยู่นอกความสามารถของโมเดล แต่เป็นส่วนหนึ่งของสติปัญญาในการตัดสินใจ เอเจนต์ที่成熟อย่างแท้จริงควรใช้ทรัพยากรเป็น และกำหนดราคาทรัพยากรเป็น

5. เส้นทางการพัฒนาที่เป็นไปได้ของ Agent Payment

5.1 ระยะที่หนึ่ง: เครื่องมือนักพัฒนาและบริการดิจิทัลนำร่องก่อน

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

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

5.2 ระยะที่สอง: งบประมาณองค์กรและความร่วมมือระหว่างเอเจนต์หลายตัว

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

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

5.3 ระยะที่สาม: ขยายจากบริการดิจิทัลสู่เศรษฐกิจในโลกจริง

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

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

5.4 ระยะที่สี่: จากเส้นทางข้ามโปรโตคอลสู่การดำเนินการข้ามตลาด

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

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

6. ความเสี่ยงและปัญหาที่รอการแก้ไข

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

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

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

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

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

ปัญหาเหล่านี้ไม่ได้ปฏิเสธ赛道 แต่แสดงให้เห็นว่า Agent Payment จะไม่สำเร็จด้วยโปรโตคอลเดียวเท่านั้น สุดท้ายมันจะกลายเป็นโครงสร้างพื้นฐานแบบผสมผสานของการชำระเงิน ตัวตน สิทธิ์ การค้นพบ ชื่อเสียง และการกระทบยอด

7. SELAT: ติดอาวุธความสามารถฝั่งผู้ซื้อสำหรับพาณิชย์ที่เกิดจากเครื่องจักร

「SELAT」มาจากคำในภาษามลายูที่แปลว่า「ช่องแคบ」เช่น ช่องแคบมะละกา (Selat Melaka) เป็นเวลาหลายร้อยปี ไม่ว่าสินค้าจะมาจากท่าเรือใด มุ่งสู่ตลาดใด การค้าตะวันออก-ตะวันตกกระแสหลักล้วนผ่านเส้นทางน้ำนี้ SELAT ต้องการเป็นช่องแคบนั้นในพาณิชย์ที่เกิดจากเครื่องจักร ไม่ว่าร้านค้าจะเทียบท่าบนรางใด ความต้องการของเอเจนต์ก็สามารถไหลผ่านที่นี่ได้

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

ภาพที่ 3: แผนภาพชั้นผู้ซื้อของ SELAT

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

• หนึ่งคลังเงิน ใช้ N รางชำระเงิน

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

• ไดเรกทอรีเอนด์พอยต์แบบรวมศูนย์

SELAT CLI รวมทะเบียนบริการบุคคลที่สามสี่แห่ง ได้แก่ Circle, MPP, Apify และ pay.sh ตลอดจนไดเรกทอรีของ SELAT เอง ช่วยให้เอเจนต์สามารถค้นพบและเปรียบเทียบเอนด์พอยต์บริการกว่า 4,000 รายการตามเจตนารมณ์แบบเรียลไทม์

• เพดานการใช้จ่ายแบบตายตัว

ผู้ปฏิบัติงานสามารถกำหนดเพดานต่อรายการและงบประมาณต่อเซสชัน และระงับสิทธิ์การใช้จ่ายได้ตลอดเวลา เอเจนต์ไม่สามารถเพิ่มวงเงินได้ด้วยตนเอง

• พ่อค้าไม่ต้องย้ายระบบ

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

ในด้านเงินทุน SELAT สามารถใช้ร่วมกับกระเป๋าเงินเอเจนต์ใดก็ได้ รวมถึงกระเป๋าเงินเอเจนต์ของ Circle และ MetaMask SELAT จะกำหนดเส้นทางการซื้อแต่ละครั้งระหว่างรางการชำระเงิน เช่น x402 และ MPP โดยยึดตามราคาเสนอแบบเรียลไทม์

7.1 ERC-8004: พรีมิทีฟถูกต้อง แต่สัญญาณน่าสงสัย

ERC-8004 กำหนดทะเบียนสามประเภท ได้แก่ ตัวตน ชื่อเสียง และการตรวจสอบ และอนุญาตให้ผู้ซื้อส่งความคิดเห็นให้ผู้ขาย ทิศทางนี้ถูกต้อง แต่ได้แยกการชำระเงินออกจากชื่อเสียงอย่างชัดเจน: ข้อเสนอแนะไม่จำเป็นต้องมาจากธุรกรรมจริง และหลักฐานการชำระเงินที่แนบมาก็เป็นทางเลือก

การศึกษเชิงประจักษ์ต่อระบบนิเวศที่ใช้งานจริงแสดงให้เห็นว่า บน Base ผู้ให้ความคิดเห็น 93.8% ไม่เคยทำการชำระเงินผ่าน x402 เลย แต่กลับมีส่วนสนับสนุนข้อเสนอแนะถึง 94.9% นอกจากนี้ข้อเสนอแนะจำนวนมากยังแสดงพฤติกรรมซิบิลแบบร่วมมือ [6] ทะเบียนบันทึกเพียงคำกล่าวอ้าง แต่สิ่งที่ผู้ซื้อต้องการจริงคือผลลัพธ์

7.2 ชื่อเสียงที่เชื่อมโยงกับข้อมูลธุรกรรมจริงคือสิ่งที่ผู้ซื้อต้องการ

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

ชั้นผู้ซื้อที่ดำเนินการจัดซื้อมีโอกาสมากที่สุดในการเชื่อมโยงทั้งสองด้านของธุรกรรม: การซื้อทุกครั้งที่ทำผ่าน SELAT จะบันทึกว่าได้ชำระให้เอนด์พอยต์ใด ชำระเท่าใด และข้อมูลเมตาสถานะการส่งมอบหลังการชำระเงิน (2xx, 4xx, 5xx) บันทึกเหล่านี้สะสมอย่างต่อเนื่องตามพ่อค้าและรางการชำระเงิน ก่อเป็นพื้นฐานข้อมูลของ "กราฟการชำระ—การส่งมอบ" (Settlement–Delivery Graph)

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

7.3 การได้รับความน่าเชื่อถือของคู่สัญญาก่อนทำธุรกรรม

ในขณะที่ผู้คนกำลังหารือกันบน X เกี่ยวกับวิธีการออกแบบกลไก Trust ที่คล้ายกับ Google PageRank สำหรับอินเทอร์เน็ตรุ่นที่สี่ SELAT ได้เปิดตัว "ดัชนีความสามารถในการทำธุรกรรม" (Transactability Index) บนกราฟการชำระบัญชี—การส่งมอบแล้ว โดยมีเป้าหมายเพื่อให้เอเจนต์ได้รับข้อมูลความน่าเชื่อถือของคู่สัญญาที่สนับสนุนโดยผลลัพธ์ธุรกรรมจริงในขณะรันไทม์

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

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

รูปที่ 3: สัญญาณความสามารถในการทำธุรกรรมในขั้นตอนการเสนอราคา

ปัจจุบัน SELAT CLI ได้ปรับให้เข้ากับสภาพแวดล้อมรันไทม์ของเอเจนต์ เช่น Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes และ Grok Bot แล้ว

8. สรุป: เศรษฐกิจเครื่องจักรต้องการมากกว่ารางการชำระเงินที่เร็วขึ้น

Agent Payment กำลังอยู่ในช่วงที่容易被ประเมินสูงเกินไปและ容易被ประเมินต่ำเกินไป มัน容易被ประเมินสูงเกินไป เพราะการชำระเงินด้วย stablecoin ได้สำเร็จทางเทคนิคไม่ได้หมายความว่าเอเจนต์มีความสามารถในการ自治ทางธุรกิจที่成熟แล้ว มัน容易被ประเมินต่ำเกินไป เพราะเมื่อซอฟต์แวร์สามารถซื้อความสามารถภายนอกได้ภายใต้ข้อจำกัดที่ชัดเจน วิธีการจัดระเบียบ วิธีการกำหนดราคา และขอบเขตการแข่งขันของเศรษฐกิจเครื่องจักรจะเปลี่ยนไป

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

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

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

เอกสารอ้างอิง

[1] Circle, 《Building the Open Agentic Economy》, 2026. https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT, 《Counterparty Risk in Agentic Payments: The Unmeasured Half》, 2026. https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud, 《Powering AI commerce with the new Agent Payments Protocol (AP2)》, 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] x402 Foundation, 《x402: มาตรฐานการชำระเงินบนอินเทอร์เน็ตแบบเปิด》. https://github.com/x402-foundation/x402

[5] Machine Payments Protocol, 《MPP: โปรโตคอลการชำระเงินสำหรับเครื่องจักรบนพื้นฐาน HTTP 402》. https://mpp.dev/

[6] Xiong และคณะ, 《Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem》, arXiv, 2026. https://arxiv.org/abs/2606.26028