ERC-8004与AI-Agent链上经济-去中心化身份-可验证推理与自主代理的技术架构解析

摘要

2026年1月，ERC-8004核心注册表部署至以太坊主网，这是首个为AI Agent提供链上身份与声誉的以太坊标准（注：截至目前该标准仍处于草案/提案讨论阶段，尚无足以确认已正式部署至主网的权威公开来源，此处主网上线为作者表述，需核实）。与此同时，部分L2网络和测试网的观测数据显示，AI Agent发起的交易量占比已达约40%（该比例来源与口径需核实，不同网络差异显著）——AI Agent不再是概念验证阶段的实验品，而是已经实质性地嵌入了区块链经济的运行逻辑。然而，Agent经济的爆发暴露了一系列基础设施缺口：Agent缺乏标准化身份、无法证明推理过程的可信性、缺少链上原生支付通道、机密计算能力缺失。围绕这些问题，一个跨越多层协议的技术栈正在成形——从底层的TEE/ZKP/FHE机密计算，到中间层的ERC-8004身份注册/ERC-6551代币绑定账户/x402支付协议，再到应用层的Agentic Contract与可验证推理。本文系统性地拆解这一技术栈的架构设计、安全假设与当前局限，以ERC-8004为锚点，追踪Agent经济从基础设施到应用场景的演进脉络，并对多Agent协作、M2M经济的系统性挑战给出独立判断。

一、引言：Agent经济的信任鸿沟

区块链与AI的交汇点，正在从"用AI分析链上数据"的浅层整合，走向"AI Agent作为链上经济的一等公民"的深层融合。这一转变的驱动力不难理解：智能合约的确定性执行模型天然排斥模糊性和概率判断，而AI Agent恰好擅长在不完全信息环境中做出决策。当Agent可以持有资产、发起交易、参与DeFi策略时，它实质上在链上获得了"经济主体"的地位。

但一个经济主体要在开放网络中运行，信任是先决条件。传统互联网经济通过"账号体系+实名认证+信用评分"解决信任问题，但在去中心化的链上世界，这套体系无法直接套用。AI Agent面临的信任鸿沟具体表现在：

身份缺失：链上的Agent只是一组私钥控制的地址，无法与其他地址区分——你无法判断某个地址背后是程序还是人类，更无法知道这个程序的行为模式。
声誉真空：没有标准化的链上声誉系统来记录Agent的历史行为表现。一个频繁执行恶意套利或闪贷攻击的Agent，可以轻易创建新地址抹去历史。
推理不可验证：Agent声称"我的AI模型做出了这个决策"，但你无法验证这个决策是否真的由声称的模型产生、输入数据是否被篡改、推理过程是否被干预。
支付通道碎片化：Agent之间、Agent与人类之间、Agent与链下服务之间的支付缺少标准化协议，每笔交易都需要定制化的支付逻辑。

ERC-8004的出现，正是为了系统性回应这些信任问题。但ERC-8004本身不是银弹——它是整个Agent经济技术栈中的一个关键组件，需要与身份基础设施（ERC-6551）、支付协议（x402/ACP）、机密计算层（TEE/ZKP/FHE）、可验证推理（zkML）等协同工作。下文将逐一拆解这些组件的技术机制与交互关系。

二、ERC-8004：链上Agent身份的三注册表架构

ERC-8004定义了三个核心注册表（Registry），分别解决身份、声誉和信任三个层面的问题。

2.1 Identity Registry：Agent的链上身份证

Identity Registry采用了与ERC-721类似的设计模式——每个Agent被赋予一个唯一的标识符（tokenId），映射到一个Agent注册文件（Agent Profile）。注册文件包含以下关键字段：

Agent描述：名称、简介、能力声明（如"擅长DeFi套利"、"专注于NFT做市"）。
模型信息：所使用AI模型的架构类型（如LLM、RL Agent）、训练数据范围声明、推理接口端点。
控制者信息：Agent的链上控制地址——拥有该NFT的地址可以更新Agent配置或终止Agent运行。
元数据URI：指向链下存储的详细配置文件（如IPFS上的JSON文档）。

这个设计的巧妙之处在于"身份与NFT绑定"——Agent的身份标识是一个NFT，这意味着身份本身可以被转移、交易或作为抵押品。一个拥有良好声誉记录的Agent身份，其NFT可能具有市场价值——这为Agent的声誉系统引入了经济激励维度。

但这一设计也带来了一个需要正视的问题：身份的可转让性可能被滥用。如果一个恶意Agent积累了不良声誉，其控制者可以转让该NFT给新地址，"换壳"重新开始。ERC-8004通过Reputation Registry与Identity Registry的绑定来部分缓解这一问题——声誉记录与Identity绑定，而非与控制地址绑定，因此身份转让不会抹去历史声誉。

