Chainfeeds 導讀：

在我看來，真正的 Web3 AI Agent 的攻克重點應該在於如何讓 AI Agent 的複雜工作流和區塊鏈的信任驗證流如何儘可能契合。

文章來源：

https://x.com/tmel0211/status/1901500405940727922

文章作者：

Haotian

觀點：

Haotian：MCP（Model Context Protocol）是一個旨在讓各類 AI LLM/Agent 無縫連接到各種數據源和工具的開源標準化協議，相當於一個即插即拔 USB「通用」接口，取代了過去要端到端「特定」封裝方式。簡單而言，原本 AI 應用之間都有明顯的數據孤島，Agent/LLM 之間要實現互通有無則需要各自開發相應的調用 API 接口，操作流程複雜不說，還缺乏雙向交互功能，通常都有相對有限的模型訪問和權限限制。MCP 的出現等於提供了一個統一的框架，讓 AI 應用可以擺脫過去的數據孤島狀態，實現動態訪問外部的數據與工具的可能性，可以顯著降低開發複雜性和集成效率，尤其在在自動化任務執行、實時數據查詢以及跨平臺協作等方面有明顯助推作用。說到此，很多人立馬想到了，如果用多 Agent 協作創新的 Manus 集成此能促進多 Agent 協作的 MCP 開源框架，是不是就無敵了？沒錯，Manus + MCP 才是 web3 AI Agent 此番遭受衝擊的關鍵。但匪夷所思的是，無論 Manus 還是 MCP 都是面向 web2 LLM/Agent 的框架和協議標準，其解決的都是中心化服務器之間的數據交互和協作的問題，其權限和訪問控制還依賴各個服務器節點的主動開放，換句話來說，它只是一種開源工具屬性。按理說，它和 Web3 AI Agent 追求的分佈式服務器、分佈式協作、分佈式激勵等等中心思想完全背離，中心化的意大利炮怎麼能炸掉去中心化的碉堡呢？究其原因在於，第一階段的 web3 AI Agent 太過於 Web2 化了，一方面源於不少團隊都來自 Web2 背景，對 Web3 Native 的原生需求缺乏充分的理解，比如，ElizaOS 框架最初就是一個，幫助開發者快捷部署 AI Agent 應用的封裝框架，恰恰就是集成了 Twitter、Discord 等平臺和一些 OpenAI、Claude、DeepSeek 等 API 接口，適當封裝了一些 Memory、Charater 通用框架，幫助開發者快速開發落定 AI Agent 應用。但較真的話，這套服務框架和 web2 的開源工具有何區別呢？又有什麼差異化優勢呢？該如何破局呢？就一條路：專注於做 Web3 原生的解決方案，因為分佈式系統的運轉和激勵架構才是屬於 Web3 絕對差異化的優勢。以分佈式雲算力、數據、算法等服務平臺為例，表面上看似這種以閒置資源為由頭聚合起來的算力和數據，短期根本無法滿足工程化實現創新的需要，但在大量 AI LLM 正在拼集中化算力搞性能突破軍備競賽的時候，一個以閒置資源、低成本為噱頭的服務模式自然會讓 Web2 的開發者和 VC 天團不屑一顧。但等 Web2 AI Agent 過了拼性能創新的階段，就勢必會追求垂直應用場景拓展和細分微調模型優化等方向，那個時候才會真正顯現 Web3 AI 資源服務的優勢。