如何构建链上代理：钱包、支付与实时数据

最后更新：2026年5月27日4 分钟阅读

大多数"AI agent"教程只讲到 LLM 这一层。真正难的部分从 agent 需要一个钱包、一种为其调用的服务付费的方式、以及对其所操作链的实时视图开始。

要构建链上 agent，需要给 agent 三种基础组件：一个用于签名的受限权限钱包、一条像 x402 这样的支付通道，以及通过 webhooks、WebSockets 或 gRPC 实现的实时数据feed。模型负责决策；这些基础组件让它能够在链上行动。

一个会写代码的 LLM 是一个 copilot。而一个持有资金、签署交易、并实时响应链上事件的 agent 则是另一回事：它是经济体系中的参与者。相应的基础设施已经存在，但分散在钱包、支付和实时数据这几类基础组件中。本指南将逐一讲解你实际需要的这三类组件，以及如何将它们连接起来。Alchemy CLI 和我们的agentic 产品将每一项都作为可直接使用的基础组件提供。

构建链上 agent 有什么不同？

普通 AI agent 技术栈中的大部分内容在链上仍然适用：模型、框架、tool-calling 模式、编排循环、eval 工具、prompt 存储，这些都可以直接沿用。如果你构建过 Slack bot、编程 agent 或研究 agent，那么技术栈的上半部分你已经很熟悉了。

有三样东西无法直接沿用：钱包、支付通道和实时数据feed。这三者在 LLM 工具生态中都没有对应的现成方案，也都不是靠选一个更聪明的模型就能解决的，而在这三者中任何一个上出错，都可能导致钱包被清空或 agent 在生产环境中卡住。

身份是一个私钥，而不是一个邮箱地址。 agent 能签署的一切，它也能花掉。密钥托管由此成为一个安全模型，而不是一份配置文件。
支付发生在协议层。 Stripe 不会接受"我是一个 agent"作为付款方身份。而加密货币的支付通道可以，通过诸如 HTTP 402/x402 这样的标准实现。
实时数据是默认模式，而不是一项附加功能。 出块时间很短，最终性（finality）很重要。轮询会消耗预算，而且agent每次都会对它关心的事件反应迟到。agent 需要链把状态主动推送给它。

下面的三个基础组件分别对应这三处变化。

链上 agent 的三个基础组件是什么？

一个生产环境中的链上 agent 通常需要三样东西：

钱包。agent 可以用它签名，且权限受限，即便 prompt 被攻破也无法将其清空。
支付通道。agent 无需人工介入即可为链下 API 和链上 gas 付费。
实时数据管道。agent 能在新区块、交易和合约事件发生的瞬间做出响应。

本指南接下来的内容，每个基础组件对应一个章节，最后再通过一个完整示例把它们组合到一起。

如何在不泄露密钥的情况下给 agent 一个钱包？

最朴素的做法是大家都会先尝试的那种：把私钥放进一个 .env 文件，用 dotenv 加载它，然后在 agent 循环内部用它签署交易。这在本地演示中能跑通，但在生产环境中，只需一次 prompt injection 就足以清空钱包。

目前正在形成两种更安全的默认做法。

第一种模式是采用带委托签名的嵌入式智能账户（可编程的钱包合约，而非原始私钥账户）。密钥保存在托管服务内部（Privy、Turnkey、使用多方计算的 Coinbase MPC）。你的 agent 从不接触密钥本身，它调用一个签名 API，该服务根据策略校验请求，然后返回已签名的交易。agent 可以在你设定的规则内签名（每笔交易的最大金额、允许的合约地址、每日限额），除此之外不能做任何事。

第二种模式是从开发者可控界面批准的、按会话（session）限定权限的钱包。agent 获得一个绑定到特定钱包、有时限且可撤销的会话。你从自己控制的 UI 中批准该会话，撤销只需一次点击。

模式 2 的最新实现是 Alchemy CLI 中的 agent wallet 功能，作为 CLI 本身的一部分随附提供：

bashCopied
# Install the latest Alchemy CLI
npm i -g @alchemy/cli@latest
# Authenticate your CLI session
alchemy auth
# Connect the wallet your agent will use
alchemy wallet connect

alchemy wallet connect 会在浏览器中打开我们的 dashboard。你选择希望 agent 使用的钱包，批准该会话，此后 CLI 就可以代表 agent 进行签名。私钥保留在 Privy 中。每次签名调用都经过一个两步流程：我们的后端构造 payload，CLI 在本地签名，请求随后到达 Privy。如果会话已过期、已被撤销，或未通过绑定检查，请求会在离开我们的基础设施之前就被拒绝。

