MCP 赛道 1.5 万字研报：AI 通用接口如何在 Web3 世界连接万物？全景式解析其发展背景、技术架构、赛道格局、风险挑战与未来潜力

Anthropic 在 2024 年末向开源生态投下了一枚重磅炸弹，即一个理论上能够连接所有应用和所有大语言模型的模型上下文协议：Model Context Protocol（简称 MCP）。MCP 作为开源生态中的当红炸子鸡，受到了 Web2 和 Web3 领域开发者的共同关注。对于 Web2 开发者来说，他们希望获得更聪明更强大的、能与环境交互的 Agent；对于 Web3 领域开发者来说，他们迫切的需要提升链上的互操作性并让 Web3 AI Agent 实现自主决策自主行动的能力。MCP 通过简单有效的架构创建了大量让人意想不到的强大的 AI 落地实际案例，在 Web2 领域我们已经看到了像 Manus、Genspark 这样受益于 MCP 协议的产品新星，在 Web3 领域也出现了一些类似的有趣新产品。而 MCP 则或是当前版本 AI 落地痛点的最优答案。

本份研报将深入探讨 AI Agent 的发展历程、MCP 协议在 Web3 的迁移、Web3 MCP 的行业现状、新的 Web3 产品机会推演，同时探讨 MCP 在 Web3 行业落地会面临的考验。

作者：Hendrix，Web3Caff Research 研究员

封面：Photo by Andrei Castanha on Unsplash

字数：全文约 15000 字

目录

• 引言
• Web2 & Web3 AI Agent 视角：从 API 到 MCP / A2A
• MCP/A2A 详解：Web3 Native 视角
  • MCP 101
  • A2A 101
• Web3 AI MCP 行业梳理与推演
  • 基础赋能类
  • 横向拓展类
  • 垂直应用类
  • 智能体间协议
• MCP 带来的 Web3 机会
• MCP 给 Web3 带来的考验
• 总结
• 要点结构图
• 参考文献

引言

人工智能（AI）的浪潮正以前所未有的力量重塑各个行业，其深度集成和广泛应用已成为不可逆转的趋势。不论是 Web2 还是 Web3 都对 MCP 寄予了巨大的期待，但 AI 从简单的对话窗口的 “全知” 发展到能处理各种问题的 “全能”，中间需要模型能力本身的提升、需要更强的规划能力，但更重要的是需要教会 AI 如何稳定使用能接触到的工具。然而，当 AI 模型，特别是大型语言模型（LLM），试图与外部世界——海量的数据源、多样化的工具集以及复杂的系统——进行交互时，一个核心的挑战浮出水面：如何建立一个标准化、安全且可信的通信桥梁？缺乏统一标准不仅导致了开发效率的低下，更在数据隐私、操作安全和结果可验证性方面带来了巨大风险。正是在这一背景下，Anthropic 提出的模型上下文协议（Model Context Protocol, MCP）应运而生。模型和外部服务商之间不必再单独开发两者间的链接。通过行业统一的接口，模型和服务商仅需要接受协议标准，就能让不同生态的应用以及不同架构的模型都直接连接，信息和智能可以不受限制的自由流动。这为 AI 的互操作性描绘了新的蓝图。

但这个协议并不是凭空出现的。Web2 AI 在探索如何让把智能从沙箱中释放出来这条路上花费了巨大的精力。从最初的传统服务 API 与聊天式 API，到模型开始利用外部能力引入服务插件与函数调用功能，到最后才发展出来我们看到的 “模型-应用” 间的 MCP 协议以及 Agent 间的通信协议。Web2 AI 在让 Agent 更强大这条路上的探索给 Web3 的后来者打下了良好的基础。因为上面提到的探索，Web3 AI Agent 从诞生那天就拥有更稳定的框架，更易用的开发工具并且有了更强大的功能。现在 MCP 的出现更是给割裂的 Web3 生态带来了巨大的机会，从基础设施到应用都可能会出现更智能更好交互的产品。为此我们将深入这个新兴领域，从技术到应用，全面透视 Web3 AI MCP 的发展之路。但在此之前，我们需要对比 MCP 出现前后 Agent 与外界交互的技术范式变化，以对 MCP 的价值有更直观的理解。

Web2 & Web3 AI Agent 视角：从 API 到 MCP / A2A
Web2 与 Web3 AI 代理视角：从 API 到 MCP / A2A

传统聊天式 API 接口（非结构化文本调用）

在早期，OpenAI 为开发者提供了通用的 “文本输入－文本输出” 接口，应用通常通过直接向大语言模型发送提示词（包含用户请求和对话上下文）来获取答案，然后由后台程序根据文本返回的生成结果，按照预先定义好的业务逻辑，选取合适的工具调用外部 API（比如数据库或者日历）。这种方式简单直观，对话式应用友好，但缺乏与工具的直接集成能力。模型自身无法直接执行外部操作或获取实时数据，开发者只能通过分析模型输出中的关键词或命令提示来触发工具调用。这在早期阶段， AI 幻觉严重且缺乏人工对齐，模型返回的答案会经常跑题或者不符合人类阅读要求，非常容易出错且难以保证输出格式一致性。其优点是实现简单、无标准限制，但缺点是稳定性差、可扩展性有限，安全性能通常和用户访问账户绑定，安全机制相对简单但缺乏更细粒度的管理，比如针对某些提示词或者某些特定交互进行授权的机制。

函数调用（Function Calling）

为了解决上面工具调用稳定性差的问题，OpenAI 在 Chat Completions API 中引入函数调用功能。函数调用让开发者通过 Function 参数预定义模型可调用的函数（即功能）以及 JSON 模版，模型在回复时可以按照自己生成结构化的调用请求（通常为 “函数名 + 参数列表”，即给特定的工具功能输入特定参数），大大提高了模型与后端逻辑交互的准确度，减少自然语言歧义导致的误调用。

这种调用的优点包括：可以接入实时数据源、降低直接调用 API 的幻觉风险、自动化程度高且输出格式相对固定，易于调整。此外由于模型只能选择调用白名单内的函数，也保证了调用范围的可控与安全。这种特性非常适用于单模型、预定义任务场景。但其缺点也明显：模型只能调用事先定义好的函数（无法动态发现新工具），且不同服务商的实现不统一，跨模型适配困难。当任务涉及多轮交互时，串联模型结果仍然需要开发者手动串接函数调用的输出。

