ERC-8211链上代理执行标准

ERC-8211 由 Biconomy 与 Ethereum Foundation Protocol’s Improve UX 团队共同开发。

非托管执行：链上 Agent DeFi 的先决条件

AI Agent 已不再仅仅是实验。它们正在自主地管理国库、执行交易、重新平衡投资组合，并与 DeFi 协议进行交互。Virtuals、Bankr、AskGina 等团队正在不断突破边界——从收益再平衡到自主交易策略，链上 Agent 经济正在真实且快速地增长。

虽然领先团队在不断探索，但现实是，目前生产环境中的大多数 Agent 仍默认执行简单的支付和 Swap。这并非因为它们缺乏智能，而是因为缺乏一种标准化的方式来表达更复杂、更具表现力的操作。每个想要超越基础转账和 Swap 的团队，都必须从头开始构建自己的执行栈。结果导致了实现方案的碎片化、重复劳动，以及不同服务商之间缺乏可组合性。

Agent 应当能够像在推理过程中那样流利地在链上执行策略，调用任何合约或服务，并默认具备可组合性和链上安全保证。ERC-8211 的目的不是取代现有团队的成果，而是为生态系统提供一个可组合、多步骤执行的共享标准，使链上执行层能够始终跟上其上层智能层的复杂性。

智能层已经飞速发展，但执行标准尚未跟上。

核心问题：动态世界中的静态执行

对比 Agent 处理日常复杂工作流（如链式 API 调用、处理变量输出、根据条件分支）的方式与目前链上执行的方式，可以发现巨大的差距。这种差距源于目前的 Batch Execution 模式。

无论是通过 ERC-4337 还是 EIP-5792，目前的 Ethereum 批量执行都是静态的。所有参数在签名时就已固定，Calldata 在触达链上之前就已完全编码。然而，DeFi 是动态的：

• Swap 输出取决于执行那一刻的 Slippage。
• Bridge 在不可预测的延迟后交付 Token，且费用多变。
• 借贷池的份额与资产比例在持续波动。

举个简单的例子：Agent 想在 Ethereum 上将 1 ETH Swap 为 USDC，然后将所有 USDC 存入 Aave。在今天，它必须预估 Swap 输出（例如 2,000 USDC），并在签名之前将该数值硬编码到存款调用中。如果由于 Slippage 实际只返回了 1,980 USDC，存款调用会尝试存入 2,000，导致失败并使整个 Batch 交易回滚。如果为了安全起见预估为 1,950，剩余的 30 USDC 就会闲置在账户中。目前没有办法简单地表达“存入我实际收到的所有金额”。

静态批量处理迫使开发者做出糟糕的选择：要么硬编码一个乐观的金额并冒着回滚的风险，要么保守估计并导致价值留存。唯一的解决方法是为每个多步骤流程部署定制的智能合约，但这带来了新的攻击面、审计成本，且每次策略更改都需要重新部署。此外，每个管理链上执行的团队都面临着相同的底层负担：Nonce 排序、Gas 管理、RPC 可靠性，且每个人都在独立重复构建。

ERC-8211：Smart Batching

ERC-8211 是一项新的 Ethereum 标准，由 Biconomy 和 Ethereum Foundation 共同开发。它通过运行时解析（Runtime-resolved）和约束验证（Constraint-validated）执行，对静态批量执行进行了根本性的增强。

核心理念很简单：在 Smart Batching 中，每个参数声明两件事：

1. 如何在执行时（而非签名时）获取其值。
2. 在该值被使用前必须满足什么条件。

在执行时，EVM 从实时链上状态解析每个参数，根据内联 Constraint 进行验证，并从头构建 Calldata。没有预编码的 Calldata，没有过时的数据，也不会因为过时的估算而导致回滚。

Fetchers

Fetcher 在执行时解析数值。参数可以读取任何链上状态——Token 余额、预言机价格、流动性池比例、任何合约视图函数的返回值——并将实时结果注入 Calldata。标准提供了一个通用的 Fetcher 来调用任何合约，并为最常见的余额查询提供了便捷缩写。

Constraints