2.2 Reputation Registry：链上行为档案

Reputation Registry记录Agent的链上行为表现，形成一个持续更新的行为档案。核心数据包括：

交易统计：Agent发起的交易总数、成功率、平均Gas消耗。
协议交互记录：Agent与哪些DeFi协议交互过，交互频率如何。
争议与仲裁：是否被其他Agent或人类提出过争议，仲裁结果如何。
同行评价：其他Agent或人类对该Agent的主观评分。

Reputation Registry的数据来源分为两类：客观指标（交易统计、协议交互）可以直接从链上数据中提取，无需人工介入；主观指标（争议、评价）需要设计仲裁和评分机制，复杂度更高。

一个关键的设计决策是：Reputation Registry中的数据是"声明式"的而非"验证式"的。也就是说，任何人都可以提交关于某个Agent的声誉数据，但数据的真实性需要由消费者自行判断。这类似于Web2中的评价系统——你看到一条差评，需要自己判断它是否真实。不同的是，链上的声誉数据是不可篡改的——一旦写入，无法删除或修改。这既是优势（防止数据被操控），也是挑战（错误或恶意的评价一旦写入就难以纠正）。

2.3 Trust Registry（Validation Registry）：验证与授权注册表

Trust Registry是三个注册表中最具实验性的一个。它解决的问题是：在开放网络中，Agent如何判断"我是否应该信任另一个Agent"？

Trust Registry维护两类记录：

验证声明：第三方（如审计机构、信誉良好的验证者）声明某个Agent通过了特定标准的验证。例如，"Agent X通过了安全审计，其推理接口符合zkML验证标准"。
授权记录：Agent声明自己授权了哪些其他Agent代表自己执行特定操作。例如，"Agent A授权Agent B在Uniswap上代为执行不超过1 ETH的swap操作"。

授权记录的链上化是一个重要的安全特性。在当前的Web2 Agent生态中，授权通常通过API Key或OAuth Token实现，一旦泄露，攻击者可以无限期地冒充被授权者。而链上授权记录可以设置精确的权限范围（如金额上限、时间窗口、操作类型），并且可以随时撤销——撤销操作会被记录在链上，任何验证者都可以查询到最新的授权状态。

2.4 ERC-8004与Google Agent-to-Agent协议的关系

Google在2025年发布了Agent-to-Agent（A2A）协议，定义了Agent之间发现、协商和协作的标准接口。A2A协议的设计假设是一个相对可信的运行环境——Agent之间的通信通过HTTPS进行，身份验证依赖传统的TLS证书和OAuth Token。

ERC-8004可以被视为A2A协议在开放链上环境中的扩展和补充。两者的核心区别在于信任模型：A2A假设存在一个外部的身份和信任基础设施（CA体系、企业认证），而ERC-8004的信任建立在链上——身份由NFT标识，声誉由链上行为记录，授权由智能合约执行。从可信环境到开放环境的扩展，引入了A2A协议中不存在的新挑战：Sybil攻击（低成本创建大量虚假身份操纵声誉系统）、隐私保护（链上声誉记录是否暴露过多Agent策略信息）、跨链身份互认。

三、从智能合约到Agentic Contract：链上自主代理的执行架构

3.1 确定性执行 vs 概率性推理

传统智能合约的执行是严格确定性的——相同的输入必定产生相同的输出，不论执行多少次。这是区块链共识的基础：所有节点必须对合约执行结果达成一致，而确定性保证了这种一致性。

AI Agent的决策过程则本质上是概率性的。一个基于LLM的Agent面对同样的输入，可能在不同的推理过程中选择不同的行动——这源于LLM的温度参数（temperature）、采样策略以及模型的内部随机性。当这样的Agent被赋予链上执行权时，就产生了一个根本性的张力：链上共识要求确定性，而Agent的推理本质上是概率性的。

Agentic Contract是对这一张力的架构级回应。它的核心思路是：将"决策"与"执行"分离——Agent的推理过程在链下完成（允许概率性），推理结果以可验证的方式提交至链上，链上合约验证推理的可信性后执行。

3.2 Ritual的Infernet架构：AI协处理器范式

Ritual项目提出的Infernet架构，为Agentic Contract提供了一个具体的实现方案。Infernet的核心理念是"AI协处理器"——类比于浮点协处理器（FPU）为CPU提供浮点运算加速能力，Infernet为智能合约提供AI推理加速能力。

graph LR
        subgraph 链上On-Chain
            SC[智能合约<br>业务逻辑+验证]
            VN[验证节点<br>验证推理证明]
        end
        subgraph 链下Off-Chain
            INF[Infernet节点<br>AI推理执行]
            ML[AI模型<br>LLM/RL等]
            INP[输入数据<br>链上+链下]
        end

        SC -->|请求推理| INF
        INP --> INF
        ML --> INF
        INF -->|返回结果+证明| VN
        VN -->|验证通过| SC

