我把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：需要启动代理访问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
总结
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