AI 插件系统（ChatGPT Plugins）  AI 插件系统（ChatGPT 插件）

尽管函数调用已经能够让开发者使用有简单工具能力的 AI 模型，但是通常这种行为都是一次性的，当用户发出非常明确的指令后，才会调用某一个工具返回一次任务。但随着模型能力和上下文长度的提升，单个工具显然限制了 AI 的能力。

为此 OpenAI 发布 ChatGPT 插件机制，允许第三方开发者基于 OpenAPI 规范构建插件，模型可在对话中动态调用丰富的插件 API 实现高度多样化的人物能力。插件的数据结构包含 OpenAPI JSON 定义及自定义元数据（对齐数据传输格式），模型在对话中会被注入插件说明文档，借助自然语言理解决定何时调用何种插件，并以插件可以理解的调用形式执行外部操作。 插件安全依赖于平台的沙箱隔离，既能保证模型调用的灵活性，又能在一定程度上防范恶意插件带来的安全风险，但部署与审核成本较高，仅限于支持插件的模型平台。至此整个 AI 工具生态出现了松动，大量的第三方工具开始进入 AI 的能力场内，并使用自己的数据支持更垂直场景下的交互。

模型上下文协议（MCP）

尽管插件已经为我们塑造了一个相对自由的工具生态，但仍旧是一个封闭在 OpenAI 体系内的工具，有很高的审核门槛，同时插件的说明文档样式并不统一，在使用时仍旧会存在不稳定的问题。（笔者猜测这或许也是插件系统不能开源的原因，在多生态间可能存在巨大的不兼容问题）

为此，Anthropic 于 2024 年 11 月开源了 MCP 协议，通过为行业不同厂家、不同结构的大语言模型提供统一的与外部真实世界同频的接口，让所有的应用都有机会变成更大的智能系统的一部分。MCP 标准化了模型与工具之间的交互，采用客户端-服务器架构。MCP 服务器会公开一组工具接口并提供统一描述，MCP 客户端可在运行时查询可用工具并调用。其优势在于极大地简化了跨模型、跨工具的集成成本，理论上只需一次对 MCP 协议的适配，就能使用任意兼容的工具。MCP 增强了可扩展性和动态性：当新工具接入系统时，模型应用可以实时发现并使用，无需修改原有代码。这个过程不仅减少了工具对接的开发，同时在跨生态（跨模型、工具）的调用中能够尽可能降低不稳定性。

MCP 的最大优势是极大的降低了系统连接的工作量。过去如果 M 个服务要和 N 个数据源连接，一共需要进行 MxN 次接口开发。但是通过 MCP 协议，只需要进行 M+N 次连接就能构建一个完整稳定的服务。这也是 MCP 生态得到认可并快速接入大量服务的原因。

Agent-to-Agent 协议（A2A）

当模型结合工具变成强大的 Agent 后，系统间的沟通问题从 “AI VS 工具” 变成了 “AI VS AI”。为此 Google 发布开源的 Agent-to-Agent（A2A）协议，定义了智能体之间通信的格式和流程。其主要优势在于提供了一个统一的协同框架：不同厂商或平台的智能体都可以使用 A2A 互通消息、交换任务结果、协商用户体验等，而无需共享内部实现。A2A 还支持长时任务、实时反馈和多模态输入输出，使得复杂工作流的交互更加灵活。但缺点在于这是一个较新的规范，目前生态和实践尚在发展阶段。

从上面我们可以清楚的理解为什么 Web3 刮起了 MCP/A2A 的风。一方面 MCP 是一种相对稳定成熟的系统（尽管推出时间不长），但经过 AI 巨头的迭代它已经足够稳定且易用，这个时候在 Web3 的落地让我们的 Agent 少走了很多弯路，一步进入工业化生产环境，避免了大量无效开发，让链上 Agent 能够快速跟上新产品新环境的变化。另一方面 Web3 在交互侧进展一直比较缓慢，工具间的合作、互操作及生态集成要么通过 API 白名单实现，要么上链通过智能合约落地，从使用和开发成本上都不经济。MCP 及 AI 模型带来的新交互方式则有机会能给 Web3 生态带来 “寒武纪生态大爆发”，而工具和 AI 之间相互配合、进化，也会给行业带来更多惊喜。

MCP/A2A 详解：Web3 Native 视角

MCP 101

借用 MCP 官方文档 [1] 中的描述：MCP 就像为 AI 系统安装了一个 “USB-C 端口”，通过统一的通信接口让模型能够访问各种数据源和服务。从组成上来看，它采用客户端-服务器（Client-Server）架构：

• MCP 主机（MCP Host）是承载 AI 模型并对外与用户交互的门户（比如 Claude Desktop、Cursor 等），它负责管理客户端的生命周期和安全策略，例如权限、用户授权以及强制执行同意要求，是人参与 AI 任务的入口；此外，主机还负责监督每个客户端中的任务，并进一步根据需要收集不同客户端返回的结果并合并答案。简单来说，主机就像空中交通管制塔台，决定哪些客户端可以执行任务，以及连接到哪些工具上；
• MCP 客户端（MCP Client）则是嵌入在主机内的 MCP 组件，每个客户端都负责处理与其连接的特定 MCP 服务器的能力协商，并协调自身与服务器之间的消息传递。由于任务执行中会返回大量的上下文信息，客户端和服务器的一对一连接可以有效的收集和管理返回的子任务结果；
• 服务器（MCP Server）是外部的轻量级服务，负责暴露具体的数据和功能给客户端。服务器将其内部的数据源和工具注册为两大类能力：
  • 资源：一般提供只读数据，用于将上下文数据加载给模型，但是服务不能将数据源进行修改，在链上环境中可以理解为，只从链上读取数据（比如钱包余额）并返回答案；
  • 工具：提供可执行的函数接口，允许模型通过调用改变状态或与外部系统交互，在链上环境中可以理解为，用户可以执行任务向某个特定地址的钱包存入一定金额的 Token。