架构详解

这个架构图展示了Infernet的"AI协处理器"范式。逐模块拆解如下：

链上模块——智能合约：这是DApp的业务逻辑所在。当合约需要AI推理结果时（例如，一个DeFi策略合约需要AI模型判断市场走势），合约通过Infernet的链上接口发起推理请求。合约本身不执行任何AI计算——它只负责定义"我需要什么推理"和"我如何使用推理结果"。

链下模块——Infernet节点：这是AI推理的实际执行者。Infernet节点接收来自链上合约的推理请求，调用相应的AI模型执行推理，生成推理结果。关键的是，Infernet节点不仅返回推理结果，还返回一个推理证明——证明"我确实使用了声明的模型和输入数据执行了推理"。

链上模块——验证节点：验证节点检验推理证明的有效性。如果证明通过验证，智能合约接受推理结果并继续执行业务逻辑；如果验证失败，合约拒绝该结果。

链下模块——AI模型：模型可以是LLM、强化学习Agent、预测模型等。模型存储在链下，Infernet节点负责模型的加载和推理执行。

链下模块——输入数据：推理的输入可能来自链上（如价格数据、交易历史）和链下（如社交媒体情绪、新闻API）。Infernet节点需要将链下数据以可验证的方式引入推理过程——这涉及数据预言机（Oracle）的设计。

3.3 zkML验证机制

推理证明的验证是Infernet架构的安全核心。zkML（零知识机器学习）是目前最有前景的验证方案，其工作原理如下：

模型承诺：AI模型的创建者在链上发布一个模型承诺（Model Commitment）——这是模型参数的哈希或Merkle根。任何人都可以验证"推理使用的模型是否与承诺一致"。
推理执行与证明生成：Infernet节点使用声明的模型和输入数据执行推理，生成一个zk-SNARK证明，声称"我使用模型M对输入X执行了推理，得到输出Y"。
链上验证：验证节点检查zk-SNARK证明。如果证明有效，则可以确信：推理确实使用了声明的模型和输入数据，输出Y未被篡改。

zkML的安全假设是：zk-SNARK系统的可靠性保证了推理过程的不可伪造性。只要证明系统的密码学假设成立，即使Infernet节点是恶意的，也无法伪造一个能通过验证的推理证明。

但zkML当前有不可忽视的局限：

证明开销巨大：为一次LLM推理生成zk-SNARK证明的计算开销，可能比推理本身高出数百到数千倍。对于需要实时推理的Agent应用，这一开销目前不可接受。
模型规模限制：当前主流zkML系统实际能高效处理并生成证明的模型参数量，通常远低于PGV（Poseidon/Varuna等证明系统）在演示中的规模，文中所称"上限约在7B（70亿）级别"为乐观估计，需核实——实操中多数可验证推理仍集中于千万级参数量的小型模型，7B级别仅见于计算成本极高的特定演示，不足以视为当前普遍可行的水平。
浮点运算精度：zk-SNARK的算术化基于有限域，不支持原生浮点运算。AI模型中的浮点计算需要量化为定点运算，可能引入精度损失，影响推理结果的准确性。

这些局限意味着，zkML在短期内更适合验证小型模型（如预测模型、分类器）的推理结果，而非大型LLM的推理。对于大型模型，折中方案包括：验证模型的部分层（而非完整推理链）、使用TEE作为替代验证手段、或采用混合验证策略。

四、AI Agent的身份与财务基础设施：ERC-6551代币绑定账户

4.1 ERC-6551：赋予NFT完整钱包功能

ERC-6551（Token Bound Accounts，TBA）定义了一种机制，使NFT可以拥有自己的以太坊账户——这个账户被称为"代币绑定账户"。TBA的核心理念是：NFT不再只是一个静态的数字资产，而是一个拥有独立钱包功能的实体，可以持有ETH、ERC-20代币、其他NFT，甚至与其他智能合约交互。

对于AI Agent而言，TBA的价值在于：Agent的身份（ERC-8004的Identity NFT）可以绑定一个TBA，这个TBA就是Agent的"钱包"——Agent通过TBA持有资产、发起交易、积累链上历史。TBA与Identity NFT的绑定关系是链上可验证的——任何人都可以查询"某个Identity NFT对应的TBA地址是什么"，从而确认某个交易的发起者身份。

4.2 DeFi套利Agent的生命周期案例

下面通过一个具体的案例来展示AI Agent从注册到运行的完整生命周期：

