34 篇博文 含有标签「Web3」

＃Web3生态系统中的MCP：全面评论

##1。MCP在Web3上下文中的定义和起源

**模型上下文协议（MCP）**是一个开放标准，它将AI助手（例如大语言模型）连接到外部数据源，工具和环境。 MCP通常被描述为“ AI的USB-C端口”，这是由于其通用的插件性质，是由Anthropic开发的，并于2024年11月下旬首次引入。它是一种解决方案，可以通过将AI模型与“数据库和APIS到开发环境”和“ APIS”和“ APIS和APIS环境”和“ APIS”和“ APIS和Bloxchains”和“ APIS和APIS”的“系统”安全地隔离而脱离隔离。

MCP最初是Anthropic的实验性侧面项目，很快就获得了吸引力。到2024年中，出现了开源参考实现，到2025年初，它已成为代理AI集成的事实上的标准**，领先的AI实验室（OpenAI，Google DeepMind，Meta AI）本地采用它。在** Web3社区**中，这种快速的吸收尤其值得注意。区块链开发人员将MCP视为将AI功能注入分散应用程序的一种方式，从而导致社区构建的MCP连接器扩散，以用于链上数据和服务。实际上，一些分析师认为，MCP可以通过使用自然语言接口来增强用户能力，以比区块链更实用的方式实现Web3的原始愿景。

总而言之，MCP不是区块链或代币**，而是AI世界中出生的开放协议，该协议在Web3生态系统中迅速接受为AI代理和分散数据源之间的桥梁。人类为标准（具有最初的GitHub规格和SDK）开源，并在其周围培养了一个开放的社区。这种社区驱动的方法为MCP集成到Web3中奠定了基础，现在它被视为针对AI支持的分散应用程序的基础基础架构。

2。技术架构和核心协议​

MCP在轻量级客户端 - 服务器架构中运行，并带有三个主要角色：

• ** MCP主机：** AI应用程序或代理本身，该应用程序安排请求。这可能是聊天机器人（Claude，ChatGpt）或需要外部数据的AI功能应用程序。主机启动交互，通过MCP询问工具或信息。
• ** MCP客户端：**主机用来与服务器通信的连接器组件。客户端维护连接，管理请求/响应消息，并可以并行处理多个服务器。例如，像光标或VS Code代理模式之类的开发人员工具可以充当MCP客户端，桥接具有各种MCP服务器的本地AI环境。
• ** MCP服务器：向AI暴露某些上下文数据或功能的服务。服务器提供工具**，资源或提示 AI可以使用的**。实际上，MCP服务器可以与数据库，云应用程序或区块链节点接口，并向AI呈现一组标准化的操作集。每个客户端服务器对通过其自己的频道进行通信，因此AI代理可以同时点击多个服务器以满足不同的需求。

核心原始图： MCP定义了一组构建AI-Tool交互的标准消息类型和原语。这三个基本原则是：

• 工具： AI可以在服务器上调用的离散操作或功能。例如，一个“搜索Documents”工具或“ ETH_CALL”工具。工具封装了诸如查询API，执行计算或调用智能合约功能之类的操作。 MCP客户端可以从服务器请求可用工具的列表，并根据需要致电。
• **资源：**数据终点可以通过服务器读取（或有时写入）的数据终点。这些可能是文件，数据库条目，区块链状态（块，交易）或任何上下文数据。 AI可以列出资源并通过标准MCP消息检索其内容（例如listreSources'和readResource'请求）。
• **提示：**结构化提示模板或服务器可以提供的指令指导AI的推理。例如，服务器可能会提供格式模板或预定义的查询提示。 AI可以请求提示模板的列表，并使用它们来保持其与该服务器的交互方式的一致性。

在引擎盖下，MCP通信通常基于JSON，并遵循类似于RPC（远程过程调用）的请求响应模式。该协议的规范定义了诸如InitializereQuest，ListTools，calltool'，'listresources等的消息''，这些消息确保任何符合MCP的客户端都可以以统一的方式与任何MCP服务器交谈。此标准化是什么使AI代理可以 *发现 *可以做什么：连接到新服务器后，它可以询问“您提供哪些工具和数据？”然后动态决定如何使用它们。

安全性和执行模型： MCP考虑了安全的，可控的交互。 AI模型本身不会执行任意代码；它将高级意图（通过客户端）发送到服务器，然后执行实际操作（例如获取数据或调用API）并返回结果。这种分离意味着敏感的动作（例如区块链交易或数据库写入）可以是沙盒子或需要明确的用户批准。例如，有诸如ping'（保持连接活力）之类的消息，甚至还有createMessagereQuest'，它允许MCP服务器要求客户端的AI生成子响应，通常通过用户确认使用。正在积极开发身份验证，访问控制和审计记录之类的功能，以确保可以在企业和分散的环境中安全地使用MCP（在路线图部分中提供更多信息）。

总而言之，MCP的体系结构依赖于标准化的消息协议（带有JSON-RPC样式调用），该消息将AI代理（主机）连接到提供工具，数据和操作的灵活服务器。这种开放的体系结构是模型 - 敏捷和**平台 - agnostic ** - 任何AI代理都可以使用MCP与任何资源进行交谈，任何开发人员都可以为数据源创建新的MCP服务器，而无需修改AI的核心代码。这种插件的可扩展性使MCP在Web3中的功能强大：可以为区块链节点，智能合约，钱包或甲壳构建服务器，并使AI代理将这些功能无缝集成到Web2 API上。

##3。MCP在Web3中的用例和应用

MCP通过启用AI驱动的应用程序来访问区块链数据并以安全，高级的方式访问区块链或链链操作，从而解锁了广泛的用例。以下是一些关键应用程序，并且有助于在Web3域中解决：

• 链上数据分析和查询： AI代理可以实时查询实时区块链状态，以提供见解或触发操作。例如，连接到以太坊节点的MCP服务器允许AI获取帐户余额，读取智能合约存储，跟踪交易或按需检索事件日志。这将聊天机器人或编码助手变成了区块链资源管理器。开发人员可以问一个AI助理问题，例如“ Uniswap池中目前的流动性是什么？”或“模拟该以太坊交易的气体成本”，AI将使用MCP工具调用RPC节点并从现场链中获取答案。这比依靠AI的培训数据或静态快照要强大得多。
• 自动化的Defi投资组合管理：通过组合数据访问和操作工具，AI代理可以管理加密货币组合或Defi位置。例如，“ AI Vault Optimizer” 可以监视用户在收益农场的位置，并根据实时市场条件自动建议或执行重新平衡策略。同样，AI可以充当 Defi Portfolio经理，在风险或费率变化时调整协议之间的分配。 MCP提供了AI的标准接口，以读取链上指标（价格，流动性，抵押比率），然后在允许的情况下调用工具以执行交易（例如移动资金或交换资产）。这可以帮助用户以难以手动执行的方式最大程度地提高收益率或管理风险24/7。
• ** AI驱动的交易用户代理：想想可以处理用户的区块链交互的个人AI助手。使用MCP，这样的代理可以与钱包和DAPP集成以通过自然语言命令执行任务。例如，用户可以说：“ AI，将0.5 ETH从我的钱包发送到爱丽丝或“将我的令牌放在最高疗法池中”。通过MCP，AI将使用安全的钱包服务器**（持有用户的私钥）来创建和签署事务，并使用区块链MCP服务器来广播。这种情况将复杂的命令行或metAmask互动变成对话体验。至关重要的是，这里使用安全的钱包MCP服务器，从而执行权限和确认，但最终结果是通过AI援助来简化链上交易。
• 开发人员助理和智能合同调试： Web3开发人员可以利用基于MCP的AI助手，这些助理可以了解区块链基础架构。例如，**链条的MCP服务器用于EVM和SOLANA ** **使AI编码副驾驶员可以深入了解开发人员的区块链环境。使用AI助手（在VS代码或IDE中）的智能合同工程师可以使AI在测试网上获取合同的当前状态，运行交易的模拟或检查日志 - 所有这些都是通过MCP调用到本地区块链节点的电话。这有助于调试和测试合同。 AI不再“盲目”编码；它实际上可以验证代码如何实时链链。该用例通过允许AI不断摄入最新的文档（通过文档MCP服务器）并直接查询区块链，减少幻觉并提出建议更准确，从而解决了一个主要的痛点。
• 交叉协调：由于MCP是统一接口，因此单个AI代理可以同时跨多个协议和服务协调 - 这在Web3互连的景观中非常强大。想象一个自治贸易代理，可以监视各种套利平台进行套利。通过MCP，一个代理可以通过连贯的界面与AAVE的贷款市场，Layerzero的跨链桥和MEV（矿工可提取值）分析服务进行交互。 AI可以在一个“思考过程”中，从以太坊（通过以太坊节点上的MCP服务器）收集流动性数据，获取价格信息或Oracle数据（通过另一台服务器），甚至调用桥接或交换操作。以前，这种多平台协调将需要复杂的自定义编码机器人，但是MCP为AI提供了一种可推广的方法，使AI可以浏览整个Web3生态系统，就好像它是一个大数据/资源池一样。这可以使晚期用例（例如跨链产量优化或自动清算保护）可以主动移动资产或抵押品的自动清算保护。
• ** AI咨询和支持机器人：另一个类别是Crypto应用程序中面向用户的顾问。例如，已集成到uniswap或化合物等平台中的 defi帮助聊天机器人可以使用MCP为用户提供实时信息。如果用户问：“对冲我的职位的最佳方法是什么？”，AI可以通过MCP获取当前费率，波动性数据和用户的投资组合详细信息，然后给出上下文感知的答案。平台正在探索** ai驱动的助手**嵌入在钱包或DAPP中的平台，可以指导用户完成复杂的交易，解释风险，甚至通过批准执行步骤序列。这些AI代理有效地坐落在多个Web3服务（DEXES，贷款池，保险协议）的顶部，使用MCP查询并根据需要命令它们，从而简化了用户体验。
• **超越Web3 - 多域工作流程：**尽管我们的焦点是Web3，但值得注意的是，MCP的用例扩展到了AI需要外部数据的任何域。它已经被用来将AI连接到Google Drive，Slack，Github，Figma等。实际上，单个AI代理可以跨越Web3和Web2： MCP的灵活性允许跨域自动化（例如，“如果我的DAO投票通过，请安排我的会议，并通过电子邮件发送结果”），将区块链动作与日常工具融合在一起。

解决的问题：总体问题MCP地址是缺乏AI与实时数据和服务交互的统一接口。在MCP之前，如果您希望AI使用新服务，则必须以临时方式手工编码该特定服务API的插件或集成。在Web3中，这特别繁琐 - 每个区块链或协议都有自己的界面，并且没有人工智能希望支持它们。 MCP通过标准化AI描述其想要的内容（自然语言映射到工具调用）以及服务如何描述其提供的内容来解决此问题。这大大减少了整合工作。例如，开发人员可以为该协议编写一个MCP服务器，而不是为每个Fefi协议编写自定义插件（本质上是用自然语言注释其功能）。然后，任何启用MCP的AI（Claude，Chatgpt还是开源型号）都可以立即使用它。这使AI 可扩展以插件方式，就像通过通用端口添加新设备的方式比安装新接口卡更容易。

总而言之，Web3中的MCP使** AI代理可以通过安全，标准化的渠道成为区块链世界的一流公民** - 查询，分析，甚至在分散系统之间进行交易。这为更自主的DAPP，更智能的用户代理以及链和链智能的无缝集成打开了大门。

4。代币学和治理模型​

与典型的Web3协议不同，** MCP没有天然令牌或加密货币。因此，没有内置的代币学 - 没有使用MCP固有的代币发行，积分或费用模型。 AI应用程序和服务器通过MCP通信，而无需涉及任何加密货币；例如，通过MCP呼叫区块链的AI可能会为区块链交易支付汽油费，但MCP本身没有增加额外的代币费用。该设计反映了MCP在AI社区中的起源：它是作为改善AI-Tool互动的技术标准而不是作为令牌化项目的技术标准。

** MCP的治理是以开源的，社区驱动的方式进行的。在将MCP作为公开标准发布后，人类表明了对协作发展的承诺。一个广泛的指导委员会和工作组成立了，以使协议的发展。值得注意的是，到2025年中，像微软和Github这样的主要利益相关者与人类同行加入了MCP指导委员会。这是在2025年Microsoft Build Build宣布的，表明行业参与者指导MCP的路线图和标准决策。委员会和维护者通过公开治理过程进行工作：通常会公开讨论更改或扩展MCP的建议（例如，通过GitHub问题和“ SEP” - 标准增强建议 - 指南 - 指南）。还有一个** MCP注册表工作组**（带有Block，Pulsemcp，Github和Anthropic公司等公司的维护者），例如多方治理。 2025年初，来自至少9个不同组织的贡献者合作建立了一个统一的MCP服务器注册表以进行发现，并证明了如何在社区成员之间分散发展，而不是由一个实体控制。

由于没有令牌，治理激励措施依靠利益相关者（AI公司，云提供商，区块链开发人员等）的共同利益来改善所有人的协议。这有点类似于W3C或IETF标准如何控制，但以更快的方式以GitHub为中心的过程。例如，Microsoft和Anthropic共同努力，为MCP（集成了Oauth和Single Sign-On之类的内容）设计了改进的授权规范，Github在官方MCP注册表服务上合作列出了可用的服务器。这些增强功能又为MCP规范做出了贡献。

值得注意的是，尽管MCP本身没有被象征化，但在MCP之上，关于经济激励措施和权力下放的前瞻性想法。 Web3中的一些研究人员和思想领导者预见了**“ MCP Networks” 的出现 - 基本上是MCP服务器的分散网络和使用类似区块链机制来发现，信任和奖励的代理。在这种情况下，人们可以想象一个令牌被用来奖励那些运行高质量MCP服务器的人（类似于矿工或节点运营商的激励方式）。智能合约或区块链可以促进声誉评级，可验证的计算和节点发现等功能，并具有令牌驾驶诚实的行为。这仍然是概念上的，但是MIT的NAMDA（稍后讨论）等项目正在尝试使用MCP的AI代理网络的基于令牌的激励机制。如果这些想法成熟，MCP可能会更直接地与链上的代酮组学相交，但是截至2025年核心MCP标准仍然是无令状的。

总之，MCP的“治理模型”是开放技术标准的：由社区和专家指导委员会协作，没有链子治理令牌。决策以技术优点和广泛的共识为指导，而不是硬币加权投票。这将MCP与许多Web3协议区分开来 - 它旨在通过开放的软件和标准来实现Web3的理想（权力下放，互操作性，用户授权），不是通过专有区块链或代币。用一个分析的话说， *“ Web3的承诺最终可以通过区块链和加密货币来实现，而是通过自然语言和AI代理人实现” *，将MCP定位为该愿景的关键推动者。就是说，随着MCP网络的增长，我们可能会看到混合模型，基于区块链的治理或激励机制增加了生态系统，这是一个密切关注的空间。

5。社区和生态系统​

MCP生态系统在短时间内爆炸性增长，涵盖了AI开发人员，开源贡献者，Web3工程师和主要科技公司。这是一项充满活力的社区努力，与主要的贡献者和合作伙伴关系**，包括：

• **人类：**作为创建者，通过开源MCP规格和几个参考服务器（用于Google Drive，Slack，Github等），人类种子为生态系统播种。 Anthropic继续领导开发（例如，Theodora Chu之类的员工担任MCP产品经理，而Anthropic的团队为规格更新和社区支持做出了巨大贡献）。 Anthropic的开放性吸引了其他人在MCP上建立，而不是将其视为单一公司工具。

• **早期采用者（Block，Apollo，Zed，Replit，Codeium，SourceGraph）：发行后的头几个月，一波早期采用者在其产品中实施了MCP。 块（以前为正方形）集成的MCP探索金融科技中的AI代理系统 - Block的CTO称赞MCP是将AI连接到现实世界应用程序的开放式桥梁。 ** Apollo （可能是Apollo GraphQl）还集成了MCP，以允许AI访问内部数据。 ** ZED（代码编辑器）， REPLAIT（Cloud IDE）， CONEIM（AI Coding Assistans）和 sourceGraph（代码搜索）**每个人都在添加MCP支持。例如，SourceGraph使用MCP，因此AI编码助手可以从存储库中检索相关代码以回答问题，并且Repliting的IDE代理可以在特定于项目的环境中提取。这些早期采用者提供了MCP的信誉和知名度。

• 大型技术认可 - Openai，Microsoft，Google：在一个显着的转弯处，否则竞争对手在MCP上保持一致的公司。 ** OpenAI的首席执行官Sam Altman在2025年3月公开宣布 Openai将在其产品中增加MCP支持（包括Chatgpt的桌面应用程序），说“人们喜欢MCP，我们很高兴能在我们的产品中增加支持”*。这意味着OpenAI的代理API和ChatGpt插件会说MCP，从而确保互操作性。几周后，** Google DeepMind的首席执行官Demis Hassabis 透露，Google即将推出的Gemini模型和工具将支持MCP，称其为“ AI Agesic ERA”的良好协议和开放标准。 ** Microsoft 不仅加入了指导委员会，而且与Anthropic合作，为MCP构建了官方的C＃SDK，以服务于企业开发人员社区。 Microsoft的GitHub单元将MCP集成到 GitHub Copilot（vs Code的“ Copilot Labs/Agents”模式），使Copilot能够将MCP服务器用于存储库搜索和运行测试用例之类的内容。此外，Microsoft宣布Windows 11将公开某些OS功能（例如文件系统访问），因为MCP服务器可以安全地与操作系统进行交互。 Openai，Microsoft，Google和Anthropic（所有人都在MCP围绕MCP集会）之间的合作是非凡的，并强调了该标准的社区竞争精神。

