AI Agent 崩盤真相：Web2 協議才是幕後黑手？

摘要： Web3 AI Agent 為何陰跌？MCP 協議帶來的估值重塑最近，有朋友提出一個有趣的觀點：諸如 #ai16z、 $arc 等 Web3 AI Agent 項目持續下跌，是...

Web3 AI Agent 為何陰跌？MCP 協議帶來的估值重塑

最近，有朋友提出一個有趣的觀點：諸如 #ai16z、 $arc 等 Web3 AI Agent 項目持續下跌，是否與近期爆紅的 MCP (Model Context Protocol) 協議有關？乍聽之下，讓人有些摸不著頭腦。但深入思考後發現，這其中確實存在一定的邏輯關聯：Web3 AI Agent 的估值定價邏輯正在發生變化，其敘事方向和產品落地路線亟需調整！本文將深入探討這一觀點。

MCP：Web2 AI 的「通用接口」，衝擊 Web3 AI Agent 的根基？

MCP 的作用：打破數據孤島，提升協作效率

MCP (Model Context Protocol) 是一個旨在讓各類 AI LLM/Agent 無縫連接到各種數據源和工具的开源標準化協議。 它可以被視為一個即插即拔的 USB「通用」接口，取代了過去需要端到端「特定」封裝的方式。

過去，AI 應用之間存在明顯的數據孤島。如果 Agent/LLM 之間想要互聯互通，就需要各自開發相應的 API 接口，不僅操作流程複雜，而且缺乏雙向交互功能，模型訪問和權限也受到限制。

MCP 的出現，提供了一個統一的框架，讓 AI 應用擺脫數據孤島狀態，實現「動態」訪問外部數據與工具的可能性。 這可以顯著降低開發複雜性和集成效率，尤其是在自動化任務執行、實時數據查詢以及跨平台協作等方面具有明顯的促進作用。

Manus + MCP：Web2 的協作框架，為何影響 Web3？

如果將 Manus (一種多 Agent 協作框架) 與 MCP 結合，是否會產生「無敵」的效果？

Manus + MCP 的組合，正是 Web3 AI Agent 遭受衝擊的關鍵原因。

Web3 AI Agent 的「Web2 化」：缺乏原生需求理解

然而，無論是 Manus 還是 MCP，它們都是面向 Web2 LLM/Agent 的框架和協議標準。它們解決的是中心化服務器之間的數據交互和協作問題，其權限和訪問控制仍然依賴於各個服務器節點的「主動」開放。換句話說，MCP 本質上只是一種開源工具。

按理來說，這與 Web3 AI Agent 所追求的「分布式服務器、分布式協作、分布式激勵」等核心思想是完全背離的。 中心化的工具，怎麼能衝擊去中心化的體系呢？

究其原因，在於第一階段的 Web3 AI Agent 過於「Web2 化」。一方面，許多團隊來自 Web2 背景，對 Web3 Native 的原生需求缺乏充分的理解。例如，ElizaOS 框架最初是一個幫助開發者快速部署 AI Agent 應用的封裝框架，它集成了 Twitter、Discord 等平台，以及 OpenAI、Claude、DeepSeek 等的 API 接口，並封裝了一些 Memory、Charater 通用框架，以幫助開發者快速開發 AI Agent 應用。但如果仔細分析，這套服務框架與 Web2 的開源工具有何區別呢？又存在什麼差異化優勢呢？

難道唯一的優勢就是 Tokenomics 激勵方式？然後用一套 Web2 可以完全取代的框架，來激勵一批更多是為了發新幣而存在的 AI Agent？ 如果按照這個邏輯思考，就能明白 Manus + MCP 為何能對 Web3 AI Agent 產生衝擊。

重新估值：Web3 AI Agent 的技術服務與創新速度不足

由於許多 Web3 AI Agent 框架和服務，僅僅解決了與 Web2 AI Agent 類似的快速開發和應用需求，但在技術服務、標準和差異化優勢上，又跟不上 Web2 的創新速度，因此，市場/資本對上一批 Web3 AI Agent 進行了重新估值和定價。

破局之道：專注 Web3 原生解決方案