Constraint 是安全层。每个解析出的数值都可以携带内联断言（如最小金额、最大上限、范围边界），并在使用前在链上强制执行。如果 Constraint 失败，整个 Batch 交易将回滚。这确保了如果解析出的余额为零，不会静默通过并导致后续经济损失，而是安全地失败。

Predicate Entries

Predicate Entry 是链上状态的纯布尔门控，这是 Smart Batching 与现有执行模型的根本区别。Predicate Entry 不发起调用，它只是在执行前检查链上条件是否满足。

例如，Agent 想要退出 Ethereum 上的金库并在 Base 链上接收 USDC。通过 Smart Batching，用户在 Ethereum Batch 中发起跨链。Base 链的 Batch 包含一个 Predicate Entry，检查：“我的 USDT 到账了吗？”中继器模拟该 Batch——如果资金未到，Predicate 失败，中继器等待。资金到账的瞬间，模拟成功，中继器提交交易。Swap 自动执行，将到账的所有 USDT 转换为 USDC。一次签名即可覆盖整个跨链流程。

开发者与 Agent 的全新体验

对于开发者，体验发生了彻底改变：

• 无需编写 Solidity 代码。
• 无需为每个流程部署合约。
• 无需为每个策略进行审计。
• 操作完全通过 SDK 在 TypeScript 中组合，编译为标准链上编码，签名一次，由 EVM 执行。

对于 Agent，这是缺失已久的执行标准。Agent 可以将整个多步骤 DeFi 策略表达为一个简单的离线脚本，并内置安全性。这意味着没有编程经验的用户也可以让 Agent 构建完整的链上工作流。用户审核后签名一次，即可自动执行，无需处理链上复杂性。由于用户已经签署了精确的工作流，Agent 在交易过程中无法产生“幻觉”。

这种“预设/后置条件”模型使该标准成为 Agent 原生的。Agent 可以设置一个 Batch：“在跨链资金到账前不要执行”（预置条件），然后“使用实际到账的金额进行 Swap 和供应”（运行时解析），最后“如果最终余额没有增加则回滚一切”（后置条件）。Agent 负责推理，基础设施负责处理不确定性。

应用场景

Smart Batching 将交易转化为程序。以下是部分应用场景：

• 无粉尘全额操作：始终发送或供应当前的精确余额，不留残余价值。
• 单次签名完成多步 DeFi 流程：Swap、供应、质押——每一步都使用前一步的实际输出。
• MEV 感知的执行门控：在调用前约束预言机价格或资金池储备。
• Agent 盈利开关：要求执行后的账户余额高于执行前，确保每项操作都是净正向的。
• 跨链编排：在 L1 跨链，然后在 L2 兑换和借贷，由 Predicate Entry 等待状态变更。
• 单次调用实现循环杠杆：供应抵押品、借款、Swap、再供应，并在原子交易中完成。
• 带会话的委托执行：授予 Agent 一个受限会话（限时、限额、限合约），Agent 在框架内自主执行策略。

开放标准与兼容性

ERC-8211 是一项账户无关（Account-agnostic）的 Ethereum 基础设施。它支持：

• ERC-7579 账户（作为执行器模块）。
• ERC-6900 账户（作为插件）。
• 原生智能账户实现。
• ERC-7702 EOA 和普通 EOA。

它与 ERC-7683、ERC-4337 以及 Ethereum Foundation 支持的互操作标准兼容。它是 Ethereum 互操作和 UX 轨道的一部分，旨在对底层实现保持中和——这意味着任何 Swap 合约、DEX、Bridge 或存款函数都可以组合进 Batch 中。

此外，它也是 Ethereum 新兴 Agent 堆栈的一部分，与 ERC-8004（身份）、ERC-8183（商业）、x402（支付）共同协作，填补了执行层的空白，使 Agent 能够自主、安全地执行复杂策略。

参与构建

目前，规范的首个版本已发布，参考合约已开源。我们邀请开发者、协议团队和 Agent 构建者部署实现，将 Smart Batching 集成到框架中，并通过反馈共同完善这一标准。

如果你正在构建链上执行的 Agent，或希望实现可组合、动态集成的 DeFi 协议，ERC-8211 正是为此而设计的标准。

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