• ** Web3开发人员社区：许多区块链开发人员和初创公司都接受了MCP。创建了几个社区驱动的MCP服务器**，以服务区块链用例：

• ** Alchemy （领先的区块链基础架构提供商）的团队构建了 Alchemy MCP服务器**，该服务器通过MCP提供按需区块链分析工具。这可能使AI通过使用自然语言的API获得区块链统计数据（例如历史交易，地址活动）。

  • 贡献者开发了一个比特币和闪电网络MCP服务器与比特币节点和闪电支付网络进行交互，使AI代理能够读取比特币块数据，甚至通过标准工具创建闪电发票。
  • Crypto Media and Education Group 无资金创建了一个** OnChain MCP服务器**专注于Web3财务互动，可能为AI助手提供了DEFI协议（发送交易，查询偏差职位等）的接口。
  • 诸如** rolup.codes （以太坊第2层的知识库）之类的项目制作了一个 MCP服务器，用于滚动生态系统信息**，因此AI可以通过查询该服务器来回答有关汇总的技术问题。
  • ** Chainstack **，一个区块链节点提供商，为文档，EVM链数据和Solana推出了一套MCP服务器（涵盖了前面），明确将其作为“将您的AI放在web3构建器上的区块链类固醇上”。

此外，以Web3为中心的社区在MCP周围涌现。例如，** pulsemcp 和鹅**是社区倡议，称为帮助建立MCP注册表。我们还看到与AI代理框架的交叉授粉：Langchain社区集成的适配器，因此所有MCP服务器都可以用作Langchain-Power驱动代理中的工具，以及Hugging Face TGI（Text-Generation-generation-interference）的开源AI平台都在探索MCP兼容性。结果是一个丰富的生态系统，几乎每天都会宣布新的MCP服务器，从数据库到IoT设备的所有内容。

• **采用量表：可以在一定程度上量化牵引力。到2025年2月（发布后仅三个月），社区已经建造了1,000多个MCP服务器/连接器。这个数字只有增长，表明整个行业的一体化。迈克·克里格（Mike Krieger）（拟人化的首席产品官）于2025年春季指出，MCP已成为“蓬勃发展的公开标准，具有成千上万的集成和成长” **。官方的MCP注册表（于2025年9月在预览中启动）正在对公开可用的服务器进行分类，从而更容易发现工具。注册表的开放API允许任何人搜索“以太坊”或“概念”并找到相关的MCP连接器。这降低了新进入者的障碍，并进一步燃烧增长。

• **合作伙伴关系：**我们已经谈到了许多隐式合作伙伴关系（与Microsoft等人的拟人化）。重点介绍几个：

• **人类与Slack **：通过Slack合作，通过MCP将Claude与Slack的数据集成在一起（Slack拥有官方MCP服务器，使AI能够检索Slack消息或发布警报）。

  • 云提供商：Amazon（AWS）和Google Cloud已与Anthropic合作以主持Claude，并且很可能在这些环境中支持MCP（例如，AWS Bedrock可能允许MCP连接器用于企业数据）。尽管没有明确的引用，但这些云伙伴关系对于企业采用至关重要。
  • 学术合作：MIT和IBM研究项目NAMDA（下一个讨论）代表了学术界与行业之间的合作伙伴关系，以在分散的环境中推动MCP的限制。
  • ** GitHub＆vs Code **：增强开发人员体验的合作伙伴关系 - 例如，VS代码的团队积极地为MCP做出了贡献（注册表维护者之一来自VS代码团队）。
  • 许多初创企业：许多AI启动（代理启动，工作流动自动化启动）正在MCP上构建，而不是重新发明轮子。这包括新兴的Web3 AI初创公司希望提供“ AI为DAO”或自主经济代理商。

总体而言，** MCP社区的多样化和迅速扩展**。它包括核心科技公司（用于标准和基础工具），Web3专家（带来区块链知识和用例）以及独立的开发人员（他们通常为其喜欢的应用程序或协议贡献连接器）。这种精神是协作的。例如，对第三方MCP服务器的安全问题促使社区讨论和最佳实践的贡献（例如，为MCP服务器开展安全工具的Stacklok贡献者）。社区快速迭代的能力（MCP在几个月内看到了几次规范升级，添加流媒体响应和更好的auth等功能）证明了广泛的参与度。

特别是在Web3生态系统中，MCP培养了**“ AI + Web3” 项目的迷你生态系统。这不仅是使用协议；它催化了新想法，例如AI驱动的Daos，AI分析的链链治理以及跨域自动化（例如将链上事件与AI通过AI联系起来）。 Limechain的Zhivko Todorov 的存在 - 例如 Zhivko Todorov 表示“ MCP表示AI和区块链的不可避免的整合” - 表明，区块链退伍军人正在积极倡导它。 AI和区块链公司之间的合作伙伴关系（例如人类和区块之间的合作伙伴，或微软的Azure Cloud，使MCP易于与区块链服务一起部署）暗示了 AI代理和智能合约手工工作**的未来。

可以说，MCP点燃了AI开发人员社区与Web3开发人员社区的第一个真正的融合。现在，黑客马拉松和聚会以MCP曲目为特色。 As a concrete measure of ecosystem adoption: by mid-2025, OpenAI, Google, and Anthropic – collectively representing the majority of advanced AI models – all support MCP, and on the other side, leading blockchain infrastructure providers (Alchemy, Chainstack), crypto companies (Block, etc.), and decentralized projects are building MCP hooks.这个双面网络效果非常好，可以使MCP成为持久的标准。

6。路线图和发展里程碑​

MCP的开发节奏很快。在这里，我们概述了迄今为止的主要里程碑，而前方的路线图从官方来源和社区更新中收集到：

• ** 2024年末 - 初始版本：** ** 2024年11月25日**，拟人化正式宣布了MCP并开源了规格和初始SDK。除了规格外，他们发布了一些用于通用工具的MCP服务器实现（Google Drive，Slack，Github等），并在Claude AI Assistant（Claude Desktop App）中增加了支持，以连接到本地MCP服务器。这标志着MCP的1.0发布。拟人化的早期概念验证集成展示了Claude如何使用MCP读取文件或以自然语言查询SQL数据库，从而验证了概念。
• ** Q1 2025 - 快速采用和迭代：在2025年的前几个月，MCP看到了广泛的行业采用**。 ** 2025年3月**，OpenAI和其他AI提供者宣布了支持（如上所述）。此期间还看到了** Spec Evolution ：拟人更新的MCP，包括流式功能**（允许大量结果或连续数据流逐步发送）。该更新于2025年4月注明了C＃SDK新闻，表明MCP现在支持诸如张大响应或实时供稿集成之类的功能。社区还以各种语言（Python，JavaScript等）建立了参考实现，超越了人类的SDK，从而确保了多声支持。
• ** Q2 2025 - 生态系统工具和治理：在 2025年5月**，Microsoft和Github加入了努力，促使正式的治理和增强安全性。在2025年的Build 2025上，Microsoft揭幕了** Windows 11 MCP Integration 的计划，并详细介绍了MCP 中的授权流的合作。大约在同一时间，将 MCP注册表**的想法引入了可用的索引服务器（根据注册表博客，最初的头脑风暴始于2025年3月）。 **“标准曲目” **过程（SEP - 标准增强提案）是在GitHub上建立的，类似于以太坊的EIPS或Python的Peps，以有序地管理贡献。社区电话和工作组（用于安全，注册表，SDK）开始召集。
• ** 2025年中 - 功能扩展：**到2025年中，路线图优先考虑了几个关键改进：
• **异步和长期运行的任务支持：**计划允许MCP处理长期操作而不会阻止连接。例如，如果AI触发需要几分钟的云作业，则MCP协议将支持异步响应或重新连接以获取结果。
• 身份验证和细粒度的安全性：开发精细授权敏感动作的机制。这可能包括将OAuth流，API密钥和Enterprise SSO集成到MCP服务器中，以便可以安全地管理AI访问。鉴于允许AI调用强大的工具的安全风险，到2025年中期，MCP安全性的指南和最佳实践正在进行中。目的是，例如，如果AI是通过MCP访问用户的私有数据库，则应遵循安全的授权流（通过用户同意），而不仅仅是一个开放式终点。
• 验证和合规性测试：认识到对可靠性的需求，社区优先建筑物合规性测试套件和参考实施。通过确保所有MCP客户端/服务器遵守规格（通过自动测试），它们旨在防止分裂。参考服务器（可能是具有远程部署和AUTH的最佳实践的示例），也在路线图上，以及一个参考客户端应用程序，展示了使用AI的完整MCP使用情况。
  • 多模态支持：将MCP扩展到文本之外，以支持图像，音频，视频数据等模式。例如，AI可能会从MCP服务器（例如设计资产或图表）请求图像或输出图像。规格讨论包括添加对 *流和块的消息 *的支持 *以交互方式处理大型多媒体内容。关于“ MCP流”的早期工作已经在进行中（以支持实时音频供稿或持续传感器数据诸如AI的情况）。
  • 中央注册表与发现：实施中央 MCP注册表的计划在2025年中期执行了服务器发现服务。 ** 2025年9月，官方的MCP注册表在预览中启动。该注册表为公开可用的MCP服务器提供了一个的真理，允许客户端通过名称，类别或功能找到服务器。从本质上讲，它就像是AP商店（但开放）的AI工具。该设计允许公共注册表（全球索引）和私人索引（特定于企业索引），所有这些都可以通过共享API互操作。注册表还引入了一种审核机制，以通过社区审核模型来旗帜或恶意服务器，以保持质量。
• ** 2025年末及以后 - 走向分散的MCP网络：虽然还没有“官方”路线图项目，但该轨迹指向更多权力下放和Web3 Synergy **：
• 研究人员正在积极探索如何向MCP添加分散的发现，声誉和激励层。 ** MCP网络**（或“ MCP端点市场”）的概念正在孵化。这可能涉及基于智能合约的注册表（因此，没有单个服务器列表的失败点），服务器/客户端具有链子身份的声誉系统，并且具有良好行为的链接，并且可能可以为运行可靠的MCP节点的奖励**。
  • ** MIT的NAMDA **项目始于2024年，是朝这个方向朝着这个方向迈出的具体步骤。到2025年，NAMDA已在MCP的基础上构建了一个原型分布式代理框架，包括动态节点发现，跨代理簇的负载平衡以及使用区块链技术分散注册表等功能。他们甚至具有基于实验令牌的激励措施和用于多代理协作的出处跟踪。 NAMDA的里程碑表明，拥有许多具有无信任协调的机器的MCP代理网络是可行的。如果采用了NAMDA的概念，我们可能会看到MCP演变为结合其中一些想法（可能是通过可选扩展或顶部分层的单独协议）。
  • 企业硬化：在企业方面，到2025年底，我们希望MCP集成到主要的企业软件产品中（Microsoft在Windows和Azure中包含在Windows和Azure中）。该路线图包括企业友好的功能，例如 SSO集成和强大的访问控件。 MCP注册表和工具包的一般可用性可能在2025年底之前大规模部署MCP（例如，在公司网络中）。

到目前为止，回顾一些密钥的发展里程碑（清晰的时间表格式）：

• ** 2024年11月：** MCP 1.0发布（拟人化）。
• ** 2024年12月 - 2025年1月：**社区建立了第一波MCP服务器； Anthropic通过MCP支持释放Claude桌面；小规模的飞行员bake，阿波罗等。
• ** 2025年2月：** 1000+社区MCP连接器已达到；人类主办研讨会（例如，在AI峰会上，驾驶教育）。
• ** 2025年3月：** OpenAI宣布支持（ChatGpt Agents SDK）。
• ** 2025年4月：** Google DeepMind宣布支持（双子座将支持MCP）； Microsoft发布C＃SDK的预览。
• ** 2025年5月：**指导委员会扩展（Microsoft/github）；构建2025演示（Windows MCP集成）。
• ** 2025年6月：** Chainstack启动Web3 MCP服务器（EVM/SOLANA）供公众使用。
• ** 2025年7月：** MCP Spec版本更新（流，身份验证改进）;官方路线图在MCP网站上发布。
• ** 2025年9月：** MCP注册表（预览）启动； MCP可能会在更多产品（Claude的工作等）中达到一般可用性。
• ** 2025年末（预计）：**注册表v1.0 live;安全最佳实践指南发布；可能具有分散发现的初始实验（NAMDA结果）。

视觉前进是，MCP变得像HTTP或JSON一样无处不在，这是许多应用程序在引擎盖下使用的常见层。对于Web3，路线图提出了更深的融合：在其中AI代理不仅会使用Web3（区块链）作为信息的来源或水槽，而且Web3基础架构本身可能会开始将AI代理（通过MCP）作为操作的一部分（例如，DAO可能会运行MCP Compatiabil AI来管理某些任务，或者可能会通过MCP出版MCP来管理某些任务。路线图的重点是诸如可验证性和身份验证之类的事物暗示，这些内容沿线信任最小的MCP交互可能是现实 - 想象AI输出带有加密证明的AI输出，或者是AI呼叫审核目的的AI工具的链上日志。这些可能性模糊了AI和区块链网络之间的界线，而MCP是该融合的核心。

总之，MCP的发展是高度动态的。它达到了重大的早期里程碑（在发布后的一年内广泛采用和标准化），并以明确的路线图强调安全性，可扩展性和发现，继续迅速发展。实现和计划的里程碑确保MCP在扩展时将保持强大：应对长期运行的任务，安全许可以及数千个工具的绝对可发现性。这种向前的动量表明，MCP不是静态的规格，而是一个不断增长的标准，可能会纳入更多的Web3味功能（服务器的分散治理，激励对齐），因为这些功能会出现。社区有望将MCP适应新的用例（多模式AI，IoT等），同时关注核心承诺：在Web3时代，使AI 更加连接，上下文感知和用户授权 **。

7。与类似的Web3项目或协议进行比较​

MCP独特的人工智能和连接性的融合意味着并不多直接苹果到苹果对等效物，但是将其与Web3和AI交集的其他项目进行比较，或者具有类似的目标是有启发性的：

