ERC-7715：怎样给 Agent 钱包权限，并在需要时收回

一个研究 Agent 要在用户离线时购买几次数据。每次付款都弹出签名窗口，任务就无法连续进行；直接给它一把可以广泛转账的密钥，又把风险留给了用户。更实际的问题是：用户能否提前批准一小段权限，以及 Agent 真正花钱时，谁来检查这段权限？

资料边界： 本文根据 2026 年 11 月 1 日查阅的官方规范与实现文档整理。ERC-7715 仍为草案。下文是设计示例，本站没有连接钱包、授予权限或实际付款。

先说清楚任务需要多少权限

假设研究任务运行七天，每天最多使用 10 USDC。这是举例的预算，并非产品报价。发出请求之前，要确定资金所在的账户和链、替用户操作的会话账户，以及这笔额度允许完成哪些动作。如果任务只能向两个指定服务商买数据，单纯的代币转账额度可能仍然过宽。

ERC-7715 描述了申请权限、查询钱包支持哪些权限和规则、查看已授予权限及撤销权限的接口。开发者需要先确认所选钱包和网络的支持范围，不能假设每一种实现都有相同的限额或商户规则。

因此，接入顺序应该是先确认钱包能否表达任务边界，再请用户批准。如果缺少必要的商户限制，就要用另一个真正执行限制的控制点，或者缩小任务范围，不能悄悄省略用户提出的条件。

钱包确认与实际执行是两条路径

这是权限流程的概念示意，不是钱包实测结果。数据服务商验证付款、交付资源，还需要另外的流程。

允许调整时，钱包返回的授权可以与应用最初提出的请求不同。应用继续运行前，应读取实际返回的账户、范围、规则和有效期。响应还包括权限上下文及执行所需信息。如果页面一直显示“申请时的预算”，却没有读取真正获批的条件，用户看到的额度可能与后续行为不一致。

执行环节交给相应的委托机制。ERC-7710 描述了委托管理器检查权限、再调用授权账户执行操作的接口；最初怎样获得授权，则可以由 ERC-7715 等机制完成。做接入评审时，需要追到具体执行限制的合约和版本，不能只检查钱包里有没有出现确认页面。

一个实际实现还要补上什么

MetaMask 的申请流程 给出了会话账户和周期性代币权限的例子：用户在钱包中检查请求，应用保存返回的授权，供之后执行。这证明存在有文档的实现路径，但不能据此推断其他钱包也支持同名权限。

对产品团队来说，会话账户本身也需要管理。它的签名材料存在哪里、哪个服务可以使用、不同任务共用还是隔离、谁能立即停止，都应该在设计阶段回答。用户主密钥没有进入 Agent，并不意味着 Agent 手中的有限能力可以不受保护。

验收应覆盖权限整个生命周期

研究任务中的情况	应该验证什么
用户调低了申请的每日额度	应用是否显示并遵守返回的实际授权？
两个工作进程争用最后一笔余额	累计用量是否在并发请求之间得到统一约束？
排队的任务执行前，权限已经过期	是否停止并重新请求决定，而不是自行扩大权限？
用户撤销了授权	应用如何获取结果并停止后续提交？
购买操作已经提交	能否分清待执行操作与已经完成的付款？

这是一组建议验收的问题，不是已完成的测试。权限请求报错、模拟失败和链上拒绝，是不同阶段的问题，不宜都藏在一句“付款失败”后面。

MetaMask 的权限管理说明提供了用户撤销入口；委托规范也提醒，过去拿到的权限可能因撤销、过期或状态变化而失效，模拟与执行之间同样可能发生变化。因此，应用既需要用户看得懂的授权记录，也需要执行时的状态检查。不要把撤销权限描述成已完成购买的退款按钮。

什么情况下值得采用

当用户希望应用在后台或周期性执行有限任务，而且所选钱包有合适实现时，ERC-7715 值得纳入方案。好的产品体验应在批准前说清用途、可能支出和停止方法，并能解释拒绝原因，而不是一出错就引导用户改成无限授权。

回到数据采购任务，下一步还需要把“获准执行的钱包动作”与具体订单、价格和交付结果对应起来。可以继续阅读钱包限额、防止重复付款，以及 ERC-7715 项目资料。