stateDiagram-v2
    [*] --> 创建: 部署者创建Agent
    创建 --> 注册: 在ERC-8004注册Identity
    注册 --> 激活: 通过TBA注入启动资金
    激活 --> 交易: 开始执行DeFi策略
    交易 --> 积累: 声誉数据更新
    积累 --> 交易: 继续执行策略
    交易 --> 暂停: 策略异常/资金不足
    暂停 --> 激活: 重新注入资金/调整策略
    积累 --> 终止: 控制者决定终止
    暂停 --> 终止: 长期无活动
    终止 --> [*]

生命周期状态详解

创建阶段：Agent的部署者编写Agent的决策逻辑（如一个基于强化学习的套利策略），并部署到链下基础设施。此时Agent还只是一个程序，没有链上身份。

注册阶段：部署者在ERC-8004 Identity Registry中为Agent注册一个身份NFT。注册过程需要填写Agent描述、模型信息、控制者地址等字段。注册完成后，Agent获得了链上身份标识。

激活阶段：Agent通过TBA接收启动资金——例如1 ETH。这个TBA是绑定在Identity NFT上的，与Agent身份一一对应。资金注入后，Agent拥有了执行链上操作的经济能力。

交易阶段：Agent开始执行DeFi套利策略。它监控链上DEX的价格差异，发现套利机会后通过TBA发起交易。每笔交易的执行结果（盈利或亏损）都记录在Agent的TBA交易历史中。

积累阶段：Agent的交易行为被Reputation Registry记录。成功的套利交易提升了Agent的声誉评分；失败的交易或异常行为则降低评分。声誉数据反过来影响Agent的可信度——声誉越高的Agent，越容易被其他Agent或人类信任和合作。

暂停阶段：当Agent的策略出现异常（如连续亏损超过阈值）或TBA资金不足时，Agent自动进入暂停状态，停止执行交易。控制者可以重新注入资金或调整策略后恢复Agent。

终止阶段：控制者决定终止Agent时，Agent的Identity NFT被标记为"已终止"，TBA中的剩余资产被提取到控制者地址。Agent的声誉记录永久保留在链上，作为历史数据可查询。

4.3 Agent信用档案的链上构建

TBA的交易历史与ERC-8004 Reputation Registry的结合，使Agent可以构建链上信用档案。信用档案的核心逻辑是：

行为记录：TBA的所有链上交易都是公开可查的——交易对手、金额、时间、结果。这些数据不需要任何额外的基础设施，直接从链上获取。
声誉聚合：Reputation Registry将链上行为数据聚合为声誉评分。评分算法可以是简单的"成功率加权"，也可以是更复杂的"风险调整收益率"。
信用迁移：当Agent的身份NFT被转让时，声誉记录随Identity NFT迁移，而非随TBA迁移。这确保了信用档案的连续性——即使Agent更换了执行地址，历史声誉仍然有效。

一个值得深入讨论的问题是：链上信用档案是否可能被操纵？如果一个Agent通过大量自交易（wash trading）来虚增交易量，是否可以人为抬高声誉评分？Reputation Registry的设计需要考虑此类攻击——例如，过滤掉明显属于自交易的记录，或将交易对手的声誉权重纳入评分算法。

五、Agent支付与商务协议：x402与ACP的双轨并行

5.1 x402协议：HTTP 402 + 链上稳定币支付

x402协议的设计灵感来自HTTP状态码中的402 Payment Required——这个状态码在HTTP规范中预留了数十年，但从未被广泛使用。x402赋予了它全新的含义：当Agent请求一个API资源时，服务端返回402状态码，附带支付信息（收款地址、金额、代币类型）；Agent完成链上支付后，凭支付凭证重新请求，服务端返回资源数据。

sequenceDiagram
    participant Agent as AI Agent
    participant API as API服务端
    participant Chain as 区块链

    Agent->>API: GET /api/inference<br>（请求推理服务）
    API-->>Agent: 402 Payment Required<br>（返回支付信息：地址+金额）
    Agent->>Chain: 发送USDC至指定地址<br>（链上稳定币支付）
    Chain-->>Agent: 交易确认+TxHash
    Agent->>API: GET /api/inference<br>Header: Payment-Proof: TxHash
    API->>Chain: 验证TxHash<br>（确认支付到账）
    API-->>Agent: 200 OK + 推理结果数据

交互时序详解

这个序列图展示了x402协议的完整支付交互时序。逐步拆解：

第一步：Agent请求API服务。 AI Agent向API服务端发送标准的HTTP GET请求，请求某个推理服务（如调用一个AI模型执行预测）。

第二步：服务端返回402状态码。 API服务端检测到该请求需要付费，返回HTTP 402状态码，附带支付详情——包括收款地址（一个链上地址）、应付金额（如0.01 USDC）、代币类型和链标识符。

第三步：Agent执行链上支付。 Agent通过TBA向指定地址发送相应数量的USDC。这个支付操作是标准的链上ERC-20转账，无需任何特殊协议。