• ** SingularityNet（AGI/X）** - 分散的AI市场：SingularityNet，由Ben Goertzel博士和其他人于2017年推出，是基于区块链的AI服务市场。它允许开发人员将AI算法获利为服务和用户消费这些服务，这些服务都是由用于付款和治理的代币（AGIX）促进的。从本质上讲，SingularityNet试图通过在网络上托管AI模型的供应，任何人都可以致电AI服务以换取令牌。从根本上讲，这与MCP有所不同。 MCP不会托管或货币化AI模型；取而代之的是，它为AI（无论在何处运行）提供了一个标准接口，以访问数据/工具。可以想象使用MCP将AI连接到SingularityNet上列出的服务，但是SingularityNet本身专注于经济层（谁提供了AI服务以及如何获得付款）。另一个关键区别是：治理 - SingularityNet具有链政府（通过 SingularityNet增强建议（SNEP）和Agix代币投票）可以发展其平台。相比之下，MCP的治理是没有令牌的链和协作的。总而言之，SingularityNet和MCP都为更开放的AI生态系统而努力，但是SingularityNet大约是AI算法的标记网络，而MCP则涉及AI-Tool互操作性的协议标准。他们可以补充：例如，SingularityNet上的AI可以使用MCP获取所需的外部数据。但是SingularityNet并没有试图标准化工具使用；它使用区块链协调AI服务，而MCP使用软件标准使AI与任何服务一起使用。
• ** fetch.ai（FET）** - 基于代理的分散平台：fetch.ai是另一个将AI和区块链混合的项目。它启动了自己的风险验证区块链和框架，用于构建自主代理，以执行任务并在分散网络上进行交互。在Fetch的愿景中，数以百万计的“软件代理”（代表人员，设备或组织）可以使用FET令牌进行交易进行谈判和交换价值。 Fetch.ai提供了代理框架（UAGENT）和基础架构，用于其分类帐中的代理之间的发现和通信。例如，获取代理商可能通过与其他代理进行停车和运输，或自动管理供应链工作流来帮助优化城市中的流量。这与MCP相比如何？两者都涉及代理商的概念，但是Fetch.ai的代理商与其区块链和代币经济密切相关 - 他们生活在Fetch Network 上并使用链逻辑。 MCP代理（AI主机）是模型驱动的（如LLM），而不是与任何单个网络绑定的； MCP满足于通过Internet或在云设置中运行，而无需区块链。 Fetch.ai试图从头开始建立一个新的分散的AI经济经济体（具有自身的信任和交易的分类帐），而MCP则是 layer-agnoffient ** - 它在现有网络上（可以在HTTPS上使用，甚至可以在blockchain的顶部使用），以启用AI II互动）。有人可能会说，提取更多是关于自治经济代理和MCP关于智能工具的代理。有趣的是，这些可能会相交：fetch.ai上的自治代理可能会使用MCP与链脱链资源或其他区块链进行交互。相反，可以使用MCP来构建利用不同区块链（不仅仅是一个）的多代理系统。在实践中，MCP的采用速度更快，因为它不需要自己的网络 - 它可以与以太坊，Solana，Web2 API等一起使用。 Fetch.ai的方法更重量级，创建了一个参与者必须加入（并获取代币）的整个生态系统。总而言之， fetch.ai vs mcp **：fetch是一个平台，具有自己的令牌/区块链，适用于AI代理，重点是代理之间的互操作性和经济交流，而MCP则是协议（在任何环境中）可以用来插入工具和数据。他们的目标重叠在启用AI驱动的自动化方面，但它们可以解决堆栈的不同层，并且具有非常不同的建筑哲学（封闭的生态系统与开放标准）。
• 连锁链接和分散的Oracles ** - *将区块链连接到链链数据：*链链接不是AI项目，而是与web3协议相关的互补问题：如何将块链连接到外部数据和计算。 ChainLink是一个分散的节点（ORACLES）网络，以信任最小的方式获取，验证和传递链链数据。例如，Chainlink Oracles通过链链接功能代表智能合约为DEFI协议提供价格提要或调用外部API。相比之下，MCP将 AI模型连接到外部数据/工具（其中一些可能是区块链）。可以说连锁链接将数据带入区块链，而MCP将数据带入了AI 。有一个概念上的相似之处：两者都在原本孤立的系统之间建立桥梁。 ChainLink专注于提供链上数据的数据的可靠性，权力下放和安全性（解决单点故障的“甲骨文问题”）。 MCP专注于AI如何访问数据的灵活性和标准化（解决AI代理的“集成问题”）。他们在不同的域（智能合约与AI助手）运行，但可能会将MCP服务器与Oracles进行比较：价格数据的MCP服务器可能将同一API称为链条节点。区别在于消费者** - 在MCP的情况下，消费者是AI或面向用户的助手，而不是确定性的智能合约。同样，MCP并不能固有地提供链链接确实可以保证的信任（MCP服务器可以集中或社区运行，并且在应用程序级别管理信任）。但是，如前所述，分散MCP网络的想法可以从Oracle网络中借入 - 例如，可以查询多个MCP服务器并进行了交叉检查结果，以确保AI不会提供不良数据，类似于多个链接链接节点的汇总方式。简而言之，**链链接与MCP **：链链接为Web3中间件，用于消耗外部数据，MCP是AI中间件，用于模型消耗外部数据（其中可能包括区块链数据）。它们解决了不同领域的类似需求，甚至可以补充：使用MCP的AI可能会作为可靠的资源获取链条提供的数据供稿，相反，AI可以作为分析的来源，链条Oracle会带来链链（尽管后一种情况会引起验证性问题）。
• ** ChatGpt插件 / OpenAI功能与MCP ** - *AI工具集成方法：*虽然不是Web3项目，但需要快速比较，因为Chatgpt插件和OpenAI的功能调用功能还将AI连接到外部工具。 ChatGpt插件使用服务提供的OpenAPI规范，然后该模型可以按照规格调用这些API。局限性是它是一个封闭的生态系统（在OpenAI的服务器上运行的OpenAI批准的插件），每个插件都是孤立的集成。 Openai的较新 “代理” * SDK在概念上更接近MCP，让开发人员定义了AI可以使用的工具/功能，但最初它特定于OpenAI的生态系统。 ** langchain 类似地提供了为LLMS工具提供代码的框架。 MCP通过为此提供开放的，模型的不可能标准**而有所不同。正如一个分析所说，Langchain为工具创建了一个面向开发人员的标准（Python接口），而MCP创建了 针对模型的标准 * - AI代理可以在没有自定义代码的情况下在运行时发现并使用任何MCP定义的工具。实际上，MCP的服务器生态系统比Chatgpt插件在几个月内增长更大，更多样化。与其具有自己的插件格式的每个模型（Openai具有不同的插件），而是在MCP周围合并。 OpenAI本身表示对MCP的支持，从本质上将其功能方法与更广泛的标准保持一致。因此，将 OpenAI插件与MCP **进行比较：插件是一种策划的集中式方法，而MCP是一种分散的社区驱动方法。在Web3心态中，MCP更“开源和无许可”，而专有插件生态系统更加封闭。即使不是区块链，这也使MCP类似于Web3的精神 - 它可以启用互操作性和用户控制（您可以为数据运行自己的MCP服务器，而不是将其全部提供给一个AI提供商）。这种比较表明了为什么许多人认为MCP具有更长期的潜力：它没有锁定到一个供应商或一个模型。
• 项目NAMDA和分散代理框架： NAMDA值得一个单独的注释，因为它将MCP与Web3概念明确结合在一起。如前所述，NAMDA（网络代理模块化分布式体系结构）是MIT/IBM计划于2024年启动，以使用MCP作为通信层建立一个可扩展的，AI代理的分布式网络。它将MCP视为消息传递主链（因为MCP使用标准的JSON-RPC样消息，非常适合与代理间通信），然后使用区块链启发的技术添加了用于动态发现，容错和可验证的识别的图层。 NAMDA的代理可以在任何地方（云，边缘设备等），但是分散的注册表（有点像DHT或区块链）可以以防篡改的方式跟踪它们及其功能。他们甚至探索给代理商代币激励合作或资源共享。从本质上讲，NAMDA是一个“ MCP的Web3版本” 可能的实验。这还不是一个广泛部署的项目，而是精神上最接近的“类似协议”之一。如果我们查看NAMDA vs MCP：NAMDA使用MCP（因此不是竞争标准），而是通过以信任最小的方式进行联网和协调多个代理的协议扩展它。可以将NAMDA与加密社区所看到的 Autonolas或多代理系统（MAS）等框架进行比较，但是这些框架通常缺乏强大的AI组件或共同的协议。 NAMDA + MCP一起展示了分散的代理网络如何运作，区块链提供身份，声誉以及可能的代币激励措施**，以及MCP提供代理通信和工具使用。

总而言之，** MCP与大多数先前的Web3项目分开。诸如SingularityNet和Fetch.ai之类的项目旨在使用区块链 *分散AI计算或服务 *； MCP改为 *标准化与服务 *的AI集成 *，可以通过避免平台锁定来增强权力下放化。甲骨文网络（例如Chainlink）将数据传递求解到区块链； MCP将数据传递解决到AI（包括区块链数据）。如果Web3的核心理想是权力下放，互操作性和用户授权，则MCP正在攻击AI领域中的互操作性作品。它甚至影响了这些较旧的项目 - 例如，没有什么可以阻止SingularityNet通过MCP服务器提供其AI服务，或者使用MCP从使用MCP来与外部系统进行交谈。我们很可能会看到一种融合， *令牌驱动的AI网络将MCP用作其通用语言 *，将Web3的激励结构与MCP的灵活性结合在一起。

最后，如果我们考虑市场知觉：MCP通常被吹捧为AI，Web3希望为Internet做什么，请打破孤岛并授权用户。这已导致一些非正式地昵称MCP为“ AI的Web3”（即使不涉及区块链）。但是，重要的是要认识到MCP是协议标准，而大多数Web3项目是具有经济层次的全栈平台。相比之下，MCP通常是一种更轻巧，通用的解决方案，而区块链项目更重，专门的解决方案。根据用例，它们可以补充而不是严格竞争。随着生态系统的成熟，我们可能会将MCP视为一个模块（就像HTTP或JSON无处不在），而不是作为竞争对手项目。

8。公众的看法，市场牵引力和媒体报道​

在AI和Web3社区中，对MCP的公众情绪一直是非常积极的，这些社区通常与热情接壤。许多人将其视为“改变游戏规则的**”，它悄悄地到达，但随后席卷了该行业。让我们分解感知，牵引力和著名的媒体叙事：

**市场牵引力和采用指标：**到2025年中，MCP在新协议中实现了很少的采用水平。如前所述。仅此一项就向市场发出了信号，即MCP可能会留在这里（类似于在互联网早期互联网时代的宽大支持TCP/IP或HTTP的广泛支持）。在Web3端， *牵引力在开发人员行为中很明显 *：黑客马拉松开始以MCP项目为特色，许多区块链开发工具现在将MCP集成作为卖点。经常引用“几个月内1000多个连接器”和迈克·克里格（Mike Krieger）的“成千上万个集成”报价的统计数据，以说明MCP捕获的速度。这表明网络效果强大 - MCP可用的工具越多，它越有用，促使采用更多（积极的反馈循环）。风投和分析师指出，MCP在一年以下实现了一年以下的“ AI互操作性”尝试在几年以来未能做到的事情，这在很大程度上是由于时间安排（在AI代理商中占据了兴趣浪潮）和开源。在Web3媒体中，有时会根据开发人员的思维方式和集成到项目中来衡量牵引力，而MCP现在在两个方面都得分很高。

**在AI和Web3社区中的公众看法：最初，MCP在第一次宣布时（2024年底）在雷达下飞行。但是到2025年初，随着成功故事的出现，感知转变为兴奋。 AI从业人员将MCP视为“缺少拼图”，以使AI代理在玩具示例之外真正有用。另一方面，Web3构建器将其视为最终将AI纳入DAPP的桥梁，而不会丢弃权力下放 - 例如，AI可以使用链上的数据而无需集中的Oracle。 思想领导者一直在赞美：例如，耶稣·罗德里格斯（Jesus Rodriguez）（著名的Web3 AI作家）在Coindesk中写道，MCP可能是“ AI时代最具变革性的协议之一，并且非常适合Web3架构”。 Rares Crisan在一个著名的资本博客中认为，MCP可以通过使互联网更加以用户为中心和自然互动来实现Web3的承诺。这些叙述将MCP视为革命性而实用的，而不仅仅是炒作。

公平地说，并非所有评论都是不可判的。像Reddit这样的论坛上的一些AI开发人员指出，MCP“不做所有事情” - 这是一种通信协议，而不是开箱即用的代理商或推理引擎。例如，一个标题为“ MCP是死胡同”的Reddit讨论认为，MCP本身并不能管理代理认知或保证质量。它仍然需要良好的代理设计和安全控制。这种观点表明，MCP可以被淘汰为银弹。但是，这些批评更多地是关于回火的期望，而不是拒绝MCP的实用性。他们强调MCP解决了工具连接性，但仍必须建立强大的代理逻辑（即MCP不会神奇地创建智能代理，它可以用工具为工具）。 **共识是，即使在谨慎的声音中，MCP也是向前迈出的一大步。 Hugging Face的社区博客指出，尽管MCP并不是一个解决方案，但它是集成，上下文意识到的AI的主要推动者，因此开发人员因此而围绕它进行集会。

媒体报道： MCP在主流技术媒体和利基区块链媒体上都获得了明显的报道：

• ** TechCrunch **经营多个故事。他们介绍了2024年推出的最初概念（“拟人化提出了一种将数据连接到AI聊天机器人连接到AI聊天机器人的新方法”。2025年，TechCrunch强调了每个大收养时刻：OpenAI的支持，Google的Embrace，Microsoft/Github的参与。这些文章通常强调MCP围绕MCP的行业团结。例如，TechCrunch引用了Sam Altman的认可，并指出了从竞争对手标准到MCP的迅速转变。这样一来，他们将MCP描绘成新兴的标准，类似于没有人希望在90年代被排除在Internet协议之外。在一个著名的出口中，这种报道向更广泛的科技界发出了信号，即MCP是重要和真实的，而不仅仅是一个边缘开放源项目。
• ** Coindesk 和其他加密出版物锁定在 Web3 Angle **上。罗德里格斯（Rodriguez）（2025年7月）的意见文章经常被引用；它绘制了一张未来派的图片，每个区块链都可以是MCP服务器，而新的MCP网络可能会在区块链上运行。它将MCP连接到分散的身份，身份验证和可验证性等概念 - 讲区块链受众的语言，并建议MCP可能是真正将AI与分散框架融合在一起的协议。 CoIntelegraph，Bankless和其他人还在“ AI代理和defi”和类似主题的背景下讨论了MCP，通常对可能性进行了乐观的态度（例如，Bankless有一篇关于使用MCP让AI管理链链交易的文章，并为自己的MCP服务器提供了一种方法）。
• **著名的VC博客 /分析师报告：**著名的资本博客文章（2025年7月）是Venture Analysis绘制MCP和Web协议演变之间相似之处的示例。它本质上认为MCP可以为Web3做HTTP对Web1所做的事情 - 提供了一个新的接口层（自然语言接口），该界面层（自然语言接口）无法替代基础基础架构，但可实现。这种叙述令人信服，并在面板和播客中得到了回应。它可以将MCP定位为不像区块链竞争，而是与最终允许普通用户（通过AI）轻松利用区块链和Web服务的下一个抽象。
• **开发人员社区的嗡嗡声：**在正式文章之外，MCP的崛起可以通过其在开发人员话语中的存在来衡量 - 会议演讲，YouTube频道，新闻通讯。例如，诸如“ MCP：Agentic AI的丢失链接”之类的流行博客文章？在Runtime.news和新闻通讯（例如AI研究人员Nathan Lambert）等网站上，讨论了与MCP的实践实验及其与其他工具使用框架的比较。总体语气是好奇心和兴奋：开发人员分享了将AI连接到他们的家庭自动化或加密钱包的演示，只使用MCP服务器几行，这是不久前的科幻服务。这种基层兴奋很重要，因为它表明MCP超越了公司认可。
• **企业的观点：**专注于企业AI的媒体和分析师也将MCP视为关键开发。例如， *新的堆栈 *介绍了人类为Claude中的远程MCP服务器的添加支持以供企业使用。这里的角度是，企业可以使用MCP将其内部知识库和系统安全地连接到AI。这对Web3也很重要，因为许多区块链公司都是企业本身，并且可以在内部利用MCP（例如，加密交易所可以使用MCP让AI分析内部交易日志以进行欺诈检测）。

**引人注目的引文和反应：**一些值得一提的是封装公众的看法：

• *“就像HTTP彻底改变了Web通信一样，MCP提供了一个通用的框架...用单个协议代替了零散的集成。” * - Coindesk。与HTTP的比较非常强大。它将MCP框架为基础架构级创新。
• *“ MCP已成为一个蓬勃发展的开放标准，具有成千上万的集成和增长。在连接您已经拥有的数据时，LLM最有用...” * - Mike Krieger（人类）。这是对牵引力和核心价值主张的官方确认，在社交媒体上已广泛分享。
• *“ Web3的承诺...最终可以通过自然语言和AI代理来实现。....MCP是我们在群众面前看到的最接近的Web3。” * - 值得注意的资本。这个大胆的声明引起了人们对加密型UX缓慢改善感到沮丧的人的共鸣。它表明AI可能会通过抽象复杂性来破解主流采用的代码。

**挑战和怀疑：**热情很高，媒体也讨论了挑战：

• **安全问题：**诸如新堆栈或安全博客之类的插座提出，如果不打磨，允许AI执行工具可能是危险的。如果恶意的MCP服务器试图获得AI执行有害动作怎么办？ Limechain博客明确警告了 *具有社区开发的MCP服务器的“重大安全风险” *（例如，处理私钥的服务器必须非常安全）。讨论中已经回应了这些问题：从本质上讲，MCP扩大了AI的能力，但权力带来了风险。社区的反应（指南，身份机制）也得到了涵盖，通常会确保正在建立缓解。尽管如此，任何对MCP的高调滥用（例如，AI引发了意外的加密转移）都会影响感知，因此媒体在这方面受到注意。
• **绩效和成本：**一些分析师指出，与直接调用API相比，使用使用工具的AI代理可能会慢或更昂贵（因为AI可能需要多个来回步骤来获得所需的东西）。在高频交易或链上执行环境中，该潜伏期可能会出现问题。目前，这些被视为优化的技术障碍（通过更好的代理设计或流媒体），而不是破坏交易。
• **炒作管理：**与任何趋势技术一样，都有一些炒作。一些声音警告不要将MCP宣布为所有问题。例如，拥抱的脸部文章问“ MCP是银弹吗？”答案否 - 开发人员仍然需要处理上下文管理，而MCP则可以与良好的提示和内存策略结合使用。这种平衡的意义在话语中是健康的。

**整体媒体情绪：**出现的叙述在很大程度上充满希望和前瞻性：

-MCP被视为一种实用工具，现在可以提供真正的改进（因此不是蒸气软件），该工具通过引用工作示例来强调：Claude Reading Files，使用MCP在VSCODE中使用MCP，AI在演示中完成SOLANA交易的AI等。

• 它也被描绘成AI和Web3的未来的战略关键。媒体经常得出结论，MCP或类似的事物对于“分散的AI”或“ Web4”或一个用于下一代Web的任何术语至关重要。有一种感觉，MCP打开了一扇门，现在的创新正在流动 - 无论是NAMDA的分散代理商还是将传统系统与AI连接到AI的企业，许多未来的故事情节都追溯到MCP的介绍。

在市场上，可以通过在MCP生态系统周围形成初创企业和资金来评估牵引力。确实，有传言/报告有创业公司专注于“ MCP市场”或托管MCP平台获得资金（关于其著名的资本写作表明VC兴趣）。我们可以期望媒体开始切向覆盖这些内容 - 例如，“启动X使用MCP让您的AI管理您的加密产品组合 - 筹集了Y百万美元”。

