去中心化 AI 信誉协议：ERC-8004 解读

区块链
, ,

通过「声誉」和「验证」来发现 Agent 并建立信任。

一、背景与问题

如今 AI Agent 正在从单机工具演变为能够互相调用、协作完成复杂任务的「经济体」。

举个具体的例子：你对一个「旅行规划 Agent」说「帮我安排下周去京都三天的行程」。这个 Agent 本身并不做所有事情，它会：调用「机票搜索 Agent」查询价格、调用「酒店预订 Agent」查询空房、调用「天气 Agent」获取预报、最后调用「支付 Agent」完成结算。整个过程中，你只和第一个 Agent 交互，背后是一条 Agent 互相雇佣的链条。

这种模式带来了一个根本性的问题：「旅行规划 Agent」怎么知道它调用的「机票搜索 Agent」不是一个伪造的恶意服务，会把你的支付信息转卖出去？我们当然可以使用例如大众点评等服务，那么去中心场景下是否有叙事潜力，能够逻辑自洽呢？

当你需要从互联网上找一个素不相识的 Agent 来完成高价值任务时，面临两个核心问题：

  1. 发现问题：Agent 分散在不同的平台和组织，没有统一的目录，如何找到一个具备特定能力的 Agent？
  2. 信任问题：即使找到了，你如何知道它是真实可靠的，而不是伪装的恶意服务？

这两个问题构成了去中心化开放 Agent 经济的基础设施缺口，ERC-8004 就是针对这一缺口提出的解决草案，并在最近已经上线。

二、协议概览与主要角色

ERC-8004 是 MetaMask、Coinbase、Google 等团队于 2025 年 8 月联合提出的以太坊标准草案，全称 Trustless Agents。

它的核心目标是：利用区块链在没有预先信任的情况下，发现、选择、并与跨组织 Agent 进行交互，从而实现开放的 Agent 经济。

整个协议由三个可部署在任意 L2 或主网上的轻量级注册表合约构成：

注册表 核心职责 解决的问题
Identity Registry Agent 的链上身份（基于 ERC-721） 发现：统一目录，可寻址
Reputation Registry 客户对 Agent 的反馈与评分 信任：事后口碑，主观感受
Validation Registry 第三方验证者对 Agent 工作的独立核验 信任：事中/事后核验，客观结果

信任模型是可插拔、分层的，安全强度与风险价值成比例——从点一份外卖这样的低风险任务，到医疗诊断这样的高风险任务，都有对应的信任组合。

协议中涉及的主要角色：

  • Agent Owner：部署并拥有 Agent NFT 的地址，可转让所有权
  • Agent Operator：Owner 授权的管理地址（ERC-721 approve 机制），可更新注册信息但不能转让所有权
  • Client：调用 Agent 服务并提交反馈的地址（可以是普通用户，也可以是另一个 Agent）
  • Validator：独立验证者合约，对 Agent 的工作结果进行核验

三、协议完整运作流程

用一个具体场景串起来：你需要找一个素不相识的 AI 分析 Agent 帮你写一份股票研究报告。

