本文从技术角度深入浅出地介绍了 ERC-8004 标准的背景、目的及其三大核心部分，并讨论 ERC-8004 的应用前景及其对 Web3 和 AI 的潜在影响。

撰文：Jason404，VP of Engineering at Codatta

TL;DR

• ERC-8004 虽然名称叫做 Trustless Agents，但是它本身既不是大模型，也不是 AI Agent，不要指望它能像 ChatGPT 一样陪你聊天，或者 Cursor 一样帮你编程；
• 如果一定要类比的话，它更类似于 Claude 提出的 MCP（Model Context Protocol），或者 Google 提出的 A2A 协议；
• 它是一张关于 AI Agent 的简历模版，告诉大家，我是谁，我能做什么，我做的怎么样，我的联系方式是什么；
• 区块链就像是一个招聘网站，大家填好的简历都挂在上面，供需双方自由浏览和选择；
• 至于这些简历信息是否完全真实可靠，没有任何人能够斩钉截铁地保证，协议本身对此也无能为力；
• 和几乎所有的 ERC 一样，它更直接面向的对象是开发者，而不是普通用户，对于普通用户而言，把它理解以太坊版本的 MCP 就好了；
• 考虑到大部分普通用户其实也不一定真正了解 MCP，所以，重点不在于 MCP，而在于以太坊版本这几个字；
• 划重点，以太坊版本；
• 什么叫以太坊版本，不是说简简单单运行在以太坊上就行了，要知道，这是一个以太坊基金会亲自下场，Metamask 和 Coinbase 这样的以太坊元老生态伙伴共同参与制定的一个标准；
• 单独一个拧出来就足以独当一面了，何况强强联合，作为提过 EIP 提案的草根，这种豪华待遇，实在让我们羡慕嫉妒恨；
• 不要以为官方下场只是个噱头，这当然不代表一定能成功，然而，每个组织背后都有庞大的用户基数支撑，这才是最大的意义；
• 要知道，一个协议标准的价值，关键不在于技术多么先进，架构多么复杂，而在于它能否被广泛接受与采用。使用者越多，生态越繁荣，协议才越有意义；
• 在 Web2，这叫做流量为王，在 Web3，这叫做共识，如果你经历过互联网平台的无孔不入，又或者 Web3 的 meme 狂潮，那么，相信你应该不会陌生；
• 总之，ERC-8004，是个很好的开始，如果你是一名 Builder，无论你的主要关注点在 AI 还是 Web3，都不妨关注一下。

什么是 ERC？

要弄明白什么是 ERC，首先要搞清楚什么是 EIP。

EIP，全称 Ethereum Improvement Proposal，中文名以太坊改进提案。

简单来说，就是大家如果觉得以太坊有什么做的不好的地方，或者做的不对的地方呢，又或者可以做得更好的地方，就可以发起一个提案，提案中呢，可以提出问题，但是，最关键的是，还要提出解决问题的方案，不建议纯 BB。

当然了，方案能不能通过，多长时间能通过，就是另外一回事了，重要的是，提出方案是自由的。

比如著名的 ERC-20、ERC-721、EIP-1559，都是以太坊改进提案，并且都是最终通过了，并正式执行了的。

等等，为什么上面一会叫 ERC，一会叫 EIP，确定不是笔误？

这还真不是，ERC 其实是 EIP 中的一个子类。

由于以太坊可以改进和提升的地方太多了 — — 别激动，我毫无贬义的意思，任何方案都是在不断升级进步中，而由于以太坊是推出最早，用户最多，生态最丰富的智能合约公链，其受到的关注也是最多的，当然关于它改进和提升的意见和建议也是最多的 — — 几乎涉及到各个方面，所以呢，为了方便管理，EIP 提案一般被分为以下几个类型：Core, Networking, Interface, ERC, Meta, Informational。

这些你在以太坊官网上都能查到，如果感兴趣的话，可以自行去查阅。

