AI Agent Economic Infrastructure Research Report (Part 2)

บทความนี้เป็นรายงานวิจัยเชิงลึกที่จัดทำโดย OKX Ventures เนื่องจากเนื้อหาค่อนข้างยาว จะแบ่งออกเป็นสองตอน: ตอนแรกจะเน้นที่ภูมิหลังเชิงมหภาค โปรโตคอล x402, ERC-8004 และ Virtuals Protocol คลิกที่นี่เพื่อไปยังลิงก์; ตอนที่สองจะวิเคราะห์ OpenClaw และแนวโน้มอุตสาหกรรมโดยรวมเป็นหลัก

บทที่ 5 OpenClaw: การศึกษาเฉพาะด้านเกี่ยวกับระบบนิเวศแอปพลิเคชัน

5.1 ภูมิหลังโครงการและการระเบิดขึ้น

ในเดือนพฤศจิกายน 2025 นักพัฒนา Peter Steinberger จากออสเตรียได้โพสต์โปรเจกต์สุดสัปดาห์ลงบน GitHub สี่เดือนต่อมาในเดือนมีนาคม 2026 โปรเจกต์นี้ได้แซงหน้า React กลายเป็นโปรเจกต์ซอฟต์แวร์ที่มีดาว (Stars) มากที่สุดในประวัติศาสตร์ GitHub — มากกว่า 250,000 ดาว ในขณะที่ React ใช้เวลา 13 ปีกว่าจะถึงตัวเลขเดียวกัน

ภายใต้แนวโน้มใหญ่ที่ผลิตภัณฑ์ AI กำลังพัฒนาไปจากเครื่องมือแบบพาสซีฟสู่ Agent แอคทีฟ การเปลี่ยนแปลงที่ OpenClaw ทำคือ: AI ไม่ต้องรอให้ผู้ใช้ไปหามันอีกต่อไป แต่จะช่วยผู้ใช้ทำงานบนแพลตฟอร์มที่มีอยู่แล้วอย่างแอคทีฟ มันอาศัยอยู่ในคอมพิวเตอร์ของผู้ใช้ พร้อมทั้งเชื่อมต่อกับช่องทางมากกว่า 20 ช่องทาง เช่น WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Lark (Feishu) และอื่นๆ และควบคุมอีเมล ปฏิทิน เบราว์เซอร์ ระบบไฟล์ และตัวแก้ไขโค้ดผ่านโปรโตคอล MCP Andrej Karpathy ได้สร้างคำศัพท์สำหรับระบบประเภทนี้ว่า: Claws; ซึ่งหมายถึง AI Agent ภายในเครื่องที่ทำงานในลูปแบ็กกราวด์ สามารถตัดสินใจและดำเนินงานได้ด้วยตนเอง คำนี้กลายเป็นคำเรียกทั่วไปสำหรับ AI Agent ที่โฮสต์ภายในเครื่องในซิลิคอนวัลเลย์อย่างรวดเร็ว

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

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

5.2 การวิเคราะห์โครงสร้างทางเทคนิค

ชั้นที่หนึ่ง: ช่องทางการส่งข้อความ — ปัญหาตัวตน

OpenClaw เชื่อมต่อกับแพลตฟอร์มมากกว่า 20 แพลตฟอร์มพร้อมกัน จากมุมมองภายใน Agent มันรู้ว่าตัวเองเป็นสิ่งเดียวกัน มีความทรงจำ การตั้งค่า และ SOUL.md ที่เป็นหนึ่งเดียว แต่จากมุมมองภายนอก คนอื่นจะรู้ได้อย่างไรว่า Agent ตัวนี้บน Telegram กับ Agent ตัวนั้นบน Discord เป็นตัวเดียวกัน? แต่ละแพลตฟอร์มมีระบบ ID ผู้ใช้ของตัวเอง แพลตฟอร์มต่างๆ ไม่เชื่อมต่อกันและไม่สามารถดูบันทึกพฤติกรรมได้ นี่คือปัญหาหลักที่ ERC-8004 พยายามแก้ไข