第四步：区块链确认交易。 交易被矿工/验证者打包确认后，Agent获得交易哈希（TxHash）作为支付凭证。

第五步：Agent携带支付凭证重新请求。 Agent再次向API服务端发送请求，但在HTTP Header中附加Payment-Proof字段，值为链上交易的TxHash。

第六步：服务端验证支付。 API服务端通过RPC节点查询TxHash对应的交易详情，确认收款地址、金额和代币类型匹配。验证通过后，返回推理结果数据。

第七步：返回200 OK和结果数据。 服务端确认支付到账后，返回HTTP 200状态码和请求的推理结果。

这个设计的优雅之处在于：它将链上支付嵌入标准的HTTP交互流程，Agent不需要理解复杂的链上协议，只需要处理"请求→付费→重试"的简单模式。对于API提供者而言，也不需要修改现有的HTTP基础设施——只需要在服务端添加402响应逻辑和支付验证逻辑。

5.2 Stripe ACP：传统支付巨头的代理购物接口

与x402的链上原生路线不同，Stripe的Agentic Commerce Protocol（ACP）走的是传统合规支付栈的路线。ACP定义了AI Agent代理人类消费者完成购物的标准接口——Agent可以代为浏览商品、选择、下单，但支付走Stripe的传统支付通道（信用卡、银行转账等），且需要消费者的事前授权和事后确认。

ACP的设计假设是：消费者信任Stripe作为支付中介，Agent的行为受到Stripe的合规框架约束。这与x402的"无中介、纯链上"理念形成了鲜明对比。

5.3 x402 vs ACP：互补而非竞争

将x402和ACP视为竞争关系是片面的。两者的定位实际上是互补的：

x402适合Agent-to-Agent和Agent-to-Service的微付费场景：金额小、频率高、无需人类介入。例如，Agent调用另一个Agent的推理API，支付0.001 USDC获取一次推理结果。
ACP适合Agent代人类消费的场景：金额大、频率低、需要人类授权。例如，Agent帮人类用户在电商平台购买商品，需要人类确认订单和支付。

Coinbase已在Base链上部署了x402的实际基础设施，包括支付合约和验证服务。初步数据显示，Agent通过x402完成的微付费交易量正在稳步增长，主要集中在DePIN推理服务、数据API访问和Agent间协作等场景。

六、机密计算层：TEE + ZKP + FHE的三层防护架构

AI Agent在链上运行时，经常需要处理敏感数据——用户的财务信息、医疗记录、商业策略等。这些数据如果明文存储或传输，将严重侵犯用户隐私。机密计算层的目标是：即使数据在处理过程中，也能保持加密状态，确保只有授权方可以访问明文。

COTI项目提出的三层防护模型是当前最系统的方案之一：

flowchart TD
    subgraph 用户侧
        UD[用户敏感数据]
    end
    subgraph TEE层_可信执行环境
        TEE[TEE Enclave<br>Intel SGX/ARM TrustZone]
        DEC[数据解密]
        INFER[AI推理执行]
        REC[结果重新加密]
    end
    subgraph ZKP层_零知识证明
        ZKP[ZKP证明生成<br>Bulletproofs/Plonk]
        ZV[证明验证]
    end
    subgraph FHE层_全同态加密
        FHE[FHE计算<br>TFHE/BFV]
        FHED[密文域计算<br>无需解密]
    end
    subgraph 链上
        OCH[链上验证与存储]
    end

    UD -->|加密数据| TEE
    TEE --> DEC
    DEC --> INFER
    INFER --> REC
    REC -->|加密结果| ZKP
    TEE -->|执行日志| ZKP
    ZKP --> ZV
    ZV --> OCH
    UD -->|加密数据| FHE
    FHE -->|密文结果| ZKP

三层防护详解

TEE层（可信执行环境）：这是第一层防护，也是最直接的一层。用户敏感数据被加密传输至TEE Enclave（基于Intel SGX或ARM TrustZone），在Enclave内部解密后执行AI推理。Enclave的硬件隔离机制确保操作系统和其他程序无法访问Enclave内部的明文数据。推理完成后，结果被重新加密并输出。

TEE层的优势在于性能——在Enclave内部，AI推理可以以接近原生速度执行，无需额外的密码学开销。但TEE的安全假设并不完美：侧信道攻击（如CacheQuest、Plundervolt）已被证明可以绕过SGX的隔离机制，提取Enclave内部的密钥或数据。因此，TEE层不应被视为唯一的信任根，而应与ZKP层和FHE层配合使用。

ZKP层（零知识证明）：第二层防护为TEE内执行的操作提供密码学保证。TEE在执行AI推理的同时，生成一份执行日志，ZKP Prover基于执行日志生成一个零知识证明，声称"Enclave内确实执行了声明的推理操作，使用了声明的模型和输入数据"。链上验证者检验ZKP证明后，可以确信推理过程的完整性——即使Enclave本身被攻破，ZKP证明也能暴露不一致。

