以太坊代理：一个为代理在以太坊中自主运行而设计的Typescript SDK

以太坊 作为一个通用的金融后端而出现，它降低了构建金融服务的成本和复杂性，同时提高了其速度和安全性。几十年来，互联网加速了通信，但没有创建一个中立的系统来定义所有权或强制履行义务。以太坊通过将这些问题嵌入到具有经济和密码学保证的软件中来解决这些问题。最初，该基础设施被设计成由人类操作。人工智能的兴起引入了代理，作为辅助人类执行任务的工具。随着人工智能代理过渡到自主行动，它们与金融基础设施的交互需要重新思考界面设计。大多数以太坊库都是为人类开发者设计的，他们在签名之前会审查交易。这些库不能保证防止自主操作所独有的故障模式。

为了解决这些架构缺陷，我们构建了 eth-agent，这是一个从第一性原理设计的 typescript SDK，用于自主的以太坊交互，其安全约束不是可选的中间件，而是执行模型的基础。

这是帮助以太坊成为现代金融系统支柱的更大努力的一部分。我们正在构建 ethrex（一个用 Rust 编写的极简高性能以太坊执行客户端，也可以用作 L2 客户端，并且是从头开始构建的 ZK 原生客户端）、ethlambda （一个用于 Lean Ethereum 的共识客户端）、带有 Aligned 的 lambda-vm（一个零知识虚拟机，它将允许我们在 Lean Ethereum 框架内证明 ethrex 执行的正确性）、lambdaworks 和现在的 eth-agent。

机构差距

以太坊提供了互联网所缺乏的东西：一个用于定义所有权和强制履行义务的中立系统——一个具有可编程执行环境和密码学强制执行的共享账本。新的金融服务获得了即时规模，因为它们可以依赖于无需许可且 24/7 运行的基础设施。然而，以太坊假设用户是有能力的。它假设任何签署交易的人都打算签署它。它假设调用者理解了他所批准的内容。当人类直接操作基础设施时，这些假设成立（即使如此，人类操作员也犯了一些大错误）。当人工智能代理代表人类运行时，这些假设就会失效。

代理可能会幻觉出一个地址。它可能会误解“发送 100”为 100 ETH 而不是 100 美元。它可能会受到提示注入的操纵。它可能会错误地处理小数，并发送比预期金额多一百万倍的金额。每种故障模式单独来看都不太可能。但总体而言，在数百万次的代理操作中，它们变成了必然。与传统金融不同，没有追索权。无法致电银行。无法撤销交易。无法提交争议。资金就这么没了。

现有库的问题

现有的以太坊库（如 ethers.js、viem、web3.js）是为人类开发者构建的，他们在签名之前会审查交易。它们不能防止自主操作所独有的故障模式。

考虑一下当人工智能代理使用 ethers.js 发送交易时会发生什么：

const wallet = new ethers.Wallet(privateKey, provider);
const tx = await wallet.sendTransaction({
  to: ensName,
  value: parseEther(amount)
});

此代码没有支出限制的概念。没有人类批准的机制。它会产生诸如 UNPREDICTABLE_GAS_LIMIT 之类的错误或 LLM 无法有意义地解释的十六进制编码的还原数据。该库假设有一个人在循环中。当没有人的时候，失败是无声的或灾难性的。问题在于它是为不同的威胁模型设计的。我们需要假设调用者可能是一个大规模运行的不可靠推理系统的库。

代理安全的两种方法

业界对这个问题产生了两种回应。

第一种方法是构建工具供人类监督代理。仪表板、批准队列、审计日志。人类仍然参与其中，在执行之前审查代理建议。这保持了安全，但牺牲了代理的主要优势：规模。如果每笔交易都需要人工审查，那么你就有了一种生成交易建议的昂贵方式，而不是一个自主系统。

第二种方法是构建护栏——拒绝危险操作的运行时检查。支出限制、允许列表、健全性检查。这允许在边界内进行自主操作。但护栏只是更多的代码，而代码有错误。

eth-agent 采用第二种方法，但有一个重要的区别：我们将受信任的表面积最小化到一个小的、可审计的约束引擎，而不是将安全检查分散在大型代码库中。约束引擎是唯一必须正确的代码。其他一切都可能失败，而不会产生灾难性后果。

设计原则

eth-agent 构建在三个原则之上：

1. 安全约束不是可选的

每个钱包实例都带有支出限制，调用代码无法绕过这些限制。如果交易超过每日限额，则会因结构化错误而失败，无论代理提出什么要求：

const wallet = AgentWallet.create({
  limits: {
    perTransaction: '0.1 ETH',
    perHour: '1 ETH',
    perDay: '5 ETH',
  },
});

这不是一个建议。代理无法导入不同的模块或修改配置来规避这些限制。安全边界在库中，而不是在应用程序中。

2. 错误的结构化是为了机器消费

每个异常都带有机器可读的元数据：

