如何建構鏈上代理:錢包、支付與即時資料

最後更新：2026年5月27日4 分鐘閱讀

大部分「AI agent」教學都停在 LLM 這一層。真正困難的部分,是 agent 需要錢包、需要付費機制來支付它呼叫的服務,以及需要即時掌握它所操作的鏈上狀態時才開始。

要打造 onchain agent,必須給 agent 三個基本元件:一個範圍受限的簽署錢包、一條像 x402 這樣的支付通道,以及透過 webhooks、WebSockets 或 gRPC 取得的即時資料流。模型負責決策,這些元件則讓它能夠在鏈上行動。

會寫程式碼的 LLM 只是個 copilot。而一個能持有資金、簽署交易,並即時對鏈上事件做出反應的 agent,則是另一回事:它是經濟體系裡的參與者。這類基礎設施已經存在,但分散在錢包、支付、即時資料這幾種元件之中。本篇指南會說明你實際需要的三個元件,以及如何把它們串接起來。Alchemy CLI 和我們的代理型產品都直接以元件的形式提供這些功能。

打造 onchain agent 有什麼不同?

一般 AI agent 技術棧裡的大部分東西在鏈上依然適用:模型、框架、工具呼叫模式、協調迴圈、評估工具、prompt 儲存。這些都能沿用。如果你打造過 Slack bot、coding agent 或 research agent,技術棧的上半部你應該已經很熟悉。

有三件事無法沿用:錢包、支付通道,以及即時資料流。這三者在 LLM 工具生態裡都沒有直接對應的東西,也不是換個更聰明的模型就能解決的問題;其中任何一個做錯,都可能是導致錢包被掏空或 agent 在正式環境中卡死的那種錯誤。

身分認證是私鑰,不是電子郵件地址。 agent 能簽署什麼,它就能花用什麼。金鑰保管因此變成一套安全模型,而不只是設定檔。
支付發生在協定層。 Stripe 不會接受「我是個 agent」作為付款方身分。而加密貨幣支付通道會,透過像 HTTP 402/x402 這樣的標準。
即時資料是預設模式,而非附加功能。 區塊時間很短,最終確定性(finality)也很重要。輪詢會消耗預算,而且 agent 需要的是鏈主動推送狀態給它。

以下三個基本元件,各自對應上述其中一項轉變。

onchain agent 的三個基本元件是什麼?

一個正式上線的 onchain agent 通常需要三樣東西:

錢包。agent 能用它簽署交易,且範圍受到限制,即使 prompt 遭到攻擊也無法把錢包掏空。
支付通道。agent 能自動支付鏈下 API 費用和鏈上 gas 費,不需要人在中間介入。
即時資料管道。agent 能在新區塊、交易、合約事件發生的當下立刻做出反應。

本指南其餘部分,每個小節對應一個基本元件,最後再有一個整合實作的範例。

如何在不洩漏金鑰的情況下,給 agent 一個錢包?

最簡單直覺的做法,也是大家第一個會嘗試的做法:把私鑰放進一個 .env 檔案,用 dotenv 載入,然後在 agent 迴圈內部用它簽署交易。這在本機 demo 上行得通,但在正式環境裡,只要一次 prompt injection 攻擊,錢包就會被掏空。

目前逐漸浮現出兩種比較安全的預設做法。

第一種做法是搭配委派簽署(delegated signing)的嵌入式智慧帳戶(programmable wallet contracts,而非原始的私鑰帳戶)。金鑰存放在保管服務中(Privy、Turnkey、採用多方運算(multi-party computation)的 Coinbase MPC)。你的 agent 永遠不會看到金鑰本身。它呼叫一個簽署 API,該服務依照你設定的政策驗證請求,再把簽署完成的交易回傳。agent 能在你設定的規則內簽署(單筆交易上限、允許的合約、每日額度),僅此而已。

第二種做法是由開發者介面核准的、範圍限定於單一 session 的錢包。agent 取得一個有時效性、可撤銷、綁定特定錢包的 session。你從自己掌控的 UI 核准這個 session,撤銷只需要按一下。

第二種做法最新的實作是 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 使用的錢包,核准這個 session,從那一刻起 CLI 就能代表 agent 進行簽署。私鑰始終留在 Privy 那一端。每一次簽署呼叫都會經過兩個步驟:我們的後端負責建構 payload,CLI 在本機端進行簽署,請求再送到 Privy。如果 session 已過期、已被撤銷,或未通過綁定檢查,請求會在離開我們的基礎設施之前就被拒絕。

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 介面,而是在 session 開始時把這份 JSON 清單餵給它,模型就能掌握完整的指令空間、錯誤碼,以及範例呼叫方式。這樣一來就能消除一整類「agent 幻想出一個不存在的參數」的失敗情況。若要取得即時鏈上資料工具,另外連接 hosted MCP server。