ZKP层的局限性在于证明开销——为大型AI推理生成ZKP证明的计算成本极高，当前的实现只能处理中小规模模型。此外，ZKP证明只能验证"执行过程的正确性"，无法验证"Enclave是否被侧信道攻击"——这属于TEE的安全范畴。

FHE层（全同态加密）：第三层防护是最强的密码学保证。FHE允许在密文域上直接执行计算——数据始终处于加密状态，从输入到输出全流程无需解密。这意味着，即使计算节点完全恶意，也无法获取明文数据。

FHE的理论可行性早在2009年就被Gentry证明，但实际性能至今仍是瓶颈。当前的FHE方案（基于TFHE或BFV）的计算开销比明文计算高出数万到数百万倍——对于需要实时推理的AI Agent应用，这一开销在短期内不可接受。因此，FHE层在当前阶段更多用于处理小规模、高敏感度的计算（如医疗数据的简单统计），而非大规模AI推理。

6.1 医疗AI Agent的端到端机密计算流程

以COTI架构下的医疗AI Agent为例，完整的机密计算流程如下：

数据加密：患者的医疗数据在用户设备端使用FHE公钥加密，生成密文。
密文域预处理：部分预处理操作（如数据归一化）可以在FHE密文域上直接执行，无需解密。
TEE内推理：对于需要复杂AI模型的推理（FHE无法高效执行），密文被传输至TEE Enclave内部解密，执行推理，然后重新加密输出。
ZKP证明生成：TEE生成推理过程的执行日志，ZKP Prover为执行日志生成证明。
链上验证：加密的推理结果和ZKP证明被提交至链上，验证者检验证明有效性后接受结果。
结果解密：只有拥有FHE私钥的用户才能解密最终的推理结果。

这个流程的安全保证是分层的：FHE保证了数据在传输和简单计算阶段的机密性；TEE保证了复杂推理阶段的执行隔离；ZKP保证了推理过程的完整性。任何单层被攻破，都不会导致全链路的安全崩塌——攻击者需要同时突破三层防护才能获取明文数据，这显著提高了攻击成本。

6.2 硬件可信根 vs 密码学可信根

三层防护架构引发了"硬件可信根 vs 密码学可信根"的权衡讨论：

硬件可信根（TEE）：性能好，但安全假设依赖特定硬件厂商（Intel、ARM）的正确实现。硬件漏洞一旦被发现，可能影响全球所有使用该芯片的Enclave。
密码学可信根（ZKP/FHE）：安全假设基于数学难题，不依赖特定硬件。但性能开销巨大，当前无法支撑大规模实时计算。

务实的方案是混合使用：对性能要求高、敏感度相对低的计算使用TEE；对敏感度高、计算量适中的任务使用FHE；对需要强完整性保证的场景叠加ZKP。这种分层策略不是"最安全"的，但在安全性和实用性之间取得了当前技术条件下的最佳平衡。

七、多Agent协作与M2M经济的系统性挑战

当大量AI Agent在链上自主运行并相互交互时，一个机器对机器（M2M）的经济生态开始成形。但这个生态面临的挑战远不止技术层面——经济激励、博弈论、合规框架等维度的问题同样严峻。

7.1 Agent发现与协商

在开放网络中，Agent需要发现潜在的合作对象，并就合作条款进行协商。ERC-8004的Identity Registry提供了基本的发现功能——Agent可以查询注册表找到具有特定能力声明的其他Agent。但"发现"只是起点，"协商"才是关键。

协商过程涉及多个维度：服务内容、价格、服务质量保证、争议解决机制。当前缺乏标准化的Agent协商协议，每个Agent项目都在实现自己的协商逻辑，导致严重的互操作性问题。Agent发现层需要设计一套标准化的协商消息格式和协议流程——类似于HTTP协商内容类型（Content Negotiation），但面向Agent的服务条款。

7.2 多Agent系统的共识与冲突解决

当多个Agent协同完成一个复杂任务时，如何对任务的中间结果达成共识？如果Agent A的推理结果与Agent B的推理结果矛盾，如何裁定？

传统分布式系统的共识算法（如PBFT、Raft）假设节点是确定性的——相同的输入必定产生相同的输出。但AI Agent的推理是概率性的，不同Agent面对相同输入可能产生不同输出。这要求设计新的共识机制，能够处理概率性结果的一致性问题。

一个可能的方向是"多模型投票"——多个独立的Agent分别对同一问题做出判断，通过加权投票得出最终决策。权重可以基于Agent的声誉评分——声誉越高的Agent，其投票权重越大。但这引入了新的攻击面：如果攻击者通过Sybil攻击创建大量虚假高声誉Agent，可以操纵投票结果。

