ERC-8004、A2A 和 MCP 共同构建了 AI 智能体（Agent）经济的基础设施，其中 ERC-8004 在以太坊上扮演了信任层的角色，将原本仅用于通信和工具调用的 Web2 协议引入了 Web3 的可信环境。

角色分工：通信、工具与信任

要理解三者的整合，首先要明确它们各自在 AI 智能体生态系统中的核心作用：

总结来说：

• A2A 负责横向的智能体对话。
• MCP 负责纵向的智能体工具调用。
• ERC-8004 在整个A2A/MCP 协作的外部，通过区块链提供了可信的“规则和账本”，确保了在开放市场中：“你是谁（身份）”，“你做得怎么样（声誉）”，以及“你是否完成了任务（验证和结算）” 都是可信和可审计的。

这种三层架构使得 AI 智能体能够从孤立的程序进化为可以在去中心化网络中进行可信、可验证、可交易协作的经济主体，具体分析如下文。

ERC-8004 与 A2A 的整合

ERC-8004 是 A2A 协议在去中心化环境下的“信任增强包”或“Web3 扩展”。

A2A 协议本身定义了智能体之间如何进行对话、分配子任务（例如：客户代理将分析任务委派给财务代理）。然而，A2A 缺少信任与安全的能力，ERC-8004 补全了这一点。

1、身份与发现（Identity & Discovery）：

• A2A 协议通过 AgentCard（代理描述文件）描述智能体的能力、API 端点等信息。
• ERC-8004 引入的身份注册表 (Identity Registry) 将智能体的链上地址与其 AgentCard 描述文件（通常是 URI）绑定起来，并在链上记录。
• 效果： 这为 A2A 提供了不可篡改的链上身份。一个智能体可以根据另一个智能体的链上地址，通过 ERC-8004 注册表查询到其 A2A 通信所需的元数据，实现可信的代理发现。

2、信誉与选择（Reputation & Selection）：

• 在 A2A 协作前，客户端代理需要决定信任哪个服务代理。
• ERC-8004 的声誉注册表 (Reputation Registry) 允许合作完成后，双方将关于服务质量的反馈和评分（包含任务描述、签名等）的哈希值 / 证明记录在链上。
• 效果： 任何智能体都可以查询并聚合这些公开的链上记录，形成去中心化的信用报告。这为 A2A 的协作协商步骤增加了信任决策的基础，避免了恶意或低效的智能体。

3、任务执行与结算（Validation & Settlement）：

• 在 A2A 协作过程中，如何确保服务代理确实完成了任务？
• ERC-8004 的验证注册表(Validation Registry) 提供了多种验证模型的链上挂钩（on-chain hook），例如支持抵押保障（Restaking）、可信执行环境（TEE）证明或零知识证明（ZK Proofs）。
• 效果： 任务执行的结果哈希或验证证明被提交到此注册表。这使 A2A 任务的交付具备可信性，并能无缝整合 x402 支付协议（一种微支付协议）或其他支付标准，实现基于验证结果的自动结算。

ERC-8004 与 MCP 的协同

MCP（Model-Controller Protocol） 关注的是单个智能体如何与其工具箱（模型、数据、API）进行交互的标准化。它使得智能体能够以统一的格式，像使用函数一样使用外部能力。

当一个复杂的任务在多个智能体之间通过 A2A 拆分和协调时，其中一个服务代理可能需要在内部使用 MCP 来调用工具。

1. A2A 协调： 客户端代理（Charlie）使用 A2A 协议向市场分析代理（Alice）发送任务请求。
2. ERC-8004 信任检查： Charlie 在发送任务前，通过 ERC-8004 的身份和声誉注册表验证 Alice 的身份和过往记录。
3. MCP 工具调用（内部）： Alice 接收任务后，在内部使用 MCP 协议来调用一个搜索 API 或一个金融模型来执行分析工作。
4. 结果返回与验证： Alice 将分析结果通过 A2A 返回给 Charlie。
5. ERC-8004 结算： 为了确保结果质量，Alice 和 / 或一个验证代理（Validator Agent，Bob）会在 ERC-8004 的验证注册表上提交结果的证明。Charlie 根据链上的验证结果，触发基于 x402 协议或其他机制的支付结算。

案例分析

这个案例基于社区中公开的 ERC-8004 示例代码库，它展示了如何利用 ERC-8004 的三个注册表来协调 AI 代理。

