ERC-4337：一笔 Agent 支付怎样从 UserOperation 走到执行结果

采购 Agent 已拿到一张待支付账单，账户里也有付款用的代币，却没有支付 Gas 的原生代币。产品希望替用户承担网络费，同时让账户检查谁有权发起这笔付款。ERC-4337 能为这种设计提供执行路径，不过从点击支付到拿到结果，中间并非只有一次校验。

资料边界： 本文于 2026 年 11 月 1 日核对官方规范和文档。ERC-4337 状态为 Final。以下是架构分析，没有连接钱包或执行真实支付，也不包含性能实测。

一个支付按钮背后的四种角色

ERC-4337 使用 UserOperation 表达账户待执行的操作。Bundler 将符合条件的操作打包，发送到 EntryPoint 合约；账户的验证逻辑负责判断操作是否获得授权；可选的 Paymaster 决定是否承担 Gas。

接入时，四种角色不能混成一个“钱包服务”：账户掌握付款权限，Bundler 提供上链通道，EntryPoint 协调验证与执行，Paymaster 管理网络费资助。某个环节返回成功，不等于其他环节已经完成。

概念流程图，非实测结果。“准备账户授权”表示生成账户认可的授权材料，链上验证仍会经由 EntryPoint 发生。

消费规则要落到账户设计里

标准把签名的具体含义交给账户实现。不同授权方式因此能共用一套提交基础设施，但不能据此认定账户天然适合无人值守的 Agent。一个不受限制的签名者和一个限权的会话签名者，都可能走 ERC-4337 路径。

对这笔账单，先写清允许调用哪个支付合约、允许哪种代币、谁能签名、权限何时结束，再确认账户代码或策略组件在哪里执行这些要求。提示词中的预算约束是任务背景，不能代替实际的权限校验。

组件文档 说明了账户与特定 EntryPoint 的关系。接入记录应把网络、EntryPoint 地址与版本、账户实现、Bundler 支持范围放在一起。另一个版本的示例能运行，不代表当前组合已通过兼容性测试。

Gas 代付意味着多一本账

Paymaster 文档 描述了资助资格检查和 Gas 资金安排。账户允许购买账单，并不意味着赞助方愿意支付网络费；反过来，愿意承担 Gas 也不构成付款授权。

产品应分别记录付给商户的金额和执行所消耗的费用。代付不可用时，是暂停、询问用户，还是按事先约定使用用户资金？这会影响用户看到的成本，不能藏在自动重试里。

到达的阶段	应进一步确认什么
RPC 已接收操作	只是收到，还是已经上链
模拟被拒绝	账户、代付方或部署条件哪一项失败
打包交易已上链	其中这笔 UserOperation 的实际执行结果
付款已确认	对应账单及商户交付状态

这是一份建议的排查模型，并非某个服务商的实测返回值。

模拟通过只是一个检查点

Bundler 模拟文档 涉及提交前的账户、部署和 Paymaster 检查。Agent 服务应保留模拟诊断与原始操作的关联。如果重试修改了 nonce、代付条件或调用内容，就不能继续沿用原先的判断。

查询回执超时，也不应该直接产生第二笔购买。建议用一个业务操作编号关联 UserOperation 与链上交易编号，再核对尚未确定的尝试。这样，客服和后台才能区分“尚未查到”与“已确认失败”，而不是让模型猜测是否需要再付一次。

适合什么场景

需要可编程账户验证、灵活 Gas 支付路径的应用，可以把 ERC-4337 作为基础设施选择。代价是接入面更大：账户、Bundler、EntryPoint 和代付方都需要版本管理和故障处理。

对 Agent 支付产品，验收终点应是与账单关联的执行结果，而不是拿到第一个哈希。可继续查看 ERC-4337 目录条目、上层权限申请接口 ERC-7715 和 支付幂等设计。