ERC-8004：给 Agent 付款之前，怎样看身份与信誉证据

一个市场里有两个 Agent，都声称能完成同一份分析。客户付费前，需要知道条目究竟指向哪个服务、评分来自哪些人，以及所谓“验证通过”到底验证了什么。熟悉的名字和一个很高的分数，还回答不了这些问题。

ERC-8004 为其中一部分信息提供共同记录方式，最终如何选择，仍由应用决定。

资料边界： 本文于 2026 年 11 月 1 日核对官方规范和项目维护文档。ERC-8004 仍为 Draft。我们没有验证某个线上 Agent 的表现，也没有进行链上部署检查或提交反馈。

三类记录，三种含义

ERC-8004 草案 分开处理链上身份、反馈信号和验证者记录。身份由注册表引用与 Agent ID 共同确定，并指向注册文档；声誉部分提供反馈接口；验证部分记录独立验证者的检查。支付明确不属于协议范围。

概念示意，不是某个 Agent 的评分或实测。每条证据路径都可能独立出现缺失或失败。

产品的数据结构和界面也应保留这些差异。“已注册”“有人评价”“某项已验证”，不适合合并成一个含义不明的绿色认证标记。

身份要一直核对到服务端点

项目团队的合约仓库 解释了复合身份标识和可选的收款钱包验证，并说明身份转移时会清除相应的钱包关联。这关系到市场的缓存策略：曾经看到的收款地址，不能永久当作 Agent 的固有属性。

我们的建议是，分别保存注册表与 Agent ID、检查过的端点、观察时间，以及收款钱包的证明。服务地址或所有权发生变化后，只能重新审查受影响的信息，不能把旧配置的“已验证”状态直接继承过去。

注册本身也不应被解释为真实公司的身份认证。市场需要根据业务另外决定是否核查经营主体、联系渠道和争议处理责任人。

数字之前，先问测量了什么

项目的声誉指南 把 ERC-8004 定位为公共反馈层，筛选、加权和展示算法由具体应用负责。标签和数值精度有助于描述信号，但没有强制统一的质量标准。

假设一条反馈测的是交付延迟，另一条评的是报告是否有用，把两者直接平均不会得到有意义的分数。即便都叫质量分，也可能使用不同量表，面对不同难度的任务。

一份有用的展示至少要回答：

• 测量的是哪项属性，单位是什么，对应什么任务？
• 纳入了哪些评价者，为什么信任或参考他们？
• 证据有多新，样本有多少？
• 是否排除了被撤回的反馈，缺失上下文怎么处理？

这些是我们的产品设计建议，并非标准额外提供的保证。草案承认女巫攻击风险；公开记录很多，本身不足以证明服务可靠。

“验证通过”必须有范围

复现结果、核对执行证明、判断一份文档是否有用，是不同的验证任务。产品应先说明方法和范围，再让用户判断这项结果与当前需求的关系，不能从一次检查推导出全面可靠。

团队仓库还提醒，验证部分仍在持续调整。接入时应锁定规范与实现版本，避免把所有草案能力写成各网络都已经一致部署。

初期市场宁可只支持少量定义清楚的证据类型，并明确显示“暂无证据”，也不宜为了一个漂亮的总分，把来源和含义不同的指标混在一起。

选择服务与批准付款，分别判断

应用可以参考身份和声誉选择交易对手，再用独立的报价、预算和支付策略决定是否付款。两次判断应能相互关联，但不能互相替代。历史评价不错，不代表今天的金额已经获批；付款成功，也不代表今天的结果符合要求。

官方资料入口见 ERC-8004 目录条目。任务通信可继续阅读 A2A，工具接入可看 MCP。这些是相邻能力，市场自己的验收与争议流程仍需单独设计。