角色定义（基于 A2A 协议）

在这个用例中，我们设定三个智能体角色，它们之间的协作通信遵循 A2A 协议的模式：

实现流程：分步详解

整个工作流是一个 A2A 任务流程，由 ERC-8004 提供信任和结算保障，由 MCP 提供工具调用能力。

阶段一：发现与信任（A2A + ERC-8004）

1. 身份绑定： Alice 和 Bob 首先将他们的链上地址与其 **AgentCard（A2A 描述文件）**URI 注册到 ERC-8004 身份注册表中。
2. 可信发现： Client Agent (Charlie) 希望寻找一个市场分析服务。它查询 ERC-8004 的声誉注册表，查看潜在 Server Agent (Alice) 的历史评分记录，并查询身份注册表获取 Alice 的 A2A 描述文件，以确认其能力和通信端点。
3. 任务协商： Charlie 基于信任评估，使用 A2A 协议向 Alice 发送市场分析任务的请求和详细参数。

阶段二：任务执行与工具调用（MCP 介入）

1. MCP 执行： Server Agent (Alice) 接收到 A2A 任务后，需要执行具体分析工作。在这个过程中，Alice 内部使用了 MCP 协议来访问所需的工具和数据：

• 调用工具： Alice 使用 MCP 标准格式调用外部金融数据 API 或 ** 大语言模型（LLM）** 来进行数据检索和推理。
• MCP 优势： 无论 Alice 调用的是一个私有的 RAG 系统还是公共的 Bing 搜索 API，MCP 确保了这些工具和模型的接口调用是标准化的。

2. 结果生成： Alice 完成分析，生成报告。

阶段三：结果验证与反馈结算（ERC-8004 + A2A）

这是 ERC-8004 提供的核心价值，它将 A2A 的通信结果带到了链上进行可信验证：

1. 验证任务： Alice 将分析报告的加密哈希值和必要的元数据提交到 ERC-8004 验证注册表。
2. 可信验证： Validator Agent (Bob) 接收到 A2A 消息，并根据任务协议，在链下使用 ** 可信执行环境（TEE）或重质押网络（Restaking AVS）** 对 Alice 的报告进行验证。
3. 验证结果上链： Bob 将验证结果（例如“任务成功”或“发现作弊”）以加密证明的形式提交到 ERC-8004 验证注册表。
4. 声誉更新：

• Charlie 确认服务完成且通过验证后，向 ERC-8004 声誉注册表提交对 Alice 的反馈和评分记录的哈希值 / 证明。
• 这为 Alice 积累了可信的链上信用。

5. 自动结算： Charlie 的智能合约监控 ERC-8004 验证注册表的状态。一旦验证通过，它将触发基于 x402 支付协议的微支付，自动向 Alice 的链上地址支付服务费用。

代码实现示例

关键协作步骤（A2A 模式）

该示例模拟了 Client Agent (Charlie)、Server Agent (Alice) 和 Validator Agent (Bob) 之间的 A2A 工作流。

关键代码片段分析：身份注册（A2A 发现的基础）

A2A 协议依赖 AgentCard 来描述智能体的能力和端点。ERC-8004 的身份注册表 (Identity Registry) 将这个 off-chain 的 A2A 描述文件与 on-chain 地址绑定，实现可信发现。

以下是 Solidity 智能合约中实现这一功能的简化代码：

// ERC-8004 IdentityRegistry 合约片段 ( 示例 )

contract IdentityRegistry {
    // 代理的基本结构，AgentAddress 是链上身份，AgentDomain 指向 off-chain 的 AgentCard/A2A 描述文件
    struct Agent {
        uint256 AgentID;
        string AgentDomain; // e.g., 'market-analysis.agent.eth'
        address AgentAddress; 
    }

    uint256 private _nextAgentID = 1;
    mapping(address => uint256) private _agentAddressToID; // 地址到 ID 的映射

    // 关键函数：注册代理
    function registerAgent(string calldata agentDomain, address agentAddress) external {
        // ... ( 检查和权限要求 )
        uint256 newAgentID = _nextAgentID++;
        _agents[newAgentID] = Agent(newAgentID, agentDomain, agentAddress);
        _agentAddressToID[agentAddress] = newAgentID;

        // 触发链上事件，供链下 A2A 发现工具索引
        emit AgentRegistered(newAgentID, agentDomain, agentAddress); 
    }

    // 供其他代理（如 Client Agent）查询
    function getAgentID(address agentAddress) public view returns (uint256) {
        return _agentAddressToID[agentAddress];
    }
}