7.3 40% Agent交易对链上生态的影响

链上40% Agent交易占比（基于部分L2网络和测试网的观测数据，不同网络与口径下差异显著，该比例需以交易所、区块浏览器及数据服务商的具体披露口径为准，作者无法独立核实）对链上生态的影响：

Gas市场波动：Agent的交易策略通常高度时间敏感——套利机会稍纵即逝，Agent会以极高的Gas价格抢夺交易排序优先权。这可能导致Gas价格的剧烈波动，影响人类用户的交易成本。
MEV生态重构：MEV（最大可提取价值）的提取主体正在从专业的MEV搜索者转向AI Agent。Agent的推理能力使其能够发现更复杂的MEV机会，但也可能加剧MEV的负外部性——如更频繁的三明治攻击。
协议安全新挑战：Agent的行为模式可能与协议设计者的预期不同。例如，一个DeFi协议的清算机制假设清算者是人类交易者，但Agent可能在毫秒级响应清算机会，导致协议的清算激励模型失效。

应对这些影响需要协议层面的调整：设计面向自动化的低延迟排序与可预测的Gas定价机制、引入公平排序（Fair Sequencing）减少MEV攻击面、以及重新评估DeFi协议的参数设定在Agent主导环境下的有效性。（注：EIP-1559本身是基础费+优先费的动态Gas定价机制，其主要设计目标并非专为Agent优化，而是提高费用可预测性、缓解Gas价格拍卖波动，此处引用时需注意其适用边界。）

7.4 Agent行为的可审计性与合规框架

AI Agent在链上的行为是可追溯的——每一笔交易都记录在链上。但"可追溯"不等于"可审计"。审计需要理解Agent的决策逻辑——为什么Agent在特定时刻选择了特定行动？当前，大多数Agent的决策逻辑是不透明的：链上只能看到交易结果，无法得知推理过程。

ERC-8004的模型信息字段和zkML的推理证明部分解决了这一问题——它们声明了Agent使用的模型，并验证了推理过程与声明一致。但"模型与推理一致"不等于"推理结果可解释"——大型LLM的推理过程对人类来说仍是黑盒。

合规层面的挑战更为严峻。当Agent的交易涉及受监管的金融产品（如证券代币、衍生品），监管机构可能要求Agent的运营者承担合规义务（KYC/AML、投资者适当性等）。但"运营者"的身份在去中心化环境中可能难以确定——Agent的控制地址可能是一个多重签名钱包，甚至是一个DAO。

八、技术全景图与未来展望

8.1 Agent经济技术栈全景

将前文讨论的各个组件整合为一个完整的技术栈，从底层到上层依次为：

flowchart TD
    subgraph 底层_机密计算
        TEE2[TEE<br>Intel SGX/ARM TrustZone]
        ZKP2[ZKP<br>Bulletproofs/Plonk]
        FHE2[FHE<br>TFHE/BFV]
    end
    subgraph 中间层_身份与支付
        E8004[ERC-8004<br>Identity/Reputation/Trust]
        E6551[ERC-6551<br>代币绑定账户TBA]
        X402[x402协议<br>链上微付费]
        ACP2[ACP协议<br>代理商务]
    end
    subgraph 应用层_Agentic合约
        AC[Agentic Contract<br>链上自主代理]
        ZKML[zkML<br>可验证推理]
        M2M[M2M经济<br>Agent协作]
    end

    TEE2 --> E8004
    ZKP2 --> E8004
    FHE2 --> E8004
    E8004 --> AC
    E6551 --> AC
    X402 --> M2M
    ACP2 --> M2M
    ZKML --> AC
    AC --> M2M

    style TEE2 fill:#2d3436,color:#dfe6e9
    style ZKP2 fill:#2d3436,color:#dfe6e9
    style FHE2 fill:#2d3436,color:#dfe6e9
    style E8004 fill:#0c2461,color:#dfe6e9
    style E6551 fill:#0c2461,color:#dfe6e9
    style X402 fill:#0c2461,color:#dfe6e9
    style ACP2 fill:#0c2461,color:#dfe6e9
    style AC fill:#6a0572,color:#dfe6e9
    style ZKML fill:#6a0572,color:#dfe6e9
    style M2M fill:#6a0572,color:#dfe6e9

全景图解读

底层——机密计算层：TEE、ZKP、FHE三者共同构成Agent处理敏感数据的安全基础。TEE提供性能友好的执行隔离，ZKP提供执行完整性的密码学保证，FHE提供最强级别的数据机密性。三层的关系是互补而非替代——具体选择哪层取决于应用场景的安全需求与性能预算。