在传输层面，MCP 支持多种通信方式：对本地进程通常采用标准输入/输出流（Stdio）方式通信，对远程服务器则支持 HTTP+Server-Sent Events (SSE) 通信——客户端通过 HTTP POST 发送请求，服务器通过 SSE 推送响应。在去中心化的环境中，大部分服务都会是通过第二种方式传递，因为大部分的数据和服务会存储在远程的链上节点中，所以只能通过远程通信获取。所有数据交换均可加密传输，以保证交互安全可靠。

这里我们会进一步以链上的语境中探索 MCP 的工作方式。以查询钱包信息为例，假如你想要查询某一个 BNB 钱包余额，整个流程如下：

• 请求接收与预处理：用户在某个 BNB Chain 的 AI Agent 交互界面提出需求，MCP 客户端所在的主机应用（即这个 Agent）会接管该 Prompt（提示词），将其按照内部消息格式改写/增强/补全，客户端确认通信安全并触发后续流程；
• 工具与资源发现：MCP 客户端向已配置的 MCP 服务器发出请求，获取能够使用的服务器名单以及相应能力，发现 BSC 官方链上 MCP、Coinmarketcap MCP 等工具有相应功能，并获取与之交互的 Prompts 模板和资源清单。所有信息都获取后，客户端会将服务器返回的能力清单缓存到本地，并决定最终使用 BSC 链上 MCP；
• 上下文构建与发送给模型：Client 将用户原始 Prompt、必要的系统指令（System Prompt）与上述工具清单一并加入 LLM 的对话上下文，并填充 BSC MCP 服务器发来的提示词模版以达到最稳定的效果。构建完成后将上下文发送给大模型；
• 模型生成调用指令：模型生成一个符合 MCP 规范的 BSC MCP 工具调用指令，并被客户端捕获发送给 Bsc 服务器；
• 工具执行与结果回传：BSC MCP 服务器接收指令后，解析指令参数并将其转给数据库，查询某一钱包的余额；完成后将结果封装返回给客户端；
• 模型最终响应生成与输出：客户端将钱包余额作为新的对话消息追加到上下文中，再次调用 LLM，将含钱包余额的上下文传入，模型据此生成最终的结果给用户。

A2A 101

MCP 协议强大的点在于它将 Agent 与丰富的外部工具生态连接起来，让 Agent 拥有了更完整的任务完成能力，但多数时候一个 Agent 可能只擅长一个类型的任务。当面对的 Prompt 输入更抽象、任务体量更大需要拆分成多部分的时候，多 Agent 系统就需要被引入。但不同厂商和框架（如 Google ADK、LangChain、CrewAI 等）均在构建各自的智能体，缺乏统一的互操作标准，导致跨系统协作成本高昂。为了避免开发多 Agent 系统的巨大工程量，并且提供开放生态中的任务一致性，Google 的 Agent-to-Agent (A2A) 协议应运而生。A2A 和 MCP 之间的区别突显了构建代理应用程序的分层方法，其中 A2A 处理 Agent 间的对等交互，而 MCP 负责管理工具访问，两者面向不同的层级的任务不相互干涉。

A2A 协议围绕几个关键概念构建：

• 代理卡 (Agent Card): 这是一个由 A2A 服务器发布的 JSON 元数据文档，描述了其身份、能力、技能、服务终结点和身份验证要求。代理卡是 Agent 的 “数字名片”，能够让不同 Agent 之间不通过集成就能够理解彼此的能力，并在此基础上建立信任连接；
• 任务与消息类型：定义了任务（Task）的创建、查询与完成流程，可以对交付给其他 Agent 的任务进行实时状态跟踪；定义了消息（Message）系统中的参与角色（任务发出方与任务执行方），每个角色发出的消息都会分别记录，两者之间会保持通畅的上下文对话，并且允许各个模态的数据（Part）参与。任务期间生成的输出会被记录为工件（Artifact）用于下一步处理；
• 极简协议层：基于 HTTP/JSON-RPC，所有交互仅包含任务调用与状态查询，无需复杂交互或持久连接，可以有效降低集成门槛。

这里我们也模拟了一个链上的 A2A 交互场景帮助读者理解。我们设想有两个链上的 Agent：PriceMonitorAgent（负责价格监测）与 TradeExecutorAgent（负责执行交易），它们可通过 Google 发布的 A2A 实现无缝协作：前者定时获取 Chainlink 数据预言机的价格，当价格触发预设阈值时，即通过 A2A 协议将 “执行交易” 任务发送给后者；后者收到任务后，通过 Uniswap V2 Router 智能合约完成在 AMM 池中执行 TokenA ⇄ TokenB 的自动兑换，并通过 A2A 消息机制反馈交易结果。

• 能力发现：价格监测 Agent 启动时，通过读取自身服务端公开的 Agent Card，声明其 “价格监控” 能力，而后价格监测 Agent 的 A2A Client 发起请求至交易 Agent 获取其支持的接口及认证配置；
• 任务派发：当价格触发阈值后，价格监测 Agent 构造任务发送给交易 Agent 的接口，完成交易指令的派发，交易 Agent 接收请求后，创建任务实体并加入执行队列；
• 任务状态查询：价格监测 Agent 可定时向交易 Agent 发起请求，查询任务状态；当状态变更或执行过程产生中间输出时，价格监测 Agent 可以请求新增的消息片段确认任务阶段，并将这些片段累积至本地上下文；
• 任务完成与反馈：当交易 Agent 调用 Uniswap MCP 服务并广播交易后，会更新任务状态为完成。价格监测 Agent 将所有片段整合，生成类似 “交换成功：已将 XXX TokenA 兑换为 XXX TokenB，交易哈希 0xabc…” 的自然语言输出，并呈现给用户。

总结来说，MCP 和 A2A 都为去中心化的 AI 网络提供了良好的基础。MCP 能够增强 Agent 能力，让自然语言主导的任务落地到链上，A2A 能够让更多的 Agent 组合能力适应更复杂抽象的语言指令。但当 Agent 获得更大能力、更多决策权、更多自主性时，传统中心化 AI Agent 在这套协议的加持下就会变得风险极高：Agent 本身会不会被恶意输入任务（转走大额资金）、任务 MCP 服务器会不会存在恶意代码（返回错误的价格数据）、其他 Agent 会不会伪装成善良 Agent 并交互（盗取敏感数据）等等。而这些问题恰好在 Web3 行业的技术加持下能够得到解决，同时 AI 技术也会让大量资金流入的公链基础设施发生变化。由此我们可以预见，MCP/A2A 的出现，或许是 Web3 和 AI 共同的机遇。

