Arch Day 233
Arch Day 233: Agent钱包架构 — Session Keys/ERC-7702/MPC
Arch Day 233: Agent钱包架构 — Session Keys/ERC-7702/MPC
2026-04-02
第十阶段 - Agentic CommerceAgent钱包SessionKeysERC7702MPC智能账户权限控制
日期: 2026-04-02 (Day 233) 阶段: 第十阶段 - Agentic Commerce 标签: #Agent钱包 #SessionKeys #ERC7702 #MPC #智能账户 #权限控制
一、核心概念
1.1 为什么Agent钱包是独立问题？
AI Agent正在成为链上经济的活跃参与者——执行DeFi策略、自动化yield farming、管理多资产组合。但核心矛盾在于：
Agent需要链上操作能力，但绝对不能给Agent无限制的私钥权限。
传统钱包设计假设"操作者=资产所有者"，但Agent场景打破了这个假设：
传统模型:
用户(拥有私钥) ──→ 签名交易 ──→ 链上执行
Agent模型:
用户(资产所有者) ──→ 授权Agent(有限权限) ──→ Agent签名 ──→ 链上执行
↑ 关键问题：如何安全授权？
1.2 Agent钱包的核心需求
| 需求 | 说明 | 优先级 |
|---|---|---|
| 最小权限 | Agent只能执行被授权的操作类型 | P0 |
| 金额限制 | 单笔和累计金额必须有上限 | P0 |
| 时间限制 | 授权必须有过期时间 | P0 |
| 可撤销 | 用户可随时终止Agent权限 | P0 |
| 可审计 | 所有Agent操作可追溯 | P1 |
| 自动化 | Agent能自主签名，无需用户每次确认 | P1 |
| 多链支持 | 同一Agent能操作多条链 | P2 |
| 熔断机制 | 异常行为自动停止 | P0 |
1.3 四种主流方案概览
Agent钱包方案
├── Session Keys（临时受限密钥）
│ └── 最适合Agent的细粒度权限模型
├── ERC-7702（EOA升级智能账户）
│ └── 2025 Pectra升级引入，EOA获得可编程性
├── MPC钱包（多方计算）
│ └── 密钥分片，无单点故障，机构级方案
└── 智能合约钱包（Safe等）
└── 多签+模块化权限，成熟方案
二、知识点详解
2.1 Session Keys：Agent的最佳权限模型
什么是Session Key？
Session Key是一个临时生成的密钥对，被授予有限的链上操作权限。它不是主私钥，而是一个"受约束的代理密钥"。
┌─────────────────────────────────────────────┐
│ Session Key 生命周期 │
├─────────────────────────────────────────────┤
│ │
│ 1. 用户用主钥签名创建Session Key │
│ ↓ │
│ 2. 定义权限范围: │
│ - 允许调用的合约地址 │
│ - 允许调用的函数选择器 │
│ - 单笔金额上限 │
│ - 累计金额上限 │
│ - 有效期(开始时间+结束时间) │
│ ↓ │
│ 3. Agent持有Session Key自主签名 │
│ ↓ │
│ 4. 链上验证器检查权限范围 │
│ ↓ │
│ 5. 过期/撤销后Session Key失效 │
│ │
└─────────────────────────────────────────────┘
Session Key的权限参数设计
// Session Key 权限定义（ERC-7715草案参考）
interface SessionKeyPermission {
// 基础信息
sessionPublicKey: address; // Session Key公钥
validAfter: uint48; // 生效时间
validUntil: uint48; // 过期时间
// 合约权限
allowedContracts: address[]; // 白名单合约地址
allowedSelectors: bytes4[]; // 允许的函数选择器
// 金额限制
spendLimit: uint256; // 单笔交易上限
cumulativeLimit: uint256; // 累计总额上限
dailyLimit: uint256; // 每日上限
// 高级约束
cooldownPeriod: uint256; // 大额操作冷却期(秒)
cooldownThreshold: uint256; // 触发冷却的金额阈值
maxTransactionsPerDay: uint16; // 每日最大交易次数
// 链限制
chainId: uint256; // 限定链ID
}
实际应用案例：DeFi Agent的Session Key配置
{
"agentId": "yield-optimizer-v2",
"sessionKey": {
"validUntil": "2026-04-09T00:00:00Z",
"permissions": [
{
"protocol": "Uniswap V4",
"contract": "0x1234...UniRouter",
"allowedFunctions": ["swap", "addLiquidity"],
"maxAmountPerTx": "1000 USDC",
"dailyLimit": "5000 USDC",
"allowedTokenPairs": ["ETH/USDC", "WBTC/ETH"]
},
{
"protocol": "Aave V4",
"contract": "0x5678...AavePool",
"allowedFunctions": ["supply", "withdraw"],
"maxAmountPerTx": "2000 USDC",
"dailyLimit": "10000 USDC",
"forbiddenFunctions": ["borrow", "liquidate"]
}
],
"globalConstraints": {
"maxGasPerTx": "500000",
"maxGasPriceGwei": "50",
"cooldownAfter": "5000 USDC单笔",
"cooldownDuration": "1 hour",
"circuitBreaker": {
"trigger": "累计亏损 > 10%",
"action": "暂停所有操作，通知用户"
}
}
}
}
2025-2026 Session Key生态进展
| 项目 | 方案 | 特点 | 状态(2026) |
|---|---|---|---|
| ZeroDev (Kernel V3) | ERC-7579 Module | 最成熟的Session Key SDK | 生产环境 |
| Biconomy | Modular SA | 多链Session Key | 生产环境 |
| Privy | Embedded Wallet + SK | 面向开发者最友好 | 生产环境 |
| Rhinestone | ERC-7579 Module Registry | 标准化模块 | 生产环境 |
| Alchemy (Modular Account) | AA + Session Key | 与Alchemy生态集成 | 生产环境 |
| Pimlico | Bundler + SK Validation | Paymaster集成 | 生产环境 |
2.2 ERC-7702：EOA的智能化升级
背景与动机
2025年3月Pectra升级（以太坊硬分叉）引入ERC-7702，这是继ERC-4337之后账户抽象的重大进展。
核心创新：允许EOA（外部拥有账户）在单笔交易中临时委托给智能合约代码执行，使EOA获得智能账户的可编程能力。
ERC-4337 vs ERC-7702 对比:
ERC-4337（2023）:
→ 部署新的智能合约钱包
→ 需要Bundler和Paymaster基础设施
→ 新地址，需迁移资产
→ 完全独立的账户体系
ERC-7702（2025 Pectra）:
→ 现有EOA直接升级
→ 保持原有地址和资产
→ 设置delegation designator
→ EOA临时"变身"为智能账户
ERC-7702技术原理
┌──────────────────────────────────────────────┐
│ ERC-7702 工作流程 │
├──────────────────────────────────────────────┤
│ │
│ 1. EOA签署authorization tuple: │
│ (chainId, address, nonce) │
│ → address = 要委托的合约地址 │
│ │
│ 2. 交易包含 authorization_list │
│ → 新的交易类型 type 0x04 │
│ │
│ 3. 执行时： │
│ EOA的code字段被临时设置为: │
│ 0xef0100 || delegateAddress │
│ → 后续调用EOA时执行delegate合约代码 │
│ │
│ 4. EOA获得智能合约能力: │
│ - 批量交易(Batch calls) │
│ - Gas赞助(Sponsored transactions) │
│ - 权限委托(Session keys via delegate) │
│ - 自定义验证逻辑 │
│ │
│ 5. 可随时撤销delegation │
│ → EOA回归普通状态 │
│ │
└──────────────────────────────────────────────┘
ERC-7702对Agent钱包的意义
// ERC-7702 + Session Key for Agent
// 用户EOA委托给支持Session Key的合约
// Step 1: 用户EOA设置delegation
const authorizationTuple = {
chainId: 1,
address: "0xAgentDelegateContract", // 支持Session Key管理的合约
nonce: await wallet.getNonce()
};
const signedAuth = await wallet.signAuthorization(authorizationTuple);
// Step 2: 通过delegate合约为Agent创建Session Key
const sessionKeyTx = encodeFunctionData({
abi: agentDelegateABI,
functionName: "createSessionKey",
args: [{
key: agentSessionPublicKey,
validUntil: Math.floor(Date.now()/1000) + 86400 * 7, // 7天
permissions: [
{ contract: uniswapRouter, selectors: ["0x5ae401dc"] }, // multicall
{ contract: aavePool, selectors: ["0x617ba037"] } // supply
],
spendLimit: parseEther("1") // 1 ETH 单笔上限
}]
});
// Step 3: Agent可以用Session Key自主签名交易
// 交易会经过delegate合约的权限检查
Pectra后的生态变化（2025-2026）
| 变化 | 影响 | Agent钱包意义 |
|---|---|---|
| EOA可编程 | 不需要部署新合约钱包 | 降低Agent接入门槛 |
| 批量交易 | 一笔tx完成多步操作 | Agent效率提升 |
| Gas赞助 | 项目方可代付Gas | Agent无需持有ETH |
| 权限委托 | 原生支持Session Key模式 | Agent权限管理标准化 |
| 向后兼容 | 不影响现有EOA | 渐进式采用 |
2.3 MPC钱包：机构级Agent方案
MPC（Multi-Party Computation）原理
MPC钱包将私钥拆分为多个分片（Key Shares），分布在不同参与方手中，签名时各方协作计算，任何单方都无法重建完整私钥。
┌─────────────────────────────────────────────┐
│ MPC钱包架构 (TSS方案) │
├─────────────────────────────────────────────┤
│ │
│ 密钥生成 (DKG - Distributed Key Gen): │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ Share1 │ │ Share2 │ │ Share3 │ │
│ │ (用户) │ │(Agent) │ │(服务商)│ │
│ └───┬────┘ └───┬────┘ └───┬────┘ │
│ │ │ │ │
│ 签名 (TSS - Threshold Signature): │
│ │ │ │ │
│ ┌───▼────┐ ┌───▼────┐ ┌──▼─────┐ │
│ │ 部分 │ │ 部分 │ │ 部分 │ │
│ │ 签名1 │ │ 签名2 │ │ 签名3 │ │
│ └───┬────┘ └───┬────┘ └───┬────┘ │
│ │ │ │ │
│ └───────────┼───────────┘ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 完整签名 (2/3) │ │
│ │ 链上验证通过 │ │
│ └────────────────┘ │
│ │
│ 阈值: 2-of-3 → 任意2方即可签名 │
│ Agent持有1个Share → 必须配合才能签名 │
│ │
└─────────────────────────────────────────────┘
MPC在Agent场景的应用模式
模式一：Agent协签模式 (2-of-3)
→ 用户Share + Agent Share 即可签名
→ 服务商Share作为恢复备份
→ Agent可自主操作（用户离线时用策略引擎代替用户审批）
→ 适合：中等金额自动化操作
模式二：Agent受限模式 (2-of-3 + Policy Engine)
→ Agent Share + Policy Engine Share 可签名
→ Policy Engine检查：金额/频率/合约白名单
→ 大额操作需要用户Share参与
→ 适合：机构级资管Agent
模式三：纯自动化模式 (Agent + HSM)
→ Agent逻辑层 + HSM硬件签名
→ 策略引擎嵌入HSM
→ 全自动但硬件级安全
→ 适合：高频交易Agent
主流MPC钱包服务商（2025-2026）
| 服务商 | 定位 | MPC方案 | Agent支持 | 典型客户 |
|---|---|---|---|---|
| Fireblocks | 机构级 | GG-20 TSS | Policy Engine + API | 银行、基金 |
| Fordefi | 机构DeFi | MPC + Policy | DeFi白名单策略 | DeFi机构 |
| Dfns | 开发者优先 | DKLS TSS | Programmable Policies | Fintech |
| Turnkey | 嵌入式 | CGGMP | Embedded API Key | DApp开发者 |
| Lit Protocol | 去中心化 | TSS Network | PKP (Programmable Key Pairs) | Web3 Agent |
| Portal | 移动端 | MPC-CMP | Mobile SDK | 消费钱包 |
Lit Protocol PKP：去中心化Agent密钥
Lit Protocol的PKP（Programmable Key Pairs）是去中心化MPC网络+可编程签名条件的组合，特别适合去中心化Agent场景：
// Lit Protocol PKP + Agent 示例
const litAction = `
// 在Lit节点上执行的签名逻辑
const checkPermission = async () => {
// 检查调用者是否为授权Agent
if (agentAddress !== authorizedAgent) throw new Error("Unauthorized");
// 检查操作是否在白名单内
const decodedTx = decodeFunctionData(txData);
if (!allowedFunctions.includes(decodedTx.functionName)) {
throw new Error("Function not allowed");
}
// 检查金额限制
if (decodedTx.value > maxAmount) {
throw new Error("Amount exceeds limit");
}
// 条件满足，分布式签名
const signature = await Lit.Actions.signEcdsa({
toSign: txHash,
publicKey: pkpPublicKey,
sigName: "agentTx"
});
return signature;
};
`;
2.4 智能合约钱包：Safe模块化权限
Safe多签 + Agent Module
Safe（原Gnosis Safe）是最成熟的智能合约钱包，通过Module系统可以为Agent授予有限操作权限。
┌─────────────────────────────────────────────────┐
│ Safe + Agent Module 架构 │
├─────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ │
│ │ Safe 多签 │ ← 3-of-5 多签控制 │
│ │ (主账户) │ │
│ └──────┬───────┘ │
│ │ 安装Module │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ Agent Module │ │
│ │ (限权操作入口) │ │
│ ├──────────────────────┤ │
│ │ ✓ 白名单合约 │ │
│ │ ✓ 白名单函数 │ │
│ │ ✓ 金额上限 │ │
│ │ ✓ 频率限制 │ │
│ │ ✓ 熔断条件 │ │
│ └──────┬───────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ AI Agent │ ← 只能通过Module操作 │
│ │ (EOA) │ │
│ └──────────────┘ │
│ │
│ 关键：Agent的EOA只能调Module暴露的接口 │
│ Module内部验证权限后，以Safe身份执行交易 │
│ │
└─────────────────────────────────────────────────┘
ERC-7579模块化标准
2025年ERC-7579成为智能账户模块的事实标准，定义了标准化的模块接口：
ERC-7579 模块类型:
├── Validator Module → 自定义签名验证逻辑
├── Executor Module → 自定义执行逻辑（Agent操作入口）
├── Fallback Handler → 处理未知函数调用
└── Hook Module → 交易前/后拦截检查（权限守卫）
Agent钱包使用模式:
Validator = Session Key验证器（验证Agent签名+权限范围）
Executor = Agent操作执行器（调用DeFi协议）
Hook = 熔断守卫（检查累计金额、异常检测）
2.5 权限设计模式详解
分层权限架构
┌─────────────────────────────────────────────────────┐
│ Agent权限分层模型 │
├─────────────────────────────────────────────────────┤
│ │
│ Level 0: 观察层 (Read-Only) │
│ ├── 查询余额 │
│ ├── 读取链上状态 │
│ └── 价格和市场数据 │
│ │
│ Level 1: 低风险操作 │
│ ├── Claim奖励 (已有头寸的收益领取) │
│ ├── Token Approve (白名单合约) │
│ └── 小额Swap (< $100) │
│ │
│ Level 2: 中风险操作 │
│ ├── Swap (< $1000/笔, < $5000/日) │
│ ├── Supply到借贷协议 │
│ ├── Add Liquidity │
│ └── 需要冷却期确认 │
│ │
│ Level 3: 高风险操作 (需用户确认) │
│ ├── Borrow (杠杆操作) │
│ ├── 大额转账 (> $5000) │
│ ├── 跨链桥接 │
│ └── 新合约交互 (非白名单) │
│ │
│ Level 4: 管理操作 (仅用户) │
│ ├── 修改Agent权限 │
│ ├── 撤销Session Key │
│ ├── 添加/移除签名者 │
│ └── 紧急资金转移 │
│ │
└─────────────────────────────────────────────────────┘
熔断机制设计
// Agent熔断机制实现逻辑
interface CircuitBreaker {
// 触发条件
triggers: {
// 价值损失熔断
portfolioDrawdown: {
threshold: "10%", // 组合价值下降10%
timeWindow: "24h", // 24小时内
action: "PAUSE_ALL" // 暂停所有操作
},
// 频率异常熔断
abnormalFrequency: {
maxTxPerHour: 20, // 每小时最多20笔
maxTxPerMinute: 5, // 每分钟最多5笔
action: "PAUSE_AND_NOTIFY" // 暂停并通知用户
},
// Gas异常熔断
gasSpike: {
maxGasPrice: "100 gwei", // Gas超过100 gwei
action: "DELAY_EXECUTION" // 延迟执行，等Gas降低
},
// 滑点保护
slippageGuard: {
maxSlippage: "2%", // 最大滑点2%
action: "REJECT_TX" // 拒绝交易
},
// 未知合约熔断
unknownContract: {
action: "REJECT_AND_ALERT" // 拒绝并告警
}
},
// 恢复机制
recovery: {
autoResume: "1h", // 1小时后自动恢复（轻度触发）
manualResume: true, // 重度触发需用户手动恢复
cooldownEscalation: true // 连续触发延长冷却时间
}
}
三、对比分析
3.1 四种方案全面对比
| 维度 | Session Keys | ERC-7702 | MPC | 智能合约钱包(Safe) |
|---|---|---|---|---|
| 权限粒度 | 极细（函数级） | 中等（delegate级） | 粗（策略引擎级） | 细（Module级） |
| 安全模型 | 链上验证 | 链上验证 | 链下多方计算 | 链上多签 |
| 部署成本 | 低（Module安装） | 极低（一笔tx） | 中（服务商费用） | 中（合约部署） |
| Gas开销 | 中等 | 低 | 低（链下计算） | 中等 |
| 去中心化 | 高（链上） | 高（协议级） | 低（依赖服务商） | 高（链上） |
| 撤销速度 | 即时（链上） | 即时 | 取决于服务商 | 即时（链上） |
| 多链支持 | 需每链部署 | 仅EVM | 天然多链 | 需每链部署 |
| 机构合规 | 弱 | 弱 | 强（审计追踪） | 中 |
| 密钥风险 | Session Key泄露=有限损失 | EOA Key泄露=全部损失 | 单Share泄露=无风险 | 单签名者妥协=安全 |
| 最适场景 | DApp内Agent | 个人用户升级 | 机构Agent | DAO/团队Agent |
| 成熟度(2026) | 成熟 | 早期生产 | 成熟 | 成熟 |
3.2 方案组合策略
实际生产环境中，最佳实践是组合使用多种方案：
推荐组合（2026最佳实践）:
个人DeFi Agent:
ERC-7702(EOA升级) + Session Keys(细粒度权限)
→ 用户EOA通过7702获得智能账户能力
→ 为Agent创建Session Key，限制操作范围
→ 熔断机制通过Hook Module实现
机构资管Agent:
MPC(密钥管理) + Smart Contract Wallet(执行层) + Policy Engine(策略层)
→ Fireblocks/Fordefi管理密钥分片
→ Safe作为链上执行钱包
→ Policy Engine检查每笔交易的合规性
DAO运营Agent:
Safe多签(治理) + Agent Module(自动化) + Session Keys(限权)
→ Safe多签管理资金库
→ Agent Module允许自动化操作（如定期投资、奖励分发）
→ Session Key限制Agent的具体操作范围
3.3 安全性对比矩阵
| 威胁场景 | Session Keys | MPC | Safe Module | 全权限EOA |
|---|---|---|---|---|
| Agent被黑 | 损失有限（受权限约束） | 单Share不足以签名 | 损失有限 | 全部资产丢失 |
| Session Key泄露 | 损失有限+可即时撤销 | N/A | N/A | N/A |
| 服务商跑路 | 无影响（链上） | 可能丢失访问 | 无影响 | 无影响 |
| 合约漏洞 | 影响该Module | 无（链下） | 影响该Module | N/A |
| 钓鱼攻击 | Session Key范围内损失 | 需要多方配合 | Module范围内损失 | 全部资产 |
| 重放攻击 | chainId+nonce保护 | 协议内保护 | nonce保护 | nonce保护 |
四、架构设计实操
4.1 DeFi Agent钱包完整架构
┌──────────────────────────────────────────────────────────────┐
│ DeFi Agent 钱包架构 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌────────────────┐ │
│ │ 用户界面 │ │ 通知服务 │ │ 监控面板 │ │
│ │ (审批/查看) │ │ (Telegram等) │ │ (操作历史) │ │
│ └──────┬──────┘ └──────┬───────┘ └───────┬────────┘ │
│ │ │ │ │
│ ═══════╪══════════════════╪════════════════════╪════════ │
│ │ 用户层/监控层 │ │
│ ═══════╪══════════════════╪════════════════════╪════════ │
│ │ │ │ │
│ ┌──────▼──────────────────▼────────────────────▼────────┐ │
│ │ 策略引擎 │ │
│ │ ┌──────────┐ ┌───────────┐ ┌────────────────────┐ │ │
│ │ │ DeFi策略 │ │ 风控引擎 │ │ 市场数据聚合器 │ │ │
│ │ │ 决策逻辑 │ │ 熔断检查 │ │ (价格/APY/Gas) │ │ │
│ │ └────┬─────┘ └────┬──────┘ └────────┬───────────┘ │ │
│ │ │ │ │ │ │
│ └───────┼─────────────┼───────────────────┼──────────────┘ │
│ │ │ │ │
│ ════════╪═════════════╪═══════════════════╪═════════════ │
│ │ Agent核心层 │ │
│ ════════╪═════════════╪═══════════════════╪═════════════ │
│ │ │ │ │
│ ┌───────▼─────────────▼───────────────────▼──────────────┐ │
│ │ 交易构建与签名层 │ │
│ │ ┌────────────┐ ┌──────────────┐ ┌────────────────┐ │ │
│ │ │ 交易编码器 │ │ Session Key │ │ 交易模拟器 │ │ │
│ │ │ (ABI编码) │ │ 签名器 │ │ (Tenderly预览) │ │ │
│ │ └────┬───────┘ └──────┬───────┘ └────────┬───────┘ │ │
│ │ │ │ │ │ │
│ └───────┼─────────────────┼────────────────────┼──────────┘ │
│ │ │ │ │
│ ════════╪═════════════════╪════════════════════╪═════════ │
│ │ 链上交互层 │ │
│ ════════╪═════════════════╪════════════════════╪═════════ │
│ │ │ │ │
│ ┌───────▼─────────────────▼────────────────────▼──────────┐ │
│ │ 智能账户 (链上) │ │
│ │ ┌────────────────┐ ┌───────────────────────────────┐ │ │
│ │ │ ERC-7702 │ │ ERC-7579 Modules │ │ │
│ │ │ Delegation │ │ ├── SessionKeyValidator │ │ │
│ │ │ │ │ ├── AgentExecutor │ │ │
│ │ │ │ │ ├── CircuitBreakerHook │ │ │
│ │ │ │ │ └── SpendLimitGuard │ │ │
│ │ └────────────────┘ └───────────────────────────────┘ │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ DeFi协议交互: Uniswap | Aave | Pendle | ... │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
4.2 权限生命周期管理
┌─────────────────────────────────────────────────────┐
│ Session Key 生命周期管理 │
├─────────────────────────────────────────────────────┤
│ │
│ 创建阶段 │
│ ┌────────────────────────────────────────────┐ │
│ │ 1. 用户发起创建请求 │ │
│ │ 2. 选择权限模板(保守/平衡/激进) │ │
│ │ 3. 自定义参数(金额/合约/时间) │ │
│ │ 4. 用主钥签名创建Session Key │ │
│ │ 5. 链上注册Session Key + 权限范围 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 运行阶段 │
│ ┌────────────────────────────────────────────┐ │
│ │ 1. Agent持Session Key签名交易 │ │
│ │ 2. 链上Validator验证: │ │
│ │ - 签名有效性 │ │
│ │ - 合约白名单 │ │
│ │ - 函数选择器白名单 │ │
│ │ - 金额限制(单笔+累计) │ │
│ │ - 时间有效期 │ │
│ │ 3. Hook检查: │ │
│ │ - 熔断条件 │ │
│ │ - 频率限制 │ │
│ │ 4. 执行交易 │ │
│ │ 5. 更新累计统计 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 终止阶段 │
│ ┌────────────────────────────────────────────┐ │
│ │ 正常终止: │ │
│ │ - 到期自动失效 │ │
│ │ - 累计额度用完 │ │
│ │ │ │
│ │ 异常终止: │ │
│ │ - 用户主动撤销 │ │
│ │ - 熔断触发自动停止 │ │
│ │ - 合约升级/暂停 │ │
│ │ │ │
│ │ 续期: │ │
│ │ - 用户审查Agent操作记录 │ │
│ │ - 调整权限参数(根据历史表现) │ │
│ │ - 重新签名创建新Session Key │ │
│ └────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────┘
4.3 机构级Agent钱包架构（MPC + Policy）
┌────────────────────────────────────────────────────────────┐
│ 机构级Agent钱包架构 (Fireblocks方案) │
├────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ 投资委员会 │ │ 合规团队 │ │
│ │ (审批规则) │ │ (AML/CFT) │ │
│ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌───────────────────────────────────────────┐ │
│ │ Policy Engine (TAP) │ │
│ │ ┌─────────────────────────────────────┐ │ │
│ │ │ 规则示例: │ │ │
│ │ │ IF amount > $50K → 需2人审批 │ │ │
│ │ │ IF 新地址 → 需合规审查 │ │ │
│ │ │ IF 非工作时间 → 延迟至工作时间 │ │ │
│ │ │ IF Agent连续亏损 > 5% → 暂停 │ │ │
│ │ └─────────────────────────────────────┘ │ │
│ └───────────────────┬───────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────┐ │
│ │ MPC签名服务 (TSS) │ │
│ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │
│ │ │ SGX │ │ SGX │ │ SGX │ │ SGX │ │ │
│ │ │Node1 │ │Node2 │ │Node3 │ │Node4 │ │ │
│ │ │(用户)│ │(Agent)│ │(备份)│ │(合规)│ │ │
│ │ └──────┘ └──────┘ └──────┘ └──────┘ │ │
│ │ 3-of-4 阈值签名 │ │
│ └───────────────────┬───────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────┐ │
│ │ 多链广播层 │ │
│ │ Ethereum | Arbitrum | Solana | Base │ │
│ └───────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────┘
4.4 实际代码示例：ZeroDev Session Key
// 使用ZeroDev Kernel V3创建Agent Session Key（2026实际代码参考）
import { createKernelAccount, createSessionKeyAccount } from "@zerodev/sdk";
import { signerToSessionKeyValidator } from "@zerodev/session-key";
import { toPermissionValidator } from "@zerodev/permissions";
// Step 1: 定义Agent权限
const agentPermissions = {
// 允许的合约和函数
policies: [
{
// Uniswap V4 Swap权限
target: "0x...UniswapRouter",
abi: uniswapRouterABI,
functionName: "swap",
args: [
null, // 任意tokenIn
null, // 任意tokenOut
{ rule: "LESS_THAN", value: parseEther("1") } // amountIn < 1 ETH
]
},
{
// Aave Supply权限
target: "0x...AavePool",
abi: aavePoolABI,
functionName: "supply",
args: [
{ rule: "ONE_OF", value: [USDC_ADDRESS, WETH_ADDRESS] }, // 白名单Token
{ rule: "LESS_THAN", value: parseUnits("5000", 6) }, // < 5000 USDC
null, // onBehalfOf
null // referralCode
]
}
],
// 全局限制
globalPolicies: [
{
type: "SPEND_LIMIT",
token: USDC_ADDRESS,
limit: parseUnits("10000", 6), // 总计不超过10000 USDC
period: "1d" // 每日重置
},
{
type: "RATE_LIMIT",
maxTransactions: 50,
period: "1d"
},
{
type: "GAS_LIMIT",
maxGasPerTx: 500000n,
maxGasPriceGwei: 50n
}
],
// 有效期
validAfter: Math.floor(Date.now() / 1000),
validUntil: Math.floor(Date.now() / 1000) + 7 * 24 * 3600 // 7天
};
// Step 2: 创建Session Key Validator
const sessionKeyValidator = await signerToSessionKeyValidator(publicClient, {
signer: agentSigner, // Agent的临时密钥
validatorData: agentPermissions,
kernelVersion: "0.3.1"
});
// Step 3: Agent使用Session Key执行交易
const agentKernelClient = createKernelAccountClient({
account: sessionKeyAccount,
chain: mainnet,
bundlerTransport: http(bundlerUrl),
paymaster: {
getPaymasterData: paymasterClient.getPaymasterData // Gas代付
}
});
// Agent自主执行Swap
const txHash = await agentKernelClient.sendTransaction({
to: uniswapRouter,
data: encodeFunctionData({
abi: uniswapRouterABI,
functionName: "swap",
args: [WETH, USDC, parseEther("0.5")] // 0.5 ETH → USDC
})
});
// 链上自动验证：金额 < 1 ETH ✓, 函数在白名单 ✓, 未超日限额 ✓
五、与Web3/DeFi的关联
5.1 DeFi Agent操作场景映射
| DeFi操作 | Agent权限需求 | 推荐方案 | 风险等级 |
|---|---|---|---|
| Swap | 白名单DEX + 金额限制 | Session Key | 中 |
| Supply/Lend | 白名单协议 + 金额限制 | Session Key | 低-中 |
| Borrow | 需用户确认 + LTV保护 | MPC(需审批) | 高 |
| Yield Farming | 白名单Farm + 自动复投 | Session Key | 中 |
| Claim Rewards | 仅claim函数 | Session Key(最小权限) | 低 |
| Rebalance | 组合内Token互换 | Session Key | 中 |
| 跨链桥接 | 白名单桥 + 金额限制 | MPC(需审批) | 高 |
| 清算保护 | 紧急repay/withdraw | Session Key(带触发条件) | 高 |
| 治理投票 | 仅vote函数 | Session Key | 低 |
| NFT交易 | 白名单市场 + 价格限制 | Session Key | 中 |
5.2 Agent钱包与DeFi协议集成模式
Agent钱包 × DeFi 协议集成:
模式一：直接交互
Agent ──(Session Key)──→ Uniswap/Aave/Pendle
优点：简单直接
缺点：需要为每个协议配置权限
模式二：通过Intent协议
Agent ──(意图描述)──→ CoW Protocol/UniswapX ──→ Solver执行
优点：最优价格，MEV保护
缺点：依赖Solver网络
模式三：通过聚合器
Agent ──(Session Key)──→ 1inch/Paraswap ──→ 最优路由
优点：自动路由优化
缺点：聚合器需要在白名单中
模式四：Agent-to-Agent (A2A)
Agent A ──(报价请求)──→ Agent B(做市商Agent)
Agent A ──(Session Key)──→ 链上结算
优点：去中心化Agent经济
缺点：信任和结算复杂
5.3 真实案例：2025-2026 Agent钱包产品
| 产品 | 方案 | 特点 | 用户规模(2026) |
|---|---|---|---|
| Coinbase Agent Kit | MPC + Policy | 机构级，合规优先 | 大型 |
| Crossmint Agent Wallets | Embedded + SK | 开发者友好，API驱动 | 中型 |
| Privy Server Wallets | Embedded + Session Key | 最快集成 | 中型 |
| Safe{Wallet} + Agent Module | 多签 + Module | DAO/团队场景 | 大型 |
| Virtuals Agent Wallet | 专用Agent钱包 | AI Agent代币交互 | 增长中 |
| Olas Agent Wallet | Service-bound | 自主Agent服务 | 增长中 |
六、面试题准备
面试题1：如何设计AI Agent的链上资产管理系统？
30秒回答： 采用分层权限架构——底层用ERC-7702将EOA升级为智能账户，中间层通过ERC-7579 Session Key Module实现细粒度权限控制（白名单合约、金额上限、时间限制），上层加入熔断机制和交易模拟。机构场景叠加MPC密钥管理。
2分钟详细回答：
Agent链上资产管理的核心挑战是在"自动化效率"和"资产安全"之间找平衡。我的设计思路分四层：
第一层：账户基础
- 个人用户采用ERC-7702，将现有EOA升级为智能账户，零迁移成本
- 机构用户采用Safe多签 + MPC密钥管理（如Fireblocks TSS）
第二层：权限管理
- 使用ERC-7579模块化标准，安装SessionKeyValidator
- 为Agent创建Session Key，精确定义：
- 白名单合约地址和函数选择器
- 单笔金额上限、每日累计上限
- 有效期（建议7天为周期，定期续签）
- 分级权限：观察 → 低风险自动 → 中风险需冷却 → 高风险需用户确认
第三层：安全守卫
- Hook Module实现熔断机制：组合回撤>10%自动停止
- 交易预执行模拟（Tenderly fork），确认预期结果后再提交
- 滑点保护：实际滑点超过2%拒绝执行
- 异常频率检测：短时间大量交易触发暂停
第四层：监控与恢复
- 所有Agent操作上链可审计
- 实时通知（Telegram/邮件）
- 紧急撤销通道：用户可一键撤销所有Session Key
- 定期权限审查：基于Agent历史表现调整权限参数
追问准备：
Q: Session Key泄露怎么办？ A: 损失被限制在Session Key的权限范围内（如最多5000 USDC/天）。用户可即时在链上撤销。相比私钥泄露丢失全部资产，Session Key泄露是"受控损失"。
Q: 如何处理多链场景？ A: 每条链独立部署智能账户和Session Key Module。通过跨链消息（如Wormhole/LayerZero）实现跨链权限同步或紧急撤销。
Q: MPC和Session Key如何选择？ A: 不是二选一，而是分层使用。MPC解决"密钥谁持有"的问题，Session Key解决"能做什么操作"的问题。机构方案：MPC管理底层密钥 + Session Key控制Agent操作范围。
面试题2：ERC-7702和ERC-4337的区别？对Agent钱包有什么影响？
30秒回答： ERC-4337是在协议外（EntryPoint合约）实现账户抽象，需要部署新的智能合约钱包；ERC-7702是协议级改动（Pectra硬分叉），让现有EOA直接委托智能合约代码执行。对Agent钱包的影响：7702大幅降低了用户接入门槛，不需要迁移资产到新地址就能获得Session Key能力。
2分钟详细回答：
| 维度 | ERC-4337 | ERC-7702 |
|---|---|---|
| 实现层 | 应用层（EntryPoint合约） | 协议层（硬分叉） |
| 钱包地址 | 新的合约地址 | 保持原有EOA地址 |
| 基础设施 | 需要Bundler+Paymaster | 不需要额外基础设施 |
| 可编程性 | 完整智能合约能力 | 通过delegation获得 |
| Gas效率 | 较高（UserOp验证开销） | 较低（原生tx） |
| 兼容性 | 需要迁移资产 | 完全向后兼容 |
对Agent钱包的具体影响：
- 用户迁移成本降为零：用户无需将资产从EOA转移到新的智能合约钱包
- Session Key可以在EOA上原生使用：通过7702 delegation到支持Session Key的合约
- 两者互补：7702让EOA获得基础可编程性，4337的模块化生态（ERC-7579）提供丰富的权限控制能力。在实践中，7702 + 7579 Module是2026年的主流组合
面试题3：如何防止Agent的"对手风险"（Agent本身作恶或被攻破）？
回答要点：
预防层面：
- Session Key限制操作范围，即使Agent作恶也只能在权限内操作
- 交易模拟预览，检查操作结果是否符合预期
- 合约白名单，防止Agent与恶意合约交互
- 金额上限，限制单次和累计损失
检测层面：
- 监控Agent的PnL，异常亏损触发告警
- 检测操作模式变化（突然频率增加、操作对象改变）
- 链上事件监听，实时追踪Agent的每笔交易
响应层面：
- 熔断机制：自动暂停Agent操作
- 一键撤销：用户可即时在链上销毁Session Key
- 资金保护：紧急情况下将资金转移到安全地址
- 事后审计：所有操作链上可查，便于追责
架构原则：
- 默认拒绝：Agent只能做明确授权的操作，其他全部拒绝
- 最小权限：给Agent完成任务所需的最小权限集
- 纵深防御：多层检查（签名验证 → 权限检查 → 熔断守卫 → 交易模拟）
- 可观察性：每一步都有日志和事件，便于审计和调试
面试题4：从产品经理角度，如何设计Agent钱包的用户体验？
回答要点：
核心矛盾：安全性需要限制，但限制太多影响Agent效率和用户体验。
UX设计原则：
-
权限模板化：不要让用户手动配置每个参数
- 提供"保守/平衡/激进"三档预设模板
- 保守：仅claim奖励+小额swap
- 平衡：中额swap+supply+自动复投
- 激进：较大额操作+多协议交互
-
渐进式信任：
- 新Agent先用最小权限运行1周
- 表现良好后自动建议扩大权限
- 类似银行新卡的额度提升机制
-
操作透明：
- 每笔Agent操作实时推送通知
- 每日/每周操作摘要报告
- 可视化PnL和操作历史
-
紧急控制：
- 一键暂停按钮（app首页醒目位置）
- 生物识别确认紧急操作
- 多渠道通知（push + Telegram + 邮件）
-
信任建立：
- Agent操作前显示模拟结果："将swap 100 USDC → ~0.033 ETH，预计滑点0.3%"
- 历史胜率/收益率展示
- 社区评分和审计认证
七、明日预告
Day 234: A2A商业生态
核心问题：当AI Agent之间可以直接交易、谈判、协作，将诞生什么样的新商业模式？
预告内容：
- Agent-to-Agent协议设计（Google A2A Protocol + Web3结合）
- Agent服务市场和定价模型
- Agent间的信任、声誉和结算机制
- x402支付协议：HTTP请求级别的Agent付费
- Agent经济的代币模型和价值捕获
- 从Agent钱包到Agent商业生态的演进
参考资料
| 资源 | 说明 |
|---|---|
| ERC-7702 EIP | 官方规范 |
| ERC-7579 EIP | 模块化智能账户标准 |
| ERC-7715 Draft | 权限请求标准草案 |
| ZeroDev Docs | Session Key实现参考 |
| Pectra Upgrade Specs | Pectra升级详细规范 |
| Fireblocks Docs | 机构级MPC方案 |
| Lit Protocol Docs | 去中心化MPC+PKP |
| Safe Modules | Safe模块化架构 |
| Rhinestone Module Registry | ERC-7579模块注册中心 |