在开始之前有一个基础认知要建立：「Agent 的 AI 服务本体是跑在普通服务器上的链下程序，区块链上存的只是它的身份名片」。ERC-8004 不关心计算在哪里发生，只关心身份信息如何上链存证。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
sequenceDiagram
    participant Owner as Agent Owner<br/>（服务提供方）
    participant IR as Identity Registry<br/>（链上）
    participant TG as The Graph<br/>（链下索引）
    participant RR as Reputation Registry<br/>（链上）
    participant VR as Validation Registry<br/>（链上）
    participant Client as Client<br/>（你）
    participant AgentSvr as Agent Server<br/>（链下服务器）
    participant Validator as Validator<br/>（验证者合约）

    rect rgb(220, 240, 255)
        note over Owner,IR: 阶段一：Agent 把名片钉上链
        Owner->>IR: register(agentURI) 注册身份，指向 IPFS 描述文件
        IR-->>Owner: 返回 agentId（铸造 NFT）
    end

    rect rgb(220, 255, 230)
        note over Client,RR: 阶段二：你去找候选 Agent
        Client->>TG: 按标签/能力筛选 Agent
        TG-->>Client: 返回候选 agentId 列表
        Client->>RR: getSummary(agentId, trustedClients, tag)
        RR-->>Client: 返回历史评分汇总
        Client->>VR: getSummary(agentId, validators, tag)
        VR-->>Client: 返回第三方核验汇总
    end

    rect rgb(255, 250, 220)
        note over Client,AgentSvr: 阶段三：链下调用（与 ERC-8004 无关）
        Client->>AgentSvr: 通过注册文件端点发起任务（MCP / A2A）
        AgentSvr-->>Client: 返回任务结果（股票研究报告）
    end

    rect rgb(255, 235, 220)
        note over Client,RR: 阶段四：完成后给评价
        Client->>RR: giveFeedback(agentId, score, tag)
        RR-->>Client: 返回 feedbackIndex，评价永久上链
    end

    rect rgb(240, 220, 255)
        note over Client,Validator: 阶段五：高风险任务客观核验（可选）
        Client->>VR: validationRequest(validatorAddr, agentId, requestHash)
        VR->>Validator: 触发验证任务
        Validator->>AgentSvr: 用相同输入重跑任务
        Validator->>VR: validationResponse(requestHash, score, tag)
        Client->>VR: getValidationStatus(requestHash)
        VR-->>Client: 返回核验结果（0-100）
    end

阶段一：Agent 把名片钉上链

Agent 服务提供方（Owner）将描述文件上传到 IPFS，然后调用 Identity Registry 注册，获得一个 agentId（本质是一个 NFT）。注册文件里写明了「它的 MCP/A2A 服务端点在哪里」以及「它支持哪些信任机制」。

这里有一个关键问题：Identity Registry 合约地址从哪里来？ERC-8004 规定每条链上只部署「一个全局单例合约」，地址由社区公认，就像 Uniswap 的合约地址一样，所有接入的工具都直接使用这个固定地址。

阶段二：你去找候选 Agent

你通过这个公认的 Identity Registry 地址，用 The Graph 等索引服务按标签/能力筛选，找到几个候选 Agent。

找到候选人之后，你面临的问题是：「注册文件里的能力描述是 Agent 自己写的，没有任何强制验证，本质上是一份简历」。因此在雇佣前，你还需要：

  • 查 Reputation Registry：看历史客户给过什么评分（主观口碑）
  • 查 Validation Registry：看有没有独立第三方核验过它的工作结果（客观背书）
  • 直接连接 MCP 端点，调用 list tools 看它实际暴露了哪些工具（亲自探测）

这三者叠加，才能相对有把握地判断这个 Agent 值不值得信任，但是注意这里最终还是没有办法 100% 确认服务值得信任（这也是我认为有点鸡肋的地方）。

阶段三：链下调用（与 ERC-8004 无关）

选定 Agent 后，你通过注册文件里的端点地址发起任务请求。「这一步完全在链下，走 MCP 或 A2A 协议，ERC-8004 不介入」，它只是给你提供了端点地址的来源。

阶段四：完成后给评价

任务完成后，你调用 Reputation Registry 的 giveFeedback() 打分，你的地址、分值、标签永久记录在链上。这条评价会成为下一个用户判断这个 Agent 的参考。

「这就是 Reputation 的本质：用过的人留下主观评价，积累成长期口碑。」

这里就类似大众点评，当然同样存在刷好评的行为，协议通过指定「信誉提供地址」来指定谁来汇总信誉，但是这里对于信任谁来汇总信誉没有约定，我看来也有点蛋生鸡鸡生蛋的嫌疑……

阶段五：高风险任务需要客观核验（可选）

如果这份报告要用于实际投资决策，口碑不够用，你需要「客观的、可追责的核验结果」。

此时向 Validation Registry 发起验证请求，指定一个 Validator 合约（比如一个质押了 ETH 的重执行节点网络）。Validator 拿着相同的输入重跑任务，结果上链。Validator 如果造假，质押的 ETH 会被没收（slash）——「这是 Validation 与 Reputation 最本质的区别：有经济惩罚兜底，而不只是主观感受」。

