Pimlico：替 Agent 付 Gas，为什么不等于限制它花钱

Agent 有足够的 USDC 付给供应商，却没有网络原生 Gas 代币。如果运行着很多小钱包，为每一个补充第二种资产会增加运维工作。Pimlico 处理的是这笔交易的执行费用问题，应用仍然需要钱包、签名器，以及签名器究竟能做什么的规则。

资料边界： 本文于 2026 年 11 月 1 日核对官方文档，没有给 Pimlico 账户充值，也没有提交 UserOperation。下文是设计选择与验收建议。

先把 Paymaster 放到正确的位置

Pimlico 文档把 Paymaster、Bundler 和 permissionless.js 工具分开介绍，Alto是其 ERC-4337 Bundler 实现。在 EVM 智能账户接入中，这些组件帮助代付和提交操作，并不取代账户所有者或签名服务。

Agent 接入指南使用外部提供的签名器控制智能账户。示例选择 Safe，由 Pimlico 提供 Bundler 与 Paymaster。它是一种文档化配置，并不意味着任意账户和 EntryPoint 版本都能随意混搭。

允许付款，与愿意代付，是两次不同判断

EVM 代付流程概念示意，非支付实测。具体准备步骤取决于账户与 SDK 接入方式。

钱包授权回答“Agent 能不能执行这个调用”；代付判断回答“某个预算是否承担这次执行费用”。Gas 额度很小，不代表代币转账额度也很小。反过来，一笔符合钱包授权的付款，也可能因为代付拒绝而无法继续。

给供应商付款的 Agent，应分别检查这两项控制。先限制签名器允许执行的操作，再设置代付预算。如果产品承诺总购买金额上限，就应指出钱包或应用里执行该限制的机制，而不是展示一张 Paymaster 策略截图。

代付策略究竟限制什么

策略指南介绍了总体、按用户以及按操作的代付限额。不符合规则时，服务返回错误，而不是继续代付。这可以保护运营方的 Gas 预算，尤其适合防止 Agent 不断尝试同一项失败任务。

我们的建议是，把 Agent 或租户映射到服务实际计量的身份。若多个任务共用一个账户，账户级用量未必能说明是哪项业务耗掉了额度。应用应保留任务与操作的关联，用于成本归属和异常调查。

Pimlico 也提供用 ERC-20 代币支付 Gas 的路径。改变费用资产与承担者，并没有让费用消失。“不需要 ETH”不应悄悄变成“用户不用付任何费用”。

切换费用承担方，需要产品层明确决定

Agent 指南有一个从代付失败回退到使用 Agent USDC 的例子。采用之前，要确认用户已经同意用这部分余额支付执行费用。一个笼统的捕获异常再重试，可能掩盖实际原因究竟是预算不足、请求格式错误，还是服务暂时失败。

更明确的产品约定是：停止并解释、转人工处理，或者使用事先批准的费用回退方案，并记录实际选择。不能把一次意外收费，作为修复无关错误的默认手段。

失败或状态变化	应该验收的问题
代付额度耗尽	停止任务，还是使用已明确批准的付款方？
操作上链但执行回退	显示执行失败，还是误报“已付款”？
多个进程使用同一账户	nonce 管理是否支持当前并发方式？
商家未交付	能否把支付回执与交付争议分开记录？

保护能够消耗 Gas 预算的密钥

Pimlico 的 API Key 保护指南提醒，泄漏的代付密钥可能被用于任意操作。浏览器来源或 user-agent 限制，并不构成完整的秘密保护边界。官方建议由持有密钥的后台验证操作，并配合支出策略。

代理服务也必须检查自己转发的内容。如果只是隐藏密钥，却接受调用者任意构造的交易，预算仍可能暴露。策略管理权限应与普通 Agent 执行路径分离，异常代付需要可观察，但不能因此把钱包秘密写入日志。

Pimlico 适合放在哪一层

如果应用希望自行选择签名器和智能账户，同时把打包与 Gas 支付交给基础设施服务，Pimlico 值得评估。比较时应把它作为执行组件，而不是完整 Agent 钱包或商家计费系统。

相关资料见 Pimlico 目录页与额度设计。有说服力的演示应同时展示成功代付，以及拒绝后用户资产和运营预算仍留在预期边界内的情况。