**感知的结论：**到2025年下半年，MCP享有突破性促进技术的声誉。它在人工智能和加密货币中都具有有影响力的人物的强烈倡导。公共叙述已经从 *“这是一个整洁的工具” *变成 * *“这可能是下一个网络的基础” *。同时，实际覆盖范围证实了它正在工作和被采用，并借用了信誉。只要社区继续应对挑战（安全性，规模安全）并且没有发生重大灾难，MCP的公开形象可能会保持积极的态度，甚至成为标志性的，因为“使AI和Web3共同发挥作用的协议”。

媒体可能会密切关注：

• 成功案例（例如，如果主要道路通过MCP实现AI司库，或者政府使用MCP用于开放数据AI系统）。
• 任何安全事件（评估风险）。
• MCP网络的发展以及任何令牌或区块链组件是否正式进入图片（这将是桥接AI和加密货币的大新闻）。

但是，到目前为止，可以通过Coindesk的一行来概括覆盖范围： *“ Web3和MCP的组合可能只是分散的AI的新基础。”

参考：

• 拟人新闻： *“介绍模型上下文协议”， * 2024年11月 -Limechain博客： *“什么是MCP，它如何适用于区块链？” * 2025年5月
• 链堆博客： *“ Web3构建器的MCP：Solana，EVM和文档”， * 2025年6月 -Coindesk Op-Ed： *“代理协议：Web3的MCP潜力”， * 7月2025年
• 著名的资本： *“为什么MCP代表真正的Web3机会”， * 7月2025年 -TechCrunch： *“ Openai采用人类标准……”， * 2025年3月26日 -TechCrunch： *“ Google要接受人类的标准……”， * 2025年4月9日 -TechCrunch： *“ Github，Microsoft Ably…（MCP指导委员会）”， * 2025年5月19日
• Microsoft Dev博客： *“ MCP的官方C＃SDK”， * 2025年4月
• 拥抱脸博客： *“＃14：什么是MCP，为什么每个人都在谈论它？” * 2025年3月
• 弥赛亚研究： *“ fetch.ai个人资料，” * 2023
• 中（NU BINDIMES）： *“揭开singularitynet”， * 2024年3月

谷歌的代理支付协议（AP2）是一个新宣布的开放标准，旨在实现由AI代理代表用户发起的安全、可信交易。AP2与超过60个支付和技术组织（包括主要支付网络、银行、金融科技公司和Web3公司）合作开发，建立了"代理支付"的通用语言 —— 即自主代理（如AI助手或基于LLM的代理）可以为用户执行的购买和金融交易。AP2的创建源于一个根本性转变：传统上，在线支付系统假设有人类直接点击"购买"，但AI代理按用户指令行动的兴起打破了这一假设。AP2解决了AI驱动商务中授权、真实性和问责制的挑战，同时与现有支付基础设施保持兼容。本报告检视了AP2的技术架构、目的和用例、与AI代理和支付提供商的集成、安全性和合规性考虑、与现有协议的比较、对Web3/去中心化系统的影响，以及行业采用/路线图。

技术架构：AP2如何工作​

AP2的核心引入了一个密码学安全的交易框架，基于可验证数字凭证（VDCs）—— 本质上是防篡改的签名数据对象，作为用户授权内容的数字"合约"。在AP2术语中，这些合约被称为授权书，它们为每笔交易形成可审计的证据链。AP2架构中有三种主要的授权书类型：

• 意图授权书： 捕获用户对购买的初始指令或条件，特别是在*"无人在场"场景中（代理将在用户不在线时稍后行动）。它定义了用户给予代理的授权范围* —— 例如，"如果音乐会门票降到200美元以下，最多买2张"。这个授权书由用户预先加密签名，作为在特定限制内同意的可验证证明。
• 购物车授权书： 代表用户已批准的最终交易详情，用于*"有人在场"*场景或结账时刻。它包括确切的商品或服务、价格和购买的其他细节。当代理准备完成交易时（例如填满购物车后），商家首先对购物车内容进行加密签名（保证订单详情和价格），然后用户（通过其设备或代理界面）签署创建购物车授权书。这确保了所见即所付，准确锁定向用户呈现的最终订单。
• 支付授权书： 发送给支付网络（如卡网络或银行）的单独凭证，表明AI代理参与了交易。支付授权书包含元数据，如用户在授权期间是否在场，并作为风险管理系统的标志。通过向收单银行和发卡银行提供用户意图的密码学可验证证据，这个授权书帮助它们评估上下文（例如，区分代理发起的购买与典型欺诈）并相应地管理合规或责任。

所有授权书都实现为由相关方密钥（用户、商家等）签名的可验证凭证，为每个代理主导的交易产生不可否认的审计跟踪。实际上，AP2使用基于角色的架构来保护敏感信息 —— 例如，代理可能处理意图授权书而从不看到原始支付详情，这些详情只在需要时以受控方式披露，保护隐私。用户意图 → 商家承诺 → 支付授权的密码学链建立了各方之间的信任，确保交易反映用户的真实指令，并且代理和商家都遵守了这些指令。

交易流程： 为说明AP2如何端到端工作，考虑一个有人参与的简单购买场景：

1. 用户请求： 用户要求其AI代理购买特定商品或服务（如"为我订购这双鞋，我的尺码"）。
2. 购物车构建： 代理与商家系统通信（使用标准API或通过代理对代理交互）为指定商品按给定价格组装购物车。
3. 商家保证： 在向用户展示购物车之前，商家端对购物车详情（商品、数量、价格等）进行加密签名。这一步创建了商家签名报价，保证确切条款（防止任何隐藏更改或价格操控）。
4. 用户批准： 代理向用户显示最终购物车。用户确认购买，此批准触发用户端的两个加密签名：一个在购物车授权书上（接受商家的购物车现状）和一个在支付授权书上（通过选定的支付提供商授权支付）。这些签名授权书然后分别与商家和支付网络共享。
5. 执行： 有了购物车授权书和支付授权书，商家和支付提供商继续安全执行交易。例如，商家向支付网络（卡网络、银行等）提交支付请求以及用户批准证明，支付网络可以验证支付授权书。结果是完成的购买交易，带有密码学审计跟踪将用户意图与最终支付联系起来。

这个流程展示了AP2如何在AI驱动购买的每一步都建立信任。商家有用户同意以什么价格购买什么的密码学证明，发卡行/银行有用户授权该支付的证明，即使AI代理促成了这个过程。在争议或错误的情况下，签名授权书作为明确证据，帮助确定问责（例如，如果代理偏离指令或如果费用不是用户批准的）。实质上，AP2的架构确保可验证的用户意图 —— 而不是对代理行为的信任 —— 是交易的基础，大大减少了模糊性。

AP2的目的和用例​

为什么需要AP2： AP2的主要目的是解决当AI代理可以代表用户花钱时出现的新兴信任和安全问题。谷歌及其合作伙伴确定了当自主代理在循环中时，今天的支付基础设施无法充分回答的几个关键问题：

• 授权： 如何证明用户实际给了代理进行特定购买的权限？（换句话说，确保代理不是在没有用户知情同意的情况下购买东西。）
• 真实性： 商家如何知道代理的购买请求是真实的，反映了用户的真实意图，而不是错误或AI幻觉？
• 问责制： 如果通过代理发生欺诈或错误交易，谁负责 —— 用户、商家、支付提供商，还是AI代理的创造者？

没有解决方案，这些不确定性围绕代理主导的商务创造了"信任危机"。AP2的使命是通过建立安全代理交易的统一协议来提供解决方案。通过引入标准化的授权书和意图证明，AP2防止了分散的生态系统，避免每个公司发明自己的临时代理支付方法。相反，任何符合要求的AI代理都可以在一套通用规则和验证下与任何符合要求的商家/支付提供商交互。这种一致性不仅避免了用户和商家的困惑，还为金融机构提供了管理代理发起支付风险的明确方式，而不是处理专有方法的拼接。简而言之，AP2的目的是成为让"代理经济"在不破坏支付生态系统的情况下增长的基础信任层。

预期用例： 通过解决上述问题，AP2为超越人类手动点击购买可能性的新商务体验和用例打开了大门。AP2支持的一些代理启用商务示例包括：

• 更智能的购物： 客户可以指示其代理，"我想要这件绿色冬季夹克，我愿意支付比当前价格高20%"。有了编码这些条件的意图授权书，代理将持续监控零售商网站或数据库。一旦夹克有绿色可选（并在价格阈值内），代理自动执行购买带有安全的签名交易 —— 捕获否则会错过的销售。从用户的初始请求到自动结账的整个交互都由AP2授权书管理，确保代理只购买授权的确切内容。
• 个性化优惠： 用户告诉其代理他们正在寻找来自特定商家的特定产品（比如新自行车）用于即将到来的旅行。代理可以与商家自己的AI代理分享这种兴趣（在意图授权书的边界内），包括相关上下文如旅行日期。商家代理知道用户的意图和上下文，可以回应定制套餐或折扣 —— 例如，"自行车+头盔+旅行架15%折扣，48小时内有效"。使用AP2，用户的代理可以安全地接受并完成这个定制优惠，将简单查询转变为商家更有价值的销售。
• 协调任务： 用户计划复杂任务（如周末旅行）完全委托它："为这些日期预订航班和酒店，总预算700美元"。代理可以与多个服务提供商的代理交互 —— 航空公司、酒店、旅行平台 —— 找到符合预算的组合。一旦确定了合适的航班-酒店套餐，代理使用AP2执行一次性多个预订，每个都经过加密签名（例如，为航空公司和酒店分别发出购物车授权书，都在用户的意图授权书下授权）。AP2确保这个协调交易的所有部分都按批准发生，甚至允许同时执行，这样门票和预订一起预订，没有一部分中途失败的风险。

这些场景只说明了AP2预期用例的一小部分。更广泛地说，AP2的灵活设计支持传统电商流程和全新的商务模式。例如，AP2可以促进类似订阅的服务（代理通过在满足条件时购买来保持您的必需品库存）、事件驱动购买（在触发事件发生瞬间购买门票或商品）、群体代理谈判（多个用户的代理汇集授权书来讨价还价群体交易），以及许多其他新兴模式。在每种情况下，共同点是AP2提供信任框架 —— 明确的用户授权和密码学可审计性 —— 允许这些代理驱动的交易安全发生。通过处理信任和验证层，AP2让开发者和企业专注于创新新的AI商务体验，而无需从头重新发明支付安全。

与代理、LLMs和支付提供商的集成​

AP2明确设计为与AI代理框架和现有支付系统无缝集成，充当两者之间的桥梁。谷歌将AP2定位为其代理对代理（A2A）协议和模型上下文协议（MCP）标准的扩展。换句话说，如果A2A为代理通信任务提供通用语言，MCP标准化AI模型如何整合上下文/工具，那么AP2在顶部添加了交易层用于商务。这些协议是互补的：A2A处理代理对代理通信（允许比如购物代理与商家代理对话），而AP2在这些交互中处理代理对商家支付授权。因为AP2是开放和非专有的，它意味着与框架无关：开发者可以将其与谷歌自己的代理开发工具包（ADK）或任何AI代理库一起使用，同样它可以与包括LLMs在内的各种AI模型工作。例如，基于LLM的代理可以通过生成和交换所需的授权书负载（由AP2规范指导）而不是仅仅自由形式文本来使用AP2。通过强制执行结构化协议，AP2帮助将AI代理的高级意图（可能来自LLM的推理）转换为具体的安全交易。

在支付方面，AP2是与传统支付提供商和标准协调构建的，而不是作为撕裂和替换系统。该协议是支付方法无关的，意味着它可以支持各种支付轨道 —— 从信用/借记卡网络到银行转账和数字钱包 —— 作为转移资金的底层方法。在其初始版本中，AP2强调与卡支付的兼容性，因为这些在在线商务中最常见。AP2支付授权书设计为插入现有的卡处理流程：它为支付网络（如Visa、万事达、美国运通）和发卡银行提供额外数据，表明AI代理参与以及用户是否在场，从而补充现有的欺诈检测和授权检查。本质上，AP2不处理支付本身；它用用户意图的密码学证明增强支付请求。这允许支付提供商以适当的谨慎或速度处理代理发起的交易（例如，如果发卡行看到有效的AP2授权书证明用户预先批准了它，可能会批准看起来不寻常的购买）。值得注意的是，谷歌和合作伙伴计划发展AP2以支持"推送"支付方法 —— 如实时银行转账（如印度的UPI或巴西的PIX系统）—— 以及其他新兴数字支付类型。这表明AP2的集成将扩展到卡之外，与全球现代支付趋势保持一致。

对于商家和支付处理商，集成AP2将意味着支持额外的协议消息（授权书）和验证签名。许多大型支付平台已经参与塑造AP2，所以我们可以期待它们会构建对它的支持。例如，像Adyen、Worldpay、PayPal、Stripe（没有明确提及但可能感兴趣）等公司可能会将AP2整合到其结账API或SDK中，允许代理以标准化方式发起支付。因为AP2是GitHub上带有参考实现的开放规范，支付提供商和技术平台可以立即开始实验。谷歌还提到了一个AI代理市场，第三方代理可以在其中列出 —— 这些代理预期支持AP2的任何交易能力。实际上，构建AI销售助手或采购代理的企业可以将其列在这个市场上，感谢AP2，该代理可以可靠地执行购买或订单。

最后，AP2的集成故事受益于其广泛的行业支持。通过与主要金融机构和技术公司共同开发协议，谷歌确保AP2与现有行业规则和合规要求保持一致。与支付网络（如万事达、银联）、发卡行（如美国运通）、金融科技公司（如Revolut、PayPal）、电商玩家（如Etsy）甚至身份/安全提供商（如Okta、Cloudflare）的合作表明AP2正在设计为以最小摩擦嵌入现实世界系统。这些利益相关者在KYC（了解您的客户法规）、欺诈预防和数据隐私等领域带来了专业知识，帮助AP2开箱即用地解决这些需求。总之，AP2构建为代理友好和支付提供商友好：它扩展现有AI代理协议来处理交易，并在现有支付网络之上分层以利用其基础设施，同时添加必要的信任保证。

安全性、合规性和互操作性考虑​

安全性和信任是AP2设计的核心。协议使用密码学（对授权书的数字签名）确保代理交易中的每个关键操作都是可验证和可追踪的。这种不可否认性是至关重要的：用户和商家都不能后来否认被授权和同意的内容，因为授权书作为安全记录。直接好处是在欺诈预防和争议解决方面 —— 使用AP2，如果恶意或有缺陷的代理尝试未授权购买，缺乏有效用户签名授权书将是明显的，交易可以被拒绝或撤销。相反，如果用户声称"我从未批准这次购买"，但存在带有其密码学签名的购物车授权书，商家和发卡行有强有力的证据支持费用。这种问责的清晰度回答了支付行业的主要合规关切。

授权和隐私： AP2强制执行代理主导交易的明确授权步骤，这与强客户认证等监管趋势保持一致。融入AP2的用户控制原则意味着代理不能花费资金，除非用户（或用户委托的人）提供了可验证的指令。即使在完全自主场景中，用户也通过意图授权书预定义规则。这种方法可以被视为类似于给代理特定交易的授权委托书，但以数字签名、细粒度的方式。从隐私角度来看，AP2注意数据共享：协议使用基于角色的数据架构来确保敏感信息（如支付凭证或个人详情）只与绝对需要它的各方共享。例如，代理可能向商家发送包含商品和价格信息的购物车授权书，但用户的实际卡号可能只通过支付授权书与支付处理商共享，而不与代理或商家共享。这最小化了数据的不必要暴露，有助于遵守隐私法和处理支付数据的PCI-DSS规则。

合规性和标准： 因为AP2是在既定金融实体的输入下开发的，它被设计为满足或补充支付中的现有合规标准。该协议不绕过通常的支付授权流程 —— 相反，它用额外的证据和标志增强它们。这意味着AP2交易仍然可以利用欺诈检测系统、3-D安全检查或任何需要的监管检查，AP2的授权书作为额外的认证因素或上下文线索。例如，银行可以将支付授权书视为类似于客户在交易上的数字签名，可能简化用户同意要求的合规性。此外，AP2的设计者明确提到与"行业规则和标准协调"工作。我们可以推断，随着AP2的发展，它可能被带到正式的标准机构（如W3C、EMVCo或ISO）以确保它与全球金融标准保持一致。谷歌已表示承诺通过标准组织开放、协作地发展AP2。这个开放过程将有助于解决任何监管关切并实现广泛接受，类似于之前的支付标准（EMV芯片卡、3-D安全等）如何经历行业范围的合作。

互操作性： 避免分散是AP2的关键目标。为此，协议是公开发布的，任何人都可以实现或集成。它不与谷歌云服务绑定 —— 实际上，AP2是开源（Apache-2许可），规范加上参考代码在公共GitHub存储库中。这鼓励互操作性，因为多个供应商可以采用AP2，他们的系统仍然可以协同工作。已经，互操作性原则被强调：AP2是现有开放协议（A2A、MCP）的扩展，是非专有的，意味着它促进了实现的竞争生态系统，而不是单一供应商解决方案。实际上，公司A构建的AI代理可以与公司B的商家系统发起交易，如果两者都遵循AP2 —— 双方都不锁定到一个平台。

