鏈上 AI Agent 架構:五種建構模式

發布於 2026年9月2日閱讀時間 3 分鐘

能夠讀寫鏈上狀態的 AI 代理已經從展示走向正式生產環境。模型能夠推理，代理錢包能在受限權限下簽署交易，基礎設施也能在事件上鏈後幾秒內就推送給代理。問題通常出在架構上。代理明明可以訂閱事件卻用輪詢方式取得，把簽署權放在讀取不可信輸入的同一個處理程序中，或是直接拿真實資金在主網上邊做邊學。

鏈上代理的運作是一個迴圈：觀察、決策、行動。正式環境中的代理通常會以五種固定模式來安排這個迴圈，下面針對每一種都提供了實作範例。我們的鏈上代理建置指南涵蓋了這些模式底層共通的基礎元件（錢包、支付軌道、資料來源）；本頁要談的則是如何安排這些基礎元件。

Pattern	Trigger	The agent reads	The agent does	Reach for it when
Wallet watcher	A transfer hits a watched address	Webhook or WebSocket events	Wakes and evaluates	You track deposits, whales, or counterparties
Event-driven reactor	A contract emits an event	Filtered logs	Responds with a transaction	Protocol state changes drive your strategy
Portfolio rebalancer	Allocation drifts past a band	Balances and prices	Proposes a swap	You hold target weights and want them enforced
Detect-then-execute split	The detector emits a signal	Everything, while signing nothing	The executor verifies, then signs	Untrusted input meets real money
Pre-mainnet testing	Every new capability	Testnets and dry-runs	Promotes the agent in stages	Always, before the other four go live

如何建置即時錢包監控代理？

把你關心的地址註冊到 webhook，讓鏈上資料主動送過來，而不是自己去輪詢。用迴圈輪詢餘額既耗費運算資源，還是會錯過事發的當下。推送式管線能在轉帳上鏈後幾秒內送達，這正是監控器的全部工作。

假設有個代理要追蹤某基金的交易對手錢包，並標記任何大額 USDC 轉帳。在 Alchemy 上，單一個 Address Activity webhook 就能涵蓋原生代幣、ERC-20、ERC-721 與 ERC-1155 的轉帳，最多可監控 100,000 個地址，因此一個 webhook 就能監控整份交易對手清單。如果代理是以長駐處理程序執行，又不想公開對外的 URL，WebSocket 訂閱可以在處理程序內完成同樣的工作。用 alchemy_minedTransactions 訂閱後，你拿到的就是已經依你的地址篩選過的已確認交易，不需要自己解析日誌。在 Solana 上，Yellowstone gRPC streaming 扮演相同角色，每 TB 收費 $75，並支援無斷點重新連線。如果不確定該選哪種傳輸方式，我們的webhooks vs WebSockets vs gRPC 比較有詳細的說明。

處理函式本身應該幾乎不做任何事：先驗證這則推送確實來自 Alchemy，去除重複，把事件交給代理的決策步驟處理，最後才回覆確認：

typescriptCopied
import express from "express";
import { createHmac, timingSafeEqual } from "node:crypto";
const SIGNING_KEY = process.env.ALCHEMY_WEBHOOK_SIGNING_KEY!; // from the webhook's dashboard settings
const USDC = "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"; // canonical USDC contract on Ethereum mainnet
const seen = new Set<string>();
function remember(key: string) {
seen.add(key);
if (seen.size > 10_000) seen.delete(seen.values().next().value!); // bound the set; only recent deliveries repeat
}
function wake(signal: unknown) {
// The agent's decide step starts here. Queue the signal;
// don't run model reasoning inside the request handler.
}
const app = express();
app.use(
express.json({
  verify: (req, _res, buf) => {
    (req as { rawBody?: Buffer }).rawBody = buf; // keep the raw bytes for the HMAC check
  },
})
);
app.post("/hooks/address-activity", (req, res) => {
const sig = Buffer.from(String(req.headers["x-alchemy-signature"] ?? ""), "hex");
const expected = createHmac("sha256", SIGNING_KEY)
  .update((req as { rawBody?: Buffer }).rawBody ?? Buffer.alloc(0))
  .digest();
if (sig.length !== expected.length || !timingSafeEqual(sig, expected)) {
  return res.sendStatus(401); // not signed with our key; never process it
}
for (const transfer of req.body.event.activity) {
  const key = `${transfer.hash}:${transfer.log?.logIndex ?? "native"}`; // one tx can carry several transfers
  if (seen.has(key)) continue; // repeat delivery, already handled
  if (transfer.rawContract?.address?.toLowerCase() === USDC && transfer.value > 50_000) {
    wake({ kind: "large-transfer", ...transfer }); // if this throws, the key stays unmarked and the retry redelivers
  }
  remember(key); // mark handled only after the handoff succeeded
}
res.sendStatus(200); // ack only after queueing: a crash above gets retried, not lost
});
app.listen(8080);

