ERC-7579：怎样审查 Agent 智能账户里的模块权限

团队已有一个智能账户，希望加入受限的 Agent 会话，而不是重写整个钱包。之后可能还要增加账户恢复、定时操作等功能。模块化能把能力拆开，但每加入一个模块，也可能改变“谁可以代表账户行动”。

ERC-7579 讨论的正是这层接口。评估时，除了看是否兼容，还要看账户和模块之间传递了什么权限。

资料边界： 本文于 2026 年 11 月 1 日核对官方草案与维护者文档。ERC-7579 仍为 Draft。我们没有安装、审计或运行本文涉及的模块。

按模块类型审查权限

规范草案 定义账户执行、配置等接口，以及多种模块角色。Validator 判断授权是否成立；Executor 可通过指定路径发起账户执行；Fallback Handler 扩展可调用行为；Hook 在执行前后加入检查。它们是不同的权限入口，不能都当作普通插件看待。

选定模块角色的概念图，非通用实现时序或实测。Fallback Handler 和模块安装路径还需另行审查。

Agent 钱包需要列出所有可能转移资金的路径。某个 Validator 带有限额，不代表其他 Validator 或 Executor 自动受到相同限制。

模块目录只能作为起点

维护者的模块目录 列出了定时转账、恢复、调用策略和时间锁 Hook 等实例，说明这种架构可以扩展哪些功能。但目录不能证明每个模块适配所有账户版本，也不能证明多个模块组合后仍满足原来的权限设计。

账户目录 则列出 Kernel、Safe7579、Nexus 等不同实现或适配层。标准与实现需要分开记录：某个账户的适配器是具体技术选择，ERC-7579 是接口标准。接入工单里只写“支持 7579 的钱包”，信息还不够。

沿着一个 Agent 会话检查完整生命周期

维护者的 Smart Sessions 指南 给出了会话操作的具体接入路径。可据此定位配置与生命周期步骤，再测试自己实际使用的组合。

建议的审查顺序如下：

1. 安装前： 明确模块拥有哪些能力，谁有权安装。账户恢复权限不要交给普通 Agent 会话。
2. 使用中： 分别尝试允许的操作和触犯每项约束的操作；检查所有受支持的调用路径，而不只是 SDK 的正常示例。
3. 移除时： 确认该模块不能再提交新操作，同时检查其他仍启用的模块与凭证。
4. 替换后： 检查旧配置有没有留下遗忘的执行入口。

这些是建议验收项，并非模块测试结果。卸载按钮能正常工作，是接口证据，但还不能证明相关权限全部结束。

批量操作怎样面对局部失败

执行模式不是纯底层细节。标准描述了受支持模式下的回滚与非回滚行为。几项互不相关的操作，可能允许其中一项失败；付款与业务状态更新组合在一起时，要求可能不同。

假设一个批次先给供应商付款，再写入内部账单引用。如果第二步失败，是否保留第一步？没有适用于所有业务的答案。接入方应选择与业务含义一致的执行模式，在需要时显示局部结果，不能只根据外层批次状态报告“全部完成”。

同样，一个保护账户的 Hook 也可能影响可用性。审查时要明确：它拒绝操作或无法完成检查怎么办？所有者怎样恢复，而普通 Agent 又不能利用同一条恢复路径绕过限制？

接入前应留下什么记录

实用的模块清单应包含网络、部署地址、代码版本、初始化数据、安装权限、支持的执行模式和移除方法。安全审查材料也应对应具体版本，而不是只对应模块名称。

我们的判断是，模块化的价值建立在依赖关系清楚的前提上。如果团队说不清到底哪个组件允许 Agent 执行操作，再增加模块通常不会让系统更好管理。官方入口见 ERC-7579 目录条目，也可对照 ERC-7715 的权限请求接口。