我把ERC-8004部署到了Sepolia：AI Agent链上身份的实战之路ERC-8004实战部署：6个智能合约部署

我把ERC-8004部署到了Sepolia：AI Agent链上身份的实战之路

标签：Web3 · AI Agent · 智能合约 · 以太坊 阅读时间：约12分钟

前言：当AI Agent开始持有资产

2025年，AI Agent正在从"聊天机器人"进化为"链上经济参与者"。它们可以持有钱包、执行DeFi策略、参与治理投票、甚至自主交易。

但一个根本问题浮出水面：

如何让一个没有人类私钥的自主实体，在链上拥有可验证的身份和信任？

2025年8月，以太坊社区提出了 ERC-8004（Trustless Agents） 标准草案，试图用三个链上注册表（身份、声誉、验证）来解决这一问题。该草案的作者阵容相当豪华——来自MetaMask、以太坊基金会、Google、Coinbase等机构。

作为一名Web3开发者，我决定不只是读标准，而是真正把它部署上去跑起来。本文记录了我从零到部署ERC-8004全套合约到Sepolia测试网的完整过程，包括踩过的坑、关键代码和最终成果。

一、ERC-8004核心概念

ERC-8004定义了AI Agent在链上的三种核心数据结构：

1. 身份注册表（Identity Registry）

基于ERC-721的Agent身份NFT，每个Agent是一个NFT Token：

// 核心数据结构
struct AgentIdentity {
    address owner;          // Agent的创建者/所有者
    string  name;           // Agent名称，如 "QClaw Master Agent"
    uint8   trustLevel;     // 信任等级 1-5
    uint256 capabilityCount;// 拥有的能力数量
    uint256 validationCount;// 被验证的次数
    bool    active;         // 是否活跃
}

关键特性：

一个地址只能创建一个Agent身份（防Sybil）
Agent身份NFT可转移，但信任等级跟着走
支持端点注册（A2A、MCP、ENS、DID）

2. 声誉注册表（Reputation Registry）

struct AgentReputation {
    uint256 totalScore;     // 累计声誉分
    uint256 feedbackCount;  // 反馈次数
    uint256 validationCount;// 验证次数
}

扣分制：初始8000分，反馈影响分数
不可操纵：每个地址对每个Agent只能反馈一次
聚合考量：分数 = 总评分 / 反馈次数的加权

3. 验证注册表（Validation Registry）

// 验证类型
enum ValidationType {
    CodeAudit,      // 0: 代码审计
    TEEAttestation, // 1: TEE认证
    ZKProof,        // 2: 零知识证明
    ManualReview,   // 3: 人工审核
    SocialSignal,   // 4: 社交信号
    Custom          // 5: 自定义
}

验证者需要质押ETH才能提交验证，验证数据包括类型、结果哈希、证明数据和过期时间。

二、技术架构

开发环境

组件	版本
Hardhat	2.x
Solidity	0.8.19
OpenZeppelin	4.9.3
ethers.js	v6
网络	Ethereum Sepolia

合约架构图

┌─────────────────────────────────────────┐
│           Application Layer             │
│  ┌─────────┐  ┌──────────┐  ┌────────┐ │
│  │ A2A协议  │  │ MCP协议   │  │ ENS   │ │
│  └────┬────┘  └────┬─────┘  └───┬────┘ │
├───────┴─────────────┴────────────┴──────┤
│           Trust Layer (ERC-8004)        │
│  ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│  │ Identity  │ │Reputation│ │Validation│ │
│  │ Registry  │ │ Registry │ │ Registry │ │
│  │(ERC-721) │ │          │ │          │ │
│  └──────────┘ └──────────┘ └─────────┘ │
├─────────────────────────────────────────┤
│           Execution Layer (EVM)          │
│  ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│  │DeFAIVault│ │ Strategy │ │ Bridge  │ │
│  │  V2      │ │ Executor │ │ (跨链)  │ │
│  └──────────┘ └──────────┘ └─────────┘ │
└─────────────────────────────────────────┘

三、部署实战

3.1 部署的合约

我将ERC-8004扩展为一个包含6个合约的完整套件（V2版本）：

合约	地址	功能
ERC8004IdentityV2	`0xc0D37E6F...`	Agent身份NFT
SimpleReputationRegistryV2	`0xeD24f204...`	声誉管理
SimpleValidationRegistryV2	`0xa390763C...`	验证注册
DeFAIVaultV2	`0xf1b78204...`	DeFi金库
StrategyExecutor	`0x3ba9BEdE...`	策略执行器
CrossChainBridge	`0xd012bcA5...`	跨链桥

所有合约已通过Sepolia Etherscan源码验证 ✅

3.2 踩坑记录

坑1：Hardhat 2.x API变更

// ❌ Hardhat 2.x 中这些方法不存在或行为变了
await contract.deployed();           // 不存在
contract.deployTransaction;          // 返回undefined

// ✅ 正确写法
const deployed = await contract.waitForDeployment();
const txHash = deployed.deploymentTransaction()?.hash;

坑2：ABI参数顺序不一致

// 合约源码：function submitFeedback(uint256 agentId, uint8 score, string comment, uint256 taskId)
// ABI声明：  function submitFeedback(uint256 agentId, uint8 score, uint256 taskId, string comment)
//                                                              ↑ 这两个参数顺序反了！

编译生成的ABI文件中参数顺序和源码不一致，导致所有feedback交易revert。手动修正ABI后解决。

坑3：网络参数未指定