CLI 的设计定位是面向 agent、而不仅是面向人类的工具接口。以下这些命令很关键：

bashCopied
# Run any command with structured output and no prompts
alchemy <command> --json --no-interactive
# Print the JSON manifest of every command and flag
alchemy --json --no-interactive agent-prompt
# Install Alchemy Skills for agent clients
npx skills add alchemyplatform/skills --yes

alchemy --json --no-interactive agent-prompt 是让这一切真正做到 agent 原生化的关键部分。你不需要让 LLM 去记忆整个 CLI 的接口，而是在会话开始时把这份 JSON manifest 提供给它，模型就能掌握完整的命令空间、错误码和示例调用方式。这消除了一整类"agent 臆造出一个不存在的 flag"这样的失败。至于实时链上数据工具，需要单独连接托管的 MCP server。

如何在这两种模式之间做选择：

Pattern	Best for	Trade-off
Embedded smart account with delegated signing	Production agents acting on behalf of end users (consumer apps, agent commerce)	More setup, but per-user isolation and granular policy
Session-scoped CLI wallet	Single-developer agents, automation, internal tools, prototypes	Faster to wire up, scoped per session, revocable from one dashboard

无论选择哪一种，规则都是一样的：agent 永远不应看到原始私钥。如果你的设计里有一个私钥驻留在内存中，你构建的就是一个安全漏洞，而不是一个 agent。

agent 如何为它调用的服务付费？

一旦 agent 有了钱包，它仍然需要为使用的东西付费，具体分两类：

链上成本。 gas、swap 手续费、跨链桥手续费，任何链上状态变更需要支付的费用。
链下成本。 RPC 请求、索引数据 API、推理调用，任何 agent 需要从服务器获取的东西。

链上成本通过 gas sponsorship 解决。许多 account abstraction 提供方都暴露了 paymaster API，paymaster 是一种代替他人支付 gas 的合约。agent 提交一个 user operation（ERC-4337 中面向智能账户的交易等价物），paymaster 负责支付，你在自己这边做用量核算。这种模式在智能账户体系中已经很常见。

链下成本是更难解决的问题，因为 agent 没有登记在案的信用卡，你也不想为每个 agent 单独配发 API key。整个生态正在收敛到的模式是 x402：HTTP 402 Payment Required 状态码，加上一段告诉 agent 如何付款的小型 payload。

完整流程如下：

agent 向某个服务发起 HTTP 请求。
服务返回 402 Payment Required，并附带一个 JSON body，描述价格、接受的 token 以及所在链。
agent 构造一笔支付（常见默认是 Base 上的 USDC），用它的钱包签名，然后携带支付凭证的 header 重新发起原始请求。
服务验证、结算，并返回数据。

我们对这整个流程做了端到端的实现。agent 可以在无需 API key、无需 dashboard 注册的情况下访问我们的 RPC API、Token API、Portfolio API、NFT API 和 Prices API。第一次请求会收到 402；后续请求按该端点标示的金额以 Base 上的 USDC 付费，并返回数据。全程无需人工介入。

一个最简化的客户端处理逻辑大致如下：

typescriptCopied
async function paidFetch(url: string, wallet: AgentWallet) {
  let res = await fetch(url);

  if (res.status === 402) {
    const requirement = await res.json();
    const payment = await wallet.signX402Payment(requirement);

    res = await fetch(url, {
      headers: { "X-PAYMENT": payment },
    });
  }

  return res.json();
}

agent 携带已签名的支付 header，重新请求同一个 URL。端点在链上结算这笔支付，返回数据，agent 继续往下执行。这种模式可以跨不同提供方组合使用：任何支持 x402 的服务，都可以在不编写自定义鉴权逻辑的情况下接收 agent 的付款。

agent 如何与链保持同步？

链默认不会主动推送数据到你的应用。如果你的 agent 每秒轮询一次 eth_blockNumber 去查看发生了什么，你既要为这些轮询付出成本，又会对每一个你关心的事件都反应迟到。

有三种模式覆盖了几乎所有真实场景下的实时需求。完整对比参见webhooks 与 WebSockets 与 gRPC 的比较，以下是面向 agent 开发者的简短版本：

Pattern	Use when
Webhooks	The agent runs as a service with a public URL and wants the provider to push events (new transactions, mined blocks, address activity). Cheapest to operate at low-to-medium event volume.
WebSockets	The agent runs a persistent process and needs sub-second pickup on logs and pending transactions. Best for in-process loops.
gRPC streaming	The agent is throughput-bound on Solana or another high-TPS chain. Lowest latency, highest cost to integrate.

