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之间的关系也在不断被重新定义，谁又知道未来会不会有什么让人意想不到的重大变革呢？