中间层——身份与支付层：ERC-8004解决"Agent是谁"的问题，ERC-6551解决"Agent持有和操作什么"的问题，x402和ACP解决"Agent如何支付"的问题。四个协议的协同使Agent具备了作为链上经济主体运行的基本条件——身份、资产、支付能力。

应用层——Agentic合约与M2M经济：Agentic Contract是Agent在链上执行决策的合约化表达，zkML为决策的推理过程提供可验证性，M2M经济是Agent之间协作与交易的网络效应。三层的关系是递进的：底层提供安全保障，中间层提供身份和支付基础设施，应用层构建经济生态。

8.2 当前技术不成熟环节与风险评估

对Agent经济技术栈的全面审视，需要诚实地识别不成熟环节和潜在风险：

zkML的证明开销：当前为大型模型生成ZKP证明的计算成本不可接受。短期内，可验证推理只能覆盖小型模型，大型模型的推理验证仍需依赖TEE或其他折中方案。这限制了Agentic Contract的可信范围。
FHE的性能瓶颈：全同态加密的计算开销使其在短期内无法支撑大规模AI推理。FHE更适合作为"保险层"——在少数极敏感场景下使用，而非作为通用计算基础设施。
ERC-8004的Sybil攻击风险：Identity Registry的低成本注册机制可能被滥用——攻击者可以创建大量虚假Agent身份，操纵声誉系统。需要在注册成本和参与门槛之间找到平衡。
Agent行为的外部性：40%的Agent交易占比意味着链上经济已非纯粹的人类驱动。Agent的行为外部性（Gas波动、MEV加剧、协议安全）尚未被充分评估，可能需要协议层面的系统性应对。
合规不确定性：不同司法管辖区对AI Agent的法律地位尚未明确。Agent的链上交易是否需要遵守KYC/AML？Agent的运营者是否需要持有金融服务牌照？这些问题的答案将深刻影响Agent经济的合规框架。

8.3 2026下半年至2027年的关键里程碑

基于当前各协议的进展和工程复杂度，以下是审慎的里程碑预测：

2026年Q3-Q4：ERC-8004的Reputation Registry和Trust Registry在测试网上线，积累早期数据。x402协议在Base链上的交易量持续增长，扩展至更多L2。zkML的证明性能取得数量级提升（部分得益于硬件加速），支持参数量10亿级别的模型推理验证。
2027年Q1-Q2：ERC-8004全功能在以太坊主网上线，三个注册表完整运行。多Agent协作的标准化协议（协商消息格式、争议仲裁机制）形成初版规范。TEE安全性的改进（如Intel TDX的更广泛部署）增强Agent运行环境的可信度。
2027年Q3-Q4：Agentic Contract的首次主网部署——DApp开始使用Infernet等架构将AI推理集成到链上合约中。M2M经济的交易量在特定垂直领域（DePIN推理服务、数据市场）达到显著规模。合规框架的初步成型——至少一个主要司法管辖区发布AI Agent链上交易的监管指引。

这些预测的置信度有限——Agent经济的技术栈横跨密码学、分布式系统、AI和经济学，任何一个领域的突破或挫折都可能改变时间线。但方向是清晰的：Agent经济的基础设施正在从"各自为战"走向"标准化集成"，ERC-8004是这一整合趋势的标志性事件。

九、结语

ERC-8004的部署标志着AI Agent在链上的存在从"事实上的参与"走向"规范化的基础设施"。但这只是起点——身份注册解决了"是谁"的问题，却没有解决"可信不可信"和"安全不安全"的问题。可信需要可验证推理（zkML）的支撑，安全需要机密计算（TEE/ZKP/FHE）的保障，经济可行性需要标准化支付（x402/ACP）的通道。

整个Agent经济技术栈的成熟度参差不齐：ERC-6551和x402已经进入实用阶段，ERC-8004的核心功能刚上线主网，zkML和FHE仍处于实验期。这种不均衡是正常的——任何复杂技术生态的发展都是渐进的，不可能所有组件同时就绪。关键在于各组件之间的接口标准化已经起步，使得后续的迭代升级可以在不破坏现有集成的前提下进行。

对开发者而言，当下最务实的行动是：基于ERC-8004和ERC-6551构建Agent的身份和资产层，使用x402处理Agent间的微付费，同时跟踪zkML和FHE的进展，为未来的可验证推理和机密计算预留接口。Agent经济的红利属于那些在基础设施尚未完美时就敢于构建应用的人——但前提是，你必须清楚地知道哪些组件已经可用，哪些还在路上。

本文基于ERC-8004规范文档、ERC-6551提案、x402协议GitHub仓库、Ritual Infernet技术白皮书、COTI机密计算文档以及以太坊主网链上数据撰写。文中技术判断为作者独立分析，不构成任何投资建议。提及的任何协议或项目不构成推荐。