分布式資源的價值：Web2 AI 難以觸及的細分市場

問題的症結已經找到，那麼該如何破局呢？ 答案只有一個：專注於 Web3 原生的解決方案，因為分布式系統的運轉和激勵架構才是 Web3 絕對的差異化優勢。

以分布式雲算力、數據、算法等服務平台為例，表面上看，這種以閒置資源為基礎聚合起來的算力和數據，短期內根本無法滿足工程化實現創新的需要。 在大量 AI LLM 正在拚集中化算力，進行性能突破的軍備競賽時，一個以「閒置資源、低成本」為噱頭的服務模式，自然會讓 Web2 的開發者和 VC 天團不屑一顧。

但等到 Web2 AI Agent 度過了拚性能創新的階段，就勢必會追求垂直應用場景拓展和細分微調模型優化等方向。 那個時候，Web3 AI 資源服務的優勢才會真正顯現。

事實上，當以資源壟斷方式爬上巨頭位置的 Web2 AI 發展到一定階段，很難再退回來用「農村包圍城市」的思想，逐個細分場景擊破。 到那時，就是過剩的 Web2 AI 開發者 + Web3 AI 資源抱團發力的時候。

Web3 AI Agent 的創新方向：構建分布式協作框架

除了 Web2 的那套快速部署 + 多 Agent 協作通信框架 + Tokenomic 發幣敘事之外，Web3 AI Agent 還有許多 Web3 Native 的創新方向值得探索：

例如，配備一套分布式共識協作框架。 考慮到 LLM 大模型鏈下計算 + 鏈上狀態存儲的特性，需要諸多適配性的組件。

• 一套去中心化的 DID 身份驗證系統

  讓 Agent 能夠擁有可驗證的鏈上身份，就像執行虛擬機為智能合約生成的唯一性地址一樣，主要為了後續狀態的持續追蹤和記錄。

• 一套去中心化的預言機系統

  主要負責鏈下數據的可信獲取和驗證。 與以往的預言機不同的是，這套適配 AI Agent 的預言機可能還需要做包括數據採集層、決策共識層、執行反饋層等多個 Agent 的組合架構，以便於 Agent 的鏈上所需數據和鏈下計算和決策能夠實時觸達。

• 一套去中心化的存儲 DA 系統

  由於 AI Agent 運行時的知識庫狀態存在不確定性，且推理過程也較為臨時性，需要一套把 LLM 背後的關鍵狀態庫和推理路徑記錄下來，存儲於分布式存儲系統中，並提供成本可控的數據證明機制，以確保公鏈驗證時的數據可用性。

• 一套零知識證明 (ZKP) 隱私計算層

  可以聯動包括 TEE 時、FHE 等在內的隱私計算解決方案，實現實時的隱私計算 + 數據證明驗證，讓 Agent 可以有更廣泛的垂直數據來源（醫療、金融），繼而 on top 之上有更多專業定制化的服務 Agent 出現。

• 一套跨鏈互操作性協議

  有點類似於 MCP 开源協議定義的框架，區別在於這套 Interoperability 解決方案，需要有適配 Agent 運行、傳遞、驗證的 relay 和通信調度機制，能夠完成 Agent 在不同鏈間的資產轉移和狀態同步問題，尤其是包含 Agent 上下文和 Prompt、知識庫、Memory 等復雜的狀態等等。

  真正的 Web3 AI Agent：信任驗證與複雜工作流的契合

在我看來，真正的 Web3 AI Agent 的攻克重點應該在於如何讓 AI Agent 的「複雜工作流」和區塊鏈的「信任驗證流」盡可能契合。 至於這些增量解決方案，是由已有的老敘事項目升級迭代而來，還是由新構成的 AI Agent 敘事賽道上的項目重新鑄就，都有可能性。

這才是 Web3 AI Agent 應該努力 Build 的方向，才是符合 AI + Crypto 大宏觀敘事下的創新生態基本面。 若不能有相關的創新開拓和差異化競爭壁壘建立，那麼，每一次 Web2 AI 賽道的風吹草動，都可能攪得 Web3 AI 天翻地覆。