Web3 AI MCP 行业梳理与推演

接下来我们会从 Web3 行业内已经跟进 MCP/A2A 服务的板块进行分析，构建完整的 Web3 MCP 地图。链上 AI 在过去半年内吸引了大量投资人与开发者的注意力，因此行业内出现了很多与 Agent / MCP / A2A 等热门概念相关的项目。具体区分其实主要有以下几类：

• 第一类做基础赋能，向外提供链上的能力，是所有链上 MCP 的源头。主要参与者是公链以及热门去中心化 Agent 框架，主要提供 MCP 服务器；
• 第二类做通信协议优化，当 MCP 服务器变多，通过提供可信的 MCP 服务赚取费用。主要参与者是新兴的 MCP 应用商店以及数据应用，主要负责完善 MCP 基建；
• 第三类做应用落地，这类产品通常选中一个核心场景（比如交易），优化场景下的系统 Prompt，限定使用的外部 MCP 服务器名单保证服务安全，通过强大的编排能力实现复杂任务的落地。主要参与者是新兴的深度应用，主要在 MCP 主机上进行优化；
• 第四类做智能体间协议，常见在 Agent 资产较多的平台。

基础赋能类

公链 MCP：一些积极拥抱 AI 战略的主流公链在早期就通过和社区共建的方式推出了自己的 MCP Server，尽可能多的向开发者暴露自己的公链能力，而这正是整个 Web3 MCP 生态的基石，如果没有公链官方 MCP，所有 MCP 服务都有可能被恶意第三方挟持。

• BNBChain MCP
• BNB Chain 在 2025 年 5 月 1 日 正式推出 MCP 服务，为社区提供了标准化基础设施，加速 AI+DApp 创新落地。在 BNBChain MCP 中提供的能力如下：
  • 区块链数据：获取包括块信息（如块高度、时间戳）、交易详情（如交易哈希、金额）、智能合约状态（如变量值）；
  • Token 和 NFT 数据：获取 Token 余额、NFT 元数据（如所有者、属性）；
  • 网络状态：获取当前 Gas 价格、链 ID 等；
  • 交易广播：如 broadcast_transaction，用于发送签名交易（例如转账、调用合约）；
  • 智能合约调用：执行合约函数，如在 PancakeSwap 上添加流动性或交换 Token（TermiX BSC-MCP）；
  • 资产管理：包括 Token 转账、流动性管理等操作；
  • 未来会添加 Swap 及跨链桥等功能。
• Solana MCP
• Solana 和 Send AI 合作推出了自己的 Agent 框架以及 MCP 服务，但 MCP 服务在初期给出的功能相对较少：
  • 链上数据查询： 获取 Token 信息、账户余额、交易历史、智能合约状态等；
  • NFT 信息查询： 查询特定 NFT 的所有权、元数据等；
  • 创建 token：允许 Agent 创建新的链上 Token；
  • 资产转移： 发送、接收 SOL 或其他 SPL Token；
  • NFT 操作： 铸造、转移、销毁 NFT；
  • 域名服务交互： 进行 Solana 域名的注册或管理。
• Base MCP
• Base 在 Coinbase 开发的 Agent 框架之上推出了自己的 MCP 服务器，同时为其增添了很多生态特色的应用方式：
  • 资产与账户管理：获取钱包地址、列出余额、ERC20 Token 余额及 NFT 列表等；
  • 转账与合约操作：原生 ETH/USDC 等资产转账、ERC20 转账、NFT 转移、合约部署及函数调用等；
  • DeFi 与 on-ramp：与 Morpho Vault 联动、Coinbase on-ramp 及 OpenRouter 充值等；
    DeFi 与上币：与 Morpho Vault 联动、Coinbase 上币及 OpenRouter 充值等；
  • 社交与扩展：解析 Farcaster 用户名、检查地址信誉等。

从上面我们不难看出，公链推出 MCP 通常包含以下两大类核心功能：数据查询（账户余额、交易历史、智能合约状态和 NFT 信息）、资产管理与交易（资产创造/转移、合约调用/部署等会改变链上状态的操作），但各自也会根据自己生态内的热门项目进行特定资产操作的定制。目前看来，除了质押、治理投票、合成资产、跨链操作等复杂服务，主流公链都向社区开放了自己的 MCP 服务，这极大的拓展了链上 Agent 的可工作范围。其他主流公链如以太坊虽然没有推出官方的 MCP 服务器，但是社区已经有了解决方案，所以理论上来说，公链的信息和服务已经向 Agent 全面开放。

另外一个细节是：几个公链的 MCP 文档中都提到了对 Cursor MCP 的适配，这相当于将链上的开发文档及合约标准都提供给了 Cursor 的上下文。通过理解公链及智能合约的构建，Cursor 这种强大的辅助编程工具可以快速帮助开发者在短时间内开发并部署相对简单的智能合约，这对公链吸引开发者扩大自己的应用生态有着巨大的好处。

智能体框架 MCP

当基础设施开放了足够的功能并包装成 MCP 服务器，协议另外一端的客户端仍旧缺失。开发者们尽可以使用 Web2 领域的 Agent 开发框架进行开发，但是这并不能满足 Web3 Agent 集成钱包、参与链上操作的需求。因此 Web3 领域的 AI Agent 框架也开始向集成 MCP 转变。

OpenMCP

OpenMCP 是由 HoloWorld 社区与 mcp-dao 协作发起的开源计划，目标是建设一套标准化的 MCP 实现，使 AI Agent 能够与各类区块链协议、DApp 及 Web3 服务无缝互动，其愿景是 “为每个 AI Agent 提供一个通用连接器”。

主要产品包括

• EVM Agent Kit：一组 TypeScript 工具集，封装对 EVM 链的查询、合约调用及协议交互能力；
• EVM MCP：基于 Express.js 和 MCP SDK 的服务端，供 AI 模型发起请求并获得链上数据或触发交易。

通过模块化的设计，OpenMCP 构建的 Agent 不仅可以进行链上交互，对支持 EVM 的公链都可以进行跨链操作。