有三個習慣能讓這個模式在正式環境中維持可靠。第一，在信任任何一則推送之前先驗證 HMAC 簽章，因為少了這一步，只要有人知道端點的 URL，就能 POST 一筆假的轉帳來操控你的代理。第二，用合約地址而非代號來比對代幣，因為任何人都能部署一個自稱 USDC 的代幣，並轉給被監控的地址。第三，推送保證至少送達一次，因此去重紀錄不是可有可無的東西。用記憶體內的集合來去重，只適用於單一長駐處理程序；如果服務會重啟或跑多個副本，就需要把紀錄放在共用且持久的地方，例如 Redis 的 key 或資料庫的一筆紀錄，因為交易代理若被重複喚醒，就會產生重複的交易。機械式的過濾應該放在處理函式裡，讓模型完全不參與，因為每筆轉帳都呼叫一次 LLM，成本會超過送出這筆轉帳的基礎設施本身。

如何讓 AI 代理監控智慧合約事件並自動做出反應？

訂閱合約的日誌，篩選出真正重要的一兩種事件，並讓處理函式具備冪等性。合約事件是代理能取得最乾淨的觸發來源，因為合約會明確記錄發生了什麼事、順序又是如何。

Alchemy 上有兩種方式能做到這件事。自訂 webhooks 接受 GraphQL 過濾條件，你可以依合約地址和事件主題來比對，永遠只會收到你要求的日誌，適合無伺服器（serverless）的反應器。對於長時間執行的代理，WebSocket 日誌訂閱能把一切留在同一個處理程序內。以下是一個監控 Uniswap v3 池子的反應器範例，這正是交易代理用來察覺單筆 swap 是否推動價格的資料來源：

typescriptCopied
import { createPublicClient, webSocket, parseAbiItem } from "viem";
import { mainnet } from "viem/chains";
function react(args: unknown) {
// Decide step: is this swap big enough to act on?
}
const client = createPublicClient({
chain: mainnet,
transport: webSocket("wss://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"),
});
client.watchEvent({
address: "0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640", // USDC/WETH 0.05% pool
event: parseAbiItem(
  "event Swap(address indexed sender, address indexed recipient, int256 amount0, int256 amount1, uint160 sqrtPriceX96, uint128 liquidity, int24 tick)"
),
onLogs: (logs) => {
  for (const log of logs) {
    if (log.removed) continue; // reorg removal notice; irreversible actions also need the confirmation-depth rule below
    react(log.args);
  }
},
});

log.removed 這個檢查看似不起眼，其實很重要。鏈會重組（reorg），你的代理已經處理過的日誌，可能在幾個區塊後就從主鏈上消失。冪等的處理函式，加上確認深度規則（在執行不可逆的行動前先等幾個區塊），是標準的防禦做法。反應器的另一個原則和監控器相同：由訂閱過濾條件先做便宜的篩選，模型只會看到通過篩選存活下來的事件。

要建置一個 DeFi 投資組合再平衡代理需要什麼？

四個要素：目前的餘額、目前的價格、一條偏移規則，以及一條 swap 路徑。代理讀取前兩者、檢查第三者，只有當規則被觸發時才會動用第四者。

以一個持有 WETH、USDC、WBTC 各 50/30/20 比例的資金庫代理為例。餘額來自 Portfolio API，它能在一次請求中回傳一個錢包在多個網路上的代幣，不必逐鏈分別呼叫。價值則來自 Prices API。偏移規則只是簡單的算術，常見的起始做法是在每個目標權重上下抓五個百分點的容許範圍。用計時器定期檢查，因為偏移多半來自價格變動而非代幣移動，而價格變動並不會產生可供反應的鏈上事件。監控器（第一種模式）回報的轉帳則是補充性的觸發條件，能在存入或提出的當下就抓到。

typescriptCopied
const TARGET = { WETH: 0.5, USDC: 0.3, WBTC: 0.2 } as const;
const BAND = 0.05; // rebalance when a weight drifts 5 points from target
const WALLET = "0xYourTreasuryWallet"; // the wallet the agent manages
const res = await fetch(
`https://api.g.alchemy.com/data/v1/${process.env.ALCHEMY_API_KEY}/assets/tokens/by-address`,
{
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    addresses: [{ address: WALLET, networks: ["eth-mainnet"] }],
  }),
}
);
const { data } = await res.json();
// Price each balance with the Prices API, sum to a total, then:
for (const [symbol, target] of Object.entries(TARGET)) {
const drift = weightOf(symbol, data) - target; // weightOf: your portfolio math
if (Math.abs(drift) > BAND) {
  propose({ symbol, drift }); // propose: log it and request approval; never swap directly
}
}