而其中应用类的提案，一般都被归做为 ERC，全称 “Ethereum Request for Comment”，这点忍不住吐槽，这名字也不知道最初是怎么起的，毫无辨识度的样子，完全看不出来到底是做啥的。

算了，反正木已成舟，不要在意这些细节。

什么叫应用类的提案呢，通俗一点来讲的话，就是首先它是个技术提案，多少涉及到代码的那种，但是呢这些代码不涉及到以太坊底层范式的改动，而是关乎具体怎么利用以太坊的现有基础设施和架构，来支撑应用实施的。

插一句，为什么要强调它至少得是个技术提案，涉及到代码的呢，因为一些治理性的，文字性的提案也是通过 EIP 流程来进行的，通常放在 Meta,、Informational 中。

如果说 Core, Networking, Interface 等对应的是以太坊的基本规则，是以太坊的宪法的话，那么 ERC 相关的，则是应用的规则，是以太坊上各个公司的公司管理制度。

你觉得这家公司的管理制度好，你可以模仿，可以山寨，如果你觉得这家公司的管理制度不好，你也可以不理会，甚至自创一套。

但是无论你觉得以太坊的宪法有什么让你不爽的地方，你都只能接受，除非你不在这里混了。

更直接的体感就是，这个 EIP 的执行与否，会不会带来以太坊的硬分叉。

比如 ERC-20 和 ERC-721，就是 Token 的协议标准，都是应用项目方在使用，随便你怎么折腾，不会影响到以太坊网络本身，有没有这两个协议，以太坊还是那个以太坊。

而 EIP-1559，则涉及到以太坊 Gas 费的计费和收费机制，会影响到底层的网络，以太坊的矿工和以太坊的开发者，以及用户都会受到影响，执行这个标准和不执行这个标准，就完全是两条链了。

总的来说，正是 ERC 提案由于很多都是应用层的标准，不会影响到以太坊网络本身，所以提案的通过与否和提案本身能不能使用没有必然的联系。

当年 ERC-721 提案，就是先实际用起来很久了，后面才慢慢形成的正式标准。

而比如 Core 类或者 Networking 类的提案，涉及到底层网络的变化，只有正式通过以后，才有可能真正的实施。

ERC-8004 概况

这么一看，就容易明白了，ERC-8004，就是这个样一个关于应用的 EIP 提案，并且，这个提案，现在大家就已经可以免费使用了，尽管还没有最终通过。

一般来说，一个 EIP 提案会有 4 个阶段，Draft, Review, Last Call, Final。

Draft 是提案阶段，这个阶段原则上没啥限制，基本上属于你想提啥提啥，毕竟你提是你的事情，大家认不认，又是另外的事情。

而进入 Review 阶段，才算是真正进入状态，社区会开始正式审查和讨论。

经过 Review 阶段的反复拉扯，如果暂时没有什么更多的问题，那么提案者可以发起 Last Call，进行最后的审议。

如果审议通过，会进入 Final 阶段，代表已经被接受为正式标准，或者可以实施了。

当然了，不是所有的提案都能完整体验到这个流程，除了 Draft 是几乎完全开放的 — — 前提是你的提案至少要看起来合理，像个提案 — — 其它的各个阶段都有可能把你刷掉。

好了，了解了这么多背景之后，我们可以正式请出今天的主角了，让我们为 ERC-8004 做一个正式的介绍。

先放上官方的原文：

我帮忙翻译一下：

ERC-8004 是一份由以太坊基金会，Coinbase，和 Metamask 等联合提出的，关于 Agent 的简历模版，帮助 Agent 更好的介绍自己是谁，能干什么，怎么干，干完了怎么验收，以及怎么联系。

如果大家都按照这个模版来写简历的话，那么就比较统一，能够降低沟通成本，拒绝无良中间商赚差价，便于用户选购，能够有效地提振 Agent 的消费市场。