一个可能的关切是确保一致的采用：如果一些主要玩家选择不同的协议或封闭方法，分散仍可能发生。然而，鉴于AP2背后的广泛联盟，它似乎准备成为事实标准。许多身份和安全专注公司（例如Okta、Cloudflare、Ping Identity）在AP2生态系统中的包含*图：超过60家跨金融、技术和加密的公司正在AP2上合作（合作伙伴的部分列表）。*表明互操作性和安全性正在共同解决。这些合作伙伴可以帮助将AP2集成到身份验证工作流程和欺诈预防工具中，确保AP2交易可以在系统间信任。

从技术角度来看，AP2使用广泛接受的密码学技术（可能基于JSON-LD或JWT的可验证凭证、公钥签名等）使其与现有安全基础设施兼容。组织可以使用其现有的PKI（公钥基础设施）来管理签名授权书的密钥。AP2似乎也预期与去中心化身份系统的集成：谷歌提到AP2创造了在代理授权的去中心化身份等领域创新的机会。这意味着未来，AP2可以利用DID（去中心化标识符）标准或去中心化标识符验证，以可信方式识别代理和用户。这种方法将通过不依赖任何单一身份提供商进一步增强互操作性。总之，AP2通过密码学和明确问责强调安全性，旨在通过设计准备合规，并通过其开放标准性质和广泛行业支持促进互操作性。

与现有协议的比较​

AP2是一个新颖的协议，解决了现有支付和代理框架未涵盖的空白：使自主代理能够以安全、标准化的方式执行支付。在代理通信协议方面，AP2建立在先前的工作之上，如代理对代理（A2A）协议。A2A（2025年早期开源）允许不同的AI代理互相交谈，无论其底层框架如何。然而，A2A本身没有定义代理应该如何进行交易或支付 —— 它更多是关于任务谈判和数据交换。AP2通过添加任何代理在对话导致购买时可以使用的交易层来扩展这个景观。实质上，AP2可以被视为A2A和MCP的补充，而不是重叠：A2A涵盖通信和协作方面，MCP涵盖使用外部工具/API，AP2涵盖支付和商务。它们一起形成了未来"代理经济"的标准栈。这种模块化方法有些类似于互联网协议：例如，用于数据通信的HTTP和用于安全的SSL/TLS —— 这里A2A可能像代理的HTTP，AP2是商务顶部的安全交易层。

当将AP2与传统支付协议和标准比较时，既有相似之处也有差异。传统在线支付（信用卡结账、PayPal交易等）通常涉及如HTTPS的安全传输协议，以及如PCI DSS的处理卡数据标准，加上可能的3-D安全的额外用户认证。这些假设用户驱动的流程（用户点击并可能输入一次性代码）。相比之下，AP2引入了第三方（代理）参与流程的方式，而不破坏安全性。可以将AP2的授权书概念与OAuth风格的委托授权的扩展进行比较，但应用于支付。在OAuth中，用户可以通过令牌授予应用程序对账户的有限访问；类似地在AP2中，用户通过授权书在某些条件下授予代理花费的权力。关键差异是AP2的"令牌"（授权书）是金融交易的特定签名指令，比现有支付授权更细粒度。

另一个比较点是AP2如何与现有电商结账流程相关。例如，许多电商网站使用如W3C支付请求API或平台特定SDK的协议来简化支付。这些主要标准化浏览器或应用程序如何从用户收集支付信息，而AP2标准化代理如何向商家和支付处理商证明用户意图。AP2专注于可验证意图和不可否认性，使其区别于更简单的支付API。它在支付网络之上添加了额外的信任层。可以说AP2不是替换支付网络（Visa、ACH、区块链等），而是增强它们。协议明确支持所有类型的支付方法（甚至加密），所以它更多是关于标准化代理与这些系统的交互，而不是从头创建新的支付轨道。

在安全和认证协议领域，AP2与EMV芯片卡中的数字签名或数字合约中的公证等事物有一些精神共同点。例如，EMV芯片卡交易生成密码图来证明卡在场；AP2生成密码学证明证明用户的代理被授权。两者都旨在防止欺诈，但AP2的范围是代理-用户关系和代理-商家消息传递，现有支付标准没有解决这个问题。另一个新兴的比较是与加密中的账户抽象（如ERC-4337），用户可以授权预编程的钱包操作。加密钱包可以设置为允许某些自动交易（如通过智能合约自动支付订阅），但这些通常局限于一个区块链环境。另一方面，AP2旨在跨平台 —— 它可以利用区块链进行一些支付（通过其扩展），但也与传统银行合作。

在主流支付行业中，还没有AP2的直接"竞争者"协议 —— 它似乎是AI代理支付开放标准的第一次协调努力。专有尝试可能出现（或可能已经在个别公司内部进行），但AP2的广泛支持使其在成为该标准方面具有优势。值得注意的是，IBM和其他公司有**代理通信协议（ACP）**和类似的代理互操作性举措，但这些没有以AP2那样全面的方式涵盖支付方面。如果有的话，AP2可能与这些努力集成或利用（例如，IBM的代理框架可以为任何商务任务实现AP2）。

总之，AP2通过针对AI和支付的独特交叉点来区分自己：旧的支付协议假设人类用户，AP2假设AI中介并填补由此产生的信任空白。它扩展而不是与现有支付流程冲突，并补充现有代理协议如A2A。展望未来，人们可能会看到AP2与既定标准一起使用 —— 例如，AP2购物车授权书可能与传统支付网关API调用协同工作，或者AP2支付授权书可能附加到银行业的ISO 8583消息。AP2的开放性也意味着如果出现任何替代方法，AP2可以通过社区合作潜在地吸收或与它们对齐。在这个阶段，AP2正在设定以前不存在的基线，有效地在AI和支付堆栈中开拓新的协议层。

对Web3和去中心化系统的影响​

从一开始，AP2就被设计为包容Web3和基于加密货币的支付。该协议认识到未来商务将跨越传统法币渠道和去中心化区块链网络。如前所述，AP2支持从信用卡和银行转账到稳定币和加密货币的支付类型。实际上，与AP2的发布一起，谷歌宣布了一个名为A2A x402的加密支付特定扩展。这个扩展与像Coinbase、以太坊基金会和MetaMask等加密行业玩家合作开发，是"代理基础加密支付的生产就绪解决方案"。名称"x402"是对HTTP 402"需要支付"状态代码的致敬，该代码从未在Web上广泛使用 —— AP2的加密扩展有效地复活了HTTP 402的精神，用于想要在链上相互收费或支付的去中心化代理。实际上，x402扩展将AP2的授权书概念适应区块链交易。例如，代理可以持有来自用户的签名意图授权书，然后在满足条件时执行链上支付（比如发送稳定币），将授权书证明附加到该链上交易。这将AP2的链下信任框架与区块链的无信任性质相结合，给出两个世界的最佳：*链下各方（用户、商家）*可以信任的链上支付由用户授权。

AP2和Web3之间的协同作用在合作者列表中是明显的。加密交易所（Coinbase）、区块链基金会（以太坊基金会）、加密钱包（MetaMask）和Web3初创公司（如Sui的Mysten Labs、闪电网络的Lightspark）参与了AP2的开发。他们的参与表明AP2被视为去中心化金融的补充而不是竞争。通过创建AI代理与加密支付交互的标准方式，AP2可以推动加密在AI驱动应用中的更多使用。例如，AI代理可能使用AP2在用信用卡或用稳定币支付之间无缝切换，取决于用户偏好或商家接受度。A2A x402扩展专门允许代理通过链上手段货币化或支付服务，这在未来的去中心化市场中可能至关重要。它暗示代理可能作为区块链上的自主经济行为者运行（一些人称为DACs或DAOs的概念），能够处理服务所需的支付（如向另一个代理支付信息的小费）。AP2可以为这种交易提供通用语言，确保即使在去中心化网络上，代理也有其行为的可证明授权书。

在竞争方面，人们可能会问：纯去中心化解决方案是否使AP2不必要，反之亦然？AP2很可能在分层方法中与Web3解决方案共存。去中心化金融提供无信任执行（智能合约等），但它本身不解决"AI是否有人类的权限做这件事？"的问题。AP2解决了这个非常重要的人类对AI信任链接，即使支付本身在链上，这仍然很重要。而不是与区块链协议竞争，AP2可以被视为将它们与链下世界桥接。例如，智能合约可能只有在包含对有效AP2授权书签名的引用时才接受某个交易 —— 这可以实现为结合链下意图证明和链上执行。相反，如果有加密原生代理框架（一些区块链项目探索用加密资金运营的自主代理），它们可能开发自己的授权方法。然而，AP2的广泛行业支持可能引导即使那些项目采用或与AP2集成以保持一致性。

另一个角度是去中心化身份和凭证。AP2使用可验证凭证非常符合Web3的身份方法（如W3C标准化的DIDs和VCs）。这意味着AP2可以插入去中心化身份系统 —— 例如，用户的DID可用于签名AP2授权书，商家可以对区块链或身份中心验证。探索代理授权的去中心化身份的提及强化了AP2可能利用Web3身份创新以去中心化方式验证代理和用户身份，而不是仅依赖中心化权威。这是协同点，因为AP2和Web3都旨在给用户更多控制和其行动的密码学证明。

潜在冲突可能只有在设想完全去中心化的商务生态系统没有大型中介角色的情况下才会出现 —— 在那种情况下，AP2（最初由谷歌和合作伙伴推动）可能太中心化或由传统玩家治理？重要的是注意AP2是开源的，旨在标准化，所以它不是谷歌专有的。这使它对重视开放协议的Web3社区更可接受。如果AP2被广泛采用，它可能减少对代理单独Web3特定支付协议的需求，从而统一努力。另一方面，一些区块链项目可能更喜欢纯链上授权机制（如多签钱包或链上托管逻辑）用于代理交易，特别是在没有任何中心化权威的无信任环境中。这些可以被视为替代方法，但它们可能仍然是小众，除非它们可以与链下系统交互。AP2通过涵盖两个世界，实际上可能通过使加密成为AI代理可以无缝使用的另一种支付方法来加速Web3采用。确实，一位合作伙伴注意到*"稳定币为[用于]传统基础设施的代理系统提供了明显的扩展挑战解决方案"，强调加密可以在处理规模或跨境场景中补充AP2。同时，Coinbase的工程负责人评论说，将x402加密扩展带入AP2"是有意义的 —— 这是代理的天然游乐场...很高兴看到代理相互支付与AI社区产生共鸣"*。这暗示AI代理通过加密网络交易的愿景不仅仅是理论想法，而是预期结果，AP2作为催化剂。

总之，AP2与Web3高度相关：它将加密支付作为一等公民纳入，并与去中心化身份和凭证标准保持一致。而不是与去中心化支付协议正面竞争，AP2可能与它们互操作 —— 提供授权层，而去中心化系统处理价值转移。随着传统金融和加密之间的界限模糊（稳定币、CBDCs等），像AP2这样的统一协议可以作为AI代理与任何形式的货币（中心化或去中心化）之间的通用适配器。

行业采用、合作伙伴关系和路线图​

AP2最大的优势之一是即使在这个早期阶段背后的广泛行业支持。谷歌云宣布它*"与超过60个组织的多元化群体合作"开发AP2。这些包括主要信用卡网络（如万事达、美国运通、JCB、银联）、领先的金融科技和支付处理商（PayPal、Worldpay、Adyen、Checkout.com、Stripe的竞争对手）、电商和在线市场（Etsy、Shopify（通过Stripe等合作伙伴）、Lazada、Zalora）、企业技术公司（Salesforce、ServiceNow、Oracle可能通过合作伙伴、Dell、Red Hat）、身份和安全公司（Okta、Ping Identity、Cloudflare）、咨询公司（德勤、埃森哲）和加密/Web3组织（Coinbase、以太坊基金会、MetaMask、Mysten Labs、Lightspark）等。如此广泛的参与者阵容是行业兴趣和可能采用的强烈指标。许多这些合作伙伴已经公开表达支持。例如，Adyen的联合CEO强调对代理商务"通用规则手册"的需求，并将AP2视为其支持商家新支付构建块使命的自然延伸。美国运通的EVP表示AP2对"下一代数字支付"*很重要，信任和问责是首要的。如前所述，Coinbase的团队对将加密支付集成到AP2中感到兴奋。这种支持合唱表明行业中许多人将AP2视为AI驱动支付的可能标准，他们渴望塑造它以确保满足其要求。

从采用立场来看，AP2目前处于规范和早期实现阶段（2025年9月宣布）。完整的技术规范、文档和一些参考实现（如Python等语言）在项目的GitHub上可供开发者实验。谷歌还表示AP2将被整合到其代理产品和服务中。一个值得注意的例子是前面提到的AI代理市场：这是一个第三方AI代理可以提供给用户的平台（可能是谷歌生成AI生态系统的一部分）。谷歌说许多构建代理的合作伙伴将使它们在市场中可用，"由AP2启用的新的可交易体验"。这暗示随着市场启动或增长，AP2将成为任何需要执行交易的代理的支柱，无论是从谷歌云市场自主购买软件还是代理为用户购买商品/服务。自主采购（一个代理代表公司从另一个代理购买）和自动许可证扩展等企业用例已被特别提及为AP2可能很快促进的领域。

在路线图方面，AP2文档和谷歌的宣布给出了一些明确指示：

• 近期： 继续协议的开放开发与社区输入。GitHub存储库将通过额外的参考实现和改进更新，随着现实世界测试的进行。我们可以期待库/SDK出现，使将AP2集成到代理应用程序中更容易。此外，合作伙伴公司可能进行初始试点项目或概念验证。鉴于许多大型支付公司参与，他们可能在受控环境中试用AP2（例如，在小用户测试版中的AP2启用结账选项）。
• 标准和治理： 谷歌已表达将AP2转移到开放治理模型的承诺，可能通过标准机构。这可能意味着向Linux基金会（如A2A协议所做）等组织提交AP2或形成联盟来维护它。Linux基金会、W3C甚至ISO/TC68（金融服务）等机构可能是正式化AP2的考虑。开放治理将向行业保证AP2不在单一公司控制下，将保持中性和包容性。
• 功能扩展： 技术上，路线图包括扩展对更多支付类型和用例的支持。如规范中所述，在卡之后，焦点将转移到**"推送"支付如银行汇款和本地实时支付方案，以及数字货币**。这意味着AP2将概述意图/购物车/支付授权书如何工作，比如直接银行转账或加密钱包转账，其中流程与卡拉取略有不同。A2A x402扩展是加密的一种扩展；类似地，我们可能看到开放银行API的扩展或B2B发票场景的扩展。
• 安全和合规增强： 随着真实交易开始通过AP2流动，将受到监管机构和安全研究人员的审查。开放过程可能会迭代使授权书更加稳健（例如，确保授权书格式标准化，可能使用W3C可验证凭证格式等）。与身份解决方案的集成（可能利用生物识别用于用户签名授权书，或将授权书链接到数字身份钱包）可能是路线图的一部分以增强信任。
• 生态系统工具： 一个新兴生态系统是可能的。已经，初创公司注意到空白 —— 例如，Vellum.ai分析提到一个名为Autumn的初创公司构建"AI计费基础设施"，本质上是Stripe之上的工具来处理AI服务的复杂定价。随着AP2获得牵引力，我们可以期待更多工具如代理专注的支付网关、授权书管理仪表板、代理身份验证服务等出现。谷歌的参与意味着AP2也可以集成到其云产品中 —— 想象Dialogflow或Vertex AI代理工具中的AP2支持，使代理处理交易成为一键（在谷歌云中管理所有必要的密钥和证书）。

总的来说，AP2的轨迹让人想起其他主要行业标准：有强大赞助商（谷歌）的初始启动、广泛行业联盟、开源参考代码，然后是迭代改进和在真实产品中的逐步采用。AP2邀请所有玩家"与我们一起构建这个未来"的事实强调路线图是关于合作的。如果势头继续，AP2可能在几年内变得像今天OAuth或OpenID Connect在其领域中一样普遍 —— 一个看不见但关键的层，实现跨服务的功能。

结论​

AP2（代理/代理支付协议）代表着朝着AI代理可以像人类一样可靠和安全地交易的未来迈出的重要一步。技术上，它引入了可验证授权书和凭证的巧妙机制，在代理主导的交易中注入信任，确保用户意图明确且可执行。其开放、可扩展的架构允许它与新兴的AI代理框架和既定的金融基础设施集成。通过解决授权、真实性和问责制的核心关切，AP2为AI驱动的商务蓬勃发展奠定了基础，而不牺牲安全性或用户控制。

AP2的引入可以被视为奠定新基础 —— 就像早期互联网协议启用网络一样 —— 为一些人称为"代理经济"的东西。它为无数创新铺平了道路：个人购物代理、自动交易发现机器人、自主供应链代理等，所有这些都在共同信任框架下运营。重要的是，AP2的包容性设计（拥抱从信用卡到加密的一切）将其定位在传统金融和Web3的交叉点，可能通过共同的代理中介协议桥接这些世界。

到目前为止，行业反应非常积极，广泛联盟表明AP2可能成为广泛采用的标准。AP2的成功将取决于持续合作和现实世界测试，但鉴于它解决的明确需求，其前景强劲。在更广泛的意义上，AP2例证了技术如何发展：一种新能力（AI代理）出现，破坏了旧假设，解决方案是开发一个新的开放标准来适应这种能力。通过现在投资开放的安全优先协议，谷歌及其合作伙伴有效地构建了下一个商务时代所需的信任架构。正如俗话说，"预测未来的最好方法是构建它" —— AP2是对AI代理为我们无缝处理交易的未来的押注，它正在积极构建使那个未来可行所需的信任和规则。