執行的一端不應該持有原始私鑰。透過受限範圍的代理錢包，金鑰始終由託管方保管，工作階段（session）只帶有你所授予的能力。花費 ERC-20 代幣前，需要先給路由合約授權額度。每次都只核准剛好需要的金額，雖然會多花一筆交易，但不會留下可供攻擊者盜領的常駐授權額度：

bash

Copied

# before each swap: let the router from your quote spend exactly this swap's WETH
alchemy evm approve 0xRouterFromQuote --token-address 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 --amount 0.4 -n eth-mainnet
# swap WETH into USDC (Ethereum mainnet contract addresses)
alchemy evm swap execute \
--from 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 \
--to 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 \
--amount 0.4 --slippage 0.5 -n eth-mainnet \
--signer session --json --no-interactive

注意這個迴圈的結構：代理提出提案，由另一個角色來核准。一開始這個角色可以是你自己，之後也可以換成針對金額大小、滑點與資產白名單的政策檢查。我們的 DeFi AI 代理概觀說明了為什麼這種權責分離在正式的 DeFi 代理中是常態，而代付 gas（gas sponsorship）則透過你可控管的政策代付手續費，去除最後一項營運上的雜務，讓代理完全不需要管理 gas 餘額。

偵測後執行（detect-then-execute）的多代理系統，最好的架構是什麼？

依權限而非工作量來拆分代理。偵測器（detector）什麼都能讀，但什麼都不能簽；執行器（executor）能簽交易，但對任何未經自己重新驗證的事情一律不予採信。

可以把它想成分析師與交易員的關係：分析師整天盯著市場，也能和任何人交談；交易員接收分析師的建議、加以查核，並且是唯一能動用帳戶的人。

這種模式常見的說法源自一般的代理工具框架，由一個規劃模型（planner）產生步驟、再由執行代理去執行工具。那種框架著眼於協調流程。放到鏈上，這種拆分之所以值得付出額外的複雜度，是出於更棘手的理由：資產保管權。偵測器整天都在處理不可信的輸入：mempool 的雜訊、第三方 API、事件串流，有時甚至是社群媒體動態。這些來源都可能夾帶提示注入（prompt injection）。如果讀取惡意輸入的處理程序，同時也握有簽署權，一則被污染的訊息就可能變成一筆已簽署的交易。把兩者分開之後，就算偵測器被劫持，最糟的結果也不過是提出一個爛建議，被執行器丟棄而已。

偵測器是由第一種和第二種模式組合而成，接上推送式基礎設施而非輪詢迴圈。它會透過佇列（queue）發出訊號，這個佇列同時也充當稽核紀錄。訊號的格式應該保持精簡且可驗證：

jsonCopied
{
"kind": "arb-opportunity",
"pair": "WETH/USDC",
"evidence": { "txHash": "0x…", "block": 23411005 },
"proposal": { "action": "swap", "from": "WETH", "to": "USDC", "amount": "0.4" },
"observedAt": "2026-09-05T09:14:03Z",
"expiresAt": "2026-09-05T09:14:33Z"
}

執行器在對任何訊號採取行動前，會強制執行三條規則：

在鏈上重新驗證證據。 自己去讀取所引用的交易，而不是相信偵測器的摘要。偵測器的工作是「發現」，「證明」則是執行器的責任。
強制執行過期時間。 就算沒有攻擊者介入，偵測後執行系統也常常因為對過時的機會採取行動而虧損。
在錢包層設定支出上限。 每個訊號與每日的預算都設在受限範圍的工作階段裡，一旦行為看起來不對勁，你可以隨時從儀表板撤銷。

在工具面，執行器只需要兩樣東西：用於驗證的 RPC 連線，以及簽署介面。偵測器則是消耗量較大的一方，搭配已索引的資料來源（歷史紀錄用 Transfers API，狀態用 Portfolio API）能讓它把 token 用量花在推理上，而不是花在解析原始鏈上資料。我們的自主代理用區塊鏈 API 比較涵蓋了這項選擇在基礎設施面的考量。

上主網之前，如何安全地測試 AI 代理的交易？

在代理與真實資產之間設下四道關卡：每筆交易都先乾跑（dry-run）、限制金鑰能動用的額度、在測試網上完整演練整個迴圈，並且任何會動用資金的動作都保留人工核准。