对大多数 agent 而言，webhooks 加上几个 Data API 调用（token balances、transaction history、portfolio）就足够了。webhook 触发，agent 被唤醒，查询增强后的状态，决定要做什么，签署一笔交易，然后继续休眠。

把它们连接起来：一个最简化的链上 agent 架构

下面是一个紧凑的架构示例，把上述三个基础组件组合到了一起。它监视自己的钱包，当有事件到达时查询一个付费端点，询问 LLM 该怎么做，然后签署一笔响应交易。在把它投入生产环境之前，请用你自己的托管服务提供方替换掉这里的 x402 签名辅助函数。

typescriptCopied
import { createPublicClient, webSocket } from "viem";
import { base } from "viem/chains";
import { execFile } from "node:child_process";
import { promisify } from "node:util";
import OpenAI from "openai";

const run = promisify(execFile);
const openai = new OpenAI();
const agentWallet = process.env.AGENT_WALLET_ADDRESS!.toLowerCase();
const client = createPublicClient({
  chain: base,
  transport: webSocket(process.env.ALCHEMY_RPC_WSS!),
});

async function signX402Payment(requirement: unknown) {
  // Plug in your x402 client and custody provider here.
  // The signer should construct the payment payload and sign it with the agent wallet.
  throw new Error("Implement x402 signing with your wallet provider");
}

// 1. Signing through the agent wallet session (no private key in process).
// Use the session approved via `alchemy wallet connect` to sign and broadcast.
async function refund(to: string, amountEth: string) {
  // Plug in your agent wallet signing provider here.
  throw new Error("Implement refund signing with your agent wallet session");
}

// 2. Paid data fetch via x402 against an Alchemy endpoint.
async function paidFetch(url: string) {
  let res = await fetch(url);
  if (res.status === 402) {
    const requirement = await res.json();
    const payment = await signX402Payment(requirement);
    res = await fetch(url, { headers: { "X-PAYMENT": payment } });
  }
  return res.json();
}

// 3. Real-time trigger: react to inbound transactions on the agent wallet.
client.watchBlocks({
  includeTransactions: true,
  onBlock: async (block) => {
    for (const tx of block.transactions) {
      if (tx.to?.toLowerCase() !== agentWallet) continue;

      const portfolio = await paidFetch(
        `https://api.g.alchemy.com/data/v1/portfolio/${tx.from}`
      );

      const decision = await openai.chat.completions.create({
        model: "gpt-4o",
        messages: [
          {
            role: "system",
            content: "You are a treasury agent. Decide whether to refund.",
          },
          {
            role: "user",
            content: JSON.stringify({ tx, sender_portfolio: portfolio }),
          },
        ],
      });

      const action = JSON.parse(decision.choices[0].message.content!);
      if (action.refund) {
        await refund(tx.from, action.amount);
      }
    }
  },
});

关于这个结构，有三点值得注意：

进程中没有私钥。 每一次签名调用都经过与 Privy 通信的 CLI 会话。如果该进程被攻破，攻击者得到的是一个可撤销的会话，而不是一个钱包。
数据调用无需 API key。 paidFetch 可以对任何支持 x402 的端点生效。该端点按每次请求以 USDC 计费。
LLM 是其中最小的一部分。 大部分的工作量都在钱包、支付和数据管道上，模型只负责做决策。

这就是这种模式。换一个触发条件（Discord 消息、cron、市场事件），换一个动作（swap、投票、跨链、mint），换一个模型，你就得到了一个不同的 agent。

用 Claude 来构建它

或者直接让 Claude 替你构建。安装 Alchemy Skills 并连接托管的 MCP server：

bash

Copied

npx skills add alchemyplatform/skills --yes

# Claude Code — see the MCP server docs for other clients
claude mcp add alchemy --transport http https://mcp.alchemy.com/mcp

然后把这段 prompt 粘贴进 Claude Code：

text

Copied

Build a TypeScript onchain agent on Base that:
1. Watches a wallet address for incoming transactions in real time
2. When a transaction arrives, queries an x402-payable portfolio API for the sender's holdings
3. Asks an LLM whether to refund
4. Signs the refund without holding the private key in the process

Use production-grade primitives.

输出结果与上面的脚本一致：一个基于 viem 的 WebSocket 连接到我们的 RPC，一个位于 x402 之后的 Portfolio API，以及通过已批准的 agent wallet 会话进行 CLI 签名来完成退款。进程中没有私钥。