因此呢，这是个对买卖双方都有利，双赢的东西，另外，表面上是给 Agent 用的简历模版，其实你不是 Agent，比如你是个真人，或者如计算器这样的 Tool，也能拿去用。

截止 2025 年 11 月 6 日，ERC-8004 处于 Review 阶段，这也意味着，今天说描述的关于 ERC-8004 的一切，仅仅代表当下的结论，在未来都有可能发生变动，所以，且看且珍惜。

ERC-8004 架构

正如前面所提到的，ERC-8004 本质上就是一份简历模版，告诉大家我是谁，我能做什么，怎么能够联系到我。

在 ERC-8004 这份简历模版中，主要包含了 3 个版块，官方分别称之为 Identity Registry, Reputation Registry, 以及 Validation Registry。

找过工作的大家一定都清楚，简历里面最基本的信息肯定都是要有的，比如你叫什么名字，专业是什么，有哪些技能点，最后至少还得留个邮箱和电话号码，要不万一被人看上了却联系不到你，就很尴尬了，这就是 Identity Registry。

当然了，公司也不都是傻白甜，有时候不是你说什么就是什么，有的会看看你有没有大佬的推荐信，有的会做一下背调，找你之前的单位了解一下你过去的工作情况，听听前夫哥对你的评价，也就是 Reputation Registry。

就算你能够在面试中过五关斩六将，顺利拿到 offer，别着急，没准还有试用期等着你呢。试用期内，公司会给你分配一些实际的任务，并且根据你任务的完成情况来最终决定你的去留。

那么，问题来了，分配什么任务，谁来具体验收你的任务，验收标准是怎么样的呢，这就是 Validation Registry。

总的来说呢，作为一个打工人，哦，不，打工 Agent，当你准备你的简历的时候，你要记住：

• 基本信息是一定要有的，也就是 Identity Registry 一定要填写，不过只是基本信息的话，在万千简历中往往会显得那么平凡，所以呢，还需要一些额外的技巧来引起关注；
• 比如，尽量找一些大佬帮忙写几封推荐信（是的，你没看错，Agent 的世界一样要拼爹），和前夫哥就算分手了，最好也是好聚好散，免得背调的时候被背刺。让你的 Reputation Registry 尽量干净漂亮一点；
• 如果你没钱没背景的话，那么，尽量放低姿态，争取试用的机会，在试用期内呢，用你的能力打动领导，让你的试用期报告，也就是 Validation Registry 更出色。

是不是非常熟悉，非常合理，天命打工 Agent 的成长必经之路。

如果你是一名喜欢跟踪热点的吃瓜群众，只是想简单了解写 ERC-8004 到底是做啥的，那么，看到这里也就差不多了，拿去吹牛装逼已经足够了，后面的部分，会讲到一些技术细节，看多了容易秃头，得不偿失。

如果你是一名初入圈的开发者，想了解更多的技术细节，或者一位尊贵的老板，以后有想法雇佣这些 Agent 给你打工的话，可以接着往下，了解一点点细节。

如果你是一名高级开发者，打扰了，耽误你时间了，你根本不应该出现在这里，你应该直接去阅读官方文档。

好了，言归正传，接下来，我们一一来拆解这三大版块。

Identity Registry

作为最时髦的 AI Agent 的基础简历，如果从形式上来看，Identity Registry 稍微显得有点不那么时髦了。

Identity Registry 本质上其实是一个以 ERC-721 标准为基础的应用实例，没错，ERC-721，也就是我们耳熟能详的 NFT。

这么算起来，加密朋克（CryptoPunks)，无聊猿 (BAYC)，阿蟹 (Axie Infinity)，胖企鹅 (Pudgy Penguins) 都算是它同父异母的兄弟了。

既然是以 ERC-721 为基础，那么在形式上跟 ERC-721 基本上是一致的，在智能合约中，它主要记录了三个信息：owner, tokenid 和 URI。

如果你是第一次看到，大概率会懵逼，这完全看不出来是啥东西啊。