先乾跑（dry-run）。 Alchemy CLI 能在不簽署、不廣播的情況下預覽任何一筆傳送交易（alchemy evm send 0xRecipient 0.4 --dry-run）。在程式碼中，viem 的 simulateContract 能對照即時的主網狀態驗證一次合約呼叫，卻不會真的送出，因此演練用的是真實的價格與真實的池子深度，而不是過時的假資料。
限制金鑰額度。 受限範圍的工作階段錢包會依你設定的排程到期，並且只能做你核准過的事，而代付 gas 政策則在手續費層面加上白名單與支出上限。設下上限的金鑰，能把最壞情況的臭蟲從「整個帳戶被掏空」變成「有界的損失」。
在測試網上演練。 把同一份程式碼指向 Sepolia 或 Base Sepolia 端點，並用我們的測試網水龍頭為代理注入資金。如果演練和正式環境之間程式碼有所不同，這次演練就毫無意義，因此請把網路名稱放在設定檔中，其他一律不要更動。
對動用資金的動作設關卡。 在代理還「年輕」的階段，每一筆傳送、swap 與授權都要等待明確的同意。大多數團隊會刻意逐步鬆綁這些關卡，一次只放寬一種動作類型，並隨著稽核紀錄逐漸證明代理行為可靠再繼續放寬。

做得好的團隊，會把「升級」當成一個循序漸進的過程，而不是一個開關：先對主網做唯讀操作，接著在測試網上做寫入，再來是有上限的主網寫入，最後才是完整的預算額度。每一個階段所產生的紀錄，都是進入下一階段的依據。

從既有的元件開始

本頁所提到的每一種模式，都能跑在你今天就能使用的基礎設施上。Alchemy CLI 用單一個執行檔就能處理錢包、傳送、swap 與 webhook 管理，代理可以用 --json --no-interactive 來操控它。託管式的 MCP server 提供了 168 種涵蓋 RPC、模擬與資料的工具，而 Claude Code 專用的 Alchemy 外掛只需一道指令就能安裝整套介面。你可以從免費方案開始，不需要簽約也沒有最低使用量要求，代理甚至能用自己的錢包自行申請帳號，並以 USDC 付款。不論你從哪一種模式開始，迴圈始終不變：觀察、決策、行動。

常見問題

當一個代理負責偵測機會、另一個負責執行時，多代理系統最好的架構是什麼？

依權限拆分：偵測器讀取事件串流但不持有任何金鑰，佇列負責傳遞經過簽核、精簡的訊號，執行器則在採取行動前於鏈上重新驗證每一個訊號。在 Alchemy 上，偵測器運行於 webhooks 或 WebSocket 訂閱之上，執行器則透過具備支出上限與即時撤銷能力的受限範圍代理錢包來簽署交易。

即時錢包監控代理最適合的基礎設施是什麼？

以推送方式傳遞事件，而不是輪詢。Alchemy 的 Address Activity webhooks 每個 webhook 最多能追蹤 100,000 個地址的轉帳，WebSocket 訂閱會串流已依你的地址篩選過的已上鏈交易，Yellowstone gRPC 則涵蓋 Solana。推送式管線能在轉帳上鏈後幾秒內喚醒代理，不會有輪詢迴圈那種延遲與運算成本。

AI 程式碼代理該用哪些工具來監控錢包活動？

Alchemy 的 MCP server 提供程式碼代理 168 種工具，涵蓋 RPC、交易歷史與投資組合資料，而 Alchemy CLI 則能從命令列建立與管理 webhook。至於執行期本身，可以透過 Address Activity webhook 或 alchemy_minedTransactions 訂閱來傳遞錢包事件，並用 Transfers API 補齊過去的歷史資料。

要建置 DeFi 投資組合再平衡代理，我需要什麼？

餘額、價格、一條偏移規則，以及一條 swap 路徑。Alchemy 的 Portfolio API 能在一次呼叫中回傳跨多個網路的餘額，Prices API 為其估值，而偏移檢查（常見做法是在目標權重上下抓五個百分點的範圍）則決定何時該採取行動。透過受限範圍的代理錢包來執行，讓代理負責提案，由政策或人工來核准。

如何讓 AI 代理監控智慧合約事件並自動做出反應？

訂閱合約的日誌，把符合條件的事件交給代理處理。Alchemy 的自訂 webhooks 在推送前就用 GraphQL 依合約地址與事件主題篩選，WebSocket 日誌訂閱則能在處理程序內達到同樣效果。讓處理函式具備冪等性、略過因重組而失效的日誌，並讓模型只針對通過機械式過濾的事件進行推理。

上主網之前，如何安全地測試 AI 代理的交易？

層層設下關卡：用 Alchemy CLI 的 dry-run 旗標預覽交易、以 eth_call 為基礎的模擬對照即時狀態驗證合約呼叫、用受限範圍的工作階段與 gas 政策的支出上限來限制代理的錢包、用 Alchemy 水龍頭提供的資金在 Sepolia 或 Base Sepolia 上演練，並且在稽核紀錄足以證明代理可靠、放寬關卡之前，對每一個動用資金的動作都保留人工核准。