OpenServ

OpenServ 是一家专注于多智能体编排的 AI 基础设施公司，提供从 Agent 开发到运行时管理的全栈解决方案，其核心产品包括 No-Code Builder、TypeScript SDK 以及开放式 API，旨在让开发者 “在任意框架、任意链上” 构建和部署智能体。平台本身既可作为 MCP 客户端，调用第三方或用户自建的 MCP 服务，也能将其工作区（Workspace）暴露为 MCP 服务端，供其他系统以统一的 JSON-RPC 规范发现并使用其工具集，通过这样的方式最大化应用 Web3 AI Agent 的能力，让其在链上及链下的应用中都能展示能力。

Heurist.ai

Heurist 成立于 2023 年，旨在打造一个去中心化的 AI 云平台，提供无服务器的 AI 即服务（AI-as-a-Service），2024 年 11 月完成了 200 万美元的种子轮融资，投资者包括 Amber Group、Contango Digital Assets、Manifold Trading 等。Heurist 的核心产品包括：

• Heurist Agent Framework：一个轻量级且多接口的 AI Agent 框架，支持通过 Telegram、Discord 等平台进行交互，便于开发者构建和部署 AI Agent；
• Heurist Mesh：一个开放的 AI Agent 网络，由多个专用的 AI Agent 组成，每个 Agent 都针对特定任务进行优化，如分析 Token 指标、扫描智能合约、处理链上数据等。

目前 Heurist 的架构同时支持多条 EVM 公链，既支持 Agent 作为 MCP Server，也支持作为 MCP Client 跨系统工作。正是这种架构能够帮助 Heurist 构建各种类型的 Agent，并使之相互配合形成开放 Agent 网络。

Deepcore

DeepCore 旨在解决 Web3 AI Agent 生态的碎片化与 “数据孤岛” 问题，构建从开发、分发到商业化的一体化平台。其愿景是 “从 AI+Chain 到 AI-as-Chain”，通过分布式架构与经济激励，实现真正去中心化的智能体网络。

主要产品包括

• DeepCore MCP Protocol：高可用的 MCP 服务端，实现对第三方 MCP 服务（如 CoinGecko、CMC）和自有接口的统一包装，支持秒级链上状态和交易数据查询；
• DeepCore MCP Store：Web3 首个类 App Store 平台，提供 1,000+ MCP 插件，包括链上数据流、AI Agent 服务，以 SSE/STDIO 两种模式对外暴露，帮助开发者 “一键接入、即刻调用”；
• DeepMatrix AI Agent Store：面向终端用户的智能体分发市场，支持托管、试用和收益分成，促进 Agent 生态繁荣。

DeepCore 基于 MCP 协议兼容所有支持 MCP 的公链，包括 EVM 兼容链：以太坊、BNB Chain、Arbitrum、Base 等；以及非 EVM 链：Solana、Aptos 等，覆盖 90% 主流第三方 on-chain 场景。

ARC

ARC（AI Rig Complex）由 AI Rig Complex 团队于 2024 年 12 月发布，定位为 Rust 语言编写的可扩展、模块化 LLM 应用开发框架。核心产品包括：

• RIG 库：用 Rust 实现的高性能 LLM 应用基础组件，支持并发、插件化加载和跨平台打包；
• Kezo：链上支付协议，为 Agent 提供原生 Token 支付、结算与激励功能，使任务执行可量化并自动扣费；
• arc-mcp-server：MCP 服务端实现，封装工具集和资源，并支持多种托管环境与 VS Code/Codeium 集成；
• Ryzome：基于 Anthropic MCP 的多链互操作层，类似 Cosmos IBC，通过 WASM 桥接实现 AI Agent 间的标准化通信与跨链调用。

目前 ARC 可以构建 MCP Server 与 Client，同时支持所有 EVM 兼容链与 Cosmos 生态，能够极大的拓展 Agent 的能力范围。

智能体框架做 MCP 拓展的意义不仅仅是简单的能力封装，它出现是必要的。尽管公链侧已经对外暴露了大部分能力，但应用本身很容易被单链生态限制。智能体框架存在的意义是将 AI 的能力带入所有接触得到的公链，更大的生态会带来更惊艳的能力，而这仅仅依靠公链 MCP 服务器是无法完成的。智能体框架为新的多链操作打开了大门。此外同时支持 MCP 客户端与服务器让市场上的 Agent 可以多样的相互组合利用，为之后的 Web3 原生 A2A 打下了良好的基础。

此外通过以上项目我们不难发现，尽管与第一波 Web3 Agent 框架出现时间相隔不长，行业仍然出现了新的框架来应对新的趋势。相反 ElizaOS 和 Swarms 这样的框架仍旧在依靠单点的 API 连接来构建服务，但新一波的框架已经带着钱包能力以及更广阔的链上能力开始构建更深度的应用，这说明 Web3 AI 已经从简单的复制 Web2 AI 能力推进到了构建独特生态的快速发展路径。

横向拓展类

应用商店

当基础设施完善后，MCP 开发难度降低，大量的 MCP 服务会涌现。不论是个人开发者在本地拓展的服务器，还是项目官方基于自有服务推出的服务器，它们都会以相对标准的方式与 Agent 进行交互。但问题出现了：如何为 Agent 提供最好最安全的服务？应用商店的出现就是通过横向收集大量 MCP，结合增值服务向 Agent 提供优质能力的业态。

DeMCP

DeMCP 专注于为 AI Agent 提供开源 MCP 服务和商业化部署平台，并允许开发者共享使用收益，架构在 SSE 代理层与标准化接口之上，向外界统一暴露各类本地 MCP 服务（即将本地 MCP 联网远程访问），无需修改原有代码即可加入生态。

核心产品包括

• SSE 代理层：将 Stdio 模式的 MCP 服务转换为 HTTP SSE 接口，支持流式交互与统一流量控制。
• TEE 安全环境：在 Intel SGX、AMD SEV 等硬件中运行代码，结合远程认证保证执行完整性与数据机密性。
• 链上注册中心：基于智能合约的去中心化服务注册与治理，记录服务 DID、版本、元数据及信誉评分。
• 支付系统：支持 USDT、USDC 等主流稳定币支付，使全球开发者可无障碍参与生态。

