การที่ AI Agent ลดลงอย่างต่อเนื่องนั้นเป็นผลมาจากโปรโตคอล MCP ซึ่งได้รับความนิยมเมื่อเร็ว ๆ นี้หรือไม่?
ผู้แต่งต้นฉบับ: Haotian (X: @tme l0 211 )
เพื่อนบางคนบอกว่าการที่เป้าหมาย Web3 AI Agent ลดลงอย่างต่อเนื่อง เช่น #ai16z และ $arc เป็นผลมาจากโปรโตคอล MCP ซึ่งได้รับความนิยมเมื่อเร็ว ๆ นี้หรือไม่ ตอนที่ได้ยินครั้งแรก ฉันรู้สึกสับสนเล็กน้อย มันสำคัญอะไร? แต่หลังจากคิดดูอย่างรอบคอบแล้ว ฉันพบว่ามีตรรกะบางอย่างจริงๆ: ตรรกะการประเมินมูลค่าและกำหนดราคาของ Web3 AI Agent ที่มีอยู่ได้รับการเปลี่ยนแปลง และทิศทางการเล่าเรื่องและเส้นทางการลงจอดของผลิตภัณฑ์จำเป็นต้องได้รับการปรับเปลี่ยนอย่างเร่งด่วน! นี่คือความคิดเห็นส่วนตัวของฉัน:
1) MCP (Model Context Protocol) เป็น โปรโตคอลมาตรฐานโอเพ่นซอร์สที่ออกแบบมาเพื่อให้ LLM/ตัวแทน AI ต่างๆ สามารถเชื่อมต่อกับแหล่งข้อมูลและเครื่องมือต่างๆ ได้อย่างราบรื่น เทียบเท่า กับอินเทอร์เฟซ USB แบบ "สากล" แบบ plug-and-play ซึ่งมาแทนที่วิธีการจัดแพคเกจ "เฉพาะ" แบบครบวงจรแบบเดิม
พูดอย่างง่ายๆ ก็คือมีเกาะข้อมูลที่ชัดเจนระหว่างแอปพลิเคชัน AI เพื่อให้บรรลุการทำงานร่วมกันระหว่างตัวแทน/LLM พวกเขาจำเป็นต้องพัฒนาอินเทอร์เฟซ API ที่สอดคล้องกัน ไม่เพียงแต่ขั้นตอนการทำงานจะซับซ้อนเท่านั้น แต่ยังขาดฟังก์ชันการโต้ตอบสองทาง และโดยปกติแล้วจะมีข้อจำกัดในการเข้าถึงโมเดลและการอนุญาตที่ค่อนข้างจำกัด
การเกิดขึ้นของ MCP มอบกรอบงานรวมศูนย์ที่ช่วยให้แอปพลิเคชัน AI หลุดพ้นจากสถานะเกาะข้อมูลในอดีต และตระหนักถึงความเป็นไปได้ของการเข้าถึงข้อมูลและเครื่องมือภายนอกแบบ "ไดนามิก" ซึ่งสามารถลดความซับซ้อนในการพัฒนาและประสิทธิภาพการบูรณาการได้อย่างมาก โดยเฉพาะอย่างยิ่งในแง่ของการดำเนินการงานอัตโนมัติ การสอบถามข้อมูลแบบเรียลไทม์ และการทำงานร่วมกันข้ามแพลตฟอร์ม
ณ จุดนี้ หลายๆ คนคิดทันทีว่า ถ้าเราใช้ Manus ซึ่งเป็นนวัตกรรมการทำงานร่วมกันแบบหลายเอเจนต์ เพื่อผสานกรอบงานโอเพ่นซอร์ส MCP ที่สามารถส่งเสริมการทำงานร่วมกันแบบหลายเอเจนต์ได้ มันจะอยู่ยงคงกระพันหรือไม่
ถูกต้องแล้ว Manus + MCP คือกุญแจสำคัญต่อผลกระทบที่ web3 AI Agent ประสบมาในครั้งนี้
2) อย่างไรก็ตาม สิ่งที่น่าทึ่งคือทั้ง Manus และ MCP เป็นเฟรมเวิร์กและมาตรฐานโปรโตคอลสำหรับ LLM/Agent แบบ web2 และทั้งคู่สามารถแก้ปัญหาการโต้ตอบและการทำงานร่วมกันของข้อมูลระหว่างเซิร์ฟเวอร์ส่วนกลางได้ การอนุญาตและการควบคุมการเข้าถึงยังขึ้นอยู่กับการเปิด "ใช้งาน" ของโหนดเซิร์ฟเวอร์แต่ละโหนด อีกด้วย กล่าวอีกนัยหนึ่ง เป็นเพียงแอตทริบิวต์ของเครื่องมือโอเพ่นซอร์สเท่านั้น
หากพูดตามตรรกะแล้ว มันขัดกับแนวคิดหลักของ web3 AI Agent อย่างสิ้นเชิง เช่น "เซิร์ฟเวอร์แบบกระจาย การทำงานร่วมกันแบบกระจาย แรงจูงใจแบบกระจาย" ฯลฯ ปืนใหญ่แบบรวมศูนย์ของอิตาลีจะระเบิดบังเกอร์แบบกระจายศูนย์ได้อย่างไร
เหตุผลก็คือเฟสแรกของ Web3 AI Agent นั้น "เน้นไปที่ Web2" มากเกินไป ในทางกลับกัน ทีมงานจำนวนมากมีพื้นฐานมาจาก Web2 และขาดความเข้าใจอย่างถ่องแท้ถึงความต้องการพื้นฐานของ Web3 Native ตัวอย่างเช่น เฟรมเวิร์ก ElizaOS เดิมทีเป็นเฟรมเวิร์กแบบแพ็คเกจที่ช่วยให้นักพัฒนาปรับใช้แอปพลิเคชัน AI Agent ได้อย่างรวดเร็ว โดยเฟรมเวิร์กนี้ผสานรวมแพลตฟอร์มต่างๆ เช่น Twitter และ Discord และ "อินเทอร์เฟซ API" บางส่วน เช่น OpenAI, Claude และ DeepSeek และรวมเฟรมเวิร์กทั่วไปของ Memory และ Charter บางส่วนไว้อย่างเหมาะสมเพื่อช่วยให้นักพัฒนาพัฒนาและนำแอปพลิเคชัน AI Agent ไปใช้ได้อย่างรวดเร็ว แต่หากจะให้เจาะจงมากขึ้น ความแตกต่างระหว่างกรอบการทำงานบริการนี้กับเครื่องมือโอเพ่นซอร์สของ web2 คืออะไร? มีข้อได้เปรียบที่แตกต่างกันอย่างไรบ้าง?
เอ่อ ข้อดีคือมีวิธีสร้างแรงจูงใจแบบ Tokenomics ใช่ไหม? จากนั้นใช้กรอบงานที่สามารถถูกแทนที่โดย web2 ได้อย่างสมบูรณ์เพื่อกระตุ้นให้กลุ่มตัวแทน AI ที่มีอยู่ออกเหรียญใหม่หรือไม่ น่ากลัว. - จากตรรกะนี้ คุณจะเข้าใจคร่าวๆ ว่าเหตุใด Manus + MCP จึงสามารถส่งผลกระทบต่อ Web3 AI Agent ได้
เนื่องจากเฟรมเวิร์กและบริการ Web3 AI Agent จำนวนหนึ่งสามารถแก้ปัญหาการพัฒนาอย่างรวดเร็วและความต้องการใช้งานที่คล้ายกับ Web2 AI Agent ได้เท่านั้น แต่ไม่สามารถตามทันความเร็วในการสร้างสรรค์นวัตกรรมของ Web2 ได้ในแง่ของบริการทางเทคนิค มาตรฐาน และข้อได้เปรียบที่แตกต่างกัน ตลาด/ทุนจึงได้ประเมินและกำหนดราคา Web3 AI Agent ชุดก่อนหน้าใหม่
3) เมื่อกล่าวเช่นนั้น ก็ต้องพบหัวใจสำคัญของปัญหาแล้ว แต่เราจะทำลายทางตันได้อย่างไร? มีทางเดียวเท่านั้น: มุ่งเน้นไปที่โซลูชันเนทีฟของ Web3 เนื่องจากการทำงานและสถาปัตยกรรมแรงจูงใจของระบบแบบกระจายคือข้อได้เปรียบที่แตกต่างโดยแท้จริงของ Web3
หากนำพลังการประมวลผลแบบคลาวด์แบบกระจาย ข้อมูล อัลกอริทึม และแพลตฟอร์มบริการอื่นๆ มาเป็นตัวอย่าง พลังการประมวลผลและข้อมูลประเภทนี้ที่รวมกับทรัพยากรที่ไม่ได้ใช้งานอาจไม่สามารถตอบสนองความต้องการของนวัตกรรมทางวิศวกรรมได้ในระยะสั้น อย่างไรก็ตาม เมื่อมี LLM ด้าน AI จำนวนมากแข่งขันกันเพื่อพัฒนาประสิทธิภาพการประมวลผลแบบรวมศูนย์ โมเดลบริการที่มี "ทรัพยากรที่ไม่ได้ใช้งาน ต้นทุนต่ำ" เป็นลูกเล่นย่อมจะถูกนักพัฒนาเว็บทูและทีม VC ดูถูกดูแคลนโดยธรรมชาติ
อย่างไรก็ตาม เมื่อตัวแทน AI ของ web2 ผ่านขั้นตอนการแข่งขันด้านนวัตกรรมประสิทธิภาพแล้ว ก็จะเดินหน้าไปในทิศทางต่างๆ เช่น การขยายสถานการณ์การใช้งานตามแนวตั้งและการเพิ่มประสิทธิภาพของโมเดลการปรับแต่งแบบแบ่งส่วน เมื่อนั้นเท่านั้นที่ข้อดีของบริการทรัพยากร AI ของ web3 จะถูกเปิดเผยอย่างแท้จริง
ในความเป็นจริง เมื่อ AI web2 ซึ่งไต่อันดับขึ้นสู่ตำแหน่งยักษ์ใหญ่ด้วยการผูกขาดทรัพยากร ไปถึงขั้นหนึ่งแล้ว การจะถอยกลับและใช้แนวคิดในการโอบล้อมเมืองจากชนบทเพื่อฝ่าฟันสถานการณ์ที่แบ่งแยกทีละสถานการณ์นั้นคงเป็นเรื่องยาก เมื่อถึงเวลานั้น ถึงเวลาที่นักพัฒนา AI web2 ส่วนเกิน + ทรัพยากร AI web3 จะต้องทำงานร่วมกัน
ในความเป็นจริง นอกเหนือจากการปรับใช้ที่รวดเร็ว + กรอบการสื่อสารร่วมมือกันของตัวแทนหลายราย + เรื่องราวการออกโทเค็น Tokenomic ของ web2 แล้ว Web3 AI Agent ยังมีแนวทางนวัตกรรมของ web3 Native มากมายที่ควรค่าแก่การสำรวจ:
ตัวอย่างเช่น จำเป็นต้องมีกรอบการทำงานร่วมกันแบบกระจายฉันทามติ ซึ่งต้องใช้ส่วนประกอบแบบปรับตัวจำนวนมากโดยพิจารณาจากลักษณะเฉพาะของการประมวลผลนอกเครือข่าย + การจัดเก็บสถานะบนเครือข่ายของโมเดลขนาดใหญ่ LLM
1. ระบบการตรวจสอบสิทธิ์ DID แบบกระจายอำนาจ ช่วยให้ตัวแทนมีข้อมูลประจำตัวบนเชนที่สามารถตรวจสอบได้ เช่นเดียวกับที่อยู่เฉพาะตัวที่สร้างขึ้นโดยเครื่องเสมือนสำหรับสัญญาอัจฉริยะ โดยหลักแล้วเพื่อการติดตามและบันทึกสถานะที่ตามมาอย่างต่อเนื่อง
2. ระบบ Oracle แบบกระจายอำนาจ ซึ่งรับผิดชอบหลักในการได้มาซึ่งข้อมูลนอกเครือข่ายที่เชื่อถือได้และการตรวจสอบข้อมูลนอกเครือข่าย ซึ่งแตกต่างจาก Oracle รุ่นก่อนๆ ชุด Oracle ที่ปรับให้เหมาะกับ AI Agent นี้อาจจำเป็นต้องสร้างสถาปัตยกรรมแบบผสมผสานของตัวแทนหลายตัว รวมถึงเลเยอร์การรวบรวมข้อมูล เลเยอร์ฉันทามติในการตัดสินใจ และเลเยอร์ข้อเสนอแนะในการดำเนินการ เพื่อให้สามารถเข้าถึงข้อมูลบนเครือข่ายของตัวแทน การคำนวณและการตัดสินใจนอกเครือข่ายได้แบบเรียลไทม์
3. ระบบ DA ที่จัดเก็บแบบกระจายอำนาจ เนื่องจากสถานะฐานความรู้ของ AI Agent ไม่แน่นอนเมื่อทำงาน และกระบวนการให้เหตุผลก็เป็นเพียงชั่วคราว จึงจำเป็นต้องมีระบบเพื่อบันทึกไลบรารีสถานะคีย์และเส้นทางการให้เหตุผลเบื้องหลัง LLM และจัดเก็บไว้ในระบบจัดเก็บแบบกระจาย และจัดเตรียมกลไกพิสูจน์ข้อมูลที่ควบคุมต้นทุนเพื่อให้แน่ใจว่าข้อมูลจะพร้อมใช้งานระหว่างการตรวจสอบห่วงโซ่สาธารณะ
4. เลเยอร์การประมวลผลความเป็นส่วนตัว ZKP ที่มีการพิสูจน์ความรู้เป็นศูนย์ สามารถเชื่อมโยงกับโซลูชันการประมวลผลความเป็นส่วนตัว ได้แก่ TEE และ FHE เพื่อให้ได้การประมวลผลความเป็นส่วนตัวแบบเรียลไทม์ + การยืนยันหลักฐานข้อมูล ทำให้ตัวแทนสามารถมีแหล่งข้อมูลแนวตั้งที่หลากหลายยิ่งขึ้น (ทางการแพทย์ การเงิน) จากนั้นตัวแทนบริการที่เป็นมืออาชีพและปรับแต่งได้มากขึ้นจะปรากฏอยู่ด้านบน
5. ชุดโปรโตคอลการทำงานร่วมกันแบบครอสเชน ซึ่งค่อนข้างคล้ายกับกรอบงานที่กำหนดโดยโปรโตคอลโอเพ่นซอร์ส MCP ความแตกต่างคือชุดโซลูชันการทำงานร่วมกันนี้ต้องการกลไกการถ่ายทอดและกำหนดตารางเวลาการสื่อสารที่ปรับให้เข้ากับการทำงาน การส่ง และการตรวจสอบตัวแทน และสามารถทำการโอนทรัพย์สินและการซิงโครไนซ์สถานะของตัวแทนระหว่างเชนที่แตกต่างกันได้ โดยเฉพาะอย่างยิ่งสถานะที่ซับซ้อน เช่น บริบทและพรอมต์ของตัวแทน ฐานความรู้ หน่วยความจำ เป็นต้น
ในความคิดของฉัน กุญแจสำคัญในการพิชิต Web3 AI Agent ที่แท้จริงควรเป็นวิธีในการสร้าง "เวิร์กโฟลว์ที่ซับซ้อน" ของ AI Agent และ "กระแสการตรวจสอบความน่าเชื่อถือ" ของบล็อคเชนให้เข้ากันได้มากที่สุด สำหรับโซลูชั่นเพิ่มเติมเหล่านี้ เป็นไปได้ว่าโซลูชั่นเหล่านี้ได้รับการอัปเกรดและทำซ้ำจากโปรเจ็กต์การเล่าเรื่องเก่าที่มีอยู่แล้ว หรืออาจถูกสร้างขึ้นใหม่จากโปรเจ็กต์ในแทร็กการเล่าเรื่อง AI Agent ที่เพิ่งสร้างขึ้นใหม่
นี่คือทิศทางที่ web3 AI Agent ควรพยายามสร้าง และสอดคล้องกับพื้นฐานของระบบนิเวศนวัตกรรมภายใต้เรื่องราวมหภาคของ AI + Crypto หากไม่มีนวัตกรรมและการพัฒนาที่เกี่ยวข้องและการสร้างอุปสรรคการแข่งขันที่แตกต่างกัน การรบกวนใดๆ ในเส้นทาง Web2 AI ก็อาจทำให้ Web3 AI พลิกกลับด้านได้