ชั้นที่สอง: เกตเวย์ — ปัญหาด้านความปลอดภัย

Gateway เป็นศูนย์ควบคุมสมองของ OpenClaw: กำหนดเส้นทางข้อความผู้ใช้ไปยัง Agent ที่ถูกต้อง โหลดประวัติการสนทนาและ Skills ที่ใช้ได้ของ Agent นั้น และกำหนดขอบเขตสิทธิ์ก่อนที่ Agent จะเริ่มคิด (กลไกไวต์ลิสต์: เมื่อข้อความมาถึง Gateway ระบบจะสร้างไวต์ลิสต์เครื่องมือแบบไดนามิกตามข้อมูล เช่น แหล่งที่มาของข้อความ ID ผู้ใช้ ID กลุ่ม เป็นต้น มีเพียงเครื่องมือที่อยู่ในไวต์ลิสต์เท่านั้นที่จะถูกฉีดเข้าไปในบริบทของ Agent Agent ไม่เห็นเครื่องมือที่อยู่นอกไวต์ลิสต์เลย ดังนั้นจึงไม่สามารถเรียกใช้ได้)

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

ชั้นที่สาม: ตัวแกนกลางของ Agent (ลูป ReAct) — ปัญหาความสามารถในการคาดการณ์

ตรรกะการทำงานของ Agent คือลูป ReAct (Reasoning + Acting): รับอินพุต → คิด (เรียกใช้ LLM) → ตัดสินใจดำเนินการ → เรียกใช้เครื่องมือ → รับผลลัพธ์ → คิดอีกครั้ง → วนซ้ำ การปรับปรุงทางวิศวกรรมที่ OpenClaw ทำ ได้แก่: การจัดกำหนดการข้อความความถี่สูง (4 กลยุทธ์: Steer/Collect/Followup/Interrupt) การทนต่อข้อผิดพลาดสองชั้นของ LLM (การหมุนเวียนการรับรอง + การลดระดับโมเดล) และกลไกการคิดแบบแบ่งระดับที่เลือกได้ (6 ระดับ)

แต่ LLM มีธรรมชาติแบบความน่าจะเป็น ผลลัพธ์ไม่แน่นอน Agent เป็นผู้ดำเนินการที่ไม่แน่นอน ดำเนินการที่ไม่สามารถย้อนกลับได้ในสภาพแวดล้อมที่ไม่แน่นอน

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

ตัวอย่างหนึ่งคือ Summer Yu หัวหน้าฝ่ายจัดตำแหน่งของ Meta Superintelligence Lab ขอให้ Agent "แนะนำอีเมลบางฉบับที่สามารถลบได้" แต่ Agent กลับลบอีเมลหลายร้อยฉบับโดยตรง (หลังจากหน้าต่างบริบทล้นจนเกิดการบีบอัด ข้อจำกัดสำคัญอย่าง "แนะนำ" ถูกทิ้งไป)

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

ชั้นที่สี่: ระบบความทรงจำ — ปัญหาความคงทนและความสามารถในการย้ายถิ่น

OpenClaw ใช้ความทรงจำสองประเภท: ความทรงจำการทำงานรายวัน (ไฟล์ YYYY-MM-DD.md) และความทรงจำสำคัญระยะยาว (MEMORY.md ซึ่งเป็นการขจัดความซ้ำซ้อน จัดประเภท และกลั่นกรองความชอบหลัก) ใช้โหมดผสมระหว่างการค้นหาเวกเตอร์และ BM25 ในการดึงข้อมูล

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

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

5.3 ปัญหาเชิงโครงสร้างทางเศรษฐกิจของ Agent

บริบทไม่ไหลเวียน: รากเหง้าของปัญหาทั้งหมด