HighKey AI

HighKey 是由 DARPAI 团队发起、基于 DARP（Decentralized Agent and Resource Protocol）扩展 MCP（Model Context Protocol）的开源项目。
HighKey 是由 DARPAI 团队发起、基于 DARP（去中心化代理和资源协议）扩展 MCP（模型上下文协议）的开源项目。

核心产品包括

• DARP Engine：一个专门针对 MCP 服务的搜索引擎和路由工具，帮助 Agent 自动发现并调用最合适的 MCP Server；
• HighKey Web 平台：为非技术用户提供的可视化界面，支持注册、浏览、评分和调用各类 MCP 服务；
• DARP Client：插件化的 IDE/CLI 工具，允许开发者在本地以 SSE 或 STDIO 模式快速集成任意 MCP Server。

HighKey 希望能为逐渐拥挤的 MCP 构建一个完整的工具层，并对其服务路径进行优化，同时核心服务层中内置的市场模块，允许 MCP 服务提供者设定付费策略（如按调用次数或订阅制），并支持 USDC/USDT 等稳定币结算。

BlockMCP

BlockMCP.ai 是一个专注于为 AI Agent 提供去中心化 MCP（Model Context Protocol）服务的综合平台，可以自动化收集社区与官方的 MCP Server，并提供安全稳定的云端托管服务。通过自动化聚合、精确分类及排名、TEE 安全部署、Token 经济激励等一系列增值服务，构建了一个可发现、可部署、可赚取报酬的 “AI App 商店” 式生态。平台架构模块化，涵盖聚合与部署层、分类与排名层、云部署与访问层、安全审计层、AI App 生态层和社区交互层，不仅简化了 MCP Server 的接入与调用，还通过 Token 支付和收益分配机制激励开发者持续贡献高质量服务。

由于 MCP 客户端在使用工具时会审核工具名单，所以单个 Agent 能够接触的工具其实是有限的。如何提供安全、高质量的服务便落到了中间层的应用商店身上。通过审核所有的 MCP 服务器，并在使用过程中提供 TEE 支持，应用商店可以为 Agent 提供安全可靠的使用环境。此外，由于目前 MCP 还没有明确的盈利方式，聚合产生的中间层业态成为了收费并分配的重要基础设施。“安全+支付” 便是 MCP 应用商店的核心。

数据应用

尽管智能体框架能够集成多链环境，通过 MCP 提供不同环境的数据，但是在真实使用过程中仍旧会遇到数据更新不及时、可信度低、数据源不足等问题。目前来看，仍旧需要高性能的数据应用横向拓展数据资产，并打包成 MCP 服务器提供给社区。

APRO

APRO Oracle 成立于 2024 年，旨在为 LLM 和 AI Agent 提供一站式 “Oracle 3.0” 数据基础设施，将链下计算与链上验证结合，覆盖 161 条主流链的实时价格喂价和链上数据，满足 DeFi 协议、DEX、NFT 应用等场景的高频、低延迟需求。AI 预言机会通过 MCP 服务器对外向 Agent 提供数据，能够推动 Agent 取代链上 Bot 进行更复杂的操作。

Goldrush  淘金热

GoldRush 是 Covalent Network 推出的多链基础数据平台，专注于为 Web3 开发者提供结构化链上数据和工具包。2024 年底，Covalent 在其 GoldRush API 平台之上发布了 GoldRush MCP Server。它利用 Covalent 的索引网络，支持对最新区块数据的即时查询，无需等待批量更新或缓存刷新。此外 Goldrush 服务覆盖 100+ 链，即便是小众测试网或 Layer 2，也能通过单一路径参数访问，满足多链应用需求。

Unibase

Unibase 是一个面向 Web3 与 AI 深度融合的去中心化内存平台，旨在为 AI Agent 提供安全、可验证且高性能的长期上下文存储与跨 Agent 协作能力。

团队陆续发布了三大核心产品

• Membase：去中心化 AI 内存层，为 Agent 提供高吞吐（100 GB/s）和低延迟（<50 ms）的持久化知识存储，支持零知识证明（ZKP）保护隐私，实现 AI 的自我进化与多生态互操作；
• AIP（Agent Interoperability Protocol）：基于 MCP 确保不同智能体能在无需中心化服务的前提下安全互调，共享数据；
• DA（Decentralized Storage & Data Availability）：采用区块链存证＋纠删码分片的去中心化存储网络，保障 Agent 数据的持久性与可审计性，并通过链上验证与索引加速检索。

通过整套数据基础设施，Unibase 希望帮助 AI 在执行任务过程中能够自由获取其他 Agent 积累的数据，让 AI 更快的自我进化。

数据应用服务商只做两件事：第一是收集各个来源的数据，由于 AI Agent 功能越来越强大，处理能力能够将链上链下各种场景混合考虑，所以需要更丰富的数据源头，不管这些数据是否拥有 MCP 服务器，都需要统一接入，统一格式并在同一个接口数据，否则需要开发者逐个添加数据源给 MCP 主机。第二是通过各种方式保证接入的数据可信，保证数据质量的一致性。这种水平扩展的增值服务也是当前 MCP 生态内不可或缺的部分。

垂直应用类

当基础设施和水平拓展都成熟时，Agent 的能力会进入下个阶段。随着多工具 MCP 的配合能力增强，MCP 的创新从服务器端来到了主机端。通过更多的 Prompt 模版注入、更多的工作流固定，Agent 的落地能力会趋于稳定，能够对外提供高完成度的服务。Web2 AI 在类似的阶段下产生了通用 Agent Manus，Web3 受限于数据和任务种类，虽然不会出现通用产品，但或许会在垂直领域出现交互逻辑完全不同的产品。

TermiX AI

TermiX 自称 “下一代 AI Web3 操作系统”，旨在将 DeFi、CeFi、DEX、桥接等功能用自然语言打开，并让 AI Agent 真正端到端完成任务。产品通过结合 AI agent、工作流以及外部服务 MCP，能够在链上实现一个 Prompt 就控制复杂操作，用自然语言识别用户意图并进行准确的实施。他们希望通过这样的系统，最终为用户提供一站式的 DeFAI 服务。

Nexy AI