至于 Validation 的结果验证/处罚等，也是在 ERC-8004 协议之外的，交给上层协议来自行实现验证者的逻辑。

四、各角色详解

4.1 Identity Registry：链上身份

Identity Registry 在 ERC-721 的基础上加了 URIStorage 扩展，每个 Agent 注册后会获得一个唯一的 agentId（即 tokenId），并关联一个 agentURI（即 tokenURI）。

一个 Agent 的全局唯一标识由两部分组成：

  • agentRegistry：{namespace}:{chainId}:{identityRegistry}，例如 eip155:1:0x742...
  • agentId：ERC-721 分配的 tokenId

这意味着 Agent 的身份本身就是一个 NFT，天然可转让、可组合，并且与所有支持 ERC-721 的应用兼容。

注册文件（Registration File）

agentURI 指向一个 JSON 注册文件，支持 ipfs://、https:// 或完全链上的 Base64 data: URI。核心字段：

1
2
3
4
5
6
7
8
9
{
  "name": "myAgentName",
  "description": "...",
  "services": [
    { "name": "MCP", "endpoint": "https://mcp.agent.eth/", "version": "2025-06-18" },
    { "name": "A2A", "endpoint": "https://agent.example/.well-known/agent-card.json" }
  ],
  "supportedTrust": ["reputation", "crypto-economic", "tee-attestation"]
}

services 完全灵活，可以指向 MCP 端点、A2A AgentCard、ENS 名称、DID 或钱包地址，让 ERC-8004 成为跨协议的统一入口。

核心接口

函数 谁调用 作用
register(agentURI) Owner 注册一个新 Agent，返回 agentId（铸造 NFT）
setAgentURI(agentId, newURI) Owner / Operator 更新注册文件地址，比如服务端点变了
setAgentWallet(agentId, newWallet, deadline, sig) Owner 设置收款地址，需要新地址提供签名证明拥有权
getAgentWallet(agentId) 任何人 查询某个 Agent 当前的收款地址
tokenURI(agentId) 任何人 读取注册文件的 URI（继承自 ERC-721）
getMetadata(agentId, key) 任何人 读取 Agent 的自定义链上元数据
setMetadata(agentId, key, value) Owner / Operator 写入自定义元数据（agentWallet 为保留字段，不能写）

agentWallet 的设计比较特别：初始值等于 Owner 地址，修改时新地址必须自己签名（证明拥有权），且 Agent 转让时自动清零——防止了新 Owner 被原 Owner 的地址截走收款。

4.2 Reputation Registry：口碑信任

Reputation Registry 解决的是「历史表现」维度的信任，任何 clientAddress（排除 Agent 自身 Owner 及 Operator）都可以提交反馈。反馈的核心是一个定点数（int128 value + uint8 valueDecimals），配合可自定义的 tag1/tag2 表达各种维度的信号：

tag1 含义 示例值
starred 满意度评分（0-100） 87
uptime 可用率（%） 9977（即 99.77%，decimals=2）
successRate 成功率（%） 89
responseTime 响应时间（ms） 560
revenues 累计收益（USD） 560

核心接口

函数 谁调用 作用
giveFeedback(agentId, value, decimals, tag1, tag2, ...) Client 提交一条新反馈，返回 feedbackIndex（该 Client 对该 Agent 的第 N 条反馈）
revokeFeedback(agentId, feedbackIndex) Client 撤回自己的某条反馈，将 isRevoked 置为 true，记录不删除
appendResponse(agentId, clientAddr, feedbackIndex, ...) 任何人 对某条反馈追加回应，Agent 可反驳差评，职业聚合器可标记垃圾评价
getSummary(agentId, clientAddresses, tag1, tag2) 任何人 查询指定地址组对某 Agent 的评分汇总（注意：must显式传地址）
readFeedback(agentId, clientAddr, feedbackIndex) 任何人 读取某条反馈的具体内容：分値、tag、是否撤回
getClients(agentId) 任何人 返回所有对该 Agent 提交过反馈的地址列表
getLastIndex(agentId, clientAddr) 任何人 返回某地址对该 Agent 共提交了几条反馈