• ล็อกพื้นที่: ความทรงจำและความรู้ของ Agent เก็บไว้บนเครื่องที่มันทำงานอยู่ เปลี่ยนคอมพิวเตอร์ก็หายไป
• แยกความไว้วางใจ: Agent A อ้างว่า "ผู้ใช้บอกว่าชอบ X เมื่อสัปดาห์ที่แล้ว" Agent B ไม่มีวิธีใดตรวจสอบความจริง
• ค้นพบไม่ได้: ต้องการหา Agent ที่ "เชี่ยวชาญการวิเคราะห์ DeFi"? ไม่มีกลไกการค้นพบที่เป็นมาตรฐาน
• มูลค่าไม่ได้กำหนดราคา: ความรู้เฉพาะด้านและความชอบผู้ใช้ที่ Agent สั่งสมมาชัดเจนว่ามีมูลค่าทางเศรษฐกิจ แต่ปัจจุบันไม่มีวิธีกำหนดราคาหรือซื้อขาย
• ชั่วคราวโดยค่าเริ่มต้น: บริบทอาจถูกบีบอัด สรุป หรือสูญหายเมื่อเซสชันรีเซ็ตได้ตลอดเวลา

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

ความขัดแย้งในการประสานงาน

Agent ต้องการเพียงบริบทที่เพียงพอเพื่อให้เหตุผล แต่การประสานงานข้ามองค์กรต้องการบริบทประวัติศาสตร์ทั้งหมด

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

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

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

เมื่อรวมการวิเคราะห์ข้างต้นเข้าด้วยกัน เราจะได้แนวคิดทางสถาปัตยกรรม:

ชั้นล่างคือสถานที่ที่ Agent ให้เหตุผล: ชั่วคราว ถูกผูกมัดด้วยโทเค็น OpenClaw, Claude Code, Cursor อยู่ที่นี่ ต้องการการตอบสนองที่รวดเร็ว มุ่งเน้นงานปัจจุบัน

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

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

แล้วเราสามารถเพิ่มส่วนประกอบเสริมแบบโมดูลาร์ที่สามารถปรับใช้ในแนวนอนโดยไม่ต้องขออนุญาต และเหมาะกับระบบ Agent ทั้งหมดได้หรือไม่ — มีความเป็นกลางที่น่าเชื่อถือ ความคงทน และความสามารถในการตรวจสอบได้? ส่วนประกอบนี้ให้อินเทอร์เฟซควบคุมระหว่างชั้นบนและชั้นล่าง อนุญาตให้บริบทไหลลงด้านล่างเมื่อจำเป็น และอนุญาตให้คำมั่นสัญญาไหลขึ้นด้านบน ก่อนดำเนินการ ให้แยกวิเคราะห์และฉีดกราฟย่อยบริบทที่เกี่ยวข้องจากกราฟความรู้แบบกระจายศูนย์ หลังดำเนินการ ให้ส่งการดำเนินการเป็นธุรกรรมที่ตรวจสอบได้ไปยังเชน พร้อมกับการติดตามแหล่งที่มา (provenance) และการอัปเดตชื่อเสียง สมมติฐานหลักของชั้นนี้คือการไหลเวียนของบริบทมีมูลค่า: หากผู้ใช้ Agent ส่วนใหญ่ไม่ต้องการการทำงานร่วมกันข้ามแพลตฟอร์ม (เช่น คนหนึ่งคนใช้ OpenClaw เพียงตัวเดียวจัดการทุกอย่าง) ชั้นกลางก็จะไม่มีความต้องการที่แท้จริง

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

จุดเริ่มต้นที่แท้จริงของ Crypto

ความต้องการทางเศรษฐกิจของ Agent ส่วนใหญ่สามารถแก้ไขได้ด้วยโซลูชัน Web2 ความไม่สามารถทดแทนได้ของ Crypto ในเศรษฐกิจ Agent มีอยู่เพียงในสถานการณ์เดียว: เมื่อคุณต้องการการทำงานร่วมกันได้โดยไม่ต้องขออนุญาต ข้ามองค์กร ข้ามแพลตฟอร์ม และผู้เข้าร่วมไม่มีความสัมพันธ์ความไว้วางใจที่กำหนดไว้ล่วงหน้า ตัวอย่างเช่น: Agent A (ทำงานบน OpenClaw เจ้าของคือผู้ใช้甲) ต้องการจ้าง Agent B