如何在這兩種做法之間做選擇:

Pattern	Best for	Trade-off
Embedded smart account with delegated signing	代表終端使用者行動的正式環境 agent(消費者應用程式、agent 商務)	設定較複雜,但可做到每位使用者獨立隔離與細緻的政策控制
Session-scoped CLI wallet	單一開發者的 agent、自動化任務、內部工具、原型開發	設定速度較快,範圍限定於單一 session,可在單一 dashboard 撤銷

不論選哪一種,規則都一樣:agent 永遠不該看到原始私鑰。如果你的設計裡有一個私鑰存在記憶體中,你打造出來的就是一個漏洞,而不是一個 agent。

agent 如何支付它所呼叫的服務費用?

agent 有了錢包之後,還是得付錢買東西,而且是兩種不同的東西:

鏈上成本。 Gas、交換手續費、跨鏈橋費用,任何鏈為狀態變更所收取的費用。
鏈下成本。 RPC 請求、索引資料 API、推論運算,任何 agent 需要從伺服器取得的東西。

鏈上成本可透過 gas 贊助解決。許多帳戶抽象(account-abstraction)供應商提供 paymaster API,paymaster 是一種能代替他人支付 gas 的合約。agent 送出一個 user operation(ERC-4337 中對應智慧帳戶交易的概念),paymaster 負責支付費用,你再於自己這一側核對使用量。這種模式在智慧帳戶系統中已經相當常見。

鏈下成本則是比較棘手的問題,因為 agent 沒有信用卡資料,而你也不想為每個 agent 都建立 API 金鑰。目前整個生態系逐漸收斂出的做法是 x402:利用 HTTP 402 Payment Required 狀態碼,搭配一段小型 payload,告訴 agent 該如何付款。

完整流程如下:

agent 對某個服務發出 HTTP 請求。
該服務回覆 402 Payment Required,附帶一個 JSON 內容,說明價格、接受的代幣種類及所在鏈。
agent 建構一筆付款(常見預設是 Base 上的 USDC),用自己的錢包簽署,並帶著付款證明重新以 header 形式送出原始請求。
該服務驗證、結算,並回傳資料。

我們已經完整實作了這整個流程。agent 可以不需要任何 API 金鑰、不需要註冊 dashboard,就直接呼叫我們的 RPC API、Token API、Portfolio API、NFT API 和 Prices API。第一次請求會收到 402;之後的請求只要以 Base 上的 USDC 支付該端點所要求的金額,就能取得資料。整個過程不需要人介入。

一個最簡化的 client 端處理程式如下:

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 vs WebSockets vs gRPC 的比較文章,這裡先提供給 agent 開發者的簡短版本:

Pattern	Use when
Webhooks	agent 以擁有公開 URL 的服務形式執行,希望由供應商主動推送事件(新交易、已挖出的區塊、地址活動)。在中低事件量下,是營運成本最低的方式。
WebSockets	agent 以持續執行的程序運作,需要在秒以內就取得 log 與待處理交易的更新。適合程序內的迴圈處理。
gRPC streaming	agent 在 Solana 或其他高 TPS 鏈上受限於吞吐量。延遲最低,整合成本也最高。

對大多數 agent 而言,webhooks 搭配幾個 Data API 呼叫(如代幣餘額、交易紀錄、portfolio)就已經足夠。webhook 觸發後,agent 被喚醒,查詢已豐富化的狀態,決定要採取什麼動作,簽署交易,然後再進入休眠。

把它們串在一起:一個最小化的 onchain 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);
      }
    }
  },
});

這個架構有三點值得注意:

程序中沒有私鑰。 每一次簽署呼叫都經過 CLI session,再與 Privy 溝通。即使這個程序遭到入侵,攻擊者拿到的也只是一個可撤銷的 session,而不是一個錢包。
資料呼叫不需要 API 金鑰。 paidFetch 能對任何支援 x402 的端點運作,該端點會按照 USDC 逐次收費。
LLM 只是整體中最小的一塊。 大部分的工作其實是錢包、支付與資料管線的串接,模型只負責做決策。

這就是整體模式。換掉觸發條件(Discord 訊息、排程、市場事件)、換掉執行動作(交換、投票、跨鏈、鑄造)、換掉模型,你就得到一個不同的 agent。

用 Claude 打造它

或者,直接讓 Claude 幫你打造。安裝 Alchemy Skills,並連接 hosted 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 session 進行 CLI 簽署以完成退款。整個過程中沒有私鑰存在於程序內。

該選用哪一種 agent 框架?

框架是建構在上述三個基本元件之上的一層。它們負責處理 agent 迴圈、工具註冊、記憶功能,以及(部分框架還包含)社群平台客戶端。選擇哪一種,取決於你要優化的是鏈的深度、多鏈的廣度,還是完整的執行環境。

