หากโปรโตคอล A2A ที่ Google เปิดตัวและโปรโตคอล MCP ของ Anthropic กลายเป็นมาตรฐานการสื่อสารทองสำหรับการพัฒนา web3 AI Agent จะเกิดอะไรขึ้น? ความรู้สึกโดยตรงคือ "น้ำไม่เหมาะ" ในมุมมองของฉัน สภาพแวดล้อมที่ web3 AI Agent เผชิญมีความแตกต่างอย่างชัดเจนจากระบบนิเวศ web2 ความท้าทายที่โปรโตคอลการสื่อสารหลักต้องเผชิญก็แตกต่างกันอย่างสิ้นเชิง:1）ความไม่ต่อเนื่องของความเป็นผู้ใช้แอปพลิเคชัน: A2A และ MCP สามารถแพร่หลายได้อย่างรวดเร็วในพื้นที่ web2 เนื่องจากพวกเขาให้บริการในสถานการณ์การใช้งานที่มีความเป็นผู้ใช้แอปพลิเคชันที่เพียงพอ ซึ่งโดยหลักการแล้วเป็น "เครื่องขยายคุณค่า" ไม่ใช่ผู้สร้างคุณค่า ในขณะที่ web3 AI Agent ส่วนใหญ่ยังคงอยู่ในระยะเริ่มต้นของการเผยแพร่ Agent ด้วยการคลิกเพียงครั้งเดียว ขาดสถานการณ์การใช้งานเชิงลึก (DeFAI, GameFAi เป็นต้น) ทำให้โปรโตคอลเหล่านี้ยากที่จะนำมาใช้ร่วมกันเพื่อสร้างคุณค่าได้อย่างเต็มที่.เช่น ผู้ใช้สามารถเขียนโค้ดใน Cursor โดยใช้โปรโตคอล MCP เป็นตัวเชื่อมต่อ โดยไม่ต้องออกจากสภาพแวดล้อมการทำงานปัจจุบันก็สามารถอัปเดตและเผยแพร่โค้ดไปยัง Github ได้ด้วยการคลิกเพียงครั้งเดียว โปรโตคอล MCP ทำให้เกิดประโยชน์เพิ่มเติม แต่หากผู้ใช้ทำการซื้อขายบนบล็อกเชนในสภาพแวดล้อม web3 โดยใช้กลยุทธ์ที่ปรับแต่งจากท้องถิ่น อาจจะทำให้เมื่อพยายามวิเคราะห์ข้อมูลบนบล็อกเชนจะรู้สึกสับสนและไม่สามารถหาทางออกได้.2）การขาดแคลนโครงสร้างพื้นฐาน: เพื่อให้เว็บ3 AI Agent สามารถสร้างระบบนิเวศที่สมบูรณ์ได้ จำเป็นต้องเติมเต็มโครงสร้างพื้นฐานระดับล่างที่ขาดแคลนอย่างรุนแรง รวมถึงชั้นข้อมูลแบบรวมศูนย์, ชั้น Oracle, ชั้นการดำเนินการตามเจตจำนง, ชั้นการเห็นพ้องต้องกันแบบกระจายศูนย์ เป็นต้น โดยปกติแล้วโปรโตคอล A2A ในสภาพแวดล้อมเว็บ2 Agent สามารถเรียกใช้ API มาตรฐานได้อย่างง่ายดายเพื่อให้การทำงานร่วมกัน แต่ในสภาพแวดล้อมเว็บ3 การทำธุรกรรมข้าม DEX ที่เรียบง่ายก็ต้องเผชิญกับความท้าทายอย่างมาก.ลองนึกภาพสถานการณ์ที่ผู้ใช้สั่งให้ AI Agent "ซื้อจาก Uniswap เมื่อราคาของ ETH ต่ำกว่า 1600 ดอลลาร์ และขายเมื่อราคาขึ้น" การดำเนินการที่ดูเหมือนจะง่ายนี้ Agent จำเป็นต้องแก้ปัญหาหลายอย่างที่เฉพาะเจาะจงกับ web3 เช่น การวิเคราะห์ข้อมูลบนเชนแบบเรียลไทม์ การปรับแต่งค่าธรรมเนียม Gas แบบไดนามิก การควบคุมสลิปเปอร์ และการป้องกัน MEV ในขณะที่ AI Agent ใน web2 เพียงแค่เรียกใช้ API มาตรฐานเพื่อให้สามารถทำงานร่วมกันได้ โครงสร้างพื้นฐานนั้นแตกต่างกันมากเมื่อเปรียบเทียบกับสภาพแวดล้อมของ web3.3）สร้างความต้องการที่แตกต่างของ web3 AI: หาก web3 AI Agent เพียงแค่ใช้โปรโตคอลและรูปแบบฟังก์ชันของ web2 แบบง่าย ๆ จะยากที่จะใช้ประโยชน์จากลักษณะของธุรกรรมแบบเชน โดยเฉพาะปัญหาที่ซับซ้อน เช่น เสียงรบกวนจากข้อมูล ความถูกต้องของการทำธุรกรรม ความหลากหลายของ Router เป็นต้น.ยกตัวอย่างธุรกรรมความตั้งใจในสภาพแวดล้อม web2 ผู้ใช้สั่งให้ "จองเที่ยวบินที่ถูกที่สุด" และโปรโตคอล A2A ช่วยให้ตัวแทนหลายคนทํางานร่วมกันได้อย่างง่ายดาย แต่ในสภาพแวดล้อม web3 เมื่อผู้ใช้คาดหวังว่าจะ "ข้ามห่วงโซ่ USDC ของฉันไปยัง Solana และมีส่วนร่วมในการขุดสภาพคล่องด้วยต้นทุนที่ต่ําที่สุด" พวกเขาไม่เพียง แต่ต้องเข้าใจเจตนาของผู้ใช้เท่านั้น แต่ยังต้องชั่งน้ําหนักความปลอดภัยความแห้งแล้งและการสึกหรอของต้นทุนและดําเนินการที่ซับซ้อนแบบ on-chain กล่าวอีกนัยหนึ่งหากการดําเนินการที่ดูเหมือนสะดวกทําให้ผู้ใช้มีความเสี่ยงด้านความปลอดภัยมากขึ้นประสบการณ์ที่สะดวกเช่นนี้ก็ไม่มีความหมายและความต้องการก็เป็นความต้องการหลอกเช่นกันเหนือ โดยสรุปแล้ว สิ่งที่ฉันต้องการจะสื่อคือ: มูลค่าของ A2A และ MCP นั้นไม่มีข้อสงสัย แต่ไม่สามารถคาดหวังให้พวกมันปรับตัวเข้ากับสนาม web3 AI Agent ได้โดยไม่มีการปรับเปลี่ยนใดๆ ช่องว่างในการติดตั้ง infra ที่ขาดหายไปนี้ ไม่ใช่โอกาสของ Builder เหรอ?
A2A กับโปรโตคอล MCP สู่ Web3 AI Agent ที่มี "จุดบอดตาย" สามจุด
หากโปรโตคอล A2A ที่ Google เปิดตัวและโปรโตคอล MCP ของ Anthropic กลายเป็นมาตรฐานการสื่อสารทองสำหรับการพัฒนา web3 AI Agent จะเกิดอะไรขึ้น? ความรู้สึกโดยตรงคือ "น้ำไม่เหมาะ" ในมุมมองของฉัน สภาพแวดล้อมที่ web3 AI Agent เผชิญมีความแตกต่างอย่างชัดเจนจากระบบนิเวศ web2 ความท้าทายที่โปรโตคอลการสื่อสารหลักต้องเผชิญก็แตกต่างกันอย่างสิ้นเชิง:
1）ความไม่ต่อเนื่องของความเป็นผู้ใช้แอปพลิเคชัน: A2A และ MCP สามารถแพร่หลายได้อย่างรวดเร็วในพื้นที่ web2 เนื่องจากพวกเขาให้บริการในสถานการณ์การใช้งานที่มีความเป็นผู้ใช้แอปพลิเคชันที่เพียงพอ ซึ่งโดยหลักการแล้วเป็น "เครื่องขยายคุณค่า" ไม่ใช่ผู้สร้างคุณค่า ในขณะที่ web3 AI Agent ส่วนใหญ่ยังคงอยู่ในระยะเริ่มต้นของการเผยแพร่ Agent ด้วยการคลิกเพียงครั้งเดียว ขาดสถานการณ์การใช้งานเชิงลึก (DeFAI, GameFAi เป็นต้น) ทำให้โปรโตคอลเหล่านี้ยากที่จะนำมาใช้ร่วมกันเพื่อสร้างคุณค่าได้อย่างเต็มที่.
เช่น ผู้ใช้สามารถเขียนโค้ดใน Cursor โดยใช้โปรโตคอล MCP เป็นตัวเชื่อมต่อ โดยไม่ต้องออกจากสภาพแวดล้อมการทำงานปัจจุบันก็สามารถอัปเดตและเผยแพร่โค้ดไปยัง Github ได้ด้วยการคลิกเพียงครั้งเดียว โปรโตคอล MCP ทำให้เกิดประโยชน์เพิ่มเติม แต่หากผู้ใช้ทำการซื้อขายบนบล็อกเชนในสภาพแวดล้อม web3 โดยใช้กลยุทธ์ที่ปรับแต่งจากท้องถิ่น อาจจะทำให้เมื่อพยายามวิเคราะห์ข้อมูลบนบล็อกเชนจะรู้สึกสับสนและไม่สามารถหาทางออกได้.
2）การขาดแคลนโครงสร้างพื้นฐาน: เพื่อให้เว็บ3 AI Agent สามารถสร้างระบบนิเวศที่สมบูรณ์ได้ จำเป็นต้องเติมเต็มโครงสร้างพื้นฐานระดับล่างที่ขาดแคลนอย่างรุนแรง รวมถึงชั้นข้อมูลแบบรวมศูนย์, ชั้น Oracle, ชั้นการดำเนินการตามเจตจำนง, ชั้นการเห็นพ้องต้องกันแบบกระจายศูนย์ เป็นต้น โดยปกติแล้วโปรโตคอล A2A ในสภาพแวดล้อมเว็บ2 Agent สามารถเรียกใช้ API มาตรฐานได้อย่างง่ายดายเพื่อให้การทำงานร่วมกัน แต่ในสภาพแวดล้อมเว็บ3 การทำธุรกรรมข้าม DEX ที่เรียบง่ายก็ต้องเผชิญกับความท้าทายอย่างมาก.
ลองนึกภาพสถานการณ์ที่ผู้ใช้สั่งให้ AI Agent "ซื้อจาก Uniswap เมื่อราคาของ ETH ต่ำกว่า 1600 ดอลลาร์ และขายเมื่อราคาขึ้น" การดำเนินการที่ดูเหมือนจะง่ายนี้ Agent จำเป็นต้องแก้ปัญหาหลายอย่างที่เฉพาะเจาะจงกับ web3 เช่น การวิเคราะห์ข้อมูลบนเชนแบบเรียลไทม์ การปรับแต่งค่าธรรมเนียม Gas แบบไดนามิก การควบคุมสลิปเปอร์ และการป้องกัน MEV ในขณะที่ AI Agent ใน web2 เพียงแค่เรียกใช้ API มาตรฐานเพื่อให้สามารถทำงานร่วมกันได้ โครงสร้างพื้นฐานนั้นแตกต่างกันมากเมื่อเปรียบเทียบกับสภาพแวดล้อมของ web3.
3）สร้างความต้องการที่แตกต่างของ web3 AI: หาก web3 AI Agent เพียงแค่ใช้โปรโตคอลและรูปแบบฟังก์ชันของ web2 แบบง่าย ๆ จะยากที่จะใช้ประโยชน์จากลักษณะของธุรกรรมแบบเชน โดยเฉพาะปัญหาที่ซับซ้อน เช่น เสียงรบกวนจากข้อมูล ความถูกต้องของการทำธุรกรรม ความหลากหลายของ Router เป็นต้น.
ยกตัวอย่างธุรกรรมความตั้งใจในสภาพแวดล้อม web2 ผู้ใช้สั่งให้ "จองเที่ยวบินที่ถูกที่สุด" และโปรโตคอล A2A ช่วยให้ตัวแทนหลายคนทํางานร่วมกันได้อย่างง่ายดาย แต่ในสภาพแวดล้อม web3 เมื่อผู้ใช้คาดหวังว่าจะ "ข้ามห่วงโซ่ USDC ของฉันไปยัง Solana และมีส่วนร่วมในการขุดสภาพคล่องด้วยต้นทุนที่ต่ําที่สุด" พวกเขาไม่เพียง แต่ต้องเข้าใจเจตนาของผู้ใช้เท่านั้น แต่ยังต้องชั่งน้ําหนักความปลอดภัยความแห้งแล้งและการสึกหรอของต้นทุนและดําเนินการที่ซับซ้อนแบบ on-chain กล่าวอีกนัยหนึ่งหากการดําเนินการที่ดูเหมือนสะดวกทําให้ผู้ใช้มีความเสี่ยงด้านความปลอดภัยมากขึ้นประสบการณ์ที่สะดวกเช่นนี้ก็ไม่มีความหมายและความต้องการก็เป็นความต้องการหลอกเช่นกัน
เหนือ
โดยสรุปแล้ว สิ่งที่ฉันต้องการจะสื่อคือ: มูลค่าของ A2A และ MCP นั้นไม่มีข้อสงสัย แต่ไม่สามารถคาดหวังให้พวกมันปรับตัวเข้ากับสนาม web3 AI Agent ได้โดยไม่มีการปรับเปลี่ยนใดๆ ช่องว่างในการติดตั้ง infra ที่ขาดหายไปนี้ ไม่ใช่โอกาสของ Builder เหรอ?