近期，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資訊編譯自互聯網。版權歸作者所有，未經許可，不得轉載