Framework	Best for	Chains	Notes
LangChain / LangGraph	適用於任何模型、任何工具的通用型協調	任意鏈(透過工具封裝)	彈性最高,預設立場最少。錢包與 RPC 工具需要自行串接。
GOAT SDK by Crossmint	需要在單一 API 下同時涵蓋 EVM 與 Solana 的多鏈 agent	EVM + Solana	採用外掛模式。適合需要跨鏈操作的 agent。
ElizaOS agent runtime	以角色檔案驅動的社群 agent(Twitter、Discord、Farcaster)	任意	包含記憶功能與平台客戶端在內的完整執行環境,比單一函式庫來得重。
Solana Agent Kit by SendAI	需要最深入 Solana 協定覆蓋率(Jupiter、Raydium、Drift 等)	僅限 Solana	屬於工具函式庫,而非執行環境,迴圈需自行實作。
Vercel AI SDK	將 agent 回應以串流方式傳送到網頁 UI	任意(透過工具)	適合需要將 agent 回應串流到瀏覽器 UI 的情境。

若想了解如何以鏈原生方式完整打造包含錢包設定、RPC 整合與 Jupiter 交換功能的 agent,可參考 Solana AI agent 建置指南。若想了解不限特定鏈的供應商比較,可參考最適合自主 onchain agent 的區塊鏈 API。

這些框架彼此之間可以互換,但基本元件不行。把 LangChain 換成 GOAT,可能一個下午就能完成;但更動 agent 簽署交易的方式,則等同於一次安全性審查。

接下來可以做什麼

這三個基本元件可以互相組合。一旦你有了一個持有範圍受限 session 錢包、能用 x402 支付資料費用、並能對即時事件做出反應的 agent,問題就不再是「agent 能不能做到這件事」,而是「agent 應該做什麼」。

我們把這三個基本元件都以現成元件的形式提供。我們的 CLI 透過由 Privy 支援、可撤銷的 session 來處理錢包。我們的 RPC、Token、Portfolio、NFT 和 Prices API 都直接支援 x402,不需要 API 金鑰、不需要註冊 dashboard、不需要簽約。Webhooks、WebSocket subscriptions 和 Solana gRPC streaming 則涵蓋了即時資料流的需求。

執行 npx skills add alchemyplatform/skills --yes,連接 hosted MCP server,然後將 LangChain、GOAT、ElizaOS 或你所使用的框架指向 Alchemy 的 API。從 npm i -g @alchemy/cli@latest 和 alchemy auth 開始。更多資訊請參考 alchemy.com/agents。

常見問題

什麼是 onchain agent?

onchain agent 是一種能讀取區塊鏈狀態、持有或掌控錢包,並依據政策或模型決策簽署交易的 AI agent。模型負責決定要做什麼;錢包、支付通道與資料流則讓它能夠實際採取行動。

如何打造一個 onchain agent?

從三個基本元件開始:一個用於簽署的範圍受限錢包、一條像 x402 這樣用於支付 API 呼叫費用的支付通道,以及透過 webhooks、WebSockets 或 gRPC 取得的即時資料流。接著,把這些元件接進你現有使用的 agent 框架或協調迴圈中。

AI agent 應該使用哪種錢包?

應選用能讓原始私鑰不會出現在 agent 程序中的錢包模式。搭配委派簽署的嵌入式智慧帳戶,適合面向終端使用者的應用程式;而範圍限定於單一 session 的 CLI 錢包,則適合開發者用的 agent、內部自動化任務與原型開發。

onchain agent 如何支付 API 費用?

它們可以使用 x402 付款機制。agent 發出請求,收到附帶付款資訊的 402 Payment Required 回應,用自己的錢包簽署這筆付款,再帶著付款證明重新送出請求。

onchain agent 應該使用 webhooks、WebSockets 還是 gRPC?

當 agent 以服務形式運作、能接收推送事件時,使用 webhooks。當 agent 以持續執行的程序運作,且需要低延遲的 log 或待處理交易資訊時,使用 WebSockets。對於像 Solana 這類高吞吐量、且延遲問題足以值得投入更多整合成本的工作負載,則使用 gRPC streaming。

onchain agent 最適合用哪種框架?

最適合的框架取決於你需要的迴圈類型。LangChain 或 LangGraph 在一般性協調上較有彈性,GOAT 適合多鏈工具覆蓋,ElizaOS 專為社群 agent 打造,Solana Agent Kit 在 Solana 上有較深入的支援,而 Vercel AI SDK 則適合面向瀏覽器 UI 的 agent。

核心基礎設施已經就緒,可供你開始打造。至於你要用它做什麼,則是沒有人能替你寫出來的部分。