Day 73：AI Agent 产品设计 — 从 UI 到 Agent 界面

日期：2026-03-17 主题：AI Agent 身份/权限/支付标准、多 Agent 协作模式、AI-native DApp 设计原则、PM 评估框架 产出：学习笔记 + 面试题答案

---

今日目标

---

一、范式转变：从 UI 到 AI

1.1 三次交互范式

第一代（命令式 UI）：用户点击按钮 → Dapp 执行
第二代（意图式 UX）：用户声明意图 → Solver 网络执行（Day 71）
第三代（Agent 式）：用户设定目标 → AI Agent 持续执行

1.2 Agent 与传统 Bot 的区别

---

二、Agent 身份与权限系统

2.1 核心问题

AI Agent 要代替用户操作链上资产，必须解决：

• 身份：Agent 是谁？（可验证的 Agent 标识）
• 权限：Agent 被允许做什么？（细粒度授权）
• 审计：Agent 做了什么？（链上可追溯）

2.2 Session Keys（会话密钥）

原理：为 Agent 生成一个临时子密钥，权限受到严格限制，到期自动失效。

主密钥（用户持有）
    └─ Session Key（授权给 Agent）
           ├─ 有效期：24小时
           ├─ 每笔最大金额：$100
           ├─ 允许协议：仅 Uniswap
           └─ 允许操作：Swap（禁止 Transfer）

技术标准：

• ERC-7715：为智能账户定义权限授权标准，规范 Session Key 的结构与验证
• EIP-7702：EOA 临时变身智能账户，允许在单笔交易中添加代码逻辑（2025.07 Pectra 升级随 EIP-7702 一起上线）

实际产品：

2.3 ERC-8004：Agent 注册与声誉

定义：链上 Agent 身份注册表，记录：

• Agent 地址（部署合约地址）
• 元数据（能力描述、版本）
• 运营者地址（谁在跑这个 Agent）
• 历史执行记录（声誉分）

意义：解决"我怎么知道这个 Agent 可信？"的问题，类比 DeFi 项目的审计报告。

---

三、Agent 支付基础设施

3.1 问题背景

AI Agent 访问外部服务（数据 API、计算资源）需要即时支付，传统方式：

• 订阅制 → Agent 无法按需支付
• API Key → 共享凭证，安全风险高
• 信用卡/银行账户 → Agent 无法持有

3.2 x402 协议（HTTP 402 复活）

原理：HTTP 状态码 402（Payment Required）在 1991 年定义但从未实现。x402 用加密货币激活它。

1. Agent → 请求资源（GET /api/data）
2. 服务器 → 返回 402 + 支付要求（收款地址/金额/链）
3. Agent → 链上支付 → 返回支付证明
4. 服务器 → 验证支付 → 返回资源

关键参数：

{
  "x402Version": 1,
  "accepts": [{
    "scheme": "exact",
    "network": "base-mainnet",
    "maxAmountRequired": "1000000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
  }]
}

推动者：Coinbase / Alchemy（2026.03 正式推出生产版本）

应用场景：

• AI Agent 按次调用链上数据 API
• Agent 购买计算资源（GPU 时间）
• 多 Agent 系统中的 Agent 间结算

3.3 Agent 钱包设计

Coinbase Agentic Wallets 架构：

用户主钱包
    └─ Agent 子钱包（智能合约钱包）
           ├─ 每日消费上限：$500
           ├─ 单笔上限：$50
           ├─ 自动 Gas 补充
           ├─ 多签审批（超过阈值）
           └─ 操作日志上链

核心设计原则：

• 最小权限：默认只读，写操作需明确授权
• 消费上限：不可绕过的硬编码限制
• 熔断机制：异常行为自动停止
• 透明日志：所有操作可被用户查询

---

四、多 Agent 协作模式

4.1 Orchestrator → Specialist 架构

用户："每周五把我 USDC 余额的 20% 投入最高 APY 的借贷协议"
    │
    ▼
Orchestrator Agent（主控）
├── 理解用户意图
├── 分解子任务
└── 协调子 Agent
    ├─ Data Agent: 查询 Aave/Morpho/Compound APY
    ├─ Risk Agent: 评估协议安全风险
    ├─ Execution Agent: 执行存款操作（持有 Session Key）
    └─ Notification Agent: 发送操作报告给用户

4.2 实际框架对比

4.3 Agent 间通信

A2A（Agent-to-Agent）协议：

• Google 提出的标准，定义 Agent 发现和调用规范
• 类比 Web3 里的 ABI：让 Agent 知道如何调用其他 Agent
• 现状：2025-2026 年仍在标准化阶段，各框架各自为政

---

五、AI-native DApp 设计原则

5.1 从命令式到声明式

命令式（传统 DApp）：
用户思考："我要 Swap ETH→USDC，选哪个 DEX？Gas 够吗？滑点设多少？"
→ 点击 Approve → 点击 Swap → 等待确认