# ❌ 直接运行，Hardhat默认连本地localhost:31337
node scripts/interact.js

# ✅ 必须指定网络
npx hardhat run scripts/interact.js --network sepolia

这个bug花了最长时间排查——所有交易都返回空值，看起来像是成功了，实际上根本没发到链上。

坑4：编译器Stack Too Deep

// hardhat.config.js
solidity: {
  version: "0.8.19",
  settings: {
    viaIR: true,  // 解决DeFAIVaultV2的stack too deep
    optimizer: {
      enabled: true,
      runs: 200
    }
  }
}

坑5：Etherscan验证

最终发现使用build-info JSON格式提交最可靠：

// 必须包含viaIR设置
const input = JSON.parse(buildInfo.input);
// 去掉remappings，直接用 @openzeppelin/... 作为source key
delete input.settings.remappings;
// 使用 solidity-standard-json-input 格式提交

四、E2E全流程验证

部署完成后，我编写了一个完整的端到端测试脚本，模拟Agent从创建到执行任务的完整生命周期：

Phase 1: 创建Agent身份 → Agent #1 "QClaw Master Agent"
Phase 2: 添加能力 → addCapability("defi_trading", capabilityHash)
Phase 3: 记录验证 → recordValidation(TEEAttestation, passed=true)
Phase 4: 更新信任等级 → trustLevel 1→5 (Platinum)
Phase 5: 声誉确认 → score=8000, validations=5

E2E Grand Loop v3 全部5个Phase通过，耗时36.8秒。

链上最终状态

Agent #1: "QClaw Master Agent"
├── Trust Level: 5/5 (Platinum)
├── Capabilities: 7 (defi_trading, data_analysis, risk_management, ...)
├── Reputation Score: 8000
├── Validations: 5 (latest: TEE Passed ✅)
├── Owner: 0x275E...dBA
└── Active: true

五、进阶：TARS安全框架

基于ERC-8004的基础设施，我进一步设计了 TARS（Trustless Autonomous Agent Resilience & Security） 三层安全框架：

Layer 1: 能力范围控制（ACS）

struct CapabilityScope {
    bytes32 role;               // "liquidity_bot"
    uint256 maxSlippageBps;     // 50 = 0.5%
    uint256 dailyLimit;         // 日限额
    address[] tokenWhitelist;   // 白名单代币
    bytes4[] allowedFunctions;  // 允许调用的函数
    uint8 dataTier;             // 1=最终, 2=预确认, 3=实时
}

Layer 2: ZK合规证明

扩展ERC-4337 UserOperation，交易进入内存池前必须携带合规证明：

实时层：<100ms，TEE认证
快速层：~1s，预生成ZK证明
深度层：数分钟，完整ZKML验证

Layer 3: 动态经济安全

RequiredStake = BaseStake + (AUM × VariableRate × VolatilityMultiplier)

质押要求随资产规模动态调整：

Tier 1 (<100 ETH): 0.5% 可变费率
Tier 2 (100-1000 ETH): 1%
Tier 3 (>1000 ETH): 2%

六、开放讨论

我在 GitHub ethereum/ERCs#1696 发起了讨论，提出了三个开放问题：

可验证合规的可扩展性：ZK证明生成耗时与高频Agent操作的矛盾如何解决？
惩罚机制的经济均衡：如何防止恶意挑战者通过虚假证明骚扰正常Agent？
身份-能力的隐私平衡：ABAC需要暴露属性信息，如何用ZK实现选择性披露？

七、如何体验

我已经搭建了一个可交互的Demo页面：

在线Demo：wscdcm.github.io/erc8004-dem… （推荐，无需安装）
本地Demo：需要启动代理访问Sepolia RPC
合约地址：所有6个V2合约均已部署在Sepolia
源码仓库：包含完整合约、部署脚本、测试用例

快速检查合约状态

// 连接Sepolia，查询Agent #1
const identity = new ethers.Contract(
  "0xc0D37E6F7B214C92f292FC0534195027CD38AB79",
  ABI, provider
);
const agent = await identity.getAgentIdentity(1);
// → name: "QClaw Master Agent", trustLevel: 5, active: true

🔗 在线体验

Demo 页面已上线：wscdcm.github.io/erc8004-dem…

支持 MetaMask 钱包交互模式和只读模式，可在浏览器中直接查看链上 Agent 状态。

总结

ERC-8004代表了Web3+AI融合的关键基础设施——它不是又一个DeFi协议，而是试图为未来的AI经济建立身份层。

从这次实践中，我的核心收获是：

标准草案≠可以直接用：ERC-8004目前仍是Draft，很多细节需要自己实现
开发者体验还很粗糙：Hardhat/ethers.js的API碎片化严重，调试成本高
信任模型的设计空间巨大：简单的声誉评分远远不够，需要分层、动态、隐私保护的体系
真正的壁垒在验证层：ZKML、TEE、形式化验证，这些才是硬核部分

AI Agent正在成为链上一等公民，而ERC-8004为它们提供了"出生证明"。但要让Agent真正可靠地管理资产，我们还有很长的路要走。

本文所有代码和合约地址均已在Sepolia测试网验证。欢迎在GitHub Issues中讨论或提交PR。

相关链接：

ERC-8004讨论帖：github.com/ethereum/ER…
Ethereum Magicians讨论：ethereum-magicians.org/t/erc-8004-…
Etherscan验证合约：在Sepolia搜索 0xc0D37E6F7B214C92f292FC0534195027CD38AB79