Nexy AI，定位为 “Solana 上的旗舰 DeFAI 平台”，旨在为交易员提供自动化研究、信号预警与一键执行能力。

核心产品包括

• AI 交易助手：集成图表分析、套利机会检测、社交媒体情绪监控、智能仓位管理和自动化交易执行于一体；
• MCP Server：封装链上（Solana、EVM）与链下（Gmgn、Dexscreener）数据源和执行工具，面向 LLM 客户端提供标准化接口。

Nexy AI 将复杂的 DeFi 操作简化为自然语言指令，从海量数据中提取实时洞察，并通过一键交易 API 将策略落地，能够提高交易员的响应速度与决策效率。

UnifAI

UnifAI Network 是一个专注于为 AI Agent 构建去中心化工具生态的平台，通过 MCP 框架，实现 AI 模型与多样化工具与服务的即时互通。公司推出 UniQ 助手作为每个用户的智能助手和投资顾问，通过简单的自然语言交互，用户可以稳定快速的完成链上多种操作。

纵观目前的深度应用，由于基础设施来源的数据只有链上数据及链上操作，尽管在水平扩展部分增加了高质量的外部数据源，但短时间内，Web3 AI 的落地场景还是会局限在 DeFAI 内，这其实就已经是 Web3 行业的通用 Agent 雏形。这些应用通过集成可信的 MCP 服务器，并对 MCP 主机进行修改和更新，植入社区验证过的稳定 Prompt，植入有稳定输出的 AI 工作流，能够稳定的给用户输出满意的答案。这或许就是短期内，Web3 AI 的最好呈现方式。

智能体间协议

尽管在 Web2 领域 A2A 协议刚刚被提出，还没有很好的实践案例，但 Web3 AI 在智能体间通信领域其实更早的迈出了第一步。从 Web3 Agent 诞生的第一天起就有一个明确与 Web2 Agent 不同的点：Web3 领域每一个 Agent 都挂载钱包，并在 EIP-7702（得到钱包持有者批准后在一定周期内可以自动执行转账，不用重复批准）的加持下，每一个 Agent 从诞生第一天就有能力做出有一定经济影响力的决策。这使得 Web3 Agent 及早的构建了全自动 Agent 社会的视野并针对其特点构造了相应的 “A2A 变体协议 “（其实在时间上早于 Google）。这其中最知名的或许就是 Virtuals Protocol 提出的 ACP 协议。

Virtuals Protocol  虚拟协议

Virtuals Protocol 是一个以 “Agent 社会”（Agent Society）为愿景的去中心化平台，旨在让 AI Agent 不仅能够执行任务，更能像独立企业一样开展商业活动。

其三大核心支柱包括

• GAME Framework：一套智能决策引擎，结合上下文、目标与工具集，为 Agent 提供模块化的行为生成能力；
• Agent Commerce Protocol（ACP）：一个开放标准，用于定义 Agent 间的交易、支付、协作与治理，以智能合约形式在链上实现可信交互；
• Tokenization Platform：将每个 Agent 或业务流程包装成可交易的 Agent Token 与 Business Token，实现资本形成、流动性注入与收益共享。

Google 提出的 A2A 通信协议多侧重消息交换与协商，而 ACP 则是在此基础上引入了 “经济层” 和 “可组合商业” 概念：

• 交易与结算：ACP 将每一步操作都映射为链上交易，内置原生支付通道，确保跨 Agent 支付与收益分配可审计、不可篡改；
• 资源与工具编排：ACP 不仅定义消息格式，还提供合约模板（如交易委托、收入分流、争议解决）和标准接口，使 Agent 能调用对方服务并完成价值交换；
• 集群协作模型：ACP 支持 “Agent Cluster”（集群）概念，可将多个专长 Agent 组合成一个协同单元，实现复杂业务流程的端到端自动化；而传统 A2A 仅处理点对点交互，缺乏跨事务协调能力；
• 经济激励与治理：ACP 与 Tokenization 平台深度集成，Agent 能通过质押、治理投票等机制参与协议演化，形成去中心化自治体系；A2A 通常不涉及经济层面治理。

ACP 的设计初衷和关键特性，恰好契合了 Web3 Agent 挂载钱包，有经济决策能力的特点。协议级的 Token 化激励和治理机制，让 Agent 社区可共同决定新功能路线、质量标准和经济激励规则，有利于推动生态持续健康发展。

MCP 带来的 Web3 机会

在 MCP 以及后续通用协议上的跟进或许是将 Crypto 引入更大 AI 场景的桥梁，但目前来说，Web3 还有很多基础设施并不能满足大规模落地的需求。我们从应用生态合理推演，MCP 在 Web3 的流行或许会带动以下领域的发展：

• 更高性能的公链：AI 需要支持更复杂的计算，如矩阵操作、浮点数运算和动态代码执行。现有的虚拟机在这些方面存在限制，需要更先进的虚拟机设计。例如，WebAssembly（WASM）支持近原生速度的复杂计算，适合 AI 应用。此外可以开始使用 AI 来优化公链自身性能，例如通过预测网络负载动态调整资源分配。这种自优化网络可以实时监控和调整工作负载，确保性能稳定；
• 更复杂的合约操作：要让 AI Agent 发挥创造力，公链必须提供更丰富的合约原语，超越简单的 Token 转账和事件触发，比如采用并行 EVM 研究中，在原生合约中支持元交易（meta-transactions）、程序化调度及嵌套事务，以便 AI Agent 能以更高抽象层级构建复杂策略；
• TEE：为了让链下的 MCP 服务器任务执行更加可信，需要大规模推动 TEE 在 AI 环境中的使用；
• 安全审计：MCP 涉及跨多个服务器的计算，这些服务器的可信度对于整个过程的安全性至关重要；此外由于 Cursor MCP 会越来越多地用于辅助生成智能合约代码，这会引入新的安全风险，因为人工智能模型本身可能存在偏差或生成易受攻击的代码 MCP。服务器和 AI 生成的合约都可能隐藏新型风险，必须建立专门的审计和持续监测体系；
• AI 预言机：AI Agent 需要跨域、本地化且可验证的数据来源，传统预言机需升级以匹配 AI 模型特性。新一代 AI Oracles 需要能够执行链下深度计算（如 NLP 文档解析、图像识别）后再汇总结果，使智能合约可直接调用复杂的推理任务；
• 跨链操作：跨链操作是 Web3 中一个长期挑战，现有的解决方案（如桥接、原子互换）往往效率低下或需要信任第三方。MCP 使 AI 代理能够协调跨链任务，提供更高效的跨链方式，显著降低跨链摩擦，支持 AI 代理在多链环境中无缝运行；
• 智能合成资产：AI 代理可以分析多个协议的数据，识别机会，并创建新的金融工具（如合成资产、衍生品）。这些资产可以通过智能合约在链上执行，实现自动化管理。MCP 使 AI 代理能够通过标准化接口访问协议数据和执行操作，为资产合成提供了基础。比如将 ERC-20、NFT、合成衍生品、RWA 等封装为新 Token，并在多链间流动，Agent 可自动调整头寸并触发再平衡。