owner 好理解，所有者嘛，谁拥有这个 Agent，tokenid 我也勉强猜得到，大概率是这个 Agent 的唯一编号，就像唐伯虎的编号是 9527 一样，这个 URI 又是个什么鬼，另外，我也完全看不出这是个啥 Agent 啊。

别急，其实奥秘就在这个 URI 之中。

URI，全称 Uniform Resource Identifier，好吧，不要在意这些细节，简单来说，你可以把它理解为一个超链接就行了，它指向了一个文件的存储地址，这个文件中，才真正记录了关于这个 ERC-721 的详细信息。

文件的格式大概就是下面这个样子：

{  "type": "<https://eips.ethereum.org/EIPS/eip-8004#registration-v1>",  "name": "myAgentName",  "description": "A natural language description of the Agent, which MAY include what it does, how it works, pricing, and interaction methods",  "image": "<https://example.com/agentimage.png>",  "endpoints": [    {      "name": "A2A",      "endpoint": "<https://agent.example/.well-known/agent-card.json>",      "version": "0.3.0"    },    {      "name": "MCP",      "endpoint": "<https://mcp.agent.eth/>",      "capabilities": {}, *// OPTIONAL, as per MCP spec*      "version": "2025-06-18"    },    {      "name": "OASF",      "endpoint": "ipfs://{cid}",      "version": "0.7" *// <https://github.com/agntcy/oasf/tree/v0.7.0*>    },    {      "name": "ENS",      "endpoint": "vitalik.eth",      "version": "v1"    },    {      "name": "DID",      "endpoint": "did:method:foobar",      "version": "v1"    },    {      "name": "agentWallet",      "endpoint": "eip155:1:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb7"    }  ],  "registrations": [    {      "agentId": 22,      "agentRegistry": "eip155:1:{identityRegistry}"    }  ],  "supportedTrust": [    "reputation",    "crypto-economic",    "tee-attestation"  ]}

我们看到，主要的字段有 7 个：type, name, description, image 以及 endpoints , registrations , 和 supportedTrust 。

其中 type, name, description, image 是 ERC-721 的标准字段，既然 ERC-8004 是以 ERC-721 为基础，文件中这几个字段是理所当然存在的。

含义也比较好理解，type 通常指遵循的协议标准，在这里肯定都是 ERC-8004 了；name 是 Agent 的名称，description 是关于这个 Agent 的描述，image 一般是用作这个 Agent 的 logo。

当然了，至于怎么起名字，怎么描述，用什么做 logo，这个就是 owner 自己发挥的空间了。

如果只是发个 PFP 的 NFT，或者搞个 Meme，那么这几个字段就足够了，不过，要用于 AI Agent，当然还是不够的了。

于是终于轮到 endpoints , registrations , 和 supportedTrust 登场了，这是相比常规的 ERC-721 的 URI 文件新增的，专门针对 Agent 设计的信息版块。

endpoints 是关于 Agent 能力的描述，具体怎么描述，ERC-8004 中没有再做进一步的规范了，这也想得开，毕竟 AI 发展这么快，AI Agent 的能力也千奇百怪，使用方式更是大不相同，很难自上而下的用一套统一的标准去约束。

在我看来，这确实也不能算偷懒，这玩意也应该是自下而上生长出来的，在其它字段都差不多的情况下，谁的自定义字段写得简单，清晰，易于理解和使用，谁就更容易被采纳和模仿，模仿的人多了，也就逐渐成为一种新的标准了。在生态发展前期强行去约束和限制，也确实不是什么好事。

上面的实例代码中给出了一些关于 endpoints 的写法，不过仅仅也只是参考，大家真正使用中，还是根据自己的实际情况来编写。

registrations 是 Agent 的身份信息，你可以理解为全网唯一的身份证编号，它其实不是一个可定义的值，事实上，一个 Agent 在完成 ERC-8004 实例的初始化的时候，它的身份证编号就已经确定了，这个身份证号由以下 4 个信息共同编码而来，我附上原文：

• namespace: eip155 for EVM chains
• chainId: The blockchain network identifier
• identityRegistry: The address where the ERC-721 registry contract is deployed
• agentId: The ERC-721 tokenId assigned incrementally by the registry

我举例说明一下，namespace 一定填写的是 eip155 ，代表这个 ERC-8004 的合约是部署在 EVM 链上的，什么，你问我如果不是 EVM 链怎么办？拜托，都不是 EVM 链了，哪来的 ERC-8004 标准，都叫 ERC 了，那肯定是 EVM 链来使用的啊。

chainId 是链的编号，当你的 ERC-8004 部署在某条链的时候，chainId 就确定了，比如以太坊的 chainId 就是 1，BSC 的 chainId 是 56。

identityRegistry 是你部署的 ERC-8004 实例的合约地址，这个随着合约的部署完成，也是确定的，不会更改的。

agentId 就是前面提到的 tokenId，换了个马甲，不过实际都是一个。

所以，你看是吧，一个 Agent，完成链上 ERC-8004 的实例化的时候，身份证编号就已经确定了。

因此，文件中记录的 registrations 需要和提供这个文件的 Agent 的身份证编号完全对应，否则，这 Agent 可以被判定为存在问题的。

supportedTrust 其实会和后面的 Reputation Registry 以及 Validation Registry 相关联了，也就之前提到过的，Agent 在这里告诉大家：可以用什么方式来增加前面提供的简历信息的真实性和可靠性。

当然了，如果作为一个素人 Agent，既没有推荐信也不想有什么实习期的话，这个字段也可以没有，只是至于这种情况下，会不会有人雇佣你，就只能听天由命了，一切交割市场这只看不见的手。

毕竟，就是咱普通人网购，如果一件商品或者一家店铺，既没有历史用户的评价可以参考，也不支持 7 天无理由退货，那就算详情页吹得再天花乱坠，你怕是也不会轻易下手吧。

关于这块，我们后面讲 Reputation Registry 和 Validation Registry 再具体展开，大家等我的 callback。

虽然我们一再说这些基本信息就够了，不过考虑到技术发展的日新月异，鬼知道那天会不会又有什么新的特征需要进行描述，另外呢，不同的 Agent 可能各自也有些自己的独特爱好需要额外展示，所以呢，Identity Registry 也贴心地为大家保留了一个组额外的可选字段，叫做 metadata，这个是标准 ERC-721 协议中没有的。

这组字段，是一组以 Key-Value 形式存储在链上的字段，不过它并非强制的，大家具体用不用，怎么用，协议并没有给出限制，属于让大家自由发挥的花式字段。

虽然现在看起来是没啥用的赋闲字段，不过我其实倒是蛮期待的，毕竟，社区的智慧是伟大的，当年 BTC 的铭文不也就是把一个原本平平无奇的 OP_RETURN 玩出花来了。

Reputation Registry

你完全可以把 Reputation Registry 想象为一个商品的评论区，对，就是下面这样。

一个的打分，配上一堆文字描述，如果再丰富一点话，可以加上图片或者视频，是不是非常的熟悉。

看出来了吧，Agent 的世界和剁手党的世界其实没有什么不同。

在 Reputation Registry 的合约中，有一系列的方法和字段，构成了整个评价体系的闭环，我们重点关注其中关键的几个。

首先是一个方法：

**function** giveFeedback(uint256 agentId, uint8 score, bytes32 tag1, bytes32 tag2, string calldata fileuri, bytes32 calldata filehash, bytes memory feedbackAuth) external

看名字不难猜到，这就是要给 Agent 进行评价来。

里面几个重要参数我们来拆解一下。

agentId 代表了你要评论的 Agent，这个可千万别搞错了，前面提到过了，实际上要指代一个 Agent，除了 agentId 外，还需要 namespace, chainId, identityRegistry 这些字段，怎么这都看不到了。

好问题，说明你是仔细思考了的，事实上，当你调用 giveFeedback 这个合约函数的时候，你在哪条链 (namespace + chainId)，对应的合约地址是什么 (identityRegistry) 就已经都是明确的了，所以只需要传递 agentId 就足够精准定位到指定的 Agent 了。

score 简直是直白得不要再直白了，就是用户给出的评分，和电商平台最大的区别就在于它不是 5 星制，而是百分制，最低 0 分，最高 100 分。

tag1 和 tag2 不用管了，看起来像是某些奇奇怪怪的标签，我理解可能类似于一些关键词标签，作为总结或者标识吧。

fileuri 和 Identity Registry 中的 URI 作用一样，都是指向一个文件的存储地址，这个文件包含了这条评价的具体内容，刚才也说过，不乏会有热心网友带来图文并茂地丰富评价，这些信息放在链上不太现实，尤其是以太坊这样贵的链上，所以呢，还是存在链下的文件中，随时可以通过 fileuri 去找到访问。

那么问题来了，文件放在链下，那不是意味着评论者随时可以自行修改了，那这个问题就大了，所以呢，filehash 这个字段的作用就在此，给出评价时，fileuri 指向的文件的哈希值也会被一并计算，并放到链上，起到类似于指纹的作用，这样，如果未来文件发生任何改动，哪怕是一个标点符号，新文件的哈希值也会和链上的 filehash 不一致，也就是指纹比对失败，以此告诫大家，链下也并非法外之地，不要动歪念头去擅自篡改证据。

这样看起来是不是很完美了，不过相信聪明的你应该又考虑到一个问题，这是谁都可以评价吗？作为竞争对手我岂不是可以恶意刷差评？

好吧，于是 feedbackAuth 字段又登场了，这个参数的意义，简单来说就是，不是你想评价就能评价，你要评价我，你得经过我同意。

这个授权，本质上是通过 Agent 所有者的签名来进行的，签名完的授权证书就是这个 feedbackAuth，整个签名和验签的机制还是比较简单的，本质上，感兴趣的同学可以直接去看看原文。

可能你又要问了，这看起来是杜绝了恶意差评，可是如果是真实的差评，不也可以屏蔽了吗？我知道你对我有意见，那我就不让你评。

这确实是可能存在的问题，不过，如果你仔细看了 feedbackAuth 后，你会发现，在授权的时候，评论者并不需要提供具体的评论信息，也就是说，作为一个 Agent，当你授权用户给你评论的时候，你并不知道他要给你评论的是什么，就算他花言巧语打动了你，让你给了他授权，他实际评论的时候，你也无法控制他具体怎么评论，某种程度上，这算是杜绝了删差评的行为。

倒是自己刷好评的现象，我思来想去，确实是没有什么有效地来解决的，这个只能依赖于大家具体对每个评论的分析和甄别了。没法，毕竟，现实生活中也是这样的。

搞清楚了 giveFeedback 方法和相关的参数，基本上 Reputation Registry 的机制和运作方式基本上你也该了解得差不多了，当然了，还有一些其它方法，比如 revokeFeedback ( 撤销评论 ), readFeedback ( 读取评论 ) 等等，都是围绕上述的核心机制来开展，方便大家使用 Reputation Registry 的，这里就不一一列举了，感兴趣的还是直接读原文吧。

最后，这里要 Callback 一下了，前面提到过的 supportedTrust ，如果你对自己有信心，敢于积极地授权大家来评论，那么，你就可以在你的 supportedTrust 里面填上“reputation”这个值：

“supportedTrust”: [ “reputation”, ]

Validation Registry

Validation Registry 是关于工作成果验收的约定，约定 Agent 的工作交付成果是什么，谁来验收成果，验收的方法是什么，验收通过的标准又是什么。

Validation Registry 的核心思想就是能动手就别 BB，吹得天花乱坠也没用，是骡子是马拉出来溜一下就知道了。

我，用户兼面试官，你，Agent，我给你一项工作，你按要求做完，为了避免我只手遮天，或者你偷奸耍滑，我们找一些双方都信得过的人，即 Validator，按照我们事先约定好的方法和标准，来实际验收一下你的工作，验收通过，皆大欢喜，我收获了成果，你的简历上多了一条成功的项目履历，这些呢，都通过区块链公开展示，这可不比单纯的好评要可信得多。

我们依然通过 Validation Registry 的一些关键方法和字段来了解 Validation Registry 的运行机制。

在 Validation Registry 中，主要的方法有两个，分别是 validationRequest 和 validationResponse。

以我所剩无几的英文基础，加上我的断句天赋，差不多能清晰地看穿它们的用途。

validationRequest 是给 Agent 用的，当你作为一个 Agent 完成了工作以后，很自然地就应该是提交工作成果，让 Validator 来验收。

validationResponse 是给 Validator 用的，验证通过还是不通过，就在这里说了算。

validationRequest 的全貌如下：

**function** validationRequest(address validatorAddress, uint256 agentId, string requestUri, bytes32 requestHash) external

其中的几个参数：

agentId 的用途和用法跟前面讲过的一样，我们不再赘述了。

validatorAddress 的用途很好猜，就是字面上的意思，验证者的地址，你找谁来验证总得明说吧。

requestUri，看到 Uri 大家应该都条件反射了，是的，没错，因为链上昂贵的价格以及少得可怜的存储空间，较大的数据一般都会在链下存储，存储位置呢通过 Uri 来指示。这个 requestUri 指向的文件呢，就是 Agent 的工作成果，要提交给 Validator 验证的。

同样的，为了防止 requestUri 指向的文件在链下被篡改，所以呢，还需要配上 requestHash 作为指纹信息，和前面 Reputation Registry 中用法一样一样的。

validationResponse 的全貌如下：

**function** validationResponse(bytes32 requestHash, uint8 response, string responseUri, bytes32 responseHash, bytes32 tag) external

其中几个参数：

requestHash 对应的就是 validationRequest 中的 requestHash ，这没毛病，验收结果得和验证对象严格对应。

response 是验收结果的总结，所谓总结，其实就是一个 0-100 之间的分数，至于多少分算高分，多少分算及格，这个我估计就只能具体问题具体分析了，毕竟，不同的应该场景对错误率的容忍度是完全不一样的。

当然了，只打分数不给理由多少有点耍流氓了，分给低了，Agent 要怀疑 Validator 是不是和用户勾结起来想吃霸王餐了，分给高了，用户又要怀疑 Validator 是不是被包养了。

所以呢，最好还是给出证据，于是，我们熟悉的 responseUri 和 responseHash 就出场了，证明 Validator 公平公正的证据——responseUri 指向的文件，和证明这个证据没有被篡改的证据——responseHash。

到此为止，有来有往，流程很清晰，机制很完美，可是总觉得差了点什么不是？

没错，就是验证标准和验证方法！！！

0 分和 100 分也许很容易分辨，也不会有太大争议，可是 59 分和 60 分呢？90 分和 91 分呢？有客观的标准吗？

ChatGPT 和 Claude 到底谁的编码能力更强？DeepSeek 的回答有没有让人满意？乔丹和詹姆斯谁是 GOAT？有一致性的答案吗？

我认为没有！

不是所有的东西都像 Crypto 的签名一样可以验证，不是所有的事情都算数题一样黑白清晰，不是对就是错的。

清官还难断家务事呢，这玩意，深究下去，是个无底洞啊。

看起来 Validation Registry 也是深谙强扭的瓜不甜的道路，很懂事地将这部分的实际操作和决策权交还给了群众，你也看到了，具体评判的标准是什么，评判的方法是什么，评判的结果大家能不能接受，其实在协议标准和链上的流程中并没有体现，实际上也没法体现。

我想，更多的细节，是需要在 ERC-8004 的不断试用过程中，逐步去总结和规范，然后在 ERC-8004 之外去沉淀和体现的。

非典型 ERC

仅仅是关于 ERC-8004，那差不多到上面就可以结束了，不过，作为一个 ERC 标准，ERC-8004 的某些方面确实不同寻常，这些不同寻常始终让我觉得很纠结，一方面，我觉得这在意料之外，另一方面，又觉得这在情理之中。

不同寻常来着与原文中这样一段话：

expect 的用词相对比较含蓄，不过描述的事情却很有霸道总裁的即视感。

正常来说，一个 ERC 标准，是给大家开放性使用的，我说的开放性使用的意思是指，你用的你的，我用我的，大家各不干扰。

同样的 ERC-20 标准，USDT 自己部署一套，USDC 也自己部署一套，大家井水不犯河水。

同样的 ERC-721 标准，无聊猿自己部署一套，胖企鹅也自己部署一套，桥归桥，路归路。

但是在 ERC-8004 这里，它的建议是，一条链上就部署一套，所有的项目方，Agent，都用这么一套来注册和管理。

考虑到它只是一个应用层协议，而非以太坊底层网络范式，正如最开始提到的一样，它其实是缺乏强制执行力的。

所以呢，在原文那段话中，用的是 expect 这样的词，而不是 must,甚至都不是 should。

只是，联想起 ERC-8004 的正统性和半官方的背景——没办法，你很难不联想到啊，拼爹这种事情哪里都存在的——它的 expect 也大概率会成为一种潜规则被真正执行下去。

毕竟，领导跟你谈话，如果用的是希望，建议这样的词的话，你不会真的只是当做领导在跟你许愿吧。

不过话说回来，这真的是个霸王条款吗，还是其实事出有因？

本着客观的标准，我认为确实是有合理性的。

这些年，特朗普的贸易战打得不可开交，充分诠释了什么叫做我不是针对你，我是说在座的各位都是垃圾。

各种关税和限制让普通人也能感受到了一个一体化的，开放的，有序的市场的重要性。

如果你也被各种涨价和限购搞过心态，那么，回到 ERC-8004 这里，就容易理解了。

ERC-8004 希望构建一个 Agent 的经济体，这个经济体越是一体化，越是开放，越是有序，就越是容易发展繁荣。

相比于各自为政，每个项目方都自己独立部署一套 ERC-8004 合约带来的割裂，如果大家都在同一套合约中开展注册登记和市场活动，那么交互链路就更简洁，相互之间的壁垒就更少，经济自然也就更自由，当然，前提是这个合约除了必要的管理职能外，不要随意插手具体的业务活动。

但是，如果只部署一套统一的合约的话，那么谁来部署呢？谁有这个号召力和公信力，让可能潜在都是市场竞争对手的项目方放下争议，共同支持呢？

答案不言而喻了，这也是我一再强调的正统性和半官方背景的意义。这样的词出现在 Web3 的世界里确实可能稍显违和，但是，它又确实在很多时候发挥着不可替代的作用。

现在，你应该能明白我说的意料之外却又情理之中的意思了吧，意料之外的是一个 ERC 标准的使用建议是只部署一个实例，情理之中的是从用途和愿景的角度，这也不失为一个合理的选择。

结语

关于 ERC-8004 的核心思想和实现方法，大概就是这些了，作为一个还没有最终定稿的提案，它的很多东西都处在动态变化中，没法作为最终的结论，但是纵观其从 Draft 到 Review 的种种改动，感觉设计理念和应用背景还是有比较好的一致性的，毕竟作为一个简历系统和劳动力市场，无论如何天翻地覆，基础的概念和手段和人类世界也没有太大的差别，所以仔细去阅读，还是很容易理解和接受的。

当然了，AI 始终处于发展之中，AI 与人类，AI 与 AI 之间的关系也在不断被重新定义，谁又知道未来会不会有什么让人意想不到的重大变革呢？

Stay hungry, Stay foolish !