应该选择哪个 agent 框架？

框架建立在上述三个基础组件之上，负责处理 agent 循环、tool 注册、记忆，以及（部分框架还提供）社交平台客户端。具体选择取决于你追求的是链的深度覆盖、多链广度覆盖，还是一个完整的运行时。

Framework	Best for	Chains	Notes
LangChain / LangGraph	General-purpose orchestration with any model and any tool	Any (via tool wrappers)	Most flexible, least opinionated. You wire the wallet and RPC tools yourself.
GOAT SDK by Crossmint	Multi-chain agents that need EVM and Solana under one API	EVM + Solana	Plugin model. Good fit when the agent crosses chains.
ElizaOS agent runtime	Social agents (Twitter, Discord, Farcaster) with character files	Any	Full runtime including memory and platform clients. Heavier than a library.
Solana Agent Kit by SendAI	Deepest Solana protocol coverage (Jupiter, Raydium, Drift, etc.)	Solana only	Tool library, not a runtime. Bring your own loop.
Vercel AI SDK	Streaming agent responses to a web UI	Any (via tools)	Good fit for streaming agent responses to a browser UI.

关于面向链原生的端到端构建流程（含钱包设置、RPC 集成和 Jupiter swap），参见 Solana AI agent 构建指南。关于跨链的提供方对比，参见面向自主链上 agent 的最佳区块链 API。

这些框架之间可以互换，但基础组件不行。你可以在一个下午的时间里把 LangChain 换成 GOAT，但更改 agent 的签名方式则是一次安全审查。

接下来可以构建什么

这三个基础组件是可以组合的。一旦你拥有了一个持有按会话限定权限的钱包、通过 x402 为数据付费、并能对实时事件做出反应的 agent，问题就不再是"agent 能不能做这件事"，而是变成了"agent 应该做什么"。

我们将这三个基础组件都作为独立的组件提供。我们的 CLI 通过由 Privy 支撑、可撤销的会话来处理钱包。我们的 RPC、Token、Portfolio、NFT 和 Prices API 都直接支持 x402，无需 API key、无需 dashboard 注册、无需签合同。Webhooks、WebSocket subscriptions 和 Solana gRPC streaming 覆盖了实时数据feed这一部分。

运行 npx skills add alchemyplatform/skills --yes，连接托管的 MCP server，然后让 LangChain、GOAT、ElizaOS 或你自己的框架调用 Alchemy 的 API。从 npm i -g @alchemy/cli@latest 和 alchemy auth 开始。更多内容参见 alchemy.com/agents。

常见问题

什么是链上 agent？

链上 agent 是一种能够读取区块链状态、持有或控制钱包、并根据策略或模型决策签署交易的 AI agent。模型负责决定要做什么；钱包、支付通道和数据feed让它能够付诸行动。

如何构建一个链上 agent？

从三个基础组件开始：一个用于签名的受限权限钱包、一条像 x402 这样用于付费 API 调用的支付通道，以及通过 webhooks、WebSockets 或 gRPC 实现的实时数据feed。然后把这些基础组件接入你现有的 agent 框架或编排循环中。

AI agent 应该使用什么样的钱包？

应使用一种能让原始私钥不进入 agent 进程的钱包模式。带委托签名的嵌入式智能账户适合面向用户的应用，而按会话限定权限的 CLI 钱包适合开发者 agent、内部自动化和原型项目。

链上 agent 如何为 API 付费？

它们可以使用 x402 支付。agent 发起请求，收到带有支付详情的 402 Payment Required 响应，用自己的钱包签署这笔支付，然后携带支付凭证重新发起请求。

链上 agent 应该使用 webhooks、WebSockets 还是 gRPC？

当 agent 以服务形式运行且能够接收推送事件时，使用 webhooks。当 agent 以持久化进程运行、且需要低延迟的日志或 pending 交易时，使用 WebSockets。对于高吞吐、类似 Solana 的工作负载，如果延迟足够重要、值得投入更多集成成本，则使用 gRPC streaming。

最适合链上 agent 的框架是什么？

最佳框架取决于你需要的具体循环方式。LangChain 或 LangGraph 在通用编排上很灵活，GOAT 在多链工具覆盖上很有用，ElizaOS 是为社交 agent 构建的，Solana Agent Kit 深耕 Solana，而 Vercel AI SDK 则很适合面向浏览器的 agent UI。

核心基础设施已经准备就绪，可供构建使用。而你用它来做什么，才是别人无法替你完成的部分。