近期,MCP(模型上下文協議)的興起引發了web3 AI代理的持續下跌。 MCP是一個開源標準協議,旨在實現不同AI模型和代理的無縫連接,解決了以往數據孤島的問題。然而,web3 AI代理過於“web2化”,未能把握web3的本質需求,導致其與中心化的平台產生衝突。當前,雖然以分佈式資源聚合的優勢,但web3 AI仍需通過身份驗證、跨鏈互操作等技術來實現更複雜的工作流,建立差異化競爭壁壘,推動創新生態的發展。
有朋友說,諸如#ai16z,弧等web3 ai代理標的的持續陰跌是由最近爆火的mcp協議造成的?乍一聽,整個人有點懵,wtf有關係嗎?但細想之後發現,真有一定的邏輯:已有
(1)MCP(模型上下文協議)是一個旨在讓各類AILLM/Agent無縫連接到各種數據源和工具的開源標準化協議,相當於一個即插即拔USB“通用”,取代了過去要端到端,“特定”封裝方式。
簡單而言,ai應用之間都有明顯的數據孤島,代理/llm之間要實現互通有無則需要各自開發相應的調用api接口,操作流程複雜不說,還缺乏雙向交互功能,通常都有相對有限的模型訪問和權限限制。 ,通常都有相對有限的模型訪問和權限限制。
mcp的出現等於提供了一個統一的框架,讓
說到此,很多人立馬想到了
沒錯,Manus + MCP才是web3 AI代理此番遭受衝擊的關鍵。
2)但,匪夷所思的是
按理說,它和web3 ai代理追求的“ 分佈式服務器、分佈式協作、分佈式激勵”,中心化的意大利炮怎麼能炸掉去中心化的碉堡呢? ,中心化的意大利炮怎麼能炸掉去中心化的碉堡呢?
究其原因在於,第一階段的,web3 ai代理太過於“ web2化”,web2背景,對web3,web3本機的原生需求缺乏充分的理解,比如,比如,elizaos框架最初就是一個,幫助開發者快捷部署ai代理,恰恰就是集成了twitter,代理應用。但較真的話,這套服務框架和web2的開源工具有何區別呢?又有什麼差異化優勢呢?
呃,難道優勢就是有一套tokenomics 激勵方式?然後用一套web2可以完全取代的框架,ai代理?可怕。 。順著這個邏輯看,你就大概明白
由於一眾web3 AI代理框架和服務只解決了類同web2 AI代理的快捷開發和應用需求,web2的創新速度
3)說到此
以分佈式雲算力、數據、算法等服務平台為例,表面上看似這種以閒置資源為由頭聚合起來的算力和數據,短期根本無法滿足工程化實現創新的需要,但在大量ai llm正在拼中心化算力搞性能突破軍備競賽的時候
但等web2 AI代理過了拼性能創新的階段,就勢必會追求垂直應用場景拓展和細分微調模型優化等方向,那個時候才會真正顯現web3 ai資源服務的優勢。
事實上,當以資源壟斷方式爬上巨頭位置上的web2 ai到一定階段,很難再退回來用農村包圍城市的思想,逐個細分場景擊破,那個時候就是過剩
事實上,web3 AI代理除了web2+多代理協作通信框架外+tokenomic發幣敘事之外
比如,配備一套分佈式,識協作框架,llm大模型鏈下計算+鏈上狀態存儲的特性,需要諸多適配性的組件。 ,需要諸多適配性的組件。
1 、一套去中心化的做身份驗證系統,讓代理能夠擁有可驗證的鏈上身份,這像執行虛擬機為智能合約生成的唯一性地址一樣,主要為了後續狀態的持續追踪和記錄;
2 、一套去中心化的甲骨文預言機系統,主要負責鏈下數據的可信獲取和驗證,和以往oracle不同的是,這套適配
3 da系統,由於ai代理運行時的知識庫狀態存在不確定性,且推理過程也較為臨時性,llm背後的關鍵狀態庫和推理路徑記錄下來存儲於分佈式存儲系統中,並提供成本可控的數據證明機制,以確保公鏈驗證時的數據可用性;
4、一套零知識證明ZKP隱私計算層,te Tee 時、 fhe等在內的隱私計算解決方案,實現實時的隱私計算+數據證明驗證,讓,讓),繼而
5 、一套跨鏈互操作性協議,有點類似於mcp開源協議定義的框架,區別在於這套互操作性解決方案,需要有適配代理運行、傳遞、驗證的中繼和通信調度機制,能夠完成代理在不同鏈間的資產轉移和狀態同步問題,尤其是包含代理上下文和提示、知識庫、內存等複雜的狀態等等;
…………
在我看來,真正的web3 AI代理的攻克重點應該在於如何讓ai代理的“複雜工作流”和區塊鏈的“信任驗證流”,由已有的老敘事項目升級迭代而來,由已有的老敘事項目升級迭代而來,還是由新構成的
這才是web3 ai代理應該努力構建的方向,才是符合ai +crypto大宏觀敘事下的創新生態基本面。若不能有相關的創新開拓和差異化競爭壁壘建立,那麼,每一次web2 ai賽道的風吹草動
資訊來源:由0x資訊編譯自互聯網。版權歸作者所有,未經許可,不得轉載