{
  code: 'DAILY_LIMIT_EXCEEDED',
  message: 'Transaction would exceed daily limit',
  suggestion: 'Reduce amount to 2.5 ETH or wait until 2024-01-16T00:00:00Z',
  retryable: true,
  retryAfter: 14400000,
  details: {
    requested: { eth: '5' },
    remaining: { eth: '2.5' }
  }
}

代理可以以编程方式确定是否重试、等待多长时间以及如何向用户解释失败的原因。这是 catch (e) { throw e } 和 catch (e) { return scheduledRetry(e.retryAfter) } 之间的区别。

3. 架构上支持人工监督

对于高价值操作，该库支持批准回调，该回调会暂停执行，直到有人响应：

const wallet = AgentWallet.create({
  onApprovalRequired: async (request) => {
    return await askHuman(request.summary);
  },
  approvalConfig: {
    requireApprovalWhen: {
      amountExceeds: '0.1 ETH',
      recipientIsNew: true,
    },
  },
});

这不是你稍后添加的 Webhook。批准流程是交易生命周期的一部分，如果拒绝批准，代理会收到结构化的拒绝。

约束如何防止失败

考虑一下前面提到的故障模式。每种故障模式都需要特定的防御措施。

幻觉地址。 代理可能会生成一个看似合理但不正确的地址。 eth-agent 提供了两种防御措施：一个拒绝已知恶意地址的阻止列表，以及一个仅将传输限制为预先批准的接收者的允许列表模式。在允许列表模式下，代理无法发送到未经配置钱包的人明确授权的任何地址。

金额混淆。 当用户想要 100 美元时，代理可能会将“发送 100”解释为 100 ETH，或者错误地处理Token小数。 eth-agent 的稳定币助手将金额解析为Token的原始单位。例如，amount: '100' 表示 100 USDC，而不是 100 × 10^6 个原始单位。对于 ETH，金额需要明确的单位：'0.1 ETH' 或 '100 GWEI'。解析器拒绝不明确的金额。

提示注入。 攻击者可能会精心制作输入，指示代理耗尽钱包。 eth-agent 的约束引擎看不到提示。它只看到建议的交易。任何指令都不能覆盖限制。如果每日限额为 1 ETH，则无论其上下文窗口中出现什么文本，代理都无法发送 2 ETH。

重复的小额交易。 代理可能会通过许多单独看起来合理的小额发送来耗尽钱包。 eth-agent 维护支出历史记录的滚动窗口。每小时限制聚合过去一小时内的所有交易；每日限制聚合过去 24 小时内的交易。一千笔 0.001 ETH 的交易与一笔 1 ETH 的交易一样达到限制。

失控支出。 循环中的代理可能会在任何人注意到之前耗尽整个余额。当支出超过初始余额的百分比（可配置，默认为 50%）时，紧急停止触发。最低余额保护确保永远不会触及准备金。这两个约束都会暂停所有操作，直到有人干预。

这些不是功能。它们是约束。价值在于它们阻止的东西。

稳定币作为一等公民

处理付款的自主代理需要稳定币，而不是波动性资产。 eth-agent 提供对 USDC、USDT、USDS (Sky)、DAI、PYUSD 和 FRAX 的内置支持，并具有人类可读的金额：

import { AgentWallet, USDC } from '@lambdaclass/eth-agent';

// 发送 100 USDC (不是 100 * 10^6)
await wallet.sendUSDC({ to: 'merchant.eth', amount: '100' });

// 内置多链支持
const balance = await wallet.getStablecoinBalance(USDC);
console.log(balance.formatted);  // "1,234.56"

小数处理是自动的（USDC 使用 6 位小数，USDS 使用 18 位小数），并且地址是按链解析的。代理可以请求 sendUSDC({ amount: '100' })，而无需了解Token的小数或查找合约地址。这是一种可以防止昂贵错误的抽象。

ERC-4337 和账户抽象

eth-agent 包括对智能账户 (ERC-4337)、捆绑器和支付方的 first-class 支持：

const smartAccount = await SmartAccount.create({
  owner: EOA.fromPrivateKey(key),
  rpc,
  bundler,
});

await smartAccount.execute([\
  { to: addr1, value: ETH(0.1), data: '0x' },\
  { to: addr2, value: ETH(0.2), data: '0x' },\
]);

会话密钥支持具有有限权限的委托签名——代理可以被授予在一个小时内为特定合约地址签署高达 0.1 ETH 交易的权限，并具有最大交易计数。当会话过期或达到限制时，签名会干净地失败。

最小依赖

eth-agent 依赖于两个运行时包：

• @noble/secp256k1 — ECDSA 操作
• @noble/hashes — Keccak256, SHA256

两者都经过审计，由 @paulmillr 维护，并且不包含传递依赖项。我们不依赖于 ethers.js、viem 或 web3.js。核心密码学原语（如 RLP 编码、ABI 编码、交易签名）是直接实现的。

这是一个深思熟虑的选择。依赖膨胀是一种安全责任，自主系统应尽量减少其攻击面。

与现有方法的比较