整合分析：

• 当 Client Agent (Charlie) 想通过 A2A 协议与 Alice 协作时，它首先查询这个 Identity Registry，用 Alice 的链上地址（可信的）获取其 AgentDomain。
• 随后，Charlie 才能通过该域名（例如 market-analysis.agent.eth）去获取 AgentCard 并进行 A2A 任务协商。

关键代码片段分析：AgentCard 支持 MCP

根据 ERC-8004 的设计，智能体的 **AgentCard（A2A 描述文件）** 是 off-chain 的，它不仅包含 A2A 通信信息，还包含智能体提供的 MCP 服务信息。

AgentCard (JSON 格式，简化 )：

{
    "agentName": "Alice_Market_Analyst",
    "agentAddress": "0xAlice123...", 
    "protocols": ["A2A", "MCP"], // 声明支持的协议

    "capabilities": {
        "analysis": {
            "functionName": "analyze_stock_trend",
            // MCP 的关键信息：定义了 Alice 执行任务时需要调用的工具 / 模型 / 提示词
            "mcp_definition_uri": "ipfs://Qmasdfg/alice_tools.json", 
            "price_model": "x402_pay_per_call" // 声明结算模型
        }
    },
    
    // ERC-8004 额外要求的信任信息
    "trustModels": ["TEE-attestation", "cryptoeconomic-validation"],
    "reputationEndpoint": "https://offchain-reputation.com/api/alice" 
}

整合分析：

• Client Agent 发现 Alice 后，下载其 AgentCard。
• AgentCard 中的 mcp_definition_uri 间接指导 Client/Server Agent 如何使用 MCP 协议来调用模型或工具（例如，查询 Alice 专用的 API 或模型）。
• 因此，ERC-8004 负责可信发现 (Identity Registry)，而 MCP 负责执行 (AgentCard 中定义的工具 / 模型接口 )。

关键代码片段分析：验证与支付（Validation & Payment）

x402 协议用于处理机器间的微支付（Micropayment）。ERC-8004 旨在作为其信任和验证的挂钩，实现基于任务完成质量的自动支付。

ERC-8004 的验证注册表 (Validation Registry) 记录了任务是否被可信地完成，这是触发 x402 支付的关键。

以下是 Solidity 智能合约中，一个基于验证成功的支付释放（Payment Release）的简化模型：

// 假设这是集成 ERC-8004 的支付 / 托管合约 (Escrow Contract)

contract AgentPaymentEscrow {
    // 引用 ERC-8004 Validation Registry
    IValidationRegistry public validationRegistry;
    // 引用 USDC 代币合约
    IERC20 public usdc; 

    // 假设 ValidationResponse 包含一个 Status（成功或失败）
    function releasePayment(uint256 taskId, uint256 amount, address payable serverAgent) 
        external onlyClient { // 只能由 Client Agent 调用
        
        // 核心步骤：查询 ERC-8004 验证注册表，确认任务已通过验证
        (uint256 status) = validationRegistry.getValidationStatus(taskId);
        
        require(status == VALIDATION_SUCCESS, "Validation failed or pending.");

        // 验证通过，执行 x402 微支付（或标准 ERC-20 转账）
        usdc.transfer(serverAgent, amount); 

        emit PaymentReleased(taskId, serverAgent, amount);
    }
}

整合分析：

1. A2A 协作：任务完成。
2. ERC-8004 验证：Validator Agent (Bob) 向 Validation Registry 提交成功状态 (VALIDATION_SUCCESS)。
3. x402 结算：Client Agent (Charlie) 或托管合约查询该状态。一旦状态被确认，资金就会根据预先协商的 x402 支付凭证条款自动释放给 Server Agent (Alice)。

简而言之，x402 定义了支付流程，而 ERC-8004 通过其链上注册表为这个流程提供了不可篡改的条件判断。

参考链接

1.https://8004.org/ 2.https://eips.ethereum.org/EIPS/eip-8004 3.https://github.com/google-agentic-commerce/a2a-x402 4.https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098 5.https://github.com/chaoschain/erc-8004-example