来源：

• 谷歌云博客 – "用新的代理支付协议（AP2）为AI商务提供动力" (2025年9月16日)
• AP2 GitHub文档 – "代理支付协议规范和概述"
• Vellum AI博客 – "谷歌的AP2：AI代理支付的新协议" (分析)
• Medium文章 – "谷歌代理支付协议（AP2）" (Tahir总结，2025年9月)
• AP2合作伙伴引用（谷歌云博客）
• A2A x402扩展 (AP2加密支付扩展) – GitHub README

隐私正在成为公共基础设施。在 2025 年，开发者需要让加密变得如存储数据一样简单的工具。Mysten Labs 的 Seal 正好提供了这样的解决方案——具有链上访问控制的去中心化密钥管理。本教程将教您如何使用基于身份的加密、门限安全和可编程访问策略构建安全的 Web3 应用程序。

简介：为什么 Seal 对 Web3 很重要​

传统的云应用程序依赖于中心化的密钥管理系统，其中单一提供商控制对加密数据的访问。虽然方便，但这创造了危险的单点故障。如果提供商被攻击、离线或决定限制访问，您的数据将变得无法访问或易受攻击。

Seal 完全改变了这种模式。由 Mysten Labs 为 Sui 区块链构建，Seal 是一个去中心化密钥管理（DSM）服务，支持：

• 基于身份的加密，内容在离开您的环境之前就受到保护
• 门限加密，将密钥访问分布在多个独立节点上
• 链上访问控制，具有时间锁、代币门控和自定义授权逻辑
• 存储无关设计，可与 Walrus、IPFS 或任何存储解决方案配合使用

无论您是在构建安全消息应用程序、门控内容平台还是时间锁定资产转移，Seal 都提供了您需要的加密原语和访问控制基础设施。

开始使用​

前提条件​

在深入学习之前，确保您具有：

• 安装了 Node.js 18+
• 对 TypeScript/JavaScript 的基本了解
• 用于测试的 Sui 钱包（如 Sui Wallet）
• 对区块链概念的理解

安装​

通过 npm 安装 Seal SDK：

npm install @mysten/seal

您还需要 Sui SDK 进行区块链交互：

npm install @mysten/sui

项目设置​

创建一个新项目并初始化它：

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

创建一个简单的 TypeScript 配置：

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

核心概念：Seal 的工作原理​

在编写代码之前，让我们了解 Seal 的架构：

1. 基于身份的加密 (IBE)​

与传统的加密方式不同（您加密到公钥），IBE 让您加密到一个身份（如电子邮件地址或 Sui 地址）。接收者只有在能够证明他们控制该身份时才能解密。

2. 门限加密​

Seal 使用 t-of-n 门限方案，而不是信任单个密钥服务器。您可以配置 3-of-5 密钥服务器，这意味着任何 3 个服务器可以合作提供解密密钥，但 2 个或更少的服务器不能。

3. 链上访问控制​

访问策略由 Sui 智能合约强制执行。在密钥服务器提供解密密钥之前，它会验证请求者是否满足链上策略要求（代币所有权、时间约束等）。

4. 密钥服务器网络​

分布式密钥服务器验证访问策略并生成解密密钥。这些服务器由不同的方运营，以确保没有单一控制点。

基本实现：您的第一个 Seal 应用程序​

让我们构建一个简单的应用程序，它加密敏感数据并通过 Sui 区块链策略控制访问。

步骤 1：初始化 Seal 客户端​

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
  // 为测试网初始化 Sui 客户端
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // 使用测试网密钥服务器配置 Seal 客户端
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // 2-of-3 门限
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

步骤 2：简单加密/解密​

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
  const { sealClient } = await createSealClient();

  // 要加密的数据
  const sensitiveData = "这是我的秘密消息！";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // 为特定的 Sui 地址加密数据
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // 可选：添加元数据
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('加密数据：', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // 稍后，解密数据（需要适当的授权）
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('解密数据：', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('加密/解密失败：', error);
  }
}

basicExample();

使用 Sui 智能合约的访问控制​

Seal 的真正威力来自可编程访问控制。让我们创建一个时间锁定加密示例，其中数据只能在特定时间后解密。

步骤 1：部署访问控制合约​

首先，我们需要一个定义访问策略的 Move 智能合约：

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

步骤 2：与 Seal 集成​

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // 在 Sui 上创建访问策略
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // 1分钟后解锁
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: 'time_lock::policy::create_time_lock',
    arguments: [
      txb.pure(unlockTime),
      txb.pure(authorizedUser)
    ]
  });

  // 执行交易创建策略
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // 您的 Sui 密钥对
  });

  const policyId = result.objectChanges?.find(
    change => change.type === 'created'
  )?.objectId;

  // 现在使用此策略加密
  const sensitiveData = "这将在1分钟后解锁！";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, 'utf-8'),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: 'time_lock'
    }
  });

  console.log('时间锁定数据已创建。请在1分钟后尝试解密。');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

实际示例​

示例 1：安全消息应用程序​

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID()
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
      recipientId: recipientAddress,
      metadata: {
        type: 'secure_message',
        sender: senderKeypair.toSuiAddress()
      }
    });

    // 将加密消息存储在去中心化存储（Walrus）上
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // 从存储中检索
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // 使用 Seal 解密
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    return JSON.parse(decryptedData.toString('utf-8'));
  }

  private async storeOnWalrus(data: any) {
    // 与 Walrus 存储的集成
    // 这将把加密数据上传到 Walrus
    // 并返回用于检索的 blob ID
  }

  private async retrieveFromWalrus(blobId: string) {
    // 使用 blob ID 从 Walrus 检索加密数据
  }
}

示例 2：代币门控内容平台​

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any
  ) {
    // 创建 NFT 所有权策略
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // 使用 NFT 访问要求加密内容
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // NFT 持有者的特殊接收者
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // 首先验证 NFT 所有权
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('访问被拒绝：未找到所需的 NFT');
    }

    // 解密内容
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

    return decryptedContent.toString('utf-8');
  }

  private async createNftPolicy(collection: string, creator: any) {
    // 创建检查 NFT 所有权的 Move 合约
    // 返回策略对象 ID
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // 检查用户是否拥有所需的 NFT
    // 查询 Sui 的 NFT 所有权
  }
}

示例 3：时间锁定资产转移​

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any
) {
  const { sealClient, suiClient } = await createSealClient();

  // 在 Sui 上创建时间锁定策略
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // 加密资产转移数据
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID()
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: 'time_lock'
    }
  });

  console.log(`资产锁定至 ${new Date(unlockTimestamp)}`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    const transferData = JSON.parse(decryptedData.toString('utf-8'));

    // 处理资产转移
    console.log('资产转移已解锁：', transferData);

    return transferData;
  } catch (error) {
    console.error('转移尚未解锁或访问被拒绝：', error);
    throw error;
  }
}

与 Walrus 去中心化存储的集成​

Seal 与 Sui 的去中心化存储解决方案 Walrus 无缝协作。以下是如何集成两者：

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any
  ) {
    // 使用 Seal 加密
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy
    });

    // 在 Walrus 上存储加密数据
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // 返回包含 Seal 和 Walrus 信息的引用
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any
  ) {
    // 从 Walrus 检索
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // 使用 Seal 解密
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });

    return decryptedData;
  }
}

// 使用示例
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from('重要文档内容');
  const recipientAddress = '0x...';

  // 存储加密数据
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('已存储，Blob ID：', result.blobId);

  // 稍后，检索并解密
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('检索到的数据：', decrypted.toString());
}

门限加密高级配置​

对于生产应用程序，您需要配置具有多个密钥服务器的自定义门限加密：

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
  // 配置多个独立的密钥服务器
  const keyServers = [
    'https://keyserver-1.your-org.com',
    'https://keyserver-2.partner-org.com',
    'https://keyserver-3.third-party.com',
    'https://keyserver-4.backup-provider.com',
    'https://keyserver-5.fallback.com'
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // 3-of-5 门限
    network: 'mainnet',
    // 高级选项
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      'https://backup-1.emergency.com',
      'https://backup-2.emergency.com'
    ]
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "关键任务加密数据";

  // 以高安全保证进行加密
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // 要求所有5个服务器以获得最大安全性
    customThreshold: 5,
    // 添加冗余
    redundancy: 2,
    accessPolicy: {
      // 多因子要求
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

安全最佳实践​

1. 密钥管理​

// src/security-practices.ts

// 正确：使用安全的密钥派生
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// 正确：安全地存储密钥（使用环境变量的示例）
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// 错误：永远不要硬编码密钥
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // 不要这样做！
);

2. 访问策略验证​

// 在加密前始终验证访问策略
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // 验证接收者地址
  if (!isValidSuiAddress(recipient)) {
    throw new Error('无效的接收者地址');
  }

  // 检查策略是否存在且有效
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('无效的访问策略');
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy
  });
}

3. 错误处理和回退机制​

// 健壮的错误处理
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });
  } catch (error) {
    if (error.code === 'ACCESS_DENIED') {
      throw new Error('访问被拒绝：请检查您的权限');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // 尝试使用备份配置
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('可用的密钥服务器不足');
    } else {
      throw new Error(`解密失败：${error.message}`);
    }
  }
}

4. 数据验证​

// 在加密前验证数据
function validateDataForEncryption(data: Buffer): boolean {
  // 检查大小限制
  if (data.length > 1024 * 1024) { // 1MB 限制
    throw new Error('数据太大，无法加密');
  }

  // 检查敏感模式（可选）
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('警告：数据包含潜在的敏感模式');
  }

  return true;
}

性能优化​

1. 批处理操作​

// 批量多个加密以提高效率
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index]
    })
  );

  return Promise.all(promises);
}

2. 缓存密钥服务器响应​

// 缓存密钥服务器会话以减少延迟
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

测试您的 Seal 集成​

单元测试​

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Seal 集成', () => {
  it('应该成功加密和解密数据', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('测试消息');
    const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient
    });

    expect(decrypted.toString()).toBe('测试消息');
  });

  it('应该强制执行访问控制策略', async () => {
    // 测试未授权用户无法解密
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from('秘密'),
      recipientId: 'authorized-user'
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('访问被拒绝');
  });
});

部署到生产环境​

环境配置​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5
  ],
  threshold: 3,
  network: 'mainnet',
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // 安全设置
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1小时
  retryAttempts: 3
};

