AI 和 Web3 是两项变革性技术,而 Google Cloud 恰好处在二者独特的交汇点上。可与区块链交互的 AI 智能体冉冉兴起,开创了一个全新的世界,它们能够支持自动化金融策略、快速支付以及更复杂的场景,例如执行复杂的 DeFi 操作和跨多条链桥接资产。

不过,这种新范式在现实中是否可行,关键在于谁托管智能体以及谁持有操作的私钥。

核心问题很简单。由于大多数加密货币用户不会运行自己的安全服务器来管理智能体密钥,因此服务提供方很可能会从两种主要架构中选择其一:一种是托管模型,其中用户将资金委托给控制私钥的第三方智能体;另一种是非托管模型,其中智能体仅构造交易,需要用户使用自己的私钥进行签名。

在目前的大多数范例中,都是智能体直接持有私钥,而大多数加密货币 Model Context Protocol (MCP) 服务器只有在配置了私钥后才能使用。不过,这并非是唯一的方案。

智能体控制模型

这种模型的适用场景为用户与第三方托管的智能体互动(在主流应用场景中,这一假设具有现实意义)。在此场景中,您不向智能体提供私钥。但智能体有自己的密钥,您授予它一个限额,允许它代表您支出。

工作原理

智能体控制模型序列图

1. 智能体获取钱包:智能体拥有一个或多个私钥。这些钱包的私钥由智能体的托管方安全管理,从不由您掌控。

2. 用户委托资金:您从个人钱包(例如 MetaMask 或硬件钱包)向智能体的公共地址发送特定的金额。

3. 智能体获得自主权:智能体现在可以完全自主地控制所掌控的钱包中的资金。智能体可以使用自己的密钥签署和执行交易,例如交换代币、购买 NFT 和向另一个智能体支付数据费用,直到预付费余额用完为止。

内在风险

虽然这种模型提供了自动化便利,但也带来了重大的风险,这些风险从您这里转移到了智能体及其托管方身上。

  • 性能风险:智能体可能办坏差事:交易智能体可能会执行有缺陷的策略,导致您委托的资金遭受损失。

  • 恶意风险:设计拙劣或有恶意企图的智能体可能会滥用资金。例如,智能体可能会将余额发送到未经授权的地址。为防止出现这种情况,托管平台应配备健全的保护措施、审核机制和规则来约束智能体行为。另一种方案是,将智能体资金放在担保资金用途的智能合约中以确保其安全。

  • 安全风险:第三方托管方现在负责保管您委托的资金。如果他们的平台遭到黑客入侵,并且智能体的私钥被盗,那么您的预付费余额将成为主要目标。

自托管模型变体

少数技术高深的用户可能想在个人服务器上运行此模型。由于 AI 智能体开发还处于初期阶段,所以这些为数不多的开发者和尝鲜者代表了当前的主要用户群体。

因此,这种自托管模型成为当下最常见的模型,而且大多数加密货币 MCP 服务器都是为了服务这种模型而构建的。在这种情况下,向智能体提供私钥在技术上是可行的,因为私钥永远不会离开用户自己控制的环境。

自托管智能体模型序列图

不过,这种方法也伴随着极高的风险。如果您的机器遭到入侵,私钥可能会被黑客盗取;而且不稳定、未授权的智能体行为也可能导致重大损失。

例如,假设您的指令为“我想用 500 美元兑换 UNI”,智能体可能会决定卖出 UNI 或买入 UNI、搞错滑点百分比或者买入错误的 UNI 代币。我们建议仅在测试环境中使用此方法。

交易构造器模型

对于大多数用户互动场景而言,这是一种基本上更为安全的非托管替代方案。在此模型中,智能体从不持有您的任何资金。它的目的是执行与智能体控制模型完全相同的工作,但不会签名和发送交易,而是把交易返回给用户,由用户签名并发送到区块链网络。

工作原理

交易构造器模型序列图

1. 用户向智能体发出指令:您要求智能体执行一项任务,例如“将我的 ETH 兑换为 USDC”。

2. 智能体构造交易:智能体分析您的查询,并构建原始交易,例如兑换交易。

3. 用户给交易签名:智能体将此数据传回给您。您的钱包会显示一个弹出式窗口,清晰说明您即将要执行的操作。只有您可以使用私钥批准交易并签名。

如何使用 Google Cloud 工具构建智能体

为了演示这个模型,我使用一套 Google Cloud 工具构建了一个智能体示例。该智能体的推理能力受到 Gemini 2.0 Flash 模型的支持,使用的编排工具为 Google 智能体开发套件 (ADK)。为进行测试,我从公共的 Google Cloud Ethereum Faucet(面向开发者的重要资源)获取了资金。

使用 ADK 开发智能体非常简单,其中附带了许多实用的功能,例如:提供简单测试和开发环境的 Web 界面;深度集成 Agent Engine 和 Google Cloud Run,可轻松在生产环境中部署智能体;简便地将智能体作为 API 服务器来运行,以轻松连接到自定义前端;另外还提供一个工具箱,可轻松连接到 MCP 服务器、智能体间 (A2A) 协议和 Google 搜索等工具。

如果您想详细了解如何使用 Google Cloud 技术栈构建智能体,可以阅读这篇文章

此应用包含两个主要部分,分别是智能体和前端。智能体构造交易,而前端则获取智能体所构造的交易并将其发送到 MetaMask 以待签名和发送。

使用 Google ADK 开发智能体非常简单,但 craft_eth_transaction 函数可能会非常复杂,具体取决于支持的操作类型。其中可包括链、资产和兑换:

from google.adk.agents import Agent

from web3 import Web3


