链上 AI 代理架构:五种构建模式
作者 Uttam Singh

能够读写链上状态的 AI 代理已经从演示走向生产环境。模型可以推理,代理钱包可以在受限权限下签名,基础设施可以在事件上链后几秒内将其推送给代理。架构仍是构建中最容易出错的部分。代理去轮询本可订阅的事件、在读取不可信输入的同一进程中持有签名权限,或是用真实资金在主网上进行学习。
链上代理是一个循环:观察、决策、行动。生产环境中的代理将这个循环组织成五种常见形态,下文对每一种都给出了实例。我们的链上代理构建指南介绍了这些形态背后共用的基础组件(钱包、支付通道、数据源);本文要讲的是如何组织这些组件。
如何构建实时钱包监控代理?
用 webhook 注册你关心的地址,让链上事件主动推送给你,而不是自己去轮询。循环轮询余额既消耗算力,又依然会错过时机。推送管道能在转账上链几秒内送达,而这正是监控代理的全部工作。
假设某个代理跟踪一支基金的交易对手钱包,并标记任何大额 USDC 转移。在 Alchemy 上,单个Address Activity webhook即可覆盖原生代币、ERC-20、ERC-721 和 ERC-1155 的转账,最多支持100,000 个地址,因此一个 webhook 就能监控整份交易对手列表。如果代理以长期运行的进程方式存在,且不想暴露公网 URL,WebSocket 订阅可以在进程内完成同样的工作。用 alchemy_minedTransactions 订阅,你拿到的就是已确认、且已按地址过滤好的交易,无需再解析日志。在 Solana 上,Yellowstone gRPC 流式接口以每 TB 75 美元的价格填补同样的位置,并支持无缝重连。如果不确定该用哪种传输方式,我们的webhooks 与 WebSockets 与 gRPC 对比对此有详细说明。
处理函数本身应当尽量做少事情。先验证投递确实来自 Alchemy,去重,把事件交给代理的决策步骤,最后才确认收到:
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 上有两种方式覆盖这个场景。自定义 webhook接受 GraphQL 过滤条件,你可以按合约地址和事件 topic 匹配,只接收你要求的日志。这适合无服务器的响应器。对于长期运行的代理,WebSocket 日志订阅可以把一切都放在同一个进程里。下面是一个监控 Uniswap v3 池子的响应器,这类信息流正是交易代理用来察觉单笔 swap 是否已经推动价格变动的方式:
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 这个检查的重要性超出其表面看起来的样子。链会发生重组,几个区块之后,代理已经据以行动的某条日志可能会从规范链上消失。幂等的处理函数加上确认深度规则(在执行不可逆操作前等待若干区块)是标准的防御手段。响应器的另一条准则和监控代理相同:订阅过滤条件负责低成本的筛除,模型只看到通过筛选后存活下来的事件。
构建 DeFi 投资组合再平衡代理需要什么?
四个要素:当前余额、当前价格、一条偏离规则、一条 swap 路径。代理读取前两项,检查第三项,只有在规则被触发时才动用第四项。
以一个持有 WETH、USDC、WBTC 按 50/30/20 比例分配的国库代理为例。余额由Portfolio API提供,它在一次请求中返回某个钱包在多条网络上的代币情况,而不需要为每条链分别发起调用。估值由Prices API提供。偏离规则是算术运算,常见的起点是围绕每个目标权重设定五个百分点的区间。按计时器检查这条规则,因为偏离多数来自价格变动而非代币变动,而价格变动不会产生任何可供响应的链上事件。监控代理(模式一)报告的转账,则是补充触发条件,能在存取款发生的瞬间捕捉到。
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
}
}执行端不应持有原始私钥。通过受限权限的代理钱包,密钥留在托管方手中,会话只携带你所授予的能力。花费一笔 ERC-20 之前,需要先给路由合约授权额度。每次只按精确金额授权会多付一笔交易,但不会给攻击者留下可被盗用的常驻额度:
# 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 余额。
构建检测-执行分离的多代理系统,最佳架构是什么?
按权限而非按工作负载来划分代理。检测器可以读取一切,但不能签署任何东西。执行器负责签署交易,且不相信任何未经它重新验证的内容。
可以把它想象成分析师和交易员的关系。分析师整天盯盘,可以和任何人交流。交易员接收分析师的建议,核实后才采取行动,账户访问权限只属于交易员。
这种模式的流行框架来自通用的代理工具体系,在那里规划模型生成步骤,由执行代理运行工具。那种框架关注的是编排问题。而在链上,这种划分之所以值得为之增加复杂度,是出于一个更棘手的原因——托管权。检测器整天消费不可信的输入:内存池噪音、第三方 API、事件流,有时还有社交媒体信息流。这些都可能携带提示注入攻击。如果读取恶意输入的进程同时也持有签名权限,一条被污染的消息就可能变成一笔已签名的交易。把两者分开,被劫持的检测器最坏也只能提出一个被执行器丢弃的糟糕建议。
检测器由模式一和模式二构成,接入推送式基础设施而非轮询循环。它通过队列发出信号,这个队列同时也充当审计日志。让信号的内容结构保持简单且可验证:
{
"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)、限制密钥可支配的额度、在测试网上完整演练整个循环、并对任何涉及资金转移的操作保留人工审批。
- 先空跑。 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在 RPC、模拟和数据方面暴露了 168 个工具,面向 Claude Code 的 Alchemy 插件可以一条命令安装整个工具面。你可以从免费套餐开始,无需签约、无最低消费,代理甚至可以用自己的钱包自助注册并用 USDC 付费。无论从哪种模式入手,这个循环始终不变:观察、决策、行动。
常见问题
检测型代理与执行型代理分离的多代理系统,最佳架构是什么?
按权限划分:一个只读取事件流、不持有任何密钥的检测器;一条承载少量已签名信号的队列;一个在行动前会重新在链上验证每条信号的执行器。在 Alchemy 上,检测器运行在 webhook 或 WebSocket 订阅之上,执行器则通过带支出上限和即时撤销能力的受限权限代理钱包完成签名。
实时钱包监控代理最适合用什么基础设施?
基于推送的事件投递,而非轮询。Alchemy 的 Address Activity webhook 可以在每个 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 的自定义 webhook 会在投递前用 GraphQL 按合约地址和事件 topic 过滤,WebSocket 日志订阅在进程内完成同样的工作。让处理函数具备幂等性,跳过因重组而失效的日志,只让模型对通过机械过滤的事件进行推理。
在上主网之前,如何安全地测试 AI 代理交易?
分层设置关卡:用 Alchemy CLI 的 dry-run 参数预览交易,用基于 eth_call 的模拟功能针对实时状态验证合约调用,用受限会话和 gas 策略支出限制约束代理的钱包,在 Sepolia 或 Base Sepolia 上用 Alchemy 水龙头提供的资金演练,并在每一笔涉及资金移动的操作上保留人工审批,直到审计日志积累出足够依据后再放宽关卡。
相关概览
基础设施2026年9月10日
用于构建自主链上代理的最佳区块链 API
对比主流区块链 API 服务商在自主链上代理场景下的表现,涵盖面向代理的原生功能、链覆盖范围,以及当你的用户是机器时真正重要的能力。
DeFi2026年6月12日
什么是 DeFi AI 智能体?用例、风险与架构
DeFi AI 智能体(也称为 DeFAI 智能体)是一种自主系统,能够在策略控制下进行推理、签名并完成链上结算。
技术2026年5月19日
Webhooks、WebSockets 与 gRPC 对比
实时数据传输主要由三种协议主导。本文介绍 webhooks、WebSockets 和 gRPC 的区别、各自的局限,以及如何在它们之间做选择。

构建区块链应用
Alchemy 将最强大的 Web3 开发者产品和工具与资源、社区及专业支持结合在一起。