一些框架使人工智能代理能够与区块链交互。它们在优化目标方面有所不同。

Coinbase AgentKit 优化了广度。它提供了数十种操作，涵盖Token传输、交换、NFT 操作和合约部署。它与 Coinbase 基础设施深度集成，包括用于密钥管理的 Smart Wallet 和通过支付方进行的无 Gas 交易。隐含的模型是一个需要做许多不同事情的代理，其安全性委托给 Coinbase 平台层。

GOAT SDK 优化了 DeFi 可组合性。它提供了 200 多个集成，将代理连接到 30 多个区块链上的借贷协议、AMM、收益聚合器和预测市场。隐含的模型是一个执行复杂金融策略的代理，其安全性委托给配置策略的人。

eth-agent 优化了安全保证。它提供的操作较少（基本传输、Token操作、余额查询），但每个操作都受到无法绕过的限制的约束。隐含的模型是一个即使发生故障也不能造成灾难性损害的代理。eth-agent 还将添加 DeFi 可组合性和更多应用程序，但首先要保证安全性。

设计理念

安全约束

下表显示了 eth-agent 作为执行路径的内置、架构属性提供的约束。这些约束类别反映了我们认为代理安全所需要的。其他框架可能会以不同的方式处理安全性，例如通过平台级控制、钱包提供商功能或应用程序级实现。

“应用程序级别”表示该框架不包含此约束，但开发人员可以在其应用程序代码中实现它。区别在于安全性是框架的属性还是每个应用程序的责任。

支持的操作

eth-agent 有意排除了复杂的 DeFi 操作。每增加一种操作类型都会增加错误的表面积。对于需要兑换或收益策略的代理，eth-agent 可以与其他框架结合使用。例如，使用 eth-agent 进行受约束的价值转移，使用另一个框架进行 DeFi 执行。

基础设施

AI 框架支持

框架集成

OpenAI、Anthropic 和 LangChain 的适配器将钱包操作转换为这些框架可以调用的函数定义：

import Anthropic from '@anthropic-ai/sdk';
import { anthropicTools } from '@lambdaclass/eth-agent/anthropic';

const tools = anthropicTools(wallet);

const response = await anthropic.messages.create({
  model: 'claude-sonnet-4-20250514',
  tools: tools.definitions,
  messages: [{ role: 'user', content: 'Send 0.01 ETH to vitalik.eth' }],
});

这些工具公开了 get_balance、send_transaction、preview_transaction 和相关操作。无论哪个框架调用它们，安全限制都适用。

执行层论点

人工智能代理将会改进。它们将减少幻觉，更好地理解上下文，更有效地抵抗操纵。但它们永远不会是完美的。任何依赖于代理正确性的系统最终都会失败，并且在金融环境中，失败意味着永久损失。

解决方案不是让代理更智能。解决方案是使执行层不可能被滥用。

┌─────────────────────────────────────────┐
│              AI Agent                   │
│  (imperfect, improving, fallible)       │
└──────────────────┬──────────────────────┘
                   │ proposes action
                   ▼
┌─────────────────────────────────────────┐
│     Constrained Execution Layer         │
│  (bounded, deterministic, auditable)    │
└──────────────────┬──────────────────────┘
                   │ only valid actions pass
                   ▼
┌─────────────────────────────────────────┐
│        Irreversible Settlement          │
└─────────────────────────────────────────┘

代理可以提出任何操作。执行层进行过滤。只有满足所有约束的操作才会到达区块链。代理仍然有用、有创造力、灵活。执行层仍然安全、有界、可预测。

这类似于操作系统如何处理不受信任的代码。内核不相信应用程序会正确运行。它强制执行内存隔离、权限检查、资源限制。应用程序可能有错误或恶意，但由于内核约束是架构上的，而不是策略上的，因此系统保持稳定。

eth-agent 将此原则应用于金融操作。代理是不受信任的代码。钱包是内核。约束是架构上的。

迈向形式化验证

当前实现通过运行时检查来强制执行约束。这比没有约束更好，但约束引擎仍然是可能存在错误的代码。我们正在探索使用 Lean 进行形式化验证，以使安全保证在数学上而不是经验上，证明“每天的支出不能超过 X”，而不是关于它的声明。

这不会验证代理。代理仍然未经验证、不可预测，能够提出任何东西。经过验证的是过滤器——站在代理提案和区块链结算之间的执行层。

结论

以太坊提供了互联网所缺乏的金融基础设施。人工智能代理提供了可以大规模使用该基础设施的操作员。缺失的部分是为代理作为操作员设计的执行层，而不是作为人类和区块链之间的中介，而是作为实际执行交易的人，以及所有由此产生的约束。

eth-agent 提供了这一层。不是通过让代理更智能，而是通过使系统在代理行为方式如何的情况下都是安全的。约束不是建议。它们是执行路径的结构属性。

代理提出。系统处理。只有安全的操作才能到达链。

• 原文链接： blog.lambdaclass.com/eth...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～