监控和日志记录​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] 为 ${recipient} 加密数据 ${encryptionId}`);
    // 发送到您的监控服务
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] 解密 ${encryptionId}：${success ? '成功' : '失败'}`);
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] 密钥服务器 ${serverUrl}：${status}`);
  }
}

资源和后续步骤​

官方文档​

• Seal 文档: https://seal-docs.wal.app/
• GitHub 仓库: https://github.com/MystenLabs/seal
• Sui 文档: https://docs.sui.io/
• Walrus 文档: https://docs.wal.app/

社区和支持​

• Sui Discord: 加入 #seal 频道获得社区支持
• GitHub Issues: 报告错误和请求功能
• 开发者论坛: Sui 社区论坛进行讨论

要探索的高级主题​

1. 自定义访问策略：使用 Move 合约构建复杂的授权逻辑
2. 跨链集成：将 Seal 与其他区块链网络一起使用
3. 企业密钥管理：设置您自己的密钥服务器基础设施
4. 审计和合规：为受监管环境实施日志记录和监控

示例应用程序​

• 安全聊天应用：使用 Seal 的端到端加密消息传递
• 文档管理：具有访问控制的企业文档共享
• 数字版权管理：具有使用策略的内容分发
• 隐私保护分析：加密数据处理工作流

结论​

Seal 代表了朝着使隐私和加密成为 Web3 中基础设施级关注点的根本转变。通过结合基于身份的加密、门限安全和可编程访问控制，它为开发者提供了构建真正安全和去中心化应用程序的强大工具。

使用 Seal 构建的主要优势包括：

• 无单点故障：分布式密钥服务器消除了中央权威
• 可编程安全：基于智能合约的访问策略提供灵活的授权
• 开发者友好：TypeScript SDK 与现有的 Web3 工具无缝集成
• 存储无关：与 Walrus、IPFS 或任何存储解决方案配合使用
• 生产就绪：由 Mysten Labs 构建，具有企业安全标准

无论您是在保护用户数据、实施订阅模型还是构建复杂的多方应用程序，Seal 都提供了您需要的加密原语和访问控制基础设施，让您可以放心地构建。

今天就开始构建，加入越来越多的开发者生态系统，让隐私成为公共基础设施的基本组成部分。

准备开始构建了吗？ 安装 @mysten/seal 并开始尝试本教程中的示例。去中心化网络正在等待将隐私和安全放在首位的应用程序。

推出协议或扩展一款链上产品，已经不再是单纯的技术问题。监管机构密切关注从代币发行到钱包隐私的每个环节，用户也期待达到消费级的安全保障。若想持续安心地构建，创始团队必须把复杂的法律备忘录转化为明确的产品决策。基于 Web3 律师最常遇到的 50 个问题，这份手册将要点拆解为建设者可以立即执行的动作。

1. 组织与治理：拆分开发公司、基金会与社区​

• 选择合适的法律载体。 传统 C-corp 或 LLC 仍然最适合处理薪酬、知识产权与投资人尽调。若要运营协议或社区资助项目，独立的非营利机构或基金会能保持激励清晰、治理透明。
• 把所有关系写进合同。 使用知识产权转让、保密协议，以及带有悬崖期、锁仓和恶意行为追回条款的归属计划。记录董事会批准，并像管理股权一样严密维护代币台账。
• 明确不同实体的边界。 开发公司可以按许可进行建设，但预算、金库政策与决策权应交由拥有章程和宪章的基金会或 DAO。若 DAO 需要法律主体，可使用 LLC 等包装。

2. 代币与证券：围绕使用价值设计，并保存决策依据​

• 假设监管会透过标签看本质。 “治理”或“功能型”标签只有在用户真正使用上线网络、出于消费动机购买且未被承诺收益时才有帮助。锁仓能减轻投机，却应记录其作为稳定性或反女巫措施的理由。
• 区分使用权与投资工具。 功能型代币应像产品通行证——价格、文档与营销都必须突出服务使用权，而非未来利润。稳定币则因储备与赎回权不同，可能触发支付或电子货币监管。
• 将质押与收益视作金融产品。 宣传年化收益、资金池或依赖团队努力，都会提高被视为证券的风险。保持营销用语朴素，披露风险因素；若通过 SAFT 募资，务必规划一条合规的主网发行路径。
• 记住 NFT 也可能被认定为证券。 分割、收益共享或强调盈利预期都会让风险上升。用途明确、附带清晰授权的消费型 NFT 风险更低。

3. 融资与销售：宣传网络价值，而非投机故事​

• 像成熟企业一样披露信息。 销售文件中要包含目的、功能、归属安排、分配、转让限制、依赖关系与资金用途。营销文案必须与之保持一致——杜绝“保本保息”类表述。
• 尊重各司法辖区的界限。 若无法满足美国等高风险市场的要求，就结合地理屏蔽、资格审查、合同限制与售后监测。KYC/AML 已是销售标配，在空投场景中也日益常见。
• 管控宣传风险。 网红推广须清晰披露合作关系并使用合规话术。交易所上币或做市协议需要书面合同、冲突审查，以及与平台的真实沟通。

4. 反洗钱、税务与知识产权：把控制点融入产品​

• 搞清自己的监管身份。 非托管软件通常 AML 负担较轻，但一旦涉及法币出入口、托管或撮合交易，就可能落入货币传输或虚拟资产服务提供商（VASP）监管。提前准备制裁筛查、升级流程，并在适用时做好旅行规则准备。
• 在会计上把代币视作现金。 收到代币通常按公允价值入账，后续处置会产生损益。向员工或外包发放代币多数在归属时计税——务必签订书面协议，跟踪成本基础，并为波动做好准备。
• 尊重知识产权边界。 为 NFT 与链上内容配套明确授权条款，遵守第三方开源协议，并注册商标。若训练 AI 模型，确认数据许可并剔除敏感信息。

5. 隐私与数据：少收集，做好删除方案​

• 默认钱包地址也是个人数据。 一旦与 IP、设备 ID 或邮箱关联，就构成可识别信息。仅收集必要数据，尽量放在链下，并采用哈希或代币化处理。
• 面向删除权设计。 链上不可篡改并不意味着可以无视隐私法规：避免把 PII 写入链上，接到删除请求时移除引用，并切断可重新识别哈希数据的关联。
• 公开透明地说明遥测。 Cookie 横幅、分析工具披露与退出选项都是基本要求。制定事件响应计划，明确严重级别、通知时限与联络人。

6. 运营与风险：尽早审计，持续沟通​

• 进行审计并主动披露。 独立的智能合约审计、必要时的形式化验证以及持续的漏洞赏金都是成熟度的标志。发布报告，坦诚说明剩余风险。
• 制定清晰的服务条款。 明确托管状态、适用资格、禁止用途、争议解决机制以及分叉处理方式。确保 ToS、隐私政策与产品行为一致。
• 提前规划分叉、保险与全球化。 保留选择支持链、快照时间与迁移路径的权利。评估网络安全、犯罪、董事与高级职员（D&O）及技术差错与疏漏（Tech E&O）等保险。面向全球运营时，做好条款本地化、出口管制审查，并通过 EOR/PEO 合作伙伴避免用工误分类。
• 为争议做好准备。 事先决定是否采用仲裁或集体诉讼弃权条款。记录执法机构的请求，核查法律程序，并解释诸如不掌握用户私钥等技术限制。

7. 建设者行动清单​

• 梳理自身角色：软件提供方、托管方、类经纪服务还是支付中介。
• 让市场宣传只描述事实与功能，避免暗示投机性收益。
• 尽量减少托管与个人数据采集，并记录不可避免的接触点。
• 持续更新代币分配、治理设计、审计状态与风险决策等文档。
• 从第一天起就为法律顾问、合规工具、审计、漏洞赏金和税务专家编列预算。

8. 让法律建议转化为产品速度​

监管不会为建设者放慢脚步。真正改变结局的是，把法律考量融入需求优先级排序、金库管理与用户沟通之中。让法务参与冲刺评审，演练事件响应，并像迭代 UX 一样迭代披露文本。做到这些，以上 50 个常见问题就不再是阻碍，而会成为协议的竞争护城河。

大多数应用仍然将身份绑定到用户名、密码和中心化数据库。这种模型脆弱（泄露）、易泄漏（数据转售）且笨拙（无尽的 KYC 重复）。围绕去中心化标识符（DID）、可验证凭证（VC）和声明的新技术栈指向了不同的未来：用户携带关于自己的加密证明，只披露必要的信息——不多也不少。

本文提炼了全景，并提供了一个可以今天就交付的实用蓝图。

转变：从账户到凭证​

这套新身份栈的核心建立在两个基础性的 W3C 标准之上，彻底改变了我们处理用户数据的方式。

• 去中心化标识符（DIDs）： 由用户自行控制的标识符，无需像域名系统那样的中心化注册表。可以把 DID 看作是永久的、自己拥有的身份地址。DID 解析为签名的 “DID 文档”，其中包含公钥和服务端点，实现安全的去中心化认证。v1.0 标准于 2022 年 7 月 19 日 成为正式的 W3C 推荐稿，标志着生态系统的重要里程碑。
• 可验证凭证（VCs）： 一种防篡改的数字格式，用于表达诸如 “年龄超过 18 岁”、 “拥有 X 大学的文凭” 或 “已通过 KYC 检查” 等声明。VC 数据模型 2.0 于 2025 年 5 月 15 日 成为 W3C 推荐稿，为凭证的发行与验证奠定了现代化基础。

对开发者有什么变化？ 影响深远。你不再把敏感的个人可识别信息（PII）存入数据库，而是验证用户钱包提供的加密证明。得益于 选择性披露 等强大原语，你可以仅请求所需的特定信息（例如特定国家的居住权），而无需看到完整文档。

与现有登录方式的结合​

这新世界并不要求抛弃熟悉的登录体验，而是对其进行补充。

• Passkeys / WebAuthn： 防钓鱼的首选认证方式。Passkey 是绑定到设备或生物特征（如 Face ID、指纹）的 FIDO 凭证，已在所有主流浏览器和操作系统上得到广泛支持，为你的应用或钱包提供无缝的无密码登录体验。
• Sign‑In with Ethereum（SIWE / EIP‑4361）： 该标准让用户证明对区块链地址的控制权，并将其关联到应用会话。通过签名的一次性 nonce 消息，实现 Web2 会话与 Web3 控制的清晰桥接。

最佳实践是将两者结合使用：对主流、日常登录实现 Passkeys，在需要钱包关联的场景提供 SIWE，以完成加密原生操作的授权。

发放与校验凭证的基础设施​

要让凭证发挥作用，需要标准化的发放和呈现方式。OpenID 基金会提供了两大关键协议。

• 发放：OpenID for Verifiable Credential Issuance（OID4VCI） 定义了受 OAuth 保护的 API，帮助将凭证从发行方（如政府机构或 KYC 提供商）导入用户的数字钱包，兼容多种凭证格式。
• 呈现：OpenID for Verifiable Presentations（OID4VP） 标准化了应用发起 “证明请求” 与用户钱包响应的交互，可通过传统的 OAuth 重定向或现代浏览器 API 完成。

在实现时，你会遇到几种针对不同生态和使用场景设计的凭证格式：

• W3C VC + Data Integrity Suites（JSON‑LD）： 常配合 BBS+ 加密，实现强大的选择性披露。
• VC‑JOSE‑COSE 与 SD‑JWT VC（IETF）： 基于 JWT 与 CBOR 的生态，同样具备选择性披露能力。

幸运的是，互操作性正在快速提升。OpenID4VC High Assurance 等配置文件正帮助缩减技术选项，使跨供应商集成对开发者更友好。

DID 方法：选择合适的地址方案​

DID 本身只是标识符；“DID 方法”决定了它如何锚定到信任根。建议支持以下常见方法：

• did:web： 通过你控制的域名实现 DID，部署极其简便，是企业、发行方以及希望利用现有 Web 基础设施作为信任锚的组织的理想选择。
• did:pkh： 直接从区块链地址（例如以太坊地址）派生 DID，适用于已有加密钱包的用户，可将身份与链上资产关联。

经验法则： 至少支持两种方法——did:web 用于组织，did:pkh 用于个人。使用标准的 DID 解析库处理查询，并参考官方注册表评估任何新方法的安全性、持久性和治理模型。

可直接使用的构建块​

核心标准之外，还有若干工具可以增强你的身份栈。

• ENS（以太坊名称服务）： 提供可读的名称（如 yourname.eth），可映射到区块链地址和 DID，极大提升用户体验，降低错误率，并提供简易的个人资料层。
• 声明（Attestations）： 灵活的、可验证的 “关于任何事物的事实”，可记录在链上或链下。例如 Ethereum Attestation Service（EAS） 为构建声誉与信任图提供了坚实底座，且无需在公共账本上存储 PII。

合规风向标​

监管常被视为障碍，但在本领域却是强大的加速器。欧盟数字身份框架（eIDAS 2.0） 已于 2024 年 5 月 20 日 正式通过，作为 EU 2024/1183 法规生效，要求所有欧盟成员国为公民提供免费 EU Digital Identity Wallet（EUDI）。实施细则于 2025 年 5 月 7 日 发布，这对公共和私营部门在欧洲采用基于钱包的凭证形成了强有力的信号。

即便你不在欧盟运营，也应预期 EUDI 钱包及其底层协议将塑造全球用户期待，推动钱包普及。

2025 年可落地的设计模式​

• 无密码优先，钱包可选： 默认使用 Passkeys 登录，安全、简洁且用户熟悉。仅在用户需要执行加密关联操作（如铸造 NFT、收款）时引入 SIWE。
• 请求证明而非文档： 用 OID4VP 发起简洁的 VC 证明请求，替代繁琐的文件上传。例如不要求驾驶证原件，而是请求 “年龄超过 18 岁” 或 “居住国为 X”。接受支持选择性披露的凭证，如 BBS+ 或 SD‑JWT。
• 服务器不存 PII： 当用户完成验证后，仅记录 声明 或短期验证结果，而非原始凭证本身。链上声明可提供可审计的记录——“用户 Y 于日期 D 通过发行方 Z 的 KYC”，而无需保存任何个人数据。
• 组织使用 did:web 成为发行方： 企业、大学等已有域名的组织可使用 did:web 作为发行方标识，凭借现有的 Web 治理模型管理密钥。
• ENS 用作昵称而非身份根基： 将 ENS 视为友好的句柄与个人资料指针，提升 UX，但真正的身份声明仍保存在凭证与声明中。

入门架构示例​

下面是一套现代化、基于凭证的身份系统蓝图：

• 认证层
  • 默认登录： Passkeys（FIDO/WebAuthn）。
  • 加密关联会话： Sign‑In with Ethereum（SIWE）用于钱包操作。
• 凭证层
  • 发放： 集成选定发行方的 OID4VCI 接口（如 KYC 提供商、大学）。
  • 呈现： 在 Web 或原生 App 中触发 OID4VP 证明请求，兼容 W3C VC（BBS+）和 SD‑JWT VC。
• 解析与信任层
  • DID 解析器： 使用支持 did:web 与 did:pkh 的库，并维护可信发行方 DID 白名单，防止伪造。
• 声明与声誉层
  • 持久记录： 需要审计的验证信号时，铸造包含哈希、发行方 DID 与时间戳的 声明，而非存储完整凭证。
• 存储与隐私层
  • 最小化原则： 服务器端仅存储必要的元数据，全部加密并设定严格的 TTL。优先使用瞬时证明，借助零知识或选择性披露降低数据泄露风险。

UX 经验教训​

• 先让钱包“隐形”： 对大多数用户而言，最佳钱包是他们根本不需要感知的。使用 Passkeys 完成登录，只有在业务必需时才弹出钱包交互。
• 渐进式披露： 不要一次性请求全部信息。仅请求能解锁当前目标的最小证明。选择性披露让你无需完整文档即可验证单一事实。
• 密钥恢复至关重要： 单设备绑定的凭证风险极大。务必从第一天就规划重新发行与跨设备迁移，这也是现代配置文件倾向采用 SD‑JWT VC 与基于声明的持有者绑定的原因。
• 可读句柄提升体验： ENS 名称远比长串十六进制地址友好，能显著降低用户错误，即使真正的权威仍在凭证与声明中。

下季度交付路线图（务实版）​

• 第 1‑2 周：
  • 为主登录流程加入 Passkeys。
  • 将所有加密原生操作置于 SIWE 检查之后。
• 第 3‑6 周：
  • 试点一个简单的 “年龄或地区门禁”，使用 OID4VP 请求。
  • 接收 VC 2.0 并支持选择性披露（BBS+ 或 SD‑JWT VC）。
  • 开始为 “验证通过” 事件生成 声明，而非记录 PII。
• 第 7‑10 周：
  • 引入合作发行方（如你的 KYC 提供商），使用 did:web 并实现 DID 白名单。
  • 在用户资料中加入 ENS 名称绑定，提升地址可读性。
• 第 11‑12 周：
  • 对呈现与撤销流程进行威胁模型分析。加入常见失败（凭证过期、发行方不可信）监控。
  • 发布明确的 隐私声明，说明收集内容、保留时长以及用户审计方式。

快速变化的关注点​

• 欧盟 EUDI 钱包 rollout： 实施与合规测试将极大影响全球的验证体验与能力。
• OpenID4VC 配置文件： 发行方、钱包与验证方之间的互操作性正因新配置文件与测试套件而持续提升。
• 选择性披露密码套件： BBS+ 与 SD‑JWT VC 的库与开发者指南正快速成熟，落地实现难度大幅下降。

构建原则​

• 证明优先，数据后置： 先验证加密证明，再决定是否需要持久化任何信息。
• 最小化收集： 只收集业务绝对必需的数据。
• 去中心化信任： 通过 DID 方法与声明构建可审计的信任链。
• 互操作优先： 采用已被广泛支持的标准与配置文件，降低供应商锁定风险。

坚持这些原则，你将在安全、合规且用户友好的数字身份领域保持竞争优势。

公有链为所有参与者提供同步且可审计的账本，但默认暴露所有数据。2025 年 9 月 3 日正式登陆 Sui 主网的 Seal，通过将链上策略逻辑与去中心化密钥管理结合，让 Web3 构建者能够精确控制谁能解密哪些载荷。

摘要​

• 产品定位： Seal 是一个秘密管理网络，使 Sui 智能合约可以在链上强制执行解密策略，同时客户端使用基于身份的加密（IBE）保护数据，并依赖阈值密钥服务器派生密钥。
• 价值所在： 无需自建后端或依赖不透明的链下脚本，隐私与访问控制直接成为 Move 的一等公民。开发者可以将密文存储在任意位置（Walrus 是理想搭档），并持续控制读取权限。
• 适用人群： 推出代币门控内容、定时解锁、私密消息或遵循策略的 AI 代理的团队，可以接入 Seal SDK，将精力集中在产品逻辑而非复杂的密码基础设施上。

策略逻辑写在 Move 里​

Seal 包含 seal_approve* Move 函数，用于定义某个身份字符串在何种条件下、由谁请求密钥。策略可以组合 NFT 持有、白名单、时间锁或自定义角色体系。用户或代理发起解密请求时，密钥服务器会通过 Sui 全节点状态评估策略，仅在链上判断通过时才会批准。

由于访问规则属于你的链上包的一部分，因此它们是透明、可审计的，并可以与其他智能合约代码一起进行版本管理。治理更新也能像其他 Move 升级一样发布，具备社区审查和链上历史。

阈值密码学负责密钥管理​

Seal 按照应用自定义的身份来加密数据。由开发者挑选的独立密钥服务器委员会共享 IBE 主密钥。当策略校验通过后，各服务器会为请求的身份导出密钥份额。当 t 台服务器响应后，客户端就能组合出可用的解密密钥。

你可以通过选择委员会成员（Ruby Nodes、NodeInfra、Overclock、Studio Mirai、H2O Nodes、Triton One 或 Mysten 的 Enoki 服务）以及设置阈值，在活性与机密性之间做权衡。想要更强的可用性？选择更大的委员会和更低的阈值。需要更高的隐私保障？提高法定人数，更多使用许可制服务商。

开发者体验：SDK 与会话密钥​

Seal 提供 TypeScript SDK（npm i @mysten/seal），负责加解密流程、身份格式化与批量请求处理，还可以签发会话密钥，避免应用频繁访问时钱包不断弹窗。对于高级场景，Move 合约可以通过特殊模式请求链上解密，使得托管释放或抗 MEV 拍卖等逻辑能够直接在合约中执行。

Seal 与存储层无关，因此团队可以将其与 Walrus 组合实现可验证的 Blob 存储，或根据运营需求使用 IPFS 甚至中心化存储。无论密文存在哪里，加密边界及其策略执行都会伴随数据移动。

使用 Seal 的最佳实践​

• 建模可用性风险： 2-of-3 或 3-of-5 等阈值直接映射为可用性保障。生产部署应混合不同服务商、监测遥测数据，并在托管关键流程前签订 SLA。
• 注意状态差异： 策略评估依赖全节点执行 dry_run 调用。避免依赖快速变化计数器或同一检查点内排序的规则，以免服务器之间出现临时不一致的审批结果。
• 规划密钥卫生： 派生密钥保存在客户端。请做好日志、轮换会话密钥，并考虑包裹加密——用 Seal 保护加密大载荷的对称密钥——以减小设备泄露时的影响范围。
• 为轮换做设计： 某次加密所使用的委员会在加密时就已固定。需要替换服务商或调整信任假设时，请预留通过重新加密迁移到新委员会的升级路径。

未来展望​

Seal 的路线图包括验证者运营的 MPC 服务器、类似 DRM 的客户端工具以及抗量子 KEM 选项。对于正在探索 AI 代理、高价值内容或受监管数据流的团队而言，本次发布已经给出了清晰蓝图：在 Move 中编写策略，组合多元化的密钥委员会，并在 Sui 的信任边界内交付尊重用户隐私的加密体验。

如果你打算在下一次发布中采用 Seal，可先用 2-of-3 的开放式委员会和简单的 NFT 门控策略做原型，然后迭代出与应用风险画像匹配的服务商组合与运营控制。

TL;DR​

跨链抽象将链、桥梁和钱包的迷宫转变为开发者和终端用户都能使用的单一、连贯的平台体验。生态系统已悄然成熟：意图标准、账户抽象、原生稳定币流动性，以及 OP Superchain 和 Polygon 的 AggLayer 等网络层倡议，使得“多链单体验”在 2025 年成为现实。对于企业而言，收益是务实的：更简化的集成、可强制执行的风险控制、确定性的操作以及合规就绪的可审计性——无需在单一链上押注全部资源。

企业真正面临的问题（以及为何仅靠桥梁无法解决）​

大多数企业团队并不想“挑选链”。他们关注的是结果：结算付款、发行资产、清算交易或更新记录——可靠、可审计且成本可预测。问题在于，当前的生产级 Web3 注定是多链的。仅在过去 18 个月内，就已上线数百个 rollup、应用链和 L2，每个都有各自的费用、最终性时间、工具链和信任假设。

传统的跨链方法解决了传输——即从 A 到 B 的代币或消息转移——但未解决体验。团队仍需为每个网络管理钱包、为每条链预留 gas、为每条路径挑选桥梁，并承担难以量化的安全差异。这种摩擦才是真正的采纳成本。

跨链抽象通过在声明式 API、意图驱动的用户体验以及统一的身份和 gas 之上隐藏链选择和传输，从而消除上述成本。换句话说，用户和应用只需表达想要做什么；平台安全地决定如何以及在哪里实现。链抽象让终端用户感受不到区块链技术的存在，却保留其核心优势。

为什么 2025 年不同：构建块终于契合​

无缝多链世界的愿景并不新鲜，但基础技术终于准备好投入生产。多个关键组件已成熟并汇聚，使得强大的链抽象成为可能。

• 网络层统一: 项目现在正在构建框架，使得不同链感觉像单一、统一的网络。OP Superchain 旨在通过共享工具链和通信层标准化 OP-Stack L2。Polygon 的 AggLayer 将众多 ZK 安全链聚合，并使用“悲观证明”进行链级会计，防止单链问题污染其他链。同时，IBC v2 正在将标准化的互操作性扩展到 Cosmos 生态系统之外，推动“IBC 随处可用”。

• 成熟的互操作通道: 跨链通信的中间件现已经过实战检验并广泛可用。Chainlink CCIP 提供企业级代币和数据跨链转移，覆盖日益增多的链。LayerZero v2 提供全链消息和标准化的 OFT 代币，拥有统一供应。Axelar 提供通用消息传递（GMP），支持跨生态系统的复杂合约调用，连接 EVM 与 Cosmos 链。Hyperlane 等平台实现了无许可部署，允许新链加入网络而无需门禁，Wormhole 则提供了跨越 40 多条链的通用消息层。

• 意图与账户抽象: 两项关键标准彻底改变了用户体验。ERC-7683 标准化跨链意图，允许应用声明目标，由共享求解网络在多链上高效执行。与此同时，EIP-4337 智能账户结合 Paymaster 实现gas 抽象。这使得应用可以赞助交易费用，或让用户使用稳定币支付，这对于可能涉及多个网络的任何流程都是必需的。

• 原生稳定币流动性: Circle 的跨链转移协议（CCTP）通过安全的燃烧‑铸造过程在链间移动原生 USDC，降低了包装资产风险并统一流动性。最新的 CCTP v2 进一步降低延迟并简化开发者工作流，使得稳定币结算成为抽象体验的无缝组成部分。

“跨链抽象”在企业技术栈中的表现​

可以将其视为可叠加在现有系统上的分层能力。目标是拥有一个单一的端点来表达意图，以及一个统一的策略层来管理其在任意数量链上的执行方式。

1. 统一身份与策略: 顶层是智能账户（EIP-4337），具备基于角色的访问控制、社交恢复以及如 Passkey 或 MPC 等现代托管选项。由中心化策略引擎治理，定义谁可以在何处执行何种操作，使用针对特定链、资产和桥梁的允许/拒绝列表。

2. Gas 与费用抽象: Paymaster 消除“我需要在链 X 上拥有原生 gas”的痛点。用户或服务可以用稳定币支付费用，或由应用全额赞助，均受预定义策略和预算约束。

3. 意图驱动执行: 用户表达结果，而非交易。例如，“将 USDC 兑换为 wETH 并在链 Y 上的供应商钱包中于下午 5 点前交付”。ERC-7683 标准定义了此类订单的格式，允许共享求解网络竞争安全且低成本地执行。

4. 可编程结算与消息: 在底层，系统使用统一 API 为每条路径选择合适的通道。可能使用 CCIP 进行代币转移（企业支持为关键），使用 Axelar GMP 进行跨生态系统合约调用，或在风险模型适配时使用 IBC 的轻客户端安全。

5. 默认可观测性与合规性: 整个工作流可追溯，从最初的意图到最终结算。生成清晰的审计日志，可导出至现有 SIEM。风险框架可编程以执行允许列表或触发紧急刹车，例如在桥梁安全姿态下降时暂停路径。

参考架构​

从上至下，链抽象系统由以下清晰层次构成：

• 体验层: 收集用户意图并完全隐藏链细节的应用界面，配合 SSO 式的智能账户钱包流程。

• 控制平面: 用于管理权限、配额和预算的策略引擎。该平面与 KMS/HSM 系统集成，维护链、资产和桥梁的允许列表，并摄取风险信息以自动断路脆弱路径。

• 执行层: 意图路由器根据策略、价格和延迟要求选择最佳互操作通道（CCIP、LayerZero、Axelar 等）。Paymaster 负责费用，从聚合的 gas 与稳定币预算金库中提取。

• 结算与状态: 用于托管和发行等核心功能的规范链上合约。统一索引器跟踪跨链事件和证明，并将数据导出至数据仓库或 SIEM 进行分析和合规。

自建还是采购：如何评估链抽象供应商​

在选择合作伙伴提供链抽象能力时，企业应提出若干关键问题：

• 安全与信任模型: 基础的验证假设是什么？系统依赖预言机、守护集合、轻客户端还是验证者网络？哪些可以被削减或否决？

• 覆盖范围与中立性: 当前支持哪些链和资产？新链能多快加入？过程是无许可的还是由供应商把关？

• 标准对齐: 平台是否支持关键标准，如 ERC-7683、EIP-4337、OFT、IBC 和 CCIP？

• 运营: 供应商的 SLA 是什么？他们对事件的透明度如何？是否提供可重放的证明、确定性重试和结构化审计日志？

• 治理与可移植性: 是否可以在不重写应用的情况下为不同路径切换互操作通道？供应商中立的抽象对长期灵活性至关重要。

• 合规性: 提供哪些数据保留和驻留控制？其 SOC2/ISO 状态如何？是否支持自带 KMS/HSM？

实用的 90 天企业部署计划​

• 第 0–15 天：基线与策略: 清点当前使用的链、资产、桥梁和钱包。定义初始允许列表，并基于明确的风险框架建立断路规则。

• 第 16–45 天：原型: 将单一用户旅程（如跨链支付）转换为基于意图的流程，使用账户抽象和 Paymaster。衡量对用户流失、延迟和支持负载的影响。

• 第 46–75 天：扩展通道: 为系统添加第二条互操作通道，并根据策略动态路由交易。如工作流涉及稳定币，集成 CCTP 实现原生 USDC 流动。

• 第 76–90 天：加固: 将平台的可观测数据接入 SIEM，进行路由故障混沌测试，并记录所有操作流程，包括紧急暂停协议。

常见陷阱（以及如何避免）​

• 仅依据“Gas 价格”路由: 延迟、最终性和安全假设与费用同等重要。仅凭价格无法构成完整的风险模型。

• 忽视 Gas: 如果体验跨越多条链，gas 抽象不是可选项——它是可用产品的基本前提。

• 将桥梁视为可互换: 实际并非如此。它们的安全假设差异显著。应将允许列表编码并实现断路器以管理风险。

• 包装资产蔓延: 尽可能使用原生资产流动性（如通过 CCTP 的 USDC），以最小化流动性碎片化并降低对手风险。

企业收益​

当链抽象实现得当时，区块链不再是零散的异构网络，而是团队可以编程调用的执行框架。它提供符合现有运营标准的策略、SLA 和审计追踪。得益于成熟的意图标准、账户抽象、稳健的互操作通道以及原生稳定币传输，你终于可以交付 Web3 结果，而无需让用户或内部开发者关心具体是哪条链完成了工作。

Alchemy 是 Web3 基础设施领域的主导力量，为数千名开发者以及 OpenSea 等大型项目提供入口。通过分析 G2、Reddit、GitHub 等平台的公开用户反馈，我们可以清晰地了解开发者看重的内容、他们的痛点以及未来 Web3 开发体验的可能形态。这不仅仅是单一供应商的情况，更是整个生态系统成熟需求的映射。

用户始终喜爱的方面​

在各类评价站点和论坛中，用户始终称赞 Alchemy 的若干关键优势，这些优势巩固了其市场地位。

• 轻松的“上手”与易用性： 初学者和小团队赞赏其快速启动的体验。G2 评论常将其称为“构建 Web3 的绝佳平台”，赞扬其简易的配置和完整的文档。它成功地抽象掉了运行节点的复杂性。
• 集中式仪表盘与工具链： 开发者重视拥有一个统一的“指挥中心”来进行可观测性管理。能够在同一仪表盘中监控请求日志、查看分析、设置告警以及轮换 API 密钥，是一次显著的用户体验提升。
• 智能的 SDK 默认设置： Alchemy SDK 默认处理请求重试和指数退避。这一小而关键的特性帮助开发者免去编写样板代码的负担，降低了构建弹性应用的摩擦。
• 强大的支持声誉： 在区块链开发常常错综复杂的环境中，响应迅速的技术支持是重要的差异化因素。TrustRadius 等聚合评价站点频繁提到 Alchemy 的帮助团队是关键优势。
• 社会认同与信任： 通过展示与 OpenSea 等巨头的案例研究以及获得强有力的合作伙伴背书，Alchemy 为选择托管 RPC 提供商的团队提供了可靠的信心。

主要痛点​

尽管优势明显，开发者在扩展应用时仍会遇到反复出现的挑战。这些痛点揭示了改进的关键机会。

• 吞吐量限制的“隐形墙”： 最常见的挫败感是遭遇 429 Too Many Requests 错误。开发者在对主网进行分叉测试、批量部署或同时服务少量用户时会触发此类错误。尤其在付费层级中，这会让用户在关键流量高峰时感到被限流，导致 CI/CD 流水线中断、测试不稳定，迫使开发者手动实现 sleep 或退避逻辑。
• 并发能力感知不足： 在 Reddit 等论坛上，常有低层级套餐只能容纳少量并发用户的说法。无论这种说法是否完全准确，或取决于工作负载，都会促使团队考虑更复杂的多供应商方案或提前升级。
• 重查询超时： 高强度的 JSON‑RPC 调用，尤其是 eth_getLogs，容易导致超时或 500 错误。这不仅破坏客户端体验，还会使本地开发工具（如 Foundry、Anvil）崩溃，造成生产力损失。
• SDK 与供应商混淆： 新手常在了解节点供应商的职责范围时遇到学习曲线。例如，Stack Overflow 上的问题显示在 eth_sendTransaction 失败时，开发者未意识到 Alchemy 并不持有私钥。API 密钥或 URL 配置错误导致的不透明错误，也给新手设置了障碍。
• 数据隐私与中心化担忧： 部分开发者倾向于自托管或隐私导向的 RPC，担心大型中心化供应商记录 IP 并可能审查交易，强调信任与透明度的重要性。
• 产品广度与路线图： G2 上的对比评价有时指出竞争对手在新生态系统的扩展速度更快，或 Alchemy “专注于少数链”。这会导致在非 EVM 链上构建的团队产生期望错位。

开发者期望破裂的节点​

这些痛点往往在开发生命周期的可预见阶段显现：

1. 原型 → Testnet： 项目在开发者本地机器上运行良好，却在 CI/CD 环境并行测试时因吞吐量限制而失败。
2. 本地分叉： 使用 Hardhat 或 Foundry 对主网进行分叉以实现真实测试的开发者，往往是首批报告 429 错误和大数据查询超时的用户。
3. NFT / 数据 API 大规模使用： 大规模 NFT 铸造或加载大型集合数据很容易触及默认速率限制，迫使开发者寻找缓存与批处理的最佳实践。

核心“待完成工作”解析​

从反馈中提炼出 Web3 开发者的三大根本需求：

• “给我一块统一的玻璃面板来观察和调试。” 该需求由 Alchemy 的仪表盘很好地满足。
• “让我的突发工作负载可预测且易于管理。” 开发者接受限额，但需要更平滑的峰值处理、更好的默认配置以及开箱即用的代码脚手架。
• “在故障期间帮助我保持不被卡住。” 当出现问题时，开发者需要明确的状态更新、可操作的事后报告以及易于实现的容灾模式。

改善开发者体验的可操作机会​

基于上述分析，任何基础设施提供商都可以通过以下方式提升产品：

• 主动式“吞吐量教练”： 在仪表盘或 CLI 中提供模拟计划工作负载的工具，预测何时会触及 CU/s（每秒计算单元）限制，并自动生成针对 ethers.js、viem、Hardhat、Foundry 等流行库的正确重试/退避代码片段。
• 黄金路径模板： 为常见痛点提供即用的生产级模板，例如针对主网分叉的保守并发配置的 Hardhat 网络配置，或高效分页批量调用 eth_getLogs 的示例代码。
• 自适应突发容量： 在付费层级提供“突发积分”或弹性容量模型，以更好地处理短期流量峰值，直接缓解被“不必要限制”的感受。
• 官方多供应商容灾指南： 承认弹性 dApp 会使用多个 RPC，提供有主见的容灾配方和示例代码，帮助开发者快速切换至备份供应商，提升信任度并贴合真实最佳实践。
• 极致透明度： 通过清晰、易获取的文档直接回应隐私与审查担忧，说明数据保留策略、记录内容以及任何过滤机制。
• 可操作的故障报告： 超越单纯的状态页，在故障发生时（如 2025 年 8 月 5‑6 日 EU 区域延迟）附上简短的根因分析（RCA）和具体建议，例如“当前可采取的缓解措施”。

结论：Web3 基础设施的路线图​

对 Alchemy 的用户反馈为整个 Web3 基础设施领域提供了宝贵的路线图。平台在简化入门体验方面表现出色，但用户在扩展性、可预测性和透明度方面的挑战指向了开发者体验的下一个前沿。

随着行业的成熟，胜出的平台将是那些不仅提供可靠接入，还能通过工具与指引帮助开发者从第一天起就构建弹性、可扩展且值得信赖的应用的供应商。

QuickNode 作为 Web3 基础设施领域的中流砥柱，以其高速和广泛的多链支持受到赞誉。为了了解它为何成为众多开发者的首选，以及哪些方面仍有提升空间，我们综合了来自 G2、Reddit、Product Hunt 和 Trustpilot 等平台的大量公开用户反馈。

分析揭示了一个清晰的故事：虽然开发者热爱其核心产品，但在成本方面仍面临不少阻力。

高光：用户喜爱的 QuickNode 特点​

整体来看，用户因 QuickNode 的三大核心优势而称赞它提供了高品质、无摩擦的开发者体验。

🚀 极速性能 & 稳定可靠​

这是 QuickNode 最受好评的特性。用户一致描述该服务为 “极速” 且 “最具性能和可靠性的 RPC 提供商”。 低于 100 ms 的延迟响应以及声称的 99.99% 正常运行时间，让开发者有信心构建并扩展响应迅速的 dApp。

正如 Nansen 的一位企业客户所言，QuickNode 提供 “强大、低延迟、高性能的节点”， 能够处理数十亿请求。这种性能不仅是数字，更是确保终端用户体验流畅的关键特性。

✅ 轻松上手 & 直观 UI​

开发者常常 “几分钟内即可启动”。平台因其简洁的仪表盘和直观的工作流而受到赞誉，这些设计抽象掉了运行节点的复杂性。

Reddit 上的一位开发者称界面为 “不费脑筋”， 而一位全栈开发者强调 “注册并部署节点只需几分钟，无需任何复杂的 DevOps 工作”。 这种易用性使 QuickNode 成为快速原型和测试的宝贵工具。

🤝 顶级客服 & 完备文档​

卓越的客服和文档是始终如一的主题。支持团队被描述为 “响应迅速且真诚有帮助”， 在处理时间敏感的问题时尤为重要。

API 文档因其清晰、详尽且适合初学者而获得普遍好评，有用户称教程 “制作精良”。 对开发者资源的投入显著降低了入门门槛，减少了集成摩擦。

痛点：用户面临的挑战​

尽管性能和体验出色，用户反馈中仍出现两大摩擦点，主要集中在成本和功能限制上。

💸 定价困境​

定价是最常被提及且情绪化的批评点。反馈呈现出两类用户的不同感受：

• 企业用户 认为费用与高性能和可靠性相匹配，属于合理投入。
• 初创公司和独立开发者 则觉得模式成本过高，难以承受。

核心问题包括：

1. 层级跳跃过大： 用户指出 “从 49 美元的 ‘Build’ 计划跳到 249 美元的 ‘Accelerate’ 计划幅度显著”， 希望有更适合成长项目的中间层级。
2. 惩罚性超额费用： 这是最痛的点。QuickNode 在超出配额后自动计费整块请求量且无法设上限，导致用户极度不满。一位用户描述 “仅多 100 万请求就会产生额外 50 美元费用”。 这种不可预测性让 Trustpilot 上的一位老客户称服务为 “最大的骗局…请远离”， 因为费用累计过高。

正如一位 G2 评论者完美总结的那样，“定价结构可以更友好于初创企业”。

🧩 小众功能缺口​

虽然 QuickNode 功能强大，但高级用户指出了若干缺口。常见需求包括：

• 更广的协议支持： 用户希望加入 Bitcoin 以及新兴的 L2 如 Starknet。
• 更强大的工具链： 部分开发者对比竞争对手时提到缺少 “更强大的 webhook 支持”。
• 现代化认证： 长期用户期望在 企业环境 中实现 OAuth 支持，以更好地管理 API Key。

这些缺口并未削弱大多数用户的核心体验，却凸显了在特定用例下竞争对手可能拥有优势的领域。

对 Web3 基础设施领域的关键启示​

QuickNode 的反馈为任何构建开发者工具的公司提供了宝贵经验。

• 性能是底线： 速度和可靠性是根基，缺一不可。QuickNode 在此设立了高标。
• 开发者体验是差异化关键： 干净的 UI、快速的上手、优秀的文档和响应式支持，能够培养忠实用户并打造让开发者真正乐于使用的产品。
• 定价可预见性建立信任： 这是最关键的教训。模糊或惩罚性的定价模型，尤其是无限制的超额费用，会引发焦虑并破坏信任。开发者一旦收到意外账单，几乎不可能长期留下。可预见、透明且对初创企业友好的定价，是巨大的竞争优势。

结论​

QuickNode 理所当然地赢得了顶级基础设施提供商的声誉。它兑现了高性能、卓越可靠性和出色开发者体验的承诺。然而，其定价模型在初创公司和独立开发者——Web3 创新的血液——中造成了显著摩擦。

这份用户反馈提醒我们，打造成功平台不仅仅是技术卓越，更在于让商业模式与用户需求和信任相契合。能够匹配 QuickNode 性能并提供更透明、可预见定价的基础设施提供商，将在未来占据极佳位置。