getSummary 的关键设计：必须显式传入 clientAddresses，只返回这组指定地址的评分汇总，而不是所有反馈的汇总。这是防女巫的核心——攻击者可以用大量小号刷分，但「哪些地址值得信任」的判断权在上层应用，协议本身不做这个决策。

两个值得注意的细节：value、tag1、tag2 写入链上 Storage（其他合约可直接读，支持链上可组合逻辑）；feedbackURI 等辅助字段只通过事件发出（便宜十几倍，链下子图索引即可）。每条反馈有 isRevoked 标志位，撤回后记录本身不删除，只是标记无效——区块链上任何数据都删不掉，这保证了审计可追溯。

4.3 Validation Registry：客观核验

Reputation Registry 依赖客户的主观感受，而 Validation Registry 提供的是独立第三方的客观核验，支持多种验证机制：Staker 质押后重跑任务对比结果（造假被 slash）、zkML 零知识证明、TEE 可信执行环境证明，或受信任的人工评判者。

核心接口

函数 谁调用 作用
validationRequest(validatorAddr, agentId, requestURI, requestHash) Owner / Operator 向指定 Validator 发起一次验证请求，requestHash 是链下数据的哈希承诺
validationResponse(requestHash, response, responseURI, responseHash, tag) Validator 合约 提交验证结果，response 值域 0-100，可多次调用更新状态
getValidationStatus(requestHash) 任何人 查询某次验证请求的当前结果：Validator 地址、AgentId、response 值、最后更新时间
getSummary(agentId, validatorAddresses, tag) 任何人 查询指定 Validator 组对某 Agent 的验证汇总（平均分、次数）
getAgentValidations(agentId) 任何人 返回某 Agent 所有验证请求的 requestHash 列表，从而反查所有验证历史
getValidatorRequests(validatorAddress) 任何人 返回某 Validator 处理过的所有请求——可用于评估 Validator 的历史工作量

validationResponse 可被多次调用（同一 requestHash），配合 tag 字段实现渐进式状态：先提交「初步核验（soft finality）」，再提交「最终确认（hard finality）」。Validator 的质押和 slashing 逻辑由各验证协议自行实现，ERC-8004 只提供记录结构。

五、与其他协议的关系

ERC-8004 与现有 Agent 协议的定位是互补而非竞争：

MCP 和 A2A 负责「怎么说话」，ERC-8004 负责「找谁说话」和「信不信他」。

协议 职责层 解决的问题
MCP 能力层 Agent 如何暴露工具、资源、提示
A2A 通信层 Agent 间认证、任务编排、消息传递
ERC-8004 目录 + 信任层 Agent 的发现、身份、声誉、核验

类比来说，如果 MCP 是 HTTP，A2A 是 SMTP，那么 ERC-8004 就是 DNS + 信用评分机构的组合。

1
2
3
4
5
6
7
8
9
10
11
flowchart TD
    App["应用层<br/>Agent Orchestrator / 用户应用"]
    ERC8004["目录 + 信任层<br/>ERC-8004<br/>（发现 · 身份 · 声誉 · 验证）"]
    A2A["通信层<br/>A2A<br/>（认证 · 任务编排 · 消息传递）"]
    MCP["能力层<br/>MCP<br/>（工具 · 资源 · 提示暴露）"]
    Agent["执行层<br/>Agent 服务本体<br/>（链下服务器 / 去中心化计算）"]

    App -->|查询可信 Agent| ERC8004
    ERC8004 -->|提供端点地址| A2A
    A2A -->|协商能力| MCP
    MCP -->|调用执行| Agent

与支付协议（x402）的关系：支付流程是正交的，ERC-8004 刻意不处理支付逻辑，但预留了集成钩子：注册文件有 x402Support 布尔字段，反馈文件有 proofOfPayment 结构。这意味着付款凭证本身可以成为声誉信号——只有真实付过钱的 Client 的反馈，自然比匿名反馈更可信。

