面对一个陌生的AI代理，你很难仅凭它自己说的话判断它是否可靠。ERC-8004 试图解决的就是这个问题：让代理的身份和过往表现记录在链上，任何人可以独立核对，而不必信任某个中心化平台的一面之词。
但"标准存在"和"你能据此做出可靠判断"之间，还有一段距离。这篇文章讲清楚两件事：ERC-8004 到底把什么写到了链上，以及作为使用者，你怎么用这些信息来核对一个代理。
ERC-8004 把代理的什么放到了链上
ERC-8004 的核心是三个链上注册表。理解它们各自负责什么，是后续所有核对操作的前提。
身份注册表（Identity Registry） 负责回答"这个代理是谁"。每个注册的代理会获得一个链上身份，以 ERC-721 代币的形式存在。这个代币有一个 agentId，并且其 tokenURI 指向一份链下文件，通常叫注册文件或 Agent Card，里面写着代理的名称、描述、服务端点、支持的通信协议以及它的收款钱包地址。这份链下文件才是代理"自我介绍"的地方，链上记录本身只是一个指针。
信誉注册表（Reputation Registry） 记录客户对代理的反馈。任何地址都可以对某个 agentId 提交一条反馈，包含一个数值评分、小数位数、最多两个标签，以及一个可选的链下详细说明文件链接。标准刻意没有定义"总分"是什么——它只存原始信号，把如何解读留给读取的人。
验证注册表（Validation Registry） 用于更高确信度的场景：让独立的验证者检查某个代理的特定工作结果，并把结论记录在链上。验证方式可以是质押后重新执行任务、可信执行环境证明，或者零知识机器学习证明。但需要注意：截至目前的官方多链部署中，验证注册表并未包含在主网正式合约集合里。它在与 TEE 社区重新设计的过程中被暂时撤回，需要验证的团队目前通过特定供应商（如 EigenCloud）自行搭建。这意味着在实际核对时，你大概率暂时接触不到一个标准化的链上验证注册表。
核对一个代理的身份，从 agentId 开始
如果你知道一个代理的链上地址或 agentId，核对身份最直接的方式是直接读取身份注册表的合约。
在以太坊主网上，身份注册表的合约地址是 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432。Polygon 主网上也有部署，地址相同。你可以在区块浏览器（如 Etherscan）的"Read Contract"页面调用几个关键函数：
ownerOf(agentId)：这个 agentId 对应的 NFT 当前属于哪个地址。这是代理的控制权归属。tokenURI(agentId)：代理的链下注册文件在哪里。可能是一个 HTTPS 链接、一个 IPFS 地址，或者直接内嵌在链上的 data URI。getAgentWallet(agentId)：代理绑定的收款钱包地址。如果你准备向这个代理付款，这个地址是你实际要转钱过去的地方，值得和注册文件里声称的地址交叉核对。
一个重要的判断依据是：agentId 本身只是一串编号，注册文件的内容才是代理的"简历"。链上记录只能证明"这个 agentId 属于这个地址"和"这份文件被这个 agentId 引用"。它不能自动证明文件里写的每一句话都是真的。注册文件里声称的服务端点是否真的在线、收款地址是否真的由代理控制，都需要额外验证。
信誉数据怎么读，以及为什么不能只看一个数
信誉注册表里的反馈是任何人可以提交的。这意味着反馈的数量和分布本身，比一个单一的分数更值得关注。
标准提供了 getSummary 函数，可以传入 agentId、一组客户地址、以及标签来筛选反馈，返回反馈条数、汇总值和小数位数。一个负责任的读取方式不是直接看"总分"，而是先看这些反馈来自谁、有多少个不同的地址、是否绑定了支付证明。
一份学术研究对 ERC-8004 早期数据的分析给出了一个很有参考价值的警告：在对以太坊、BSC 和 Base 链上信誉数据的系统检查中，研究者发现大量反馈来自被标记为 Sybil 的地址。在 BSC 上，这类地址占到了反馈提交者的 73.6%；在 Base 上占 59.2%。如果剔除这些反馈，超过一半有信誉记录的代理在相应链上就没有任何有效反馈剩余。
这意味着"这个代理有信誉记录"本身几乎不构成信任理由。你需要看的不是有没有记录，而是记录是否来自多个独立、可追溯的交互方。
注册文件里有一个值得留意的字段：proofOfPayment。如果一条反馈附带了这笔交互的支付交易哈希，那么这条反馈至少和一笔真实发生过的转账绑定了，比一个匿名钱包的裸评分可信得多。
一次完整的核对流程
假设你现在面对一个代理，准备判断是否值得和它交互。可以按这个顺序来。
第一步：确认它真的注册过。 用 agentId 或地址查身份注册表，确认 ownerOf 返回一个有效地址。如果它没有注册，就没有链上身份可供核对。
第二步：找到并读取注册文件。 通过 tokenURI 拿到文件地址，打开看几个关键内容：代理声称做什么、支持哪些通信端点、收款地址是什么、声明支持哪种信任模型（supportedTrust 字段）。一个声称只支持 reputation 的代理，意味着它的可信度完全建立在客户反馈上；如果它要做的是涉及资金的操作，这个信任等级可能不够。
第三步：拉取信誉数据，按来源和标签拆开看。 不要只看一个汇总数字。查 getSummary 时，先不传客户地址筛选，看看总条数和不同提交者的数量。然后用标签筛选，比如只看 tag1="successRate" 的记录，避免把"质量评分"和"响应时间"混在一起平均出一个没有意义的数字。如果某条反馈附带了 proofOfPayment，优先参考这类有支付凭证的反馈。
第四步：确认你准备打款的地址。 用 getAgentWallet 读到的地址，和注册文件里写的收款地址对比。如果你在某个界面上看到了一个代理，界面显示了一个收款地址，把这个地址回到链上查它是否确实是该 agentId 绑定的钱包。向一个未经核对的钱包地址转账是不可逆的，ERC-8004 本身不提供任何找回机制。
第五步（可选，视情况）：确认链下文件是否可验证。 如果注册文件放在 IPFS 上且使用了内容寻址（CIDv1），读取工具可以验证返回的字节是否与 CID 的哈希匹配，防止网关篡改内容。如果文件在普通 HTTPS 域名上，只能确认它可访问，无法确认内容未被替换。
限制和常见误判
注册数量不等于活跃代理数量。 一项对早期数据的实证研究发现，大量注册是批量铸造的占位符或模板化部署。在以太坊上，约 53% 的注册没有可用的 tokenURI；在 BSC 上这一比例是 9%。真正暴露了至少一个有效服务端点的代理，在各链上只占注册总数的 3% 到 15%。看到一个 agentId 存在，只能说明有人在链上铸造了它，不能说明背后有一个在运行的代理。
信誉可以被低成本操纵。 研究估算，在 Base 链上制造一条反馈的中位成本约为 0.0042 美元，在 BSC 上约 0.0027 美元。这意味着刷反馈的经济门槛极低。这也是为什么来源分布比分数本身更重要的原因。
验证注册表目前不可依赖。 如前所述，官方部署中验证注册表不在主网合约集合内。如果你的核对流程依赖于"这个代理被独立验证者检查过"，需要先确认你查询的链上是否有可用的验证注册表，或者该代理是否通过其他渠道（如特定供应商）提供了验证记录。
ERC-8004 不处理支付纠纷。 标准本身不涉及资金托管、退款或争议解决。反馈只是一种事后信号，如果你因为一个代理的低信誉记录而决定不交互，这是它的价值；如果你已经转了钱，而对方没有履约，链上信誉记录不会帮你把钱拿回来。
核对一个 AI 代理的信誉，核心不是找到一个"可信分数"，而是确认身份链上锚定、拆开看反馈来源、验证收款地址一致、理解当前验证手段的局限。ERC-8004 提供了比"相信对方官网"更可审计的起点，但它把解读和判断的责任留给了读取数据的人。