MCP 给 Web3 带来的考验

上文中提到了很多 MCP 在 Web3 落地过程中的巨大潜力，但这并不意味着新技术在 Web3 行业的嫁接可以无痛落地。将 MCP 整合到 Web3 基础设施中，首先面临的是技术栈的巨大复杂性与潜在冲突：

• 预言机依赖与可信度：当 MCP 模型在链下运行，其结果需要通过预言机（Oracle）喂给智能合约来保证运行结果的正确。这引入了新的信任假设和攻击向量。预言机本身可能被操纵，或者链下计算环境的安全性无法得到充分保障。如何确保链下 MCP 组件输出的真实性、完整性和及时性，同时防止预言机成为性能瓶颈或中心化故障点，是一个核心难题；
• ZK-ML (零知识机器学习) 的局限性：虽然 ZK-ML 等前沿技术理论上可以验证链下 AI 计算的正确性而不暴露模型细节，但目前 ZK-ML 的技术成熟度、支持的模型复杂度和计算开销，距离大规模应用于 MCP 级别的模型仍有很长的路要走。其工程实现难度极高，且可能引入新的密码学安全风险；
• “智能” 合约的脆弱性：当智能合约的逻辑开始依赖 MCP 输出的复杂决策时，合约的攻击面会显著扩大。AI 模型的 “黑箱” 特性可能导致其行为难以预测，一旦 MCP 模型出现未预料到的行为或被恶意输入所欺骗，可能导致智能合约执行错误，造成灾难性的资金损失或治理混乱；
• 升级与维护的困境：AI 模型需要持续迭代和更新以保持其性能和安全性。但在区块链的不可篡改特性下，如何对已部署的 MCP 组件进行升级？是通过代理合约、硬分叉还是其他机制？这涉及到复杂的治理流程和潜在的兼容性风险。错误的升级可能导致系统分裂或功能失效。

其次，当引入新的 MCP 功能特征时，会与过去 Web3 产品设计理念产生严重冲突：

• 治理的隐性中心化：若 MCP 组件的更新、参数调整等关键决策由少数 “专家” 或开发者掌握，即便通过 DAO 投票，也可能因信息不对称导致权力集中；
• “自主” 作恶的可能性：高度智能化的 MCP 组件如果被恶意利用或出现漏洞，可能在 Web3 环境中自主执行大规模的恶意操作（如自动化盗取 Token、操纵市场、散布虚假信息），其速度和范围可能远超传统攻击。当一个由 MCP 驱动的去中心化应用出现问题导致用户损失时，责任应由谁承担？是 MCP 的开发者、协议部署方、DAO 社区、智能合约审计方，还是用户自身？在法律和监管层面，这将是一个极具争议的灰色地带；
• 透明度与可解释性缺失：Web3 强调透明，但 MCP 的核心模型往往是 “黑箱”。在需要高度问责和透明的场景（如资金管理、投票决策），依赖一个无法完全解释其行为的 AI，会引发严重的信任危机。

这些问题只是其中的一部分。当新的应用和交互方式产生时，或许 Web3 和 Web2 应用的界限会逐渐模糊，这对于 Web3 的开发者来说，需要解决的问题以及关注的焦点会越来越多。

总结

从 Web3 行业的角度来看，MCP/A2A 的落地应用为行业带来了新的活力和机遇。公链、新兴应用商店、深度应用等不同参与者纷纷跟进，构建起了完整的 Web3 MCP 地图。当智能体获得更大能力、更多决策权和自主性，其实也带来了一系列安全风险。MCP 带来了新的信息端点，会给恶意攻击者提供新的入口；自然语言提示词在通信过程中很容易由于漏洞增加一系列恶意系统提示词，导致任务方向被劫持；新的交互上下文传输很可能导致钱包密钥泄露等等。但 Web3 生态中快速成长的 TEE、零知识证明、同态加密、多方计算以及一系列的高性能共识系统都有望作为系统的补充给这些问题提供解决方案，这或许是只有 Web3 生态能够教出的答卷，同时 AI 技术或许也将成为推动公链基础设施下一次变革的主要力量。

要点结构图

参考文献

[1] MCP 官方文档

免责声明:   本报告由 Web3Caff Research 编写，所含信息仅供参考，不构成任何预测或投资建议、提议或要约，投资者请勿依赖此类信息购买、出售任何证券、加密货币或采取任何投资策略。报告中使用的术语和表达的观点旨在帮助理解行业动向，促进 Web3 包括区块链行业负责任发展，不应被解释为明确的法律观点或 Web3Caff Research 的观点。报告中的看法仅反映作者截至所述日期的个人意见，与 Web3Caff Research 立场无关，且可能随后续情况而变化。本报告中所含的信息和看法来自 Web3Caff Research 认为可靠的专有和非专有来源，并不一定涵盖所有数据，亦不保证其准确性。因此，Web3Caff Research 不对其准确性和可靠性作任何形式的担保，也不承担以任何其他方式产生的错误和遗漏的责任（包括因疏忽而对任何人产生的责任）。本报告可能含有 “前瞻性” 信息，这类信息可能包括预测和预报，本文并不构成对任何预测的担保。是否依赖本报告所载信息完全由读者自行决定。本报告仅供参考，不构成购买或出售任何证券、加密货币或采取任何投资策略的投资建议、提议或要约，并请您严格遵守所在国家或地区的相关法律法规。