ETH_RPC_URL = "RPC URL"


# (This is the tool function defined in the next section)

def craft_eth_transaction(to_address: str, amount: float, from_address: str, chain_id: int):

   # Step 1: Fetch the sender's next transaction count (nonce)

   # Step 2: Determine transaction type (ETH transfer or smart contract call)

   # Step 3: Construct the 'data' field using ABI

   # Step 4: Assemble and return the final, unsigned transaction


# The Agent is defined with a simple, non-custodial instruction

root_agent = Agent(

   name="transaction_crafter_agent",

   model="gemini-2.0-flash",

   description="An agent that crafts Ethereum transactions for a front-end to send via MetaMask.",

   instruction=(

       "You are an agent that crafts ETH transactions. "

       "Your only job is to collect the information from the user to craft Ethereum transactions.. "

       "The sender's address will be provided to you as context, along with the chain ID."

       "Use the `craft_eth_transaction` tool to generate the transaction object. "

       "The tool will return a JSON object that is ready to be sent to MetaMask. "

       "Leave gas and gasPrice fields empty; MetaMask will set them."

       "**IMPORTANT:** After using the tool, you must present the final transaction JSON in the response, formatted exactly like this:\\n"

       "   ```json\\n"

       "   {\\n"

       "     \\"to\\": \\"0x...\\",\\n"

       "     \\"from\\": \\"0x...\\",\\n"

       "     \\"value\\": \\"0x...\\",\\n"

       "     \\"nonce\\": \\"0x...\\",\\n"

       "     \\"chainId\\": \\"0xaa36a7\\"\\n"

       "   }\\n"

       "   ```\\n"

   ),

   tools=[craft_eth_transaction],

)

客户端的逻辑很清晰,且聚焦于 Web3 交互。前端不需要了解大语言模型 (LLM) 或智能体编排的任何细节。它会调用智能体的 API 端点(托管在 Google Cloud Run 上),获取标准的 JSON 交易对象,并将其传递给 MetaMask。

ADK 能够轻松地将智能体作为 API 服务器来运行,从而实现了这种清晰的关注点分离。前端的两个主要职能是,从智能体的响应中提取交易,以及将交易发送到 MetaMask。下面给出了上述两种职能的示例:

/**

* Step 1: Process the agent's response to extract the crafted transaction data.

* The agent's only output is a standard, unsigned transaction object.

*/

function extractTransactionFromAgentResponse(agentEvents) {

   const functionResponse = agentEvents.find(

       e => e.content?.parts?.[0]?.functionResponse?.name === 'craft_eth_transaction'

   )?.content.parts[0].functionResponse;


   if (functionResponse?.response?.success) {

       // The raw transaction object, ready for the user's wallet

       return functionResponse.response.transaction;

   }

   return null;

}


/**

* Step 2: Pass the crafted transaction to the user's wallet for execution.

* This function triggers a MetaMask pop-up, putting the user in full control.

*/

async function executeMetaMaskTransaction(txData) {

   if (!txData || typeof window.ethereum === 'undefined') {

       console.error("Invalid transaction data or MetaMask not found.");

       return;

   }


   try {

       // The 'eth_sendTransaction' call asks the wallet to sign and send.

       // The private key is never exposed to our web application.

       const txHash = await window.ethereum.request({

           method: 'eth_sendTransaction',

           params: [txData], // txData is the JSON object from the agent

       });


       console.log(`Transaction sent successfully! Hash: ${txHash}`);

       return txHash;


   } catch (error) {

       // This error typically means the user rejected the transaction in MetaMask.

       console.error("Transaction failed or was rejected by user:", error);

   }

}

智能体如何确认意图

智能体操作是通过与智能体对话达成决策,而 MetaMask 弹出式窗口则代表此次对话的结论。

请把它想象成数字版的财务顾问,它先解释具体策略,然后将最终文档交给您签名。签名是您在知情且同意相关操作的前提下做出的审慎且必要的最终确认。在获得您的明确批准后,它可以将智能体的建议付诸实践,从而让您安心无忧。尤其是考虑到智能体的解释可能会因底层 LLM、对话上下文和它所能访问的数据而产生巨大的差异,所以在批准钱包交易之前,最好对每个交易都检查两遍。

MCP 服务器应满足两种现实需要

在未来的愿景中,智能体会自主向其他智能体支付服务费,此时智能体控制模型就成了必然的选择。在这种经济环境中,智能体需要有自己的资本才能运转。

不过,交易构造器模型提供了一个安全的桥梁来实现这一未来愿景。使用它可以安全地为智能体提供资金,也可以直接执行一次性交易来完成较简单的操作。这种灵活性非常重要。

从开发者的角度来看,增加这种能力应该并非难事。如果 MCP 服务器已经能够准备交易并使用所持有的密钥签名,那么它应该能够执行相同的逻辑,只不过不执行最终的签名步骤,而是将未签名的交易返回给用户。这一小小的变化为用户提供了一种更安全、更灵活的范式,甚至可以实现更复杂的设计,例如多智能体系统中专门的“签名智能体”。

因此,任何想要获得广泛应用的稳健 MCP 服务器都应赋予开发者这种灵活性,以构建出具备以下能力的应用:

  • 以用户为中心提出安全的财务决策建议并制定相应方案。

  • 使用委托的资金执行专业化、自动化且定义明确的任务。

我们建议同时提供以上两种支持,在保护用户的同时推动真正的创新。

如需详细了解如何使用 Google Cloud 构建 Web3 智能体,请点击此处

相关推荐

精选内容

关注【谷歌云服务】
微信公众号
微信咨询:
周一至周五 早上 9 点到晚上 6 点
联系我们