与 EIP-7702 的关系：结合 EIP-7702 的 Gas 赞助能力，应用可以代替 Client 支付提交反馈的 gas，Client 甚至不需要持有 ETH，大幅降低参与门槛。

六、可能遗留的问题

ERC-8004 是一个务实的最小化协议，刻意将复杂问题留给生态解决，这带来了灵活性，但也留下了一些值得关注的开放问题：

1. 女巫攻击根治难

协议通过「显式传入 clientAddresses」的设计来缓解刷分问题，但这只是把责任转移给了上层应用。谁来维护一份「可信 reviewer 名单」？这本身又是一个鸡生蛋蛋生鸡的问题——新的声誉系统同样需要信任引导（bootstrap），我个人理解就是有点「留给后人智慧」的感觉……。

2. 恶意能力无法链上验证

ERC 原文明确指出：「this ERC cannot cryptographically guarantee that advertised capabilities are functional and non-malicious」。注册文件中声称的能力（比如”我能做医疗诊断”）是否属实，协议本身无法验证，只能依赖声誉和验证两个事后机制。这也是大模型这种混沌系统的通病，通常还是要靠确定性系统来进行弥补。

3. Validator 的激励设计不在范围内

Validation Registry 只提供结构，具体 Validator 如何质押、如何被惩罚（slashing）由各验证协议自行设计。这意味着 Validator 的质量参差不齐，用户需要自行甄别信任哪些 Validator。

4. 链下数据的持久性

注册文件和反馈文件大量依赖链下存储（https:// 或 IPFS），链上只保存哈希作为完整性承诺。IPFS 数据如果没有人 pin，依然可能失效；https:// 链接则有中心化风险。协议 RECOMMEND 使用 IPFS，但并非强制。

5. 跨链身份聚合

一个 Agent 可以同时在多条链注册，registrations 字段支持声明多个注册记录，但如何在链下将这些分散的身份聚合成统一的信誉视图，协议没有给出规范。

总体来看，这些问题可以归结为一个更深层的矛盾：ERC-8004 试图用「去中心化的数据结构」解决「需要社会共识才能解决」的信任问题。链上的数据可以做到不可篡改，但「谁的评价值得信赖」「哪个 Validator 真的可靠」这些问题的答案，本质上不是技术问题，而是社会共识问题。

协议的回答是：「我提供基础设施，让生态自己演化出答案。」这是一个务实的选择，也是以太坊生态一贯的路子——但它也意味着，在生态足够成熟之前，ERC-8004 的信任保证更多是「有胜于无」，而不是真正的 trustless。甚至我个人觉得最后理论上的「去中心化」还是会演化成几个大服务商的事实「中心化」。

七、总结

ERC-8004 出现的时机很准——MCP/A2A 已被主流接受，但跨组织 Agent 协作尚未大规模落地，它试图补上最后一块缺失的拼图：可组合的链上身份、声誉与验证基础设施。设计哲学是最小化链上接口、最大化生态可扩展性，三个注册表只定义结构，把评分算法、激励机制、声誉聚合全部留给上层——这是以太坊生态的一贯路子（ERC-20、ERC-721 都是如此）。

但它也有一个根本性的冷启动困境：Reputation 需要足够多的可信评价才有意义，Validation 需要足够多的 Validator 建起声誉才有价值，而这两者都需要生态先存在才能积累。与其说它「解决了信任问题」，不如说它「让信任问题变得可观测、可追溯、可组合」——真正的信任，还是要靠时间和博弈来沉淀。

在那个未来，雇佣一个素不相识的 AI Agent 来处理重要决策，就像在电商平台上看商家评分和官方质检报告一样自然——不需要认识对方，只需要相信那套记录系统。

最后的最后，对于区块链/去中心化系统，我还是坚持这个观点「只有当个人生产效率在某方面大于集体生产效率，去中心化才是有意义的」，而 AI 是否能来这样生产力的进步，从而催化去中心化世界的发展，让我们拭目以待吧。

八、参考资料