声明式（AI-native）：
用户说："换 1 ETH 成 USDC，帮我找最优路径"
→ Agent 自动处理一切，完成后通知

5.2 六大设计原则

1. 渐进式授权（Progressive Permission）

• 首次：仅读取权限
• 信任建立后：小额执行权限
• 长期用户：更高额度

2. 可解释性（Explainability）

• Agent 必须能解释"为什么这样做"
• 每笔操作附带推理链
• 用户可随时查询决策依据

3. 熔断设计（Circuit Breaker）

• 价格偏离预期 >5% → 暂停执行
• Gas 超出预算 → 取消并通知
• 异常模式检测 → 立即停止

4. 人在回路（Human in the Loop）

• 高风险操作强制人工确认
• 阈值可配置（$100/$1000/$10000）
• 紧急停止按钮始终可用

5. 透明日志（Transparent Logging）

• 链上操作永久可查
• 链下决策（LLM 推理）也要记录 hash
• 用户随时可 export 操作历史

6. 优雅降级（Graceful Degradation）

• Agent 不可用时退回手动 UI
• 网络问题 → 延迟执行，不静默失败
• 清晰的错误提示和恢复路径

5.3 UX 模式总结

---

六、安全设计考量

6.1 攻击面矩阵

6.2 安全最佳实践

✅ 每个 Agent 使用独立的 Session Key
✅ Session Key 有效期最长 7 天
✅ 消费上限写入合约（不可 LLM 绕过）
✅ 关键操作需链上多签
✅ Agent 代码开源 + 第三方审计
✅ 用 TEE 保护 LLM 推理过程
❌ 不要让 Agent 持有主钱包私钥
❌ 不要在 Prompt 中包含助记词

---

七、PM 评估框架：如何判断 AI Agent 产品价值

7.1 三个核心问题

1. 自动化价值：这个任务用 AI 代替人工，价值提升有多大？
   → 量化：节省时间 × 使用频率 × 用户数

2. 可验证性：Agent 的操作结果可以独立验证吗？
   → 链上操作 = 高可验证；纯链下 = 风险高

3. 容错代价：Agent 犯错的后果有多严重？
   → 金融操作错误代价高 → 需要严格 HiL 设计

7.2 产品价值矩阵

                    高自动化价值
                        │
           ┌────────────┼────────────┐
           │            │            │
    低风险 │  ✅ 理想产品  │   ⚠️ 谨慎  │  高风险
           │  (组合收益  │  (大额交易  │
           │   自动化)   │   自动化)   │
           └────────────┼────────────┘
                        │
                    低自动化价值

7.3 当前最具商业价值的 AI Agent 产品

---

八、2026 最新动态（本周速报）

---

九、面试题答案

Q：如何设计一个 AI Agent 友好的 DeFi 产品？

30秒版本： AI Agent 友好的 DeFi 产品需要三层设计：细粒度权限系统（Session Keys）、结构化 API（减少 LLM 解析错误）、熔断保护机制（防止 Agent 异常操作）。

2分钟版本：

权限层：

• 接入 ERC-7715 Session Key 标准，让用户可以给 Agent 颁发限时限额的"授权令牌"
• 权限粒度到操作级别：可以 Swap 不可以 Transfer，可以在 Uniswap 不可以在未知合约

接口层：

• 提供语义化 API：POST /intent 接受自然语言意图，返回结构化执行计划
• 支持模拟执行（dry-run）：Agent 先预演，用户确认再执行
• 标准化事件 schema：方便 Agent 解析链上结果

安全层：

• 消费上限硬编码在合约里（LLM 无法绕过）
• 价格偏离熔断：Gas 超预算/价格滑动 >X% 自动取消
• 操作日志链上可查：用户随时审计 Agent 行为

案例：Uniswap v4 的 Hooks 系统可以被设计成 Agent 兼容的——通过自定义 Hook 实现 Agent 的权限验证和熔断逻辑，不需要改核心合约。

---

Q：AI Agent 如何改变 Web3 产品的用户增长策略？

关键变化：

1. 获客：不再只获取"人类用户"，还要获取"Agent 用户"——API 质量、文档质量变成核心竞争力
2. 留存：Agent 的粘性来自授权历史和习惯模式（换产品=重新训练/配置），比人类用户更高
3. 变现：按 Agent 调用次数收费（x402 模型）而非订阅制，收入更细粒度
4. 指标：需要新增 Agent MAU、Agent 调用成功率、平均授权额度等指标

---

十、今日总结

核心洞察（PM 视角）： AI Agent 不是让 DApp 更智能，而是让 DApp 变成基础设施。未来的竞争不是谁的 UI 更好，而是谁的 API 和权限系统更适合被 Agent 调用。做好 Agent 的工具，比做好人类的界面更重要。

---

Day 73 完成 · 下一步：Day 74 部署上线